可用性 · XB 现场笔记

PodDisruptionBudget 限制经驱逐接口产生的中断

Sat, 10 Apr 2027 00:00:00 +0000

PodDisruptionBudget 限制一组选中 Pod 通过驱逐产生的中断。它可以协助维护期间保留服务容量或法定多数，但不能保证两者必然存在。保护取决于调用者使用 Eviction API、选择器选中正确成员，以及 Ready 条件真正反映应用所需能力。只建立一份对象而不核对这些前提，并不能让维护自动安全。

允许中断多少，应来自应用的失败模型。三成员多数派系统通常需要两个正常成员，但 Pod 就绪本身不证明成员身份、数据同步或成员之间的连通性。PDB 是应用健康检查与维护流程的补充，不会理解数据库协议，也不会自动纠正已经失去同步却仍报告 Ready 的副本。

保护边界在驱逐接口

节点崩溃、网络分区和节点压力驱逐，都不会被 PDB 阻止。但已经不可用的成员仍可能减少后续维护可使用的额度。直接删除 Pod 或整个工作负载会绕过预算，工作负载控制器正常滚动更新时的删除也不受它限制。因此“主动中断”不自动等于“必然经过预算保护”，必须看实际调用路径。

正常 drain 通过驱逐请求工作，在预算阻挡时重试；选择直接删除的调用方则绕过这层保护。依赖预算之前，应确认维护工具真实行为。Deployment 与 StatefulSet 的滚动可用性由各自更新策略控制，所以要协调发布和节点维护，不能假定一份 PDB 就会把所有会影响副本的操作自动串行化。

计算之前先弄清分母

minAvailable 与 maxUnavailable 只能选择其一。三个健康副本配整数 minAvailable 二，在普通稳定状态下允许驱逐一个健康成员。maxUnavailable 一则相对于预期规模表达允许量。currentHealthy 计算符合条件的 Ready Pod，并排除正在删除或已经记录待中断的成员；只处于 Running 阶段并不够，进程在跑也可能完全没有服务能力。

expectedPods 并不总等于控制器的期望 replicas。此次核对的 Kubernetes 1.34.0 实现中，整数 minAvailable 使用选中 Pod 对象的数量；百分比 minAvailable 与 maxUnavailable 则从所属控制器取得预期规模。因此它与 StatefulSet replicas 不一致，可能来自策略类型或协调时刻，不能直接断定选择器拼错。不同字段的分母需要按实际计算路径理解。

状态额度大体是 currentHealthy 减去 desiredHealthy，再把负数限制为零，同时还有安全检查与尚未完成驱逐的记账。解释状态时，也应核对 observedGeneration 与 conditions。零只是当前决定，不是诊断结论；它可能表示刻意严格的策略、已有不可用 Pod、正在处理的驱逐，或者控制器同步出现问题。看到一个零就删预算，会跳过最关键的风险判断。

百分比向上取整。七个副本的一半要求留下四个健康成员，而一个期望副本配百分之三十 maxUnavailable，仍允许失去唯一副本。写成百分比并不自动保证小规模工作负载安全。应检查应用可能达到的最小规模，包括自动扩缩与维护变化之后的状态，而不是只在当前五个副本时算一次就永远沿用。

不健康策略改变排空行为

默认 IfHealthyBudget 下，Running 但未就绪的 Pod，在 currentHealthy 至少等于 desiredHealthy 时可以驱逐。如果应用已经低于这个门槛，该 Pod 可能阻挡排空，让它有机会恢复。预算并不是看不见它，而是根据不健康状态与整组健康数量做了保守选择。CrashLoopBackOff 或错误就绪探针因此可能让维护长时间等待。

AlwaysAllow 允许这些运行中但不健康的 Pod 不受该健康门槛限制而被驱逐，不表示健康 Pod 可以无限制删除。选择策略时要同时考虑恢复与维护，尤其要判断替代 Pod 是否也会被同一个错误探针卡住。改变不健康驱逐策略可以解除某类阻塞，却不会修复造成不健康的应用问题。

三个健康投票成员允许一次中断，是常见的保守选择。成员数量变化时，应重新计算法定多数与可用性；允许一个并不适合所有规模或成员变更协议。下一次健康成员驱逐可能需要等待替代成员真正就绪，不能只看到新 Pod 出现就继续操作，更不能忽视数据同步和重新加入集群所需时间。

坏掉的样子

最小健康数等于当前全部可用副本，可以是刻意阻止健康驱逐的设计，不一定属于配置错误。应记录维护如何获得余量。drain 很慢时，先看替代副本调度、就绪、既有中断与应用负责人的可用性要求，不要单纯因为操作卡住就移除预算，把原本需要决策的停机风险变成默默发生。

