今天凌晨我們用阿里雲伺服器自建的 kubernetes 叢集出現突發異常情況，部落格站點（blog-web）與部落格 web api（blog-api）的 pod 無法正常啟動（CrashLoopBackOff）。 kubectl get pods -l app=blog-web ```text NAME READY STATUS RESTARTS AGE blog-web-79d579cd94-5t8w4 0/1 CrashLoopBackOff 10 34h blog-web-79d579cd94-gjwct 0/1 CrashLoopBackOff 10 34h blog-web-79d579cd94-hsgfv 1/1 Running 1 32m blog-web-79d579cd94-jj4gt 1/1 Running 0 34h blog-web-79d579cd94-k5rmv 1/1 Running 0 34h blog-web-79d579cd94-mc8hs 1/1 Running 1 24h blog-web-79d579cd94-td9pp 1/1 Running 1 32m blog-web-79d579cd94-trpsn 0/1 CrashLoopBackOff 10 34h blog-web-79d579cd94-w9w7v 1/1 Running 1 109m blog-web-79d579cd94-zgrq4 1/1 Running 1 109m blog-web-79d579cd94-zm4sh 0/1 CrashLoopBackOff 10 34h blog-web-79d579cd94-zrqln 1/1 Running 0 34h ``` kubectl get pods -l app=blog-api ```text NAME READY STATUS RESTARTS AGE IP blog-api-599bdd9787-9cpn7 0/1 CrashLoopBackOff 78 33h 192.168.139.55 blog-api-599bdd9787-zfbdh 0/1 CrashLoopBackOff 76 33h 192.168.132.239 ``` CrashLoopBackOff 的原因是讀取不到 CofigMap 掛載的 volume 中的 appsettings.Production.json 檔案。 blog-web 的錯誤日誌 > failed to start container "blog-web": Error response from daemon: OCI runtime create failed: container_linux.go:346: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"/var/lib/kubelet/pods/022d72c9-a85f-4c58-bc27-c8ba414c5d5a/volume-subpaths/appsettings/blog-web/0\\\" to rootfs \\\"/var/lib/docker/overlay2/f4c8e87344c54969e041f11ef73d1617970c64f05e5415c5d5456517e208a5a0/merged\\\" at \\\"/var/lib/docker/overlay2/f4c8e87344c54969e041f11ef73d1617970c64f05e5415c5d5456517e208a5a0/merged/app/appsettings.Production.json\\\" caused \\\"no such file or directory\\\"\"": unknown blog-api 的錯誤日誌 > OCI runtime create failed: container_linux.go:346: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"/var/lib/kubelet/pods/81c1715d-7ac4-469f-afa8-980b87d604b1/volume-subpaths/appsettings/blog-api/0\\\" to rootfs \\\"/var/lib/docker/overlay2/9a5dc28604d305180bc9e026db21570b22ff685d0b4db3e3df863f3dfca0f515/merged\\\" at \\\"/var/lib/docker/overlay2/9a5dc28604d305180bc9e026db21570b22ff685d0b4db3e3df863f3dfca0f515/merged/app/appsettings.Production.json\\\" caused \\\"no such file or directory\\\"\"": unknown 我們的應用容器在啟動時會從 volume 中複製 appsettings.Production.json 檔案到當前應用所在的資料夾，複製失敗會導致容器無法啟動。 blog-web 部署的 pod replica 比較多，只有部分 pod 宕機，對部落格站點的訪問影響不大。而 blog-api 只部署了2個 pod replica，全部宕機，本來即使 blog-api 全部宕機也不會造成致命影響，但是。。。 但是，在部落格後臺（i-web）的 pod 健康檢查（readinessProbe與livenessProbe）中卻強依賴了 blog-api（這個地方會改進），在健康檢查時會請求 blog-api 進行檢查，如果請求失敗，i-web 的健康檢查也失敗，結果 blog-api pod 全部宕機最大的受害者是部落格後臺， i-web 的 pod 因健康檢查失敗全部宕機。 ```text NAME READY STATUS RESTARTS AGE i-web-7996f9679b-fk6hk 0/1 CrashLoopBackOff 98 5d10h i-web-7996f9679b-gsz2j 0/1 CrashLoopBackOff 107 5d13h i-web-7996f9679b-xfj5d 0/1 CrashLoopBackOff 101 5d10h ``` 從而造成從凌晨1:49左右故障發生開始，部落格後臺一直502，直到7:50左右才恢復。 發現故障後，我們採取的處理方法是強制刪除處於 CrashLoopBackOff 狀態的 pod ```bash kubectl delete pod $1 --force --grace-period 0 ``` 舊版 pod 刪除後，新 pod 都能正常啟動，於是故障恢復。 這是我們自[去年2月23日](https://www.cnblogs.com/cmt/p/12353192.html)將生產環境切換到 k8s 之後第一次與這個 CofigMap 掛載問題相遇，到目前我們也不知道為什麼會這樣？但我們知道這不是百年修得同船渡的緣分，這是我們接下來面臨的一個挑戰——上船容易，開船難。而且，今年我們正在進行全員登船——將所有部署環境都遷移到k8s上，這個挑戰將變得更大，但我們已經下定決心，2013年上雲，2021年擁抱雲原生。 非常抱歉，這次故障給您帶來了很大的麻煩，請您諒解！園子的高可用是我們今年重點解決的一個問題，請給我們一些時間。