一、启动探针（Startup Probe）
核心作用
是Kubernetes v1.16版本后官方新增的功能，核心解决仅配置存活探针（Liveness Probe）、就绪探针（Readiness Probe）时延迟时间设置过短导致的容器无限重启问题：若容器刚启动就因探测失败被杀死，会陷入无限循环。
工作逻辑
必须配置启动探针且探测成功之后，才会开始执行存活探针和就绪探针，从根源上规避了上述问题。
配置参数
| 参数 | 说明 | 默认值 | 最小值 |
| — | — | — | — |
| initialDelaySeconds | 容器启动后多久开始执行启动探测 | 0秒 | 0秒 |
| periodSeconds | 探测间隔时间 | 10秒 | 1秒 |
| timeoutSeconds | 单次探测超时时间，超时则判定本次探测失败 | 1秒 | 1秒 |
| successThreshold | 启动成功判定阈值，连续探测成功次数达到该值则标记启动成功 | 1次 | - |
| failureThreshold | 启动失败判定阈值，连续探测失败次数达到该值则标记启动失败，容器会被杀死 | 3次 | - |
结果处理逻辑
-
探测成功：允许存活探针、就绪探针开始执行
-
探测失败：静默等待下一次启动探针执行，不做额外处理
-
状态未知：同样静默，等待下一次探测
二、生命周期钩子（Lifecycle Hooks）
基本概念
生命周期钩子由Pod所在节点的kubelet发起（注意不是API Server），在容器进程启动前、容器进程终止前执行，属于容器生命周期的一部分，可以为Pod中的每个容器单独选择是否配置钩子。
执行类型
支持两种执行方式：
-
Exec类型：执行一段自定义命令
-
HTTP Get类型：发起HTTP请求
两种钩子定义
- postStart（启动后钩子）
-
触发时机：容器初始化完成后、容器启动命令执行前触发
-
特性：不会阻塞容器启动命令的执行，即钩子可能还未执行完成，容器的启动命令就已经开始运行
- preStop（关闭前钩子）
-
触发时机：容器被杀死、发送终止信号之前触发，会先执行preStop钩子逻辑，再发送终止信号
-
作用：是Pod优雅终止（Graceful Shutdown）的核心环节
优雅终止补充说明
Pod优雅终止的理想流程为：发送SIGTERM（15号）信号 → 等待应用执行优雅退出逻辑 → 超时后发送SIGKILL（9号）信号强制杀死容器。
但存在以下情况会导致无法正常优雅终止：
-
容器卡死，忽略SIGTERM信号
-
应用优雅退出逻辑存在bug，未正确处理终止信号
-
应用代码有问题，无法正常执行优雅退出逻辑
此时kubelet会设置默认30秒的容忍时限：从发送SIGTERM开始，若30秒内容器仍未退出，则直接发送SIGKILL信号强制杀死，preStop钩子若执行时间超过该时限，会被强制终止无法完成执行。
可通过Pod的terminationGracePeriodSeconds字段自定义容忍时限，默认值为30秒。
三、实验验证
实验1：启动探针功能验证
实验准备
配置包含以下探针的Pod资源清单：
-
启动探针：HTTP Get类型，探测
/index1.html页面，失败阈值30次，间隔10秒（即最长允许5分钟启动时间） -
就绪探针：HTTP Get类型，探测
/index2.html页面，延迟1秒，间隔3秒
实验步骤与结论
-
创建Pod后初始状态为
NotReady -
进入Pod创建
index2.html文件，Pod仍为NotReady：因为启动探针探测的index1.html未创建，启动探针未通过，就绪探针不会执行 -
创建
index1.html文件后，启动探针通过，就绪探针开始执行，Pod变为Ready状态 -
结论：必须启动探针通过后，存活/就绪探针才会开始执行
实验2：Exec类型生命周期钩子验证
实验准备
配置包含以下钩子的Pod资源清单：
-
postStart：执行命令echo "poststart" >> /usr/share/message -
preStop：执行命令echo "prestop" >> /usr/share/message
实验步骤与结论
-
创建Pod后进入容器，查看
/usr/share/message文件已存在poststart内容，证明postStart钩子执行成功 -
开启死循环脚本持续打印
/usr/share/message文件内容，另一个终端删除Pod，观察到文件新增prestop内容，证明preStop钩子在容器终止前执行成功
实验3：HTTP Get类型生命周期钩子验证
实验准备
- 在Master节点启动web服务，端口映射为
1234:80
docker run -it --rm -p 1234:80 nginx:latest - 配置Pod的钩子：
-
postStart：HTTP Get请求访问Master节点的/index.html（1234端口） -
preStop：HTTP Get请求访问Master节点的/index1.html（1234端口）
实验步骤与结论
-
创建Pod后，Master节点web服务日志出现访问
/index.html的请求，证明postStart钩子执行成功 -
删除Pod后，Master节点web服务日志出现访问
/index.html的请求，证明preStop钩子执行成功
四、综合实验演示（全生命周期功能整合）
实验配置
配置多容器Pod，整合以下所有生命周期特性：
- 容器1：
-
启动逻辑：初始化后创建
live文件，休眠600秒后删除该文件，再休眠3600秒 -
存活探针：Exec类型，检测
live文件是否存在，延迟1秒，间隔3秒 -
postStart钩子：HTTP Get类型，访问Master节点1234端口的/index.html -
preStop钩子：HTTP Get类型，访问Master节点1234端口的/index1.html
- 容器2：基于busybox镜像
-
存活探针：HTTP Get类型，检测80端口的
/index.html页面，延迟1秒，间隔3秒，超时3秒 -
就绪探针：HTTP Get类型，检测80端口的
/index1.html页面
-
Init容器1：探测
myservice这个Service -
Init容器2：探测
mydb这个Service
实验步骤与问题排查
-
创建Pod后卡在Init容器阶段：原因是集群中不存在
myservice和mydb对应的Service资源 -
创建
myservice的ClusterIP Service（端口80）后，第一个Init容器通过，但仍卡在第二个Init容器 -
创建
mydb的ClusterIP Service（端口80）后，所有Init容器通过，Pod进入主容器创建阶段 -
此时Pod的
postStart钩子执行失败：原因是之前启动的测试web服务被关闭，重新启动web服务后钩子执行成功 -
此时Pod状态为
1/2 Ready：因为第二个容器缺少就绪探针要求的/index1.html文件，进入第二个容器创建该文件后，Pod变为全Ready状态 -
验证存活探针：进入第二个容器删除
/index.html文件后，容器被杀死重建，Pod变为NotReady（新容器不存在/index1.html，不满足就绪探针要求） -
验证
preStop钩子：通过web服务日志可确认容器终止前发起了对应的HTTP请求
补充说明
Pod生命周期的所有功能（启动探针、存活探针、就绪探针、生命周期钩子）可以同时使用，也可以为不同容器配置不同功能，互不冲突。本小节共包含13个实验，需逐一验证理解，为后续学习K8s控制器（底层依赖Pod生命周期知识）打下基础。
AI 总结
本小节详细讲解了Kubernetes Pod生命周期中启动探针、生命周期钩子的核心概念、配置参数与工作逻辑，通过多组分层实验验证了各特性的实际效果，最终通过整合所有生命周期功能的综合实验，帮助学员全面掌握Pod生命周期的关键知识点，为后续学习K8s控制器等内容奠定基础。