【故障公告】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 左右博客站点发生的故障给您带来麻烦了,请您谅解。