Kubernetes · XB 现场笔记

调度器计算资源请求，而不是瞬时使用率

Sun, 02 Apr 2028 00:00:00 +0000

Kubernetes 调度判断的是 Pod 在资源请求和其他放置约束下是否适合某个节点，不是简单查看当前 CPU 曲线，然后把任务塞进看起来最空闲的位置。请求为未来需求提供记账输入，实际使用率则是另一种观测。决定一个表面空闲的集群是否有能力容纳特定 Pod 之前，需要同时理解两者，不能让其中一个指标替代全部容量判断。

以准入后的真实配置为依据

对于普通应用容器，调度器在判断节点是否容纳 Pod 时，会计算它们的请求。初始化需求、Pod 额外开销以及受支持的 Pod 级资源配置，也可能影响有效请求。最终经过准入的 Pod 才是实际输入，包括默认值和修改结果，而不只是操作者记得提交的源文件。排查时应读取保存下来的对象，确认控制面实际看到什么。

Node allocatable 也不同于硬件总容量，它表示按照节点配置可以提供给 Pod 的资源量。其他工作负载即使暂时空闲，其资源请求仍然占用调度记账中的空间。不过，请求并不表示应用已经实际分配了同样多的物理内存，也不表示独占相应数量的 CPU 核心。放置记账、实时消耗和独占策略属于不同机制，不能混用“预留”一词解释。

限制通过执行栈约束运行中的工作负载，通常不会在调度检查时替代已经显式填写的较小请求。因此，一个容器的 CPU limit 可以大于单个节点 CPU 容量，同时仍然凭较小 request 完成调度。这个被接受的限制不会制造额外处理器，也不承诺进程一定能够达到填写的上限；它只是配置了允许使用的边界。

坏掉的样子

Pending 可能源于请求资源不足，也可能由污点、亲和性、存储、拓扑或其他条件阻塞。改变资源值之前，应查看 PodScheduled 条件和调度事件。降低请求无法修复不匹配的节点选择器或不可用的卷；如果原请求本来真实，盲目降低还可能把调度失败转化成运行期争用，并没有建立合理容量方案。

默认值让省略字段尤其容易误读。填写 limit 而不填 request，且没有准入机制提供另一默认请求时，Kubernetes 会把该资源限制复制为请求。因此，只设置一个很大的 limit，也可能形成很大的调度需求。应查看实际对象中的两个映射，并考虑 LimitRange 的影响，再解释放置失败，不能假定省略请求就等于完全没有记账成本。

API 还会拒绝请求大于对应限制的配置。这属于准入校验失败，不是调度器在判断集群容量。区分这两个阶段，可以解释为什么一份清单根本无法创建 Pod，而另一份会创建可检查的对象，只是暂时没有分配节点。错误发生位置不同，修复所需证据也不同，不应统一归因于资源不足。

QoS 也不是免疫承诺。在传统每容器规则下，Guaranteed 要求所有相关容器同时具有 CPU 和内存请求与限制，并且分别相等。只让内存相等并不足够。即使类别为 Guaranteed，也可能遇到资源失败，不能用类别代替优先级、容量规划、应用正确性或实际节点压力分析。选择请求应考虑负载证据和故障代价，而不是追求某个标签。

快速验证

准备至少包含一个 Ready、没有污点工作节点的临时 Kubernetes 集群，确保 kubectl 可用，节点已有 python:3.11-slim-bookworm 镜像。保存为 request-placement.py，执行 python3 request-placement.py KUBECONFIG_PATH CONTEXT，明确指定测试参数。账号需要创建、删除命名空间。实测服务端为 Kubernetes 1.34.11，所选节点报告可分配十个 CPU。

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'}}}]}

from decimal import Decimal, ROUND_CEILING

def cpu_quantity(value):
 return Decimal(value[:-1]) / 1000 if value.endswith('m') else Decimal(value)

