【故障公告】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 左右部落格站點發生的故障給您帶來麻煩了，請您諒解。
