Kubernetes · XB 现场笔记

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

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

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

读取准入后的请求。API 拒绝、已创建但 Pending，以及成功放置，属于不同阶段。

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

对于普通应用容器，调度器在判断节点是否容纳 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，也可能遇到资源失败，不能用类别代替优先级、容量规划、应用正确性或实际节点压力分析。选择请求应考虑负载证据和故障代价，而不是追求某个标签。

快速验证

以下实验及观察结果沿用原文记录。本次审阅没有重新执行 Kubernetes 集成实验；文中的成功结果属于历史记录，不代表本轮取得了新的运行证据。

准备至少包含一个 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-10-15。
Kubernetes: Pod Quality of Service Classes，Guaranteed 条件及服务质量保护的边界，已核验 2026-10-15。

Kubernetes CronJob 需要历史清理策略

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

CronJob 按计划创建 Job，再由 Job 管理真正执行工作的 Pod。完成后的对象可以保留有用状态，但保留量受到多种独立机制影响。尤其要注意，CronJob 本来就有默认历史上限；省略显式历史字段，并不意味着普通已完成运行会无限堆积。分析清理问题时，先分清对象类型与状态，再判断是哪项机制没有覆盖。

当另一机制允许更早删除时，数量与 TTL 都不保证最低保留时长。清理是异步的，活动任务限制也不证明业务可安全重试。本轮未重跑保留诊断。

历史记录不等于日志归档

CronJob 默认最多保留三个成功 Job 和一个失败 Job，控制器分别协调两类记录。某类上限设为零，表示不保留该类历史，但清理是异步过程，不是任务结束那个瞬间必然消失。仍在运行的 Job 不属于完成历史，需要单独观察，不能期待这两个数量上限替它们设置运行期限。

三十天每小时一次意味着七百二十个计划机会，不一定保留七百二十个 Job，更不一定恰好产生相同数量的 Pod。错过调度、并发策略、重试与并行度都会改变关系，一个 Job 也可能拥有多个 Pod。用运行次数估算存储或控制面容量之前，应把这些假设说清楚，不能把理想时间表直接当成当前对象数量。

Pod 对象仍在，也不保证容器日志仍然可读。节点故障、日志轮转、容器清理和驱逐都会影响访问。真正需要按时长保留的证据，应交付到合适的日志系统。Kubernetes 对象便于调查状态，但不能替代归档保证；只延长 Job 历史，不会自动解决节点日志的生命周期问题。

大量历史仍有对象存储、列表大小和排查噪声等成本。Watch 接收相关变化，不会因为一个对象仍存在，就持续重新发送它所有未变化的状态。应测量真实对象数和控制面行为，避免把保留状态描述为永不停歇的控制器活动。调查困难可能值得优化，但应使用正确机制解释成本。

数量与年龄是独立策略

CronJob 历史限制的是已结束 Job 的数量，不是至少保留多久。密集运行可能很快替换最后一条失败记录，稀疏运行则可能保留很长时间。应根据查看间隔和失败频率选择数量，不能认为保留一次失败就足够覆盖所有工作负载，也不能把数量设置说成按时间执行的保留窗口。

TTL-after-finished 写在 Job 上。若希望应用到今后由 CronJob 创建的任务，应将 ttlSecondsAfterFinished 放在 Job 模板的 spec 中。计时从 Job 达到 Complete 或 Failed 开始，过期只代表具备级联删除资格。零表示完成后立即具备资格，省略则没有这项按年龄清理的规则，不能混淆省略与零的含义。

历史控制器与 TTL 都可能删除同一个 Job。因此，历史数量很大或 TTL 很长，都不保证最低保留时长，只要另一机制允许更早删除即可。Finalizer 和控制器进度还可能推迟实际消失。修改 CronJob 模板影响未来 Job，不会替所有旧 Job 自动重写现存 TTL；验证时应分别读取模板与既有对象。

所属关系决定级联行为

CronJob 创建的 Job 引用其所有者，Job 与 Pod 之间也形成从属关系。普通级联删除可以沿这条链清理。显式 orphan 删除则保留从属对象，并移除相关所有者链接，不是故意留下普通悬空引用再等待垃圾收集器追赶。两种删除方式具有不同结果，操作前应核对传播策略。

Job 被孤立后，原 CronJob 不再裁剪它们的历史，但已经配置的 TTL 仍可作用于各个完成任务。直接创建的 Job 同样需要明确保留决策。不同客户端的删除选项不能凭记忆统一推断，也不能认为孤儿马上就会消失。确认谁负责清理，比仅仅看到一个空 owner 字段更重要。

坏掉的样子

始终没有进入终止条件的 Job，不会因完成后 TTL 获得清理资格，历史上限也不会限制活动任务。合适的 activeDeadlineSeconds 可以约束运行时间，concurrencyPolicy 则控制计划任务重叠。它们解决不同问题，而且都不能证明底层业务重复执行安全；重试、副作用和幂等性仍然需要应用负责。

历史上限为零可能在调查前就移除失败记录。缩短保留前，应把必要日志与结果文件保存在其他地方。反过来，所有者关系不存在或 TTL 缺失，只是需要调查的信号，不能直接授权删除；其他控制器或业务保留要求可能有意承担清理责任，不能把所有未自动消失的记录都当成泄漏。

快速验证

以下保留的只读诊断本轮没有重新执行。应明确选择临时测试上下文和命名空间，并对照存储的 CronJob、它实际拥有的 Job、完成条件与创建时间。命名空间总数包含无关工作负载和活动 Job，因此不能拿它直接与单个 CronJob 的两项历史上限比较。

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

即使源清单省略历史字段，第一行通常也会显示 API 默认值。空输出不证明无限保留，应检查查询错误和完整对象。最后一行只显示第一个所有者引用。TTL 与 owner 同时为空，只说明尚未证明这两项机制负责清理，不表示永远不可能删除。跨多个完成周期复查，期望所属完成历史在协调后受限，同时单独评估活动任务与无关对象。

来源

Kubernetes Job，“Clean up finished jobs automatically” 与已完成 Job 的 TTL 机制，已核验 2026-10-15。
Kubernetes CronJob，默认历史上限与 job template，已核验 2026-10-15。
Kubernetes 垃圾回收，owner reference 与级联删除，已核验 2026-10-15。
Primary reference，TTL 资格与 finalizer，已核验 2026-10-15。
Primary reference，日志轮转与节点保留，已核验 2026-10-15。

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

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

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

有效预算沿 cgroup 层级生效。本地上限、相对 CPU 权重和内存记账是不同控制；图中数值来自保留的历史原文，不是新实验。

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

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

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

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

坏掉的样子

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

多容器 Pod 可以分别配置容器限制。一个容器暂时没有用完额度，并不自动承诺另一个容器可以越过自己的上限。PodLevelResources 在 Kubernetes 1.34 为默认开启的 beta 功能，仍取决于组件支持和特性开关配置。共享 Pod 预算不会抹去显式容器上限，不能悄悄用它替代每容器配置的含义。下面实验明确只使用容器 resources，并核对准入后的 Pod 没有配置 Pod 级 resources 字段，保持验证范围清楚。

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

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

快速验证

以下实验及观察结果沿用原文记录。本次审阅没有重新执行 Kubernetes 集成实验；文中的成功结果属于历史记录，不代表本轮取得了新的运行证据。

准备采用 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-10-15。
Kubernetes: Resource Management，传递给运行时的容器请求与限制，已核验 2026-10-15。
Linux: Control Group v2，层级、CPU 带宽、权重与内存记账，已核验 2026-10-15。
Kubernetes 1.34 Pod-level resources，特性阶段、支持条件与共享 Pod 预算，已核验 2026-10-18。

Cordon 与 drain 协调节点维护

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

Cordon 改变调度资格，drain 协调驱逐并等待 Pod 终止。两条命令都不保证维护期间工作一定保留；应用关闭逻辑、替代容量、存储和中断预算共同决定结果。应把排空视为需要观察的状态，并记录明确例外，而不是从命令名称推导节点已经可以安全关机。

Cordon 是放置限制，不证明节点已清空。Drain 不是原子事务，也不证明写入或替代副本成功。本轮没有执行原文保留的诊断命令。

Cordon 改变未来放置

Cordon 设置节点的不可调度字段，已有 Pod 继续运行，普通的新调度会避开它。Drain 自己也会执行 cordon，因此单独先做一次可以留下观察窗口，但不是必需步骤。Uncordon 重新允许调度，不保证立即出现新副本，也不会修好不健康的 kubelet；恢复前仍应核对节点状态与应用准备情况。

这项调度限制存在例外。DaemonSet Pod 容忍不可调度条件，直接填写 nodeName 的 Pod 则绕过普通调度选择。具有相应容忍度的其他 Pod 也可能符合放置条件。因此，需要检查真实剩余负载，不能把 cordon 说成阻止所有 Pod 到来的防火墙，更不能只凭不可调度字段就判断节点已经清空。

Drain 具有过滤检查和独立操作

