Pod异常问题排查和解决方法 |
您所在的位置:网站首页 › 重启ipc是什么意思 › Pod异常问题排查和解决方法 |
本文目录类别内容诊断流程诊断流程常见排查方法检查Pod的状态检查Pod的详情检查Pod的配置检查Pod的事件检查Pod的日志检查Pod的监控使用终端进入容器Pod故障诊断常见问题及解决方案常见的Pod异常状态及处理方式Pod OOM异常问题处理诊断流程![]() 问题原因 若Pod停留在Pending状态,说明该Pod不能被调度到某一个节点上。通常是由于资源依赖、资源不足、该Pod使用了hostPort、污点和容忍等原因导致集群中缺乏需要的资源。 问题现象 Pod的状态为Pending。 解决方案 查看Pod的事件,根据事件描述,定位Pod不能被调度到节点的原因。主要原因有以下几类: 资源依赖创建Pod时,需要依赖于集群中ConfigMap、PVC等资源。例如,Pod添加存储卷声明前,存储卷声明需要先与存储卷绑定。 资源不足在集群信息页面,选择节点管理 > 节点,查看容器组、CPU、内存的使用情况,确定集群的资源使用率。说明 某个节点实际使用的CPU、内存资源非常低,新加入一个Pod时,如果会导致实际使用的资源超过该节点最大可供使用的资源,则调度程序不会将该Pod分配到该节点。这样可避免在日常的流量高峰时段,节点上出现资源短缺的情况。若集群中的CPU或内存都已经耗尽,可参考如下方法处理。删除或减少不必要的Pod。具体操作,请参见管理容器组(Pod)。根据自身业务情况,调整Pod的资源配置。具体操作,请参见设置容器的CPU和内存资源上下限。在集群中添加新的节点。具体操作,请参见创建节点池。为节点进行升配。具体操作,请参见升配Worker节点的资源。该Pod使用了hostPort如果您使用了hostPort,那么Deployment或ReplicationController中Replicas值不能超过集群中的节点数,因为每个实例的任意端口只有一个。如果该端口被其他应用占用,将导致Pod调度失败。因此建议您不要使用hostPort,您可以使用Service访问Pod,更多信息,请参见Service。 污点和容忍当您在Pod的事件中看到Taints或Tolerations时,说明是由于污点导致,您可以删除污点或者给Pod设置容忍。更多信息,请参见管理节点污点、创建无状态工作负载Deployment和污点和容忍。 Pod状态为Init:N/M(Init:Error和Init:CrashLoopBackOff)问题原因 若Pod停留在Init:N/M状态,说明该Pod包含M个Init容器,其中N个已经启动完成,但仍有M-N个Init容器未启动成功。若Pod停留在Init:Error状态,说明Pod中的Init容器启动失败。若Pod停留在Init:CrashLoopBackOff状态,说明Pod中的Init容器启动失败并处于反复重启状态。问题现象 Pod的状态为Init:N/M。Pod的状态为Init:Error。Pod的状态为Init:CrashLoopBackOff。解决方案 查看Pod的事件,确认当前Pod中未启动的Init容器是否存在异常。具体操作,请参见检查Pod的事件。查看Pod中未启动的Init容器的日志,通过日志内容排查问题。具体操作,请参见检查Pod的日志。查看Pod的配置,确认未启动的Init容器配置是否正常。具体操作,请参见检查Pod的配置。关于Init容器的更多信息,请参见调试Init容器。Pod状态为ImagePullBackOff问题原因 若Pod停留在ImagePullBackOff状态,说明此Pod已被调度到某个节点,但拉取镜像失败。 问题现象 Pod的状态为ImagePullBackOff。 解决方案 通过查看该Pod的事件描述,查看具体拉取失败的镜像名称。 确认容器镜像名称是否正确。登录到Pod所在的节点,执行docker pull [$Image]命令,查看是否能正常抓取容器镜像。说明 [$Image]为容器镜像的名称。若镜像拉取失败,请参见docker pull失败解决。如果您使用的是私有镜像仓库,请参见使用私有镜像仓库创建应用解决。Pod状态为CrashLoopBackOff问题原因 若Pod停留在CrashLoopBackOff状态,说明容器中应用程序有问题。 问题现象 Pod的状态为CrashLoopBackOff。 解决方案 查看Pod的事件,确认当前Pod是否存在异常。具体操作,请参见检查Pod的事件。查看Pod的日志,通过日志内容排查问题。具体操作,请参见检查Pod的日志。查看Pod的配置,确认容器中的健康检查配置是否正常。具体操作,请参见检查Pod的配置。关于Pod健康检查的更多信息,请参见配置存活、就绪和启动探测器。Pod状态为Completed问题原因 若Pod出现Completed状态,说明容器中的启动命令已执行完毕,容器中的所有进程都已退出。 问题现象 Pod的状态为Completed。 解决方案 查看Pod的配置,确定Pod中容器的启动命令。具体操作,请参见检查Pod的配置。查看Pod的日志,通过日志内容排查问题。具体操作,请参见检查Pod的日志。Pod状态为Running但没正常工作问题原因 部署使用的YAML文件有问题。 问题现象 Pod状态为Running但没正常工作。 解决方案 查看Pod的配置,确定Pod中容器的配置是否符合预期。具体操作,请参见检查Pod的配置。使用以下方法,排查环境变量中的某一个Key是否存在拼写错误。以command拼写成commnd为例,说明拼写问题排查方法。 说明 创建Pod时,环境变量中的某一个Key拼写错误的问题会被集群忽略,如Command拼写为Commnd,您仍能够使用该YAML文件创建资源。但容器运行时,不会执行有拼写问题的YAML文件,而是执行镜像中的默认命令。在执行kubectl apply -f命令前为其添加--validate,然后执行kubectl apply --validate -f XXX.yaml 命令。如果您将command拼写成commnd,将看到错误信息XXX] unknown field: commnd XXX] this may be a false alarm, see https://gXXXb.XXX/6842pods/test。执行以下命令,将输出结果的pod.yaml文件与您创建Pod使用的文件进行对比。 kubectl get pods [$Pod] -o yaml > pod.yaml说明 [$Pod]为异常Pod的名称,您可以通过kubectl get pods命令查看。pod.yaml文件比您创建Pod所使用的文件多几行,说明已创建的Pod符合预期。如果您创建Pod所使用文件里的代码行在pod.yaml文件中没有,说明您创建Pod使用的文件存在拼写问题。查看Pod的日志,通过日志内容排查问题。具体操作,请参见检查Pod的日志。可通过终端进入容器查看容器内的本地文件是否符合预期。具体操作,请参见使用终端进入容器。Pod状态为Terminating问题原因 若Pod的状态为Terminating,说明此Pod正处于关闭状态。 问题现象 Pod状态为Terminating。 解决方案 Pod停留在Terminating状态一段时间后会被自动删除。若Pod一直停留在Terminating状态,可执行如下命令强制删除: kubectl delete pod [$Pod] -n [$namespace] --grace-period=0 --forcePod状态为Evicted问题原因 当节点的内存、磁盘空间、文件系统的inode和操作系统可分配的PID等资源中的一个或者多个达到特定的消耗水平,就会引发kubelet主动地驱逐节点上一个或者多个Pod,以回收节点资源。 问题现象 Pod的状态为Evicted。 解决方案 执行以下命令,查看Pod的status.message字段,来确定Pod被驱逐的原因。kubectl get pod [$Pod] -o yaml -n [$namespace]预期输出:status: message: 'Pod the node had condition: [DiskPressure].' phase: Failed reason: Evicted通过上述status.message字段,可以判断当前Pod是因为节点磁盘压力 (DiskPressure) 被驱逐。说明 注意这里仅以磁盘压力驱逐为例,其它例如内存压力(MemoryPressure)和PID压力(PIDPressure)等也会以类似的方式展示。执行以下命令,删除被驱逐的Pod。kubectl get pods -n [$namespace]| grep Evicted | awk '{print $1}' | xargs kubectl delete pod -n [$namespace]以下汇总如何避免Pod被驱逐的方法:内存压力:根据自身业务情况,调整Pod的资源配置。具体操作,请参见设置容器的CPU和内存资源上下限。为节点进行升配。具体操作,请参见升配Worker节点的资源。磁盘压力:定时清理节点上的业务Pod日志,避免磁盘被日志打满。为节点进行磁盘扩容。具体操作,请参见步骤一:扩容云盘容量。PID压力:根据自身业务情况,调整Pod的资源配置,具体操作,请参见进程ID约束与预留。Pod OOM异常问题处理问题原因当集群中的容器使用超过其限制的内存,容器可能会被终止,触发OOM(Out Of Memory)事件,导致容器异常退出。关于OOM事件,请参见为容器和Pod分配内存资源。 问题现象若被终止的进程为容器的阻塞进程,可能导致容器异常重启。若出现OOM异常问题,登录容器服务管理控制台,在Pod详情页面单击事件页签可看到OOM事件pod was OOM killed。具体操作,请参见检查Pod的事件。若集群配置了集群容器副本异常报警,则OOM事件出现时可收到相关报警。关于配置报警,请参见容器服务报警管理。解决方案查看发生OOM异常的Pod所在的节点。命令行方式查看:执行以下命令,查看容器信息。kubectl get pod [$Pod] -o wide -n [$namespace]预期输出: NAME READY STATUS RESTARTS AGE IP NODE pod_name 1/1 Running 0 25h 172.20.6.53 cn-hangzhou.192.168.0.198控制台方式查看:查看Pod详情下的节点信息,请参见检查Pod的详情。登录Pod所在的Node,查看内核日志/var/log/message。在日志中查询关键字out of memory,确认具体被OOM终止的进程。如果该进程是容器的阻塞进程,OOM终止后容器会重启。通过Pod内存监控查看内存增长曲线,确定异常出现时间。具体操作,请参见检查Pod的监控。 根据监控、内存增长时间点、日志、进程名等信息,排查Pod内对应进程是否存在内存泄漏。若OOM是进程内存泄漏导致,请您自行排查泄露原因。若进程运行状态正常,则根据实际运行需要,适当增大Pod的内存限制,建议Pod的内存实际使用量不超过内存限制值的80%。具体操作,请参见设置容器的CPU和内存资源上下限。 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |