Pod异常问题排查
本文介绍关于Pod异常问题的诊断流程、排查方法、常见问题及解决方案。
排查流程
1、首先需查看Pod是否处于异常状态，具体操作请参见下文【 检查Pod的状态 】相关章节
2、如果Pod状态异常，可通过在容器服务控制台查看Pod事件、Pod日志、Pod配置等信息确定异常原因
3、如果Pod状态为Running但并未正常工作，请参见下文【 Pod状态为Running但没正常工作 】章节
4、若确认Pod状态异常是由Pod OOM所致，请参见【 Pod OOM异常问题处理 】章节
5、如果根据本文的操作说明问题仍未解决，请提交工单申请售后服务
常规排查方法
检查Pod的状态
1、登录控制台
2、在控制台左侧导航栏，单击集群
3、在集群列表页面，单击目标集群名称
4、在集群管理页左侧导航栏，选择工作负载 > 容器组
5、在容器组页面顶部选择Pod所在的 命名空间 ，查看Pod状态。若状态为Running，说明Pod运行正常。若状态不为Running，说明Pod状态异常
检查Pod的详情
1、登录控制台
2、在控制台左侧导航栏，单击集群
3、在集群列表页面，单击目标集群名称
4、在集群管理页左侧导航栏，选择工作负载 > 容器组
5、在容器组页面顶部选择Pod所在的命名空间，然后单击目标Pod名称，查看Pod的名称、镜像、Pod IP、所在节点等详细信息
检查Pod的配置
1、登录控制台
2、在控制台左侧导航栏，单击集群
3、在集群列表页面，单击目标集群名称或者目标集群右侧操作列下的详情
4、在集群管理页左侧导航栏，选择工作负载 > 容器组
5、在容器组页面左上角选择Pod所在的命名空间，然后单击目标Pod名称或者目标Pod右侧操作列下的详情
6、在Pod详情页面右上角单击编辑，查看Pod的YAML文件和详细配置
检查Pod的事件
1、登录控制台
2、在控制台左侧导航栏，单击集群-运维管理-事件中心
3、在时间列表页面选择查询选项，类型选择为pod，选择命名空间和名称选项
4、点击查询按钮查看pod事件
检查Pod的日志
1、登录控制台
2、在控制台左侧导航栏，单击集群-运维管理-日志中心
3、日志中心需要使用ctg-log-operator插件支持，若未安装插件，根据页面提示安装ctg-log-operator插件
4、在日志中心页面，切换到应用日志标签页，依次选择命名空间、负载类型、负载名称、开始结束时间，然后点击搜索按钮查看Pod的日志
检查Pod的监控
1、登录控制台
2、在控制台左侧导航栏，单击集群-运维管理-监控
3、监控功能需要使用ccse-monitor插件支持，若未安装插件，根据页面提示安装ccse-monitor插件
4、在集群健康页面，选择查看Pod的CPU、内存、网络I/O等监控大盘
使用终端进入容器
1、登录控制台
2、在控制台左侧导航栏，单击集群
3、在集群列表页面，单击目标集群名称或者目标集群右侧操作列下的详情
4、在集群管理页左侧导航栏，选择工作负载> 容器组
5、在容器组页面，单击目标容器组右侧远程登陆
6、可通过终端进入容器，在容器内查看本地文件等信息
Pod状态为Pending
问题现象：Pod长期处于Pending状态。
问题原因：Pod长期处于Pending状态是因为Pod不能被调度到某一个节点上。通常是由于资源依赖、资源不足、该Pod使用了hostPort、污点和容忍等原因导致集群中缺乏需要的资源。
解决方案：通过查看Pod的事件定位Pod不能被调度到节点的原因，常见的原因有以下几类：
1、存在资源依赖。创建Pod时，需要依赖于集群中ConfigMap、PVC等资源。例如，Pod添加存储卷声明前，存储卷声明需要先与存储卷绑定。
2、资源不足。在集群信息页面，查看节点CPU、内存的使用情况，确定集群的资源使用率。若集群中的CPU或内存都已经耗尽，可参考如下方法处理：
- 调整deployment资源类型副本数量
- 调整Pod的资源配置
- 为集群添加新的节点
- 为节点进行升配
3、使用了hostPort，使用hostPort会导致因端口新占用导致Pod新副本无法调度到节点，改为通过Service访问Pod。
4、污点和容忍。当在Pod的事件中看到Taints或Tolerations时，说明是由于污点导致，可以删除污点或者给Pod设置容忍。
Pod状态为ImagePullBackOff
问题现象: Pod的状态为ImagePullBackOff。
问题原因: Pod使用的镜像拉取失败，可能因镜像地址错误，或者遇到网络问题，导致镜像无法拉取。
解决方案: 查看Pod的事件描述，找到无法拉取的镜像地址，确认容器镜像地址是否正确。若地址无误，登录到Pod所在的节点，手动执行docker pull 命令看镜像是否能正常拉取。
Pod状态为CrashLoopBackOff
问题现象: Pod的状态为CrashLoopBackOff。
问题原因: Pod中的应用负载启动失败所致。
解决方案: 1、查看Pod的日志，定问题原因。2、查看Pod的存活探针和就绪探针配置是否正确。
Pod状态为Completed
问题现象: Pod的状态为Completed。
问题原因: Pod中的应用程序正常执行后退出，若应用行为不符合预期则需要排查。
解决方案: 1、查看Pod配置，检查Pod中容器的启动命令是否正确。2、通过Pod日志定位问题。
Pod状态为Running但没正常工作
问题原因: 部署使用的YAML文件有问题。
问题现象: Pod状态为Running但没正常工作。
解决方案: 1、查看Pod的配置，确定应用的启动参数是否存在问题。2、检查Pod的环境变量配置是否存在问题。3、查看Pod的日志，通过日志内容排查问题。4、通过控制台提供的远程登陆功能进入到容器内部排查
Pod状态为Terminating
问题现象：Pod状态为Terminating。
问题原因：Pod正处于关闭状态。
解决方案：若Pod一直停留在Terminating状态，可执行如下命令强制删除：
kubectl delete pod -n --grace-period=0 --force
Pod状态为Evicted
问题现象：Pod的状态为Evicted。
问题原因：当节点的内存、磁盘空间、文件系统的inode和操作系统可分配的PID等资源中的一个或者多个达到特定的消耗水平，节点的kubelet进程就会主动地驱逐一到多个Pod，以回收节点资源。
解决方案：
1、执行以下命令，查看Pod的status.message字段，来确定Pod被驱逐的原因。
kubectl get pod -o yaml -n
2、执行以下命令，删除被驱逐的Pod。
kubectl get pods -n | grep Evicted | awk '{print $1}' | xargs kubectl delete pod -n
Pod OOM异常问题处理
问题现象：容器异常重启，并重启次数较多
问题原因：Pod使用超过其限制的内存
解决方案：
1、确定发生OOM异常的Pod所在的节点
2、登录Pod所在的Node，查看系统日志文件/var/log/message，搜索out of memory关键字，确认具体被OOM终止时间点和进程名称
3、根据Pod的内存监控数据，排查Pod内应用进程否存在内存泄漏。若应用进程存在内存泄漏导致需客户自行修正程序漏洞。若进程运行状态正常，则根据实际运行需要，适当增大Pod的内存限制
