【故障公告】K8s CofigMap 挂載問題引發網站故障

這是我們自去年2月23日将生産環境切換到 k8s 之後第一次與這個 CofigMap 挂載問題相遇，到目前我們也不知道為什麼會這樣？但我們知道這不是百年修得同船渡的緣分，這是我們接下來面臨的一個挑戰——上船容易開船難。非常抱歉，這次故障給您帶來了很大的麻煩，請您諒解！園子的高可用是我們今年重點解決的一個問題，請給我們一些時間。

今天淩晨我們用阿裡雲伺服器自建的 kubernetes 叢集出現突發異常情況，部落格站點（blog-web）與部落格 web api（blog-api）的 pod 無法正常啟動（CrashLoopBackOff）。

kubectl get pods -l app=blog-web

kubectl get pods -l app=blog-api

CrashLoopBackOff 的原因是将 CofigMap 挂載到容器 volume 失敗。

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

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 因健康檢查失敗全部當機。

進而造成從淩晨1:49左右故障發生開始，部落格背景一直502，直到7:50左右才恢複。

發現故障後，我們采取的處理方法是強制删除處于 CrashLoopBackOff 狀态的 pod

舊版 pod 删除後，新 pod 都能正常啟動，于是故障恢複。

這是我們自去年2月23日将生産環境切換到 k8s 之後第一次與這個 CofigMap 挂載問題相遇，到目前我們也不知道為什麼會這樣？但我們知道這不是百年修得同船渡的緣分，這是我們接下來面臨的一個挑戰——上船容易，開船難。而且，今年我們正在進行全員登船——将所有部署環境都遷移到k8s上，這個挑戰将變得更大，但我們已經下定決心，2013年上雲，2021年擁抱雲原生。

非常抱歉，這次故障給您帶來了很大的麻煩，請您諒解！園子的高可用是我們今年重點解決的一個問題，請給我們一些時間。

deployment 配置檔案中對應的 ConfigMap 挂載配置

根據評論中 @瘋狂的小企鵝 建議：

最好還是不要用subpath的方式将configMap Volume挂載到容器裡去

我們将采用 projected volume 的方式挂載 ConfigMap，對應的配置如下