Pod概念Pod是Kubernetes集群中部署和管理的最小基本单元，具有协同寻址和协同调度。Pod是一个或多个容器的集合，是一个或一组服务（进程）的抽象集合。Pod可以共享网络和存储（可以简单理解为逻辑虚拟机，但不是虚拟机）。Pod创建后，由一个UID唯一标识。当Pod生命周期结束并被等效的Pod替换时，将重新生成UID。Docker是KubernetesPod中最常用的容器运行时，但Pod也可以支持其他容器操作，例如rkt、podman等。Kubernetes集群中的Pod可以用于两个主要目的：运行单个容器的Pod。“每个Pod一个容器”模型是最常见的Kubernetes用例；在这种情况下，Pod可以被认为是单个容器的包装器，Kubernetes直接管理Pod，而不是容器。运行多个一起工作的容器的Pod。Pod可能封装一个应用程序，该应用程序由多个紧密耦合且需要共享资源的并置容器组成。这些位于同一位置的容器可以形成一个单一的内聚服务单元，其中一个容器从共享卷向公众提供文件，而一个单独的“衣架”容器刷新或更新这些文件。Pod将这些容器和存储资源打包成一个可管理的实体。PodController控制器可以为你创建和管理多个Pod，管理副本和rollout，并在集群范围内提供自我修复能力。例如，如果一个节点发生故障，控制器可以将相同的替代节点调度到不同的节点上，以自动替换Pod。包含一个或多个Pod的控制器的一些示例包括：Deploymentkubernetes中最常用的控制器，用于运行无状态应用程序StatefulSet用于运行有状态应用程序DaemonSet就像计算机中的守护进程一样，它可以运行集群“Daemon”存储、日志收集和监控等控制器通常使用您提供的Pod模板来创建它负责的Pod。Pod故障分类Pod状态始终处于PendingPod状态始终处于WaitingPod状态始终处于ContainerCreatingPod状态始终处于ContainerCreatingPod状态处于ImagePullBackOffPod状态处于CrashLoopBackOffPod状态处于ErrorPod状态始终处于TerminatingPod状态InUnknown以上为个人总结，不完整之处还请见谅！Pod故障排除命令kubectlgetpod-oyaml#检查Pod配置是否正确kubectldescribepod#查看Pod的详细事件信息kubectllogs[-c]#查看容器日志Pod故障及排查方法Pod一直处于Pending状态。这个状态表示Pod的YAML文件已经提交给Kubernetes，API对象已经创建并保存在Etcd中。但是这个Pod里面有些容器因为某些原因无法成功创建。比如调度不成功（可以使用kubectldescribepod命令查看当前Pod的事件，进而判断调度不成功的原因）。可能原因：资源不足（集群中所有Nodes不满足Pod请求的CPU、内存、GPU等资源）；HostPort已经被占用（通常建议使用Service对外开放服务端口）。Pod始终处于Waiting或ContainerCreating状态。首先，使用kubectldescribepod命令查看当前Pod的事件。可能的原因有：1、镜像拉取失败，例如镜像地址配置错误，国外镜像源（gcr.io）拉不出来，镜像私钥配置错误，镜像过大等导致pull超时时间（kubelet可以适当调整--image-pull-progress-deadline和--runtime-request-timeout选项）等2.CNI网络错误，一般需要检查CNI网络插件的配置-in，例如：无法配置Pod网络，无法分配IP地址。3、容器无法启动。您需要检查是否打包了正确的镜像，或者是否配置了正确的容器参数。4.创建podsandbox失败，查看kubelet日志，可能是磁盘坏了（输入/输出错误）。Pod一直停留在ImagePullBackOff状态一般是镜像名称配置错误或者镜像私钥配置错误导致的。这种情况可以使用dockerpull来验证是否可以正常拉取镜像。如果privateimagekey配置错误或没有配置，检查如下：1.查询docker-registry类型的Secret#查看docker-registrySecret$kubectlgetsecretsmy-secret-oyaml|grep'dockerconfigjson:'|awk'{打印$NF}'|base64-d2,CreateaSecretoftypedocker-registry#首先创建一个Secret类型为docker-registry$kubectlcreatesecretdocker-registrymy-secret--docker-server=DOCKER_REGISTRY_SERVER--docker-username=DOCKER_USER--docker-password=DOCKER_PASSWORD--docker-email=DOCKER_EMAIL#然后在Deployment中引用这个Secretspec:containers:-name:private-reg-containerimagePullSecrets:-name:my-secret```Pod一直处于CrashLoopBackOff状态CrashLoopBackOff的状态表明容器已启动，但异常退出。此时可以先查看容器的日志。通过命令kubectllogs和kubectllogs--previous可以找到一些容器退出的原因，比如：容器进程退出，健康检查退出失败，如果此时没有发现任何线索，也可以执行在容器中命令进一步查看退出原因（kubectlexeccassandra–cat/var/log/cassandra/system.log），如果还是没有线索，需要SSH登录Pod所在的Node，并检查Kubelet或Docker日志以进行进一步调查。处于Error状态的Pod通常意味着Pod在启动过程中发生了错误。常见原因包括：依赖的ConfigMap、Secret、PV不存在；请求的资源超过了管理员设置的限制，比如超过了LimitRange等；违反了集群的安全策略，比如违反了PodSecurityPolicy；容器没有操作集群的权限例如开启RBAC后，需要为ServiceAccount配置角色绑定；Pod处于Terminating或Unknown状态。从v1.5开始，Kubernetes不会因为Node断开连接而删除正在运行的Pod，而是将其标记为ItisinTerminating或Unknown状态。删除这些状态的Pod有以下三种方式：1.从集群中删除节点。使用公有云时，kube-controller-manager会在删除VM后自动删除对应的Node。在部署在物理机上的集群中，管理员需要手动删除Node（比如kubectldeletenode）。2.节点恢复正常。Kubelet会重新与kube-apiserver通信，确认这些Pod的预期状态，然后决定删除或继续运行这些Pod。用户强制删除。用户可以执行kubectldeletepodspod-name--grace-period=0--force来强制删除Pod。不建议使用这种方式，除非明确知道Pod确实处于停止状态（比如Node所在的VM或物理机已经关闭）。特别是对于StatefulSet管理的Pod，强行删除很容易导致脑裂或者数据丢失等问题。3.Pod行为异常。这里所说的异常行为是指Pod没有按预期执行，例如podSpec中设置的命令行参数没有运行。这一般是因为podSpecyaml文件的内容不正确。可以尝试使用--validate参数重建容器，例如：kubectldeletepodmypod和kubectlcreate--validate-fmypod.yaml，或者检查创建的podSpec是否正确。例如：kubectlgetpodmypod-oyaml，修改静态Pod的Manifest后，不会自动重建。Kubelet使用inotify机制检测/etc/kubernetes/manifests目录下的静态Pod（可以通过Kubelet的--pod-manifest-path选项指定），并在文件发生变化后重新创建相应的Pod。但是，有时修改静态Pod的Manifest后不会自动创建新的Pod。在这种情况下，一个简单的修复方法是重启Kubelet。Unknown这是一种异常状态，意思是Pod的状态无法通过kubelet持续的报告给kube-apiserver，这很可能是主从节点（MasterandKubelet）之间的通信问题。参考链接https://kubernetes.io/zh/docs...https://kubernetes.io/docs/ta...https://www.huweihuang.com/ku...https://blog。csdn.net/fanren2...https://zhuanlan.zhihu.com/p/...本文由YP发布！
