当前位置: 首页 > news >正文

k8s故障处理经典案例(Classic Case of k8s Fault Handling)

k8s故障处理经典案例

问题描述

kubernetes版本:v1.22.5

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

排查过程

遇到问题先查日志

首先进入宿主机,查看三个日志,按照pod名称及imageid进行筛选。其中pod名称为khaos-guardian-bmzsk ,imageid1da9e4f1-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相关的有一个dockerbug:https://github.com/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 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

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

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

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

解决问题

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

step1:检索出TerminatingPod

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自定义脚本。


http://www.mrgr.cn/news/91839.html

相关文章:

  • 最新本地部署 DeepSeekR1 蒸馏\满血量化版 + WebOpenUI 完整教程(Ubuntu\Linux系统\Ollama)
  • 用户中心项目教程(九)---前端页面设计测试登录功能
  • YOLOv8与BiFormer注意力机制的融合:提升多场景目标检测性能的研究
  • JavaScript数据类型全解析,怎么区分呢?
  • 【spring】静态代理与动态代理 | AOP面向切面编程
  • stm32单片机个人学习笔记15(I2C通信协议)
  • NLP-RNN-LSTM浅析
  • 自然语言处理NLP 02统计语言模型
  • 【Quest开发】全身跟踪(一)
  • 嵌入式学习(18)---Linux文件编程中的进程
  • LeetCode 热题 100_搜索插入位置(63_35_简单_C++)(二分查找)(”>>“ 与 “/” 对比)
  • 雷龙CS SD NAND(贴片式TF卡)测评体验
  • uni-app开发app时 使用uni.chooseLocation遇到的问题
  • vue3学习1
  • Express 模块
  • elasticsearch在windows上的配置
  • 详解TCP协议多种机制
  • [NKU]C++理论课 cours 3 数据抽象(封装->隐藏实现的手段,隐藏->封装的重要目标)
  • 适用于复杂背景的YOLOv8改进:基于DCN的特征提取能力提升研究
  • 毕业项目推荐:基于yolov8/yolo11的100种中药材检测识别系统(python+卷积神经网络)