Kubernetes 三种探针各有什么作用，配置不当会有什么后果？

结论：readinessProbe 决定 Pod 是否接流量（从 Service endpoints 摘除/加入），livenessProbe 决定容器是否重启，startupProbe 保护慢启动应用在启动完成前不被 liveness 误杀。

展开：语义差异是核心：readiness 失败不重启容器，只摘流量，适合下游依赖暂不可用的临时状态；liveness 失败由 kubelet 重启容器，只有应用内部死锁、假死这类重启才能恢复的场景才该用它。startupProbe 成功后 liveness/readiness 才开始生效，典型配置 failureThreshold: 30, periodSeconds: 10 给应用 5 分钟启动窗口，替代过去给 liveness 设超长 initialDelaySeconds 的粗暴做法。探测方式有 httpGet、tcpSocket、exec 和 gRPC（v1.27 稳定）。血泪教训：1）liveness 与 readiness 用同一个深依赖接口（如查数据库），数据库抖动会导致全部 Pod 同时被重启或摘流，级联雪崩——readiness 可以查依赖，liveness 只应查进程自身活性；2）timeoutSeconds 默认 1s 太短，高负载时健康接口超时引发连环重启；3）滚动更新时 readiness 不达标会卡住发布，这是保护机制不是 bug。HTTP 探针还要注意路径幂等、不要打日志风暴。