Kubectl 先列出 Pod 并检查删除条件。独立 Pod 或管理控制器已经不存在的 Pod 可能需要 force；emptyDir 需要确认丢弃内容；DaemonSet 需要 ignore 选项。镜像 Pod 会被跳过，因为删除 API 表示不能停止 kubelet 根据静态清单管理的底层工作负载，静态程序需要单独规划维护。

预检查不等于原子事务。真正开始驱逐后，一部分可以成功，另一部分仍在等待或失败；失败时节点也可能已经被 cordon。再次尝试前应重新读取节点与 Pod 状态，不能认为命令非零退出就表示所有东西都保持原样。维护记录要区分哪些请求被接受、哪些进程已经退出，以及哪些副本仍未恢复。

Ignore-daemonsets 会留下 DaemonSet Pod。Delete-emptydir-data 允许丢失临时卷内容，不负责迁移。Force 允许处理无管理控制器的 Pod，却不会绕过 PodDisruptionBudget。选择参数前要核对归属、数据用途与重建方式；即使一个进程无状态，删除唯一实例也可能影响服务，因此无状态不是足够的安全证明。

预算约束主动驱逐

服务端支持时，drain 使用 Eviction API，并检查适用的中断预算。Disable-eviction 则改为直接删除，绕过这种保护。这个区别非常重要：添加 force 不能解决预算拒绝，而绕过驱逐可能删除维持法定多数或业务可用性所需的副本。不能把几个名字带有强制含义的参数视为同一个开关。

健康 Pod 可能因为预算没有可中断数量而被阻塞。默认 IfHealthyBudget 还限制已经运行但不健康的 Pod：当所保护应用已经低于健康要求时，驱逐可能等待；这并不表示每个不健康 Pod 都必须先变 Ready。AlwaysAllow 改变这类不健康 Pod 的判定，应结合应用恢复行为选择，而不是为了让终端尽快返回随意启用。

Drain 会等待终止，并重试部分被拒绝的驱逐。超时默认无限，但认证失败、服务端错误等仍可能结束命令。优雅终止只给应用一个停止窗口，不能证明写入完成或替代副本可用。设置合理的操作期限，有助于把受阻维护暴露出来，而不是让值班人员无限等待没有说明的进度。

坏掉的样子

可中断数量为零是重要线索，不是立即削弱预算的许可。应检查选择到的 Pod、当前和期望健康数、替代容量与存储拓扑。先恢复不健康副本或增加安全容量，可能比降低保护更合理。多节点并行排空会竞争同一预算，还可能加重恢复压力；增加并发不能凭空获得更多可用副本。

维护不能继续时，应找出具体剩余 Pod 和原因，不要为了看到成功退出而直接换成 disable-eviction。关闭节点之前，仍需验证应用健康，以及静态 Pod、DaemonSet 等剩余类别。普通 drain 成功本来就会留下部分工作负载，操作手册必须解释这些例外如何处理，而不是把它们当作遗漏。

快速验证

以下保留命令本轮没有执行。应明确选择临时集群与目标命名空间。客户端干跑仍读取集群，但不真正提交驱逐，也不验证服务端是否准许驱逐。示例中的 ignore 与 emptyDir 参数会压下对应预检查拒绝，所以不能把这份输出当成未忽略任何问题的完整安全报告。

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 状态。Pod 列表只涵盖当前命名空间，而且只显示第一个 owner reference；空列或非空列都不能证明完整控制器关系。实际操作前应比较所有命名空间和控制引用。预算列表虽然跨命名空间，却未显示命名空间与选择器，需要逐个匹配实际负载。真实排空仍须在获准环境单独验证，这些检查不能认证其成功。

来源

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

Horizontal Pod Autoscaler 依赖明确的指标语义

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

HorizontalPodAutoscaler 把配置的指标转换为副本建议，因此选择指标与聚合口径本身就是应用设计的一部分。增加副本应该能够降低所测压力，或提升真正有用的吞吐量，否则控制器可能只增加费用，却无法缓解瓶颈。应设置明确的最小与最大副本数，但成本上限不等于性能保障，更不代表到达上限之后仍能处理任何规模的请求。

展示原文算术模型，不是实时观测。历史 Python 模型通过范围不变。模型未包含真实控制器的容差、就绪、稳定窗口与速率策略；不证明集群行为或服务可用。

区分测量与控制

HPA 通常周期性协调，控制器默认同步间隔为十五秒。对于按 Pod 平均的目标，基本计算是当前副本数乘以当前指标与目标指标的比值，再向上取整。CPU 利用率相对于资源 requests 计算，不是相对于 limits，也不是整台节点的总容量。把分母理解错，会让看起来合理的百分比对应完全不同的扩容时机。

跨 Pod 求平均，与对时间序列做移动平均是两回事。Metrics Server 的 CPU 用量来自一个测量窗口，自定义适配器则有自己的查询与取样语义。HPA 并不会统一替每种输入做一个可配置时间窗口的平滑。容差、就绪处理、稳定窗口与速率策略属于控制层，是围绕指标建议的不同机制，不能全部称作“先平滑再决策”。

先确定单位，再讨论目标数字。按 Pod 的自定义指标使用 AverageValue；对象和外部指标可使用 Value 或 AverageValue，扩缩意义不同。整个队列的总积压与每副本平均积压不是可以随意互换的输入。资源利用率还要求提供相应资源请求。即使接口返回正常数字，如果它衡量的不是实际瓶颈，控制器依旧可能做出没有业务价值的动作。

选择增加副本能够改善的信号

CPU 常适合计算密集型服务，但必须先有可用的资源指标接口，并非所有集群天然具备。工作者等待数据库时，可能 CPU 很低、延迟很高；增加更多工作者反而加重数据库压力。依赖自动扩缩之前，应验证目标值是否对应每副本能够持续承担的真实工作，而不是只确认图表会随着请求变化。

请求速率、在途工作与消费积压都需要明确范围。按 Pod 的指标应保留必要的逐 Pod 观测，不能一概预聚合成每工作负载一条序列；对象或外部指标则要聚合到指定工作负载或队列，排除无关流量。避免不必要的用户级、请求级标签，防止查询成本膨胀和选择条件变得难以解释。聚合不是越少越好，而是必须与指标类型的契约一致。

副本字段要有明确负责人

HPA 会读取目标的 scale 信息，并修改副本数。Deployment 初始 replicas 不是 HPA 下限，真正配置的地板是 minReplicas。若部署流程反复提交一个固定副本数，便可能与 HPA 争抢同一字段。应明确配置所有权，并提前安排取消自动扩缩之后使用什么静态规模；不要把最初的副本值说成控制器永远不读取、也完全无关的数字。

坏掉的样子

自定义指标不可用时，不会自动转去读取 CPU。配置多个指标后，HPA 选择可用建议中的最大值；若某一路失败，而其他可用建议要求缩容，则跳过这次缩容。若有效指标要求比当前更多的副本，仍可能扩容。因此显式加入 CPU 是增加一条输入，并不是在两个方向上都无条件接管的故障切换机制。

还要区分整个指标来源失败，与部分 Pod 缺失测量。后者也会在资源算法里触发保守调整，但不是同一种问题。应检查 conditions 与 events，不要断言任何单个样本缺失都会让 ScalingActive=False。有效读数、失败来源与副本上下限可能同时存在，单看某个显示为未知的数值无法还原整个决策过程。

适配器数据过旧，会让控制器在队列已清空之后才扩容。调目标值前，先检查时间戳、查询范围、缓存与采集延迟。接口报错与“读数有效但选错了指标”也不同：把内存当作不合适的延迟代理，不会仅因为相关性差就把读数变成 Unknown。先判断是取不到数据，还是数据根本无法指导有效动作。

快速验证

保存为 hpa_metric_sim.py，执行 python3 hpa_metric_sim.py。这个标准库模型使用已经计算好的每副本平均值，初始副本位于上下限内，展示多指标取最大值和来源失败时的缩容保护。它并没有实现每一种 HPA 指标类型，更没有访问真实集群。

import math
import sys


def desired_for(current, value, target):
 assert current > 0 and target > 0
 if value is None:
 return None
 assert value >= 0
 return math.ceil(current * value / target)


def decide(current, metrics, min_replicas, max_replicas):
 assert 0 < min_replicas <= current <= max_replicas
 recommendations = [desired_for(current, value, target)
 for _, value, target in metrics]
 available = [want for want in recommendations if want is not None]
 if not available:
 return current
 want = max(available)
 if None in recommendations and want < current:
 return current
 return max(min_replicas, min(max_replicas, want))


def check(actual, expected, message):
 assert actual == expected, (message, actual, expected)
 print(f"OK: {message} -> {actual}")


