面向初级运维，使用 Linux 节点和稳定 Kubernetes API。命令按 Bash 编写。本文为教学故障场景，日志及结果为示意，不冒充生产实测；执行前确认 context、命名空间和权限。
一、遭遇情况：容器一直运行，但 Service 没有可用后端
Pod 显示 Running，READY 却是 0/1，重启次数一直没增长。通过诊断入口访问首页又能得到 200，为什么集群还不把它当作就绪服务？
本篇案例是 readinessProbe 请求 /healthz，而演示 Nginx 只提供首页，健康检查返回 404。应用进程活着，但不满足声明的就绪条件。
二、原因分析：三种探针各自解决不同问题
| 探针 | 主要判断 | 失败后的典型作用 |
|---|---|---|
| readinessProbe | 当前能否接收业务流量 | 影响 Ready 与可用后端，不直接要求重启 |
| livenessProbe | 是否需要通过重启恢复 | 达到失败阈值后终止容器并按策略处理 |
| startupProbe | 启动阶段是否完成 | 成功前抑制其他两类探针，失败达到阈值也可触发终止 |
Running 不等于 Ready，Ready 也不等于所有业务请求都正确。探针检查口径必须符合应用含义，不能只为了绿色状态随便请求一个总是成功的地址。
三、排查思路：先找到失败的是哪一个请求
kubectl describe pod 目标Pod -n 目标命名空间
kubectl get deployment 目标部署 -n 目标命名空间 -o yaml
kubectl logs 目标Pod -n 目标命名空间 -c 容器名 --tail=100 --timestamps
从事件核对探针类型、失败状态码或超时。再看路径、端口、HTTP/HTTPS、命名端口是否对应真实监听。
HTTP 探针由 kubelet 发起，和用户从 Ingress 访问的完整链路不同。应用如果要求特定 Host、认证或只监听容器回环地址，可能导致探针失败；应明确设计健康端点，而不是假设浏览器能打开就意味着探针一定成功。
如果是慢启动，核对 startupProbe 与启动时间预算。不要直接移除所有探针，也不要把外部数据库暂时不可用一律放进 liveness，让大量应用一起重启。
四、实践：一个因 404 而未就绪的 Deployment
保存 kt08-probe.yaml：
apiVersion: v1
kind: Namespace
metadata:
name: kt08
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
namespace: kt08
spec:
replicas: 1
selector:
matchLabels:
app: probe-demo
template:
metadata:
labels:
app: probe-demo
spec:
containers:
- name: web
image: nginx:stable-alpine
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
path: /healthz
port: http
periodSeconds: 5
timeoutSeconds: 2
failureThreshold: 3
kubectl apply -f kt08-probe.yaml
kubectl get pods -n kt08
kubectl describe pod -n kt08 -l app=probe-demo
预期容器 Running，但 Ready 为 false，事件提示 readiness 返回 404，重启次数不因这条 readiness 规则直接增长。若同时配置了其他重启机制，仍需分别判断。
五、修复实践：校正端点，而不是校正“颜色”
在这个演示应用里，首页就是用于证明 Web 进程响应的端点，可把实验 readiness 改为 /：
kubectl patch deployment web -n kt08 --type=strategic -p '{"spec":{"template":{"spec":{"containers":[{"name":"web","readinessProbe":{"httpGet":{"path":"/","port":"http"}}}]}}}}'
kubectl rollout status deployment/web -n kt08 --timeout=120s
kubectl get pods -n kt08
预期新 Pod 变为 1/1 Ready。真实应用不一定适合检查首页，应提供能表达自身就绪状态的轻量接口。这里的 / 是实验修复，不是所有服务的健康检查标准答案。
慢启动应用可以增加合适的 startupProbe；失败阈值与周期提供大致启动容忍预算，但还受请求耗时与调度等影响，不应当作精确秒表。配置应根据实际启动分布评估。
六、验证与总结
检查事件中的旧失败不再持续出现、新 Pod Ready、Deployment 可用，并继续通过真实业务入口验证。旧事件仍在列表里，不一定意味着故障还在，注意最近时间和计数。
如果同时关注 Service，可进一步检查 EndpointSlice 的 endpoint 条件；不要仅看里面有 IP，就断定它已经是可用后端。下一篇会把选择器、端口与后端状态连起来。
探针故障的关键是先判断哪种探针、请求了什么、为什么失败，再选择路径修正、启动预算或应用修复。未就绪不必然需要重启，重启也不必然让探针含义变正确。