备案站点的 Kubernetes 资源调度与 QoS 保障运维

容器编排下，"够不够资源"由三个数字共同决定

单机部署时代，一台机器跑一个服务，资源够不够很直观。容器编排把多个服务的多个副本混部到同一批节点上之后，"这个容器能用多少资源、节点资源紧张时先牺牲谁"，变成了一套需要显式配置才能生效的规则——而这套规则最基础的输入，就是每个容器声明的资源请求（requests）和资源限制（limits）。不填这两个值，或者填得随意，编排系统的调度和驱逐行为就完全不受控制，这也是容器化环境下最常见的"莫名其妙被重启"的根源之一。

关键要点

• 资源请求决定"调度时保证分配多少"，资源限制决定"运行时最多能用多少"，两者的关系直接决定了这个容器的服务质量等级。
• 内存超限和 CPU 超限的后果完全不同：前者是容器被直接杀掉，后者只是被限速，不会杀进程。
• 节点资源紧张时，驱逐顺序不是随机的，而是按照服务质量等级和资源超用程度排序。
• 中断预算能防止编排系统在节点维护或驱逐时一次性打掉太多副本，是容易被忽视但很重要的一道防线。

requests 和 limits：两个数字，三种服务质量等级

配置方式	服务质量等级	特点
不设置 requests 和 limits	最低优先级	资源紧张时最先被驱逐，也拿不到任何调度保证
requests 设置但 < limits	中间优先级	保证基础用量，允许突发用量，但突发部分不受保护
requests 等于 limits	最高优先级	资源用量完全确定，受到最强的调度和驱逐保护

这套分级直接决定了节点资源紧张时的驱逐顺序：最低等级最先被牺牲，最高等级几乎不会被主动驱逐（除非它自己突破了限制）。核心业务、对延迟敏感的服务应该配成最高等级（requests 等于 limits），非核心的批处理或可容忍中断的任务可以用较低等级换取更灵活的资源调度空间，容量规划的整体思路见 容量规划与弹性伸缩。

一个常见的误区是给所有服务都配成同一个等级——要么图省事全都不设置（结果是关键服务和边缘任务在资源紧张时被同等对待，核心服务可能被无辜牵连驱逐），要么所有服务都配成最高等级（结果是集群资源无法弹性复用，浪费大量预留但很少用到的资源）。合理的做法是按服务的重要性和容忍中断的程度分层配置，而不是一刀切。

内存超限被杀，CPU 超限被限流：两种完全不同的后果

这是一个经常被误解的细节：内存和 CPU 的限制机制在底层实现上完全不同，超限之后的表现也完全不同。

资源类型	超限后的行为	对应用的影响
内存	容器被直接杀掉（退出码通常是特定的信号值）	进程终止，需要重启，可能丢失内存中的状态
CPU	容器被限速（分配到的 CPU 时间片减少）	处理变慢，但进程不会被杀，不会丢失状态

这个差异对故障排查有直接影响：内存问题的表现是容器反复重启，排查思路和普通的内存泄漏问题类似，但要额外确认是应用本身泄漏还是内存限制设置过小，见 内存泄漏与 OOM 排查；CPU 问题的表现是延迟升高但进程存活，容易被误判为应用本身变慢，实际根因却是 CPU 限制设置过紧，排查方向应该先看容器的 CPU 限流指标，而不是一头扎进应用代码找性能问题。

驱逐顺序：不是随机牺牲

节点资源（尤其是内存）紧张到需要主动驱逐容器腾出空间时，编排系统的驱逐顺序遵循明确的规则，而不是随便挑一个杀掉：

1. 优先驱逐没有设置资源请求、且当前用量最高的容器——这类容器既没有调度保证，又占用最多资源，是最合理的驱逐对象。
2. 其次驱逐设置了请求但实际用量超出请求值的容器，按超出比例排序，超得越多越先被驱逐。
3. 最后才会考虑用量没有超出请求值、且服务质量等级最高的容器，这类容器只有在极端资源压力下才会被波及。

理解这套顺序的价值在于：一个配置合理（requests 等于 limits、用量没有超标）的核心服务，几乎不会因为其他服务的资源滥用而被无辜驱逐。如果发现核心服务频繁被驱逐，第一件事应该是检查它自己的资源配置是否合理，而不是简单归咎于"集群资源不够"。

