健康 · XB 现场笔记

Consul 发现结果取决于健康策略与新鲜度

Thu, 06 Apr 2028 00:00:00 +0000

Consul 服务发现提供注册端点和已经记录的健康观测，不能承诺每个返回端点都会成功响应调用方的下一次请求。实用的运维模型需要分开四件事：注册了什么、哪些检查与该实例有关、查询接受哪些状态，以及这些观测可能已经过去多久。仅仅成功解析到一个地址，并没有自动建立上述全部保证，也没有证明业务请求已经能够完成。

注册记录与健康状态是两回事

catalog 存储注册信息，健康端点再附上检查结果。不加过滤的 /v1/health/service/web 响应，可以包含检查为 critical 的实例。检查失败并不会自动抹去服务注册；显式注销、配置了持续 critical 后自动移除，属于不同的生命周期机制。ACL 也可能影响读者能看到哪些记录，所以查询里缺少实例，不能只归因于健康检查失败。

注册的检查通常从 critical 开始，除非显式提供初始状态。但这并不意味着每个注册服务都一定具有有意义的就绪检查。判断某个服务实例时，需要结合它自己的服务级检查，以及 serfHealth 等节点级检查。同一节点上，数据库服务的检查失败，不会自动让不相关的 Web 服务检查失败；节点级检查变为 critical，则会影响该节点上的服务。不要把“相关检查全部通过”误解成“这台机器上的所有服务检查都必须通过”。

检查结果也不只是布尔值。脚本退出码零表示 passing，一表示 warning，其他退出码表示 critical；HTTP 检查把成功的 2xx 视为健康，把 429 视为 warning，其他响应表示失败。这些状态究竟证明了什么，仍取决于探测内容。TCP 握手成功或进程存在，并不证明应用能完成一次真实请求；检查实现必须与希望验证的能力对应。

DNS 并非总是只返回 passing

HTTP 健康端点的 passing=true 要求相关检查全部 passing。Consul DNS 服务查询的默认策略不同：warning 实例仍可符合候选条件，critical 实例则被排除。配置 dns_config.only_passing=true 后，warning 也会被排除。因此，一个 warning 实例出现在 DNS，却不在 passing-only API 结果里，不一定意味着检查失效，也可能只是两条路径明确采用了不同策略。

比较结果时，应保持服务、数据中心、适用时的命名空间，以及观察时间窗口一致。Consul 的 DNS 通常监听 8600 端口；如果没有配置相应转发，只向系统解析器查询，并不是直接检查 Consul。直接查询能够去掉这一中间环节，但仍然不会自动从调用方网络探测业务端点，也不能证明返回地址在所有网络路径上都可达。

新鲜度包含多个阶段

探测间隔、探测超时、连续失败阈值、agent 到 server 的传播、读取一致性，以及客户端缓存，都可能增加延迟。三十秒间隔不等于端到端三十秒内必定摘除。TTL 检查从最近一次更新计算到期；如果服务在 TTL 中途失败，并不一定还会获得完整的一段新 TTL。应观察真实状态转移，不能把一个配置数字当成所有故障路径的精确上界。

反熵负责修复 agent 本地状态与 catalog 的差异。文档中的周期随集群规模变化，而且是近似间隔；注册变更本身也会触发更新。如果同步持续失败，差异可以跨越多个周期，因此周期同步既不是唯一更新机制，也不是最长收敛时间的保证。网络不可达、权限错误或存储故障，不会因为下一分钟到来就必然消失。

HTTP 查询通常使用 default 一致性模式，DNS 通常允许 stale 读取。consistent HTTP 读取要求 leader 向多数派确认身份，会付出额外代价。然而，更强的 catalog 读取一致性，也无法发现尚未被任何检查观测到的应用故障。注册状态的一致性与真实业务的就绪程度，始终是不同问题，不能互相替代。

坏掉的样子

