调度 · XB 现场笔记

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

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

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

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

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

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

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

坏掉的样子

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

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

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

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

快速验证

以下实验及观察结果沿用原文记录。本次审阅没有重新执行 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 本来就有默认历史上限；省略显式历史字段，并不意味着普通已完成运行会无限堆积。分析清理问题时，先分清对象类型与状态，再判断是哪项机制没有覆盖。

历史记录不等于日志归档

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 对命令起点的理解就会变化。排查看似正确的五字段日历表达式之前，应先确认正在编辑的到底是哪种任务表，而不是只检查分钟和小时。

账号列改变了解析边界

传统用户记录依次填写分钟、小时、月内日期、月份、星期，再接命令正文，由 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 规则转义。调度语法、命令能否执行和应用结果是否成功，必须分别检查。

快速验证

本轮复核没有重复需要特权的守护进程、账号和任务表操作，上述版本限定结果保留为此前观察。

使用全新的临时 Debian 12 Docker 容器，以 root 运行，安装 python3、cron、procps 和 passwd。确认没有活动 cron 进程、已有 root 任务表，以及名为 xbtime 的账号。将代码保存为 cron-tables.py，执行 python3 cron-tables.py。它只创建实验账号、任务文件和临时目录，最多等待七十五秒经过一个真实计划分钟，结束后会清理这些资源。

from pathlib import Path
from tempfile import TemporaryDirectory
import json
import os
import pwd
import shutil
import subprocess
import time

assert os.geteuid() == 0 and Path('/.dockerenv').exists(), 'use a disposable root Linux container'
assert subprocess.run(['pgrep', '-x', 'cron'], capture_output=True).returncode == 1
assert subprocess.run(['crontab', '-l'], capture_output=True).returncode != 0
assert shutil.which('root') is None
username = 'xbtime'
try:
 pwd.getpwnam(username)
except KeyError:
 pass
else:
 raise AssertionError('test account already exists')
system_table = Path('/etc/cron.d/xbcatm_time_test')
assert not system_table.exists()
subprocess.run(['useradd', '--create-home', '--shell', '/bin/sh', username], check=True)
account = pwd.getpwnam(username)
daemon = None
try:
 with TemporaryDirectory(prefix='cron-tables-') as directory:
 root = Path(directory)
 os.chown(root, account.pw_uid, account.pw_gid)
 worker = root / 'worker.py'
 worker.write_text('''from pathlib import Path
import json,os,sys
root=Path(__file__).parent
mode=sys.argv[1]
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()
(root/(mode+'.json')).write_text(json.dumps(data))
''')
 user_table = ('SHELL=/bin/sh\nPATH=/usr/bin:/bin\nLAB_TABLE=user\n'
 f'* * * * * /usr/bin/python3 {worker} user\n'
 f'* * * * * /usr/bin/python3 {worker} percent%first%second\n'
 f'* * * * * root /usr/bin/id >{root}/wrong-column.err 2>&1\n')
 subprocess.run(['crontab', '-'], input=user_table, text=True, check=True)
 invalid = subprocess.run(['crontab', '-'], input='* * * * * /bin/true',
 text=True, capture_output=True)
 assert invalid.returncode != 0
 assert subprocess.check_output(['crontab', '-l'], text=True) == user_table
 system_table.write_text('SHELL=/bin/sh\nPATH=/usr/bin:/bin\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)
 try:
 deadline = time.monotonic() + 75
 names = ['user.json', 'system.json', 'percent.json', 'wrong-column.err']
 while time.monotonic() < deadline:
 assert daemon.poll() is None
 if all((root/name).exists() and (root/name).stat().st_size 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 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:
 daemon.terminate()
 daemon.communicate(timeout=5)
 daemon = None
finally:
 if daemon is not None:
 daemon.terminate()
 daemon.communicate(timeout=5)
 system_table.unlink(missing_ok=True)
 subprocess.run(['crontab', '-r'], capture_output=True)
 subprocess.run(['userdel', '--remove', username], capture_output=True, check=True)

用户表任务实际以 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。

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

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

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

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

按标签匹配节点

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

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

偏好还是强制

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

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

反亲和把副本分开

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

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

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

坏掉的样子

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

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

快速验证

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

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

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

来源

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

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

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

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

默认值也是契约的一部分

某资源只有 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 请求等于限制、内存请求等于限制。只让内存相等不足以获得该类别。类别也不是资源故障免疫证明，固定请求比例不能代替真实需求测量与故障测试。选择配置的目标是服务行为可靠，而不是追求一个看起来更强的标签。

坏掉的样子

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。

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 格式，不能让不合法输入在本地模型里悄悄变成通配符；未来或其他版本的运算符也不在本例范围内。

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

坏掉的样子

最贵的故障是过宽的容忍度污染了专用池。一条写着 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。

调度 · XB 现场笔记

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

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

坏掉的样子

快速验证

来源

Kubernetes CronJob 需要历史清理策略

历史记录不等于日志归档

数量与年龄是独立策略

所属关系决定级联行为

坏掉的样子

快速验证

来源

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

账号列改变了解析边界

坏掉的样子

快速验证

来源

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

按标签匹配节点

偏好还是强制

反亲和把副本分开

坏掉的样子

快速验证

来源

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

默认值也是契约的一部分

内存具有不同失败行为

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

坏掉的样子

快速验证

来源

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

选中同伴，再定义拓扑域

硬规则可能形成放置上限

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

坏掉的样子

快速验证

来源

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

给专用者的标记

效果决定行为

配对即约定

坏掉的样子

快速验证

延伸阅读

来源