什么都没有匹配到的选择器保护不了任何东西。相反，policy/v1 中空选择器会匹配命名空间的所有 Pod，可能意外扩大范围。应把完整选择器，包括 matchExpressions，与真实标签和所属控制器对照。单独一个 expectedPods 数字，不能证明选中了正确应用；范围过窄和范围过宽都可能破坏原本的维护意图。

快速验证

在指定的只读上下文和命名空间中检查已有对象。以下原命令保持不变，本轮没有在真实集群重新运行。

kubectl get pdb -A -o custom-columns=NAME:.metadata.name,MIN:.spec.minAvailable,MAX:.spec.maxUnavailable,EXPECTED:.status.expectedPods,HEALTHY:.status.currentHealthy,ALLOWED:.status.disruptionsAllowed
kubectl get pdb zk-pdb -o jsonpath='{.spec.selector.matchLabels}{"\n"}'
kubectl get statefulset zookeeper -o jsonpath='{.spec.replicas}{"\n"}'
kubectl get pods -l app=zookeeper --field-selector=status.phase=Running --no-headers | wc -l

最后一条统计 Running Pod，不是 Ready Pod。选择器命令只显示 matchLabels，因此可能遗漏 matchExpressions。这些输出可以提供初步线索，但在判定 HEALTHY 或 EXPECTED 异常之前，需要阅读完整 PDB 与 Pod 对象。额度为零不会自动说明原因；额度为正也不证明应用层的法定多数一定能承受下一次驱逐，仍须结合真实成员健康。

来源

Configure a PodDisruptionBudget, selectors, rounding and unhealthy-Pod policies，已核验 2026-10-15。
Pod disruptions, eviction boundaries, involuntary failures and rolling updates，已核验 2026-10-15。
Kubernetes 1.34.0 disruption controller, getExpectedPodCount and countHealthyPods distinguish integer minimums, controller scale and outstanding disruptions，已核验 2026-10-15。

Pod 反亲和把选中的同伴分散放置

Thu, 18 Mar 2027 00:00:00 +0000

Pod 反亲和表达一个 Pod 应该避开哪些选中的同伴。主机拓扑可以减少共用节点的风险，可用区拓扑可以覆盖更大的故障域。规则不会创造额外容量，也不能证明应用已经具备高可用性；它负责影响落点，复制机制、就绪、存储与故障恢复仍然有各自职责。三个副本分开只是减少共同故障的一步，并非完整恢复方案。

强制规则过滤候选节点，偏好规则贡献评分。如果硬条件没有留下可行节点，新 Pod 会持续 Pending，直到相关条件改变。对严格隔离要求而言，这可能是正确结果，但必须提前计入容量规划，而不是在故障时才发现“不允许同处”的代价。偏好则允许权衡，不应被描述成几乎等同于硬性分离。

选中同伴，再定义拓扑域

labelSelector 识别同伴 Pod，topologyKey 指定用哪个节点标签划分它们所在的位置。kubernetes.io/hostname 通常区分节点，topology.kubernetes.io/zone 按可用区分组。应查看真实标签值，不要假定不同基础设施提供者都自动具备同一套标签；键存在但值错误，同样可能让故障域定义失真。

命名空间范围也是规则的一部分。既没有显式命名空间列表、也没有 namespaceSelector 时，默认匹配待调度 Pod 自己所在的命名空间。空的 namespaceSelector 对象则匹配所有命名空间。因此经过配置后，规则可以跨命名空间影响调度，并不是天然的租户隔离边界。审阅时必须把同伴标签与命名空间选择一起看，不能只看 app 名称。

相关节点需要一致的拓扑标签。Kubernetes 文档明确警告，缺少标签会导致意外的反亲和行为，但不能把这个警告简化成“所有未标记节点必定被接纳”或“必定被排除”。Pod 间规则、既有落点和 topology spread 是不同机制，需要查看真实规则与候选集合。直接把两种机制的缺失标签表现混在一起，会导向相反而同样错误的诊断。

硬规则可能形成放置上限

对于互相被选择器选中的副本，强制 hostname 反亲和通常让每个合格主机域最多容纳一个匹配副本。九个这样的副本放到六个合格节点，仍会有三个等待，哪怕节点还有很多 CPU。滚动更新的额外副本也可能先撞到同一道上限，所以容量规划不能只计算稳定状态的 replicas。

强制可用区反亲和同样会限制每区匹配同伴数量，但还需要检查准入配置。启用 LimitPodHardAntiAffinityTopology 时，强制反亲和的 topologyKey 被限制为 hostname。不能假定任何集群都会接受区域级硬规则，更不应在未核对允许拓扑之前就把它写进可用性设计。命令行没有执行到调度阶段，可能是准入先拒绝了清单。

