调度 · 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。

Cron 系统任务表与用户任务表有不同契约

Wed, 12 Jan 2028 00:00:00 +0000

Cron 可以从不止一种任务表读取计划。用户任务表属于某个账号，而系统任务表能够为每一条记录指定运行账号。把一行原样复制到另一种表中，如果没有调整字段，cron 对命令起点的理解就会变化。排查看似正确的五字段日历表达式之前，应先确认正在编辑的到底是哪种任务表，而不是只检查分钟和小时。

Debian 用户表在五个字段后开始命令，系统表则先增加用户名。未转义百分号先于 shell 引号处理，并分离标准输入。本图为示意图；没有执行需要特权的示例。

账号列改变了解析边界

传统用户记录依次填写分钟、小时、月内日期、月份、星期，再接命令正文，由 crontab 命令安装给选定用户。Debian 的 /etc/crontab 和 /etc/cron.d 下文件，则在五个日历字段之后额外增加用户名。这个用户名属于系统表格式，并不是可以随意放进用户任务表的说明性字段；多写或少写都会改变后续解释。

月份限制仍然必须满足。当月内日期与星期都受到限制时，Debian/Vixie 的日期规则允许满足其中之一，但月份与星期并不是二选一。把表达式迁移到带秒字段或采用其他日期组合方式的调度产品前，应核对具体方言。表面上相似的空格布局，不能证明两个调度器提供相同语义。

系统任务文件还受所有权、权限、名称及末尾换行要求约束。Debian 中应采用 root 所有、组和其他用户不可写且名称被接受的文件，不要把任意备份后缀当成有效任务名。/etc/cron.daily 等周期目录通常通过发行版安排和 run-parts 被调用，不是每份脚本都独立当作 crontab 解析。实际运行时间需要查看本机已安装的调度安排。

坏掉的样子

在 root 用户自己的任务表中，五字段后再写 root，意味着让 shell 执行一个名为 root 的命令。任务表安装成功，不证明这个命令存在。反过来，系统表漏掉账号列，就会把命令文字当成用户名。审阅时需要同时检查解析边界与最终身份，尤其是任务会写文件或读取受保护数据时，不能仅凭“都是 root 配置的”推断执行账号。

任务环境同样是一份契约。不要默认交互别名、shell 启动文件或启动 cron 的父进程环境都会传给任务。需要的值应明确配置，同时选择合适的 PATH 和解释器。cron.d 文件中的环境也不应被认为自动继承 /etc/crontab 中的设置。验证时要采用真正的运行账号检查权限与输出，避免管理员手工执行成功掩盖低权限任务失败。

百分号在完整命令交给 shell 之前就有特殊含义。未转义的百分号会划分标准输入，后续百分号再变成换行。仅用 shell 引号包围内容，并不能取消 cron 的这一步解释。复杂逻辑适合放进脚本；确实需要把字面百分号写在表中时，应按 cron 规则转义。调度语法、命令能否执行和应用结果是否成功，必须分别检查。

快速验证

2026-10-19 修复草案：此版本只进行了静态检查与离线命令／文件状态替身测试，没有执行守护进程、账号或任务表变更。技术与实际运行验证仍然受阻。下文版本限定的结果属于原始示例。

未来运行需要另行授权的新建一次性 Debian 12 环境，预装 Python 3.11+、cron 3.0pl1-162、procps 与 passwd，并允许执行 /tmp 中的包装 shell 脚本；不得挂载宿主目录，不得已有 cron 进程、root 任务表、xbtime 账号或实验任务文件，/etc/crontab、/etc/cron.d 与任何用户任务表也不得启用其他计划（包括周期目录的派发），并且不得有并发管理操作。保存为 cron-tables.py，只有独立核实这些条件后才能使用 python3 cron-tables.py --isolated-disposable-lab。该参数和 root 身份都不能证明隔离。脚本仍会修改实验环境范围的账号文件和 cron 状态，结束后必须丢弃整个环境。