namespace = 'notes-requests-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 workers = [n for n in obj(namespace, 'nodes')['items'] if
 not n['spec'].get('unschedulable') and not n['spec'].get('taints')
 and any(c['type'] == 'Ready' and c['status'] == 'True' for c in n['status']['conditions'])]
 assert workers, 'a Ready worker without taints is required'
 worker = workers[0]
 allocatable = cpu_quantity(worker['status']['allocatable']['cpu'])
 too_large = str(int(allocatable.to_integral_value(rounding=ROUND_CEILING)) + 1)
 for name, request in [('burst', '10m'), ('oversized', too_large)]:
 podspec = spec()
 podspec['nodeSelector'] = {'kubernetes.io/hostname': worker['metadata']['labels']['kubernetes.io/hostname']}
 podspec['containers'][0]['resources'] = {
 'requests': {'cpu': request, 'memory': '24Mi'}, 'limits': {'cpu': too_large, 'memory': '96Mi'}}
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': name}, 'spec': podspec})
 burst = wait_for(lambda: obj(namespace, 'pod', 'burst'), pod_ready)
 assert burst['spec']['nodeName'] == worker['metadata']['name']
 def insufficient(p):
 return any(c['type'] == 'PodScheduled' and c['status'] == 'False'
 and c.get('reason') == 'Unschedulable' and 'Insufficient cpu' in c.get('message', '')
 for c in p.get('status', {}).get('conditions', []))
 pending = wait_for(lambda: obj(namespace, 'pod', 'oversized'), insufficient)
 assert pending['status']['phase'] == 'Pending' and not pending['spec'].get('nodeName')
 only_limit = spec()
 only_limit['containers'][0]['resources'] = {'limits': {'cpu': '200m', 'memory': '64Mi'}}
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'defaulted'}, 'spec': only_limit})
 defaulted = wait_for(lambda: obj(namespace, 'pod', 'defaulted'), pod_ready)
 resources = defaulted['spec']['containers'][0]['resources']
 assert resources['requests'] == resources['limits'] == {'cpu': '200m', 'memory': '64Mi'}
 assert defaulted['status']['qosClass'] == 'Guaranteed'
 invalid = spec()
 invalid['containers'][0]['resources'] = {'requests': {'cpu': '200m'}, 'limits': {'cpu': '100m'}}
 denied = k('create', '-n', namespace, '-f', '-', payload={
 'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'invalid'}, 'spec': invalid}, expected=None)
 assert denied.returncode != 0 and 'must be less than or equal to cpu limit' in denied.stderr
 print(json.dumps({'node_allocatable_cpu': str(allocatable), 'limit_cpu': too_large,
 'small_request_with_large_limit_scheduled': True,
 'larger_than_node_request_pending': True,
 'limit_only_defaulted_resources': resources,
 'defaulted_qos': defaulted['status']['qosClass'],
 'request_above_limit_rejected': True}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

程序用 nodeSelector 指向该工作节点，仍让调度器负责实际分配。两个对照 Pod 的 CPU limit 都是十一核。第一个只请求十毫核，最终在指定节点 Ready；第二个请求十一核，保持 Pending，没有 nodeName，PodScheduled 报告 Unschedulable，并包含 Insufficient cpu。两者的程序都只空闲等待，没有真的尝试消耗十一核。

第三个 Pod 只填写 200m CPU 与 64Mi 内存限制。存储对象中出现完全相同的请求，实际 QoS 类别为 Guaranteed。第四个尝试请求 200m，却限制为 100m，被 API 拒绝。全部断言通过，命名空间随后删除。这些真实对象分别展示了成功放置、调度拒绝、默认填充和结构校验，而不是只计算一张假想容量表。

实验没有测量真实峰值容量、资源管理器独占行为或所有调度插件。生产请求需要从工作负载证据出发，把实际准入需求与使用量共同审阅，不能将一张空闲曲线或熟悉的请求比例当成放置保证，也不能把 kind 节点报告的容量直接当作生产机器基准。

来源

Kubernetes: Resource Management，基于请求的放置、限制及准入默认值，已核验 2026-09-13。
Kubernetes: Pod Quality of Service Classes，Guaranteed 条件及服务质量保护的边界，已核验 2026-09-13。

Kubernetes CronJob 需要历史清理策略

Fri, 25 Feb 2028 00:00:00 +0000

CronJob 本身不跑你的任务：它创建一个 Job，Job 再创建 Pod。Pod 跑完之后，Job 和 Pod 都不会自动消失。Pod 是故意留着的，好让你事后还能读到它的日志；Job 留着，是为了让你还能看到这次运行的状态。

这份默认对一次运行是对的，对一万次运行就是错的。每一个已完成的 Job 都是 etcd 里的一个对象、每次列表响应里的一行，以及所有关心 Job 的控制器都会收到的一次 watch 事件。给这堆东西设边界的有两套彼此独立的机制：CronJob 控制器按数量裁的历史上限，和 TTL 控制器按时间裁的 TTL。

已完成的 Job 并不免费

已完成的 Job 会留住它的 Pod，而 Pod 只要还在，容器日志就还在。于是保留策略成了你和“命名空间堆满墓碑”之间唯一的东西。按小时调度跑三十天就是 720 次运行：720 个 Job 加 720 个 Pod，每个都有自己的名字、状态、owner reference，以及你每次 kubectl get jobs 输出里的一行。已完成的 Job 也不是完全静止的：它的 status conditions 一直留在 API 里，被每个 watcher 反复读取。单个对象的开销微不足道，但它是随时间线性增长的，所以它长期保持隐形，直到某天突然变成问题。

可观测性上的代价比资源代价来得更早。命名空间里一旦有几百个已完成的 Job，kubectl get jobs 一屏就放不下，真正的失败混在一堆成功里看不出来。API server 的内存压力确实存在，但它是渐进的；你排查问题的能力下降却是立刻发生的，也正是这一点逼着人去配清理策略。这笔账是悄悄复利的：按小时的任务一年下来堆满墓碑，而每分钟一次的任务一周就追平。

两套机制，两个控制器

CronJob 控制器按数量裁。successfulJobsHistoryLimit 默认是 3，failedJobsHistoryLimit 默认是 1，把任意一个设成 0 就表示这一类一个都不留。裁剪按类别分别进行，并且从最旧的开始，所以一个长期失败的 Job 只会留下最近一次失败。这两个上限 API 都不强制；不设策略本身也是一种策略，只不过是一种会持续泄漏的策略。

TTL 控制器按时间裁。ttlSecondsAfterFinished 写在 Job 上，控制器会在 Job 完成之后的那个秒数把它删掉，并级联删掉它的 Pod。设成 0 表示完成即刻可删；不设则 TTL 控制器永远不会碰它。这个特性从 v1.23 起稳定，而且它读的是 Job 而不是 CronJob——这一点下面会用到。两套机制之间没有任何协调：谁先触发谁生效，所以一个比历史窗口更短的 TTL 会悄无声息地盖掉你配的数量。

owner reference 决定谁来清理

由 CronJob 创建的 Job 带着指向该 CronJob 的 owner reference，所以删除 CronJob 会级联到它的 Job 以及这些 Job 的 Pod。级联删除正是删掉一个 CronJob 看起来就万事大吉的原因：Job 和 Pod 一起消失，历史上限根本没参与进来。但按数量裁剪这件事是 CronJob 控制器做的，而它必须知道 CronJob 存在，才知道上限是多少。因此 kubectl delete cronjob --cascade=orphan 会留下 owner reference 悬空的 Job，且没有任何东西再来裁它们；而 TTL 依然生效，因为它是逐个 Job 单独判定的。

对于你直接创建、而非经由 CronJob 创建的 Job，官方文档写明的默认删除策略是 orphanDependents：删掉 Job 可能把它的 Pod 留在原地。控制面最终会在这些 Pod 失败或完成后把它们回收，但文档明确警告残留的 Pod 可能拖慢甚至拖垮集群，并因此建议把 ttlSecondsAfterFinished 设上。清理策略是一道保留决策，不是洁癖偏好。

坏掉的样子

为了“保持命名空间干净”把两个历史上限都设成 0，会让每个 Job 在完成的那一刻被删掉，Pod 和它的日志随之消失。你真正需要看的那次失败就此不见，而且无法恢复。留几条成功记录，再留足够覆盖一个周末的失败记录；读不到的证据不叫证据，被删掉的日志也不叫日志。

TTL 只从“完成”那一刻起算，所以一个永远跑不完的 Job 永远不会过期。卡在 ImagePullBackOff 的 Pod 会让它的 Job 一直停在 active 状态：既不是成功，也不是失败，于是两类历史上限都不统计它。给 job template 加上 activeDeadlineSeconds，让卡死的运行最终失败，再交给 TTL 去回收。

快速验证

把配置和实际堆积量对照着看：

kubectl get cronjob hourly-rollup -o jsonpath='{.spec.successfulJobsHistoryLimit} {.spec.failedJobsHistoryLimit} {.spec.jobTemplate.spec.ttlSecondsAfterFinished}{"\n"}'
kubectl get jobs --sort-by=.metadata.creationTimestamp --no-headers | wc -l
kubectl get pods --field-selector=status.phase=Succeeded --no-headers | wc -l
kubectl get jobs -o jsonpath='{range .items[*]}{.metadata.name} ttl={.spec.ttlSecondsAfterFinished} owner={.metadata.ownerReferences[0].name}{"\n"}{end}'

第一行两个值都为空，说明没有任何东西在限制保留量。Job 数量稳定在两个上限之和附近，说明 CronJob 控制器正在裁剪；数量随时间持续上涨，说明它没有。最后一条命令里，ttl 为空且 owner 也为空的 Job 就是孤儿，两个控制器都不会再去删它。

来源

Kubernetes Job，“Clean up finished jobs automatically” 与已完成 Job 的 TTL 机制，已核验 2026-09-16。
Kubernetes CronJob，默认历史上限与 job template，已核验 2026-09-16。
Kubernetes 垃圾回收，owner reference 与级联删除，已核验 2026-09-16。

cgroup 在层级中执行容器资源预算

Fri, 11 Feb 2028 00:00:00 +0000

Kubernetes 资源字段只有经过节点执行栈落实，才成为实际约束。在 Linux 上，kubelet 与容器运行时通过 cgroup 组织进程并配置资源控制器。最终形成的是一个层级，而不是简单贴在 Pod 上的单个数字。判断进程真正可以消耗多少资源之前，需要检查对应容器控制组及继承的约束，避免把清单意图直接等同于有效运行预算。

读取实际执行资源约束的控制器

在 cgroup v2 中，cpu.max 用配额与周期表示 CPU 带宽，单位是微秒。10000 100000 表示该组每个周期可使用相当于十分之一个 CPU 的时间。它不会把进程固定在一个核心上，也不会降低处理器时钟频率。组内如果存在多个可运行线程，就可能在同一周期中更快消耗完共同额度，然后等待下一段可用预算。

CPU weight 负责另一件事：在发生争用时，影响相应层级中有资格竞争的组之间的相对分配。Kubernetes 的 CPU 请求既参与调度，也可以影响这个权重。请求本身不是运行时硬上限，权重也不保证应用的墙钟延迟或独占核心。应把放置需求、相对份额和带宽上限分别理解，而不是都称为已经预留的 CPU。

内存控制器分别暴露限制与使用量。memory.max 描述控制组的硬内存边界，memory.current 报告当前记账使用。回收与 OOM 属于内存机制，不是 CPU 那样按周期进行的节流。应用堆大小也不能解释全部记账内存，调查限制问题时需要把运行时指标与控制器视图对应起来，关注额外进程、缓存和其他开销。

坏掉的样子

层级约束可能比某个本地文件显示的值更严格。子组没有本地 CPU 上限，仍可能受到祖先限制；容器的 cgroup 命名空间也可能隐藏部分层级。因此，不能看到本地 max 就推断可以无限使用整个节点。有效预算还取决于节点上下文与父级约束，容器内部可见的信息未必足以解释所有争用和节流。

多容器 Pod 可以分别配置容器限制。一个容器暂时没有用完额度，并不自动承诺另一个容器可以越过自己的上限。Pod 级资源功能涉及额外字段和版本条件，不能悄悄用它们替代每容器配置的含义。下面实验明确只使用容器 resources，并核对准入后的 Pod 没有配置 Pod 级 resources 字段，保持验证范围清楚。

即使整机 CPU 平均使用率不高，频繁节流仍可能解释应用延迟。反过来，单个节流计数也不能确定所有延迟来源。应查看相关时间窗口中的增量，结合负载需求与请求延迟分析，并记住祖先争用及其他资源也会造成等待。短暂合成循环只能建立执行机制的证据，不能替真实应用完成容量规划或延迟承诺。

控制器文件还依赖环境。cgroup v1 使用不同接口，CPU 管理策略和运行时配置也可能影响放置与执行细节。需要验证实际节点设置，不能复制一个路径就假定含义完全相同。本例要求 cgroup v2 接口，只读取控制器文件，没有修改节点的资源控制配置。运行条件不满足时，检查应明确失败，而不是输出伪造的成功结果。

快速验证

准备采用 cgroup v2 的临时 Linux Kubernetes 集群、kubectl，以及节点可用的 python:3.11-slim-bookworm 镜像。保存为 cgroup-enforcement.py，执行 python3 cgroup-enforcement.py KUBECONFIG_PATH CONTEXT，明确指定测试参数。账号需要创建、删除命名空间。实测服务端为 Kubernetes 1.34.11，使用 kind 的容器运行时配置。

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-cgroup-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 podspec = spec()
 podspec['containers'] = []
 for name, request, limit, memory in [('small', '25m', '100m', '64Mi'), ('large', '50m', '200m', '96Mi')]:
 container = spec()['containers'][0]
 container['name'] = name
 container['resources'] = {'requests': {'cpu': request, 'memory': '24Mi'},
 'limits': {'cpu': limit, 'memory': memory}}
 podspec['containers'].append(container)
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'budgets'}, 'spec': podspec})
 wait_for(lambda: obj(namespace, 'pod', 'budgets'), pod_ready)
 snapshot = '''from pathlib import Path
import json,os
p=Path('/sys/fs/cgroup')
assert (p/'cgroup.controllers').exists(), 'this example requires cgroup v2'
print(json.dumps({'cpu_max':(p/'cpu.max').read_text().strip(),
 'cpu_weight':int((p/'cpu.weight').read_text()),
 'memory_max':int((p/'memory.max').read_text()),
 'group_inode':os.stat(p).st_ino}))
'''
 observations = {}
 for name, expected_cpu, expected_memory in [('small', 0.1, 64), ('large', 0.2, 96)]:
 data = json.loads(k('exec', '-n', namespace, 'budgets', '-c', name, '--', 'python3', '-c', snapshot).stdout)
 quota, period = map(int, data['cpu_max'].split())
 assert quota / period == expected_cpu
 assert data['memory_max'] == expected_memory * 1024 * 1024
 observations[name] = data
 assert observations['small']['group_inode'] != observations['large']['group_inode']
 load = '''from pathlib import Path
import json,time
p=Path('/sys/fs/cgroup/cpu.stat')
def counters(): return {k:int(v) for k,v in (line.split() for line in p.read_text().splitlines())}
before=counters(); begin=time.monotonic(); cpu=time.process_time(); value=0
while time.monotonic()-begin < 3: value=(value+1)%1000003
after=counters()
print(json.dumps({'wall_seconds':time.monotonic()-begin,'process_cpu_seconds':time.process_time()-cpu,
 'nr_throttled_delta':after['nr_throttled']-before['nr_throttled'],
 'throttled_usec_delta':after['throttled_usec']-before['throttled_usec']}))
'''
 throttling = json.loads(k('exec', '-n', namespace, 'budgets', '-c', 'small', '--', 'python3', '-c', load).stdout)
 assert throttling['nr_throttled_delta'] > 0 and throttling['throttled_usec_delta'] > 0
 final = obj(namespace, 'pod', 'budgets')
 assert pod_ready(final) and all(c['restartCount'] == 0 for c in final['status']['containerStatuses'])
 assert 'resources' not in final['spec']
 print(json.dumps({'container_groups': observations, 'measured_throttling': throttling,
 'container_restarts': 0, 'pod_level_resource_field_used': False}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

两个容器位于同一 Pod，却暴露不同的控制组目录身份。较小容器的 cpu.max 为 10000 100000，memory.max 为 67108864；较大容器分别为 20000 100000 和 100663296。观察到的 CPU 权重是六与十一。这些是当前运行时映射结果，不是要求所有安装都必须重现的通用常量，代码也没有把权重数字当成可移植断言。

在较小容器中执行约三秒繁忙循环，节流周期增加三十次，节流时间约增加 2.707 秒。墙钟经过约 3.007 秒，进程实际 CPU 时间约为 0.298 秒。两个容器最终都保持就绪，重启次数为零。全部断言通过，命名空间随后清理，结果显示 CPU 约束确实影响了实际执行，而不是仅存在于清单。

实验验证不同容器的真实配置与 CPU 节流，没有测量争用工作负载之间的公平性，没有展示所有祖先配置，也没有测试 Pod 级资源分配。把底层控制器观测转化为运维结论时，需要保留这些边界，不能从一次成功节流推导全部共享资源保障。

来源

Kubernetes: About cgroup v2，Linux 资源控制器集成及前提，已核验 2026-09-13。
Kubernetes: Resource Management，传递给运行时的容器请求与限制，已核验 2026-09-13。
Linux: Control Group v2，层级、CPU 带宽、权重与内存记账，已核验 2026-09-13。

cordon 与 drain 让节点安全离线

Thu, 03 Feb 2028 00:00:00 +0000

cordon 和 drain 是两件事，只是大家习惯一口气说完。cordon 给节点打上 spec.unschedulable，让调度器不再选它；drain 则把已经在上面跑的 Pod 请走。前者瞬时完成、随时可逆，后者是一个循环，要逐个 Pod 去跟驱逐 API 打交道。

矛盾在于：drain 是一个带安全护栏的客户端流程。它在删除任何东西之前会先拒绝，而每一个能越过拒绝的参数，都在拿掉一部分护栏。搞清楚哪个参数对应哪一类拒绝，就是维护窗口和线上事故之间的差别。

cordon 关门，drain 清场

kubectl cordon node-1 把 spec.unschedulable 置为 true，调度器随即把该节点从新 Pod 的候选里滤掉。已经在跑的 Pod 照常服务，这正是要先 cordon 的原因：先停止接收新工作，再开始搬走已有的工作。cordon 也是让 drain 有意义的前提——不封门，调度器会把替代副本直接放回你正在清空的那台机器上。kubectl drain 自己也会打这个标记，所以单独先执行一次 cordon 只是稳妥，不是必需。kubectl uncordon 就是反向的同一个补丁，调度器立刻会重新使用这台节点——先确认 kubelet 已经 Ready 再放它回去。

接下来 drain 逐个驱逐 Pod：服务端支持驱逐 API 时走驱逐，不支持时退化为普通的删除。驱逐是一种优雅终止，terminationGracePeriodSeconds 会被尊重，drain 会一直等到它结束。但优雅期是一扇窗口而不是保证——忽略 SIGTERM 的 Pod 到期照样被杀，真正保护数据的是 Pod 自己的关闭逻辑。镜像 Pod（mirror pod）是例外：它们由 kubelet 依据静态清单管理，根本无法通过 API server 删除，所以 drain 直接跳过，而不是在这里失败。

拒绝清单一票否决

drain 在删除任何东西之前先拒绝，而且一个不合规的 Pod 会挡住这台节点上的全部驱逐，而不只是它自己那一次。三类拒绝对应三个不同的参数，kubectl 的报错文案里写得很直白：没有控制器的 Pod 会得到 cannot delete Pods that declare no controller (use --force to override)，管理它的资源已经消失的 Pod 也一样；用了 emptyDir 的会得到 Pods with local storage (use --delete-emptydir-data to override)；而 DaemonSet 的 Pod 得到 DaemonSet-managed Pods (use --ignore-daemonsets to ignore)。

DaemonSet 这一类是加了参数也不改变结果的那一种。无论有没有 --ignore-daemonsets，drain 都不会删 DaemonSet 的 Pod，因为 DaemonSet 控制器无视不可调度污点，删掉会立刻被重建；这个参数只是让 drain 不再拒绝而已。还有两类 Pod 无论如何都会落到被排空的节点上：容忍 node.kubernetes.io/unschedulable 污点的，以及直接写死 nodeName、绕过调度器的。容忍这个污点的通常就是 DaemonSet，文档因此明确建议除了 DaemonSet 之外不要容忍它。

最终拍板的是预算，不是参数

拒绝清单清空之后，drain 开始提交驱逐请求，此时说话算数的是 PodDisruptionBudget。当某个 PDB 的 disruptionsAllowed 为 0，驱逐请求会返回 429，drain 就带着退避一直重试，直到 --timeout 到期——而这个参数默认是 0，也就是无限。这个重试循环正是卡住的 drain 看起来像“挂起”而不是“失败”的原因：drain 只是在忠实执行你的指令，不报错、不推进，只反复打 evicting pod。

真正绕过预算的参数是 --disable-eviction，它跳过驱逐 API 直接删除 Pod。--force 不做这件事，它只负责那些没有控制器的 Pod——这跟大多数人的直觉正好相反。这两个参数完全不能互换，把它们当成同一类“强制开关”来用，是排空流程里最常见、代价也最高的误用。还有一点要注意：默认的不健康 Pod 驱逐策略 IfHealthyBudget 会让一个卡在 CrashLoopBackOff 的 Pod 把整台节点的排空拖住，直到它变成 Ready。

坏掉的样子

永远不返回的 drain。minAvailable 等于副本数，或者 maxUnavailable: 0，算出来的可中断数就是 0，驱逐请求被永远拒绝，终端就那么停在那里。同时排空多台节点也帮不上忙，它们共用同一个预算。用 kubectl get pdb -A 一条条核对定位：某个 PDB 选中的 Pod 正好落在你要排空的节点上，且 ALLOWED DISRUPTIONS 显示 0，它就是元凶；正确的修法是换一个允许一次驱逐的预算，而不是把超时调大。

把负载一起带走的 drain。面对卡住的排空，有人会去抓 --force 或 --disable-eviction，节点是清空了，被预算保护的那几个 Pod 也一起没了。如果那是一个需要法定多数的服务，这场“维护”就变成了事故。安全的顺序是：先修预算、再耐心等待，把 --force 留给你已经逐一确认过确实无状态的那个 Pod。

快速验证

确认节点已经封门，并看清 drain 会拒绝什么：

kubectl get node node-1 -o jsonpath='{.spec.unschedulable}{"\n"}'
kubectl drain node-1 --dry-run=client --ignore-daemonsets --delete-emptydir-data
kubectl get pods --field-selector spec.nodeName=node-1 -o custom-columns=NAME:.metadata.name,OWNER:.metadata.ownerReferences[0].kind
kubectl get pdb -A -o custom-columns=NAME:.metadata.name,MIN:.spec.minAvailable,MAX:.spec.maxUnavailable,ALLOWED:.status.disruptionsAllowed

第一条在节点被 cordon 之后会打印 true。第二条干跑会列出 drain 打算驱逐的 Pod，以及它按名字拒绝的 Pod。第三条里 OWNER 列为空的 Pod 必须靠 --force 才能删；第四条里，如果某个 PDB 的 Pod 就在这台节点上而 ALLOWED 是 0，那么这次 drain 会一直等下去，而不是报错退出。

来源

安全地排空节点，drain 流程及其与 PodDisruptionBudget 的交互，已核验 2026-09-16。
kubectl drain 参考，精确的拒绝条件与参数说明，已核验 2026-09-16。
Pod 中断，主动与被动中断的区别以及驱逐重试，已核验 2026-09-16。

Horizontal Pod Autoscaler 按目标利用率扩缩容

Wed, 22 Dec 2027 00:00:00 +0000

由于它依据一段时间序列的平均值而不是单个尖峰来决定动作，你往往还要配一个最大副本数，避免扩张失控。

把平滑后的均值当作决策依据

HPA 不会拿一个瞬时读数当依据;它先按窗口对观测值取平均、做平滑,再拿去和期望值比较。这样是为了避免一次一秒的尖峰就重画副本数:先聚合,等到平滑后的数值真正越过了目标,再去动副本。因此真正要调的是三件事:指标源、聚合口径(按 Pod 平均还是集群总量),以及取样的窗口。窗口太短会放大噪声,太长又追赶不上需求。动手改 HPA 之前,先把文档里「怎么聚合、多久算一次」那段读明白,再做任何别的。

选一个你真正能改进的指标

选指标才是设计核心,因为伸缩的上限由目标定。CPU 在任何集群上都好取、对 CPU 密集的负载也顺,可它是个代理:真正排队等锁、等数据库的服务,CPU 往往是闲着的,变坏的是延迟。请求速率、或一个自定义的 queue_depth 这类指标测起来更麻烦,反映的却是用户真正感受到的东西。选一个你能对得上的指标:当它越线时,真实的体验确实变了;并且让 HPA 用和应用同样的口径去定义负载,于是它收敛的是那个让体验变差的数字,而不是那个恰好便宜的抄近道数。

自动化与初始值无关

replicas 的初值是起点,不是 HPA 的依据。一旦 HPA 接管,副本数归它管,初值只是下限或出发点。二者在最好的意义上互不相关:关掉控制器,你仍然有一个稳定、明码的陈述基数;开着一个无人调整的 HPA,它也只管自己那部分。所以下限要现实(它才是那个地板),上限要挡住成本风险的峰值,而初值只负责让最开始的几秒体面一点——在控制器的头几次采样落地之前,它撑起第一段安全期。

坏掉的样子

自定义指标不可用时不会自动回退到中央处理器。接口返回错误或空序列时，控制器把对应指标标为无效，把扩缩条件置为假，然后保持当前副本数而不是猜一个数。只配了队列深度的工作负载，会在最需要扩容时原地冻结。正确做法是把中央处理器与自定义指标并列配置，取算出副本数更多的一方，这样队列信号丢失时仍有降级可用的输入，至少不会把服务钉在原地。

适配器链路还会引入延迟。抓取间隔与缓存叠加后，读到的可能是几分钟前的队列深度，于是对已排空的工作继续加副本，造成超调。先看序列时间戳与查询延迟，再决定是否放宽目标值，每个工作负载只暴露一条预聚合序列，不要把原始高基数序列直接喂给扩缩器。

基数爆炸会从另一侧压垮同一条链路。按用户或按请求打标签，会把一个信号膨胀成数万条序列，拖慢接口，让拉取超时，读数翻转为未知。应先在监控侧聚合，只暴露工作负载级的平均值或总量，收敛序列规模后再对接自动扩缩。

目标类型配错同样致命。自定义指标只支持数值与平均值，利用率只适用于配好资源申请的资源指标。没有资源申请就用中央处理器利用率，或拿内存利用率当延迟代理，都会长期未知。先确认哪一路报未知，再把类型改成链路真正提供的那种，并补齐缺失的资源申请。

快速验证

把下面的代码存为水平扩缩模拟脚本并运行。它只用标准库，不碰任何集群，复刻两条核心规则：多指标取算出副本数更多的一方，缺失指标直接跳过，全部缺失时保持副本数不变，便于本地复现线上行为。

import math
import sys


def desired_for(current, value, target):
 """单个指标算出的期望副本数；返回空表示该路指标不可用。"""
 if value is None or target is None or target <= 0:
 return None
 return math.ceil(current * value / target)


def decide(current, metrics, min_replicas, max_replicas):
 """多指标取最大值；全部缺失时保持当前副本数不变。"""
 wants = []
 for _, value, target in metrics:
 want = desired_for(current, value, target)
 if want is not None:
 wants.append(want)
 if not wants:
 return current
 return max(min_replicas, min(max_replicas, max(wants)))


def check(actual, expected, message):
 if actual != expected:
 raise AssertionError(f"{message}：实际 {actual}，期望 {expected}")
 print(f"OK: {message} -> {actual}")


def main():
 current = 4
 cpu = ("cpu", 80, 50) # 4 * 80/50 = 6.4 -> 7
 queue = ("queue", 900, 300) # 4 * 900/300 = 12
 check(decide(current, [cpu, queue], 1, 20), 12, "多指标取最大值")
 check(decide(current, [cpu, ("queue", None, 300)], 1, 20), 7, "一路缺失仍按可用指标扩容")
 check(decide(current, [("cpu", None, 50), ("queue", None, 300)], 1, 20), 4, "全部缺失时保持副本数")
 check(decide(current, [cpu, queue], 1, 10), 10, "最大副本数依然限幅")
 print("PASS: 4 scenarios; max-wins and hold-on-missing verified")
 print(sys.version.split()[0])


if __name__ == "__main__":
 main()

四个场景锁定关键行为：合并场景证明中央处理器要七个而队列要十二个时取十二个；单个缺失证明一路失败仍由中央处理器接管；全部缺失证明保持不动而非缩零；限幅场景证明算完后最大副本数依然生效。预期输出以通过信息结尾，说明四组场景成立，最大值优先与缺失保持均已验证，并打印解释器版本。

上述断言在苹果电脑的解释器上已通过。它只验证副本数计算，不验证抓取延迟、缓存与基数。上线前请用真实指标接口的时间戳与扩缩事件复核，再改生产目标值。

来源

Kubernetes 水平自动扩缩，说明算法与指标来源，已核验 2026-06-01。
资源指标流水线，说明指标服务与资源指标接口，已核验 2026-06-01。

CronJob 把时间表变成一次 Pod 运行

Fri, 17 Dec 2027 00:00:00 +0000

CronJob 就是一份 Job 模板加一条 cron 表达式。表达式每次匹配，控制器就新建一个 Job，由它把 Pod 跑到完成再停掉。两轮之间没有任何常驻进程，这正是它吸引人的地方：批处理任务直接继承集群的重试、资源与调度机制，不需要谁养一个守护进程来触发它。

代价是时间表只被“近似”兑现。Kubernetes 承诺每个执行时刻“大约”创建一个 Job，这句措辞把两个方向的偏差都包了进去——同一时刻冒出两个 Job，或者一个都没有。凡是被排进 CronJob 的活都必须能安全跑两遍，因为你真正拿到的保证是至少一次，而不是恰好一次。

一张时间表催生一个 Job

schedule 用熟悉的五个字段——分、时、日、月、星期——支持 Vixie cron 的区间与步长写法，所以 */10 * * * * 每十分钟触发一次，*/15 9-17 * * mon-fri 只落在工作时段内。? 与 * 等价，@daily、@hourly 这类宏会展开成对应的表达式。没有设置 timeZone 的 CronJob 跟随控制器管理器所在时区的本地时钟，控制面一换地方，任务的执行时刻就跟着变。少写一个字段是校验错误，这也让它成为 CronJob 少数会大声失败的配置错误之一。

每一次匹配都会生成一个以 CronJob 命名的独立 Job，这也是 CronJob 名字被限制在 52 个字符以内的原因：控制器还要再拼上十一个字符，而 Job 名字的上限是 63。CronJob 自己从不执行任务，它只创建 Job，Pod 归 Job 所有。从 Kubernetes v1.32 起，生成的 Job 会带上 batch.kubernetes.io/cronjob-scheduled-timestamp 注解，记录它本该在什么时候跑——控制器重启之后，这是区分“迟到的运行”和“准时的运行”的唯一依据。

并发是一道策略，不是猜

concurrencyPolicy 决定上一轮 Job 还在跑时又到点该怎么办。默认的 Allow 直接再起一份；Forbid 跳过这一次；Replace 取消正在跑的那个 Job 换新的。这条策略只约束同一个 CronJob 生成的 Job，两个不同的 CronJob 之间互不阻塞。

危险的是 Replace：如果 Job 稳定地跑得比间隔慢，每个到点时刻都会杀掉那个眼看就要跑完的运行，活永远做不完。大家说“别重叠”时想要的通常是 Forbid，但有两个附带条件——被跳过的那些轮次就是丢了；而且当前 Job 跑完之后，startingDeadlineSeconds 仍会被重新评估，一个迟到大半天的运行可能照样起来。

漏跑次数有一百的额度

startingDeadlineSeconds 划出“迟到多久还值得补跑”的边界，过了这条线的那一轮直接跳过并记为失败；而跳过某一次并不会让时间表停下，下一个匹配时刻照样会触发。不设这个字段时，漏跑本身没有截止时间，但控制器还有一道硬上限：它统计自上次计划时间以来漏掉了多少个时刻，超过一百个就一个都不补，并打出 too many missed start times. Set or decrease .spec.startingDeadlineSeconds or check clock skew。

官方例子把这笔账算得很清楚。一个每分钟触发的 CronJob，控制器从 08:29 停到 10:21，中间漏掉 112 个时刻，于是恢复后什么都不会补跑。改成 startingDeadlineSeconds: 200，控制器只统计最近 200 秒内漏掉的时刻——三个——Job 就起来了。同一个字段还藏着一个更细的坑：小于十秒的值不可靠，因为控制器每十秒才检查一次。suspend: true 能让 CronJob 停摆而不影响已在运行的 Job，但被挂起的执行时刻照样计入漏跑，所以没有截止时间就恢复挂起，积压会一次性全放出来。

坏掉的样子

最经典的是 Job 和自己重叠。一份跑二十五分钟的报告放在十分钟的间隔上，用默认的 Allow，峰值会同时有三份在读同一份输入、写同一份输出。它从不以报错的形式出现：你看到的是重复行、翻倍的 API 开销，或者三份里有一份报锁超时。要么换成 Forbid 并接受被跳过的轮次，要么把 Job 做成幂等，再给它加一把租约，让迟来的那份提前退出。

第二种是静默的补跑丢失。控制面停机时间超过一百个调度间隔，积压就会在恢复时被整体丢弃，唯一的痕迹是控制器管理器日志里的一行。对每分钟一次的轮询来说这是对的，对每晚一次的备份来说就是错的——这正是 startingDeadlineSeconds 的用途：把它设成真实的容忍度（一天两次的备份就是八小时），既限定了运行可以有多陈旧，也让“一百个间隔”这道上限永远够不着。

快速验证

把时间表、并发策略和最近一次触发时间放在一起看：

kubectl get cronjob nightly-report -o jsonpath='{.spec.schedule} {.spec.concurrencyPolicy} {.spec.startingDeadlineSeconds}{"\n"}'
kubectl get cronjob nightly-report -o jsonpath='{.status.lastScheduleTime}{"\n"}'
kubectl get jobs --sort-by=.metadata.creationTimestamp -o custom-columns=NAME:.metadata.name,START:.status.startTime,SUCCEEDED:.status.succeeded
kubectl get events --field-selector involvedObject.kind=CronJob --sort-by=.lastTimestamp | tail -5

lastScheduleTime 应该落在距当前一个调度间隔之内；差出几个小时，说明控制器停过，或者表达式从未匹配。START 时间互相重叠而 SUCCEEDED 仍为空，是 Allow 配上跑不完的 Job 的典型特征；事件里出现 too many missed start times，就直接指向漏跑规则。

来源

Kubernetes CronJob，调度语法、并发策略、漏跑一百次的规则与历史上限，已核验 2026-09-16。
CronJob v1 API 参考，CronJob spec 的字段级定义，已核验 2026-09-16。

节点亲和把工作负载放到合适的节点

Thu, 09 Dec 2027 00:00:00 +0000

亲和性是放置匹配：可以"偏好"某个标签也可以"强制"它，再用反亲和把副本散开，换取更强的韧性。硬件从来不会长期均匀——这边一池 GPU，那边高速本地 NVMe，还有合规数据的隔离区——而工作负载悄悄依赖落到对的地方。没有显式规则，调度器只按空闲容量铺，需要 GPU 的 Pod 落到没有 GPU 的节点，在运行时而不是调度时才失败。

亲和把这次失败前移到它该在的位置。 placements 写成节点上的数据（标签）配 Pod 上的规则，可 review 的配置代替了"哪些节点是特殊的"部落知识。读 manifest 的人一眼看出工作负载必须跑在哪、为什么。

按标签匹配节点

亲和性规则读取节点标签，让你说明某个 Pod 应该、甚至必须落在带某个标签的节点上。把稳定的标签一次性打在节点上，剩下的就让调度器去匹配。accelerator=nvidia-a100、storage=nvme、zone=regulated 这类标签描述机器的持久属性；因为它们住在 node 对象上，换机器也不影响引用它的 Pod 规则——新硬件打同样的标签，老规则继续生效。

标签名要像 API 字段一样认真起，因为改一个被广泛引用的标签名，就是跨所有匹配它的 manifest 的迁移。约定小而有文档的词表，胜过每队自创 key：workload-class、hardware、compliance 覆盖大多数家底，再配半页约定文档，免得 GPU 标签拼出五种写法。像校验镜像 tag 一样在 CI 里校验标签——要求一个没有任何节点携带的标签的 Pod，是该死在流水线里的拼写错误，而不是凌晨三点的发布。

偏好还是强制

偏好型规则尽力而行，条件允许就把负载摊开；强制型规则则硬性拒绝那些满足不了标签的 Pod。只有放置真地有讲究才用强制，否则偏好能留给调度器更多弹性。成本模型很直白：强制拿可用性换正确——没有匹配节点有位子，Pod 就 Pending，也不去错的地方；偏好拿正确换可用——落到次优但活着的地方。

大多数家底想要的是：少数硬约束用强制（有 GPU、合规区、架构），软诉求全用偏好（跨机架摊、优先新型号）。偏好项的权重给软诉求排优先级：便宜容量优先，贵池子当溢出。强制规则每季度 review，因为去年稀缺的硬件今年可能遍地都是；一条没人记得的强制规则，就是"集群明明有空位却不调度"的病因。

反亲和把副本分开

反亲和看的是其它 Pod，把一个工作负载的副本摊到不同节点，单个节点故障的杀伤面就变小。配合副本数与 topology 键使用，分离才有意义，而不是表面文章。topologyKey: kubernetes.io/hostname 跨机器散，topologyKey: topology.zone 跨故障域散。前者扛死 kubelet，后者扛死机房——按你真正怕的 outage 选键；跨 zone 散要 zone 数不小于副本数才有意义。

强制反亲和值得跟强制亲和一样的谨慎：三副本配强制主机散开，坏一台没事，但工作负载永远超不过节点数，两节点集群根本装不下。对多数服务，高权重的偏好反亲和拿到几乎全部韧性，又没有调度脆弱。强制形态留给那几个 co-location 真的比 Pending 更糟的：quorum 成员、单 leader 对。

新规则上线后不要只看能否调度，还要看落点是否符合预期：用一周时间每天按节点标签分组统计一次实际分布，确认 GPU 负载真的留在 GPU 池、合规负载没有外溢。若发现偏好规则长期被容量压力打败，就把缺口量化成扩容需求写进排期；若某条强制规则的匹配节点长期为零，就回头检查标签名是否拼错或已被改名，避免一条僵尸规则悄悄卡住未来的发布。

坏掉的样子

标志性故障是永久 Pending：events 写着 didn't match pod affinity rules，节点却半空。病因几乎总在标签侧——节点标签没打、改名了、值跟规则对不上（nvme 对 nvme-ssd）。kubectl get nodes -L hardware,workload-class 一张表看清实际标签面，跟 Pod 的要求一对，mismatch 多半当场招供。

更阴的是满足但错位的放置：偏好规则在容量压力下悄悄输掉，几周下来 GPU 负载漂到共享节点，GPU 池子却闲着。偏好意味着调度器可以不听，有压力时它真不听。定期按意图审计放置——按负载和节点标签分组查——对总在漂的规则从偏好升强制，或把逼你妥协的容量缺口补上。

快速验证

标签面、要求、实际落点一起看：

kubectl get nodes -L accelerator,workload-class --no-headers
kubectl describe pod api-0 | grep -A 8 "Node-Selectors"
kubectl get pods -o wide -l app=api | awk '{print $1, $7}' | sort | uniq -c | sort -rn | head

第一条看标签面，第二条看一个 Pod 到底要求什么，第三条证明副本真散开了还是悄悄堆在一台上。

来源

Kubernetes 节点亲和文档，节点亲和语义，已核验 2026-06-10。
Kubernetes taints 与 tolerations，说明把 Pod 从专用节点挡开，已核验 2026-09-05。

Kubernetes 滚动更新逐步替换 Pod

Sat, 27 Nov 2027 00:00:00 +0000

maxSurge 与 maxUnavailable 两个窗口，给一次发布过程中最多能多出或缺少的 Pod 数定了上限,让升级始终在容量可控的前提下进行。

一次只换一小批

滚动更新不会把整份负载一次换掉,而是一批一批地先起新、再撤旧,并且整条链路都尊重 readiness。控制器会等新的 Pod 变就绪,才认为这次发布往前挪了一步,于是那些始终就绪不了的 Pod 会卡住这次发布,而不是偷偷用坏版本扛流量。这正是旧行为:任何时刻都不会从旧版一步跨到新版、中间一刻也没有空窗。因为切换被 readiness 拦住,你会在第一批新 Pod 就发现问题、中断发布,而不是等全量上线才知道砸了。

用 surge 与 drain 两扇窗

maxSurge 与 maxUnavailable 两扇窗,规定了整个发布的形状。maxSurge 允许多少个高于期望的额外 Pod,用于边排旧边补新;maxUnavailable 允许替换期间低于期望多少个。它们一组合,既定速度也定余量:surge 给得多就跑得快,代价是要有抵抗它的容量;而 maxUnavailable:1 + maxSurge:0 则偏向容量不动,却慢,并且发布窗口可以拉得很长。挑这两扇窗,看的应该是「如果这次发坏了我能容忍多坏」,而不是挑一组看起来左右均衡的数字,因为它们字面上就限定了这次发布能触碰多少 Pod。

回滚只是重新部署

因为一次发布本身只是另一张 spec,回滚不过是把镜像指回上一次跑的那份,然后同样受 readiness 约束的批次扰动,倒着再来一遍。把上一个版本保留着、随时能起,并优先用一个你读过、测过的旧镜像,而不是现场打的补丁——这样回滚路径本身就是一条被测试过的路径。审计一致、Pod 更替受同样的窗口约束,而团队也确切知道「回滚」是什么意思,它就是一次对最后已知好版本的重新部署,没有任何别的。

先选形状，再调节奏

strategy.type 只有两个值,而默认值把这个选择藏了起来。RollingUpdate 让新旧 Pod 在 surge 与 unavailable 两扇窗里重叠;Recreate 先把旧 Pod 删光,再建新 Pod,最小可用数按构造就是零,两扇窗直接被忽略。当两个版本绝不能并存,就选 Recreate:旧代码读不回去的单写迁移、排他文件锁或单例 worker、新旧互不兼容的有线协议。姊妹篇调的是波次节奏,这篇定的是发布形状。无状态层默认 RollingUpdate;一旦选了 Recreate,就要把停机排进计划,而不是等它找上门:测一次冷启动、预拉镜像、提前公告窗口。选之前先答三问:两个版本能同时 serving 吗,旧版本占着新版本要独占的资源吗,停机窗口能量化吗。第一问答否,直接 Recreate;第二问答是也倾向 Recreate,比如旧 Pod 占着的 hostPort 或 ReadWriteOnce 卷,新 Pod 根本起不来;第三问答否,说明还没测冷启动,先测再选。

坏掉的样子

经典死法一:有状态负载配了 RollingUpdate,直接脑裂。新旧 Pod 在一波里重叠,两个 leader 短暂并存,各接各的任务、各按各的 schema 写,事后合并只能人工。版本不能并存的地方,重叠本身就是 bug,解法是 Recreate 或真正的协调。它最难查:服务一直有响应,错误藏在重复任务与主键冲突里,等对账才爆发。有 leader 选举或单写假设的负载,别用重叠发布。

镜像死法二:Recreate 的停机超出窗口。团队只预算了三十秒,可新镜像拉得慢、readiness 要几分钟,而最小可用数是零,多出来的每一分钟都是全停。更糟的是回滚也要再停一次,窗口直接翻倍。选它之前,先计时一次冷启动。

死法三:把 RollingUpdate 配成了全停。四个副本配 maxUnavailable: 50%,一次撤掉两个,又有一个新 Pod CrashLoop,剩下孤零零一个扛全流量,直接被压垮。小舰队把 maxUnavailable 留在零或一。

快速验证

把下面存成 strategy_window.py,跑 python3 strategy_window.py。只用标准库,不碰进程之外的任何东西,用副本数与窗口算术推每个策略的可用下限。

"""Compare the availability floor of Recreate vs RollingUpdate (stdlib only)."""

def rolling_window(replicas, max_surge, max_unavailable):
 if replicas <= 0:
 raise ValueError("replicas must be positive")
 if max_unavailable >= replicas:
 raise ValueError("maxUnavailable covers the whole fleet: configured full stop")
 floor = replicas - max_unavailable
 ceiling = replicas + max_surge
 return floor, ceiling


def recreate_window():
 return 0, 0


def main():
 replicas, surge, unavailable = 6, 1, 1
 rolling_floor, rolling_ceiling = rolling_window(replicas, surge, unavailable)
 stopped, _ = recreate_window()
 assert rolling_floor == 5, rolling_floor
 assert rolling_ceiling == 7, rolling_ceiling
 assert rolling_floor > 0, "rolling update must keep serving"
 assert stopped == 0, "recreate stops everything first"
 try:
 rolling_window(4, 1, 4)
 except ValueError as error:
 print("caught expected misconfiguration:", error)
 else:
 raise AssertionError("maxUnavailable >= replicas should fail")
 print(f"replicas={replicas} surge={surge} unavailable={unavailable}")
 print(f"rolling: min available={rolling_floor}, max total={rolling_ceiling}")
 print("recreate: min available=0 (full stop, then rebuild)")
 print("PASS: rolling keeps serving; recreate stops everything first")


if __name__ == "__main__":
 main()

六副本、一 surge、一 unavailable,能保持五个 serving、最多七个总量;Recreate 按构造下限就是零。断言把这条契约写死,而 maxUnavailable 盖住全部四个副本的误配必须抛错,而不是算出一个下限。把六副本换成你的真实副本数再跑一遍,结论不变,数字跟着变。

断言在 macOS 的 Python 3.14.4 下通过。模型只算窗口算术,不覆盖拉镜像、探针与调度。发布日之前,先确认线上真实的 strategy.type,再去 staging 计时一次冷启动,计时要计全程:拉镜像、探针变绿、旧连接排空,三段加起来才是真实窗口。

来源

Kubernetes Deployment 滚动更新，滚动更新语义，已核验 2026-06-12。
Kubernetes 更新 Deployment，说明滚动行为与回滚，已核验 2026-09-05。

安全上下文需要运行时证据来验证

Sat, 20 Nov 2027 00:00:00 +0000

Kubernetes 的 securityContext 配置进程身份及部分操作系统约束，可以缩小被攻陷应用允许执行的操作，但本身不会建立完整安全边界。应先确定应用实际需要什么操作，再配置对应字段，并在最终容器中同时测试允许与拒绝的行为。只有一份看起来严格的清单，还不能说明运行中的进程已经按预期受到限制，也不能代替应用本身的权限设计。

把设置放在正确层级

Pod 级配置可以提供用户和组身份、共享卷的组权限行为，以及 seccomp 配置。容器级字段可以覆盖适用的默认值，并设置 capabilities、权限提升和只读根文件系统。需要核对字段真实 API 范围，把熟悉的名称写在错误位置，并不会获得等价约束。相同的 securityContext 名称之下，不代表所有字段都能互换放置。

runAsUser 选择数值用户身份，runAsNonRoot 则要求容器符合非 root 策略。这些设置补充镜像元数据，不能仅凭一个用户名看起来普通，就信任实际权限。卷权限也必须允许所选身份完成必要工作。下面的 emptyDir 通过 fsGroup 提供组访问，使应用能够写入指定工作目录，而不必因此获得对整个根文件系统的写权限。

Linux capabilities 把传统上广泛关联于 root 的权限拆成不同能力。删除 ALL 会移除容器配置中的这些能力。普通容器默认并不继承全部 Linux 能力，而容器内以 root 运行，也不等于已经成功逃逸到宿主机。应审阅真实有效权限，避免用这两种过度简化替代证据。减少权限很有价值，但其效果需要准确描述。

坏掉的样子

allowPrivilegeEscalation false 会为进程设置 no_new_privs，限制通过执行程序获取新权限，例如 set-user-ID 或文件能力引起的身份与权限提升。它不会撤销进程已经拥有的全部权限，也不代替业务授权。应检查实际进程标志和有效能力，不能把每一次被拒绝的操作都归因于这个字段，否则可能误解其他身份或文件权限设置的作用。

readOnlyRootFilesystem 让容器根文件系统只读，其他挂载仍可能可写，包括明确提供的工作卷。这并不是全面禁止执行代码：解释器仍可以读取并运行可写卷中的程序。它也不会阻止网络请求，或撤销对已经挂载数据的读取。只读存储约束的是一类操作，不能直接证明攻击无法继续，更不能把“不能改根目录”扩写成“不能写入任何内容”。

Seccomp 过滤系统调用，但 RuntimeDefault 取决于运行时提供的默认配置。进程报告过滤模式，说明存在实际过滤机制，不证明所有不期望的调用和攻击路径都被阻断。普通 Linux 容器运行时也能执行这些字段，不是必须采用特殊沙箱它们才生效。更强隔离有独立设计要求，应按威胁模型讨论，不能把是否有效与某一个产品名称绑定。

互相冲突的身份设置可能通过 API 准入，却阻止容器启动。镜像也可能原本需要在根文件系统中写缓存或临时文件。应检查启动状态和被拒绝路径，只提供实际所需工作存储，不要用恢复 root、允许权限提升或打开整个根文件系统来处理所有权限报错。必要写入与过大权限需要通过真实调用区分。

快速验证

准备临时 Linux Kubernetes 集群、kubectl，以及节点可用的 python:3.11-slim-bookworm 镜像。保存为 security-context.py，执行 python3 security-context.py KUBECONFIG_PATH CONTEXT，明确指定测试集群。账号需要创建、删除命名空间。实测服务端为 Kubernetes 1.34.11，使用 kind 的标准运行时配置，所有对象均属于本次临时实验。

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-security-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 probe = '''from pathlib import Path
import errno,json,os,subprocess,time
status=dict(line.split(':',1) for line in Path('/proc/self/status').read_text().splitlines() if ':' in line)
try:
 Path('/tmp/forbidden-write').write_text('x')
 raise AssertionError('root filesystem unexpectedly writable')
except OSError as error:
 assert error.errno==errno.EROFS
try:
 os.setuid(0)
 raise AssertionError('unexpected UID escalation')
except OSError as error:
 assert error.errno==errno.EPERM
work=Path('/work'); (work/'data').write_text('writable')
(work/'example.py').write_text("print('interpreted from the writable volume')")
ran=subprocess.check_output(['python3',str(work/'example.py')],text=True).strip()
result={'uid':os.getuid(),'gid':os.getgid(),'cap_eff':int(status['CapEff'].strip(),16),
 'no_new_privs':int(status['NoNewPrivs']),'seccomp':int(status['Seccomp']),
 'root_write_errno':errno.EROFS,'uid_zero_denied':True,
 'volume_value':(work/'data').read_text(),'writable_volume_code':ran}
assert result['uid']==result['gid']==10001
assert result['cap_eff']==0 and result['no_new_privs']==1 and result['seccomp']==2
print(json.dumps(result),flush=True); time.sleep(600)
'''
 podspec = spec(probe)
 podspec['securityContext'] = {'runAsNonRoot': True, 'runAsUser': 10001,
 'runAsGroup': 10001, 'fsGroup': 10001, 'seccompProfile': {'type': 'RuntimeDefault'}}
 podspec['volumes'] = [{'name': 'work', 'emptyDir': {}}]
 c = podspec['containers'][0]
 c['securityContext'] = {'allowPrivilegeEscalation': False, 'readOnlyRootFilesystem': True,
 'capabilities': {'drop': ['ALL']}}
 c['volumeMounts'] = [{'name': 'work', 'mountPath': '/work'}]
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'restricted'}, 'spec': podspec})
 wait_for(lambda: obj(namespace, 'pod', 'restricted'), pod_ready)
 observed = json.loads(wait_for(lambda: k('logs', '-n', namespace, 'restricted').stdout.strip(), bool))
 conflicting = spec()
 conflicting['securityContext'] = {'runAsNonRoot': True, 'runAsUser': 0}
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'conflict'}, 'spec': conflicting})
 refused = wait_for(lambda: obj(namespace, 'pod', 'conflict'), lambda p:
 any(c.get('state', {}).get('waiting', {}).get('reason') == 'CreateContainerConfigError'
 for c in p.get('status', {}).get('containerStatuses', [])))
 waiting = refused['status']['containerStatuses'][0]
 assert 'runAsUser breaks non-root policy' in waiting['state']['waiting']['message']
 assert waiting['restartCount'] == 0
 print(json.dumps({'runtime_observation': observed,
 'conflicting_uid_accepted_by_api_but_container_start_refused': True,
 'container_escape_resistance_tested': False}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

受约束 Pod 报告 UID 和 GID 均为 10001，有效能力为零，NoNewPrivs 为一，seccomp 模式为二。在根文件系统的 /tmp 下写入返回 EROFS，尝试切换到零号用户返回 EPERM。这些结果反映组合身份和权限设置的效果，不能单独归因为其中某个标志，也没有逐一隔离测量每个字段的独立贡献。

进程成功写入 /work 中的数值，并调用 Python 执行刚写在该卷里的文件。这个允许操作刻意展示工作卷仍然可用，以及只读根声明的边界。第二个 Pod 同时声明 runAsNonRoot 和 runAsUser 零，API 接受对象，但 kubelet 在容器启动前报告 CreateContainerConfigError，说明对象保存成功和进程成功启动是不同阶段。

全部断言通过，命名空间随后删除。实验验证这些具体运行时约束和启动失败，没有测试容器逃逸抵抗能力、每一条 seccomp 规则、敌对多租户隔离或应用授权模型。真实交付需要将这些设置与对应访问需求一起审阅，并保留允许与拒绝操作各自的实际证据。

来源

Kubernetes: Security Context，Pod 与容器安全字段及运行时效果，已核验 2026-09-13。
Linux: No New Privileges Flag，通过执行程序获取新权限的限制，已核验 2026-09-13。
Linux: capabilities(7)，独立能力权限与进程能力集合，已核验 2026-09-13。

水平自动伸缩按需扩缩容

Thu, 04 Nov 2027 00:00:00 +0000

自动伸缩器根据当前用量与目标值推算出期望副本数，因此选对指标，往往比一开始把副本数定成多少更重要。

指标决定副本数

HPA 并不直接盯着负载看,它按周期采样你配置的指标,把实时读数与你设定的目标值比出比率,再由它推导出期望副本数:超过目标就扩容,不足就缩容,分母是当前 pod 的平均值。所以在它背后,选哪个指标、怎么聚合(按 pod 还是按集群)、以及取多长的窗口,才是真正决定「什么算负载」的东西。算出来的副本还会被 maxReplicas 与最小副本数夹住,并在默认同步周期里逐次校准。想让伸缩可预测,靠的是理解这条指标本身,而不是记住某一个常数。

扩容更激进、缩容更克制

缩容被刻意设计得不对称:控制器绝不会在利用率刚刚下降的那一瞬间动手,因为它要躲开瞬时尖峰,免得副本数像橡皮筋一样来回震荡。它会等一个稳定窗口(downscale-stabilization),守住 minReplicas 这条底线,然后才真正缩。扩容总是更快,因为排队那一刻用户已经感到了慢;缩容放慢,是因为留着多余副本远比让集群来回颠簸便宜。一套务实的参数是:下限留足真实尖峰的余量,目标值取一个能消化负载的比值,并把稳定窗口当成「我容忍多少负载噪声」的加注,而不是凭手感乱调的旋钮。

指标才是薄弱环节

整台控制器只会继承你喂给它的指标,指标怎样,伸缩器就怎样追。指标滞后于真实需求,控制器就总是在追赶慢半拍的数字;指标找一个与真正瓶颈相关性很差的代步量,伸缩器就是在缩错的东西。所以 HPA 最难的不是那几行 YAML,而是选哪个指标、定多少目标。给一条延迟敏感的服务配 CPU 目标、给 I/O 敏感的工作配内存目标,往往会让伸缩器朝反方向走。先搞清真正先饱和的是什么——队列深度、在途请求、连接占用——选择你可以在一个窗口内行动的平均值,并验证「当这个指标上升时,真实延迟确实跟着变坏」。到那时,HPA 才是伸缩你的流量的工具,而不是一台在废坐标上乱猜的机器。

坏掉的样子

指标一旧，伸缩就开始来回晃。管线延迟一两分钟时，控制器拿到的永远是上一波负载：尖峰过去，它才把副本加上去；加上去又被缩容稳定窗口按住，迟迟下不来。面板上不是跟随负载的曲线，而是一上一下的震荡。这时调目标值没有用，应当先修指标时延与采样窗口，再谈目标定多少。

指标直接缺失是更危险的一种。拉不到指标时，控制器会拒绝动作并报出 ScalingActive=False，这是保护而不是缺陷。最典型的故障是把“没有数据”当成“没有负载”：有人看到利用率掉零就手动缩容，结果把正在服务的容量一起删掉。正确姿势是把缺失当成未知，保持上一次决策，同时去查指标管线与事件流，而不是继续动副本数。

上下限会从另一个方向卡死控制循环。maxReplicas 当初为了省钱设得太小，真尖峰到来时期望副本被死死夹在上限，ScalingLimited=True 一直亮着，排队与超时却在上涨；minReplicas 设得太大，则会掩盖目标值估错的问题，因为底座托住了副本，你永远看不到需求下降后控制器敢不敢缩。最后不要让两个控制器拧同一个旋钮：HPA 管个数、VPA 改 request，请求值一动，利用率分母就变，两边互相追打；滚动更新太激进时，新 Pod 尚未接流量，老 Pod 仍在承压，平均值被稀释后误判为可缩容，副本走出锯齿。看到这种抖动，先把控制面分开排查，再调目标。

快速验证

把下面代码保存到临时目录的 hpa_loop.py，运行 python3 hpa_loop.py。它只用标准库模拟一条控制循环：期望副本等于当前副本数乘以当前指标除以目标值再向上取整，再用上下限夹住；指标缺失时保持上次决策；缩容必须等稳定窗口过期，否则先按住不动。脚本断言：热指标扩容、冷却期内冷指标不缩、窗口过期后可缩、超限被上下限夹住。

import math

TARGET = 50.0
MIN_REPLICAS = 2
MAX_REPLICAS = 10
STABILIZATION_S = 300


def desired(current_replicas, current_util):
 raw = math.ceil(current_replicas * current_util / TARGET)
 return max(MIN_REPLICAS, min(MAX_REPLICAS, raw))


def step(state, now, current_util):
 replicas, last_scale = state
 if current_util is None:
 print(f"t={now}s metric=missing hold={replicas}")
 return state
 want = desired(replicas, current_util)
 if want < replicas and now - last_scale < STABILIZATION_S:
 print(f"t={now}s metric={current_util} want={want} hold={replicas} (cooldown)")
 return state
 print(f"t={now}s metric={current_util} {replicas}->{want}")
 if want != replicas:
 return (want, now)
 return state


def main():
 state = (3, -10**9)
 state = step(state, 0, 100)
 assert state[0] == 6, state
 state = step(state, 60, 15)
 assert state[0] == 6, state
 state = step(state, 400, 15)
 assert state[0] == 2, state
 state = step(state, 460, None)
 assert state[0] == 2, state
 assert desired(2, 500) == 10
 assert desired(2, 5) == 2
 print("PASS: scale-up 3->6, cooldown holds 6, then 6->2; clamps at 10 and 2")


if __name__ == "__main__":
 main()

运行逐行打印每次决策，最后输出 PASS。热样本把三副本推到六，紧接着的冷样本因窗口没过而停在六，同一冷值在窗口过期后缩到二，超大指标夹在上限十，超小指标托在下限二。该实验只验证算术与冷却语义，不验证管线延迟与启动耗时。上集群调参前，再用描述命令与利用率曲线对照假设表。

来源

Kubernetes 水平自动伸缩文档，HPA 如何推演副本数，已核验 2026-05-06。
HorizontalPodAutoscaler 演练，多指标与状态条件的完整示例，已核验 2026-05-06。

Kubernetes 标签定义选择关系，不代替授权

Thu, 09 Sep 2027 00:00:00 +0000

标签是 Kubernetes 用于选择对象的键值元数据。Service 选择器、运维查询和工作负载控制器都可能依赖标签，但每个消费者有自己的 API 和处理方式。因此，标签变化可能改变对象所属集合，同时底层进程仍然健康。审阅时应把标签视为真实消费者的输入，而不是仅用于展示的贴纸，否则看似简单的文字修改也可能改变路由。

确认正在使用哪一种选择语言

标签键采用限定名称格式，值也有字符和长度约束。标签值可以为空；不为空时，其允许字符及首尾位置受到限制，最大长度为六十三个字符。任意长段落或不受约束的 JSON 并不适合放在标签值里。描述性信息可以采用 annotation，但仍然要遵守对应格式和消费契约，不能把换字段当成取消所有限制。

等值条件检查某个键是否具有指定值，集合条件还支持成员关系与存在性检查。同一个选择器里的多个条件需要同时满足。有一个容易忽略的细节：track!=canary 也会匹配根本没有 track 键的对象。如果不允许键缺失，应另外要求这个键存在，不能认为“不等于某值”就已经隐含“这个键肯定存在”。

不同资源的选择字段结构并不相同。普通带选择器的 Service 使用等值映射，不能把完整集合表达式随意塞进某个映射值。另一些 API 提供 LabelSelector 结构，而 kubectl 列表查询能够接受选择表达式。把命令行中方便使用的查询转换成清单之前，应核对目标字段的真实结构，避免把同一个概念误当成完全相同的输入格式。

坏掉的样子

Service 选择器会识别本命名空间中匹配的 Pod，端点机制再跟踪地址与就绪状态。标签匹配本身不证明服务已经准备好，也不证明端口配置正确。在普通就绪策略下，路由可用目标还取决于端点条件。检查时应查看相应 EndpointSlice 和应用探测结果，不能在一次标签查询成功后就停止验证。

publishNotReadyAddresses 设置会改变服务发现对就绪状态的处理。在这种配置下，不能仅凭端点被标成就绪，就断言对应容器已经通过应用探测。下面实验采用普通默认行为，没有测试这个覆盖设置，因此结果也不应无条件推广到使用该选项的服务。

给健康 Pod 修改标签，可能把它移出 Service，却并不终止进程。过宽的条件则可能把原本不该提供服务的工作负载加入后端。如果 Pod 由控制器管理，手工改标签还可能影响所属关系与协调行为。应通过负责的控制器更新预期状态，并在改变共享键含义之前核对主要消费者，避免修好一个查询却破坏另一条路由。

选择器不是网络授权。某个 Pod 即使不属于一个 Service，也可能继续通过自身地址或其他 Service 被访问，除非另有控制阻止。NetworkPolicy、应用授权和路由分别解决不同部分，不能把选择器描述成能够拒绝所有未选中对象直连流量的访问名单。对象是否被发现，与请求最终是否允许，必须分别成立。

快速验证

准备可丢弃的 Kubernetes 集群，确保 kubectl 可用，节点已有 python:3.11-slim-bookworm 镜像。保存代码为 label-selectors.py，执行 python3 label-selectors.py KUBECONFIG_PATH CONTEXT，明确传入测试集群配置与上下文。脚本在独有命名空间创建三个独立 HTTP Pod 和一个 Service，结束后删除它们。实测服务端版本是 Kubernetes 1.34.11。

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-labels-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 for name, role, track in [('a', 'reader', 'stable'), ('b', 'reader', 'canary'), ('c', 'writer', None)]:
 script = '''from http.server import BaseHTTPRequestHandler,HTTPServer
class Handler(BaseHTTPRequestHandler):
 def do_GET(self):
 data=LABEL.encode();self.send_response(200);self.send_header('Content-Length',str(len(data)));self.end_headers();self.wfile.write(data)
 def log_message(self,*args): pass
HTTPServer(('0.0.0.0',8080),Handler).serve_forever()
'''.replace('LABEL', repr(name))
 podspec = spec(script)
 podspec['containers'][0]['readinessProbe'] = {'httpGet': {'path': '/', 'port': 8080}, 'periodSeconds': 1}
 labels = {'app': 'catalog', 'role': role}
 if track:
 labels['track'] = track
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': name, 'labels': labels}, 'spec': podspec})
 for name in ('a', 'b', 'c'):
 wait_for(lambda name=name: obj(namespace, 'pod', name), pod_ready)
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Service', 'metadata': {'name': 'readers'},
 'spec': {'selector': {'app': 'catalog', 'role': 'reader'}, 'ports': [{'port': 80, 'targetPort': 8080}]}})
 def selected():
 slices = obj(namespace, 'endpointslices', selector='kubernetes.io/service-name=readers')['items']
 return {e['targetRef']['name'] for item in slices for e in item.get('endpoints', [])
 if e.get('conditions', {}).get('ready') and e.get('targetRef')}
 before = wait_for(selected, lambda names: names == {'a', 'b'})
 inequality = {p['metadata']['name'] for p in obj(namespace, 'pods', selector='app=catalog,track!=canary')['items']}
 assert inequality == {'a', 'c'}
 expression = {p['metadata']['name'] for p in obj(namespace, 'pods', selector='app in (catalog),role=reader')['items']}
 assert expression == {'a', 'b'}
 writer_ip = obj(namespace, 'pod', 'c')['status']['podIP']
 probe = 'from urllib.request import urlopen; print(urlopen(' + repr('http://'+writer_ip+':8080/') + ',timeout=3).read().decode())'
 assert k('exec', '-n', namespace, 'a', '--', 'python3', '-c', probe).stdout.strip() == 'c'
 k('label', 'pod', 'b', '-n', namespace, 'role=writer', '--overwrite')
 after = wait_for(selected, lambda names: names == {'a'})
 assert pod_ready(obj(namespace, 'pod', 'b'))
 invalid = k('patch', 'pod', 'a', '-n', namespace, '--type=merge',
 '-p', json.dumps({'metadata': {'labels': {'notes.example/value': 'has spaces'}}}), expected=None)
 assert invalid.returncode != 0 and 'Invalid' in invalid.stderr
 print(json.dumps({'service_targets_before': sorted(before), 'service_targets_after': sorted(after),
 'inequality_also_matches_missing_key': sorted(inequality),
 'set_selector_matches': sorted(expression), 'excluded_pod_directly_reachable': True,
 'invalid_label_value_rejected': True}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

Pod a 与 b 的 role 为 reader，c 为 writer；三者共享 app=catalog，并通过 HTTP 就绪探测。a 的 track 为 stable，b 为 canary，c 则没有这个键。reader Service 最初具有 a、b 两个就绪目标。集合式查询能够找到这两个 reader，而 track!=canary 会找到 a、c，实际确认缺少键时也会匹配不等式。

从 a 向 c 的 Pod 地址发起真实 HTTP 请求，会返回 c，即使 c 不属于 reader Service。随后把 b 的 role 改为 writer，Service 的就绪端点集合只剩 a，但 b 自己仍然处于就绪状态。另一个包含空格标签值的补丁被 API 拒绝。所有断言都已运行通过，结果同时覆盖查询、控制器维护的端点和实际网络请求。

实验验证了隔离测试网络中的 API 选择、EndpointSlice 变化和直连可达性，没有测试所有控制器的接管规则，没有执行网络策略隔离，也没有测量 Service 性能。审阅真实路由变化时，应分别观察选择意图、端点就绪和访问政策，使每一层都有可检查的结果，而不是靠某个标签名称推断完整安全边界。

来源

Kubernetes: Labels and Selectors，合法值、等值及集合式选择条件，已核验 2026-09-13。
Kubernetes: Services，基于选择器的后端发现，已核验 2026-09-13。
Kubernetes: EndpointSlices，端点身份及就绪条件，已核验 2026-09-13。

命名空间划分对象范围，其他边界需要政策

Wed, 25 Aug 2027 00:00:00 +0000

命名空间为 Kubernetes 集群中的许多对象限定范围。两个团队都可以创建名为 settings 的 ConfigMap，因为包含命名空间后的完整身份不同。这种组织边界很有价值，但不会自动提供网络隔离、独立内核、专属节点容量或完整租户隔离。工作负载实际需要哪一种保障，就应确认额外由什么政策和执行机制落实，而不是把它们都归因于命名空间。

名称范围取决于资源类型

Pod、Service、ConfigMap 和许多工作负载控制器属于命名空间资源。Node、命名空间本身以及其他集群级资源，则不会因为客户端指定了某个命名空间，就被划分成另一份独立副本。应查看具体资源的 API 范围，不能假定所有对象都住在某个房间里面。命名空间也不是由独立子集群构成的嵌套层级。

在 Pod 内部，服务短名称通常按所在命名空间解析。带限定的名称可以指向别处，例如默认集群域下的 api.other.svc.cluster.local。这种约定负责定位目的地址，并不决定允许还是拒绝连接。集群域也可以另行配置，因此示例中的后缀不是所有安装都必须采用的常量。诊断 DNS 时需要结合实际域和工作负载所在位置。

自动化中的命名空间选择应保持明确。对象名称即使正确，如果当前活动命名空间错误，仍然会访问另一个资源。尤其是修改操作，应有意指定 kubeconfig、上下文和命名空间，而不是依赖操作者终端之前留下的状态。对象范围让身份更清楚，但具有广泛权限的管理员依然能够跨范围修改内容，不能因此省略权限审查。

坏掉的样子

没有适用网络政策的命名空间，仍然按照集群网络本身的行为保持连通。仅创建命名空间，或在 DNS 中加入它的名称，并不会拒绝其他 Pod。网络隔离需要正确的政策，以及真正执行这些政策的网络实现。应用认证还是另一层：域名能解析，只说明找到了地址，并不能证明某个调用者应该获准读取返回内容。

RBAC 则单独控制 API 操作。一个 RoleBinding 可以让账号读取本命名空间的 ConfigMap，而不给它读取其他范围的能力。但权限是叠加的，另一个广泛绑定仍可能授予更多访问。应以目标身份实际验证允许和拒绝的请求，不能认为添加一份较小角色，就自动取消先前更大的授权。网络流量政策也不会代替这一层 API 权限。

ResourceQuota 主要在准入阶段约束对象数量，以及汇总的资源请求或限制等指标。它本身不会节流正在运行的进程，也不会预留物理节点容量。LimitRange 可以为新接纳的工作负载提供默认值和边界，运行时资源限制则由其他机制执行。这些政策都需要明确配置；只有一个命名空间，并不能让会争抢共享资源的邻居自动变得无害。

快速验证

准备使用默认 cluster.local 域的临时 Kubernetes 集群，确保 kubectl 管理员能够执行测试 impersonation，节点已有 python:3.11-slim-bookworm 镜像。把代码保存为 namespaces.py，执行 python3 namespaces.py KUBECONFIG_PATH CONTEXT，明确传入测试配置。实测集群是 Kubernetes 1.34.11，采用 kind 网络。脚本创建两个唯一命名空间，并在结束后删除两者。

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'}}}]}

suffix = uuid4().hex[:8]
first, second = 'notes-a-' + suffix, 'notes-b-' + suffix
created = []
try:
 for namespace, value in [(first, 'A'), (second, 'B')]:
 k('create', 'namespace', namespace)
 created.append(namespace)
 apply(namespace, {'apiVersion': 'v1', 'kind': 'ConfigMap', 'metadata': {'name': 'settings'}, 'data': {'scope': value}})
 script = '''from http.server import BaseHTTPRequestHandler,HTTPServer
class Handler(BaseHTTPRequestHandler):
 def do_GET(self):
 data=VALUE.encode();self.send_response(200);self.send_header('Content-Length',str(len(data)));self.end_headers();self.wfile.write(data)
 def log_message(self,*args): pass
HTTPServer(('0.0.0.0',8080),Handler).serve_forever()
'''.replace('VALUE', repr(value))
 podspec = spec(script)
 podspec['containers'][0]['readinessProbe'] = {'httpGet': {'path': '/', 'port': 8080}, 'periodSeconds': 1}
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'web', 'labels': {'app': 'web'}}, 'spec': podspec})
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Service', 'metadata': {'name': 'api'},
 'spec': {'selector': {'app': 'web'}, 'ports': [{'port': 80, 'targetPort': 8080}]}})
 wait_for(lambda namespace=namespace: obj(namespace, 'pod', 'web'), pod_ready)
 wait_for(lambda namespace=namespace: obj(namespace, 'endpointslices', selector='kubernetes.io/service-name=api')['items'],
 lambda slices: any(e.get('conditions', {}).get('ready') for s in slices for e in s.get('endpoints', [])))
 assert obj(first, 'configmap', 'settings')['data']['scope'] == 'A'
 assert obj(second, 'configmap', 'settings')['data']['scope'] == 'B'
 nodes_a = {n['metadata']['uid'] for n in obj(first, 'nodes')['items']}
 nodes_b = {n['metadata']['uid'] for n in obj(second, 'nodes')['items']}
 assert nodes_a == nodes_b and nodes_a
 apply(first, {'apiVersion': 'v1', 'kind': 'ServiceAccount', 'metadata': {'name': 'reader'}, 'automountServiceAccountToken': False})
 apply(first, {'apiVersion': 'rbac.authorization.k8s.io/v1', 'kind': 'Role', 'metadata': {'name': 'read-config'},
 'rules': [{'apiGroups': [''], 'resources': ['configmaps'], 'verbs': ['get']}]})
 apply(first, {'apiVersion': 'rbac.authorization.k8s.io/v1', 'kind': 'RoleBinding', 'metadata': {'name': 'read-config'},
 'subjects': [{'kind': 'ServiceAccount', 'name': 'reader', 'namespace': first}],
 'roleRef': {'apiGroup': 'rbac.authorization.k8s.io', 'kind': 'Role', 'name': 'read-config'}})
 identity = 'system:serviceaccount:' + first + ':reader'
 assert k('--as', identity, 'get', 'configmap', 'settings', '-n', first).returncode == 0
 denied = k('--as', identity, 'get', 'configmap', 'settings', '-n', second, expected=None)
 assert denied.returncode != 0 and 'Forbidden' in denied.stderr
 apply(first, {'apiVersion': 'v1', 'kind': 'ResourceQuota', 'metadata': {'name': 'one-service'},
 'spec': {'hard': {'services': '1'}}})
 wait_for(lambda: obj(first, 'resourcequota', 'one-service'), lambda q: q.get('status', {}).get('used', {}).get('services') == '1')
 extra = {'apiVersion': 'v1', 'kind': 'Service', 'metadata': {'name': 'extra', 'namespace': first},
 'spec': {'ports': [{'port': 80}]}}
 quota_denial = k('create', '-f', '-', payload=extra, expected=None)
 assert quota_denial.returncode != 0 and 'exceeded quota' in quota_denial.stderr
 assert not obj(first, 'networkpolicies')['items'] and not obj(second, 'networkpolicies')['items']
 remote = 'api.' + second + '.svc.cluster.local'
 probe = '''import json,socket
from urllib.request import urlopen
print(json.dumps({'short_name':socket.gethostbyname('api'),
 'qualified_name':socket.gethostbyname(REMOTE),
 'cross_namespace_body':urlopen('http://'+REMOTE+'/',timeout=3).read().decode()}))'''.replace('REMOTE', repr(remote))
 network = json.loads(k('exec', '-n', first, 'web', '--', 'python3', '-c', probe).stdout)
 assert network['short_name'] == obj(first, 'service', 'api')['spec']['clusterIP']
 assert network['qualified_name'] == obj(second, 'service', 'api')['spec']['clusterIP']
 assert network['cross_namespace_body'] == 'B'
 print(json.dumps({'same_names_different_configmaps': True, 'nodes_are_cluster_scoped': True,
 'rbac_allows_local_and_denies_other_namespace': True,
 'quota_rejects_second_service': True, 'short_and_qualified_dns_match_services': True,
 'cross_namespace_http_succeeds_without_network_policy': True}))
