在 .NET 5.0 背锅 、 Memcached 的惹祸 、缓存雪崩以后,咱们没有找到问题的真正缘由,咱们知道没有找到根源的故障老是会再次光临的,不是在这周就是在下周,也许就在双11先后。html
就在今天双11的前一天晚上,在咱们 20:30 进行常规发布的时候,它来了。。。node
本来平滑的 memcached 服务器 tcp 链接数走势曲线开始爬坡,博客站点大量的访问请求响应缓慢,每次都“惹祸”的 memcached 天然首当其冲地成为嫌疑的焦点。web
咱们重启了全部 memcached 服务,tcp 链接数飞流直下三千尺地降了下来,可是降落以后却又开始新的一轮爬坡,故障没有恢复,网站访问速度依然缓慢。缓存
这时,咱们忽然醒悟,memcached 没有惹祸,问题不在 memcached ,问题可能在前方阵地(用阿里云服务器自建的kubernetes集群)的 pods 发生了 tcp 链接泄漏,立马赶赴前线。服务器
博客站点的多个 pod 处于 CrashLoopBackOff 状态tcp
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 链接数从爬坡状态回归平滑状态,故障就恢复了。memcached
查看 k8s 集群 node 服务器的 tcp 链接状况,在故障期间,node 服务器的 tcp 链接数上蹿下跳,大量 tcp 链接没法创建。oop
到目前咱们仍是没有找到问题的根源,但咱们知道了 memcached 没有惹祸,memcached 是在背锅,但不知道在为谁背锅。post
很是抱歉,今天 20:35~21:35 左右博客站点发生的故障给您带来麻烦了,请您谅解。网站