先把话说在前面Kubernetes 里探针Probe这四五个字段可能是整个 Pod 定义里最不起眼、却最能决定线上稳定性的一小段配置。很多人用 k8s 用了一两年Deployment、Service、Ingress 摸得滚瓜烂熟唯独探针这段配置常年靠复制粘贴改个端口就往上扔。结果就是容器偶尔被误杀、发布时流量被导到没就绪的 Pod、慢启动应用被反复重启排查到最后发现根因全在探针上。这篇文章不聊大而全的 Kubernetes 原理就专注把 k8s 探针这件事讲透。我会从三种探针的分工逻辑讲起拆解每个检测参数背后的设计意图给出可落地的配置模板和调优建议再把我自己踩过和帮别人排查过的典型故障案例整理成速查表。无论你是刚接触 K8s 的运维新手还是已经被探针折磨过的开发者这篇内容都能直接拿来用。1. 先搞明白探针到底在解决什么问题1.1 没有探针的时候K8s 是怎么“盲管”应用的最朴素的容器管理逻辑是这样的只要容器进程还活着K8s 就认为这个 Pod 是可用的。但现实中“进程活着”和“服务可用”之间隔着十万八千里。我见过太多例子Java 应用进程还在但线程池已经满到拒绝新请求Nginx 进程健在但后端 upstream 全挂它只能返回 502数据库连接池被耗尽应用线程全部阻塞在获取连接上。这些情况下进程都没有退出可流量打到 Pod 上就是错误。没有探针时K8s 对这种情况毫无办法。它不知道你的应用内部发生了什么也不会主动做任何干预。你只能等用户来投诉然后手动重启或者写一堆乱七八糟的外部监控脚本去调 API 删 Pod。这显然不是平台该有的行为——编排平台的核心能力之一就是自动发现“不健康”的实例并做自愈。探针就是 K8s 给出的答案。1.2 三种探针三种完全不同的“健康观”K8s 提供了三种探针对应三个不同层面的健康检查视角存活探针livenessProbe回答“这个容器还活着吗”。失败时 kubelet 会杀掉容器并触发重启策略。它关注的是进程级、内部状态级的问题比如死锁、内存泄漏导致的假死。就绪探针readinessProbe回答“这个容器能不能接收流量”。失败时 Pod 会从 Service 的 Endpoints 里摘掉但容器不会被杀死。它关注的是服务可用性比如依赖组件没准备好、缓存没加载完、流量过载。启动探针startupProbe回答“这个应用启动完成了吗”。它专门用来保护慢启动的应用在启动探针成功之前存活探针和就绪探针都不会生效。三者的失败后果差异很关键存活探针失败是“杀掉重启”就绪探针失败是“摘流量不杀”。如果搞混这两者的使用场景后果相当严重。举个反向例子有个团队为了“确保服务健康”把存活探针配得特别敏感一有波动就重启容器。结果流量高峰期容器被连续重启Pod 反复 CrashLoopBackOff整个集群被他们自己玩挂了。存活探针应该是保守的、低频的、只查最致命的指标就绪探针才应该对业务状态敏感。1.3 探针能探测的三种检测机制每种探针都可以用三种方式之一来执行检测HTTP 请求httpGetkubelet 向指定路径发起 HTTP GET 请求只要返回码在 200~399 之间就算成功。这是最常用的方式适合所有暴露 HTTP 接口的应用。TCP 连接tcpSocketkubelet 尝试建立 TCP 连接能连上就算成功。适合 Redis、MySQL 这类非 HTTP 协议的组件或者在应用还没有健康检查端点时做兜底。执行命令execkubelet 在容器内执行一条命令以退出码 0 判定成功。适合无法通过端口表达状态、需要综合判断的场景比如检查某个内部进程是否在跑、配置文件是否完整。三种机制没有绝对的优劣核心是匹配应用暴露状态的方式。HTTP 能拿到业务层状态但前提是你的应用得真的实现了一个有意义的健康检查端点TCP 最省事但只能证明“端口能连”证明不了“业务能用”exec 最灵活但要小心命令本身的开销和依赖。后面我会专门展开每种方式的具体坑。2. 探针参数详解K8s 是如何判定“成功”和“失败”的2.1 五个关键参数构成了一个“欠采样”的判断系统先看一个典型的探针配置长什么样readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 10 periodSeconds: 5 timeoutSeconds: 3 failureThreshold: 3 successThreshold: 1这五个参数的含义分别是参数默认值含义initialDelaySeconds0容器启动后等待多久才开始第一次探测给应用留初始化时间periodSeconds10每隔多少秒探测一次timeoutSeconds1单次探测的超时时间超时算本次失败failureThreshold3连续失败多少次后才判定探针状态翻转就绪变未就绪 / 存活变不存活successThreshold1连续成功多少次后才判定探针状态恢复仅 readiness 和 startup 需要liveness 固定为 1注意 K8s 的判定是“欠采样”的不是一次失败就立刻反应。这其实是个很好的设计——它能过滤掉 GC 停顿、网络抖动、偶发超时等瞬时扰动。但反过来这个设计也意味着探针从“第一次失败”到“真正触发动作”存在时间差。以大流量场景为例如果一次失败就要立即摘流量那很容易抖动但如果失败判定阈值太大异常流量已经打进来很久了摘流量的动作才姗姗来迟。后面我会给出实战中的建议阈值。2.2 一次失败的完整“生命周期”探针状态机理解探针判定的关键在于搞清楚“单次探测”和“探针状态”的关系。kubelet 每过一个 periodSeconds 就发起一次探测得到结果后更新内部的探针状态。判定规则可以概括为单次探测结果成功、失败含超时。连续失败次数达到 failureThreshold 后探针进入“失败”状态。连续成功次数达到 successThreshold 后探针回到“成功”状态。这里有个容易忽略的点探针状态是有“记忆”的。比如 readinessProbe 的 failureThreshold 是 3如果前两次已经失败了第三次探测成功那么连续失败计数会清零探针状态继续维持“就绪”。这意味着即便应用已经持续异常了两轮探测只要在触发阈值前恢复就不会发生摘流量。反过来一旦连续失败达到阈值探针进入失败态之后再恢复需要连续成功 successThreshold 次才能回到就绪态而在这期间 Pod 一直处于“未就绪”状态流量不会进来。2.3 参数怎么配核心是理解你的应用“启动曲线”很多人配置探针参数全凭感觉我给一个更系统的思路先画出应用从进程启动到完全可服务的时间曲线。假设某服务进程启动只要 1 秒但加载一个 500MB 的缓存文件需要 15 秒。这期间 HTTP 端口已经监听了但请求进来会因为没有缓存而报错。如果把 readinessProbe 的 initialDelaySeconds 设为 10periodSeconds 设为 5那第一次探测发生在 10 秒恰好命中缓存加载的“临界区”Pod 会被标记未就绪。这本身没问题但很可能在 15 秒缓存加载完后接下来第一次成功的探测才把它重新标记为就绪。如果 periodSeconds 是 210 秒时未就绪12 秒时可能缓存还没好又失败一次连续失败超过 thresholdPod 从 Service 摘除。等到缓存加载完毕再重新就绪中间会出现几秒到几十秒的可用性空窗。更麻烦的是 livenessProbe。如果把它也配置在启动早期initialDelaySeconds 太短就会在应用还在初始化时被判定失败然后杀掉容器。启动要 15 秒但 initialDelay 只留了 5 秒结果容器每 5 秒被杀一次永远起不来这就是典型的 CrashLoopBackOff 陷阱。正确的做法是区分两种启动场景启动很快3~5 秒内直接用 livenessProbe readinessProbeinitialDelaySeconds 给一个略大于启动时间的值即可。启动很慢几十秒甚至几分钟用 startupProbe 保驾护航。startupProbe 成功之前livenessProbe 和 readinessProbe 不参与判定。startupProbe 的 failureThreshold 要足够大periodSeconds 可以短一些确保启动期间不被误杀。启动完成后liveness 接管“运行时存活管理”readiness 接管“流量接入管理”各司其职。举个我实践过的配置startupProbe: httpGet: path: /health/startup port: 8080 periodSeconds: 2 failureThreshold: 30 # 60 秒内允许最多 30 次失败给慢启动充分余量 timeoutSeconds: 2 livenessProbe: httpGet: path: /health/live port: 8080 periodSeconds: 10 timeoutSeconds: 3 failureThreshold: 3 readinessProbe: httpGet: path: /health/ready port: 8080 periodSeconds: 5 timeoutSeconds: 2 failureThreshold: 1 successThreshold: 1注意我把三个探针指向了三个不同端点。后面会解释为什么不能共用一个端点。3. 检测方式选型HTTP、TCP、exec 各自的适用场景与深坑3.1 HTTP 探针最常用也最容易“假健康”httpGet 是目前生产环境里最主流的探针方式核心原因是它最能反映业务层的真实状态。一个设计良好的 /healthz 端点通常会去检查关键依赖——数据库连接是否可用、缓存是否就绪、磁盘空间是否充足——然后返回 200 或 500。但这里深坑非常多。第一不要只依赖“端口能通”。如果健康检查端点只返回 200 但不做任何内部检查那它和 TCP 探针没什么区别。很多应用框架的默认 health 端点只检查进程活着不会检查线程池、队列积压、依赖组件状态。你得自己确认 /healthz 到底检查了什么。第二注意返回码范围。K8s 把 200~399 都算成功。也就是说你的 /healthz 返回 301、302 重定向也会被判定为“健康”。如果应用把根路径 / 重定向到某个登录页而健康检查路径配置成了 /那探针会一直成功但这个应用可能根本没法处理业务请求。我遇到过类似案例某团队配置 httpGet path: /Nginx 把它 302 跳转到强制登录页探针永远成功直到用户把链路测挂。第三不要忽略 scheme 和 httpHeaders。如果你的健康检查端点只允许内网访问那没问题但如果端点放在 HTTPS 后面探针默认走 HTTP你需要显式配置 scheme: HTTPS。另外很多应用要求自定义 Header比如 Authorization可以在 httpHeaders 里加。经常有人忘了这步导致探针永远收到 401容器反复重启。第四检查路径本身不能太重。有些团队把健康检查做成“全量检查”把所有依赖都探一遍结果每次探测耗时好几秒而 timeoutSeconds 只配了 1 秒。这个后面会展开说。3.2 TCP 探针简单粗暴但只能证明“端口在听”tcpSocket 是三种方式里最“低水平”的。kubelet 只是去 connect 一下TCP 握手成功了就算健康。它适合以下场景应用不暴露 HTTP 接口比如 Redis、MySQL、Kafka没法用 httpGet。应用处于早期阶段还没有实现健康检查端点先拿 TCP 兜底。探针目标是一个独立组件端口连通性基本等价于可用性。但它的问题也很明显只要端口还在 listen探针就认为健康哪怕这个进程已经陷入死锁、无法响应任何请求。TCP 层面的连接成功只能说明内核协议栈还在工作到不了业务层。我自己的习惯是TCP 探针只作为最低限度兜底但凡应用能提供 HTTP 健康检查端点一律用 httpGet。如果你现在还在用 tcpSocket 探测一个 Web 应用强烈建议尽早改造。3.3 exec 探针灵活性强但坑比想象中多exec 探针给了你最大的自由度在容器内执行任意命令退出码为 0 就成功。它的典型场景有两个没有网络端口的进程或者端口本身不能代表可用性。比如一个批处理进程、一个 Agent 类程序你要检查它内部的某个状态文件是否更新、某个工作协程是否还在跑。需要在容器内做多级判断比如检查磁盘使用率、检查子进程健康、检查配置文件是否完整用一个命令组合表达。但 exec 探针的坑也最隐蔽。第一依赖容器内环境。你的命令可能依赖 shell、依赖某个二进制、依赖容器镜像里的特定路径。镜像一旦做了精简比如用了 distroless 镜像里面连 /bin/sh 都没有exec 探针直接失败。这是很多人从 CentOS 镜像换成 distroless 后容器莫名重启的主要原因。第二命令本身会成为额外开销。如果探针命令很重比如写了一个脚本去扫描日志、查数据库而 periodSeconds 又很短这个探针本身就会拖垮容器。我在某个故障现场见过探针脚本里有个 grep 全目录日志的操作直接把 CPU 打满。第三exec 探针有一个特殊用法值得留意命令可以在容器内主动“杀掉自己”。比如livenessProbe: exec: command: - sh - -c - pgrep -f my-worker-process || exit 1如果检测到进程假死或关键线程消失就返回非 0让 kubelet 杀掉容器重启。但这里要非常小心如果命令本身退出码写反了或者 pgrep 匹配到了探针命令自己就会造成误杀。我建议 exec 探针的命令越简单越好不要指望在探针里写复杂的业务逻辑。3.4 三种机制选型对照表检测方式判定条件优点缺点推荐场景httpGet返回码 200~399反映业务层真实状态可自定义 Header依赖健康检查端点的实现质量所有暴露 HTTP 接口的业务应用tcpSocketTCP 握手成功简单不依赖应用侧实现只能证明端口在听无法反映业务可用性Redis、MySQL、Kafka 等非 HTTP 组件exec命令退出码为 0自由度最高可做综合判断依赖容器内环境额外开销易误杀无端口进程、需多条件判断的场景4. 真实故障案例探针配置引发的连环事故4.1 慢启动应用被 livenessProbe 反复杀死我接手过一个模拟系统应用是个 Java 服务启动时要加载模型文件耗时大约 40 秒。运维同事一开始没配 startupProbe只配了 livenessProbeinitialDelaySeconds 设为 10periodSeconds 为 5failureThreshold 为 3。算一下时间线第 10 秒开始探测每 5 秒一次14 秒左右加载还没完成连续失败 3 次后——大约第 24 秒——kubelet 杀掉容器。这还没完重启后又一次循环开始时间更长永远起不来。K8s 控制台 Event 里全是“Liveness probe failed: HTTP probe failed with statuscode: 503”和“Back-off restarting failed container”。修复方式就是加 startupProbefailureThreshold 给足 30 次periodSeconds 设 2这样 60 秒的启动窗口足够覆盖 40 秒的加载时间。startupProbe 成功的瞬间livenessProbe 接管之后运行期出问题才会重启。这里我想强调一个细节很多人以为把 initialDelaySeconds 调大就能解决慢启动。比如给 liveness 配 initialDelaySeconds: 45确实也能绕过启动窗口。但这样做的代价是如果应用启动过程中卡死了比如等待某个远程依赖超时挂起K8s 要等到 45 秒后才会开始探测再等几轮失败才会杀容器。而用 startupProbe最短 2 秒就能探一次一旦发现启动卡住就能快速失败。一个是“干等”一个是“主动观察”效果完全不同。4.2 就绪探针和存活探针共用端点导致故障雪崩这个案例在线上出现过不止一次。某团队图省事把所有探针都指向同一个 /health 端点。平时流量低没问题但有一次大促流量暴涨数据库连接池被占满所有请求都慢/health 端点在检查数据库连接时也超时返回 500。readinessProbe 连续失败Pod 被从 Service 摘除流量被分摊到其他 Pod其他 Pod 也没扛住同样未就绪、同样摘除。按说这是一个正常的缩流量保护机制问题在于 livenessProbe 也指向同一个 /health它也失败了。liveness 失败不是摘流量而是直接杀容器。于是 Pod 被杀、重启、继续打数据库、继续失败、再被杀形成更大范围的雪崩。正确的设计必须把“存活”和“就绪”拆成两个端点/health/live只做最轻量的检查比如进程是否活着、关键 goroutine 是否正常。不碰数据库不碰外部依赖避免在资源紧张时因为依赖慢而误杀容器。/health/ready检查一切影响服务可用性的事项包括依赖状态、线程池水位、缓存是否就绪等。它失败时可以接受因为后果只是摘流量不会重启容器。这个拆分逻辑的本质是liveness 检查的应该是“不可恢复的致命问题”readiness 检查的才是“当前可用的业务状态”。牵一发而动全身的因素不应该放在 liveness 里。4.3 超时时间太短探针成了应用性能瓶颈有个 Web 服务的健康检查端点在正常负载下响应约 600ms偶尔在 GC 时到 1.5 秒。运维同事把 livenessProbe 配成了 timeoutSeconds: 1结果 GC 一到就超时失败连续 3 次失败后容器被杀。一天发生好几次全是非必要的重启。这类问题本质上是“探针超时时间与应用响应分布”不匹配。我一般会先看应用的 TP99 响应延迟。如果 TP99 是 800mstimeoutSeconds 至少给 2 秒不能拿 TP50 或者平均值去定。另外探针会把自身的超时请求打到应用上有一个常被忽略的点如果探针超时了kubelet 会直接判定失败但那个请求可能还在应用侧继续执行占用连接池。在高并发时探针自身的流量也会成为压垮应用的最后一根稻草。所以我建议生产环境的探针响应本身要控制在 100ms 以内——健康检查端点里不要做重操作更不要去查完整数据库最好只做一个简单的依赖状态缓存查询。4.4 滚动更新时就绪探针没来得及摘流量升级发布的时候老版本 Pod 被终止新版本 Pod 还没就绪但 Service 的 Endpoints 里仍然保留了还没来得及更新的老 Pod。如果就绪探针的 periodSeconds 配得太大比如 30 秒那么在一个周期内某个已终止的 Pod 还会继续接收流量如果配得太小又可能因为瞬时抖动频繁摘流量。核心矛盾在于K8s 的滚动更新策略最大程度的“快速”而就绪探针的更新频率决定了流量切换的“精确度”。我见过的问题是maxSurge 和 maxUnavailable 默认配成 25%新版本 Pod 的 readiness 一直不通过老版本又被不断缩容集群里既没有足够的可用副本新副本又进不来造成可用性下降。排查时发现新版本应用启动要 30 秒而 readiness 的 initialDelaySeconds 还是默认的 0periodSeconds 5第一次探测发生在启动后 5 秒连续失败超过阈值Pod 长时间处于未就绪状态。调完配置initialDelaySeconds: 20failureThreshold: 3滚动更新立刻顺畅了。所以发布新版本前一定要先在测试环境跑一遍探针在真实启动时间下的行为不要默认“配置一样就不用改”。4.5 优雅停机与就绪探针的“时间差”还有一个容易忽略的细节Pod 进入 Terminating 状态时readiness 探针会继续运行直到所有容器退出。如果你的应用在收到 SIGTERM 后立刻停止响应健康检查但容器真正退出前还有一段优雅关闭期那么在这段时间里K8s 认为 Pod 还是就绪的但实际已经无法处理请求。流量在优雅停机窗口内被打进来用户报错。行业里的通行解法是 preStop hook 里加 sleeplifecycle: preStop: exec: command: - sh - -c - sleep 5这样 Pod 收到 SIGTERM 后先等 5 秒让 Endpoints 控制器来得及把 Pod 摘掉再真正开始关闭进程。但 sleep 时长要配合 readinessProbe 的 periodSeconds 和 terminationGracePeriodSeconds 一起调。如果 sleep 设太长而 terminationGracePeriodSeconds 太短容器会被强制杀死优雅停机反而失败。4.6 常见问题速查表现象典型原因排查方向解决思路容器反复重启无明显业务报错liveness 超时阈值过小/启动期失败看 Pod Event、容器启动日志、探针历史加 startupProbe调大 timeoutSecondsPod 一直未就绪Service 不转发流量readiness 端点返回非 2xx/3xx手动 curl /health/ready 看返回码检查应用依赖修健康检查端点逻辑流量高峰时大量 Pod 被摘除readiness 端点依赖重数据库查询看探针响应耗时轻量化健康检查端点引入依赖状态缓存发布时新版本始终不可用initialDelay 小于启动时间看新 Pod 的 Event 时间线用 startupProbe 覆盖启动窗口Pod 被误杀一天重启很多次timeoutSeconds 小于 TP99看应用延迟分布按 TP99 弹性设置 timeout流量打到 Terminating Pod优雅停机前未摘流量看接入层日志时间戳配置 preStop sleep配合 readiness 周期5. 从经验里提炼的最佳实践探针配置的“道”与“术”5.1 探针是应用的一部分不是 YAML 的一部分这句话是我一直想强调的。很多团队把探针配置当成“基础设施的活”应用开发者不关注运维同学只看 YAML 里的参数结果两边对不上。实际上健康的探针设计必须由应用开发者主导健康检查端点暴露什么信息、依赖哪些组件、返回什么状态码这些都需要应用侧代码配合。如果应用不提供 /health/live 和 /health/ready运维在 YAML 里再怎么调参也是“隔靴搔痒”。我见过最好的实践是应用框架层面统一提供三个端点各自语义清晰。liveness 端点只查进程健康readiness 端点查依赖可用性和负载水位startup 端点用于初始化状态。然后运维在平台侧统一封装探针配置模板开发者只需声明“我的应用启动需要 30 秒”或“我的应用依赖 MySQL和Redis”平台根据这些声明自动生成探针参数。这套协作模式下探针的语义在代码里被固化参数在平台上被标准化线上事故率明显下降。5.2 参数调优的“两套公式”根据个人经验探针参数里最值得花心思的是 failureThreshold、periodSeconds 和 timeoutSeconds。这里分享两个经验公式。一是“探测周期 × 失败阈值”要大于“单次可能出现的异常时长”。比如应用偶尔会发生一次 5 秒的 GC 停顿导致健康检查端点无响应那么 periodSeconds5failureThreshold3总时间窗口是 15 秒大于 5 秒不会被误杀。如果 periodSeconds10failureThreshold2总窗口是 20 秒也还行。关键是这个乘积要能覆盖最坏情况。二是“超时时间”要大于应用健康检查端点的 TP99 响应时间我一般取 2~3 倍甚至更大。比如 TP99800mstimeout2sTP992stimeout5s。同时健康检查端点自身响应要足够轻不能让探针流量本身影响应用性能。5.3 探针与发布流程的联动探针不只是运行时的健康管理工具它和发布流程是深度绑定的。滚动更新是否顺利很大程度上取决于探针能否正确反映新版本的就绪状态。这里有几个容易被忽略的点maxSurge 和 maxUnavailable 的配置要和探针就绪时间匹配。如果新版本启动慢而 maxSurge 设得很小滚动更新会在“等就绪”阶段卡住整体发布变慢。如果采用蓝绿发布或金丝雀发布readiness 探针的状态直接影响流量切分。可以结合 ReadinessGate 做更精细的灰度控制但基础前提仍然是探针本身准确。每次发版前检查新版应用的启动时间是否发生变化。依赖组件变多、数据量变大、初始化逻辑变复杂都会让启动变慢。如果 startupProbe 的 failureThreshold 不够发布当天才会发现容器一直重启。5.4 生产环境建议的探针参数参考值下面这套配置是我在多数场景下实践后认为比较稳妥的基线值可以直接复制改端口后用但务必根据你自己的应用响应特性再调startupProbe: httpGet: path: /health/startup port: 8080 periodSeconds: 3 timeoutSeconds: 2 failureThreshold: 40 successThreshold: 1 livenessProbe: httpGet: path: /health/live port: 8080 periodSeconds: 10 timeoutSeconds: 3 failureThreshold: 3 # liveness 的 successThreshold 固定为 1 且不建议调整 readinessProbe: httpGet: path: /health/ready port: 8080 periodSeconds: 5 timeoutSeconds: 3 failureThreshold: 3 successThreshold: 1实际项目中一些极端场景的参数差异很大。比如一个本身就要求秒级自动摘除的海量流量服务failureThreshold 可以缩到 1让第一次失败就摘流量而一个只做离线计算、流量抖动容忍度高的任务型容器periodSeconds 可以拉到 30 秒减少探针开销。参数本身没有“最佳”只有“适配”。5.5 探针运维的日常日志、Event 和监控最后聊聊探针的日常运维。排障时第一手信息来自 K8s 的 Event比如 kubectl describe pod 里能看到Liveness probe failed或Readiness probe failed这会告诉你失败的是哪种探针、失败了几次。但 Event 里看不到单次探测延迟想看这个得在 kubelet 侧采集探针耗时指标。我建议在监控体系里纳入这几项探针失败次数和失败率按探针类型分维度监控。探针单次请求耗时分布。如果耗时逐步上涨说明健康检查端点在变慢往往能提前预警依赖问题。容器重启次数和重启原因分类。频繁重启但业务日志无异常往往就是探针误杀。Pod 就绪状态变化次数。发布期间频繁变化说明就绪探针不稳定要检查依赖抖动。另外有一个使用习惯不要只在出问题时才看探针平时发完版本后花两分钟看一眼探针的成功率和耗时曲线能省下后续大量排查成本。探针不仅是 K8s 的“眼睛”也是你的“预警雷达”把它用好了很多线上事故都可以在用户感知前被自动消化掉。这套探针配置能力和故障排查思路我在多个模拟项目和真实生产环境里反复验证过核心结论始终一致探针配置没有银弹但一定有方法论。把语义拆对把参数调准把监控补上探针就是 K8s 里最值得信任的自动运维机制。现在回过头去检查你的 Deployment看看三个探针是不是各司其职、端点有没有拆开、超时时间够不够——这几分钟的检查很可能帮你避开一次凌晨三点的线上事故。