finally:
 for namespace in reversed(created):
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

每个命名空间都有名为 settings 的 ConfigMap、名为 web 的 Pod 和名为 api 的 Service。两份配置分别保留 A 与 B 值。带着任一命名空间查询 Node，得到的仍是同一组集群级节点身份。这验证了名称范围，而没有把共享节点想象成两套各自独立的容量池。

测试服务账号只获准读取第一个命名空间的配置。以它的身份发出的请求，在本地成功，在第二个范围返回 Forbidden。随后 ResourceQuota 把第一个命名空间的 Service 数量限制为一；确认已有使用量后，再创建另一个服务会被拒绝。这验证真实准入决策，而不是仅检查配额对象已经存在。

最后，从第一个 Pod 发出的请求把短名称 api 解析为本地 Service，把第二个命名空间的完整服务名称解析到对应地址，并通过 HTTP 收到 B。两个命名空间都没有 NetworkPolicy，全部断言运行通过。这个结果展示命名、API 授权、一种数量配额及网络可达性各自独立成立。

实验没有证明网络政策已经被执行，没有验证 CPU 公平性，也没有建立面对敌对租户的完整隔离。真实系统需要哪些边界，就应分别审查并实际测试，不能用属于不同命名空间这一事实代替所有安全和容量要求。