IgnoredDuringExecution 表示这些调度规则不会在条件变化后自动驱逐或重新分配既有 Pod。更新工作负载模板影响替换 Pod，不会立即重排全部现有副本。已经存在的硬反亲和也可能限制新 Pod，因此只查看待调度对象的一条偏好 term 并不足够；还要理解当前同伴及其限制。

Kubernetes 1.34.0 的评分插件也会考虑既有 Pod 的偏好 term；当新 Pod 没有 Pod 间偏好时，一个配置选项可以跳过这部分计算。因此，不能无条件宣称已经运行的 Pod 的偏好总会被忽略，实际行为需要结合版本与调度器配置。

用拓扑分布表达有界不均衡

Topology spread 表达的契约不同于“每个域只许一个同伴”。采用 DoNotSchedule 时，maxSkew 限制候选域中的匹配 Pod 数与合格域全局最小值的差。采用 ScheduleAnyway 时，降低偏斜只是偏好。多条约束组合时，每条硬约束都必须可满足；增加一条看似合理的规则，也可能让原先可行的交集消失。

假设两个同样合格的区分别有二和一个匹配 Pod，maxSkew 为一。再放进较满的区会让相关差值变成二，放进较空的区则保持平衡。若合格域数量少于 minDomains，全局最小值改为零，并不是提高。该选项只能与 DoNotSchedule 配合，能够有意阻止进一步集中，代价是新的 Pod 可能无法调度。

均衡结果依赖标签、选择器、资格条件与放置顺序，并不是九个副本永远自动形成三三三。Pod 间亲和在大型集群可能增加明显的调度计算成本。应优先选择能清晰表达目标契约的机制，并实际测量调度性能，不要把“另一种规则一定更便宜”当作无需条件的保证。可读性与真实性比套一个统一模板更重要。

坏掉的样子

合格域不足时，额外副本可能 Pending，而 HPA 仍继续建议增长。如果规则限制每可用区一个，在已经占用的区增加节点并不能解决问题。放宽硬规则会改变可用性契约，应该明确接受这个取舍，不能把它当成没有后果的普通调度修补。

缺少拓扑标签、选错同伴范围，都可能让预期分离失去意义。什么同伴都没有选中的规则证明不了任何隔离，而过宽选择器又可能阻挡无关工作负载。判断分布不均之前，先核对命名空间范围与实际标签；并不是每种肉眼看起来不均匀的布局都代表调度器出错。

快速验证

在指定的只读集群上下文和命名空间执行检查。以下原有命令保持不变，本轮没有在集群重新运行。

kubectl get nodes -L topology.kubernetes.io/zone -L kubernetes.io/hostname
kubectl get pods -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName,PHASE:.status.phase
kubectl get events --field-selector reason=FailedScheduling --sort-by=.lastTimestamp | tail -5
kubectl get pods -o jsonpath='{range .items[*]}{.spec.nodeName}{"\n"}{end}' | sort | uniq -c

这些 Pod 列表覆盖整个命名空间，不一定等于规则选中的同伴集合。空节点名包括尚未调度的 Pod，空拓扑单元格则暴露标签缺失。根据实际选择器与命名空间范围筛选观察结果，再比较域和事件。每节点恰好一个 Pod，不证明反亲和就是原因；数量不均也不能单独证明某条分布约束被违反，必须把真正的候选域和 maxSkew 一起计算。

来源

把 Pod 分配到节点，Pod 间亲和与反亲和规则、拓扑键与调度行为，已核验 2026-10-15。
Pod 拓扑分布约束，maxSkew、whenUnsatisfiable、minDomains 与偏斜计算示例，已核验 2026-10-15。
Kubernetes 1.34.0 inter-Pod affinity scoring, processExistingPod and IgnorePreferredTermsOfExistingPods，已核验 2026-10-15。

就绪探针改变路由资格，存活探针触发容器重启

Wed, 13 Jan 2027 00:00:00 +0000

Readiness 与 liveness 回答不同的运维问题。就绪探针判断当前容器是否应该参与一个能够接收普通 Service 流量的 Pod，存活探针则判断是否应该执行预先配置的容器重启恢复。两者都可以使用 HTTP，但协议相同不代表语义相同。应先确定希望平台采取什么动作，再设计触发该动作的条件，否则一个健康接口可能同时承担互相冲突的责任。

同时观察响应和平台动作

就绪探针失败会让容器变成未就绪，并影响 Pod 的 Ready 条件。对于普通带选择器的 Service，端点协调随后改变哪些后端可以参加正常路由。Pod 可以保持 Running，同时处于未就绪状态，应用进程也可能继续运行。重启次数、Pod 标识和 Ready 条件回答的是不同问题，排查时不能只看其中一个状态就推导全部行为。