临时系统账号使用既有 nogroup，并把既有私有工作目录作为主目录，不新建主目录或私有组，也不初始化 lastlog；实际读取其 UID，不再假定为一千。从首次尝试修改起，账号创建、查询、任务表安装与进程启动都处于清理范围内。两份实验任务表都用 MAILTO 禁用邮件；准确的固定版本“不存在”诊断与权限或命令失败分开处理。工作进程通过同目录替换发布完整 JSON，故意错误的条目仍在五个字段后直接写 root。仅该条目选择一个简短的 SHELL 包装脚本：持共享锁核对许可，使锁描述符跨 exec 保留，再将原始命令交给 /bin/sh；诊断通过改名发布。正向运行许可与共享生命周期锁用于约束已获准工作的清理。每项清理独立尝试，进程和工作等待都有期限；错误会保留原始失败并跳过私有文件删除，但删除失败也可能只留下部分文件。撤销许可可避免延迟工作把停止文件消失误当成允许运行。屏障不能证明每个 cron 包装进程都已退出，因此仍须丢弃整个环境。

from pathlib import Path
from tempfile import mkdtemp
import fcntl
import json
import os
import pwd
import shutil
import subprocess
import sys
import time


def command(arguments, **options):
 return subprocess.run(arguments, capture_output=True, text=True, timeout=5,
 env={**os.environ, 'LC_ALL': 'C'}, **options)


def table_absent(result):
 # Debian cron 3.0pl1-162: other listing failures must abort.
 return (result.returncode == 1 and result.stdout == ''
 and result.stderr == 'no crontab for root\n')


def remove_table():
 current = command(['crontab', '-l'])
 if table_absent(current):
 return
 current.check_returncode()
 command(['crontab', '-r']).check_returncode()
 if not table_absent(command(['crontab', '-l'])):
 raise RuntimeError('could not verify table removal')


def attempt(errors, name, operation):
 try:
 operation()
 except Exception as error:
 errors.append(f'{name}: {error!r}')


def stop_daemon(daemon, errors):
 if daemon is None:
 return
 attempt(errors, 'terminate cron', daemon.terminate)
 try:
 daemon.wait(timeout=5)
 except subprocess.TimeoutExpired:
 attempt(errors, 'kill owned cron', daemon.kill)
 attempt(errors, 'reap cron', lambda: daemon.wait(timeout=5))
 except Exception as error:
 errors.append(f'wait cron: {error!r}')


def remove_account(username):
 try:
 pwd.getpwnam(username)
 except KeyError:
 return
 command(['userdel', username]).check_returncode()
 try:
 pwd.getpwnam(username)
 except KeyError:
 return
 raise RuntimeError('account removal not verified')


def wait_workers(root):
 with (root / 'lifetime.lock').open() as gate:
 deadline = time.monotonic() + 5
 while True:
 try:
 fcntl.flock(gate, fcntl.LOCK_EX | fcntl.LOCK_NB)
 return
 except BlockingIOError:
 if time.monotonic() >= deadline:
 raise TimeoutError('workers did not release lifetime lock')
 time.sleep(0.1)


worker_source = r'''from pathlib import Path
import fcntl,json,os,sys
root=Path(__file__).parent
mode=sys.argv[1]
with (root/'lifetime.lock').open() as gate:
 fcntl.flock(gate,fcntl.LOCK_SH)
 if not (root/'run-permit').exists(): raise SystemExit(0)
 data={'uid':os.getuid(),'table':os.environ.get('LAB_TABLE'),
 'path':os.environ.get('PATH'),'shell':os.environ.get('SHELL'),
 'parent_only':os.environ.get('PARENT_ONLY')}
 if mode=='percent': data['stdin']=sys.stdin.read()
 destination=root/(mode+'.json')
 temporary=root/f'{mode}-{os.getpid()}.tmp'
 temporary.write_text(json.dumps(data))
 temporary.replace(destination)
'''


shell_source = r'''#!/usr/bin/python3
from pathlib import Path
import fcntl,os,sys
root=Path(__file__).parent
with (root/'lifetime.lock').open() as gate:
 fcntl.flock(gate,fcntl.LOCK_SH)
 if not (root/'run-permit').exists(): raise SystemExit(0)
 os.set_inheritable(gate.fileno(),True)
 os.execv('/bin/sh',['/bin/sh',*sys.argv[1:]])
'''