passing 探测可能检查了错误依赖、从不同网络发起，或者遗漏死锁。反过来，如果每个实例的就绪状态都绑定到同一个共享依赖，共同故障又可能一次摘除整个池。应围绕可用的请求能力和预期降级行为选择检查，同时保留客户端超时及有界恢复路径，不能把注册表当成消除所有请求失败的机制。

不要根据一张 API 与 DNS 不一致的截图就宣布检查没有运行。先检查 warning 策略、相关检查 ID、ACL 可见性、注销行为，以及缓存或陈旧观测。critical 实例继续出现在未过滤的健康响应里，本来就是正常现象，不是服务器忽略过滤条件的证据。只有先确认比较对象与策略，才有依据继续追查异常。

快速验证

把代码保存为 consul_filter.py，执行 python3 consul_filter.py。这个标准库实验使用合成记录，不启动 Consul agent，不发网络请求。它验证筛选差异和陈旧快照风险，并不是 Consul 运行时实现的集成测试。

from copy import deepcopy

nodes = {"n1": "passing", "n2": "critical"}
services = [
 {"ID": "web-1", "Name": "web", "Node": "n1", "Status": "passing"},
 {"ID": "web-2", "Name": "web", "Node": "n1", "Status": "warning"},
 {"ID": "db-1", "Name": "db", "Node": "n1", "Status": "critical"},
 {"ID": "web-3", "Name": "web", "Node": "n2", "Status": "passing"},
]


def health_rows(name):
 # Synthetic snapshot: only the node and THIS service contribute checks.
 return [
 {"ID": item["ID"], "Checks": [nodes[item["Node"]], item["Status"]]}
 for item in services if item["Name"] == name
 ]


def selected(rows, allowed):
 return [row["ID"] for row in rows if all(s in allowed for s in row["Checks"])]


snapshot = health_rows("web")
assert [row["ID"] for row in snapshot] == ["web-1", "web-2", "web-3"]
assert selected(snapshot, {"passing"}) == ["web-1"]
assert selected(snapshot, {"passing", "warning"}) == ["web-1", "web-2"]
print("unfiltered: web-1 web-2 web-3; passing-only: web-1; default DNS policy: web-1 web-2")

previous = deepcopy(snapshot)
services[0]["Status"] = "critical"
current = health_rows("web")
assert selected(previous, {"passing"}) == ["web-1"] # An old snapshot stays old.
assert selected(current, {"passing"}) == []
assert len(current) == 3 # Failing health is not deregistration.
assert selected(current, {"passing", "warning"}) == ["web-2"]
print("service failure changes selection, not registration; an old snapshot still selects web-1")

nodes["n1"] = "critical"
assert selected(health_rows("web"), {"passing", "warning"}) == []
print("node failure excludes both web instances on n1; db-1 never controlled their earlier health")

断言证明不相关的数据库健康不会控制 Web 选择，warning 与 critical 在两种策略下不同，而失败注册仍保留在未过滤视图中。更新当前状态，也不会改写之前复制的快照。最后将节点状态改为 critical，模型会把该节点上的两个 Web 实例都移出符合 DNS 策略的候选集合。这些结果是确定的集合运算，不是实际测得的服务故障摘除延迟。

部署验收仍需在配置的 warning 策略下，对照真实未过滤与 passing-only 健康响应，以及直接 DNS 查询。分别记录检查状态转换和客户端不再使用实例的时刻。本次没有执行这项集成；离线模型没有提供探测时间测量、DNS 报文证据或可用性保证。把模型的适用范围写清楚，才能避免“断言都通过”掩盖尚未验证的运行链路。

来源