存活探针连续失败达到配置阈值后，kubelet 会终止容器并按相应重启规则处理。普通 Always 策略应用 Pod 会在原 Pod 中获得替换容器，而不是必然创建一个新 Pod 对象，也不是发布另一版应用。应在比较 Pod 身份的同时查看容器重启次数与终止状态，避免把一次进程恢复误报为完整工作负载替换。

检查应便宜，而且成功条件要具有实际含义。TCP 连接成功只证明监听端能够接受连接，不证明应用能够完成有用工作。HTTP 可以表达更丰富的问题，但如果它递归调用昂贵的依赖检查，也可能成为额外负载来源。探针自己的执行成本应符合工作负载容量和超时预算，不能让健康检查本身把健康服务压慢。

坏掉的样子

把共享数据库故障当成存活失败，可能导致所有正常应用进程不断重启，却完全无法修复数据库。把同一个依赖直接加入就绪检查也需要判断：撤走全部副本可能同时撤掉本来有价值的降级响应，在局部故障中还可能把流量集中到剩余副本。应依据服务实际契约定义就绪，包括已经明确支持的部分可用行为，而不是照抄统一依赖清单。

就绪状态不是网络访问控制。即使某个 Pod 不再属于 Service 的就绪目标，它的地址仍可能被直接访问。既有连接、其他路由层，以及 publishNotReadyAddresses 等 Service 设置，也需要单独分析。因此，不能把 readiness 失败描述成一个瞬时保证，认为从此没有任何请求能够到达进程。它改变的是对应服务发现和路由流程中的资格。

阈值和时序决定敏感程度。超时过短可能把 CPU 争用误认成故障，要求连续多次失败则可以避免对一次短暂延迟立即反应。启动保护是另一回事：配置了 startup 探针时，在它成功之前不会执行就绪与存活探针。这些参数定义采样和恢复策略，并不证明终止过程中不会丢失请求；可靠停机仍需应用参与。

快速验证

准备可丢弃的 Kubernetes 集群，确保 kubectl 可用，节点能够使用 python:3.11-slim-bookworm 镜像。保存为 probe-actions.py，执行 python3 probe-actions.py KUBECONFIG_PATH CONTEXT，明确传入测试集群参数。账号需要创建、删除命名空间。原文记录的服务端为 Kubernetes 1.34.11，本轮没有重新执行集群实验；脚本创建一个 HTTP Pod 和采用默认端点就绪行为的普通 Service。

import json
import subprocess
import sys
import time
from uuid import uuid4

assert len(sys.argv) == 3, 'usage: python3 example.py DISPOSABLE_KUBECONFIG CONTEXT'
base = ['kubectl', '--kubeconfig', sys.argv[1], '--context', sys.argv[2], '--request-timeout=30s']
image = 'python:3.11-slim-bookworm'


def k(*args, payload=None, expected=0):
 result = subprocess.run(base + list(args), input=json.dumps(payload) if payload is not None else None,
 capture_output=True, text=True, timeout=150)
 if expected is not None:
 assert result.returncode == expected, result.stderr
 return result


def obj(namespace, kind, name=None, selector=None):
 args = ['get', kind, '-n', namespace, '-o', 'json']
 if name:
 args.append(name)
 if selector:
 args += ['-l', selector]
 return json.loads(k(*args).stdout)


def apply(namespace, data):
 return k('apply', '-n', namespace, '-f', '-', payload=data)


def wait_for(read, ready, seconds=120):
 until = time.monotonic() + seconds
 while time.monotonic() < until:
 value = read()
 if ready(value):
 return value
 time.sleep(0.5)
 raise AssertionError('expected Kubernetes condition did not arrive')


def pod_ready(pod):
 return any(c['type'] == 'Ready' and c['status'] == 'True'
 for c in pod.get('status', {}).get('conditions', []))


def spec(script='import time; time.sleep(600)'):
 return {'automountServiceAccountToken': False, 'terminationGracePeriodSeconds': 1,
 'containers': [{'name': 'app', 'image': image, 'imagePullPolicy': 'IfNotPresent',
 'command': ['python3', '-c', script],
 'resources': {'requests': {'cpu': '10m', 'memory': '24Mi'},
 'limits': {'cpu': '200m', 'memory': '96Mi'}}}]}

namespace = 'notes-probes-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 server = '''from http.server import BaseHTTPRequestHandler,HTTPServer
from pathlib import Path
class Handler(BaseHTTPRequestHandler):
 def do_GET(self):
 flag={'/live':'/tmp/live-fail','/ready':'/tmp/ready-fail'}.get(self.path)
 code=503 if flag and Path(flag).exists() else 200
 body=b'worker'; self.send_response(code); self.send_header('Content-Length',str(len(body)))
 self.end_headers(); self.wfile.write(body)
 def log_message(self,*args): pass