def main():
 current = 4
 cpu = ("cpu", 80, 50)
 queue = ("average_queue", 900, 300)
 missing_queue = ("average_queue", None, 300)
 cool_cpu = ("cpu", 10, 50)
 check(decide(current, [cpu, queue], 1, 20), 12, "maximum wins")
 check(decide(current, [cpu, missing_queue], 1, 20), 7, "missing allows scale-up")
 check(decide(current, [cool_cpu, missing_queue], 1, 20), 4, "missing blocks scale-down")
 check(decide(current, [("cpu", None, 50), missing_queue], 1, 20), 4, "all missing holds")
 check(decide(current, [cpu, queue], 1, 10), 10, "upper bound")
 check(decide(current, [cool_cpu, ("average_queue", 30, 300)], 1, 20), 1, "valid low metrics shrink")
 check(decide(current, [cool_cpu], 2, 20), 2, "lower bound")
 print("PASS: 7 model scenarios; no Kubernetes controller was exercised")
 print(sys.version.split()[0])


if __name__ == "__main__":
 main()

七条断言分别检查热指标提出十二与七副本、失败来源伴随缩容建议时保持四个、全部来源失败时也保持四个，以及两个边界和完整有效的缩容到一个。两种语言中的代码副本都在本轮通过 Python 3.12.14 本地运行。相同代码确保公式和保护条件一致，输出中的数字可以逐项与正文解释对应。

实验没有运行集群控制器、指标适配器、容差、就绪调整、稳定窗口或扩缩速率策略。学习目标是代码中明确写出的失败来源保护条件。要证明生产自动扩缩可用，仍需另行核对真实时间戳、状态条件和伸缩事件；算术断言成功不能替代这条端到端证据。

来源

Kubernetes 水平自动扩缩，说明算法与指标来源，已核验 2026-10-15。
资源指标流水线，说明指标服务与资源指标接口，已核验 2026-10-15。
HorizontalPodAutoscaler walkthrough, Pods metrics use AverageValue; object/external types differ，已核验 2026-10-15。

CronJob 把时间表变成 Job

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

CronJob 把一份 Job 模板与循环时间表组合起来。CronJob 控制器负责创建 Job，再由 Job 管理执行工作的 Pod。一次运行可以包含重试、替换 Pod，或按照 Job 配置启动多个并行工作者，不应把它简化为每次只启动一个短命容器。两次运行之间不需要专门的应用进程等候触发，但已经完成的 Job 和 Pod 可能继续保留，供排查与审计使用。

时间表只是近似兑现。某个时刻可能生成重复 Job，也可能完全漏掉，因此不能无条件承诺每个计划时刻都至少执行一次。应用既要能安全重复执行，也要记录哪些业务周期真正完成。幂等性解决重复效果，独立的完整性检查解决根本没有运行的工作，这两个问题不能互相替代。

时间表是近似调度，不是持久队列，也不保证每个时刻的工作都完成。startingDeadlineSeconds 限制启动迟到，不限制运行时长。原文命令未重跑；执行状态仍为受阻。

时间表产生的是 Job

五个字段依次表示分、时、日、月与星期，支持区间、步长和 @daily 等宏。*/10 * * * * 表示每十分钟的计划时刻，并不保证 Pod 恰好在那个瞬间开始执行。即使 Job 已经建立，节点资源不足、镜像拉取或调度过程仍可能让实际工作晚于计划。

如果业务依赖当地钟表时间，应明确设置 spec.timeZone。省略时使用控制器管理器的本地时区；换一台机器本身不会必然改变行为，只有相关时区配置变化才会影响解释。不要把 TZ 或 CRON_TZ 塞进 schedule 字符串，应使用专门字段。夏令时切换以及报表所覆盖的业务日期，仍需要应用自己的明确规则，不能靠时区名称代替业务定义。

CronJob 名称应控制在五十二个字符以内，为生成 Job 名称时追加的后缀留空间。从 Kubernetes 1.32 起，生成的 Job 带有 batch.kubernetes.io/cronjob-scheduled-timestamp，可以把原定时间与创建、启动时间比较，判断延迟发生在哪一层。这个注解是诊断依据之一，并非唯一审计来源，更不能证明备份、报表或其他业务结果已经成功完成。

并发策略只约束同一个 CronJob

默认的 Allow 允许 Job 重叠。Forbid 在前一次仍活跃时拒绝新的启动；跳过的时间计入漏跑，之后是否还能启动仍取决于截止时间。Replace 先请求删除，再创建替代 Job；异步删除不证明旧 Pod 已经停止。这些策略不会协调另一个 CronJob，也不会阻止集群外的工作者同时修改相同数据。

如果任务每次都比调度间隔长，Replace 可能不断打断尚未完成的工作。Forbid 用漏掉启动机会换取减少重叠，并没有建立一个持久任务队列。对于重复写入有害的操作，应设计业务级去重或协调，同时考虑替换期间已经提交了一半的结果。持有一把锁本身不代表中途失败之后就能安全继续，更不代表漏掉的业务周期会自动补齐。

启动期限、挂起与历史保留

startingDeadlineSeconds 限制的是允许多晚开始，而不是任务最多运行多久。不设置时，每次计划没有单独的启动截止时间。概念文档描述超过一百次漏跑时拒绝补启动，但此次核对的 1.34.0 调度辅助函数会产生警告并返回最近的合格时刻，并不单凭这个计数拒绝启动。应核对服务端版本，不要看到警告就推断永久停摆。设置启动期限后，统计窗口受该期限限制；小于十秒的值可能错过控制器检查，不能当作精确实时调度器。

挂起会停止创建新 Job，但不会终止已存在的 Job。挂起期间的计划时间也算漏跑，所以恢复时可能立即发生补调度，仍受其他规则限制。不要把这理解成每个历史时刻都必然对应一个补建 Job。若每一期报表都必须处理，应使用持久的业务工作清单记录完成情况，而不是把 CronJob 历史当作可靠队列。

历史保留默认留下三个成功 Job 和一个失败 Job。它控制的是已完成对象的保留数量，不是同时运行数，也不替代执行期限。修改模板只影响将来创建的 Job；已经启动的 Job 继续使用自己的规格。调度配置、单次任务配置和结果保留策略需要分别审阅，才能知道一次变更真正影响哪批工作。

坏掉的样子

一个运行二十五分钟的任务放在十分钟时间表上，使用 Allow 时可能出现重叠和重复写入。应查看真实所属关系、活跃 Pod 与完成记录，再判断业务重复是否由调度造成。启动期限应该反映结果迟到多久仍然有用，而不是随便选一个数字，只为了让控制器不再产生警告。

lastScheduleTime 长时间不更新也可能是预期行为：挂起、Forbid、稀疏的日历表达式或时区改变，都可能解释这个现象。事件会过期，成功创建 Job 也不等于备份可恢复。监控应同时关注最后一次经过验证的可用结果，以及调度本身的健康，避免每天都有绿色 Job，却从未检查产物是否真的能用。

快速验证

在指定的只读集群上下文与命名空间中，检查已有的 nightly-report。下列命令保留自原文，本轮没有在真实集群重新执行。

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

Job 列表还会包含同一命名空间里的其他任务，判断之前必须通过 ownerReferences 核对所属 CronJob。只有 START 时间不能证明运行重叠，SUCCEEDED 为空也不能证明任务仍在执行；还要结合 active、failed 与完成条件，以及对应的原定时间。时间间隔要按实际日历和策略解释，保留的事件没有说明时，再寻找控制器日志，不能根据一条缺失记录直接认定整个控制面停过。

来源

Kubernetes CronJob，调度语法、并发策略、漏跑一百次的规则与历史上限，已核验 2026-10-15。
CronJob v1 API 参考，CronJob spec 的字段级定义，已核验 2026-10-15。
Kubernetes 1.34.0 CronJob scheduling helper, mostRecentScheduleTime and nextScheduleTime select the latest missed time and warn above 100，已核验 2026-10-15。
CronJob job control (v1.34.0)，DeleteJob 使用后台传播；替换不是等待 Pod 终止的屏障，已核验 2026-10-18。

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

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

节点亲和把工作负载的要求与节点标签匹配起来。它可以要求 NVMe 存储，也可以偏好较新的机型，但不会代替调度器的其他检查。即使没有亲和规则，调度器也会先按资源请求、污点、存储卷约束等条件筛选，再给可行节点评分，并非只比较此刻的空闲容量。

GPU 放置说明了这一区别：通过设备插件声明 GPU 扩展资源请求，才能把设备数量纳入资源适配；加速器标签可以进一步选择型号。标签本身不会分配 GPU，容忍污点也既不请求设备，又不要求一定进入专用池。必须分别表达资源需求、放置要求和允许进入哪些节点。

必要亲和按标签过滤。偏好亲和参与可行节点评分，两者单独都不保证成功放置。

按标签匹配节点

accelerator=nvidia-a100、storage=nvme 等标签描述的属性，需要节点供给流程建立并持续维护。替换节点不会自动继承旧节点的任意标签。应先确认新硬件确有这些属性，再附上旧标签；否则规则在形式上匹配，实际选到的机器却不适合业务。