来源

Kubernetes: Namespaces，对象名称范围与集群级资源，已核验 2026-09-13。
Kubernetes: Resource Quotas，命名空间准入限制与对象数量，已核验 2026-09-13。
Kubernetes: RBAC authorization，命名空间角色绑定与权限叠加，已核验 2026-09-13。
Kubernetes: Network Policies，网络隔离需要政策及实际执行它的实现，已核验 2026-09-13。
Kubernetes: DNS for Services and Pods，短名称、命名空间限定的服务名称与集群域，已核验 2026-09-13。

Kubernetes Service 为 Pod 提供稳定入口

Mon, 23 Aug 2027 00:00:00 +0000

既然 Pod 会重建，就很难记住它的地址。Service 在这组 Pod 前面固定一个名字，让调用方不因 Pod 更换而受影响。

一个地址，一组 Pod

多副本带来了多个 Pod,而每个 Pod 都有自己的 IP,还会随时被重建。Service 正是它们前面那个稳定的家:你声明一个选择器,平台就分给它一个固定的集群 IP 和一段可被 DNS 解析的名字。集群 DNS 把名字解析到 Service 上,因此组件(Ingress、负载均衡、别的 Pod)只依赖这个名字,而从不关心具体某个 Pod 的地址。抽象的全部意义就在于:名字是持久的,背后站着的每一样东西都可以即丢即换。

