k8spod启动慢（k8s pod启动过程）

K8S故障检查-Pod处于ContainerCreating状态

1、常见导致POD长时间处于“ContainerCreating”状态的原因包括镜像拉取问题、资源不足、持久卷问题、网络问题以及安全上下文或Docker/运行时问题。要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“FaiLED to pull image”或“ImagePullBackoff”事件，表明镜像拉取存在问题。

2、面对k8s应用卡在ContainerCreating状态的困扰，我通过kubectl describe po命令获取到了关键的日志信息。

3、ContainerCreating：这种情况表示容器正在创建中，常见于配置问题导致的容器创建失败。例如，当使用docker服务时，可能会遇到节点上的kube-proxy、kubelet或docker服务重启后容器仍无法创建的情况。解决这类问题，通常需要检查服务的运行状态，确认资源是否充足，或者是否存在网络、存储配置问题。

4、一个pod的完整创建，通常会伴随着各种事件的产生，k8s种事件的种类总共只有4种：Podstatus 有一组PodConditions。PodCondition中的ConditionStatus，它代表了当前pod是否处于某一个阶段（PodScheduled，Ready，Initialized，Unschedulable），“true” 表示处于，“false”表示不处于。

5、如果创建Pod时状态为ContainerCreating，检查是否需要升级runc版本并重新配置源后重新安装。初始化集群时出现错误，检查crio.conf配置文件，确保配置正确。遇到fs.may_detach_mounts相关错误，调整sysctl配置并重启相关服务。安装与配置kubeovn：修改install.sh脚本以适应集群环境。

6、在集群部署过程中，可能会遇到问题。例如，如果创建pod时状态为containercreating，检查是否需要升级runc版本并配置源，然后重新安装。初始化集群时出现错误，可能需要编辑crio.conf来解决。另外，遇到fs.may_detach_mounts相关错误，可能是sysctl配置问题，需要调整相关设置后重启CRIO服务。

K8s中Pod生命周期和重启策略

1、K8s中Pod生命周期包括五种状态，重启策略有三种。Pod生命周期状态： Pending：API server已创建Pod，但容器镜像尚未运行。 Running：Pod中的所有容器都在运行中或正在启动中。 Succeeded：Pod中的所有容器已成功退出，并且不会重启。 Failed：Pod中的所有容器都已退出，且至少有一个容器是异常退出的。

2、Always策略：无论正常或非正常停止，容器均会重启。例如，正常关闭tomcat服务后，Pod状态恢复正常，而非正常关闭时，容器会重启。Never策略：正常或非正常停止，容器都不会重启。停止Tomcat后，正常情况下容器状态保持，非正常时显示Error状态。

3、重启策略有三种：Always、OnFailure和Never。如果设置为Always，那么无论因为什么原因停止，Pod都会自动重启。如果设置为OnFailure，则只有Pod非正常停止时（例如，因为崩溃或被杀死）才会重启。如果设置为Never，则Pod在任何情况下都不会自动重启。

4、重启Pod：通常是由Pod内部的故障或错误触发的。当Pod中的容器因为某些原因（如程序崩溃、资源不足等）异常退出时，K8s会根据预设的重启策略（restartPolicy）来决定是否重启该Pod。这里的重启策略包括Always（总是重启容器）、OnFailure（当容器异常退出时重启容器）和Never（从不重启容器）^[1][2]^。

5、在Pod层面配置共享Volume，允许所有容器访问，保留持久数据，即使容器重启。容器间共享IP与端口空间，通过localhost相互发现。多容器Pod示例展示了共处容器与资源的打包管理，以及容器间通信与协调。Pod中设置重启策略，如Always，降低应用中断时间，适用于所有容器。

搭建一个k8s单机版,yaml已经创建好,但pod状态一直处于pEnd