Consul Health API，服务实例、检查、passing 过滤和 ACL 可见性，已核验 2026-10-15。
Consul 健康检查，初始状态、脚本及 HTTP 结果与 TTL 到期，已核验 2026-10-15。
Consul DNS 配置，only_passing 与相关检查，已核验 2026-10-15。
Consul DNS 行为，8600 端口和缓存控制，已核验 2026-10-15。
Consul 一致性，agent 更新及近似反熵周期，已核验 2026-10-15。
Consul 一致性模式，HTTP、DNS 默认模式和多数派确认，已核验 2026-10-15。
Consul 健康检查参考，超时、阈值和 critical 服务注销，已核验 2026-10-15。

liveness 与 readiness 告诉 Kubernetes Pod 的状态

Wed, 14 Jul 2027 00:00:00 +0000

慢启动不等于进程已死：readiness 负责遮挡流量，liveness 只负责让进程活着。把两者搞混是最常见的健康检查错误。团队把同一个接口同时接进两种探针，于是每个变慢的依赖都变成重启循环——应用需要时间，存活探针偏不给，Pod 恰恰死在本来再忍一会儿就能活的关口。两种探针并存，因为"没就绪"和"已死"要的是相反的动作：一个要时间，一个要重启。

防混的心智模型是医院分诊。就绪探针是分诊护士，决定谁现在能看医生；存活探针是抢救车，只在病人心跳停了才推出来。没人会因为坐在候诊区就给人除颤。记住这个画面，探针配置几乎不用想就写对了。

Readiness 把流量挡在门外

连续 readiness 失败达到阈值，会让 Pod 失去普通 Service 路由资格，但 Pod 仍在运行，好让进程完成热身或自行恢复。端点条件与数据路径在失败、恢复两个方向都异步收敛；已有连接和 Pod 直连需要分别考虑。就绪失败不直接触发探针重启，却可能移除全部服务容量，不能无条件称为安全：缓存可以慢慢热，迁移可以跑完，下游依赖可以回来，全程不丢 Pod 的内存状态，也不付重启的代价。

就绪接口要围绕真正的可服务性设计，而不是进程存在性。检查那些决定这个 Pod 此刻能否正确回答的东西：结构迁移是否应用、必需的缓存是否装满、关键下游是否可达。只检查"服务能响应"的就绪探针，会把注定失败每个请求的 Pod 放进流量——比不检查还糟，因为负载均衡器是信任它的。但也别把所有依赖都塞进去：非关键的推荐服务挂了，就绪失败等于为一件装饰品扔掉主干流量。

Liveness 守护进程本身

liveness 探针连续失败达到阈值会终止容器，是否重启遵循重启策略，这是结束僵死状态的最后一招。它要处理的该是"进程卡死"这类问题，而不是容器只是暂时还没就绪。合格的目标很窄：死锁——此后任何请求都不会再成功；协程或线程泄漏到只有新进程能清；内存状态损坏到任何重试都救不回来。每种情况的共同点是不可逆：不重启就不可能恢复，而不只是恢复得慢。

这个门槛意味着很多服务应该只配极简的存活探针，甚至不配。把存活检查打到外部数据库上，每次数据库抖动都会变成全集群的重启风暴，还顺手毁掉本可以加速恢复的热缓存。优先用廉价的本地检查——主循环定时刷新的看门狗时间戳——不问进程之外的任何东西，只回答"这个进程是不是卡死了"。崩溃之后是否重启，取决于容器重启策略；存活探针则能在普通退出之前识别选定的不可恢复本地故障。

给探针留足余量

把 initialDelaySeconds 设到足够大，别把冷启动误判成崩溃；timeout 也要配合真实工作量。把两类探针分开，让慢的 Pod 由 readiness 护住，而不是被 liveness 误回收。启动慢的容器最好再加一个启动探针：它成功之前，存活与就绪探针都保持关闭，于是需要预热大缓存的版本升级能拿到几分钟而不是几秒，稳态的存活检查强度一点不减。