把标签词表当作 API 管理。重命名一个键会影响所有引用它的清单，过时的值则可能错误描述硬件。校验配置时要对照预期节点清单，包括计划扩容但还未上线的容量。某个标签暂时不存在，可能是供给过程未完成或整个节点池暂时缺席，不一定只是拼写错误。不要让静态校验把这些不同原因混成同一个结论。

隔离还依赖标签完整性。Kubernetes 1.34 文档建议结合 Node authorizer、NodeRestriction 准入插件和受保护的 node-restriction.kubernetes.io/ 标签键。普通的节点自报合规标签并不是独立安全边界。需要明确谁能修改标签，以及谁能修改工作负载的放置要求；字符串匹配不能代替这些权限检查。

偏好还是强制

requiredDuringSchedulingIgnoredDuringExecution 排除不满足规则的节点；preferredDuringSchedulingIgnoredDuringExecution 为可行节点增加带权偏好，其他评分仍可能胜出。两种形式都不保证剩余容量、应用健康或故障韧性。必要条件可能让 Pod 保持 Pending；偏好允许落到不匹配的节点，但所有硬约束仍须通过。

名称还说明生效时机。采用 IgnoredDuringExecution 时，节点标签后来改变不会驱逐已绑定的 Pod；改变偏好也不会自动重新分布现有副本。应把新的调度决策与当前实际落点分开检查，不能看到新规则就假定全部旧副本已经迁移。

同时设置 nodeSelector 与必要节点亲和时，两者必须都满足。多个 nodeSelectorTerms 之间是“或”，同一项内的 matchExpressions 是“与”。排查容量之前先核对分组：把替代条件误写成同时成立的条件，可能直接排除整个目标节点池。

反亲和把副本分开

Pod 反亲和匹配的是指定命名空间范围与拓扑域中的其他 Pod。kubernetes.io/hostname 表示节点；标准可用区键是 topology.kubernetes.io/zone。相关节点需要一致的拓扑标签。准入策略还可能限制必要反亲和使用哪些拓扑键，因此不能假定所有集群都接受必要的可用区规则。

假设三个副本相互选中，要求主机级分离，却只有两个满足其他条件的节点，那么可能有两个副本运行、第三个 Pending，并非整个工作负载完全无法运行。偏好反亲和允许共置，不能承诺几乎相同的韧性。选择规则时，要结合应用能承受的故障、可用拓扑域与替代容量，不能只看总节点数。

坏掉的样子

Pod 处于 Pending 时，读取完整调度事件和准入后的配置。标签不匹配只是一种可能；资源请求放不下、未容忍污点、卷拓扑以及调度配置中的附加约束，都可能排除节点。观测到 CPU 使用率低，不代表请求账本还有余量。应修复实际报告的约束，而不是先把必要亲和降成偏好。

已绑定 Pod 的落点不合预期时，要对照它调度时的规则与节点标签。检查原规则是否只是偏好、标签之后是否改变，以及 Pod 是否通过 nodeName 绕过普通调度。当前分布不符意图，不足以说明调度器因容量变化而迁移了既有 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

grep 视图可能遗漏亲和细节。最后的管道同时包含唯一 Pod 名和表头，因此不能汇总每节点副本数；固定列号也容易失效。应检查完整的 affinity、nodeSelector、实际 nodeName 及被选择的同伴 Pod，再明确统计拓扑域。以上命令不能证明放置正确或具备韧性。图中记录的是较早的单独绘图审阅；真实调度仍未验证。

来源

Kubernetes 节点亲和文档，节点亲和语义，已核验 2026-06-10。
Kubernetes taints 与 tolerations，说明把 Pod 从专用节点挡开，已核验 2026-09-05。
Kubernetes 1.34 placement rules，标签可信性、条件分组与调度时亲和语义，已核验 2026-10-18。
Kubernetes scheduler，筛选与可行节点评分，已核验 2026-10-18。
Schedule GPUs，设备资源请求与 GPU 型号标签的区别，已核验 2026-10-18。

Kubernetes 滚动更新逐步替换 Pod

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

先选择发布的形状，再调整速度。新旧版本能否同时处理请求？能否安全共享存储和任务所有权？如果新版本起不来，如何恢复？这些问题决定 Deployment 应该用 RollingUpdate 重叠运行，还是用 Recreate 先停旧版、再起新版。姊妹篇讨论滚动的节奏和现场观察；本篇讨论兼容性、停机与恢复边界。

先检查兼容性与所有权，再选择版本重叠。Recreate 只改变升级顺序；回滚仍需经过演练的镜像、配置与数据恢复方案。

逐步替换，还是先停后起

RollingUpdate 是 Deployment 的默认策略。surge 和 unavailable 两个预算控制替换过程，允许新旧 ReplicaSet 同时存在。就绪状态参与可用副本的计算，但不代表业务逻辑正确，更不代表每个请求都成功。不能因为看到 Ready，就推断订单、支付或后台任务已经通过发布验收。

Recreate 在 Deployment 升级时等待旧 Pod 终止，再创建新版本，因此应计划一段没有可用服务副本的时间。选择这个策略时，要移除 rollingUpdate 配置块；其中的字段只属于滚动更新。停机窗口要通过测量得到，不能顺手把三十秒当成保证。旧进程退出慢、新镜像下载慢、存储挂载慢，都可能拉长用户实际感受到的中断。

兼容性才是选择依据

允许版本重叠，意味着接口、持久化数据以及后台工作都能兼容。前端健康检查可能正常，旧 worker 却读不懂新 worker 刚写入的记录。调整副本数之前，应测试混合版本的读写、任务领取和重试行为。副本预算能安排进退顺序，不能修复不兼容的数据库结构变化。

有状态并不自动意味着必须选择 Recreate：协调正确的副本式应用，也可能支持新旧版本同时运行。反过来，Recreate 不是分布式锁。它的先停后起约束适用于 Deployment 升级；如果人工删除一个 Pod，ReplicaSet 可能在旧 Pod 仍处于终止状态时创建替代者。真正的单写者需要应用层协调，必要时还要有隔离旧所有者的机制，确保失去资格的进程不能继续写入。不能把发布策略当成这种机制的替代品。

存储术语也不能混淆。ReadWriteOnce 限制的是一个节点以读写方式挂载，并不等于只能有一个 Pod；同一节点上的多个 Pod 仍可能使用同一卷。对于支持的 CSI 卷，ReadWriteOncePod 才提供单 Pod 访问约束。应检查实际驱动、卷的访问模式与工作负载需求，而不是看到一个存储标签，就认定已经解决了所有权问题。

回滚也是一次变更

保留可以重新启动的旧镜像和修订历史。kubectl rollout undo 恢复记录过的 Pod 模板；只把镜像地址改回去，可能漏掉已经变化的启动参数或环境引用。这两种操作都不会撤销数据库迁移，也不会恢复独立修改过的 ConfigMap 内容。旧模板继续引用同一个 ConfigMap 名称时，重新启动的旧程序仍可能读到新数据。

发布前要记录镜像、配置和数据结构之间的兼容关系。如果需要混合运行或回退，应优先安排向后兼容的迁移顺序。恢复流程必须演练，包括谁执行、按什么顺序做、需要多久，以及如何判断旧版已经恢复业务。只留着旧 ReplicaSet，不能证明恢复是安全的。使用 Recreate 时，回到旧版也可能再经历一次停机和启动；恢复时间不能只按正常升级的一半估算。

坏掉的样子

没有正确协调的 worker，可能在所有 Pod 都 Ready 时重复执行任务或破坏数据。此时需要检查任务所有权与版本兼容性，而不只是看容器是否健康。另一类故障是 Recreate 的冷启动超出预算：镜像拉取或卷挂载很慢，应用真正开始启动之前，停机时间就已经被耗尽。因此演练要包含真正的冷启动和旧版退出耗时，不能只测缓存齐全时的进程启动。

四个副本设置 maxUnavailable: 50%，预算允许减少到两个可用副本，不会自动变成一个。新替代 Pod 崩溃可能让进度停滞；另外发生的节点故障等独立事件，才可能把现有容量继续压低。决定采用这个预算之前，先验证两个实例能否承担预期流量，而不是把「更新仍在允许范围内」等同于业务容量足够。

零 unavailable 也无法防止无关故障。另一个极端是允许全部副本不可用：这样的配置可以合法存在，只是通常不符合服务目标。若团队要禁止它，应明确这是自己的发布政策，而不是 Kubernetes API 的校验规则。真正不能同时为零的是 surge 和 unavailable，否则替换过程没有可推进的空间。

快速验证

把下面保存为 strategy_window.py，运行 python3 strategy_window.py。这是只使用标准库的本地模型，仅接受正整数副本数与非负整数预算。它计算规划量，不模拟控制器，也不是完整的 API 校验器；百分比换算、自动扩缩容和副本数为零的情况不在这个模型内。Kubernetes 允许把 Deployment 缩容到零；程序拒绝它，只因为本练习讨论的是有副本需要替换的场景。

"""Integer rollout-budget arithmetic; no cluster or traffic is exercised."""


