服务一直在 CrashLoopBackOff,可它根本没崩——是 k8s 的存活探针,在它启动还没完成时,就把它"杀"了
这是一个让我把"服务崩溃"的方向查了个遍、最后却发现"凶手是 k8s 自己"的诡异故障。我把一个服务部署到 Kubernetes 上,可它怎么都起不来——kubectl get pods 一看,状态永远是 CrashLoopBackOff(崩溃-重启循环);它启动一下、过几十秒就被杀掉、然后重启,周而复始,永远进不了正常运行的状态。
我第一反应是:"服务崩溃了?"于是我查应用日志、查内存、查依赖,想找出它"崩溃"的原因。可奇怪的是,应用日志里,根本没有任何崩溃、报错、异常的痕迹——日志显示,它正在正常地、不紧不慢地启动:加载配置、连接数据库、初始化缓存、预热数据……这个服务比较"重",完整启动一次,要40 多秒。可日志才打到一半(启动了二十几秒),就戛然而止、然后是一条重启的记录。我一脸困惑:它明明没崩,只是启动得慢,为什么会一直 CrashLoopBackOff?直到我去看了 kubectl describe pod 的事件,才揪出了那个出人意料的真凶——是 Kubernetes 的"存活探针(liveness probe)",把我的服务给"杀"了!我给这个服务配了一个存活探针,让 k8s 每隔一段时间,就来探测一下"服务还活着吗"。可问题是,我把探针的"初始延迟(initialDelaySeconds)"设得太短了(比如 10 秒)——也就是说,服务才启动 10 秒、还远没有启动完成(它要 40 多秒呢),k8s 的存活探针就迫不及待地来探测了;而此时服务还没起好、探测端口还不通,探针就判定"这个服务不健康/没活着",于是把它杀掉、重启。重启后,又是同样的循环——启动到一半、被探针误杀、重启……我的服务,就这样被一个'太心急'的存活探针,在它'还没起好'的时候反复'误杀',永远地困在了 CrashLoopBackOff 里。它不是'崩溃'了,是被'冤杀'了。
故障现场:启动还没完成,就被探针判了"死刑"
我把出问题的 k8s 配置,简化一下。问题就藏在那个"太心急"的存活探针上:
# 我的 Deployment 配置(有问题的版本)
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 10 # ← 致命: 才等 10 秒, 就开始探测!
periodSeconds: 5 # 每 5 秒探测一次
failureThreshold: 3 # 连续 3 次失败, 就判定"死了", 杀掉重启
# 故障时序:
# 0秒: 容器启动, 应用开始初始化(它要 40+ 秒才能起好)
# 10秒: 存活探针开始探测 /health (但应用还没起好, 端口还不通!)
# 10秒: 探测失败 (第1次)
# 15秒: 探测失败 (第2次)
# 20秒: 探测失败 (第3次) → 达到 failureThreshold=3!
# 20秒: k8s 判定"这个容器死了", 杀掉它、重启!
# → 可是! 应用其实只是"还没启动完"(它需要40+秒), 根本没死!
# → 重启后, 又是同样的循环: 启动到20秒被杀 → 重启 → 又被杀 ...
# → 永远 CrashLoopBackOff! 永远起不来! (被存活探针"冤杀")看清这个时序,我才明白我的服务是怎么被"冤杀"的。问题的核心,在于我那个"存活探针(liveness probe)"的initialDelaySeconds(初始延迟),设得太短了——它和我服务的真实启动时间,严重地不匹配。我的服务,完整启动需要 40 多秒;可我给探针设的初始延迟只有 10 秒。这意味着,容器启动后,才过了 10 秒,k8s 的存活探针,就迫不及待地开始来探测 /health 端点了——可这时候,我的服务还远远没有启动完成,那个 /health 端点根本还没准备好、端口还不通呢!于是,探测自然失败了;探针又按 periodSeconds=5 每 5 秒探一次,连续探了 3 次(到第 20 秒),全部失败,达到了 failureThreshold=3 这个"判定死亡"的阈值。于是,k8s 就错误地判定:"这个容器已经死了!"——把它杀掉、重启。可问题是,我的服务根本没死,它只是"还没启动完"(它就需要 40 多秒嘛)!被杀掉重启后,新的容器又从 0 开始启动,又是启动到 20 秒、又被那个'太心急'的探针、在'还没起好'的时候,判定为'死亡'、再次杀掉……这就形成了一个永远跳不出的死循环:启动 → 没起好就被探针误杀 → 重启 → 又启动到一半被误杀……我的服务,就这样,被一个'还没给够它启动时间、就急着判它生死'的存活探针,反复地、冤枉地'杀死',永远地卡在了 CrashLoopBackOff 这个状态里。它从头到尾,一次都没有真正'崩溃'过;它只是,从来没被给过'足够把自己启动完'的时间,就被一次次地'冤杀'了。我那场"查遍了崩溃原因、却发现它根本没崩"的诡异故障,根源,正是这个被我随手设短了的 initialDelaySeconds。
第一件事:搞懂存活探针(liveness)和就绪探针(readiness)的区别
定位到根源,我必须把 k8s 的探针机制,尤其是"存活探针"和"就绪探针"这两个极易混淆的概念,彻底搞清楚:Kubernetes 提供了几种"探针(probe)",来探测容器的健康状况,从而进行自动化的管理。其中最重要、也最容易被混淆的两个,是"存活探针(liveness probe)"和"就绪探针(readiness probe)"——它们的目的、以及"探测失败后的后果",截然不同。
k8s 三种探针, 尤其是 liveness vs readiness 的区别:
# 1. 存活探针(liveness probe): 判断容器"是否还活着"
# - 探测失败的后果: 【杀掉容器、重启它】!
# - 用途: 检测容器是否"卡死/僵死"(进程在, 但已经不工作了), 重启来恢复。
# - 关键: 它的"失败惩罚"很重(杀掉重启), 所以绝不能"误判"!
# → 我的坑: 它在"启动还没完成"时误判, 把还在启动的容器杀了。
# 2. 就绪探针(readiness probe): 判断容器"是否准备好接收流量"
# - 探测失败的后果: 【把它从 Service 的负载均衡里摘掉】(不给它发流量), 但【不杀它】!
# - 用途: 启动慢/暂时繁忙时, 先别给它发流量, 等它就绪了再发。
# - 关键: 它的"失败惩罚"轻(只是不发流量), 不会杀容器。
# 3. 启动探针(startup probe, k8s 1.16+): 专门处理"启动慢"的容器
# - 在它成功之前, liveness/readiness 都【不会启动】(给足启动时间)。
# - 专门解决我这种"启动慢被 liveness 误杀"的问题!
# 核心区别:
# - liveness 失败 → 杀掉重启 (重, 用于"僵死后恢复")
# - readiness 失败 → 不发流量, 不杀 (轻, 用于"暂时没准备好")
# → 用错了, 或参数设错了, 后果天差地别(尤其 liveness 误判 = 反复重启)!原理终于清晰了。Kubernetes 的探针,目的是探测容器的健康、并据此自动化管理;而其中最重要、也最易混淆的两个——"存活探针(liveness)"和"就绪探针(readiness)"——它们的目的和"失败后果",截然不同。存活探针(liveness),判断的是容器"是否还活着";它探测失败的后果,是杀掉容器、重启它——它的用途,是检测容器是否"卡死/僵死了"(进程还在、但已经不工作了),然后通过重启来恢复;它的"失败惩罚"非常重(直接杀掉重启),所以它绝对不能"误判"!就绪探针(readiness),判断的是容器"是否准备好接收流量";它探测失败的后果,只是把容器从 Service 的负载均衡里摘掉(不给它发流量),但不杀它——它的用途,是在容器启动慢、或暂时繁忙时,先别给它发流量、等它就绪了再发;它的"失败惩罚"很轻。此外,还有一个专门为"启动慢"的容器设计的"启动探针(startup probe)"(k8s 1.16+):在它成功之前,liveness 和 readiness 都不会启动,从而给容器足够的启动时间——它正是为了解决我这种"启动慢被 liveness 误杀"的问题而生的。理解了这个核心区别(liveness 失败 = 杀掉重启,惩罚重;readiness 失败 = 不发流量,惩罚轻),我才明白我的错有多严重:我用了一个"失败惩罚极重(杀掉重启)"的存活探针,却给了它一个"远不够服务启动"的初始延迟,导致它在服务还没起好时就反复地、重重地"误杀"了它。用错探针类型、或设错探针参数,后果天差地别——尤其是 liveness 的误判,会直接导致这种反复重启的灾难。
第二件事:正解——用启动探针,或给存活探针足够的启动余量
搞懂了根因——"存活探针在服务还没启动完时就误杀了它"——正解就清晰了:核心是要"给服务足够的启动时间,别让存活探针在它启动期间就来'判生死'"。最佳方案,是用专门的"启动探针(startupProbe)";如果用不了,也要把存活探针的初始延迟和容忍度,设得足够大,覆盖服务的真实启动时间。
# 正解1(推荐, k8s 1.16+): 用 startupProbe, 专门处理慢启动
startupProbe:
httpGet: { path: /health, port: 8080 }
failureThreshold: 30 # 允许失败 30 次
periodSeconds: 5 # 每 5 秒一次 → 总共给 30*5=150 秒的启动时间!
# 在 startupProbe 成功之前, 下面的 liveness/readiness 都【不会启动】
livenessProbe:
httpGet: { path: /health, port: 8080 }
periodSeconds: 5 # startup 成功后才开始, 不用再操心启动慢了
readinessProbe:
httpGet: { path: /ready, port: 8080 }
periodSeconds: 5
# → startupProbe 给足启动时间(150秒); 启动完后, liveness 才接管 → 不会再误杀!
# 正解2(没有 startupProbe 时): 把 liveness 的初始延迟设够大
livenessProbe:
httpGet: { path: /health, port: 8080 }
initialDelaySeconds: 60 # ← 等 60 秒(大于服务启动的 40 秒)再开始探测
periodSeconds: 10
failureThreshold: 3
# → 缺点: initialDelaySeconds 是"死的"——设 60 秒, 那即使服务真的卡死了,
# 也要等 60 秒才发现。而 startupProbe 是"启动好了就立刻接管", 更灵活。
# 正解3: readiness 和 liveness 分开, 用不同的端点/逻辑
# - readiness(/ready): 检查"依赖是否就绪"(数据库连上了吗) → 控制流量
# - liveness(/health): 只检查"进程是否僵死"(简单的存活检查) → 控制重启
# 别让 liveness 去检查"复杂的依赖"(依赖抖一下, liveness 失败 → 把好好的容器杀了!)这套正解,都围绕"给服务足够的启动时间、别让存活探针误杀"展开,但各有侧重。正解1(startupProbe,推荐)是最优雅的:用专门的"启动探针",给一个很大的容忍度(比如 30 次失败 × 5 秒 = 150 秒的启动窗口)——在它成功之前,liveness 和 readiness 都不会启动;等服务真正启动完、startupProbe 成功了,liveness 才"接管"。这样,服务启动期间,绝不会被 liveness 误杀,而启动完之后,liveness 又能正常地履行"检测僵死、重启恢复"的职责。正解2(调大 initialDelaySeconds)是没有 startupProbe 时的退而求其次:把存活探针的初始延迟,设得大于服务的真实启动时间(比如服务要 40 秒,就设 60 秒);缺点是这个延迟是"死的"——设了 60 秒,那即使服务真的在第 5 秒就卡死了,也要等 60 秒才能被发现并重启,不如 startupProbe "启动好了就立刻接管"灵活。正解3(readiness 和 liveness 分开)则点出一个重要的最佳实践:别让 liveness 去检查"复杂的依赖"!liveness(/health)应该只做简单的"进程僵死检查";而"依赖(如数据库)是否就绪"这种检查,应该放在 readiness(/ready)里——因为如果你让 liveness 去检查数据库,那数据库稍微抖一下、liveness 失败,k8s 就会把你那个本来好好的容器给杀了重启(而重启根本解决不了数据库的问题)!一句话:慢启动用 startupProbe(或调大 liveness 延迟);liveness 只做简单存活检查、别查复杂依赖;依赖就绪检查交给 readiness。
下面这张图,对比了"liveness 误杀慢启动"和"startupProbe 保驾护航"两条路径:
这张图的对比很清楚:左边红色那条,只配 liveness 且初始延迟太短,服务还没起好就被探测、被判死亡、杀掉重启,陷入 CrashLoopBackOff;右边绿色那条,配 startupProbe 给足启动时间,启动期间 liveness 不启动,等服务真正启动完、startup 成功后,liveness 才接管正常检测,绝不误杀。两条路的根本分野,在于你有没有给服务"足够的、不被打扰的启动时间"。
第三件事:探针配置的其它"坑"
填平了"慢启动被误杀"这个坑,我把探针配置相关的其它常见坑,也一并梳理了一遍:
# 探针配置的其它常见坑:
# 坑1: liveness 探测的逻辑太"重"/太"复杂"
# - liveness 应该轻量、快速(就检查进程在不在、能不能响应)
# - 别在 liveness 里查数据库、调下游 —— 它们慢/挂了, 会让 liveness 失败 → 误杀!
livenessProbe:
httpGet: { path: /health } # /health 只做最简单的"我还活着"检查
# 坑2: liveness 和 readiness 用了【同一个】端点和逻辑
# - 它们目的不同(一个管重启, 一个管流量), 该用不同的检查!
# 坑3: 探针超时(timeoutSeconds)太短, 偶尔抖动就失败
livenessProbe:
timeoutSeconds: 1 # ← 1秒太短! 偶尔 GC 停顿就超时 → 误杀。设 3-5 秒更稳
# 坑4: failureThreshold 太小, 一次抖动就重启
failureThreshold: 1 # ← 太敏感! 一次失败就杀。设 3 次, 容忍偶尔抖动
# 坑5: 探针打到的端点, 自己有 bug / 依赖了会挂的东西
# - 健康检查端点本身要简单可靠, 别让它成为新的故障源
# 坑6: 没配 readiness, 流量在服务"还没就绪"时就打进来 → 报错
# - 启动慢的服务, 一定要配 readiness, 没就绪就别让流量进来
# 核心: 探针是"自动化运维"的好工具, 但它"自动地杀/不发流量",
# 所以配错了, 它会"自动地"帮倒忙 —— 误杀、或放错误流量进来。这一梳理,让我对探针配置有了全面的警觉。探针是 k8s 强大的"自动化运维"工具,但正因为它会"自动地"采取行动(杀容器、摘流量),一旦配错,它就会"自动地"帮倒忙。坑1、2(liveness 太重/和 readiness 混用):liveness 应该轻量(只查进程存活),别让它查数据库、调下游(那些慢/挂了会让 liveness 失败、误杀容器);liveness 和 readiness 目的不同(一个管重启、一个管流量),该用不同的检查逻辑。坑3、4(超时/阈值太敏感):timeoutSeconds 太短(如 1 秒),偶尔一次 GC 停顿就超时、误杀;failureThreshold 太小(如 1 次),一次网络抖动就重启——这些都要设得宽容一些,容忍偶尔的抖动。坑5(健康端点自身有问题):探针打到的健康检查端点,本身要简单可靠,别让它依赖会挂的东西、成为新的故障源。坑6(没配 readiness):启动慢的服务不配 readiness,流量会在它"还没就绪"时就打进来、导致报错。这些坑共同说明:配探针,不是'随便填几个数字'——你要深刻理解每个探针的'职责'、它'失败后的自动行为',以及各个参数(初始延迟、周期、超时、阈值)和你服务'真实行为'的匹配。配好了,探针是帮你自动恢复、自动调度流量的好帮手;配错了,它就是一个会'自动误杀你服务、或放错误流量进来'的、自动化的麻烦制造者。
第四件事:三种探针,各司其职——一张"配置心法"
这次踩坑,逼着我把 k8s 三种探针的"正确用法",系统地理了一遍。我把它们各自的职责、该检查什么、配置要点,总结成了一套"配置心法":
# k8s 三种探针的"配置心法": 各司其职
# === startupProbe(启动探针): 负责"保护启动过程" ===
startupProbe:
httpGet: { path: /health, port: 8080 }
failureThreshold: 30 # 给足启动时间(failureThreshold * periodSeconds)
periodSeconds: 5 # 比如 30*5=150秒, 覆盖最慢的启动
# 职责: 在它成功前, 屏蔽 liveness/readiness, 给服务"不被打扰的启动时间"
# 检查: 服务的基本端口/端点是否起来了
# 谁需要: 启动慢的服务(比如要预热、要建很多连接的)
# === livenessProbe(存活探针): 负责"重启僵死的容器" ===
livenessProbe:
httpGet: { path: /health, port: 8080 }
periodSeconds: 10
timeoutSeconds: 3
failureThreshold: 3 # 容忍偶尔抖动, 别太敏感
# 职责: 检测"进程僵死"(还活着但不工作了), 失败就重启来恢复
# 检查: 要【轻量、简单】! 只检查"进程能不能响应", 别查复杂依赖!
# 谁需要: 几乎所有服务(但要配对, 别误杀)
# === readinessProbe(就绪探针): 负责"控制流量" ===
readinessProbe:
httpGet: { path: /ready, port: 8080 }
periodSeconds: 5
failureThreshold: 3
# 职责: 判断"能不能接流量", 没就绪/暂时繁忙就不发流量(但不杀)
# 检查: 可以检查"依赖是否就绪"(数据库连上了吗、缓存热了吗)
# 谁需要: 所有对外提供服务的(尤其启动慢、或依赖多的)
# 配置心法总结:
# startup 保护"启动" → livenes 负责"重启" → readiness 负责"流量"
# 三者配合: 启动期 startup 罩着, 启动后 liveness 守着、readiness 调度流量。这套"配置心法",让我对 k8s 三种探针的协作,有了清晰的全局图景。它们三个,各司其职、相互配合,共同管理着一个容器从"启动"到"运行"再到"出故障"的整个生命周期:startupProbe(启动探针)负责"保护启动过程"——在它成功之前,屏蔽掉 liveness 和 readiness,给服务一段"不被打扰的、足够的启动时间";它专为"启动慢"的服务而设。livenessProbe(存活探针)负责"重启僵死的容器"——在服务启动之后,持续检测它是否"僵死了"(进程还在、但不工作了),一旦确认僵死就重启来恢复;它的检查要轻量、简单(只查进程能不能响应),绝不能查复杂依赖(否则会误杀)。readinessProbe(就绪探针)负责"控制流量"——判断容器"能不能接收流量",在它没就绪或暂时繁忙时,把它从负载均衡里摘掉(不发流量、但不杀);它可以检查"依赖是否就绪"。三者配合的完整图景是:'启动期,startupProbe 罩着(给足启动时间);启动后,liveness 守着(检测僵死、重启恢复)、readiness 调度流量(就绪了才发流量)'。我那次的坑,本质上是让一个'负责重启'的 liveness,越俎代庖地去管了'启动过程'(而它根本不该、也没能力管好这个),又因为参数没配对,把'还在启动的服务'当成'僵死的服务'给重启了。理解了三种探针'各司其职'的分工,把'保护启动'交给 startup、'重启僵死'交给 liveness、'控制流量'交给 readiness,你才能正确地、协调地用好这套强大的自动化运维机制。把三种探针的职责对比整理成一张表:
| 探针 | 职责 | 失败后果 | 检查什么 |
|---|---|---|---|
| startupProbe | 保护启动过程 | 启动超时才重启 | 基本端口起来没 |
| livenessProbe | 重启僵死容器 | 杀掉重启(重!) | 轻量, 进程是否僵死 |
| readinessProbe | 控制流量 | 不发流量(轻) | 依赖是否就绪 |
第五件事:自动化是把双刃剑——它会"自动地"做对,也会"自动地"做错
这次踩坑,在更高的层面给了我一个关于"自动化"的深刻反思。我把这个反思,沉淀了下来:
关于"自动化运维"的深刻反思: 它是把双刃剑
# 自动化的好: 它能"自动地"帮你做正确的事
# - liveness 自动重启僵死的容器(不用人半夜爬起来重启)
# - readiness 自动把没就绪的实例摘掉流量
# - HPA 自动扩缩容、k8s 自动调度 ...
# → 极大地解放了运维, 让系统能"自愈"、自管理。
# 自动化的险: 它也会"自动地"帮你做错误的事
# - 配错了的 liveness, 会"自动地"反复误杀你好好的服务(本文!)
# - 配错了的 HPA, 可能"自动地"无限扩容、烧钱
# - 配错了的自动清理, 可能"自动地"删了不该删的数据
# → 自动化, 会"忠实地"执行你给它的规则, 哪怕规则是错的!
# 而且它"自动地"执行, 往往比人手动出错, 更快、更大规模、更难察觉。
# 用好自动化的关键:
# 1. 深刻理解每个自动化机制的"行为"——它在什么条件下, 会自动做什么?
# 2. 谨慎地配置它的"规则/参数"——因为它会忠实地按规则自动执行。
# 3. 给自动化加"护栏"——上限、确认、灰度、可观测, 防它自动闯大祸。
# 4. 监控自动化的"行为"——它自动做了什么? 做对了吗?
核心: 自动化, 放大了你的"意图"——
你的意图(配置)对, 它就自动地、高效地, 帮你把对的事做好、做大;
你的意图(配置)错, 它也会自动地、高效地, 帮你把错的事做错、做大。
所以, 配置自动化, 要格外审慎 —— 因为它会"忠实地、自动地"放大你的对与错。这层反思,是这次踩坑给我最高维度的收获。k8s 的探针,是一种强大的"自动化运维"机制;而这次踩坑让我深刻地认识到:自动化,是一把"双刃剑"——它既会"自动地"帮你做对的事,也会"自动地"帮你做错的事。自动化的好显而易见:liveness 自动重启僵死的容器(不用人半夜爬起来)、readiness 自动摘掉流量、HPA 自动扩缩容……它极大地解放了运维、让系统能"自愈"。可自动化的险,同样深刻:一个配错了的 liveness,会"自动地"反复误杀你好好的服务(正是我这次的遭遇!);一个配错了的自动清理,可能"自动地"删了不该删的数据。自动化,会"忠实地"执行你给它的规则——哪怕那个规则是错的;而且,它"自动地、高效地"执行,往往比人手动出错,更快、更大规模、更难察觉。所以,用好自动化的关键在于:深刻理解每个自动化机制的"行为"(它在什么条件下会自动做什么)、谨慎地配置它的"规则/参数"(因为它会忠实地照着自动执行)、给自动化加上"护栏"(上限、确认、灰度、可观测)、并监控自动化的"行为"。而这一切的核心,是一个深刻的认识:自动化,放大了你的"意图"——你的意图(配置)对,它就自动地、高效地,帮你把对的事做好、做大;你的意图(配置)错,它也会自动地、高效地,帮你把错的事做错、做大。所以,配置自动化,必须格外审慎——因为它会'忠实地、自动地'放大你的每一个对与错。我那次,正是用一个'错误的探针配置(意图)',让 k8s '自动地、忠实地'帮我把'误杀服务'这件错事,反复地、高效地干了一遍又一遍。把"自动化的好"与"自动化的险"对照成一张表:
| 维度 | 自动化的好 | 自动化的险 |
|---|---|---|
| 对的配置 | 自动高效地做对事 | — |
| 错的配置 | — | 自动高效地做错事 |
| 速度规模 | 快速大规模地正确 | 快速大规模地犯错 |
| 可察觉性 | 解放人力 | 错得更隐蔽难察觉 |
| 该有的态度 | 充分利用 | 审慎配置+加护栏+监控 |
一张"k8s 探针该怎么配"的决策图
把这次踩坑沉淀成一张图。每当你给一个服务配 k8s 探针时,照着它走:
这张图的核心:启动慢就配 startupProbe 给足启动时间;liveness 只做轻量的进程存活检查(别查复杂依赖,否则会误杀);依赖就绪检查交给 readiness;超时/阈值设宽容点。把"三种探针各司其职、参数匹配服务真实行为"变成本能,那个"被探针误杀、CrashLoopBackOff"的坑就再也碰不到你。
我立下的几条 k8s 探针规矩
这次"被存活探针误杀、CrashLoopBackOff"的事故后,我给自己立了几条规矩:
- 慢启动用 startupProbe:启动慢的服务配 startupProbe,给足启动时间,绝不让 liveness 在启动期误杀。
- liveness 只做轻量检查:存活探针只检查"进程是否僵死",轻量简单,绝不查数据库等复杂依赖。
- 依赖检查归 readiness:"依赖是否就绪"的检查放 readiness,它失败只摘流量不杀容器。
- 探针参数匹配真实行为:初始延迟、超时、阈值都要匹配服务的真实启动时间和响应特性,留足余量。
- 超时/阈值别太敏感:timeoutSeconds 设 3-5 秒、failureThreshold 设 3 次,容忍偶尔抖动。
- 分清三种探针职责:startup 保护启动、liveness 重启僵死、readiness 控制流量,各司其职。
- 给自动化加护栏并监控:理解探针的自动行为,部署后用 describe pod 验证没被误杀,监控重启次数。
这几条里,第一条和第二条是直接根治这次 bug 的核心。而贯穿所有规矩的那条主线,是对"自动化机制行为"的深刻理解。我这次栽跟头,根子上是我对 k8s 探针这个"自动化机制",理解得太肤浅了——我只知道"配个探针能做健康检查",却不清楚"存活探针失败会自动杀容器""它和服务启动时间如何配合""它和就绪探针有何区别"这些它真实的、自动的行为。正因为不理解它的'自动行为',我才会给它配上一个'会自动误杀我服务'的错误参数,却浑然不觉。这再次印证了用好任何自动化机制的根本前提:你必须深刻地理解它'会在什么条件下,自动地做什么'——因为自动化机制,会'忠实地、不打折扣地'按你的配置自动行动,你对它行为的任何一点误解或疏忽,都可能被它'自动地'放大成一场真实的故障。理解自动化的行为、并据此审慎地配置它,是驾驭一切自动化机制的关键。
写在最后:把权力交给自动化之前,先真正理解它
这次被 k8s 探针"冤杀"服务的经历,给我一个在这个"一切皆自动化"的时代尤其重要的启示:我们正越来越多地,把各种'决策权'和'执行权',交给自动化的系统——让自动化的探针决定'要不要重启一个容器'、让自动化的扩缩容决定'要不要增减实例'、让自动化的流水线决定'要不要发布上线'、让自动化的算法决定'要不要通过一笔交易'……自动化,极大地提升了效率;可与此同时,我们也必须清醒地意识到:每当我们把一项'决策/执行权',交给一个自动化系统时,我们就必须确保,我们真正、深刻地理解了'这个系统,会在什么情况下、做出什么样的自动决策与行动'——因为一旦交出了权力,它就会'自动地、不容商量地'去执行,而它执行的对错,完全取决于我们当初对它的理解和配置是否正确。我把"要不要重启容器"这个权力,交给了 k8s 的存活探针;可我并没有真正理解它的行为(它会在服务还没启动完时就来判生死),于是,它就"自动地"用一个我没预料到的方式(反复重启),把事情办砸了。
想通这一点,我对"向自动化交权"这件事,生出了一份审慎的敬畏。把权力交给自动化,本质上,是一种'信任'——你信任这个自动化系统,会按你期望的方式,正确地行使你交给它的权力。可这份信任,必须建立在'真正理解'的基础上,而非'想当然的乐观'之上。一个负责任的工程师,在把任何一项权力交给自动化之前,都会先扪心自问:我真的理解这个自动化系统的行为吗?它会在哪些边界情况下,做出我没预料到的决策?如果它'自动地'做错了,后果有多严重?我有没有给它加上必要的'护栏'(上限、确认、灰度),来限制它万一做错时的破坏?越是把'重要的、后果严重的'权力(比如删数据、发布上线、自动交易)交给自动化,这份'交权前的深刻理解与审慎设防',就越是不可或缺。因为自动化的效率,是一柄双刃剑——它能'自动地'把对的事高效地做好,也能'自动地'把错的事高效地做砸;而我们能不能驾驭这柄双刃剑,关键就在于,我们在向它交权之前,有没有真正地理解它、并为它可能的'自动犯错',做好了周全的防护。
所以,如果你也在这个时代,越来越多地与各种自动化系统打交道、向它们交付权力,我想把这次踩坑最想说的话送给你:在把任何一项决策或执行的权力,交给一个自动化系统之前,请先确保你'真正、深刻地理解了它的行为'——它会在什么条件下,自动地做什么;并为它'万一自动做错'的可能,加上必要的护栏与监控。别因为自动化'方便''高效',就轻率地、不求甚解地,把重要的权力交出去;要带着一份审慎,去理解它、去配置它、去为它设防。因为自动化系统,是你意图的'忠实而高效的执行者'——它会把你的对,高效地放大成更大的对;也会把你的错,高效地放大成更大的错。而决定它最终是'你的得力助手'还是'你的麻烦制造者'的,正是你在向它交权之前,对它理解得有多深、为它防范得有多周。那个'冤杀'了我服务的存活探针,最终教给我的,正是这份'向自动化交权前,先真正理解它'的审慎——它让我懂得,在这个把越来越多权力交给自动化的时代,真正的智慧,不是'盲目地信任自动化的高效',而是'在深刻理解的基础上,审慎地、有护栏地,去借用自动化的力量';唯有如此,我们才能既享受自动化带来的巨大效率,又不至于,被我们亲手交出去的、却没真正理解的那份权力,反过来,'自动地'伤害到自己。
—— 别看了 · 2026