【故障公告】Memcached 的“惹祸”，不知在为谁背锅
在 .NET 5.0 背锅 、 Memcached 的惹祸 、缓存雪崩之后，我们没有找到问题的真正原因，我们知道没有找到根源的故障总是会再次光临的，不是在这周就是在下周，也许就在双11前后。
就在今天双11的前一天晚上，在我们 20:30 进行常规发布的时候，它来了。。。
原本平滑的 memcached 服务器 tcp 连接数走势曲线开始爬坡，博客站点大量的访问请求响应缓慢，每次都“惹祸”的 memcached 自然首当其冲地成为嫌疑的焦点。
我们重启了所有 memcached 服务，tcp 连接数飞流直下三千尺地降了下来，但是降落之后却又开始新的一轮爬坡，故障没有恢复，网站访问速度依然缓慢。
这时，我们突然醒悟，memcached 没有惹祸，问题不在 memcached ，问题可能在前方阵地（用阿里云服务器自建的kubernetes集群）的 pods 发生了 tcp 连接泄漏，立马赶赴前线。
博客站点的多个 pod 处于 CrashLoopBackOff 状态
NAME READY STATUS RESTARTS AGE IP NODE blog-web-6644bfd597-2fpd6 1/1 Running 0 48m 192.168.86.93 k8s-n20 blog-web-6644bfd597-4cnc5 1/1 Running 0 49m 192.168.168.112 k8s-n6 blog-web-6644bfd597-bqbmf 0/1 CrashLoopBackOff 11 49m 192.168.73.63 k8s-node10 blog-web-6644bfd597-db8jk 0/1 Running 13 48m 192.168.107.238 k8s-node3 blog-web-6644bfd597-dthtn 0/1 CrashLoopBackOff 13 49m 192.168.104.103 k8s-node11 blog-web-6644bfd597-fxzml 1/1 Running 13 48m 192.168.195.224 k8s-node5 blog-web-6644bfd597-qvgkf 1/1 Running 12 47m 192.168.89.229 k8s-n8 blog-web-6644bfd597-slmp7 0/1 CrashLoopBackOff 13 49m 192.168.201.126 k8s-n14 blog-web-6644bfd597-txg5h 0/1 CrashLoopBackOff 13 45m 192.168.42.57 k8s-n13 blog-web-6644bfd597-wc57c 0/1 Running 13 47m 192.168.254.167 k8s-n7 blog-web-6644bfd597-xt5hc 0/1 CrashLoopBackOff 11 47m 192.168.228.53 k8s-n9 blog-web-6644bfd597-zz564 1/1 Running 0 47m 192.168.118.27 k8s-n4
怀疑造成 tcp 连接泄漏可能是这些处于 CrashLoopBackOff 状态的 pod ，于是将 pod 全部强制删除，在删除后过了一段时间，memcached 服务器 tcp 连接数从爬坡状态回归平滑状态，故障就恢复了。
查看 k8s 集群 node 服务器的 tcp 连接情况，在故障期间，node 服务器的 tcp 连接数上蹿下跳，大量 tcp 连接无法建立。
到目前我们还是没有找到问题的根源，但我们知道了 memcached 没有惹祸，memcached 是在背锅，但不知道在为谁背锅。
非常抱歉，今天 20:35~21:35 左右博客站点发生的故障给您带来麻烦了，请您谅解。
