k8s故障处理经典案例（ClassicCaseofk8sFaultHandling）

k8s故障处理经典案例 问题描述

kubernetes版本：v1.22.5

部分Pod在新版本发布后一直处于ContainerCreating状态，经过kubectl delete命令删除后一直Terminating状态。

排查过程

遇到问题先查日志

首先进入宿主机，查看三个日志，按照pod名称及imageid进行筛选。其中pod名称为khaos-guardian-bmzsk ，imageid为1da9e4f1-a5d4-40db-b8bc-4db1d27ca458。

kubelet

日志：journalctl -u kubelet | grep khaos-guardian-bmzsk 

docker

日志：journalctl -u docker | grep 1da9e4f1-a5d4-40db-b8bc-4db1d27ca458

系统日志：cd /var/log && grep khaos-guardian-bmzsk  messages

花费了不少时间检索日志，实际上没有找到任何有用的信息。

配置细节排查

我们可以看到整个集群只有这个daemonset的pod出现过这个问题，其他的pod没有出现，那么可能问题出在这个daemonset的某些配置引发的这个问题。但这个daemonset的配置比较复杂，并且包含4个container，所以这块排查起来很吃力，也比较浪费时间。经过细节的梳理，以及团队内部同学的协作，我们最终发现是有两个配置项引发的问题。

hostPIDlifecycle.postStart hostPID

官方文档： kubernetes.io/docs/concepts/security/pod-security-standards/

配置到pod spec中，用于让Pod中的所有容器感知宿主机的进程信息，并且执行进程管理。

此外，相关联的还有一个shareProcessNamespace配置，也是配置到pod spec中，用于单pod多container场景下让pod下的container相互感知pid，具体介绍： kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/

lifecycle.postStart

用于在指定container成功Running后执行一些自定义脚本，具体介绍： kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

相关联的docker bug

这里与hostPID/shareProcessNamespace相关的有一个docker的bug： github /kubernetes/kubernetes/issues/92214

当开启进程信息共享时，如果对docker容器执行exec命令，并且docker容器先于exec进程退出，那么此时exec的执行会卡住。

docker bug复现过程

通过docker run运行一个容器：

docker run -d --pid=host --rm --name nginx nginx

在另一个终端执行docker exec指令：

docker exec -it nginx sh

随后kill容器：

docker kill nginx

可以看到当kill掉容器后，对应的exec进程此时卡住了，无法退出，只能强行关闭终端解决。 

Kubernetes Pod管理细节

如果想要了解这个docker bug对pod生命周期的影响，我们来看看kubernetes源码中的pod创建流程。首先了解一个背景，kubernetes的每一个pod在kubelet中都对应有一个goroutine一一对应来管理维护其reconcile，即任何pod spec的变更或者宿主机container status的变化都由该goroutine来保证执行和同步。

SyncPod

每当Pod Spec变化时，例如创建时，会按照EphemeralContainers、InitContainers、Containers依次执行容器创建。具体参考： github /kubernetes/kubernetes/blob/b722d017a34b300a2284b890448e5a605f21d01e/pkg/kubelet/kuberuntime/kuberuntime_manager.go#L1048

这种创建虽然在kubernetes中是顺序执行的，但是宿主机的容器启动成功却是异步的，不能保证顺序性。有的容器可能在最开始执行创建，但是可能在最后才运行成功。

但是，如果容器中存在PostStart脚本，那么将会阻塞后续容器的创建，需要等待PostStart脚本执行完成后才会继续执行。具体参考： github /kubernetes/kubernetes/blob/b722d017a34b300a2284b890448e5a605f21d01e/pkg/kubelet/kuberuntime/kuberuntime_container.go#L297

如果底层是docker，那么这里使用的便正是docker exec命令来实现的PostStart自定义脚本执行。

解决问题

找到问题根因后，解决目前集群中Terminating的Pod就比较简单了。

step1：检索出Terminating的Pod

kubectl get pod -n xxx -owide | grep Terminating

step2：进入宿主机干掉docker容器

kubectl node-shell x.x.x.x docker ps -a | grep xxx docker rm -f xxx exit

step3：退出宿主机，强删对应的Pod

kubectl delete -n xxx pod/xxx --force

操作记录：

问题总结

尽量不要使用docker作为底层容器管理工具。

尽量不要在pod中使用postStart自定义脚本。