HTTPServer(('0.0.0.0',8080),Handler).serve_forever()
'''
 podspec = spec(server)
 c = podspec['containers'][0]
 c['readinessProbe'] = {'httpGet': {'path': '/ready', 'port': 8080}, 'periodSeconds': 1, 'failureThreshold': 2}
 c['livenessProbe'] = {'httpGet': {'path': '/live', 'port': 8080}, 'periodSeconds': 1, 'failureThreshold': 3}
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'worker', 'labels': {'app': 'worker'}}, 'spec': podspec})
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Service', 'metadata': {'name': 'web'},
 'spec': {'selector': {'app': 'worker'}, 'ports': [{'port': 80, 'targetPort': 8080}]}})
 def targets():
 return {e['targetRef']['uid'] for s in obj(namespace, 'endpointslices', selector='kubernetes.io/service-name=web')['items']
 for e in s.get('endpoints', []) if e.get('conditions', {}).get('ready') and e.get('targetRef')}
 initial = wait_for(lambda: obj(namespace, 'pod', 'worker'), pod_ready)
 uid = initial['metadata']['uid']
 wait_for(targets, lambda value: value == {uid})
 def change(path, create):
 method = 'touch' if create else 'unlink'
 k('exec', '-n', namespace, 'worker', '--', 'python3', '-c',
 'from pathlib import Path; Path('+repr(path)+').'+method+'()')
 change('/tmp/ready-fail', True)
 wait_for(lambda: obj(namespace, 'pod', 'worker'), lambda p: not pod_ready(p))
 wait_for(targets, lambda value: not value)
 time.sleep(4)
 unready = obj(namespace, 'pod', 'worker')
 assert unready['metadata']['uid'] == uid and unready['status']['containerStatuses'][0]['restartCount'] == 0
 address = 'http://' + unready['status']['podIP'] + ':8080/api'
 probe = 'from urllib.request import urlopen; print(urlopen('+repr(address)+',timeout=3).read().decode())'
 assert k('exec', '-n', namespace, 'worker', '--', 'python3', '-c', probe).stdout.strip() == 'worker'
 change('/tmp/ready-fail', False)
 wait_for(targets, lambda value: value == {uid})
 change('/tmp/live-fail', True)
 restarted = wait_for(lambda: obj(namespace, 'pod', 'worker'), lambda p:
 pod_ready(p) and p['status']['containerStatuses'][0]['restartCount'] >= 1)
 assert restarted['metadata']['uid'] == uid
 assert restarted['status']['containerStatuses'][0]['restartCount'] == 1
 wait_for(targets, lambda value: value == {uid})
 print(json.dumps({'readiness_removed_ready_target_without_restart': True,
 'unready_pod_direct_http_still_succeeds': True,
 'readiness_recovery_restores_target': True,
 'liveness_container_restarts': 1, 'same_pod_uid': True}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

起初 Pod 已就绪，它的标识出现在 Service 的 EndpointSlice 就绪目标中。创建本地标记文件后，只有 readiness 路径返回 503。达到失败阈值并完成协调后，就绪目标集合为空。再过四秒，Pod 标识仍相同，容器重启次数仍为零。这同时验证了路由资格变化与进程没有重启，而不是仅检查接口返回码。

在同一个 Pod 内，向它自己的未就绪 Pod 地址直接发送 HTTP 请求，仍能得到 worker。这没有测试其他 Pod 或外部客户端的可达性。删除就绪失败标记，目标资格便恢复。接着创建另一个标记，让 liveness 路径失败，kubelet 实际重启容器一次。新容器的可写层不再包含该标记，Service 就绪目标随之恢复。整个过程中 Pod 的标识没有变化，显示重启发生在容器层面。

原文报告全部断言通过，命名空间随后删除；这里保留的是历史执行归属，不表示本轮独立重现。实验展示了不同平台动作与直接可达性，没有测试已有连接的优雅排空，也没有证明生产可用性。真实发布还需要共同验证端点传播、应用停机、未完成工作和客户端行为。健康探针返回成功，只能说明该探针检查的条件成立，不能代替整个请求生命周期的交付证据。

来源

Kubernetes: Configure Probes，失败阈值以及就绪和存活探针的不同动作，已核验 2026-10-15。
Kubernetes: Pod Lifecycle，容器重启与 Pod 就绪状态，已核验 2026-10-15。
Kubernetes: EndpointSlices，后端就绪条件及服务发现行为，已核验 2026-10-15。

被动上游健康判断来自失败流量，不来自探测定时器

Tue, 05 Jan 2027 00:00:00 +0000

nginx 被动上游健康判断利用真实请求结果，决定某个节点是否暂时停止接收流量。max_fails 设置失败尝试阈值，fail_timeout 同时规定计数区间和不可用时长。这些配置不会安排周期性的应用探测。主动检查需要被支持的检查能力与额外配置，不能把真实请求结果策略直接称作一个已经运行的探活定时器。

坏掉的样子

不是每个看起来像错误的 HTTP 响应，都算一次失败上游尝试。代理重试配置参与定义这种分类。在本次设置中，只有列入 http_503，HTTP 503 才参与相应被动失败处理。如果认为所有 5xx 都会自动导致健康失败，就可能期待节点已被摘除，而 nginx 仍依据真实规则继续选择它。必须先核对什么结果被配置认定为失败。

另一个错误是把超时窗口结束当成恢复证明。不可用时段结束后，节点可以重新获得真实流量资格，未必先通过独立健康探测。如果后端仍坏着，这次请求仍会失败。least_conn 依据活动连接改变选择，并不提供渐进恢复权重的升温过程，也不能代替受支持的 slow-start 机制。资格恢复、健康证明和逐渐加量需要分别理解。

重试也有边界。响应数据已经发送给客户端后，更换节点不能透明修复中途错误；重放有副作用的操作还可能产生重复。下面只使用 GET，并在成功正文发送之前产生失败，且明确限制尝试次数。它没有为所有应用方法证明安全重试语义，不能把这个成功切换案例直接用于任何写操作。

快速验证

以下固定镜像的 Docker 网络集成原样保留，本轮没有重跑；既有结果属于历史记录。

将脚本保存为 check-passive-health.py，准备 Python、Docker 和固定镜像后运行。记录服务器为单 worker 的 nginx 1.28.0。可丢弃容器里的两个 HTTP 端点报告自身身份，并能受控返回 503。另一个控制监听提供计数，查询它不会通过被均衡组产生业务请求，便于区分观察动作与真实探测流量：

from contextlib import contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import http.client,json,socket,subprocess,time,uuid

NGINX='nginx@sha256:552e7481ca93ffccd046aa658dbbed22caefbc09c66fa7cd247cbb90b8a5c609'
PYTHON='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],capture_output=True,text=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def wait(predicate):
 deadline=time.monotonic()+15
 while time.monotonic()<deadline:
 try:
 if predicate():return
 except OSError:pass
 time.sleep(.1)
 raise AssertionError('fixture did not become ready')

@contextmanager
def lab(configuration,files=None,backend=None,extra_ports=()):
 name='xbcatm-nginx-'+uuid.uuid4().hex[:10];tags=[name+':proxy',name+':backend'];containers=[name+'-proxy',name+'-backend']
 try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'files').mkdir();(root/'nginx.conf').write_text(configuration)
 for path,content in (files or {}).items():
 target=root/'files'/path;target.parent.mkdir(parents=True,exist_ok=True)
 target.write_bytes(content if isinstance(content,bytes) else content.encode())
 docker('network','create',name)
 if backend is not None:
 (root/'backend.py').write_text(backend)
 (root/'backend.Dockerfile').write_text(f'FROM {PYTHON}\nCOPY backend.py /backend.py\nCMD ["python", "/backend.py"]\n')
 docker('build','--network','none','-f',str(root/'backend.Dockerfile'),'-t',tags[1],str(root))
 docker('run','-d','--name',containers[1],'--network',name,'--network-alias','backend',tags[1])
 wait(lambda:docker('exec',containers[1],'python','-c','import socket;s=socket.create_connection(("127.0.0.1",8081),timeout=.5);s.close()',check=False).returncode==0)
 (root/'Dockerfile').write_text(f'FROM {NGINX}\nCOPY nginx.conf /etc/nginx/nginx.conf\nCOPY files /srv\n')
 docker('build','--network','none','-t',tags[0],str(root))
 docker('run','--rm','--network',name,tags[0],'nginx','-t')
 published=[arg for value in (8080,*extra_ports) for arg in ('-p','127.0.0.1::'+str(value))]
 docker('run','-d','--name',containers[0],'--network',name,*published,tags[0])
 details=json.loads(docker('inspect',containers[0]).stdout)[0]
 binding=details['NetworkSettings']['Ports']['8080/tcp'][0];assert binding['HostIp']=='127.0.0.1';port=int(binding['HostPort'])
 def ready():
 connection=socket.create_connection(('127.0.0.1',port),timeout=.5);connection.close();return True
 wait(ready)
 def request(path,method='GET',headers=None,body=None):
 connection=http.client.HTTPConnection('127.0.0.1',port,timeout=5)
 try:
 connection.request(method,path,body=body,headers=headers or {})
 response=connection.getresponse();return response.status,{k.lower():v for k,v in response.getheaders()},response.read()
 finally:connection.close()
 request.port=port;request.network=name
 request.ports={int(key.split('/')[0]):int(value[0]['HostPort']) for key,value in details['NetworkSettings']['Ports'].items() if value}
 yield containers[0],request
 finally:
 docker('rm','-f',*containers,check=False);docker('image','rm',*tags,check=False);docker('network','rm',name,check=False)

def config(locations,extra=''):
 return 'worker_processes 1;\nerror_log /tmp/error.log notice;\nevents {}\nhttp {\naccess_log off;\n'+extra+'\nserver { listen 8080; root /srv;\n'+locations+'\n}\n}\n'
backend=r'''
from http.server import BaseHTTPRequestHandler,ThreadingHTTPServer
from urllib.parse import urlsplit,parse_qs
import itertools,json,threading
lock=threading.Lock();ids=itertools.count(1);counts={'A':0,'B':0};active={'A':0,'B':0};faults={'A':200,'B':200};gates={}
class Handler(BaseHTTPRequestHandler):
 protocol_version='HTTP/1.1'
 def setup(self):super().setup();self.ident=next(ids)
 def log_message(self,*args):pass
 def do_GET(self):
 parsed=urlsplit(self.path);label=self.server.label;code=200
 if label=='control':
 query=parse_qs(parsed.query)
 with lock:
 if parsed.path=='/fail':faults[query['peer'][0]]=int(query['status'][0])
 if parsed.path=='/release':gates[query['path'][0]].set()
 data={'counts':dict(counts),'active':dict(active),'faults':dict(faults),'held':list(gates)}
 else:
 with lock:
 counts[label]+=1;active[label]+=1;code=faults[label]
 if parsed.path.startswith('/hold/'):gates[parsed.path]=threading.Event()
 if parsed.path.startswith('/hold/'):assert gates[parsed.path].wait(20)
 data={'peer':label,'path':self.path,'connection':self.ident}
 body=json.dumps(data,sort_keys=True).encode();self.send_response(code)
 self.send_header('Content-Type','application/json');self.send_header('Content-Length',str(len(body)))
 self.end_headers();self.wfile.write(body)
 if label!='control':
 with lock:active[label]-=1