def rolling_budget(replicas, surge, unavailable):
 values = (replicas, surge, unavailable)
 if any(type(value) is not int for value in values):
 raise ValueError("this model accepts integers only")
 if replicas <= 0 or surge < 0 or unavailable < 0:
 raise ValueError("positive replicas and nonnegative budgets required")
 if surge == 0 and unavailable == 0:
 raise ValueError("surge and unavailable cannot both be zero")
 planned_floor = max(0, replicas - unavailable)
 target_ceiling = replicas + surge
 return planned_floor, target_ceiling


def main():
 assert rolling_budget(6, 1, 1) == (5, 7)
 assert rolling_budget(4, 0, 2) == (2, 4)
 assert rolling_budget(4, 1, 4) == (0, 5)
 for invalid in [(4, 0, 0), (4, -1, 1), (0, 1, 0)]:
 try:
 rolling_budget(*invalid)
 except ValueError:
 pass
 else:
 raise AssertionError(f"invalid model input accepted: {invalid}")
 print("rolling: planned availability floor=5, replica target ceiling=7")
 print("full-unavailability budget: planned floor=0 (permitted)")
 print("recreate: expect a zero-serving interval during replacement")
 print("PASS: budget arithmetic only; runtime availability untested")


if __name__ == "__main__":
 main()

预期输出四行，最后一行明确写着只通过预算算术、未测试运行时可用性。六副本、一 surge、一 unavailable 的结果是五和七；允许四个副本全部不可用的例子，故意得到零，而不是抛出「非法配置」。两项预算同时为零、负预算、零副本等不属于本模型有效输入的情况，则通过断言检查拒绝路径。

正在终止的 Pod、独立故障、调度以及真实请求处理都没有进入模型。因此，五不是实际观测到的服务能力下限，七也不是所有运行进程的绝对上限。程序只帮助检查算术和策略假设，不能给线上可用性出具证明。把数字换成自己的副本配置之前，也要先处理百分比和实际需求变化，而不是直接复制结论。

本次修订在 Linux 的 Python 3.12.14 中执行了断言，没有执行 Kubernetes 集成实验。采用某个策略前，应在测试环境演练升级和回滚，同时持续发请求、检查存储使用，并运行混合版本业务测试。把这些现场结果与本地算术结果分开记录，才知道哪些结论有真实环境的证据支持，哪些还只是规划假设。

来源

Kubernetes Deployment，升级顺序与修订回退，已核验 2026-10-15。
Deployment API，策略字段与更新预算，已核验 2026-10-15。
Kubernetes 持久卷，节点级与 Pod 级访问模式，已核验 2026-10-15。
Kubernetes ConfigMap，配置引用与传播，已核验 2026-10-15。
Kubernetes StatefulSet 删除注意事项，身份与重复进程风险，已核验 2026-10-15。

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

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

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

原文 Kubernetes 1.34.11 历史样例，本次未重跑。结果反映组合设置；RuntimeDefault 取决于运行时。没有测试容器逃逸抵抗、全部 seccomp 规则、敌对多租户隔离或应用授权。执行仍为受阻。

把设置放在正确层级

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、允许权限提升或打开整个根文件系统来处理所有权限报错。必要写入与过大权限需要通过真实调用区分。

快速验证

以下实验及观察结果沿用原文记录。本次审阅没有重新执行 Kubernetes 集成实验；文中的成功结果属于历史记录，不代表本轮取得了新的运行证据。

准备临时 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-10-15。
Linux: No New Privileges Flag，通过执行程序获取新权限的限制，已核验 2026-10-15。
Linux: capabilities(7)，独立能力权限与进程能力集合，已核验 2026-10-15。

水平自动伸缩按需扩缩容

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

HorizontalPodAutoscaler 根据配置的指标目标调整可伸缩工作负载。它的输出是期望副本数，不是“额外 Pod 已经接收流量”的保证。调度、镜像启动、初始化、就绪状态以及节点容量，都会决定这个建议多久才能转变成真正有用的服务能力。设计控制循环时，必须把这些延迟一起考虑，不能只根据一条公式估计恢复时间。

仅展示原文的算术与列表状态模型。历史 Python 模型执行仍为通过；未测试容差、速率策略、逐 Pod 处理、Kubernetes 协调或真实就绪容量。本次未运行样例。

指标产生的是副本建议

对于简单的逐 Pod 平均值，期望副本等于当前副本数乘以当前指标除以目标指标，再向上取整。比值为二时，在额外控制介入之前会建议翻倍。比值低于一可能建议缩容，但容差、缺失测量、就绪处理、上下限和扩缩行为，都可能阻止或限制最终动作。公式描述起点，不是所有条件下都直接生效的完整算法。

CPU 利用率以资源 requests 为分母。改变请求值，即使用掉的 CPU 没变，也可能改变利用率，所以纵向与横向伸缩需要协调。指标接口必须可用，目标还要支持 scale 子资源。HPA 修改 Deployment 的副本数量，再由 Deployment 控制器管理 ReplicaSet 与 Pod；这几层职责不同，不应把它们统称为一个瞬间完成的操作。

默认协调周期为十五秒，但它不是端到端响应时间的承诺。指标自身还有采集窗口和传输延迟。需要区分跨 Pod 的平均用量、测量管线里的时间平均，以及控制器对建议值的稳定处理。一条过旧但格式有效的数字，仍可能误导运行正常的控制器，造成尖峰过去以后才扩容的现象。

稳定的是建议历史，不是上次调整时间

缩容稳定机制保留近期副本建议，并在配置窗口中选择最高值。默认缩容窗口为五分钟，autoscaling/v2 的 behavior 可以进一步调整。它不是从上一次真正改变副本数开始计时的简单冷却期。即使某次较高建议没有改变现有数量，只要仍在窗口里，也可能推迟下一次缩容，这正是下面模型专门展示的差异。

速率策略另外限制一段时间内可以改变多少 Pod 或百分比。因此扩容也可能被限制，不能说它永远立即、无限进行。最小副本应考虑启动延迟所需余量，最大副本应符合节点容量和成本。稳定机制能降低反复变化，却不能修复选错瓶颈或目标值的问题；把窗口加长只是改变响应方式，不会让错误信号变正确。

选择增加副本能够缓解的压力

CPU 对计算密集型请求可能有效，队列深度或每副本工作量可能更适合后台工作者。但延迟或任意资源图表，并不会天然成为合适的控制输入。如果所有副本都在等待同一台已经饱和的数据库，继续增加副本可能扩大争用，反而延长等待时间。需要先确认瓶颈能否随着应用副本增加而解除。

具体检查新增一个副本后会发生什么：工作能否分配给它，每副本压力是否下降，下游是否还有足够容量。长连接、分区不均与缓存预热都会推迟效果。控制器仅仅改变数量，不会替应用重新分片或自动迁移已有连接。观察这些行为，可以判断问题应该通过扩容解决，还是需要改变工作分配或下游容量。

坏掉的样子

缺失指标表示未知需求，不表示需求为零。多指标配置中，即使一路失败，另一条有效扩容建议仍可能使用；但失败来源会阻止其余指标建议的缩容。个别 Pod 缺失样本也有保守处理。应通过条件和事件区分这些情况，而不是假定每次缺少一个样本就停止所有动作，也不要据此手工删除仍在服务的容量。

maxReplicas 过低时，计算出的建议被限制，ScalingLimited 可以显示这一情况，但队列仍在增长。过高的下限也会掩盖真实低需求。部署自动化反复写固定 replicas 会与 HPA 竞争。还应检查 CPU 请求变化和启动就绪状态，再归咎于普通滚动更新：HPA 支持 Deployment 发布，并不是把每个初始化 Pod 都当成可以随意缩掉容量的零负载样本。

快速验证

保存为 hpa_loop.py，执行 python3 hpa_loop.py。它用标准库建模比例计算、上下限，以及取近期最高建议的缩容窗口。模型明确省略容差、速率策略、逐 Pod 样本和真实 Kubernetes 协调，不应被当作生产控制器的完整复制品。运行只涉及本地算术与列表状态，不访问集群。

import math

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


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


def step(replicas, history, now, value):
 if value is None:
 print(f"t={now}s metric=missing hold={replicas}")
 return replicas
 recommendation = desired(replicas, value)
 history[:] = [(t, count) for t, count in history if now - t <= WINDOW_S]
 history.append((now, recommendation))
 if recommendation < replicas:
 result = min(replicas, max(count for _, count in history))
 else:
 result = recommendation
 print(f"t={now}s raw={recommendation} {replicas}->{result}")
 return result


def main():
 history = []
 replicas = step(3, history, 0, 100)
 assert replicas == 6
 replicas = step(replicas, history, 240, 50)
 assert replicas == 6
 replicas = step(replicas, history, 400, 15)
 assert replicas == 6 # A recent recommendation, not a recent scale event.
 replicas = step(replicas, history, 541, 15)
 assert replicas == 2
 replicas = step(replicas, history, 600, None)
 assert replicas == 2
 assert desired(2, 500) == 10
 assert desired(2, 5) == 2
 print("PASS: recommendation history holds 6 at t=400, then shrinks to 2")