选择规则决定由谁响应

Pod 靠「匹配」加入 Service,而不是靠被人点名登记:标签打中了选择器,它就进入;不再匹配或不再就绪,就被移出。平台从选择器推出后端这份视图,当一个 Pod 通过探针与就绪,就把它加进去,缩容或下线时就拿掉。所以后端列表是一份实时推导的视图,而不是从头到尾手打的名单。也正因为后端由选择器与就绪共同决定,一个没就绪的 Pod 会自己掉出去,流量绝不会被送到不该服务的 Pod 上。

流量总给当前匹配的

这层间接,正是让端点变化落不到调用方身上的原因。客户端只握着那个名字;它背后的集合被扩、被替、被滚动更新,都不需要改客户端设一个字。滚动更新一个接一个地替换掉又续上 Pod,Service 始终把流量导向当前匹配且就绪的那批,于是调用方察觉不到任何断层。你可以依赖这件事:只要选择器精准、Pod 与它匹配,Service 在每个时刻都把流量送进正确的那批。把选择器钉紧、探针管严,这个稳定的家便能在里面的 Pod 全是新面孔时依旧稳如磐石。

稳定名字是对调用方的承诺

虚拟地址如何分配是另一回事,本篇要讲的是这个稳定入口对调用方意味着什么。一个守规矩的客户端只需要在启动时解析一次 Service 名字,此后整个生命周期都握着它,即使后端被全部换掉也不必改配置、不必重启。承诺成立需要三个习惯同时成立:选择器始终精确命中目标 Pod,就绪状态始终把未就绪者挡在集合之外,调用方不偷存某次看到的 Pod 地址直连。把 Service 名字当作唯一受支持的访问方式,扩缩容、崩溃重启、滚动发布都可以发生在名字背后,而调用方看到的始终是同一个家。

