k8spod进程关系，k8spod状态详解

k8s在创建Pod时先创建pause容器,还是先与cni交互执行网络

总结，Kubernetes在创建pod时，先启动pause容器以创建命名空间，然后POD中的其他容器共享这个命名空间，实现进程间的隔离和独立封装。通过pause容器的命名空间机制，确保了容器之间的资源隔离和通信隔离，有效管理了容器在集群中的运行。

接下来是init容器。它们在Pod中的其他容器启动之前开始执行，并执行初始化逻辑，如创建用户账户、执行数据库迁移或创建数据库结构。在创建init容器时，需要考虑资源和限制的优先级分配，因为init容器总是先于其他应用程序容器启动。调度程序将为init容器分配更高的资源优先级，因此在定义这些参数时应保持严格。

在部署不使用CRI-O的k8s集群，采用kube-ovn网络插件时，需要进行一系列的准备工作和配置。首先，确保加载必要的内核模块并安装ipvsadm。接着，更新yum源，安装Go语言环境，为cri-o的安装做准备。安装cri-o时，从源码包下载并生成默认配置。随后，安装conmon，同样是从源码获取并安装。

Calico+macvlan双网络为实现Calico+macvlan双网络配置，必须创建一个辅助网络，专门用于macvlan。配置时需避免将默认路由设置为macvlan网络，以避免路由冲突。确保`vmultus-cni.io/defaul...`注解设置为`net-calico-2`，而`k8s.vcni.cncf.io/netw...`注解设置为`net-macvlan`。

然而，CNI网桥仅管理k8s创建的容器（Pod），对于通过docker run单独启动的容器，docker仍然会将其连接到docker0网桥上，因此这些容器的IP地址将属于docker0的170/16网段。相比之下，在calico网络环境中，无论是IPIP还是BGP模式，cni0网桥并不适用，网桥设备主要还是docker0。

pkg/kubelet/kubelet.go -- HandlePodAdditions方法 Pod创建首先来看看 HandlePodAdditions 函数。

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

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

POD的生命周期与重启策略是K8s中的关键概念，理解它们对于确保应用程序稳定运行至关重要。

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

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

容器在其生命周期内也有Waiting、Running和Terminated等状态，以及针对不同状态的具体原因（Reason）描述。例如，容器状态为Terminated且原因CrashLoopBackoff，表示容器由于某种异常退出后，系统试图重启容器。

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服务重启后容器仍无法创建的情况。解决这类问题，通常需要检查服务的运行状态，确认资源是否充足，或者是否存在网络、存储配置问题。

K8S线上集群排查,实测排查Node节点NotReady异常状态

1、K8S线上集群Node节点NotReady异常状态的排查方法主要包括以下几点：检查硬件资源：使用df m命令检查磁盘空间，确保有足够的空间供Node节点和Pod使用。使用free命令检查CPU使用率，确保CPU资源未被过度占用。使用top c命令查看CPU使用情况，确保无异常。

2、在项目中遇到的线上集群问题，特别是Kubernetes （K8S）集群中Node节点状态变为NotReady，导致服务停止的问题，我们进行了一次深入的排查与解决。文章将聚焦于如何有效识别和解决这类问题。首先，让我们了解一下在K8S中Pod的状态。

3、在搭建Kubernetes（k8s）集群过程中，若遇到节点一直处于NotReady状态问题，通过执行命令查看日志，发现提示信息为[failed to find plugin flAnnel in path [/opt/cni/bin]]。执行排查步骤，进入指定目录检查，确认flannel插件是否缺失。

4、一次K8S集群中遇到的Too Many Open Files问题排查，起因是一个运行机器学习推理服务的节点出现Node NotReady异常，通过查看日志发现是因为dockerd进程打开的文件数过多导致。初步怀疑是由于root用户文件限制较小，将限制调整为655360后重启docker进程，但问题并未解决，而是陆续在其他节点上重复出现。

5、Kubernetes 13 OS： CentOS 2009 Kernel： 94-elelrepo.x86_64 Docker： 6 线上告警提示集群中存在 2-3 个 K8s 节点处于 NotReady 的状态，并且 NotReady 状态一直持续。问题的解决可以通过两种方法，我们先来看看 A 方案。

6、Pod的异常场景主要分为两类，根据Pod容器是否运行。以下是详细的13种场景分析。调度失败 常见错误状态：Unschedulable Pod被创建后进入调度阶段，K8s调度器依据Pod资源需求和调度规则为Pod选择节点。当集群节点无法满足Pod需求时，Pod将处于Pending状态。