【故障公告】K8s CofigMap 挂载问题引发网站故障

今天凌晨我们用阿里云服务器自建的 kubernetes 集群出现突发异常情况，博客站点（blog-web）与博客 web api（blog-api）的 pod 无法正常启动（CrashLoopBackOff）。

kubectl get pods -l app=blog-web

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

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 因健康检查失败全部宕机。

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

kubectl delete pod $1 --force --grace-period 0

旧版 pod 删除后，新 pod 都能正常启动，于是故障恢复。

这是我们自去年2月23日将生产环境切换到 k8s 之后第一次与这个 CofigMap 挂载问题相遇，到目前我们也不知道为什么会这样？但我们知道这不是百年修得同船渡的缘分，这是我们接下来面临的一个挑战——上船容易，开船难。而且，今年我们正在进行全员登船——将所有部署环境都迁移到k8s上，这个挑战将变得更大，但我们已经下定决心，2013年上云，2021年拥抱云原生。

非常抱歉，这次故障给您带来了很大的麻烦，请您谅解！园子的高可用是我们今年重点解决的一个问题，请给我们一些时间。