Kubernetes集群中的Pod有时候会进入Terminating或Unknown状态,本文列举了6种可能的原因,帮助我们排查这种现象。原文: K8s Troubleshooting — Pod in Terminating or Unknown Status[1]
有时我们会看到K8S集群中的pod进入”Terminating“或”Unknown“状态,pod进入这两种状态可能有以下原因:
-
优雅终止周期(Graceful termination period): 当pod被删除时,会进入”Terminating”状态,等待容器优雅关闭。如果容器关闭所需时间超过默认期限(默认30秒),则pod将保持在”Terminating”状态。 -
Finalizers: Finalizer是一种允许在删除资源之前清理资源的机制。如果pod有Finalizer,并且相关的清理操作被卡住或没有响应,则pod将保持在”Terminating”状态。 -
无响应容器(Unresponsive containers): 如果pod中的容器在终止过程中没有响应SIGTERM信号,则可能导致pod卡在”Terminating”状态。 -
节点问题(Node issues): 如果节点无响应、断开连接或遇到其他问题,pod可能会进入”Unknown”状态。在这种情况下,Kubernetes控制平面无法确定pod的实际状态。 -
网络问题(Network issues): 节点与Kubernetes控制平面之间的连接问题可能导致pod进入”Unknown”状态。例如,如果控制平面无法与节点通信,则无法接收来自pod的状态更新。 -
Kubelet问题: 如果节点上运行的Kubelet进程出现问题或崩溃,可能会导致无法将pod状态上报给控制平面,从而造成pod进入”Unknown”状态。
故障排查
优雅终止周期(Graceful termination period)
K8S中的优雅终止周期是在删除pod时,容器的优雅关闭时间。在此期间,容器接收SIGTERM信号,执行必要的清理工作,例如关闭连接,完成正在进行的任务,并在资源终止之前释放资源,默认为30秒。
-
检查pod状态和事件: 通过 kubectl
检查pod的状态和事件以获取相关信息:
$ kubectl describe pod <pod-name> -n <namespace>
-
检查容器日志:
$ kubectl logs <pod-name> -c <container-name> -n <namespace> --previous
-
调整优雅终止周期: 如果容器始终需要更多的时间来清理资源,可以通过在pod的YAML文件中设置 terminationGracePeriodSeconds
字段来调整pod的终止周期。
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
terminationGracePeriodSeconds: 60
containers:
- name: my-container
image: my-image
Finalizers
Finalizer允许在删除资源之前清理资源,如果pod上存在Finalizer,并且相关的清理操作被卡住或没有响应,则pod将保持在”Terminating”状态。例如:
apiVersion: v1
kind: Pod
metadata:
name: my-finalizer-pod
finalizers:
- example.com/cleanup
spec:
containers:
- name: busybox
image: busybox
command: ["sh", "-c", "sleep 3600"]
检查是否有finalizer,可以运行以下命令:
$ kubectl get pod <pod-name> -n <namespace> -o json
如果确定不需要finalizer,或者确定可以将其安全删除,可以使用kubectl patch
命令。但是,这样做要小心,因为可能会导致意想不到的副作用:
$ kubectl patch pod <pod-name> -n <namespace> -p '{"metadata":{"finalizers":["<finalizer-1>", "<finalizer-2>", ...]}}'
无响应容器(Unresponsive containers)
当容器消耗过多系统资源时,可能会进入无响应状态。
-
用 kubectl describe
命令查看Pod状态和事件。
$ kubectl describe pod <pod-name> -n <namespace>
-
检查Pod/container日志:
$ kubectl logs <pod-name> -c <container-name> -n <namespace>
-
强制删除pod: 可以强制删除被卡住的pod
$ kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0
节点/网络/Kubelet问题
执行以下步骤处理节点问题:
-
检查节点状态/事件: 检查pod所在节点的状态:
$ kubectl describe node <node-name>
$ kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=<node-name>
-
检查节点系统日志
$ journalctl -u kubelet
$ journalctl -u docker
$ journalctl -u containerd
$ cat /var/log/messages
-
排空节点: 如果已经确定了节点问题,并且需要执行维护,可以排空节点以安全驱逐所有正在运行的pod,并将节点标记为不可调度:
$ kubectl drain <node-name>
结论
你好,我是俞凡,在Motorola做过研发,现在在Mavenir做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。微信公众号:DeepNoMind
参考资料
K8s Troubleshooting — Pod in Terminating or Unknown Status: https://blog.devgenius.io/k8s-troubleshooting-pod-in-terminating-or-unknown-status-2878f6ec66b8
– END –
原文始发于微信公众号(DeepNoMind):5分钟搞懂K8S Pod Terminating/Unknown故障排查
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/164801.html