if __name__ == "__main__":
 main()

零秒时模型从三个副本扩到六个。二百四十秒时再次建议六个，数量并未变化。四百秒时新的原始建议为两个，但近期的六副本建议仍在窗口内，所以继续保持六个；此时距离上次实际扩容已超过五分钟。五百四十一秒时，那个较高建议离开窗口，模型才缩到两个。这说明约束来自建议历史，而不是上次调整的时间戳。

两种语言中的代码均在本轮通过 Python 3.12.14，包含输入缺失保持和两个边界断言。这些结果只证明模型声明的行为。调试真实集群时，还应按时间对照 HPA 条件、副本建议、实际数量、Pod 就绪和应用延迟。本轮没有运行真实控制器或指标管线，本地成功不能代替真实系统验证。

来源

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

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

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

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

这是历史实验观察，不是新的集群运行结果。缺少键时的不等式会影响查询成员；Service 选择不会强制实施网络授权。实验使用普通就绪行为，未执行 NetworkPolicy 隔离。

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

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

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

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

坏掉的样子

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

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

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

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

快速验证

以下实验及观察结果沿用原文记录。本次审阅没有重新执行 Kubernetes 集成实验；文中的成功结果属于历史记录，不代表本轮取得了新的运行证据。

准备可丢弃的 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-10-15。
Kubernetes: Services，基于选择器的后端发现，已核验 2026-10-15。
Kubernetes: EndpointSlices，端点身份及就绪条件，已核验 2026-10-15。

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

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

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

命名空间身份只是一类边界。历史实验未证明网络政策执行、CPU 公平性或面对敌对租户的完整隔离。ResourceQuota 约束准入，不是运行中进程带宽或物理容量预留。本次未重跑示例。

名称范围取决于资源类型

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

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

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

坏掉的样子

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

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

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

快速验证

历史集群集成示例保持原样；当前没有 Kubernetes，因此本次没有重跑。

准备使用默认 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 更换而受影响。

前后集合是模型结果，不是传输测试。稳定发现不证明每个请求都会成功。端点条件、端口和数据路径需分别检查。精确本地模型本轮再次通过；未执行 Kubernetes 或传输测试。

一个地址，一组 Pod

普通 ClusterIP Service 在对象存续期间保持虚拟地址，集群 DNS 提供发现名称。调用方可以依赖这个名称，而后端可互换的 Pod 逐渐被替换。这把稳定的客户端契约与单个后端生命周期分开，不需要每替换一个副本就推送客户端配置。但稳定身份仍有明确范围，不能扩写成全部网络行为都不会变化。

无头和 ExternalName Service 具有不同发现行为，无选择器 Service 则可以使用单独管理的 EndpointSlice。虚拟地址稳定的结论应限于普通情形。Deployment 管理工作负载，本身不是发起网络连接的客户端；真正使用发现结果的是应用、网关和其他组件。审阅调用关系时，应区分资源控制与请求转发这两层。

选择规则决定由谁响应

带选择器的 Service 识别本命名空间里匹配的 Pod，EndpointSlice 控制器异步协调地址和条件。就绪通常决定普通流量资格，但未就绪端点可能继续存在，只是就绪条件为假，不一定从 API 对象中彻底删除。列表成员、成员条件和最终是否选择它，是需要分别观察的状态。

选择器不会授权网络访问，标签匹配也不证明 targetPort 正确或应用能返回有用响应。publishNotReadyAddresses 与终止中端点处理还会影响解释。需要先核对选中集合及条件，再检查实际数据路径；这些观察相关，却不能互相替代。未被一个 Service 选中的 Pod，也可能通过其他入口被访问，不能把发现名单当成隔离策略。

流量总给当前匹配的

扩缩容和替换可以在同一名称背后进行，但名称不保证请求连续。已经连接到某个后端的会话，可能因后端终止而失败；更新传播到代理需要时间，没有可用端点时，即使 DNS 仍能解析也不能服务。稳定地址并不负责迁移已建立连接，更不会自动补足被删掉的副本容量。

应联合规划就绪、更新容量、终止排空和客户端重试；非幂等操作还需要应用层保证重复请求安全。替换期间要实际观察可用性，不能宣称选择器足够精确就没有任何中断。下方本地模型只演示集合选择，不验证传播时间和传输行为，也不证明一次集合替换就等于完成无损发布。

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

应把 Service 名称当成受支持的发现接口，而不是缓存某次看到的 Pod IP。使用普通 Service VIP 的调用方，不需要每次后端变化都重新解析，但永远只在启动解析一次，会在 Service 删除重建、地址变化时失败。应按客户端库的行为处理解析与连接生命周期，不能把后端稳定抽象误读成无限缓存许可。

无头服务的答案可能包含变化的端点地址，因此调用方需要自己的发现与均衡行为。要测试库如何刷新 DNS、替换连接和处理过期结果。稳定是带生命周期条件的接口契约，不是关闭刷新或忽略失败的理由；名称继续存在、地址仍有效、连接仍可用，也不是完全相同的三个判断。

坏掉的样子

最安静的故障是选择器谁也选不中。比如把 app: web 写成 app: webs,或者 Deployment 不再给 Pod 打预期标签,Service 的端点集合就会变成空。此时集群 IP 与 DNS 名字依然能解析,故障表现为连接被拒绝或超时,而不是名字不存在。当 Service 能解析却送不出流量时,先看它的端点集合:空的可用集合可能来自标签、就绪、Pod 地址或协调进度，本身也不能排除另有网络问题。

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

端口配错是从另一侧打破承诺。Service 映射到错误的容器 targetPort，就无法把请求交给预期监听者;手选一个已经分配的 NodePort 会让 API 操作失败。ClientIP 亲和可能把共享来源地址的客户端集中到同一后端，但不表示永久绑定已经移除的端点，也不表示每次后端失败都会变成全局中断。应根据应用需求选择亲和，并单独验证故障切换。

快速验证

把下面程序保存到临时工作目录的 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()

四个场景验证的是这个本地选择模型:稳态时两个就绪的 web Pod 在集合里,未就绪者被挡在外面;滚动时选择器不变,集合从一个就绪 Pod 换成另一个;过窄的选择器会清楚地收敛为空。空选择器是反例:它大声告警,而不是悄悄匹配全部或悄悄返回空。本轮在 Linux、Python 3.12.14 上运行两种语言模型通过。空选择器告警是程序自己的保护；Kubernetes 可以通过显式管理的 EndpointSlice 支持无选择器 Service。

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

来源

Kubernetes：Services，Service 抽象，已核验 2026-10-15。
Kubernetes：Pods，Service 所选择的 Pod，已核验 2026-10-15。
Kubernetes：Deployments，管理 Pod 集合，已核验 2026-10-15。
Primary reference，端点条件与就绪例外，已核验 2026-10-15。
Primary reference，普通与无头 DNS 答案，已核验 2026-10-15。

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

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

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

阈值乘周期可辅助规划，不是精确重启时刻。启动成功不强迫就绪成功，也不保证持续健康。本轮没有重跑原文保留的 Kubernetes 集成实验。

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

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

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

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

坏掉的样子

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

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

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

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

快速验证

以下实验及观察结果沿用原文记录。本次审阅没有重新执行 Kubernetes 集成实验；文中的成功结果属于历史记录，不代表本轮取得了新的运行证据。

准备可丢弃的 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-10-15。
Kubernetes: Pod Probes，启动成功前抑制存活与就绪检查，已核验 2026-10-15。

Kubernetes Secret 需要明确的访问边界

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

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

Secret 的边界既包括直接读取者，也包括能够创建消费者的主体。窄投射只限制这一次交付，不一定限制创建者。轮换还需要交付、重载和签发方验证。此图是概念示意，本轮没有执行集群实验。

编码与保护处于不同层次

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

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

Secret 适合小规模值。Kubernetes v1.34.0 将解码后的 data 值总和限制为一 MiB；这项检查不计算 Base64 表示或元数据的大小；请求与元数据仍有各自的限制。应只挂载需要的键，并只交付给真正需要它的容器。文件模式可以缩小工作负载内部的读取范围，却不能替代 API 授权或对创建工作负载权限的控制。环境变量注入也有暴露范围和生命周期方面的取舍，应根据应用需求选择，不能默认它一定比文件更安全。

坏掉的样子

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

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

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

快速验证

以下实验及观察结果沿用原文记录。本次审阅没有重新执行 Kubernetes 集成实验；文中的成功结果属于历史记录，不代表本轮取得了新的运行证据。

准备可丢弃的 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-10-15。
Kubernetes: Good practices for Secrets，加密、最小权限与工作负载访问，已核验 2026-10-15。
Kubernetes: RBAC authorization，资源操作、角色绑定和命名空间范围，已核验 2026-10-15。
Secret validation (v1.34.0)，ValidateSecret 累加解码后的 data 值字节数，再比较 MaxSecretSize，已核验 2026-10-18。

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：镜像，可变标签与摘要固定身份，已核验 2026-10-15。

