【故障公告】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，对应的配置如下