Kubernetes中Pod从Initialized到Ready阶段执行什么操作？如何排查延迟？

1. 排除镜像拉取后，剩余耗时的常见产生环节 #

• K8s编排预处理环节：包含Secret/ConfigMap挂载、存储卷（PVC/临时卷）挂载、安全规则（SELinux/AppArmor、SecurityContext）配置等操作，如果用到网络存储，挂载耗时波动会非常明显，最高可能达到十几秒。
• 初始化容器执行环节：如果Pod配置了init容器，必须等所有init容器全部执行完成才会启动主容器，init容器的执行耗时会全部算在这个阶段内。
• 主容器启动与应用初始化环节：容器创建完成后，主进程启动到实际对外可用的耗时完全由镜像内的应用逻辑决定，比如加载配置、建立远程连接、缓存预热等操作，很多业务应用本身的初始化耗时就可达几十秒。
• 健康检查等待环节：如果配置了启动探针（startupProbe）或就绪探针（readinessProbe），kubelet需要等到探针连续返回成功后才会将Pod标记为Ready，探针的初始延迟、探测间隔配置不合理的话，就算应用早已启动完成，也会额外增加等待时间，这是最常见的耗时波动原因。
• 节点资源争抢环节：如果Pod调度的节点同时有多个Pod在启动，CPU、内存、磁盘IO资源不足时，容器启动、应用初始化的进程会被系统限流，耗时会出现无规律波动。

2. 精准追踪阶段内执行流程的方法 #

• 获取带精确时间戳的Pod事件：不要使用默认的k get event输出，执行如下命令即可查看对应Pod的全量事件与毫秒级时间戳：

kubectl get event -o custom-columns=LAST_TIMESTAMP:.lastTimestamp,REASON:.reason,MESSAGE:.message --field-selector involvedObject.name=<替换为你的Pod名称>

• 查看节点kubelet日志：登录Pod调度到的工作节点，查看对应时间段的kubelet日志，kubelet会记录Pod生命周期每个操作的精确时间，包括存储挂载、容器创建、探针执行的全流程耗时。
• 查看容器运行时日志：如果使用Docker作为运行时，查看对应时间段的dockerd日志；如果使用containerd，查看containerd日志，可以明确区分是K8s编排层的耗时，还是容器创建启动环节的耗时。
• 应用侧埋点排查：在镜像的启动脚本或应用代码中增加各初始化阶段的时间打印，明确应用本身从启动到对外可用的实际耗时，直接和Pod的阶段耗时做对比。

3. 延迟归属判断方法 #

• 排除探针配置导致的等待耗时后，在对应节点本地直接用docker run启动同一镜像，统计从容器启动到应用对外可用的耗时，如果和K8s中Initialized到Ready的耗时基本一致，说明延迟是镜像/应用本身导致的。
• 如果本地启动耗时远低于K8s中的耗时，说明延迟由K8s侧导致，优先排查存储挂载、节点资源、安全规则配置这几个点。

内容的提问来源于stack exchange，提问作者Christophe Blin