Kubernetes实战K8S集群Pod异常状态排查
Posted Friends of the wind
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Kubernetes实战K8S集群Pod异常状态排查相关的知识,希望对你有一定的参考价值。
机缘
本文旨在帮助朋友们能快速定位、以最简单可行只法解决遇到的问题,希望您能举一反三,篇幅有限不能详尽,见谅 (*^__^*)
内容概括:
- 实战项目经验
如何有效减少排查解决问题的时间?尤其是有些问题解决,需要停服务,会影响关联的业务。 - 遇到的问题实用解法
- 扩展延伸
一、 实战项目经验
提示:意识理念很重要,所以先要保证遵守原则不变,才能处变不惊,最高效解决问题。我总结了三原则
原则:
- 勿求快,多想一步,多问一句 即便是感觉很小的操作,也要考虑到可能发生意料外之事,我们之前出现过几次类似问题,都是同一种方法解决的,同样的情况出现,可是这次,背景不一样,用相同的方法,不但没解决问题,还制造了新问题,欲速不达。
- 要全面了解 正向的反馈,不利的反馈都要听,提前做些努力,想出应对之法,做的时候会特别顺畅,高效。
- 不光多看运维文档,而且要用心观察 遇到一个问题,我们费了好大力气,花费时间不少,想最快解决,却找不到参照方法。等静下心,我发现运维文档的预案里明明就有,当时为什么就视而不见,现在想想,这类问题发生的次数少,而且平时这个文档阅读的少,而且是粗略的看。
二、遇到的问题实用解法
提示:当前创作和你的工作、学习是什么样的关系
例如:
- 节点NotReady
图1 命令返回信息显示节点异常
简单问题:可以一条命令看到,程序dead状态,直接启动即可。
1)kubelet进程异常
执行查看命令:systemctl status kubelet.service
执行启动命令:systemctl start kubelet.service
2)docker进程异常
执行命令:systemctl status docker.service
执行启动命令:systemctl start docker.service
复杂问题:需要执行多条命令,并和其他部门同事沟通确认情况,综合分析协助定位问题并解决。
依然是NodeReady报错:
第一步:执行上面两个查看服务状态命令,返回信息显示无异常;
第二步:执行kubectl describe nodes node01(异常节点名) | grep Events
在事件列信息里确认是哪里出现问题,如果显示和docker有关,则证明还是“docker进程异常”,但是状态并没有死掉。
第三步:docker为什么会异常?因场景而异,有的时候是承载docker的节点物理内存不足,导致进程被杀死,或没被杀死,不能提供正常运行及处理任务所需内存。
第四步:想办法释放节点内存,重启docker服务。
- pod异常状态
1)镜像下载失败:ImagePullBackOff
简单问题:镜像仓库异常或pod的镜像仓库配置项不正确。
解决方法:执行kubectl describe nodes node01(异常节点名) | grep Events,进一步确认是不是这个问题,或者是不是还有其他问题。docker images本地可以查看到镜像,则需要将其执行:docker push ip:port/soft:v1.0将其推送到私有远程仓库,如果用pod控制器创建的可以删除pod,自动创建方式实现重建pod。如果还是不成功,可能也有网络问题,需要手动导入docker.tar包文件,执行docker load即可。
2)pod状态为Error、Unknown
小知识:pod稳定态为Running、Error、Unknown,其余都是中间态;稳定态是一般情况不会变化了,此状态可能原因是镜像下载的次数超了配置的次数,不再尝试重试,返回的状态。
解决方法:一般是配置问题,如:请求的资源超过了管理员设置的限制。执行下面三条命令:
kubectl get pod -o yaml 与正常的pod对比确认 Pod 的配置是否正确
kubectl describe pod 查看 Pod 的事件
kubectl logs [-c ] 查看容器日志
此外,Unknown也可能是网络问题导致。多个应用部署在不同节点需要交互。
三、扩展延伸
提示:对基础知识了解的越透彻,k8s运行逻辑越清楚,越能快速定位问题,解决问题。
例如:
-
k8s网络小知识
图2 k8s网络拓扑从微观来分:
1)容器间通信 例如:docker与docker
2)pod间通信
3)服务到pod通信 例如:service到pod
从宏观来分:
1)pod间通信 pod1和pod2属于同主机;pod1和pod3属于跨主机
2)Node与pod间通信 Node1和pod1/pod2属于同主机;Node1和pod3属于跨主机
跨主机通信,需要借助第三方网络插件,如:Flannel等
以上是关于Kubernetes实战K8S集群Pod异常状态排查的主要内容,如果未能解决你的问题,请参考以下文章
云原生之kubernetes实战k8s集群下的DaemonSet 高级资源对象
云原生之kubernetes实战在k8s集群环境下部署Tomcat应用
云原生之kubernetes实战在k8s环境下部署Heimdall导航页
云原生之kubernetes实战kubernetes集群的HPA弹性伸缩