坏掉的样子

最安静的故障是选择器谁也选不中。比如把 app: web 写成 app: webs,或者 Deployment 不再给 Pod 打预期标签,Service 的端点集合就会变成空。此时集群 IP 与 DNS 名字依然能解析,故障表现为连接被拒绝或超时,而不是名字不存在。当 Service 能解析却送不出流量时,先看它的端点集合:空集合说明问题在标签,而不在网络。

第二个常见陷阱是顺手写成的无头 Service。一旦设置 clusterIP: None,虚拟 IP 就不存在了,DNS 直接返回不断变化的 Pod 地址,每个客户端都要自己做负载均衡。为单一稳定入口编写的代码,突然要面对多个漂移地址,重试不均、连接复用失效都会跟着来。只有调用方明确想要服务发现时才用无头形式,不要把它当成默认写法。

端口配错是从另一侧打破承诺。Service 的 port 指向了容器根本没有监听的 targetPort,流量进来也永远送不到;手选的 NodePort 还可能和同一批节点上的另一个 Service 撞车。最后,不要给无状态服务留下 sessionAffinity: ClientIP:每个客户端会被粘到同一个后端上,均衡的副本池变成冷热不均的分片,一个 Pod 要死不活,看起来就像整组服务都挂了。除非业务真的要求粘性会话,否则一律关闭亲和。

快速验证

把下面程序保存到临时工作目录的 service_endpoints.py,运行 python3 service_endpoints.py。它只用字典模拟 Service 端点收敛,不修改进程之外的任何东西:一个函数根据选择器、Pod 标签与就绪状态推导端点集合,四个场景依次演练它,其中故意留空的选择器是反例,用于证明空选择器必须告警,而不是悄悄匹配到奇怪的结果。

"""用选择器加就绪状态模拟 Service 端点收敛。"""

PODS = [
 {"name": "web-1", "labels": {"app": "web"}, "ready": True},
 {"name": "web-2", "labels": {"app": "web"}, "ready": True},
 {"name": "web-3", "labels": {"app": "web"}, "ready": False},
 {"name": "worker-1", "labels": {"app": "worker"}, "ready": True},
]


def select_endpoints(pods, selector):
 """推导端点集合；空选择器告警而不是默默匹配。"""
 if not selector:
 return [], "warning: empty selector matches nothing"
 matched = sorted(
 pod["name"]
 for pod in pods
 if pod.get("ready")
 and all(pod.get("labels", {}).get(key) == value for key, value in selector.items())
 )
 return matched, ""


def check(condition, message):
 if not condition:
 raise AssertionError(message)


def main():
 endpoints, warning = select_endpoints(PODS, {"app": "web"})
 check(endpoints == ["web-1", "web-2"], "就绪的 web Pod 应组成集合")
 check(warning == "", "精确的选择器不应告警")
 print("steady state:", endpoints)

 rolling = [dict(pod, ready=True) if pod["name"] == "web-3" else pod for pod in PODS]
 rolling = [pod for pod in rolling if pod["name"] != "web-1"]
 endpoints, _ = select_endpoints(rolling, {"app": "web"})
 check(endpoints == ["web-2", "web-3"], "滚动应以新就绪 Pod 替换旧 Pod")
 print("after rollover:", endpoints)

 endpoints, _ = select_endpoints(PODS, {"app": "web", "track": "stable"})
 check(endpoints == [], "过窄的选择器应收敛为空，而不是报错")
 print("over-narrow selector:", endpoints)

 endpoints, warning = select_endpoints(PODS, {})
 check(endpoints == [] and "empty selector" in warning, "空选择器必须大声告警")
 print("empty selector:", repr(warning))

 print("PASS: four convergences; readiness-gated selection, rollover, and empty warning hold")


if __name__ == "__main__":
 main()

四个场景的收敛结果和健康 Service 完全一致:稳态时两个就绪的 web Pod 在集合里,未就绪者被挡在外面;滚动时选择器不变,集合从一个就绪 Pod 换成另一个;过窄的选择器会清楚地收敛为空。空选择器是反例:它大声告警,而不是悄悄匹配全部或悄悄返回空。这些断言已在 macOS、Python 3.14.4 下运行通过。

这个模拟只验证标签加就绪的收敛逻辑,不实现 kube-proxy、集群 DNS 与真实探针时序,也不覆盖生产环境的端口冲突。发布前还要对照 Pod 标签与就绪状态检查真实端点集合,并用真正的 Service 名字在两个语言环境里各走一遍查询。

来源

Kubernetes：Services，Service 抽象，已核验 2027-08-15。
Kubernetes：Pods，Service 所选择的 Pod，已核验 2027-08-15。
Kubernetes：Deployments，管理 Pod 集合，已核验 2027-08-15。

启动探针成功后，其他探针才开始执行

Sun, 22 Aug 2027 00:00:00 +0000

Startup 探针为容器提供单独的初始化契约。在已经配置的启动探针成功之前，Kubernetes 不会执行这个容器的 liveness 或 readiness 探针。这比“宽限期内忽略一些存活失败”更具体：另外两种检查根本还没有开始。启动检查成功之后，后续健康和就绪判断才按各自规则接管，不能把三个名称理解成同一个接口的不同标签。

为每个阶段定义可观察条件

应用进程必须先运行，启动探针才可能成功。因此，容器已经 Running 时，container status 中的 started 仍可能为 false，所在 Pod 也可能尚未 Ready。运行状态描述进程正在执行，启动成功则描述配置的检查条件已经满足。提前开放的 HTTP 监听端可以报告进度，但不应该因此自动声称全部准备已经完成。

启动条件应代表必要的本地准备，例如加载索引或验证初始状态。只有打开端口确实就是所需前置条件时，单纯检查端口才足够。如果监听器先出现，昂贵的初始化稍后才结束，过早成功的检查就会提前解除存活保护，再次造成原本想避免的重启循环。接口名称不会替应用定义初始化完成的真实含义。

启动检查一旦成功，kubelet 就停止当前容器实例的 startup 探针，并按独立配置运行存活与就绪检查。启动成功不是永久健康证明：应用稍后仍可能变成未就绪，或者需要重启。新的容器实例还要重新完成自己的启动检查，不能继承上一实例已经成功的结论。把实例身份和状态变化一起记录，才能解释重复启动的原因。

坏掉的样子

启动探针如果一直不成功，最终会达到失败阈值。Kubelet 随后终止容器，并根据对应重启策略处理。因此，启动保护不是允许初始化无限等待。周期、超时和失败阈值应依据真实初始化耗时设置，同时考虑环境中可能发生的资源争用与可以接受的恢复时间，避免只按开发机器的一次快速启动选择参数。

failureThreshold 与 periodSeconds 的乘积可用于规划启动预算，但不能把它写成所有实际重启都严格遵守的秒表。初始延迟、探针执行与调度、终止宽限和重启退避也影响完整时间线。排查慢发布时，应记录真实尝试和状态变化，而不是仅根据两个配置数字推断容器应该已经重启，或断定平台行为错误。

除非通过 startup 明确建立依赖，否则不应认为 liveness 会等 readiness 成功才开始。就绪与存活原本回答两个持续运行阶段的问题。反过来，启动成功也不会强迫就绪成功：后续 readiness 可能因为另一个条件拒绝流量资格，而进程仍然正常存活。把这些结果分开，才能选择正确恢复动作，避免用反复重启处理暂时不可服务。

修改探针也需要应用实际配合。一个永远返回成功的接口，不会因为名称叫 startup，就具备验证初始化步骤的能力。状态转换应有明确实现，并提供足够诊断信息解释为什么仍在等待。接口还应避免向非预期调用方暴露凭据或敏感初始化内容。下面的测试仅输出计数和合成状态，便于核对调用顺序。

快速验证

