白眉大叔
在 Kubernetes 中，Pod 的探针（Probe）是保障应用高可用的核心机制。K8s 提供了三种探针：存活探针（LivenessProbe）、就绪探针（ReadinessProbe） 和 启动探针（StartupProbe）。
为了让你更直观地理解，我们可以用一个“餐厅后厨”的例子来类比：
- 启动探针 (StartupProbe)：检查厨师是否到岗并完成开工准备（穿工服、备食材）。没准备好前，不安排其他检查。
- 存活探针 (LivenessProbe)：检查厨师是否还在正常工作（没晕倒、没摸鱼）。如果不动了，就换个人（重启容器）。
- 就绪探针 (ReadinessProbe)：检查厨师当前做的菜是否合格可以上桌。如果不合格，暂时不让他出菜（从服务流量中摘除），但不会开除他。
下面是一个综合了这三种探针的完整 YAML 案例（以 Nginx 为例）：
在启动探针成功前，存活和就绪探针都会被暂时禁用，防止应用还没起好就被误杀
案例：
apiVersion: v1
kind: Pod
metadata:
name: probe-demo
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
# 1. 启动探针 (StartupProbe)
# 针对启动较慢的应用（如加载大模型、复杂初始化的Java应用）
# 在启动探针成功前，存活和就绪探针都会被暂时禁用，防止应用还没起好就被误杀
startupProbe:
httpGet:
path: /index.html
port: 80
failureThreshold: 30 # 允许失败30次
periodSeconds: 10 # 每10秒探测一次（相当于给了应用 30*10=300秒 的启动时间）<websource>source_group_web_3</websource>
# 2. 存活探针 (LivenessProbe)
# 检测容器是否“死”了（如进程死锁、假死）。失败后会触发容器重启
livenessProbe:
exec: # 方式一：执行容器内命令
command:
- pgrep
- nginx # 检查 nginx 进程是否存在
initialDelaySeconds: 30 # 容器启动后等待30秒再开始探测（避开启动期）
periodSeconds: 10 # 每10秒探测一次
timeoutSeconds: 5 # 单次探测超时时间为5秒
failureThreshold: 3 # 连续失败3次才判定为不健康并重启<websource>source_group_web_4</websource>
# 3. 就绪探针 (ReadinessProbe)
# 检测容器是否“准备好”接收流量。失败后会将 Pod 从 Service 的端点列表中剔除
readinessProbe:
tcpSocket: # 方式二：检测 TCP 端口是否连通
port: 80
initialDelaySeconds: 5 # 启动后等待5秒开始探测
periodSeconds: 5 # 每5秒探测一次
failureThreshold: 3 # 连续失败3次标记为未就绪
在 Kubernetes 中，kubelet 是运行在每个节点上的“健康检查员”，它通过你配置的探针（Probe）定期对容器执行诊断操作。kubelet 探测探针的具体机制和流程如下：
1. kubelet 的三种底层探测手段
kubelet 本身并不直接“感知”应用状态，而是通过以下三种方式去“询问”容器：
- ExecAction（执行命令）：kubelet 在容器内部执行你指定的命令（例如
cat /tmp/healthy或pgrep nginx）。如果命令退出时的状态码为0，kubelet 就认为探测成功；否则视为失败。 - HTTPGetAction（HTTP 请求）：kubelet 向容器指定的 IP 地址、端口和路径（例如
/healthz）发送一个 HTTP GET 请求。如果返回的状态码在200到399之间，kubelet 判定为成功。 - TCPSocketAction（TCP 端口检测）：kubelet 尝试与容器的指定端口建立 TCP 连接。如果连接能够成功建立，kubelet 就认为探测成功；如果连接被拒绝或超时，则判定为失败。
3. 探测结果触发的动作
kubelet 探测完成后，会根据探针的类型采取不同的行动：
- 存活探针（LivenessProbe）：如果 kubelet 判定存活探针失败，它会直接杀掉（Kill）该容器，并根据 Pod 的重启策略（RestartPolicy，通常是 Always）来重启容器，以应对应用死锁或假死的情况。
- 就绪探针（ReadinessProbe）：如果 kubelet 就就绪探针失败，它不会重启容器，而是将该 Pod 的 IP 地址从对应 Service 的后端端点（Endpoints）列表中剔除。这样，Service 的流量就不会再转发给这个还没准备好的 Pod。当探测重新成功后，kubelet 会再次把 Pod 加回流量列表。
- 启动探针（StartupProbe）：如果配置了启动探针，kubelet 会暂时禁用该容器的存活和就绪探针，直到启动探针探测成功为止。如果启动探针失败，kubelet 会杀掉容器并重启。这主要是为了给启动缓慢的应用（如加载大模型的 Java 应用）留出足够的初始化时间，防止被存活探针误杀。
简单来说，kubelet 就像一个严格的巡检员，拿着你给的检查清单（探针配置），按时去敲容器的门（执行探测手段），并根据门内的反应（退出码、HTTP状态码、TCP连接）来决定是重启它（Liveness）还是暂时不派活给它（Readiness）。
-----------------------
在 Kubernetes 中验证探针（Startup、Liveness、Readiness）是否生效，主要有查看 Pod 事件、观察 Pod 状态、检查 Endpoints 以及查看 Kubelet 日志这几种非常实用的方法。
1. 查看 Pod 事件（最直接的验证方式）
Kubelet 每次执行探针检测并触发动作时，都会在 Pod 的事件（Events）中留下记录。这是验证探针最直观的方法。
- 验证存活探针 (Liveness)：
执行命令：kubectl describe pod <pod-name>
在输出的Events区域，如果存活探针失败，你会看到类似这样的记录：
Warning Unhealthy Liveness probe failed: ...
紧接着会有一条：
Normal Killing Container <container-name> was killed due to liveness probe failure - 验证启动探针 (Startup)：
同样使用kubectl describe pod <pod-name>。如果启动探针失败，你会看到：
Warning Unhealthy Startup probe failed: ...
随后容器会被 Kubelet 杀掉并重启。
2. 观察 Pod 状态与重启次数
通过实时观察 Pod 的状态变化，可以验证探针是否触发了预期的动作。
- 验证存活/启动探针（触发重启）：
执行命令：kubectl get pod <pod-name> -w（-w表示持续观察）- 如果存活探针失败，你会发现 Pod 的
RESTARTS（重启次数）不断增加，且STATUS会在Running到CrashLoopBackOff之间波动。 - 如果启动探针一直失败，Pod 会陷入反复重启的循环，无法进入正常的
Running状态。
- 如果存活探针失败，你会发现 Pod 的
- 验证就绪探针（流量摘除）：
就绪探针失败不会导致 Pod 重启，因此RESTARTS次数不会变。你需要通过下一条方法来验证。
3. 检查 Service 的 Endpoints（验证就绪探针）
就绪探针的核心作用是控制流量。如果就绪探针失败，Kubelet 会将该 Pod 的 IP 从对应 Service 的后端端点（Endpoints）中剔除。
- 先获取 Pod 的 IP：
kubectl get pod <pod-name> -o wide - 查看该 Pod 所属 Service 的 Endpoints：
kubectl describe endpoints <service-name> - 验证方法：当就绪探针失败时，你会发现
Addresses列表中不再包含该 Pod 的 IP；当探针重新成功后，该 IP 又会重新出现在Addresses列表中。
4. 查看 Kubelet 日志（底层排错）
如果你想看到 Kubelet 到底执行了什么命令、返回了什么状态码，可以直接登录到 Pod 所在的节点查看 Kubelet 的系统日志。
- 执行命令（根据系统不同）：
journalctl -u kubelet -f | grep <pod-name>
或者查看日志文件：tail -f /var/log/messages | grep probe - 在这里你可以看到 Kubelet 周期性执行探针的原始日志，例如
Probe failed for container ...或Liveness probe succeeded等详细信息。
欢迎来撩 ： 汇总all