Kubernetes Deployment 描述期望状态

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

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

数量序列解释原文的本地算术模型。真实控制器各有职责，异步协调也可能受阻。历史模型通过记录保持不变；本次未重跑示例。

声明规范胜过过程脚本

一份 Deployment 是「终态」的陈述,而不是一张命令清单:多少副本、哪个镜像、哪条 tag、什么标签。操作者写下「要什么」,控制器这位 reconcile 循环决定「怎么要」。区别在于资源所有权，而不是有没有使用命令行。kubectl run 通常创建独立 Pod，kubelet 可以重启其中容器，但这个 Pod 消失后，没有 ReplicaSet 负责补足一组替代对象。Deployment 同样可以通过一条命令创建，客户端退出之后，存储下来的规范仍会持续指导控制器。中断客户端并不能可靠说明 API 是否已经接纳请求；重试或诊断收敛之前，先查看实际存储的对象，区分请求传递状态与控制器执行状态。

由控制器填补差距

Deployment 控制器管理 ReplicaSet，再由副本集控制器维持 Pod 数量。容器崩溃时，kubelet 可以在同一个 Pod 内重启容器；删除或丢失 Pod 后创建替代对象，则是另一条协调路径。它们会配合工作，但不能都说成同一个控制器每隔几秒创建一个 Pod，否则无法区分实例身份、重启与替换。

协调是异步过程，依赖控制面正常以及容量足够。镜像拉取失败、配额、准入拒绝和存储不可用，都可能长期阻止收敛。应查看条件与事件，确认究竟哪一层受阻。期望副本数是系统追求的目标，不是真实就绪容量的证据，也不是恢复时间上限；控制器反复尝试不等于问题已经得到解决。

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

修改 Pod 模板会触发发布与修订版本，单纯缩放不会。控制器按照更新策略、就绪和可用性要求调整新旧 ReplicaSet 数量。流量由 Service 与对应数据路径另行处理，Deployment 控制器本身不是逐条迁移连接的代理。发布状态和请求成功需要分别观察，不能把模板变化自动等同于无中断流量切换。

回滚恢复先前 Pod 模板，不会恢复 Deployment 所有字段，更不会撤销数据库模式等外部状态。保留的 ReplicaSet 提供回滚历史，revisionHistoryLimit 默认十份，清理从发布完成之后开始。流水线重复应用未变化的模板，并不会只因执行了一次就生成新修订；版本库审计与集群修订解决的是不同范围的历史问题。

坏掉的样子

apps/v1 Deployment 的选择器不可变，Pod 模板必须匹配它。模板违反选择器时会被 API 校验拒绝，不是先接受对象，再持续产生不受管理的游离 Pod。需要改变选择器时，应规划明确迁移。选择器重叠值得审查，但仅仅标签匹配，不会抹掉已有控制所有者引用，不能把所有重叠都解释成控制器互抢副本。

删除受管理 Pod 或直接缩放下层 ReplicaSet，可能被负责的控制器纠正。相比之下，kubectl scale deployment 修改的就是 Deployment 期望副本数，直到其他参与者再次修改才会变化。HPA、后续 apply 或 GitOps 协调器可能覆盖它；Deployment 自己不会秘密记住版本库里的旧数字。应找出真正写入该字段的主体，再制定紧急缩放流程。

受阻发布可能因清理完成条件未满足，保留超过预期数量的 ReplicaSet。宣布历史泄漏前，应查看 rollout 状态。外部变更历史与经验证回滚计划仍应保留；历史上限零会移除正常回滚目标，但数量大本身也不能证明控制面性能已经下降。需要用实际对象状态与系统指标区分暂时保留、策略选择和真实故障。

快速验证

把下面程序存成 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 template must fail this validation model"

 print(f"desired={desired} final-observed={observed}")
 print(f"recovery-actions={actions}")
 print(f"observed-count-drift-corrected={drift}")
 print("PASS: controller closes the desired-vs-observed gap; mismatched template is rejected by the local validation check")


if __name__ == "__main__":
 main()

两次整数数量恢复都以同步结尾。另一个标签检查把不匹配模板作为反例拒绝，演示 API 接纳之前要检查的契约，但没有提交真实 Deployment，也没有实现接管、监听、调度和就绪机制。跑通后会打印两次补差动作序列与最终同步,手工多出的副本被删回期望数。若把期望改成你的真实副本数再跑一遍,收敛结论不变,数字跟着变。

本轮在 Linux、Python 3.12.14 上运行两种语言的断言通过。模型只验证收敛算术,不涉及调度探针与存储,发布日之前,还要去真实集群确认选择器、副本数与历史版本数，并检查真正的就绪容量与请求失败率。

来源

Kubernetes：Deployments，Deployment 资源的说明，已核验 2026-10-15。
Kubernetes：Controllers，Kubernetes 及其模型，已核验 2026-10-15。

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

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

PersistentVolumeClaim 把存储的生命周期与重建的 Pod 分开，但不保证一定能恢复数据。PersistentVolume 描述存储，声明请求存储，由控制器安排绑定或供应。真正的恢复仍取决于后备存储、可用拓扑与备份；有了 StorageClass，可以由 provisioner 动态供应，而不必预先建好每块卷。

声明与卷各自有独立的生命周期。finalizer 可以推迟对象删除，回收策略决定释放后的存储如何处理。维护前应核对两者：处理失误可能留下持续 Terminating 的声明、删掉本想保留的数据，或留下一份没人在用却仍在计费的存储。

保护机制推迟删除，不证明控制器健康。Retain 需要核对归属、备份并按提供方流程决策。保留诊断仍受阻，本轮未重跑。

声明、卷与绑定

普通匹配会检查容量、访问模式、存储类、volumeMode、选择器及既有归属。不匹配的声明可以停在 Pending，应检查事件与 StorageClass，不能只猜一个原因。绑定不证明拓扑可用：显式指定 PV 时，即使节点亲和性冲突也可能绑定成功，后续调度与挂载仍需各自成功。已释放但尚未回收的 Retain 卷也不会自动成为新声明的可用备件；旧 claimRef 可能仍然存在。

accessModes 没有默认值。ReadWriteOnce 允许单节点读写挂载，该节点上的多个 Pod 仍可能共用它，不是单 Pod 独占。ReadWriteOncePod 才为受支持的 CSI 卷提供单 Pod 约束；访问模式本身并不在挂载后执行写保护。Immediate 不等待消费者就开始绑定或供应，受拓扑限制的存储可能因此无法使用。受支持的 WaitForFirstConsumer 则结合消费 Pod 的调度约束协调存储，之后才完成放置；它不是先完成调度再随意创建卷。

删除顺序与 finalizer

通常先停用 Pod，再处理声明与卷。删除仍在使用的声明会记录 deletionTimestamp，但 kubernetes.io/pvc-protection 可以推迟对象消失。Kubernetes v1.34.0 对普通 PVC 引用的检查只计入已经分配节点的 Pod；仅有未调度 Pod 引用，并不会维持这项保护。这是控制器的引用检查，不是实时挂载探测。因此，持续 Terminating 的声明需要检查已调度消费者、控制器进度和其他 finalizer，不能仅凭状态推断唯一原因。

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

回收策略：Delete 还是 Retain

声明最终消失后，卷被释放，回收策略接手。存储插件支持时，Delete 异步回收 PV 与后备资产，不保证两者立即或原子地消失。Retain 保留 PV 对象、把它标成 Released，并且刻意不让它被新的声明使用，因为上一个占用者的数据还在上面——回收于是变成一串手工动作：确认归属与备份，再按存储提供方流程有意回收、复用或删除资产，而不是把删除写成唯一结局。

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

坏掉的样子

最经典的是删不掉的声明。有人删了 PVC，看到 Terminating，然后开始等——而某个 Pod 仍然挂着它，通常是没缩容到零的 StatefulSet，或者卡在不可达节点上的 Pod。没有报错，没有超时，而这份 PVC 一直占着背后的存储。正确做法是找到那个 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)"'

这些保留的诊断本轮没有执行。保护标记说明清理待完成，不证明控制器健康，也不证明一定还有 Pod。第四条查找所有命名空间内名为 data 的声明，因此必须先核对目标命名空间，再确认某个 Pod 是否是消费者。Released 加 Retain 需要归属与恢复决策，不代表应自动删除；旧 claimRef 也可能仍然存在。

来源

Persistent Volumes，绑定、访问模式、回收策略、Released 状态与 pvc/pv 保护 finalizer，已核验 2026-10-15。
Storage Classes，动态供应、reclaimPolicy 与 volumeBindingMode，已核验 2026-10-15。
Persistent Volumes (v1.34)，v1.34 预绑定、访问模式边界与受支持的回收行为，已核验 2026-10-18。
PVC protection implementation，v1.34.0 podUsesPVC 的节点分配及显式引用检查，已核验 2026-10-18。

HPA 按负载缩放 Deployment 的副本

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