准备可丢弃的 Kubernetes 集群、kubectl，以及节点可用的 python:3.11-slim-bookworm 镜像。保存为 startup-gate.py，执行 python3 startup-gate.py KUBECONFIG_PATH CONTEXT，明确指定测试配置与上下文。账号需要创建、删除命名空间。实测服务端为 Kubernetes 1.34.11，本次短实验设置一秒周期及六十次启动失败阈值，为人工控制的放行留出时间。

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-startup-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 server = '''from http.server import BaseHTTPRequestHandler,HTTPServer
from pathlib import Path
import json
counts={'startup':0,'live':0,'ready':0}
class Handler(BaseHTTPRequestHandler):
 def do_GET(self):
 key=self.path.removeprefix('/'); code=200
 if key in counts:
 counts[key]+=1
 if key=='startup' and not Path('/tmp/start').exists(): code=503
 body=json.dumps(counts).encode(); 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['startupProbe'] = {'httpGet': {'path': '/startup', 'port': 8080}, 'periodSeconds': 1, 'failureThreshold': 60}
 for field, path in [('livenessProbe', '/live'), ('readinessProbe', '/ready')]:
 c[field] = {'httpGet': {'path': path, 'port': 8080}, 'periodSeconds': 1, 'failureThreshold': 2}
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'slow'}, 'spec': podspec})
 wait_for(lambda: obj(namespace, 'pod', 'slow'), lambda p:
 any('running' in c['state'] for c in p.get('status', {}).get('containerStatuses', [])))
 read = 'from urllib.request import urlopen; print(urlopen("http://127.0.0.1:8080/stats",timeout=3).read().decode())'
 def counts():
 result = k('exec', '-n', namespace, 'slow', '--', 'python3', '-c', read, expected=None)
 return json.loads(result.stdout) if result.returncode == 0 else None
 before = wait_for(counts, lambda d: d and d['startup'] >= 3)
 assert before['live'] == before['ready'] == 0
 starting = obj(namespace, 'pod', 'slow')
 assert not pod_ready(starting)
 assert starting['status']['containerStatuses'][0]['started'] is False
 assert starting['status']['containerStatuses'][0]['restartCount'] == 0
 k('exec', '-n', namespace, 'slow', '--', 'python3', '-c',
 'from pathlib import Path; Path("/tmp/start").touch()')
 ready = wait_for(lambda: obj(namespace, 'pod', 'slow'), pod_ready)
 assert ready['status']['containerStatuses'][0]['started'] is True
 enabled = wait_for(counts, lambda d: d and d['live'] > 0 and d['ready'] > 0)
 time.sleep(3)
 after = counts()
 assert after['startup'] == enabled['startup']
 assert after['live'] > enabled['live'] and after['ready'] > enabled['ready']
 assert obj(namespace, 'pod', 'slow')['status']['containerStatuses'][0]['restartCount'] == 0
 print(json.dumps({'before_startup_success': before, 'after_startup_success': after,
 'other_probes_suppressed_before_startup': True,
 'startup_probe_stops_after_success': True, 'container_restarts': 0}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

HTTP 服务分别记录 startup、live、ready 路径的请求次数。统计路径只读取数据，不增加这三个计数。启动路径最初返回 503，直到本地放行文件出现。观察到三次启动请求时，另外两个计数都为零，容器没有重启，started 字段为 false。这直接验证其他探针尚未执行，而不是把它们的失败隐藏起来。

创建放行文件后，下一次启动检查成功。Pod 变成 Ready，started 变成 true，存活与就绪计数开始增加。再等三秒，启动计数保持固定，另外两个计数继续增加。本次最终分别观察到四、四、五次；持续探针的精确次数会受到时序影响，因此断言检查的是变化关系，而不是强制所有运行都得到同一个数字。

全部断言通过，容器没有重启，命名空间随后删除。实验通过真实 HTTP 调用验证了抑制与交接，没有测量生产启动耗时分位数，也没有耗尽启动失败预算。选择真实阈值时需要补充这些观测，同时保持初始化完成与持续服务健康之间的区别，不能用一次启动通过替代后续运行质量。

来源

Kubernetes: Configure Probes，启动失败预算与探针配置，已核验 2026-09-13。
Kubernetes: Pod Lifecycle，启动成功前抑制存活与就绪检查，已核验 2026-09-13。

Kubernetes Secret 需要明确的访问边界

Sat, 21 Aug 2027 00:00:00 +0000

Kubernetes Secret 是用于保存工作负载所需机密值的 API 对象，提供专门的类型、消费路径和访问控制目标。但它不会让所有其他参与者都无法读取内容。设计边界时，需要同时考虑谁能取回对象、谁能创建消费者、谁能查看消费者输出，以及谁能管理运行它们的节点。仅区分配置对象与秘密对象，还不足以完成权限设计。

编码与保护处于不同层次

在 JSON API 表示中，Secret 的 data 使用 base64；stringData 则便于在写入时提交字符串。Base64 无需密钥就能还原，并不是加密。这种表示也不能证明某个具体集群怎样保护底层存储。Kubernetes 文档说明，若未配置相应加密，秘密数据默认不在存储层加密。应核对实际 API 服务器和存储设置，不能看到编码文字就推断保密措施已经生效。

存储加密同样不会阻止获得授权的 API 读取者拿到数据。RBAC 中的 get、list 和 watch 权限都可能暴露 Secret 内容，广泛的列表权限并不只是允许查看对象名称。备份和诊断输出也需要保护。正常应用最终仍要获得可用值，因此，一旦有权消费数据的程序被控制，攻击者就已经进入这份数据的信任边界，不能靠编码再次隔离它。

Secret 适合小规模值，单对象有一 MiB 限制。应只挂载需要的键，并只交付给真正需要它的容器。文件模式可以缩小工作负载内部的读取范围，却不能替代 API 授权或对创建工作负载权限的控制。环境变量注入也有暴露范围和生命周期方面的取舍，应根据应用需求选择，不能默认它一定比文件更安全。

坏掉的样子

禁止直接 get Secret，不一定禁止间接取得内容。主体如果可以在命名空间创建 Pod，通常就能在自己提交的规范中指定一个 Secret 卷，由 kubelet 把数据交给该工作负载。创建相应控制器的权限也可能产生类似效果。因此，除了直接读取数据的规则，还必须一起审查创建工作负载的权限及适用的准入限制，否则边界会漏掉实际消费路径。

把全部键挂进去，会扩大进程能够读取的内容集合。通过 volume items 只选一个键，可以限制这一次投射，但有更大创建权限的主体仍可能提交另一份投射定义。不能把一份范围较小的清单，误当成编写清单的人本身也受到同等范围限制。预期消费者是谁，以及谁能定义消费者，是需要分别处理的两个权限问题。

轮换也不只是修改 API 对象。数据交付、应用重新加载、凭据签发和旧值撤销都有各自时序。环境快照与 subPath 挂载不会像普通投射那样自动刷新；文件更新也不会强迫应用丢弃已经缓存的旧值。只有把签发系统与消费者一起验证，才能判断旧凭据是否确实不再被接受，不能仅以对象更新时间作为轮换完成证据。

快速验证

准备可丢弃的 Kubernetes 集群，并使用有测试 impersonation 权限的管理员连接，确保节点已有 python:3.11-slim-bookworm 镜像。保存为 secret-access.py，执行 python3 secret-access.py KUBECONFIG_PATH CONTEXT，明确指定专用配置和上下文。实测版本为 Kubernetes 1.34.11。这里全部数值都是明确的合成示例，输出只报告检查结果，不打印存储内容。

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'}}}]}

import base64
namespace = 'notes-secrets-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 demo = 'DEMO_ONLY_NOT_A_CREDENTIAL'
 k('create', '-n', namespace, '-f', '-', payload={'apiVersion': 'v1', 'kind': 'Secret', 'metadata': {'name': 'example'},
 'type': 'Opaque', 'stringData': {'needed': demo, 'unused': 'UNUSED_DEMO'}})
 stored = obj(namespace, 'secret', 'example')
 assert base64.b64decode(stored['data']['needed']).decode() == demo
 apply(namespace, {'apiVersion': 'v1', 'kind': 'ServiceAccount', 'metadata': {'name': 'creator'},
 'automountServiceAccountToken': False})
 apply(namespace, {'apiVersion': 'rbac.authorization.k8s.io/v1', 'kind': 'Role',
 'metadata': {'name': 'pod-creator'},
 'rules': [{'apiGroups': [''], 'resources': ['pods'], 'verbs': ['create', 'get']},
 {'apiGroups': [''], 'resources': ['pods/log'], 'verbs': ['get']}]})
 apply(namespace, {'apiVersion': 'rbac.authorization.k8s.io/v1', 'kind': 'RoleBinding',
 'metadata': {'name': 'pod-creator'},
 'subjects': [{'kind': 'ServiceAccount', 'name': 'creator', 'namespace': namespace}],
 'roleRef': {'apiGroup': 'rbac.authorization.k8s.io', 'kind': 'Role', 'name': 'pod-creator'}})
 identity = 'system:serviceaccount:' + namespace + ':creator'
 denied = k('--as', identity, 'get', 'secret', 'example', '-n', namespace, expected=None)
 assert denied.returncode != 0 and 'Forbidden' in denied.stderr
 probe = "from pathlib import Path\nimport json,time\nroot=Path('/example')\nprint(json.dumps({'synthetic_value_matches':(root/'one').read_text()=='DEMO_ONLY_NOT_A_CREDENTIAL',\n 'unused_key_absent':not (root/'unused').exists(),\n 'service_account_token_absent':not Path('/var/run/secrets/kubernetes.io/serviceaccount/token').exists()}),flush=True)\ntime.sleep(600)"
 podspec = spec(probe)
 podspec['serviceAccountName'] = 'creator'
 podspec['volumes'] = [{'name': 'example', 'secret': {'secretName': 'example',
 'items': [{'key': 'needed', 'path': 'one'}], 'defaultMode': 0o400}}]
 podspec['containers'][0]['volumeMounts'] = [{'name': 'example', 'mountPath': '/example', 'readOnly': True}]
 definition = {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'reader', 'namespace': namespace},
 'spec': podspec}
 k('--as', identity, 'create', '-f', '-', payload=definition)
 wait_for(lambda: obj(namespace, 'pod', 'reader'), pod_ready)
 output = wait_for(lambda: k('--as', identity, 'logs', '-n', namespace, 'reader').stdout.strip(), bool)
 observed = json.loads(output)
 assert all(observed.values())
 print(json.dumps({'api_base64_decodes_to_synthetic_value': True,
 'direct_secret_get_forbidden': True, 'same_identity_can_create_consuming_pod': True,
 'mount_observation': observed, 'etcd_encryption_tested': False}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

程序创建包含两个演示键的 Secret，确认 API 中的 base64 可以还原成给定的合成文字。然后为服务账号绑定一个角色，允许创建 Pod 和读取 Pod 日志，却不给读取 Secret 的权限。管理员以这个账号身份发出的直接读取请求会返回 Forbidden，因此这一步实际验证了对应的 API 授权拒绝。

同一个被模拟的主体接着创建 Pod，只投射需要的键。由它指定的工作程序确认：读到预期演示值，未需要的键没有出现，也不存在自动挂载的服务账号令牌。该主体再通过获准的日志接口读取这些布尔结果。全部检查通过，展示了直接请求被拒绝之后，工作负载路径仍然能够取得指定内容，而不是仅从权限配置进行猜测。

命名空间最后被删除。本实验没有使用真实凭据或实际签发的服务账号令牌，也没有测试底层存储加密和轮换流程。它建立的是授权与投射行为的证据，不是一套完整秘密管理系统。在称某份数据已经严格限定范围之前，应同时评估直接读取者，以及能够创建或修改读取者的主体。

来源

Kubernetes: Secrets，API 表示、消费方式和访问含义，已核验 2026-09-13。
Kubernetes: Good practices for Secrets，加密、最小权限与工作负载访问，已核验 2026-09-13。
Kubernetes: RBAC authorization，资源操作、角色绑定和命名空间范围，已核验 2026-09-13。

ConfigMap 把配置与镜像分开

Fri, 20 Aug 2027 00:00:00 +0000

ConfigMap 把非敏感配置放在镜像之外，让环境相关设置发生变化时，不必重新构建应用产物。真正有用的边界需要明确：镜像提供代码，工作负载定义则指定这些代码应该读取哪份配置。因此，一次发布不仅是一个镜像标签，配置引用同样属于正在交付的行为。只记录镜像版本，可能无法解释两个环境为什么表现不同。

给配置一个可审阅的身份

ConfigMap 的 data 值是字符串，也可以通过 binaryData 表达二进制内容及其 API 编码形式。它适合小规模配置，数据大小有一 MiB 限制，不是通用文件仓库，更不是保护秘密的机制。API 能检查对象结构，却不知道某个应用参数在业务上是否合理。因此，结构合法和业务正确仍需分别验证，不能以创建成功代替配置审查。

Pod 可以通过环境变量引用或挂载文件消费配置。普通 Pod 引用要求 ConfigMap 位于这个 Pod 所在的命名空间。名称、必需键和应用解释方式都应明确。Deployment 对象被 API 接受，并不证明它引用的每个键都存在，也不证明新容器能够带着这些值成功启动。发布检查必须继续观察真实工作负载的结果。

单位、允许值与默认值应属于应用配置规范。某个字符串看起来像布尔值或数字，并不说明接收方会采用什么转换规则。在不同环境之间推广配置之前，需要结合真实消费者检查这些规则，避免同一份文本被解释成不同业务含义。

版本化的不可变 ConfigMap 更容易表达发布身份。settings-v2 可以与 settings-v1 同时保留，而 immutable 会禁止修改当前对象的数据。但这项保护不阻止有权限的操作者删除对象，再用同名重新创建另一份内容。对象生命周期权限和发布记录，应与希望实现的不可变承诺一致，不能把一个字段理解成所有可能路径都被永久封闭。

坏掉的样子

修改配置与替换进程是两种不同动作。已经注入运行中容器的环境值，不会因为 ConfigMap 更新而被改写。普通投射文件可能最终更新，但应用仍要重新读取；subPath 挂载和已经打开的文件又有不同生命周期。因此，API 中出现了新值，并不能直接宣布应用已经完成配置切换，还需要查看消费者实际读到了什么。

把 Deployment 的 Pod 模板改为引用新的 ConfigMap，是明确的滚动替换触发条件。仅修改 ConfigMap 本身，不会自动改写这个模板。同样，校验和 annotation 只有在某个工具真正把它更新到 Pod 模板中时才起作用。Kubernetes 不会自行发现任意外部配置变化，并替应用生成期望的校验和；这部分自动化需要有真实实现。

回退依赖旧输入仍然存在。旧对象已经删除，再把工作负载指回 settings-v1 就可能失败；只恢复镜像，也不能恢复被修改的配置。清理前应检查现有消费者及回退需要，并保留必要版本。配置还要通过业务验证，例如格式正确的阈值仍可能禁用服务或改变行为，不能把版本化本身当成兼容性证明。

快速验证

准备可丢弃的 Kubernetes 测试集群，确保 kubectl 可以访问，且节点能够使用 python:3.11-slim-bookworm 镜像。把代码保存为 config-releases.py，执行 python3 config-releases.py KUBECONFIG_PATH CONTEXT，将后两个参数替换成专用集群的配置文件路径和上下文。测试账号需要创建、删除本次命名空间的权限。实测服务端为 Kubernetes 1.34.11，客户端为 kubectl 1.34.1。

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'}}}]}


def deployment(namespace, name, podspec):
 return apply(namespace, {'apiVersion': 'apps/v1', 'kind': 'Deployment', 'metadata': {'name': name},
 'spec': {'replicas': 1, 'selector': {'matchLabels': {'app': name}},
 'template': {'metadata': {'labels': {'app': name}}, 'spec': podspec}}})


def deployment_pod(namespace, name):
 wait_for(lambda: obj(namespace, 'deployment', name), lambda d:
 d.get('status', {}).get('observedGeneration', 0) >= d['metadata']['generation']
 and d.get('status', {}).get('updatedReplicas') == 1
 and d.get('status', {}).get('availableReplicas') == 1
 and d.get('status', {}).get('replicas') == 1)
 def pods():
 return [p for p in obj(namespace, 'pods', selector='app=' + name)['items']
 if not p['metadata'].get('deletionTimestamp')]
 return wait_for(pods, lambda p: len(p) == 1 and pod_ready(p[0]))[0]

namespace = 'notes-config-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 for version, mode in [('v1', 'blue'), ('v2', 'green')]:
 apply(namespace, {'apiVersion': 'v1', 'kind': 'ConfigMap',
 'metadata': {'name': 'settings-' + version}, 'immutable': True, 'data': {'mode': mode}})
 podspec = spec()
 podspec['containers'][0]['env'] = [{'name': 'MODE', 'valueFrom':
 {'configMapKeyRef': {'name': 'settings-v1', 'key': 'mode'}}}]
 deployment(namespace, 'web', podspec)
 first = deployment_pod(namespace, 'web')
 def mode(pod):
 return k('exec', '-n', namespace, pod['metadata']['name'], '--', 'python3', '-c',
 'import os; print(os.environ["MODE"])').stdout.strip()
 assert mode(first) == 'blue'
 rejected = k('patch', 'configmap', 'settings-v1', '-n', namespace, '--type=merge',
 '-p', json.dumps({'data': {'mode': 'changed'}}), expected=None)
 assert rejected.returncode != 0 and 'immutable' in rejected.stderr
 assert obj(namespace, 'configmap', 'settings-v1')['data']['mode'] == 'blue'
 def select(version):
 patch = [{'op': 'replace',
 'path': '/spec/template/spec/containers/0/env/0/valueFrom/configMapKeyRef/name',
 'value': 'settings-' + version}]
 k('patch', 'deployment', 'web', '-n', namespace, '--type=json', '-p', json.dumps(patch))
 return deployment_pod(namespace, 'web')
 second = select('v2')
 assert mode(second) == 'green' and second['metadata']['uid'] != first['metadata']['uid']
 third = select('v1')
 assert mode(third) == 'blue' and third['metadata']['uid'] != second['metadata']['uid']
 image_ids = [p['status']['containerStatuses'][0]['imageID'] for p in (first, second, third)]
 assert len(set(image_ids)) == 1
 assert len({p['metadata']['uid'] for p in (first, second, third)}) == 3
 print(json.dumps({'modes': ['blue', 'green', 'blue'], 'distinct_pod_uids': 3,
 'same_image_id': image_ids[0], 'immutable_update_rejected': True,
 'retained_config_rollback_verified': True}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

程序创建两个不可变 ConfigMap，以及引用 settings-v1 的单副本 Deployment。第一个 Pod 从环境变量读取 blue。随后尝试覆盖这份 ConfigMap 数据，API 会拒绝操作，再读取对象也确认原值仍是 blue。这验证的是服务器实际执行了约束，而不是仅在文件中找到了 immutable 字样。

接着修改 Pod 模板，让它引用 settings-v2。控制器协调完成、容器就绪之后，另一个 Pod 读取 green。再选择保留的第一版，会再次替换 Pod 并读到 blue。三次 Pod 标识各不相同，但运行时观察到的镜像身份完全一致。全部断言已经通过，实验命名空间随后删除，未留下这些测试配置和工作负载。

这个实验使用简单工作进程，验证配置选择、进程替换以及依赖旧输入的回退，没有证明应用兼容性、生产滚动期间的可用性或外部副作用已经回滚。发布证据应把镜像、配置版本、工作负载定义和应用观测结果放在一起，让每一部分变化都有具体依据可供审阅。

来源

Kubernetes: ConfigMaps，非敏感配置、消费方式与不可变属性，已核验 2026-09-13。
Kubernetes: Deployments，Pod 模板变更及滚动替换，已核验 2026-09-13。

Kubernetes Deployment 描述期望状态

Thu, 19 Aug 2027 00:00:00 +0000

与其描述步骤，不如描述终态。这条思想支撑起副本、滚动更新与回滚的一切机制。

声明规范胜过过程脚本

一份 Deployment 是「终态」的陈述,而不是一张命令清单:多少副本、哪个镜像、哪条 tag、什么标签。操作者写下「要什么」,控制器这位 reconcile 循环决定「怎么要」。它与一条命令的本质差别在于:一条 kubectl run 是命令一样「去执行一下」,而 Deployment 说「这个状态要一直保持」。命令被中途打断可能留下半截结果;控制器则会反复收敛,直到与现实相符。这正是把启动、升级这些动作,从一锤子买卖变成系统持续盯守的事情的能力来源。

由控制器填补差距

reconcile 循环正是 Deployment 值得信任的原因。每次控制面看到现实与声明不相同——副本少了、Pod 被驱逐、节点丢失——它就做一步修正,再把现实推回声明。不是靠人每隔一会去手工补一个副本,而是控制器自己每几秒对一次账。这是它与「打一条命令」的根本差异:漂移不是你发现之后去修,而是系统自行察觉并回位。也正因此,被驱逐的、崩掉的 Pod 会自己回来,而不需要有人在半夜醒着盯。

一次次发布都是经过步骤的

变化也以同样的方式被描述:一次滚动更新就是换一份新的 Deployment,控制器用新副本逐步接管、尊重 ready 状态,让整支队伍在受控的节奏里切换。因为每一次改动都会生成一个新的 Revision 并留下记录,所以发布过程本身是可回溯的;回滚,不过就是再指向上一版 spec,而不是写一段「不知道自己在做什么」的脚本。这让集群在大规模下依然可以维护:意图只写一次,由控制器永久去追索,而每一次改动都把历史留下。

坏掉的样子

不可变的选择器会把一次随手的标签改动变成长期漂移。选择器在创建之后就不能再改,如果只改模板标签而不改选择器,新起的副本就会落在选择器之外:副本集一边报告缺副本,一边却有游离的副本在旁边空转。对称的错误是两份选择器重叠的负载,各自的控制器都把对方的副本算成自己的观测状态,轮流扩缩,谁也收敛不了。解法朴素而严格:把选择器加模板标签当成一份原子契约,对着两者逐行比对,一分钟就能定位漂移;凡是必须换选择器,就新建一份负载,而不是原地修补旧对象。

手改观测对象注定被循环打回。直接改下层副本集的副本数、顺手删一个副本省资源,或者只在集群里扩容却不改声明里的期望副本,都只能生效几秒,控制器下一次同步就会把副本数和模板按声明重写回去。上了版本同步的集群下一次对账就会直接覆盖回去,手工扩容看起来像是没有执行过。表象像是接口没有生效,看事件会发现控制器每轮都在补同一个差。如果紧急扩容是真的,就去改声明与版本库,而不是改眼前的观测对象。

历史版本也会从审计变成负担。每次改动都会留下一份旧副本集,保留多少由历史上限决定,持续集成的流水线每次提交都下发一次,若把上限设到几十,集群里很快攒下几十份僵尸版本,拖慢查询也撑大键值存储。用查询旧版本的数量与存储增长来验证清理效果,而不是只看发布成功。反过来把上限设成零,则连可回滚的目标都不剩。没有实测理由就保留默认的十份,把真正的审计交给版本库,而不是堆在集群里。

快速验证

把下面程序存成 desired_state_loop.py,运行 python3 desired_state_loop.py。它只用标准库,每轮比较期望与观测,差一个就补一个动作,直到差距归零,既演示节点丢失后的补齐,也演示手改多出的副本如何被收回。

"""期望态收敛循环模型（仅标准库）：期望 vs 观测，控制器补差直到归零。"""

def reconcile_step(desired, observed):
 if observed < desired:
 return "create-one-pod"
 if observed > desired:
 return "delete-one-pod"
 return "in-sync"


def converge(desired, observed, log):
 while observed != desired:
 action = reconcile_step(desired, observed)
 log.append(action)
 if action == "create-one-pod":
 observed += 1
 else:
 observed -= 1
 log.append("in-sync")
 return observed


def main():
 desired = 3
 observed = 1 # 节点丢失后只剩一个
 actions = []
 observed = converge(desired, observed, actions)
 assert observed == desired
 assert actions == ["create-one-pod", "create-one-pod", "in-sync"], actions

 # 手工漂移：期望未变，观测多了两个。
 observed = 5
 drift = []
 observed = converge(desired, observed, drift)
 assert observed == desired
 assert drift == ["delete-one-pod", "delete-one-pod", "in-sync"], drift

 # 标签错配不会自愈：选择器之外的模板标签永远不计入观测。
 selector = {"app": "api"}
 template_labels = {"app": "api-v2"} # 故意错配，否定对照
 matched = all(template_labels.get(k) == v for k, v in selector.items())
 assert not matched, "mismatched labels must not count as observed"

 print(f"desired={desired} final-observed={observed}")
 print(f"recovery-actions={actions}")
 print(f"manual-scale-reverted={drift}")
 print("PASS: controller closes the desired-vs-observed gap; label mismatch stays visible")


if __name__ == "__main__":
 main()

两次恢复都以同步结尾,而标签错配是否定对照:选择器之外的副本永远不计入观测,循环不会自作主张把契约错误也治好,而是让它一直可见。跑通后会打印两次补差动作序列与最终同步,手工多出的副本被删回期望数。若把期望改成你的真实副本数再跑一遍,收敛结论不变,数字跟着变。

断言已在 macOS 的 Python 3.14.4 下通过。模型只验证收敛算术,不涉及调度探针与存储,发布日之前,还要去真实集群确认选择器、副本数与历史版本数。

来源

Kubernetes：Deployments，Deployment 资源的说明，已核验 2027-08-15。
Wikipedia：Kubernetes，Kubernetes 及其模型，已核验 2027-08-15。

PVC 为 Pod 提供容器之外的持久存储

Fri, 13 Aug 2027 00:00:00 +0000

容器本性易失，所以要用 PersistentVolumeClaim 把真实存储钉到它身上，即使 Pod 被重建也不丢数据。这个拆分是刻意的：PersistentVolume 声明已经存在的容量，PersistentVolumeClaim 请求需要的容量，由控制器把两者配上。有了 StorageClass，声明还能通过 provisioner 自己创建卷，于是没人需要预先造好存储。

真正会咬人的是：声明与卷各自有独立的生命周期，由各自的规则管着。finalizer 决定声明什么时候才允许消失，回收策略决定卷之后会怎样。删除顺序搞错，就会得到一个卡在 Terminating 的声明；策略搞错，要么留下本想保留的数据，要么留下一份没人在用却仍在计费的存储。

声明、卷与绑定

绑定是一次「全部满足」而不是「最接近」。一块卷只有在容量不小于请求、访问模式包含所请求的模式、storageClassName 匹配，并且没有被别的声明占用时，才是候选。除了这几项，volumeMode（Filesystem 与 Block）也必须一致；而已经释放却还没清理的卷并不会变回可用的备件，它的 claimRef 仍指向上一个声明，所以新的声明根本看不到它。什么都不满足的声明会停在 Pending，并带一条指明究竟哪一项没满足的事件，这比一句笼统的失败有用得多；常见原因是要的访问模式该类交付不了，以及类名根本不存在。

accessModes 没有默认值，必须选一个，而多数单节点块存储 provisioner 实际能交付的就是 ReadWriteOnce。它同时是单节点的，所以副本分布在不同节点上的 StatefulSet 无法共用一份声明。类支持动态供应时，volumeBindingMode 决定时机：Immediate 在声明一出现就创建卷，可能把受拓扑限制的卷放到没有节点能用的可用区；WaitForFirstConsumer 则让声明一直 Pending，直到有 Pod 被调度，再在那个 Pod 所在的可用区创建。

删除顺序与 finalizer

顺序是 Pod、声明、卷，保护机制由 finalizer 实现。在 Pod 仍挂载着声明时删除声明，什么都不会被删掉：声明拿到删除时间戳、翻成 Terminating，然后停在那里，因为 kubernetes.io/pvc-protection 仍在它的 finalizer 列表里。只有再没有任何 Pod 引用这份声明时，控制器才会摘掉那个 finalizer，所以那个「永远 Terminating」的 PVC 并不是控制器卡住，而是一份仍被使用着的声明。

反方向也有同样的保护。PersistentVolume 带着 kubernetes.io/pv-protection，所以删除一块已绑定到声明的卷会被推迟到它不再被绑定为止。正是这个顺序让误敲的 kubectl delete pv 可恢复，也解释了为什么只要声明还在，卷看起来就会无视删除命令。

回收策略：Delete 还是 Retain

声明最终消失后，卷被释放，回收策略接手。Delete 会删掉 PV 对象以及外部基础设施上的存储资产。Retain 保留 PV 对象、把它标成 Released，并且刻意不让它被新的声明使用，因为上一个占用者的数据还在上面——回收于是变成一串手工动作：删 PV、清理存储资产、再删掉资产本身。

动态供应的卷会继承其 StorageClass 的策略，而后者默认是 Delete。这个默认对临时数据是对的，对数据库是错的，而且它不可见：PVC 与 Pod 清单里都没有一个字提到策略，决定是几个月前在一个集群级对象里做出的，审阅工作负载的人从来看不到。所以在评审一份有状态工作负载时，回收策略应当和容量、访问模式放在一起看。

坏掉的样子

最经典的是删不掉的声明。有人删了 PVC，看到 Terminating，然后开始等——而某个 Pod 仍然挂着它，通常是没缩容到零的 StatefulSet，或者卡在不可达节点上的 Pod。没有报错，没有超时，而这份 PVC 一直占着背后的存储。正确做法是找到那个 Pod，而不是手工删 finalizer；在 Pod 还在写的时候摘掉 finalizer，正是把卷从运行中的进程脚下抽走的做法。

第二种是 Retain 留下的孤儿。声明没了，Pod 没了，命名空间可能也没了，一块 Released 的 PV 和它的存储资产却无限期留在那里。它没被使用，也不处于错误状态，所以没有告警会响，任何工作负载的清单里也看不到它。反向的错误同样安静：某个类的默认 Delete 策略从未被覆盖，等到有人想找回数据时才发现回收早已把它删掉了。

快速验证

同时看绑定的两侧，以及是谁占着这份声明：

kubectl get pvc -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,STATUS:.status.phase,VOLUME:.spec.volumeName,CLASS:.spec.storageClassName
kubectl get pv -o custom-columns=NAME:.metadata.name,STATUS:.status.phase,POLICY:.spec.persistentVolumeReclaimPolicy,CLAIM:.spec.claimRef.name
kubectl get pvc data -o jsonpath='{.metadata.finalizers}{"\n"}'
kubectl get pods -A -o json | jq -r '.items[] | select(.spec.volumes[]?.persistentVolumeClaim.claimName=="data") | "\(.metadata.namespace)/\(.metadata.name)"'

处于 Terminating、且 finalizer 里仍有 kubernetes.io/pvc-protection 的声明，正被某个 Pod 占着，第四条命令会把它指出来。卷这一侧，卡在 Released 且策略为 Retain 的 PV 就是孤儿：没有东西引用它，也不会有人复用它，只有手工回收才能清掉。

来源

Persistent Volumes，绑定、访问模式、回收策略、Released 状态与 pvc/pv 保护 finalizer，已核验 2026-09-16。
Storage Classes，动态供应、reclaimPolicy 与 volumeBindingMode，已核验 2026-09-16。

HPA 按负载缩放 Deployment 的副本

Wed, 11 Aug 2027 00:00:00 +0000

HorizontalPodAutoscaler 是一个反馈控制器，不是容量规划器。每个同步周期（默认 15 秒）它会向 resource metrics API 要一次每 Pod 的 CPU，用观测值除以目标值得到比值，再把结果写进目标工作负载的 scale 子资源。公式只有一行：desiredReplicas = ceil(currentReplicas * currentMetricValue / desiredMetricValue)。

有意思的地方全在限定条件里。控制器会刻意忽略小的比值、刻意推迟缩容，并且在读不到指标或算不出分母时干脆不动。这三种行为是它稳定的原因，也正是为什么一个看起来配置正确的 HPA 会长期停在固定副本数上，而服务在一旁持续超时。

比值与死区

用利用率作目标时，分母不是一个百分比，而是一串毫核数：CPU request 为 200m、目标 60% 的容器，得到的目标指标是 120m。控制器随后把这个比值与 1.0 比较，允许一个可配置的容忍度（默认 0.1），比值落在带内就完全跳过伸缩动作。这条带子不是舍入细节，它就是防抖机制本身。

这条带子让可观测到的行为变得很粗。目标指标 120m 时，平均用量 110m、120m 与 132m 都让副本数原地不动，133m 才是第一个会改变它的值。步进本身是一次向上取整，所以 160m 对 120m 会把三个副本抬到四个，而不是 3.99——Pod 不能是分数，控制器因此永远往容量更充裕的一侧偏。

缺失指标与一票否决

指标尚未到达的 Pod 会被搁置，而不是按零计入；控制器随后保守地把它们加回来：判定为缩容时，假设这个缺失的 Pod 吃满了目标值；判定为扩容时，假设它是零。这个不对称会削弱任一方向的幅度。按 CPU 伸缩时尚未就绪的 Pod 也会被搁置：默认启动后 30 秒内转为就绪的 Pod 会被当作「尚未就绪」，而就绪的第一次认定还有一个 5 分钟的上限窗口。完全没有 CPU request 的 Pod 没有分母，其利用率就是未定义，HPA 对该指标不做任何动作——这是 HPA「看起来什么都没做」最常见的原因。

多个指标会让规则更严而不是更松。控制器为每个指标各算一个副本数并取最大者，所以只要有一个指标要求扩容，扩容仍然会执行。但如果某个指标根本无法换算成副本数，而能换算的指标又指向缩容，那么整次缩容会被跳过。一个坏掉的指标源因此冻结了收缩，却放行了增长。

稳定窗口与速率限制

缩容会被一个 300 秒的稳定窗口过滤。每条建议都会被记录下来，控制器只应用窗口内最高的那条，近似一个滑动最大值。一次短暂尖峰产生的十个副本的建议，会把实际生效的副本数一直压在十，直到这条建议过期，所以第一次真正的收缩发生在负载回落整整五分钟之后。扩容则完全没有稳定窗口，一有指示立刻生效。

速率限制同样是不对称的。默认扩容策略允许每 15 秒增加「当前副本数的 100%」与「4 个 Pod」中的较大者，缩容则允许移除 100% 的副本。一个从 1 个副本起步的冷 HPA 因此可以走到 5、10、20，在指标还没来得及反应之前就翻倍——流量尖峰时这是特性，指标本身出错时这就是事故。

坏掉的样子

最经典的是目标没有分母。HPA 报告利用率 unknown，记下 FailedGetResourceMetric 或 ScalingActive=False 这样的状况，然后永远不改副本数——所以症状不是一个报错页面，而是一个固定规模上持续超时的服务。原因几乎总是容器没写 CPU request，或者没装 metrics-server；kubectl create deployment 输出的是 resources: {} 且没有设置它的参数，所以这是手写清单的默认状态。

第二种是够不着的目标。因为 maxReplicas 是在比值之后才夹紧的，需要超过上限的工作负载每个周期都在算出更大的数字，又每个周期都被截断：利用率一直顶在天花板上，status 里报告无法继续扩容，却没有任何事件说明目标本身就不可能达到。上限要按实测容量来定，而不是按期望；同时记住同一套机制也会让冷 HPA 一路翻倍撞上去。

快速验证

确认指标存在、分母存在，以及控制器到底决定了什么：

kubectl get hpa web -o wide
kubectl top pods -l app=web
kubectl get deploy web -o jsonpath='{.spec.template.spec.containers[0].resources.requests.cpu}{"\n"}'
kubectl get hpa web -o jsonpath='{range .status.conditions[*]}{.type}={.status} {.reason}{"\n"}{end}'
kubectl describe hpa web | sed -n '/Events/,$p'

第一行给出当前利用率对目标利用率；这一列显示 <unknown> 就说明指标缺失。第三条在没有 CPU request 时什么都不打印，而这正是第二条能跑通、HPA 却仍拒绝伸缩的常见原因。最后两条给出状况原因和 FailedGetResourceMetric 事件，真正的解释在那里。

来源

Horizontal Pod Autoscaling，算法、容忍度、缺失指标处理、稳定窗口与默认策略，已核验 2026-09-16。
HPA walkthrough，对 metrics-server 与 requests 的依赖，已核验 2026-09-16。
metrics-server，HPA 读取的 resource metrics API 实现，已核验 2026-09-16。

liveness 与 readiness 告诉 Kubernetes Pod 的状态

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

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

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

Readiness 把流量挡在门外

readiness 探针失败，会把 Pod 从 Service 的端点里剔除，但 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'

两种探针共用一个接口，或异常事件与下游事故时间重合，就是还没拆干净的记号。

来源

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

Kubernetes · XB 现场笔记

调度器计算资源请求，而不是瞬时使用率

以准入后的真实配置为依据

坏掉的样子

快速验证

来源

Kubernetes CronJob 需要历史清理策略

已完成的 Job 并不免费

两套机制，两个控制器

owner reference 决定谁来清理

坏掉的样子

快速验证

来源

cgroup 在层级中执行容器资源预算

读取实际执行资源约束的控制器

坏掉的样子

快速验证

来源

cordon 与 drain 让节点安全离线

cordon 关门，drain 清场

拒绝清单一票否决

最终拍板的是预算，不是参数

坏掉的样子

快速验证

来源

Horizontal Pod Autoscaler 按目标利用率扩缩容

把平滑后的均值当作决策依据

选一个你真正能改进的指标

自动化与初始值无关

坏掉的样子

快速验证

延伸阅读

来源

CronJob 把时间表变成一次 Pod 运行

一张时间表催生一个 Job

并发是一道策略，不是猜

漏跑次数有一百的额度

坏掉的样子

快速验证

来源

节点亲和把工作负载放到合适的节点

按标签匹配节点

偏好还是强制

反亲和把副本分开

坏掉的样子

快速验证

来源

Kubernetes 滚动更新逐步替换 Pod

一次只换一小批

用 surge 与 drain 两扇窗

回滚只是重新部署

先选形状，再调节奏

坏掉的样子

快速验证

延伸阅读

来源

安全上下文需要运行时证据来验证

把设置放在正确层级

坏掉的样子

快速验证

延伸阅读

来源

水平自动伸缩按需扩缩容

指标决定副本数

扩容更激进、缩容更克制

指标才是薄弱环节

坏掉的样子

快速验证

延伸阅读

来源

Kubernetes 标签定义选择关系，不代替授权

确认正在使用哪一种选择语言

坏掉的样子

快速验证

来源

命名空间划分对象范围，其他边界需要政策

名称范围取决于资源类型

坏掉的样子

快速验证

来源