def main():
 if sys.argv[1:] != ['--isolated-disposable-lab']:
 raise SystemExit('requires a separately verified disposable Debian 12 lab')
 if os.geteuid() != 0:
 raise RuntimeError('root is required, but does not prove isolation')
 probe = command(['pgrep', '-x', 'cron'])
 if probe.returncode != 1 or probe.stdout or probe.stderr:
 raise RuntimeError(f'cron absence not established: {probe!r}')
 if not table_absent(command(['crontab', '-l'])):
 raise RuntimeError('expected absent root table; existing table or listing error')
 if shutil.which('root', path='/usr/bin:/bin') is not None:
 raise RuntimeError('the deliberately invalid command exists')
 username = 'xbtime'
 try:
 pwd.getpwnam(username)
 except KeyError:
 pass
 else:
 raise RuntimeError('test account already exists')
 system_table = Path('/etc/cron.d/xbcatm_time_test')
 if system_table.exists() or system_table.is_symlink():
 raise RuntimeError('system test table already exists')
 root = Path(mkdtemp(prefix='cron-tables-', dir='/tmp'))
 daemon = None
 account_attempted = account_created = table_attempted = system_owned = False
 try:
 (root / 'lifetime.lock').touch(mode=0o644)
 (root / 'run-permit').touch()
 account_attempted = True
 command(['useradd', '--system', '--no-create-home', '--no-user-group',
 '--gid', 'nogroup', '--home-dir', str(root), '--no-log-init', '--shell', '/bin/sh', username]).check_returncode()
 account_created = True
 account = pwd.getpwnam(username)
 os.chown(root, account.pw_uid, account.pw_gid)
 worker = root / 'worker.py'
 worker.write_text(worker_source)
 # The account must read both files even under a restrictive parent umask.
 worker.chmod(0o644)
 guarded_shell = root / 'guarded-shell'
 guarded_shell.write_text(shell_source)
 guarded_shell.chmod(0o755)
 (root / 'lifetime.lock').chmod(0o644)
 user_table = ('SHELL=/bin/sh\nPATH=/usr/bin:/bin\nLC_ALL=C\nMAILTO=""\nLAB_TABLE=user\n'
 f'* * * * * /usr/bin/python3 {worker} user\n'
 f'* * * * * /usr/bin/python3 {worker} percent%first%second\n'
 f'SHELL={guarded_shell}\n'
 f'* * * * * root /usr/bin/id >{root}/wrong-column.tmp 2>&1; '
 f'/bin/mv {root}/wrong-column.tmp {root}/wrong-column.err\n')
 table_attempted = True
 command(['crontab', '-'], input=user_table).check_returncode()
 invalid = command(['crontab', '-'], input='* * * * * /bin/true')
 assert invalid.returncode != 0
 listed = command(['crontab', '-l'])
 listed.check_returncode()
 assert listed.stdout == user_table
 with system_table.open('x') as handle:
 system_owned = True
 handle.write('SHELL=/bin/sh\nPATH=/usr/bin:/bin\nLC_ALL=C\nMAILTO=""\nLAB_TABLE=system\n'
 f'* * * * * {username} /usr/bin/python3 {worker} system\n')
 system_table.chmod(0o644)
 daemon = subprocess.Popen(['cron', '-f'], env={**os.environ, 'PARENT_ONLY': 'parent-demo'},
 stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
 deadline = time.monotonic() + 75
 names = ['user.json', 'system.json', 'percent.json', 'wrong-column.err']
 while time.monotonic() < deadline:
 if daemon.poll() is not None:
 raise RuntimeError('cron exited')
 if all((root / name).exists() for name in names):
 break
 time.sleep(0.2)
 else:
 raise AssertionError('scheduled table outputs were not produced')
 user = json.loads((root / 'user.json').read_text())
 system = json.loads((root / 'system.json').read_text())
 percent = json.loads((root / 'percent.json').read_text())
 wrong = (root / 'wrong-column.err').read_text()
 assert user['uid'] == 0 and user['table'] == 'user'
 assert system['uid'] == account.pw_uid and system['table'] == 'system'
 assert all(value['parent_only'] is None for value in (user, system))
 assert all(value['path'] == '/usr/bin:/bin' for value in (user, system))
 assert all(value['shell'] == '/bin/sh' for value in (user, system))
 assert percent['stdin'] == 'first\nsecond\n'
 assert 'root: not found' in wrong
 print(json.dumps({'user_table': user, 'system_table': system,
 'missing_final_newline_rejected': invalid.returncode,
 'previous_table_preserved': True, 'percent_stdin': percent['stdin'],
 'username_in_user_table_fails': wrong.strip()}), flush=True)
 finally:
 original = sys.exc_info()[1]
 errors = []
 attempt(errors, 'revoke run permit', lambda: (root / 'run-permit').unlink(missing_ok=True))
 if system_owned:
 attempt(errors, 'remove system table', lambda: system_table.unlink(missing_ok=True))
 if table_attempted:
 attempt(errors, 'remove root table', remove_table)
 stop_daemon(daemon, errors)
 attempt(errors, 'wait for workers', lambda: wait_workers(root))
 if account_attempted:
 attempt(errors, 'remove account', lambda: remove_account(username))
 if not account_created:
 errors.append('account creation failed partway; database state needs lab disposal')
 if not errors:
 attempt(errors, 'remove private files', lambda: shutil.rmtree(root))
 if errors:
 message = 'cleanup incomplete; discard lab: ' + '; '.join(errors)
 if original is not None:
 original.add_note(message)
 else:
 raise RuntimeError(message)


if __name__ == '__main__':
 main()

原始历史运行中，用户表任务以 UID 零执行，系统表任务使用当时分配 UID 一千的新建账号。本次修订改为创建系统账号，并核对实际查询到的 UID。两者分别得到自己的 LAB_TABLE 值和明确配置的 PATH，都没有继承启动守护进程的父环境变量 PARENT_ONLY。包含百分号的记录把 first\nsecond\n 传入标准输入。错误加入用户名的用户记录则输出 root: not found，即使它所在的任务表此前已经成功安装。

程序还尝试用没有末尾换行的新内容替换任务表，该操作以退出码一被拒绝，原表保持不变。原始示例曾报告全部断言在 cron 3.0pl1-162 上通过；修订版本尚无真实守护进程结果。额外探测发现，这个软件包即使使用检查选项，也接受了错误的分钟文字，因此这里不会从退出码零推导出所有字段都已经有效；记录的是版本限定的实际观察，而不是猜测其他版本必然相同。

实验验证账号、环境、百分号解析及安装失败后的保留行为，没有测试邮件投递、夏令时处理或实际业务成功。部署真正任务时，应把这些额外要求继续列为可验证条件，并检查最终运行结果，不能以文件存在或安装命令成功替代完成证据。

来源

Debian 12: crontab(5)，用户与系统任务表格式、环境及百分号处理，已核验 2026-09-13。
Debian 12: cron(8)，系统任务文件、所有权和执行环境，已核验 2026-09-13。
Debian 12: crontab(1)，任务表安装、检查选项和末尾换行要求，已核验 2026-09-13。
Python 3.11 subprocess，超时与子进程清理语义，已核验 2026-10-19。
Debian cron 3.0pl1-162 crontab.c，区分不存在任务表的诊断与其他失败，已核验 2026-10-19。
Python 3.11 os.replace，同文件系统原子发布，已核验 2026-10-19。
Debian cron 3.0pl1-162 do_command.c，所选 shell 接收 -c 与命令，已核验 2026-10-19。
Python 3.11 os，描述符继承与 exec，已核验 2026-10-19。
Linux flock(2)，跨 exec 的锁生命周期，已核验 2026-10-19。
Debian 12 useradd(8)，系统账号、组、主目录与日志初始化选项，已核验 2026-10-19。

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

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。

Requests 参与放置，limits 约束资源消耗

Thu, 27 May 2027 00:00:00 +0000

Requests 参与放置和资源共享，limits 约束运行时消耗。它们是有关联的输入，不是对应用性能的一套通用下限与上限保证。应结合负载行为、争用风险和恢复要求选择，并查看准入后的 Pod，因为默认值与策略可能改变清单里提交的资源值。先区分记账、实际使用和执行约束，才能解释配置为什么影响行为。

解释放置前先读准入后的请求。CPU 节流和内存压力具有不同机制，需要关联证据；资源字段都不保证应用性能。

默认值也是契约的一部分

某资源只有 limit、没有 request 时，如果准入没有提供另一请求，Kubernetes 会把限制复制为请求。因此，只配 limit 通常不是零调度成本。LimitRange 默认值与 ResourceQuota 检查也会影响准入。解释 Pod 为什么 Pending 之前，应读取实际保存的两张资源映射，不能仅凭源文件中某一字段缺失进行判断。

Request 不会预先分配应用的物理内存，也不必然独占 CPU 核心。CPU 请求参与调度及争用时的相对份额。没有 CPU limit 的容器可以利用超过请求的空闲 CPU，但节点容量、祖先约束和竞争负载仍然构成边界。省略限制可能是有意选择，应配套明确容量和争用策略，而不是简单认定只配一边必然错误。

Linux 上 CPU limit 通常通过带宽节流执行，耗尽配额本身不会直接杀死进程。但等待可能增加延迟、触发应用超时或影响探针。整机 CPU 平均值低，也不能排除某个上限很紧的容器正在频繁节流。要比较对应时间窗口的需求、配额和等待，而不是拿整机平均值替代容器约束。

内存具有不同失败行为

内存限制不是 CPU 那种周期额度。内核可以回收记账内存，并在无法满足约束时触发控制组 OOM；它是响应实际压力的机制，不是看板曲线越线就立刻杀死进程。节点压力与应用自身失败又是另外的机制。应区分容器 OOM、节点驱逐和普通进程终止，避免给所有重启使用同一种解释。

容器记账内存不只包含托管堆。原生分配、线程栈、文件相关内存以及内存型卷都可能参与。进程 RSS 和应用堆指标很有用，却都不等于控制组全部计费字节。应依据运行时与内核检查合适的记账视图，并考虑采样间隔可能漏掉的短峰值，不能只把堆参数与 limit 作一次简单大小比较。

退出码 137 是 shell 风格的 SIGKILL 表示，不是 OOM 的独立证明。应结合容器终止原因、控制器计数、节点事件和负载指标；操作者或其他机制也能发送 KILL。突然终止后的日志可能不完整，但仍可揭示泄漏、过大输入或工作负载变化，不能因为怀疑 OOM 就完全排除日志证据。

根据证据定容，而不是套比例

应覆盖正常流量、发布、批处理及恢复过程采集代表性数据。计算历史分位数需要持续监控；metrics-server 与 kubectl top 提供近期资源指标，不是内建的一周 p95 档案。余量要根据负载波动和失败代价选择，不能把统一百分比当成普遍适用的容量公式，短时测试也未必包含恢复峰值。

如果显式较小的 request 不变，单纯提高 limit 通常不会额外占用调度容量；提高 request 才会减少放置余量。分析其他 Pod Pending 时应区分这两种变更。还要考虑 HPA 利用率目标，因为改变 CPU request 会改变分母，即使真实使用量不变，伸缩建议也可能跟着改变，资源调整需要联合审阅。

在传统每容器 QoS 规则下，Guaranteed 要求所有相关容器同时满足 CPU 请求等于限制、内存请求等于限制。只让内存相等不足以获得该类别。类别也不是资源故障免疫证明，固定请求比例不能代替真实需求测量与故障测试。选择配置的目标是服务行为可靠，而不是追求一个看起来更强的标签。

Kubernetes 1.34 还提供默认开启的 beta PodLevelResources。使用受支持的 Pod 级 CPU 与内存预算时，QoS 分类会考虑这些字段；前面的常规逐容器规则并非适用于所有配置的完整判据。检查准入后的对象时，也要查看 Pod 级资源字段，不能只读取第一个容器便宣布类别已经确定。

坏掉的样子

OOM 循环可能来自余量不足、泄漏、不适当的堆配置或意外输入。节流可能来自过紧配额，但也应结合请求延迟和需求解释。任何单项观察都不自动意味着应该增加上限；增加可能把压力转移给其他工作负载，或掩盖真正的应用问题。先建立原因与后果，再决定调整配额还是修正程序。

同样，没有节流也不能证明 request 应降低。请求还影响争用时份额，而观察窗口可能没有覆盖原先要保障的需求。告警应采用负载特定的预警窗口；一个使用率阈值无法承诺在突然分配峰值前提前几天通知。重新评估时还应考虑默认值、配额和节点容量，避免只修改一个数字就期待整体风险消失。

快速验证

以下保留的只读命令本轮没有重新执行。应选择获准测试上下文，以及实际名为 prod 的目标命名空间；这个示例名称不代表可以读取未知生产集群。命令只提供初步快照，不是完整的逐容器用量比较，也没有创建受控超限条件来验证执行效果。

kubectl top pods -n prod --sort-by=memory | head
kubectl get pods -n prod -o custom-columns=NAME:.metadata.name,REQ:.spec.containers[*].resources.requests.memory,LIM:.spec.containers[*].resources.limits.memory --no-headers | head -n 15
kubectl get events -n prod --field-selector reason=OOMKilling --sort-by=.lastTimestamp | tail -n 5

Top 默认展示 Pod 合计，逐容器输出需要另行选择。自定义列列出多个容器值却没有名称，OOMKilling 事件也不保证存在或长期保留。事件为空不能成为没有 OOM 的反证。结论需要结合准入资源、终止原因、控制组计数与历史使用量，成功列出对象不等于限制已经经过运行验证。

来源

Kubernetes 资源管理，官方文档说明 requests 与 limits 的语义，已核验 2026-10-15。
Kubernetes QoS 等级，说明 Guaranteed、Burstable 与 BestEffort 行为，已核验 2026-10-15。
Primary reference，CPU 计数与内存控制器记账，已核验 2026-10-15。
Primary reference，资源指标范围，已核验 2026-10-15。
Kubernetes 1.34 Pod-level resources，Pod 级特性阶段与 QoS 判定优先级，已核验 2026-10-18。

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

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

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

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

强制反亲和让选中的同伴避开已经占用的拓扑域；拓扑分布则限制候选放置的数量差。两者都依赖选择器、命名空间范围、合格域和其他约束。

选中同伴，再定义拓扑域

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

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

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

硬规则可能形成放置上限

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

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

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

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

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

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

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

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

坏掉的样子

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

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

快速验证

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

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

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

来源

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

污点会排斥那些不打算容忍它的 Pod

Thu, 25 Feb 2027 00:00:00 +0000

污点排斥没有容忍对应效果的 Pod，容忍度只移除这项障碍，不会强制把负载送到专用硬件。专用节点设计通常还需要标签与必要的节点亲和，再分别检查容量和准入策略。不能把通行资格理解成目的地保证，也不能把容忍度当成工作负载的完整权限边界。

容忍度移除匹配污点这一项障碍。效果决定后果，放置与权限仍是其他机制。

给专用者的标记

NoSchedule 污点在未被容忍时，阻止普通的新调度，但不移动已有 Pod。这可以把 GPU 等专用节点留给特定负载。不能进一步概括为所有污点都不影响运行中程序：NoExecute 具有驱逐行为，PreferNoSchedule 则只是调度偏好。首先看清 effect，才能判断这次变更会影响新放置还是已有实例。

污点不是安全隔离。有权提交合适容忍度的主体可能获得池子资格，直接指定 nodeName 还会绕过普通调度检查。准入限制、授权和设备资源请求是另外的控制；一个 GPU 容忍度既没有请求 GPU，也不保证有空闲 GPU。审阅专用池时，需要同时核对谁能修改模板、谁能添加容忍度以及真正需要哪些硬件资源。

效果决定行为

NoSchedule 对未容忍的 Pod 构成硬性调度排除；PreferNoSchedule 提供软性避让偏好，单靠它不会让节点完全失去资格。NoExecute 还可能移除已经绑定、却没有匹配容忍度的 Pod。匹配 NoExecute 的容忍度可以带 tolerationSeconds，限定污点出现之后还能停留多久；不写时长与设置短时长具有不同后果。

执行基于污点驱逐的是相应驱逐控制器，不是调度器把正在运行的进程搬走。这不等同于 kubectl drain，中断预算处理与操作顺序并不相同。维护应选择适合的流程，先评估受影响负载，不要把 NoExecute 当成有同样保护栏的快速排空按钮。容忍过期引发的延迟动作同样需要纳入维护时间线。

配对即约定

本例演示 Equal 和 Exists 两种运算符，匹配由键、运算符、值及效果共同决定。Equal 比较值，Exists 忽略指定键的值；空 effect 覆盖所有效果。合法的空 key 需要 Exists，并把匹配扩展到所有键。应校验 API 格式，不能让不合法输入在本地模型里悄悄变成通配符；未来或其他版本的运算符也不在本例范围内。

匹配完成之后，所有剩余硬性污点都必须被容忍，这项调度过滤才通过。但资源、亲和、卷和其他调度插件仍可以拒绝节点。对专用节点标签设置必要亲和，才补上容忍度刻意不提供的目的地限制。许可进入与要求只能进入，是两条不同契约，缺少后一条时专用负载完全可能落到通用节点。

模型限定为 Kubernetes 1.34 的 Equal/Exists 子集，把省略的字符串值按空字符串比较。它不是完整的 API 校验、默认填充或准入实现。后续版本由特性开关控制的其他操作符，需要另行按版本检查，不能直接当作本模型已经支持。

坏掉的样子

最贵的故障是过宽的容忍度污染了专用池。一条写着 operator: Exists 却不带值的容忍度，或一份被复制进公共图表的容忍度，会匹配该键下的所有取值，于是普通发布突然有资格落到图形处理器或竞价节点上。预留池被廉价负载占满，而它真正要服务的专用负载反而长期等待调度。这恰好与守护进程集的故障互为镜像：那边是缺了容忍度导致专用节点没有覆盖，这边是多了容忍度导致专用节点失去保护。应审计宽泛容忍度，但它不是 RBAC 授权；公共模板里必须写清键、值与效果。

第二种故障是把本该用 NoSchedule 的地方写成了 NoExecute。前者只拦截新负载，后者会把没有匹配容忍度的运行中负载直接驱离，还可能在 tolerationSeconds 倒计时结束后动手。一个维护污点若选错效果，就可能意外驱逐生产负载，而从示例里顺手复制的六十秒容忍倒计时，会把一次预留变成一场无人排期的延迟驱逐。与标准 IgnoredDuringExecution 节点亲和不同，污点侧的效果字段自带破坏力，因此维护污点先在单台节点演练，看过负载分布再向整池推广。

第三种故障是污点与容忍度之间的拼写漂移。节点上的 dedicated=gpu:NoSchedule 永远遇不上清单里的 dedicated=GPU:NoSchedule，写着 PreferNoSchedule 的容忍度也覆盖不了 NoSchedule 的污点。专用负载于是长期等待调度，事件里写着存在污点但负载未能容忍，而池子表面一切健康。请用查看负载详情的输出对照查看节点污点的输出，逐字比对两侧，再把规范的三元组收敛到同一份文档里，避免口头约定慢慢走样。

快速验证

把下面的代码存为污点容忍模拟脚本并运行。它只用标准库，不触碰任何集群，复刻上文四条匹配规则：按键匹配，按运算符与取值匹配，按效果匹配，软偏好永不拦截。

def tolerates(taint, tol):
 """一条容忍度按键、取值、运算符与效果匹配一条污点。"""
 operator = tol.get("operator", "Equal")
 if operator not in {"Equal", "Exists"}:
 raise ValueError("model supports only Equal and Exists")
 if not tol.get("key") and operator != "Exists":
 raise ValueError("empty key requires Exists")
 if operator == "Exists" and tol.get("value"):
 raise ValueError("Exists requires an empty value")
 if tol.get("key") and tol["key"] != taint["key"]:
 return False
 if tol.get("operator", "Equal") == "Equal":
 if tol.get("value", "") != taint.get("value", ""):
 return False
 effect = tol.get("effect", "")
 if effect and effect != taint.get("effect"):
 return False
 return True


def schedulable(taints, tolerations):
 """只有硬性污点全部被容忍时负载才允许调度。"""
 for taint in taints:
 if taint["effect"] == "PreferNoSchedule":
 continue
 if not any(tolerates(taint, tol) for tol in tolerations):
 return False
 return True


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


def main():
 gpu = {"key": "dedicated", "value": "gpu", "effect": "NoSchedule"}
 exact = {"key": "dedicated", "value": "gpu", "effect": "NoSchedule"}
 check(schedulable([gpu], [exact]), True, "精确匹配允许调度")
 check(schedulable([gpu], []), False, "缺失容忍应当拒绝")
 wide = {"key": "dedicated", "operator": "Exists", "effect": "NoSchedule"}
 other = {"key": "dedicated", "value": "spot", "effect": "NoSchedule"}
 check(schedulable([other], [wide]), True, "存在运算符匹配任意取值")
 check(schedulable([gpu], [{"key": "dedicated", "value": "spot", "effect": "NoSchedule"}]), False, "错误取值应当拒绝")
 evict = {"key": "maintenance", "value": "drain", "effect": "NoExecute"}
 any_effect = {"key": "maintenance", "value": "drain"}
 check(schedulable([evict], [any_effect]), True, "空效果覆盖任意效果")
 check(schedulable([evict], []), False, "未容忍的 NoExecute 不通过调度过滤")
 soft = {"key": "cost", "value": "cheap", "effect": "PreferNoSchedule"}
 check(schedulable([soft], []), True, "软偏好永不拦截")
 print("PASS: 7 scenarios; allow and repel verified")


if __name__ == "__main__":
 main()

七个场景锁定关键行为：精确匹配证明放行成立，缺失容忍证明拒绝成立，存在运算符匹配任意取值但错误取值仍被挡回，空效果覆盖驱逐型污点，未容忍的 NoExecute 不通过该过滤，但模型没有执行真实驱逐，而软偏好永不拦截。预期输出以通过信息结尾，说明七组场景成立。

本轮在 Linux、Python 3.12.14 上重新运行两种语言的实验，并额外验证不合法容忍度、空键与效果错配反例。它只验证匹配逻辑，不验证容量亲和与真实污点。上线前请对照负载事件与节点实际污点列表复核，再改生产配置。

来源

Kubernetes 污点与容忍，说明效果与调度，已核验 2026-10-15。
Kubernetes 节点亲和，说明按节点标签匹配负载，已核验 2026-10-15。
Kubernetes v1.34.0 core API types，可省略的字符串值与 Equal/Exists 容忍操作符，已核验 2026-10-18。

调度 · XB 现场笔记

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

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

坏掉的样子

快速验证

来源

Kubernetes CronJob 需要历史清理策略

历史记录不等于日志归档

数量与年龄是独立策略

所属关系决定级联行为

坏掉的样子

快速验证

来源

Cron 系统任务表与用户任务表有不同契约

账号列改变了解析边界

坏掉的样子

快速验证

来源

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

按标签匹配节点

偏好还是强制

反亲和把副本分开

坏掉的样子

快速验证

来源

Requests 参与放置，limits 约束资源消耗

默认值也是契约的一部分

内存具有不同失败行为

根据证据定容，而不是套比例

坏掉的样子

快速验证

来源

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

选中同伴，再定义拓扑域

硬规则可能形成放置上限

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

坏掉的样子

快速验证

来源

污点会排斥那些不打算容忍它的 Pod

给专用者的标记

效果决定行为

配对即约定

坏掉的样子

快速验证

延伸阅读

来源