Pod生命周期（二）：探针机制与Init容器特性及实验验证
一、探针机制补充：启动探测（Startup Probe）
背景与问题
Kubernetes 1.16版本之前仅存在存活性（Liveness Probe）与就绪性（Readiness Probe）两类探针，若存活性探测配置的时间点过早，会出现应用容器还未启动完成就被探测判定为不存活、被杀死重建的循环Bug，最终导致Pod进入BackOff不可用状态。
启动探测核心规则
-
触发时间范围：从容器创建时即开始探测，到应用启动完成时结束。
-
执行优先级：启动探测成功之前，就绪探测与存活性探测默认不会执行，避免提前探测未启动完成的应用。
-
核心作用：确认应用程序是否已经启动完成，为后续两类探测提供生效前提。
三类探针定位总结
-
启动探测：确认「你启动了吗？」
-
就绪探测：确认「你准备好了吗？」
-
存活性探测：确认「你还活着吗？」
探针通用规则
-
所有探针均由节点上的
kubelet执行，而非API Server。 -
探针为可选配置，默认值为空：不配置就绪探测则Pod默认就绪，不配置存活性探测则无存活检测机制，不配置启动探测则无启动状态校验。
-
探针机制支持为不同容器单独配置，也可按需选择部分启用。
二、Init容器的核心特性
Init容器是Pod启动阶段运行的临时容器，用于执行应用容器启动前的初始化逻辑，核心特性如下：
-
线性阻塞启动：多个Init容器必须按定义顺序依次执行，前一个Init容器以返回码0成功退出后，才会启动下一个Init容器；前一个失败则后续Init容器永远不会被创建。
-
返回码强制要求：Init容器必须以返回码0退出才算成功，若返回非0值：
-
若Pod重启策略为
Always/OnFailure，则会不断重启失败的Init容器，直到全部Init容器成功； -
若重启策略为
Never，则只要任意一个Init容器返回非0，整个Pod直接标记为失败，不会重启。
-
镜像独立性：Init容器可以与应用容器（App Container）配置不同的镜像，可将依赖工具、敏感初始化逻辑等放在Init容器中执行，与应用镜像解耦。
-
探针限制：Init容器不支持配置就绪探测，其余配置规则与应用容器基本一致。
-
可选性：Init容器不是Pod的必填配置，可按需添加。
三、实验验证环节
实验1：验证Init容器阻塞性
资源清单配置
测试Pod名为init-1，配置2个Init容器与1个应用容器：
-
Init容器1
init-my-service：使用基础镜像，执行until nslookup my-service; do echo "Waiting for my service"; sleep 2; done逻辑，循环解析my-service域名，解析成功则退出循环。 -
Init容器2
init-my-db：逻辑同上，仅解析域名替换为my-db。 -
应用容器
my-app：使用基础镜像，执行打印rap is running后休眠3600秒的逻辑。
操作与验证
-
直接创建Pod：由于集群中不存在
my-service与my-db的Service资源，集群DNS插件无法解析对应域名，init-my-service持续循环，Pod状态为Init:0/2，应用容器不会被创建。 -
创建
my-service的ClusterIP类型Service：执行kubectl create svc clusterip my-service --tcp=80:80，集群DNS插件会自动将Service名解析为对应的ClusterIP。 -
观察Pod状态：
init-my-service解析成功后退出，init-my-db开始启动，Pod状态变为Init:1/2，验证了Init容器线性阻塞启动的特性：前一个成功才会启动下一个。
实验2：验证Init容器返回码强制要求
自定义镜像说明
使用自定义镜像randexit:v1，默认启动后休眠5秒，返回随机返回码（返回值≥50时返回1，<50时返回0），可通过追加参数--exitcode=数值强制指定返回码。
操作与验证
-
配置Init容器强制返回1：在测试Pod的Init容器中追加参数
--exitcode=1，创建Pod后Init容器会以返回码1退出，触发重启策略不断重启，应用容器永远不会被创建。 -
修改参数强制返回0：将参数修改为
--exitcode=0，重新创建Pod后Init容器以返回码0成功退出，应用容器正常启动，验证了Init容器必须返回0才能进入后续启动流程的规则。
实操小技巧
kubectl支持常用资源简写，可简化操作命令：
-
Service 简写为
svc -
Deployment 简写为
deploy -
Pod 简写为
po
AI 总结
本部分首先补充了Kubernetes 1.16版本新增的启动探测（Startup Probe）机制，解决了早期存活性探测过早触发导致应用未启动完成就被杀死、陷入循环重启的Bug，明确了启动、就绪、存活性三类探针的定位、执行优先级与通用规则；随后详细梳理了Init容器的5项核心特性，包括线性阻塞启动、返回码强制要求、镜像独立性、探针限制与可选性；最后通过两组对照实验分别验证了Init容器的阻塞性与返回码规则，同时补充了kubectl常用资源简写等实操技巧，帮助理解Pod启动阶段的完整生命周期逻辑。