k8s运维故障排查总结
一.Pod相关问题及排查
1.Pod无法启动:
sh
1.使用 kubectl describe pod [pod_name] -n [namespace_name] 命令查看该 Pod的状态信息，检查容器的状态和事件信息，判断是否出现问题。
2.使用 kubectl logs [pod_name] -n [namespace_name] 命令查看该 Pod 容器的日志信息，判断是否有错误或异常信息。
3.使用 kubectl get events --field-selector involvedObject.name=[pod_name] -n [namespace_name] 查看 Pod事件信息，是否有异常事件发生。2.Pod无法连接其他服务
sh
1.使用 kubectl exec -it [pod_name] -n [namespace_name] -- /bin/bash 命令进入该 Pod所在的容器，尝试使用 ping或 telnet等命令测试与其他服务的网络连接 情况。
2.使用 kubectl describe pod [pod_name] -n [namespace_name] 命令检查 Pod的NetworkPolicy配置，判断是否阻止了该 Pod 访问其他服务。
3.使用 kubectl describe service [service_name] -n [namespace_name] 命令检查目标服务的配置和状态信息，判断是否存在故障3.Pod运行缓慢或异常
sh
1.使用 kubectl top pod [pod_name] -n [namespace_name] 命令查看该 Pod的 CPU 和内存使用情况，判断是否存在性能瓶颈。
2.使用 kubectl exec -it [pod_name] -n [namespace_name] -- /bin/bash 命令进入该 Pod 所在的容器，使用top或 htop 命令查看容器内部进程的 CPU 和内存使 用情况，找出可能存在的瓶颈。
3.使用 kubectl logs [pod_name] -n [namespace_name] 命令查看该 Pod 容器 的日志信息，寻找可能的错误或异常信息。4.Pod无法调度到节点上运行
sh
1.使用 kubectl describe pod [pod_name] -n [namespace_name] 命令查看 Pod 的调度情况，判断是否存在资源不足、调度策略等问题。
2.使用 kubectl get nodes 和 kubectl describe node [node_name] 命令查看所有节点的资源使用情况，判断是否存在节点资源不足或故障的情况。
3.使用 kubectl describe pod [pod_name] -n [namespace_name] 命令检查 Pod所需的标签和注释，以及节点的标签和注释，判断是否匹配。5.Pod状态一直pendding状态
sh
1.使用 kubectl get pods -n <namespace> 命令检查 Pod 的状态和事件，确定Pod处于何种状态以及是否有任何错误或警告信息。
2.检查 Pod 的资源清单（YAML 或 JSON），确保各项字段（如镜像名称、资源请求、端口等）配置正确。
3.如果 Pod 需要特定类型的节点（如 GPU 节点），确认集群中是否有符合条件的节点可用。
4.检查 Pod 所需的资源配额（如 CPU、内存）是否已经达到上限，可以使用 kubectl describe pod <pod-name> -n <namespace> 查看详细信息。
5.检查 Pod 所需的存储卷是否可用，确保没有引发挂载错误。
6.如果是调度问题，可以通过以下方式解决：
1.确保有足够的节点资源满足该 Pod 调度需求
2.检查该节点的 taints 和 tolerations 是否与 Pod 的 selector 匹配
3.调整 Pod 的调度策略，如使用 NodeSelector 、Affinity等。6.Pod无法访问外部服务
sh
1.查看 Pod 中的 DNS配置是否正确
2.检查 Pod 所在的命名空间中是否存在 Service 服务
3.确认该 Pod 是否具有网络访问权限
4.查看 Pod 所在的节点是否有对外的访问权限
5.检查网络策略是否阻止了 Pod 对外的访问7.Pod启动后立即退出
sh
1.查看该 Pod 的事件信息：kubectl describe pod <pod-name>
2.查看该 Pod 的日志：kubectl logs <pod-name>
3.检查容器镜像是否正确、环境变量是否正确、入口脚本是否正常
4.尝试在本地使用相同的镜像运行该容器，查看是否有报错信息，如执行 docker run image-name8.Pod启动后无法正确运行应用程序
sh
1.查看 Pod 中的应用程序日志：kubectl logs <pod-name>
2.查看该 Pod 的事件信息：kubectl describe pod <pod-name>
3.检查应用程序的配置文件是否正确
4.检查应用程序的依赖是否正常
5.尝试在本地使用相同的镜像运行该容器，查看是否有报错信息，如执行 docker run image-name
6.确认该应用程序是否与 Pod 的资源限制相符9.Pod内部服务或者网络连接问题
sh
1.使用 kubectl get pods -n <namespace> 命令检查 Pod的状态和事件，查看是否有任何错误或警告信息。
2.确认 Pod 所属的 Service是否已经创建，且与 Pod使用的端口和协议匹配。
3.检查 Pod 内部的 DNS配置，确保能够解析其他服务的域名。
4.使用 kubectl exec <pod-name> -n <namespace> -- <command> 命令进入Pod 内部，手动测试容器之间的网络连通性。10.Pod与存储卷之间的问题
sh
1.使用 kubectl get pods -n <namespace> 命令检查 Pod的状态和事件，查看是否有任何错误或警告信息。
2.确认存储卷是否已经正确地绑定到 Pod 上，可以使用 kubectl describe pod <pod-name> -n <namespace> 查看详细信息。
3.使用 kubectl exec <pod-name> -n <namespace> -- <command> 命令进入 Pod内部，手动测试存储卷是否能够正常挂载和访问。
4.检查存储卷提供程序（如 NFS 、AWS EBS）的配置是否正确，并确保其可用性。
5.确保存储卷访问模式（如 ReadWriteOnce 、ReadOnlyMany）与应用程序的要求相匹配。11.其中一个Pod显示状态为 0/1 Completed
sh
可能的原因：
1.容器启动失败
• 容器镜像可能无法正确拉取，或者镜像本身存在问题。
• 镜像拉取凭据可能有误或未正确配置。
• 容器的启动命令或参数可能有误
#解决：用kubectl logs <pod-name> 查看容器日志，以获取失败的详细信息。
2.资源限制：
• 节点上可能没有足够的资源（如CPU或内存）来启动容器。
• Pod可能因为资源不足而被调度器拒绝
#解决：确保镜像名称正确且镜像在仓库中可用。检查 imagePullSecrets 是否正确配置。
3. 配置错误：
• Pod定义中可能存在错误，例如端口映射不正确或环境变量设置有误。
• 安全上下文或命名空间配置可能不正确。
#解决：• 查看节点状态，确认是否有足够的资源可用。• 检查Pod的资源请求和限制是否合理。
4.网络问题：
• Pod可能无法访问所需的网络资源，或者网络策略限制了其通信。
• 服务发现或DNS解析问题也可能导致连接失败。
#解决：• 查看网络策略配置，确认它们没有阻止必要的通信。• 检查服务发现和DNS设置。
#其他解决：
• 检查 pod.yaml 文件中的配置，确保所有设置正确无误。• 验证端口、环境变量和其他配置项。
• 确保所有必需的服务和资源都已启动并运行。• 检查服务之间的依赖关系和通信路径。
• 如果节点资源不足，尝试手动将Pod调度到其他节点。• 使用 kubectl drain <node> 从节点上移除Pod。
• 使用 kubectl describe pod <pod-name> 查看事件，以获取更多关于失败的信息。二.Node相关问题及排查
1.Node状态异常
sh
1.使用 kubectl get nodes 命令查看集群中所有节点的状态和信息，判断是否存在故障。
2.使用 kubectl describe node [node_name] 命令查看目标节点的详细信息，包括 CPU、内存、磁盘等硬件资源的使用情况，判断是否存在性能瓶颈。
3.使用 kubectl get pods -o wide --all-namespaces 命令查看集群中所有 Pod的状态信息，判断是否有Pod运行在目标节点上导致资源紧张。2.Node上运行的Pod无法访问网络
sh
1.使用 kubectl describe node [node_name] 命令查看目标节点的信息，检查节点是否正常连接到网络。
2.使用 kubectl describe pod [pod_name] -n [namespace_name] 命令查看Pod所运行的节点信息，判断是否因为节点状态异常导致网络访问失败。
3.使用 kubectl logs [pod_name] -n [namespace_name] 命令查看 Pod容器的日志信息，寻找可能的错误或异常信息。3.Node上的Pod无法访问存储
sh
1.使用 kubectl describe pod [pod_name] -n [namespace_name] 命令检查 Pod的 volumes配置信息，判断是否存在存储挂载失败的情况。
2.使用 kubectl exec -it [pod_name] -n [namespace_name] -- /bin/bash 命令进入Pod所在的容器，尝试使用ls 和 cat等命令访问挂载的文件系统，判断是否存 在读写错误。
3.使用 kubectl describe persistentvolumeclaim [pvc_name] -n [namespace_name] 命令查看相关 PVC 配置和状态信息，判断是否存在故障。4.存储卷挂载失败
sh
1.使用 kubectl describe pod [pod_name] -n [namespace_name] 命令检查 Pod 的 volumes配置信息，判断是否存在存储卷定义错误。
2.使用 kubectl describe persistentvolumeclaim [pvc_name] -n [namespace_name] 命令检查PVC的状态和信息，判断是否存在存储配额不足或存储资源故障等原因。
3.如果是 NFS 或 Ceph 等网络存储，需要确认网络连接是否正常，以及存储服务器 的服务是否正常。5.Node节点加入集群后无法被调度
sh
1.检查该节点的 taints和 tolerations是否与 Pod的selector匹配
2.检查该节点的资源使用情况是否满足 Pod的调度要求
3.确保该节点与 Kubernetes API-server 的连接正常6.k8s集群中的PersistentVolume 挂载失败
sh
1.检查 PersistentVolume 和Pod之间的匹配关系是否正确
2.检查 PersistentVolumeClaim 中的storageClassName是否与 PersistentVolume的 storageClassName匹配
3.检查节点存储配置和 PersistentVolume的定义是否正确
4.自动供给层面的权限是否已经给到位三.集群层面问题及排查
1.集群中很多Pod运行缓慢
sh
1.使用 kubectl top pod -n [namespace_name]命令查看所有Pod的 CPU和内存 使用情况，判断是否存在资源瓶颈。
2.使用 kubectl get nodes 和 kubectl describe node [node_name] 命令查看所有节点的资源使用情况，判断是否存在单个节点资源紧张的情况。
3.使用 kubectl logs [pod_name] -n [namespace_name] 命令查看 Pod容器的日志信息，寻找可能的错误或异常信息。2.集群中某个服务不可用
sh
1.使用 kubectl get pods -n [namespace_name] 命令查看相关服务的所有 Pod的状态信息，判断是否存在故障。
2.使用 kubectl describe pod [pod_name] -n [namespace_name] 命令检查 Pod的网络连接和存储访问等问题，寻找故障原因。
3.使用 kubectl describe service [service_name] -n [namespace_name] 命令查看服务的配置和状态信息，判断是否存在故障。3.集群中的Node和Pod不平衡
sh
1.使用 kubectl get nodes 和 kubectl get pods -o wide --all-namespaces 命令查看所有Node和Pod的状态信息，判断是否存在分布不均的情况。
2.使用 kubectl top pod -n [namespace_name] 命令查看所有Pod的CPU和内存使用情况，判断是否存在资源瓶颈导致 Pod分布不均。
3.使用 kubectl describe pod [pod_name] -n [namespace_name] 命令查看 Pod 所运行的节点信息，并使用 kubectl describe node [node_name] 命令查看相关节点的状态信息，判断是否存在节点不平衡的情况。
4.使用 kubectl describe pod / node [node_name] 查看当前Pod/Node上是否有相关的亲和或反亲和策略导致固定调度。4.集群中的某个节点宕机
sh
1.使用 kubectl get nodes 命令检查节点状态，找到异常节点。
2.使用 kubectl drain [node_name] --ignore-daemonsets 命令将节点上的 Pod 驱逐出去，并将其部署到其他节点上。添加 --ignore-daemonsets 参数可以忽略DaemonSet 资源。
3.如果需要对节点进行维护或替换硬件：
1.先将节点设置为不可以调度 kubectl cordon [node_name]
2.再通过 kubectldrain [node_name] --ignore-daemonsets 命令将节点上的Pod 驱逐出去，并将其部署到其他节点上。
3.然后再次 kubectl delete node [node_name] 安全的进行节点下线。5.集群中的API---Server不可用
sh
1.使用 kubectl cluster-info 命令查看集群状态，判断是否存在 API-Server不可用的情况。
2.使用 kubectl version 命令查看集群版本，确认 Kubernetes API-Server 和 kubelet 版本是否匹配。
3.使用 systemctl status kube-apiserver 命令检查 API-Server 运行状态，确认是 否存在故障或错误。
4.结合 apiServer 所在的节点查看系统层面的日志，进一步定位问题点。6.Kubernetes 命令执行失败
sh
1.检查 Kubernetes API-Server 是否可用：kubectl cluster-info
2.检查当前用户对集群的权限是否足够：kubectlauth can-i <verb> <resource>
3.检查 kubeconfig文件中的登录信息是否正确：kubectl config view7.Kubernetes master 节点不可用
sh
1.检查 kube-apiserver 、kube-scheduler 、kube-controller-manager 是否都在运行状态
2.检查 etcd 存储系统是否可用
3.尝试重新启动 master 节点上的 kubelet和容器运行时8.Kubernetes 集群绕过了 LoadBalancer，直接访问 Pod
sh
1.检查 Service 和 Pod 的通信是否使用了 ClusterIP类型的 Service
2.确认该 Service 的 selector是否匹配到了正确的 Pod9.Kubernetes 集群中的 Deployment 自动更新失败
sh
1.检查更新策略是否设置正确，如rollingUpdate 或 recreate
2.检查 Kubernetes API-Server 和 kubelet 之间的连接是否正常
3.检查 Pod 的定义是否正确10.Kubernetes 集群中的状态检查错误
sh
1.检查节点日志和事件信息，并确认错误类型
2.确认该状态检查是否与 kubelet 的版本兼容
3.尝试升级 kubelet 和容器运行时等组件11.Kubernetes 集群中的授权配置有误
sh
1.检查 RoleBinding 和 ClusterRoleBinding 定义是否正确
2.检查用户或服务账号所绑定的角色是否正确
3.检查 kubeconfig 文件中的用户和访问权限是否正确12.Kubernetes 集群无法连接 etcd 存储系统
sh
1.检查 etcd 存储系统是否正常运行
2.检查 kube-apiserver 配置文件中 etcd 的连接信息是否正确
3.尝试手动连接 etcd 集群，如执行 etcdctl cluster-health13.K8S集群服务访问失败？
sh
原因：证书不能被识别，其原因为：自定义证书，过期等。
解决方法：更新证书即可。14.K8S集群服务访问失败？
sh
原因分析：端口映射错误，服务正常工作，但不能提供服务。
解决方法：删除svc，重新映射端口即可。15.K8S集群服务暴露失败？
sh
原因分析：该容器已暴露服务了。
解决方法：删除svc，重新映射端口即可。16.外网无法访问K8S集群提供的服务？
sh
原因分析：K8S集群的type为ClusterIP，未将服务暴露至外网。
解决方法：修改K8S集群的type为NodePort即可，于是可通过所有K8S集群节点访问服务。
kubectl edit svc nginx-deployment17.pod状态为ErrImagePull？
sh
kubectl logs readiness-httpget-pod
原因分析：image无法拉取；
解决方法：更换镜像即可。18.创建init C容器后，其状态不正常？
sh
原因分析：查看日志发现，pod一直出于初始化中；然后查看pod详细信息，定位pod创建失败的原因为：初始化容器未执行完毕。
解决方法：创建相关service，将SVC的name写入K8S集群的coreDNS服务器中，于是coreDNS就能对POD的initC容器执行过程中的域名解析了。19.探测存活pod状态为CrashLoopBackOff？
sh
原因分析：镜像问题，导致容器重启失败。
解决方法：更换镜像即可。20.POD创建失败？
sh
原因分析：镜像问题导致容器无法启动
解决方法：更换镜像。21.POD的ready状态未进入？
sh
原因分析：POD的执行命令失败，无法获取资源。
sh
解决方法：进入容器内部，创建yaml定义的资源22.kube-flannel-ds-amd64-ndsf7插件pod的status为Init:0/1？
sh
排查思路：kubectl -n kube-system describe pod kube-flannel-ds-amd64-ndsf7 #查询pod描述信息；
sh
原因分析：k8s-slave1节点拉取镜像失败。
解决方法：登录k8s-slave1，重启docker服务，手动拉取镜像。k8s-master节点，重新安装插件即可。23.K8S创建服务status为ErrImagePull？
sh
排查思路：
kubectl describe pod test-nginx
原因分析：拉取镜像名称问题。
解决方法：删除错误pod；重新拉取镜像；24.不能进入指定容器内部？
sh
原因分析：yml文件comtainers字段重复，导致该pod没有该容器。
解决方法：去掉yml文件中多余的containers字段，重新生成pod。25.创建PV失败？
sh
原因分析：pv的name字段重复。解决方法：修改pv的name字段即可26.pod无法挂载PVC？
sh
原因分析：pod无法挂载PVC
sh
accessModes与可使用的PV不一致，导致无法挂载PVC，由于只能挂载大于1G且accessModes为RWO的PV，故只能成功创建1个pod，第2个pod一致pending，按序创建时则第3个pod一直未被创建；
解决方法：修改yml文件中accessModes或PV的accessModes即可。27.pod使用PV后，无法访问其内容？
sh
原因分析：nfs卷中没有文件或权限不对。
sh
解决方法：在nfs卷中创建文件并授予权限。28.查看节点状态失败？
sh
Error from server (NotFound): the server could not find the requested resource (get services http:heapster:)
原因分析：没有heapster服务。
解决方法：安装promethus监控组件即可。29.helm安装组件失败？
sh
[root@k8s-master01 hello-world]# helm install
Error: This command needs 1 argument: chart nam
[root@k8s-master01 hello-world]# helm install ./
Error: no Chart.yaml exists in directory "/root/hello-world"
原因分析：文件名格式不对。
解决方法：mv chart.yaml Chart.yaml四.Pod常见状态异常及排查
sh
一般来说，无论 Pod 处于什么异常状态，都可以执行以下命令来查看 Pod的状态：
$ kubectl get pod <pod-name> -o yaml 查看 Pod 的配置是否正确
$ kubectl describe pod <pod-name> -n 命名空间 查看 Pod 的事件
$ kubectl logs <pod-name> [-c <container-name>] 查看容器日志如上这 些事件和日志通常都会有助于排查 Pod 发生的问题。1.一直处于 Pending 状态
sh
1.Pending 说明 Pod 还没有调度到某个 Node上面。可以通过 kubectl describe pod <pod-name> 命令查看到当前 Pod的事件，进而判断为什么没有调度。可能的原因包括：
1.资源不足，集群内所有的 Node 都不满足该 Pod请求的 CPU、内存、GPU 等资源；
2.HostPort 已被占用，通常推荐使用 Service对外开放服务端口；2.一直处于 Waiting 或 ContainerCreating 状态
sh
首先还是通过命令查看到当前 Pod 的事件。可能的原因包括：
1.镜像拉取失败，比如：
配置了错误的镜像；
Kubelet 无法访问镜像（国内环境访问 gcr.io 需要特殊处理）；
私有镜像的密钥配置错误；
镜像太大，拉取超时（可以适当调整 kubelet 的 --image-pull-progress- deadline 和 --runtime-request-timeout 选项）；
2.CNI 网络错误，一般需要检查 CNI 网络插件的配置，比如
无法配置 Pod 网络;
无法分配 IP 地址;
3.容器无法启动，需要检查是否打包了正确的镜像或者是否配置了正确的容器参数；3.处于 ImagePullBackOff 状态
sh
这通常是镜像名称配置错误或者私有镜像的密钥配置错误导致。这种情况可以使用 docker pull <image> 来验证镜像是否可以正常拉取。如果是私有镜像，需要首先创建一个 docker-registry 类型的 Secret
docker-email=DOCKER_EMAIL 然后在容器中引用这个 Secret：
spec:
containers:
imagePullSecrets:
- name: my-secret4.Pod一直处于 CrashLoopBackOff 状态
sh
CrashLoopBackOff状态说明容器曾经启动了，但又异常退出了。此时可以先查看一下容器的日志
$ kubectl logs <pod-name>
$ kubectl logs --previous <pod-name>这里可以发现一些容器退出的原因，比如：
容器进程退出；
健康检查失败退出;
此时如果还未发现线索，还可以到容器内执行命令来进一步查看退出原因,那就需要 SSH 登录该 Pod 所在的 Node上，查看 Kubelet 或者 Docker 的日志进一步 排查了,查询 pod 在哪台 Node：
$ kubectl get pod <pod-name> -o wide5.Pod处于Error状态
sh
通常处于 Error 状态说明 Pod 启动过程中发生了错误。常见的原因包括：
依赖的 ConfigMap 、Secret 或者 PV 等不存在；
请求的资源超过了管理员设置的限制，比如超过了 LimitRange等；
违反集群的安全策略，比如违反了 PodSecurityPolicy等；
容器无权操作集群内的资源，比如开启 RBAC 后，需要为 ServiceAccount 配置角色绑定；6.Pod处于 Terminating 或 Unknown 状态
sh
Kubernetes 不会因为 Node 失联而删除其上正在运行的 Pod，而是将其标记为 Terminating 或 Unknown 状态。想要删除这些状态的 Pod 有三种方法：
1.从集群中删除该 Node。使用公有云时，kube-controller-manager 会在 VM 删除后 自动删除对应的 Node。而在物理机部署的集群中，需要管理员手动删除 Node（如kubectl delete node <node-name>。
2.Node 恢复正常。Kubelet 会重新跟 kube-apiserver 通信确认这些 Pod 的期待状态， 进而再决定删除或者继续运行这些 Pod。
3.用户强制删除。用户可以执行 kubectl delete pods <pod> --grace-period=0 -- force 强制删除 Pod。除非明确知道 Pod 的确处于停止状态（比如 Node 所在 VM 或 物理机已经关机），否则不建议使用该方法。特别是 StatefulSet 管理的 Pod，强制删除 容易导致脑裂或者数据丢失等问题。五.kubernetes故障排查-分析容器退出状态码
1.Pod status状态解释
sh
CrashLoopBackOff：容器退出，kubelet 正在将它重启
InvalidImageName：无法解析镜像名称
ImageInspectError：无法校验镜像
ErrImageNeverPull：策略禁止拉取镜像
ImagePullBackOff：镜像正在重试拉取
RegistryUnavailable：连接不到镜像中心
ErrImagePull：通用的拉取镜像出错
CreateContainerConfigError：不能创建 kubelet 使用的容器配置
CreateContainerError： 创建容器失败
m.internalLifecycle.PreStartContainer：执行 hook 报错
RunContainerError：启动容器失败
PostStartHookError：执行 hook 报错
ContainersNotInitialized：容器没有初始化完毕
ContainersNotReady：容器没有准备完毕
ContainerCreating：容器创建中
PodInitializing ：pod 初始化中
DockerDaemonNotReady：docker 还没有完全启动
NetworkPluginNotReady：网络插件还没有完全启动
1.ImagePullBackOff
问题原因:
镜像拉取失败。
可能原因：
1.可能是网络问题导致，检查Pod所在节点是否能够正常访问网络;
2.镜像名称写错，也可能会导致这个错误;
3.镜像是私有仓库，镜像无权限拉取;
2.ContainerCreating
问题分析:
容器正在创建阶段，等待容器创建，该过程包含拉取镜像的时间。
3.Pending
问题分析:
任务已经被K8S集群接受，但是未调度到指定节点。
可能原因:
1.当前集群不正常工作，请检查集群状态，比如CNI组件未安装;
2.指定的调度的节点不存在时也会出现这样的问题;
3.端口冲突，无法完成调度;
4.所有节点都被打上污点，且pod没有配置污点容忍也会导致该状态;
4.CrashLoopBackOff
问题分析:
处于该状态，说明Pod内至少有一个容器正在重启。
可能原因:
1.可能是容器的守护进程运行命令结束导致的;
5.Completed
问题分析:
容器正常退出，容器没有被强制中断。
6.Running
问题分析:
至少有一个容器处于正常运行状态。
7.Init:1/2
问题分析:
当前的Pod处于初始化容器阶段，目前已经完成一个初始化容器，正在进行第二个容器初始化。
8.PodInitializing
问题分析:
Pod正处于初始化阶段。
9.ErrImageNeverPull
问题分析:
将镜像下载策略设置为Never，且本地也没有缓存镜像，因此启动容器失败。
10.OutOfcpu
问题分析:
一般情况下是由于CPU资源不足导致的。
11.OutOfmemory
问题分析:
一般情况下是由于内存不足无法分配导致的。
12.NodePorts
问题分析:
当前的worker节点的端口可能存在冲突。
13.RunContainerError
问题分析:
运行容器时出错，可以通过kubectl describe pods <POD_NAME>查看详细的信息。
14.ErrImagePull
问题分析:
拉取镜像是失败。
可能原因:
1.镜像名称写错了;
2.没有访问权限;
15.Terminating
问题分析:
Pod的容器正在删除，此过程可能需要等待一段时间，一般情况下不会超过60s。2.容器Exit Code
sh
1.容器退出状态码的区间
必须在 0-255 之间
0 表示正常退出
外界中断将程序退出的时候状态码区间在 129-255 ，(操作系统给程序发送中断信号，比如 kill -9 是 SIGKILL ，Ctrl+c 是 SIGINT)
一般程序自身原因导致的异常退出状态区间在 1-128 (这只是一般约定，程序如果 一定要用 129-255 的状态码也是可以的)注意：有时我们会看到代码中有 exit(-1)，这时 会自动做一个转换，最终输出的结果还是会在 0-255 之间。转换公式如下，code 表现退出的状态码：
当指定的退出时状态码为负数，转换公式如下：
256 - (|code| % 256)当指定的退出时状态码为正数，转换公式如下：
code % 2563.常见的容器退出状态码解释
sh
EXIT CODE 0
退出代码 0 表示特定容器没有附加前台进程
该退出代码是所有其他后续退出代码的例外
如果开发人员想要在容器完成其工作后自动停止其容器，则使用此退出代码。比如：kubernetes job 在执行完任务后正常退出码为 0
EXIT CODE 1
程序错误，或者 Dockerfile 中引用不存在的文件，如 entrypoint 中引用了错误的包
程序错误可以很简单，例如 "除以0"，也可以很复杂，比如空引用或者其他程序 crash
EXIT CODE 137
表明容器收到了 SIGKILL 信号，进程被杀掉，对应 kill -9
引发 SIGKILL 的是 docker kill。这可以由用户或由 docker 守护程序来发起，手动 执行：docker kill
137 比较常见，如果 pod 中的 limit 资源设置较小，会运行内存不足导致OOMKilled，此时 state 中的 "OOMKilled" 值为 true，你可以在系统的 dmesg -T 中看到 oom 日志
EXIT CODE 139
表明容器收到了 SIGSEGV 信号，无效的内存引用，对应 kill -11
一般是代码有问题，或者 docker 的基础镜像有问题
EXIT CODE 143
表明容器收到了 SIGTERM 信号，终端关闭，对应 kill -15
一般对应 docker stop 命令
有时 docker stop 也会导致 Exit Code 137。发生在与代码无法处理 SIGTERM 的情况下，docker 进程等待十秒钟然后发出 SIGKILL 强制退出。
不常用的一些 EXIT CODE
Exit Code 126: 权限问题或命令不可执行
Exit Code 127: Shell 脚本中可能出现错字且字符无法识别的情况
Exit Code 1 或 255：因为很多程序员写异常退出时习惯用 exit(1) 或 exit(-1) ，-1
会根据转换规则转成 255。这个一般是自定义 code，要看具体逻辑。用或者其他程序 crash
EXIT CODE 137
表明容器收到了 SIGKILL 信号，进程被杀掉，对应 kill -9
引发 SIGKILL 的是 docker kill。这可以由用户或由 docker 守护程序来发起，手动 执行：docker kill
137 比较常见，如果 pod 中的 limit 资源设置较小，会运行内存不足导致OOMKilled，此时 state 中的 "OOMKilled" 值为 true，你可以在系统的 dmesg -T 中看到 oom 日志
EXIT CODE 139
表明容器收到了 SIGSEGV 信号，无效的内存引用，对应 kill -11
一般是代码有问题，或者 docker 的基础镜像有问题
EXIT CODE 143
表明容器收到了 SIGTERM 信号，终端关闭，对应 kill -15
一般对应 docker stop 命令
有时 docker stop 也会导致 Exit Code 137。发生在与代码无法处理 SIGTERM 的情况下，docker 进程等待十秒钟然后发出 SIGKILL 强制退出。
不常用的一些 EXIT CODE
Exit Code 126: 权限问题或命令不可执行
Exit Code 127: Shell 脚本中可能出现错字且字符无法识别的情况
Exit Code 1 或 255：因为很多程序员写异常退出时习惯用 exit(1) 或 exit(-1) ，-1
会根据转换规则转成 255。这个一般是自定义 code，要看具体逻辑。