在 .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 左右博客站點發生的故障給您帶來麻煩了,請您諒解。網站