失败阈值按观测到的行为调，别在服务之间抄整数。检查周期乘以失败次数只是规划估计，不是真实反应时间保证。探针所处周期、超时、调度、终止宽限与重启退避都会改变时间线；就绪端点变化与已有连接也并非在同一瞬间全部完成。量出冷启动的分位耗时、依赖恢复时间、最坏的回收停顿，再定每个数字：比告警快，比噪声慢。

坏掉的样子

标志性故障是依赖故障期的重启循环：数据库变慢，本来就绪探针就够了，但存活探针共用同一个失败的接口，全集群一波波重启。每次重启清空热缓存，下一波恢复更慢，系统无限振荡。诊断看重启时间戳与依赖事故是否对齐；修法是拆接口——就绪查依赖，存活只查进程——让生病的下游只挡流量，不杀 Pod。

镜像故障是僵尸 Pod：服务能响应所以存活探针通过，但请求全卡在死锁的工作池后面。流量源源不断送进一个什么都不回答的 Pod。修法是让存活接口走真实路径——带短超时申请一个工作槽、确认没有客户端请求时仍会刷新的本地进度心跳保持新鲜——卡死能失败探针，单纯慢则不失败。

快速验证

检查探针接线与最近的杀戮记录：

kubectl get pod web-0 -o jsonpath='{.spec.containers[*].livenessProbe}{"\n"}{.spec.containers[*].readinessProbe}{"\n"}'
kubectl get events --field-selector reason=Unhealthy --sort-by=.lastTimestamp | tail -n 10
kubectl describe pod web-0 | grep -A3 -i 'liveness\|readiness'

这些未改动的诊断本轮没有重新执行。若语义适合两项决策，共用 URL 并不天然错误。Unhealthy 事件包含探针失败，不能证明发生了杀进程；需要关联具体 Pod、容器重启计数和终止原因。带期限的检查必须区分死锁、暂时负载及没有业务请求的正常空闲，不能用一次失败代替完整故障判断。

来源

Kubernetes 探针，liveness 与 readiness 官方文档，已核验 2026-10-15。
配置存活与就绪探针，探针配置任务指南，已核验 2026-10-15。

探针告诉平台何时出手

Fri, 18 Jun 2027 00:00:00 +0000

探针结果是控制循环使用的证据，不是平台对应用健康的直接理解。Kubernetes 不会从 healthz 这个路径名称推断你希望怎样恢复服务；真正决定下一步的是探针类型、结果、阈值与容器生命周期。把每次失败都描述成“重启 Pod”，会抹掉直接影响可用性的关键区别。

三个问题，对应不同动作

启动探针为初始化提供独立的检测政策。配置后，在它成功之前，存活和就绪探针都不会执行。启动探针成功后，在当前容器生命周期内便不再持续检查；如果容器重新启动，则需要再次通过启动阶段，不能把上一次成功沿用到新生命周期。

存活检查用于识别适合通过重启当前容器恢复的状态。达到失败阈值后，kubelet 终止受到影响的容器，并应用对应的重启政策。这不是保证重建整个 Pod、改变其身份或修复外部数据库，也不意味着容器之间的依赖与在途工作都能自动安全恢复。

就绪失败则让容器继续运行，并持续检查是否恢复。它影响通常按就绪状态选择目标的 Service 流量，但不是防火墙，也不会取消已经通过连接到达的请求。直接访问实例的客户端和现有连接，仍需要自己的生命周期处理，不能把就绪状态误读成网络阻断保证。

阈值统计连续观察结果

failureThreshold 为三，不是从启动以来累计失败三次就动作，而是连续失败达到三次；一次成功会打断这段失败序列。就绪恢复可以要求多次连续成功，而启动和存活探针的 successThreshold 必须为一。阅读结果轨迹之前，应先明确进入失败和恢复成功两个方向的阈值。

超时、初始延迟、执行周期和终止宽限期同样影响实际表现。阈值乘周期可以辅助估算，但不能当成端到端故障切换的精确秒表；调度、探针执行和路由传播都参与其中。容器尚未就绪时，就绪探针还可能比配置周期更频繁地执行，以便更快恢复就绪。

