探针失败：无流量与 CrashLoop

仓库样例 examples/probes/deployment.yaml 在最小闭环基础上挂了合理探针：httpGet path=/、port=80，readiness 短延迟高频探测，liveness 稍晚启动、间隔更长。本场景的重点不是「会抄字段」，而是故意把它配错一次，用 get / describe / get endpoints 把因果链钉死。对照 kubectl explain probe，确认 httpGet、initialDelaySeconds、periodSeconds、failureThreshold 各自在时间轴上扮演什么角色。

readinessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 2
  periodSeconds: 5
  failureThreshold: 3
livenessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 10
  periodSeconds: 10
  failureThreshold: 3

读这段字段时，按时间线想，不要按「开关」想。容器启动后：前 2 秒 readiness 还不急着判失败；之后每 5 秒探一次，连续 3 次失败才摘流量。liveness 则故意晚 10 秒再动手，给启动与预热留窗口。生产里最常见的误配是：把业务级「依赖下游超时」塞进 liveness——下游抖动时 kubelet 连环杀进程，事故从「慢」升级成「全员重启」。另一类是 readiness path 写错或依赖尚未就绪的内部接口，导致滚动发布期间新副本永远进不了 Endpoints，Service 只剩旧副本甚至零后端。

要点

readiness 管「能不能接客」，liveness 管「该不该重开店」——把启动慢当成卡死，是探针事故的经典剧本。

实验结束后务必 kubectl delete -f examples/probes/ 清理，或把清单恢复为仓库原样再 apply。把这次对照写成两行笔记就够用：readiness 失败 = 副本在、流量无；liveness 过激 = 启动中被杀、CrashLoop。中阶后续的发布回滚与排障决策树，都会反复问你同一句话：现在是流量问题，还是进程生死问题？