中断预算：防止一次性打掉太多副本

节点维护、集群升级、主动腾挪资源等场景下，编排系统可能需要同时对多个节点上的多个副本做驱逐或重启。如果没有约束，这类批量操作可能在短时间内同时中断一个服务的大部分甚至全部副本，即使每个副本本身都能快速重启，短暂的服务能力骤降依然会造成明显的用户可感知问题。

中断预算的作用是给编排系统设定一条红线：某个服务在任意时刻最多允许多少个副本同时处于不可用状态，超过这个数量，后续的驱逐操作会被阻塞，直到已中断的副本恢复。这本质上是把"批量维护操作"和"服务持续可用"这两个目标做了协调，避免维护操作意外演变成一次自己人为造成的故障。这类保护机制和优雅停机的目标是一致的，都是为了让编排层面的正常操作不会变成用户可感知的中断，见 优雅停机与健康检查。

没有配置中断预算的服务，在节点批量维护时可能会经历远超预期的可用性下降，这类问题往往要等到真的赶上一次集群升级才会暴露，建议在故障演练里专门覆盖这个场景，见 故障演练与预案验证。

资源画像不准：两种方向相反的故障

给容器设置多少资源请求和限制，本质上是在给这个服务的资源需求画像。画像不准会在两个相反的方向上出问题：

画像偏差方向	表现	后果
请求值设得过高	实际用量远低于申请量	集群资源被大量预留但闲置，整体资源利用率低下
请求值设得过低	实际用量经常超出申请量	频繁触发驱逐或限流，服务表现不稳定

准确的资源画像需要基于真实的历史用量数据，而不是凭感觉估算一个"看起来安全"的数字。做法上，应该先在监控里观察服务实际的资源使用曲线（尤其是峰值和 P99），再据此设定请求和限制，而不是反过来先拍一个数字再看会不会出问题，监控与指标采集的方法见 可观测性建设。资源画像也不是一次配置就一劳永逸，业务量增长或代码逻辑变化都会改变实际资源需求，需要定期回顾并调整，这和整体的容量规划是同一套节奏，见 容量规划与弹性伸缩。

常见坑

• 不设置资源请求和限制：编排系统对这个容器的资源需求一无所知，调度和驱逐行为完全不可控。
• 把内存超限的问题当成 CPU 问题排查：两种超限的表现（进程被杀 vs 被限速）完全不同，排查方向搞反会浪费大量时间。
• 所有服务用同一套资源配置：核心服务和边缘任务的资源保护级别没有区分，资源紧张时可能牵连核心服务。
• 没有配置中断预算：节点维护或集群升级时，一个服务的大部分副本可能被同时打断。
• 资源配置基于估算而非实际用量数据：过度预留浪费资源，配置过紧则频繁触发驱逐或限流。

常见问题

requests 和 limits 应该设成相等还是留一定差距？

对延迟敏感、要求稳定性的核心服务，建议设成相等，获得最高的服务质量等级和最强的调度保证。对能容忍一定波动、希望利用突发资源的服务，可以让 limits 高于 requests，但要意识到突发部分不受同等保护。

容器频繁重启，怎么判断是内存超限还是应用本身的问题？

先看容器的重启原因和资源用量曲线：如果重启前内存用量持续攀升并在触顶时被杀，且限制值设置偏保守，可能只是限制设小了；如果即使调大限制内存依然持续增长不回落，则更可能是应用本身存在内存泄漏，排查方法见 内存泄漏与 OOM 排查。

中断预算设置得越严格越安全吗？

不完全是。设置得过于严格（比如要求几乎不允许任何副本同时不可用）可能导致节点维护或必要的重新调度操作长时间无法推进，反而影响运维效率。需要在"维护效率"和"服务可用性"之间找一个符合业务承受能力的平衡点。

资源画像应该多久回顾一次？

没有固定周期，但建议在业务量有明显变化、代码有重大改动、或者监控发现资源用量曲线和配置明显不匹配时主动回顾。定期（比如每季度）做一次盘点也是稳妥的做法，避免配置和实际需求长期脱节。

资料来源

Kubernetes 官方文档中关于资源请求限制、服务质量等级与驱逐策略的公开说明，以及容器编排系统中断预算机制的官方文档。本文为通用运维说明，仅供参考，具体行为以实际编排平台版本为准。