实验选择四次启动失败、三次存活失败、两次就绪失败，并要求连续两次就绪成功才能恢复。这组数字只是为了看清不同计数器的边界，不是生产推荐。真实门槛应结合启动时间、检查成本、错误恢复方式以及误判代价确定，不能照搬实验参数。

检查机制决定你拿到了什么证据

HTTP 检查使用文档定义的 200 至 399 成功范围。即使响应正文写着“内部错误”，返回 200 也不会因为人类读出了坏消息，就自动变成失败探针。应沿实际探测路径检查认证和重定向，而不是默认平台与交互式浏览器具有完全相同的访问结果。

TCP 探针证明的是连接可以打开，不是查询或事务能够完成。exec 检查则需要镜像里确实存在相应命令，并且退出状态有明确含义；频繁创建进程还会消耗节点资源。应该选择能够回答当前问题的低成本机制，而不是认为检查越复杂、调用越多就越可靠。

就绪成功并不是存活执行的前提。没有启动探针隔离时，初始化较长的应用可能还没来得及就绪，就因为存活失败反复被终止。相反，启动容忍窗口过大，也会推迟发现真正无法完成的启动。两边都需要依据实际启动分布和恢复目标权衡。

探针失败与 Unknown 结果不是同一种状态。Kubernetes 文档规定 Unknown 不改变容器状态，之后继续检查。本例只接受成功与失败两个值，故意没有第三种结果，所以无法预测传输错误会如何分类。实际排查应检查 kubelet 事件和部署中的探针处理机制，先确认错误属于哪类，再解释是否应计入连续失败。

坏掉的样子

把外部依赖可用性直接作为存活条件，可能在共享故障期间不断重启健康进程；另一个独立线程上始终绿色的处理器，又可能遗漏业务工作线程的死锁。重启并不天然便宜，它会中断在途工作、重复初始化，也可能进一步增加故障依赖的压力。

如果就绪涵盖每一项可选依赖，本来还能服务的容量也会被撤走；如果状态频繁抖动，负载会在副本之间来回转移，进一步恶化饱和。因此，既要测试明确故障能否被发现，也要测试误判和恢复行为，不能只看一次故障注入能不能把状态变红。

应对照探针结果、容器重启次数、事件记录、就绪变化和真实客户端流量，并确认部署中的配置与路由消费者。一个本地计数模型通过，不代表 kubelet、网络路径或负载均衡器已经正确执行同样规则。平台侧证据不能由应用侧自述替代。

快速验证

保存为 probe_policy_check.py，用 Python 3.10 以上版本执行 python3 probe_policy_check.py，本轮已在 Python 3.12.14 上重新运行。这个确定性模型接收成功或失败两个值，不部署 Pod，不调用 Kubernetes，不安排真实探测时间，也不会重启操作系统进程。

class ProbePolicy:
 # (consecutive successes, consecutive failures), chosen for this experiment.
 thresholds = {"startup": (1, 4), "liveness": (1, 3), "readiness": (2, 2)}

 def __init__(self):
 self.restart_requests = 0
 self.start_container()

 def start_container(self):
 self.started = self.ready = self.restart_requested = False
 self.successes = dict.fromkeys(self.thresholds, 0)
 self.failures = dict.fromkeys(self.thresholds, 0)

 def sample(self, kind, passed):
 if self.restart_requested:
 return "awaiting-restart"
 if kind != "startup" and not self.started:
 return "suppressed"
 if kind == "startup" and self.started:
 return "disabled"
 success_limit, failure_limit = self.thresholds[kind]
 self.successes[kind] = self.successes[kind] + 1 if passed else 0
 self.failures[kind] = 0 if passed else self.failures[kind] + 1
 if passed and self.successes[kind] >= success_limit:
 if kind == "startup":
 self.started = True
 elif kind == "readiness":
 self.ready = True
 if not passed and self.failures[kind] >= failure_limit:
 self.ready = False
 if kind != "readiness":
 self.restart_requested = True
 self.restart_requests += 1
 return "restart-requested" # A model output, not a kubelet or OS action.
 return "sampled"