for port,label in [(8081,'A'),(8082,'B'),(8083,'control')]:
 server=ThreadingHTTPServer(('0.0.0.0',port),Handler);server.label=label
 threading.Thread(target=server.serve_forever,daemon=True).start()
threading.Event().wait()
'''
extra='''
upstream passive { server backend:8081 max_fails=1 fail_timeout=2s; server backend:8082; }
upstream plain { server backend:8081 max_fails=1 fail_timeout=30s; server backend:8082; }
upstream single { server backend:8081 max_fails=1 fail_timeout=30s; }
add_header X-Upstream $upstream_addr always; add_header X-Attempts $upstream_status always;
'''
locations='''
location /passive { proxy_next_upstream error timeout http_503; proxy_next_upstream_tries 2; proxy_pass http://passive; }
location /plain { proxy_next_upstream error timeout; proxy_pass http://plain; }
location /single { proxy_next_upstream error timeout http_503; proxy_pass http://single; }
location /control/ { proxy_pass http://backend:8083/; }
'''
active_config=config('location / { proxy_pass http://peers; health_check; }',
 'upstream peers { zone peers 64k; server backend:8081; server backend:8082; }')
with lab(config(locations,extra),{'active.conf':active_config},backend) as (proxy,request):
 def control(path):
 status,_,body=request('/control/'+path);assert status==200;return json.loads(body)
 def call(path):
 status,h,b=request(path);return {'status':status,'attempts':h['x-attempts'],'upstream':h['x-upstream'],'peer':json.loads(b)['peer']}
 control('fail?peer=A&status=503');results={}
 plain=[call('/plain') for _ in range(6)]
 assert [r['status'] for r in plain].count(503)==3 and all(',' not in r['attempts'] for r in plain)
 results['unlisted_http_503']=plain
 for _ in range(2):
 first=call('/passive')
 if first['attempts']=='503, 200':break
 assert first['status']==200 and first['attempts']=='503, 200' and first['peer']=='B',first
 results['failed_attempt_then_success']=first
 after_failure=control('state')['counts']['A']
 excluded=[call('/passive') for _ in range(4)]
 assert all(r['peer']=='B' and r['attempts']=='200' for r in excluded)
 assert control('state')['counts']['A']==after_failure
 time.sleep(.4);assert control('state')['counts']['A']==after_failure
 results['during_exclusion']=excluded;results['background_probe_count']=0
 control('fail?peer=A&status=200');deadline=time.monotonic()+6;recovered=None
 while time.monotonic()<deadline:
 observed=call('/passive')
 if observed['peer']=='A':recovered=observed;break
 time.sleep(.1)
 assert recovered and recovered['status']==200;results['live_request_after_window']=recovered
 control('fail?peer=A&status=503');before=control('state')['counts']['A']
 single=[call('/single') for _ in range(2)]
 assert all(r['status']==503 and r['attempts']=='503' for r in single)
 assert control('state')['counts']['A']==before+2;results['single_peer_still_attempted']=single
 probe=docker('exec',proxy,'nginx','-t','-c','/srv/active.conf',check=False)
 assert probe.returncode!=0 and 'unknown directive "health_check"' in probe.stderr
 results['active_health_check_directive_supported']=False
 print(json.dumps(results,sort_keys=True))

首先让 A 返回真实 HTTP 503，B 返回 200。一个对照组只对连接错误和超时重试。六次请求仍各选择 A、B 三次，没有多次尝试的响应。A 的 max_fails=1 不会因为这个未列入的 HTTP 结果把它移除。实验检查状态与所选上游地址，不只查看最终正文，从而避免把应用返回值与节点资格变化混淆。

被动检查组列入 http_503，允许两次尝试，并为 A 设置 max_fails=1 fail_timeout=2s。某个请求先遇到 A 的 503，再在 B 成功，客户端最终得到 200。nginx 记录上游状态 503, 200 和两个地址。这里的状态确实来自后端 HTTP 响应，不是根据连接拒绝推断出来的合成标签。

A 被排除期间，后续四次请求都只使用 B。包括受控暂停在内，A 的请求计数保持不变，说明这份配置没有发送后台健康探测。随后把后端恢复正常，在配置窗口之后，一个真实请求重新选中 A 并成功。测试等待这个选择被实际观察到，而不是假定某个精确时钟边界已经证明节点恢复。

另一个组只包含 A。即使设置 max_fails=1 fail_timeout=30s，两次请求仍到达这个失败节点并返回 503。对于单服务器组，nginx 忽略这些被动不可用参数。拓扑没有其他节点可选，就不能假定多节点摘除行为能够凭空提供可用替代。配置看起来有失败阈值，不代表所有组结构都会采用同一处理结果。

最后，一个可丢弃候选配置包含 health_check，被测二进制以未知指令拒绝它。这直接验证安装能力边界：被动参数没有启用主动检查。有效运行配置继续保留，不会仅因为通用文档出现某个模块或商业能力，就把它写成本机已经可用。能力判断应与实际版本、构建和配置对应。

根据服务响应契约设计失败检测

先决定哪些结果代表节点不可用，哪些属于合法应用响应。授权失败或对象不存在，不一定说明服务器不健康。被动检测还依赖有流量到达，因此安静但损坏的节点可能直到用户请求出现才被测试。主动检查在可用时回答另一种时间问题，但仍需要设计自己的成功条件，不能只靠“主动”这个名称判断可靠性。

如果部署主动检查，应定义有意义的健康端点，并理解它实际经过哪些依赖。仅 TCP 接受连接不能证明应用能产生有用响应；反过来，过宽的依赖检查可能因为共享下游问题移除全部节点。成功条件应对应摘除节点真正能保护的业务流量，避免检测结果和应采取的路由动作失去关联。

观测时把客户端最终状态与尝试状态、节点地址、延迟和排除状态一起看。最终 200 可能掩盖第一次失败以及额外等待。核实部署版本的能力、重试限制和恢复路径，才能让可用性承诺对应客户端真实体验，而不是只对应配置里出现了“健康”相关词汇。

来源

nginx upstream module，max_fails、fail_timeout 双重含义、单节点行为与 slow start，已核验 2026-10-15。
nginx proxy module，失败尝试分类、重试条件与重试限制，已核验 2026-10-15。
nginx HTTP health check guide，被动检查、主动检查及产品能力的区别，已核验 2026-10-15。

可用性 · XB 现场笔记

PodDisruptionBudget 限制经驱逐接口产生的中断

保护边界在驱逐接口

计算之前先弄清分母

不健康策略改变排空行为

坏掉的样子

快速验证

来源

Pod 反亲和把选中的同伴分散放置

选中同伴，再定义拓扑域

硬规则可能形成放置上限

用拓扑分布表达有界不均衡

坏掉的样子

快速验证

来源

就绪探针改变路由资格，存活探针触发容器重启

同时观察响应和平台动作

坏掉的样子

快速验证

来源

被动上游健康判断来自失败流量，不来自探测定时器

坏掉的样子

快速验证

根据服务响应契约设计失败检测

延伸阅读

来源