HorizontalPodAutoscaler 是反馈控制器，不是容量规划器，默认同步间隔为十五秒。根据配置，它读取资源、自定义或外部指标，再更新工作负载的 scale 子资源。基本计算为 desiredReplicas = ceil(currentReplicas * currentMetricValue / desiredMetricValue)，之后还要考虑缺失数据、就绪状态、容忍度、稳定窗口及上下界，不能只靠这一行公式预测全部实际行为。

一份看起来正确的 HPA 对象，不证明容量必然及时到位。指标可用性、请求、副本上限、调度及应用启动都会影响结果。应分别查看建议副本数与真实就绪容量；提高期望数量不会制造新节点，也不能自动修好受阻发布。判断伸缩是否有效，必须跟踪从指标到应用接流量的整段过程。

原文算术示意，不是观察到的伸缩事件。保留的 Kubernetes 只读诊断仍为受阻，本次未重跑。建议四个副本不证明四个 Pod 已就绪或应用容量充足。

比值与死区

CPU 利用率目标把实际 CPU 用量与相关请求比较，得到百分比，目标本身也是百分比。如果每个 Pod 只有一个容器，都请求 200m，目标为百分之六十，那么每 Pod 120m 是便于理解的简化等价值。它不是异构 Pod 或所有指标类型通用的分母；多个容器和不同请求会改变聚合结果。

集群默认容忍度为一附近的 0.1。Kubernetes 1.34 的分方向容忍度仍为默认关闭的 alpha 功能；不能假定每个 HPA 都能覆盖它，要先检查特性开关和控制器配置。应把它理解为控制死区，而不是承诺 132m 永不伸缩、133m 必然动作。指标聚合、整数利用率、就绪状态及实现中的算术都会影响边界。忽略其他修正时，三个副本以 160m 对比 120m 目标，会建议四个副本；舍入、速率策略与最终能否调度仍需分别观察，不能从一个毫核数字直接推出真实扩容时刻。

缺失指标与一票否决

缺失 Pod 指标采用保守处理。Kubernetes 1.34.0 的 GetResourceReplicas 在缩容时，把缺失样本补为该 Pod 的资源请求乘以 max(100%, 目标利用率)；普通逐 Pod 指标分支 calcPlainMetricReplicas 则使用目标量。两者扩容时都补零。因此，请求 200m、目标利用率 60% 时，缩容替代值是 200m，而不是 120m。重新计算可能取消动作；状态中显示的利用率仍基于原有可用样本，不包含这些保守假定。CPU 对尚未就绪的 Pod 还有额外处理，涉及可配置的就绪延迟与初始化窗口。这些规则围绕启动采样及就绪变化，不表示所有 Pod 都一律被忽略整整五分钟。诊断时应查看实际采样和状态时间，不能把默认窗口当成一个简单倒计时。

CPU 利用率计算需要相关资源请求；即使 kubectl top 能报告用量，缺失 request 仍可能让该指标不可计算。配置多个指标时，HPA 选择最大的建议副本数；一个不可用指标可能阻止缩容，另一个有效指标却仍能支持扩容。因此，缺一个来源不代表整个控制器必然停止，必须结合每个指标的结果和状态条件解释。

稳定窗口与速率限制

默认缩容会考虑五分钟建议窗口，并选取其中仍相关的最高建议，以减轻振荡。这不是从外部负载曲线回落开始严格等待五分钟的保证。建议记录、当前副本、上下界和行为配置共同决定何时缩减。默认扩容稳定窗口为零，但用户可以修改行为；没有稳定窗口也不表示完全没有同步、采样和启动延迟。

默认扩容速率策略允许十五秒内增加四个 Pod 或当前数量的一倍，取允许变化较大的策略。默认缩容策略可允许在其周期内全部减少，但仍受到稳定窗口和最小副本数限制。这是允许速率，不是自动按一、五、十不断增长的命令。指标必须要求相应扩容，maxReplicas 仍会封顶，新增副本还要经过实际调度与就绪过程。

坏掉的样子

利用率 unknown 可能来自缺失请求、指标不可用、授权问题或其他获取与计算错误。应读取 ScalingActive 及其原因，不能把 unknown 直接当作没有 CPU 样本的证明。需要检查所有相关容器，只查第一个容器不能确定整份 Pod 的分母；同时还要核对准入默认值与实际 HPA 指标类型。

达到 maxReplicas 的工作负载，即使控制器正确执行配置，也可能继续过载。ScalingLimited 能说明数量受限，但容量规划还需要节点空间、启动延迟和下游承载能力。提高上限可能只制造更多 Pending Pod，或压垮共享依赖。宣布自动伸缩成功前，应比较期望副本、可用副本与服务延迟，不能只看到 desired 数字增加就认为问题解决。

快速验证

以下保留的只读诊断本轮没有重新执行。请明确选择获准测试集群和命名空间，并把简略输出与完整 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-10-15。
HPA walkthrough，对 metrics-server 与 requests 的依赖，已核验 2026-10-15。
metrics-server，HPA 读取的 resource metrics API 实现，已核验 2026-10-15。
Kubernetes 1.34 HPA，按版本限定的容忍度与缺失指标保守处理，已核验 2026-10-18。
Kubernetes v1.34.0 副本计算实现，区分资源利用率与普通逐 Pod 指标的缺失样本替代，已核验 2026-10-18。

liveness 与 readiness 告诉 Kubernetes Pod 的状态

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

慢启动不等于进程已死。readiness 与 liveness 分别决定普通 Service 流量是否应该进入这个 Pod，以及终止容器是否有助于恢复，两项决策相互独立。readiness 失败不会暂停 liveness；需要配置 startup 探针，才能在启动阶段抑制另外两种检查。只把接口分成两个名字，不能自动解决这个时序问题。

本文关注健康信号的选择与接线错误的诊断。关键是每次检查实际测到了什么，而不是 URL 名称。共用一个接口可以合理；共用会因下游抖动而失败的检查，并据此触发不必要的重启，却可能扩大故障。设计时应验证具体故障模式与预期恢复动作，不能假定有两个接口就天然安全，也不能把“还没准备好”直接解释成“需要杀死重来”。

普通 Service 路由异步收敛；已有连接与 Pod 直连需要另行考虑。

Readiness 把流量挡在门外

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

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

Liveness 守护进程本身

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

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

给探针留足余量

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

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

坏掉的样子

标志性故障是依赖故障期的重启循环：数据库变慢，本来就绪探针就够了，但存活探针共用同一个失败的接口，全集群一波波重启。每次重启清空热缓存，下一波恢复更慢，系统无限振荡。诊断看重启时间戳与依赖事故是否对齐；修法是调整决策语义，让重启信号保持本地且确实有助于恢复。就绪检查关键依赖可能有用，但共享下游故障时撤掉全部副本，可能比提供降级响应更糟。

镜像故障是僵尸 Pod：服务能响应所以存活探针通过，但请求全卡在死锁的工作池后面。流量源源不断送进一个什么都不回答的 Pod。短超时申请工作槽无法区分死锁与健康但饱和的工作池，反而可能在过载时触发重启。应寻找关键工作机制停止推进的证据，容纳预期停顿与正常空闲，并验证重启确实能改善这类故障。暂时过载需要另行处理，不能用一次抢不到槽位就证明进程已无法自行恢复。

快速验证

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

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

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

来源

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

Kubernetes · XB 现场笔记

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

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

坏掉的样子

快速验证

来源

Kubernetes CronJob 需要历史清理策略

历史记录不等于日志归档

数量与年龄是独立策略

所属关系决定级联行为

坏掉的样子

快速验证

来源

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

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

坏掉的样子

快速验证

来源

Cordon 与 drain 协调节点维护

Cordon 改变未来放置

Drain 具有过滤检查和独立操作

预算约束主动驱逐

坏掉的样子

快速验证

来源

Horizontal Pod Autoscaler 依赖明确的指标语义

区分测量与控制

选择增加副本能够改善的信号

副本字段要有明确负责人

坏掉的样子

快速验证

延伸阅读

来源

CronJob 把时间表变成 Job

时间表产生的是 Job

并发策略只约束同一个 CronJob

启动期限、挂起与历史保留

坏掉的样子

快速验证

来源

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

按标签匹配节点

偏好还是强制

反亲和把副本分开

坏掉的样子

快速验证

来源

Kubernetes 滚动更新逐步替换 Pod

逐步替换，还是先停后起

兼容性才是选择依据

回滚也是一次变更

坏掉的样子

快速验证

延伸阅读

来源

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

把设置放在正确层级

坏掉的样子

快速验证

延伸阅读

来源

水平自动伸缩按需扩缩容

指标产生的是副本建议

稳定的是建议历史，不是上次调整时间

选择增加副本能够缓解的压力

坏掉的样子

快速验证

延伸阅读

来源

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

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

坏掉的样子

快速验证

来源

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

名称范围取决于资源类型

坏掉的样子

快速验证

来源

Kubernetes Service 为 Pod 提供稳定入口