1、资源不足：原因：如果集群中的资源不足，Pod可能无法被调度到任何节点上，从而处于Pending状态。解决方法：检查集群的资源使用情况，确保有足够的资源可供Pod使用。可以考虑增加节点或调整Pod的资源请求和限制。调度问题：原因：调度器可能由于某些原因无法找到合适的节点来部署Pod。

2、假设一位机器学习研究人员想要在PyTorch环境中使用基于python的GPU进行测试，她请求她的工程团队提供一个带有两个GPU的Jupyter笔记本，以及她所有的库。然而，工程团队告诉她这需要三天时间，包括获取GPU、创建堆栈以及授予对JupyterHub的访问权限。

3、编写YAML资源清单：首先，需要编写一个YAML文件，定义Pod的配置信息，包括容器镜像、资源限制、环境变量、存储卷等。使用kubectl APPly命令创建：通过kubectl命令行工具，使用apply命令将YAML文件应用到kubernetes集群中，Kubernetes会根据定义创建Pod。

4、当创建Pod时，该Pod保持Pending状态。

k8s中Pod状态及问题排查方法

1、含义：调度器未能将 Pod 调度到可用节点。可能原因：节点资源不足或 Pod 依赖的资源未准备好。排查方法：检查节点资源使用情况及资源预留情况，确保集群有足够的 cpu 和其他资源。CrashLoopBackOff 状态：含义：容器在启动后立即崩溃或退出。可能原因：容器配置错误、应用程序错误、内存不足或权限问题。

2、解决方法：仔细检查Pod的YAML配置文件，确保语法正确且配置合理。可以使用kubectl describe pod 命令查看Pod的详细信息，以获取更多关于错误的信息。总结：Pod状态一直处于Pending通常是由于资源不足、调度问题、镜像拉取问题、权限问题或配置错误等原因导致的。

3、如果原因是Pod无法安装请求的卷，请确保清单适当地指定其详细信息并确保Pod可以访问存储卷。或者，如果该节点没有足够的资源，则手动从该节点删除Pod，以便将Pod调度到另一个节点上。否则，可以扩展节点资源容量。如果使用nodeSelector安排Pod在Kubernetes集群中的特定节点上运行，就会发生这种情况。

4、要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。资源不足时，使用kubectl describe Node命令检查节点资源状态。检查持久卷（PVC）状态，确保其STATUS为“Bound”，表明存储供应无问题。

5、调度问题是最常见的原因。如果节点没有足够的资源满足 Pod 的请求（包括有效请求和实际使用的资源），或者节点处于不可调度状态，如因压力或人为原因被封锁，Pod 将被挂起。查看调度事件可以帮助我们理解问题所在，如使用 `kubectl describe pod` 查看详细信息。

重启虚机后,k8s的kube-apiserver无法正常启动的问题

在重启设备后，执行 systemctl status kube-apiserver 命令时，未发现该服务，表明配置文件可能存在错误，因此决定对K8S集群进行重构。在master端检查pod时，发现flannel和coredns未启动，容器启动失败。

这通常是由于配置文件出错或者服务未正确安装和启动。此时，需要检查并重新安装和启动kube-apiserver服务，确保服务正常运行并监听在正确的端口上。综上所述，针对K8s的apiserver无法启动的问题，需要根据具体的错误信息和日志进行排查和解决。如果问题依然存在，建议查阅K8s的官方文档或寻求社区的帮助。

kube-apiserver报错，错误如下：这个错误指明了是与apiserver通信时认证失败造成的，接着就去找哪个组件报错说无法获取apiserver的资源，但是查了kube-controller-manager、kube-scheduler、kube-proxy和kubelet都没有找到相关的错误。

ImagePullBackOffKubernetes Pod启动失败原因之一是运行时无法从注册表中检索容器镜像。这种情况意味着Pod不会启动，因为清单中至少有一个容器无法启动。当Pod遇到此问题时，kubectl get pods命令将显示Pod状态为ImagePullBackOff。镜像名称或标签输入错误时，可能会发生此错误。