Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

问题描述

kubernetes版本:v1.22.5

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

排查过程

遇到问题先查日志

首先进入宿主机,查看三个日志,按照pod名称及imageid进行筛选。其中pod名称为khaos-guardian-bmzskimageid1da9e4f1-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

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

配置细节排查

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

  • hostPID
  • lifecycle.postStart

hostPID

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

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

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

lifecycle.postStart

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

相关联的docker bug

这里与hostPID/shareProcessNamespace相关的有一个dockerbughttps://github.com/kubernetes/kubernetes/issues/92214

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

docker bug复现过程

通过docker run运行一个容器:

Code Block
languagexml
docker run -d --pid=host --rm --name nginx nginx

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

Code Block
languagexml
docker exec -it nginx sh

随后kill容器:

Code Block
languagexml
docker kill nginx

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

Kubernetes Pod管理细节

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

SyncPod

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

Image Added

Tip

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

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

Image Added

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

解决问题

找到问题根因后,解决目前集群中TerminatingPod就比较简单了。

step1:检索出TerminatingPod

Code Block
languagexml
kubectl get pod -n xxx -owide | grep Terminating

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

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

step3:退出宿主机,强删对应的Pod

Code Block
languagexml
kubectl delete -n xxx pod/xxx --force

操作记录:

Image Added

Image Removed


问题总结

  • 尽量不要使用docker作为底层容器管理工具。
  • 尽量不要在pod中使用postStart自定义脚本。







Panel
titleContent Menu

Table of Contents