policy = ProbePolicy()
for _ in range(3):
 assert policy.sample("startup", False) == "sampled"
 assert policy.sample("liveness", False) == "suppressed"
 assert policy.sample("readiness", True) == "suppressed"
assert policy.restart_requests == 0 and not policy.ready
assert policy.failures["liveness"] == 0 and policy.successes["readiness"] == 0
policy.sample("startup", True)
assert policy.started and not policy.ready
assert policy.sample("startup", False) == "disabled"
print("three startup failures do not trigger liveness; startup success enables the other probes")

policy.sample("readiness", True)
assert not policy.ready
policy.sample("readiness", True)
assert policy.ready
policy.sample("readiness", False)
assert policy.ready
policy.sample("readiness", True) # Breaks the consecutive-failure run.
policy.sample("readiness", False)
assert policy.ready
policy.sample("readiness", False)
assert not policy.ready and policy.restart_requests == 0
for result in (True, False, True):
 policy.sample("readiness", result)
assert not policy.ready
policy.sample("readiness", True)
assert policy.ready
print("two readiness failures remove readiness without restart; two consecutive successes restore it")

for result in (False, False, True, False, False):
 policy.sample("liveness", result)
assert policy.restart_requests == 0
assert policy.sample("liveness", False) == "restart-requested"
assert policy.restart_requests == 1 and not policy.ready
assert policy.sample("liveness", False) == "awaiting-restart"
assert policy.restart_requests == 1
policy.start_container() # Explicitly model the beginning of another container lifetime.
assert not policy.started and not policy.ready
for _ in range(4):
 policy.sample("startup", False)
assert policy.restart_requests == 2
print("three consecutive liveness failures request a restart; a fresh lifetime runs startup checks again")
print("four startup failures request another restart; no real container, clock, or traffic route was changed")

前三次启动失败尚未达到实验阈值，期间试图输入的存活、就绪观察都会被抑制，不增加它们的计数。启动成功后，其他检查才开始生效，但不会因此自动变成就绪，仍然需要满足就绪自己的成功条件。

连续两次就绪失败撤下就绪状态，却不申请重启；恢复需要连续两次成功，中间插入相反结果会重置相应的连续计数。连续三次存活失败才产生一次重启请求；模型处于等待重启阶段时，继续输入失败不会重复增加请求数量。

显式开始一个新的容器生命周期后，启动状态被清空，连续四次启动失败又会申请重启。Unknown 结果、传输错误分类、真实计时、重启政策执行、终止宽限和端点传播都没有在此验证；依赖完整平台行为之前，需要在目标集群上补充对应验收。

来源

Kubernetes：存活、就绪与启动探针，探针动作、机制、阈值和启动阶段隔离，已核验 2026-10-15。
Kubernetes：配置探针，可执行配置与容器重启观察，已核验 2026-10-15。
Kubernetes：Pod 生命周期，容器重启政策及终止与流量生命周期的区别，已核验 2026-10-15。

健康 · XB 现场笔记

Consul 发现结果取决于健康策略与新鲜度

注册记录与健康状态是两回事

DNS 并非总是只返回 passing

新鲜度包含多个阶段

坏掉的样子

快速验证

来源

liveness 与 readiness 告诉 Kubernetes Pod 的状态

Readiness 把流量挡在门外

Liveness 守护进程本身

给探针留足余量

坏掉的样子

快速验证

延伸阅读

来源

探针告诉平台何时出手

三个问题，对应不同动作

阈值统计连续观察结果

检查机制决定你拿到了什么证据

坏掉的样子

快速验证

延伸阅读

来源