Kubernetes 预留资源：系统组件也需要活路

一、节点不是只给业务 Pod 用

Kubernetes 节点上除了业务 Pod，还有 kubelet、容器运行时、日志采集、监控 Agent、网络插件和系统进程。如果不做资源预留，业务 Pod 把 CPU 和内存占满，系统组件也会被拖垮。

节点稳定性不是把资源全部卖给业务，而是给系统组件留活路。

二、先理解节点资源分配

flowchart TD
A[节点总资源] –> B[系统预留]
A –> C[Kube 预留]
A –> D[Eviction 阈值]
A –> E[Pod 可分配资源]

system-reserved 给系统进程，kube-reserved 给 Kubernetes 组件，eviction 阈值用于保护节点。剩下的才是可分配给 Pod 的资源。

如果没有预留，节点看起来利用率很高，但一到压力场景就会出现 kubelet 不响应、日志丢失、网络异常。

三、配置要按节点角色调整

kubelet_config:
systemReserved:
cpu: "500m"
memory: "1Gi"
kubeReserved:
cpu: "500m"
memory: "1Gi"
evictionHard:
memory.available: "500Mi"

不同节点角色预留不同。GPU 节点、日志密集节点、网关节点都可能需要更高系统预留。

node_reservation_policy:
profile_by_node_pool: true
monitor_system_cpu: true
alert_kubelet_pressure: true
review_after_daemonset_change: true

新增 DaemonSet 后，要重新评估预留。每个常驻组件都在消耗节点资源。

四、预留要和调度容量一致

预留资源后，节点 allocatable 会变小。容量规划要使用 allocatable，而不是机器规格。否则平台以为有很多资源，实际调度后很快触发驱逐。

还要观察系统组件指标。kubelet CPU、容器运行时内存、日志 Agent 队列，都能反映预留是否足够。

预留策略还要和 QoS 等级配合。Guaranteed Pod、Burstable Pod、BestEffort Pod 在节点压力下被处理的优先级不同。关键系统组件应尽量有明确 requests 和 limits，不要和普通工作负载混在一起。

node_pressure_alerts:
kubelet_cpu_high: true
container_runtime_memory_high: true
eviction_threshold_near: true
daemonset_resource_growth: true

节点池扩容时，也要把预留算进去。一个 64G 内存节点，并不代表可以调度 64G 的业务 Pod。容量模型必须使用 allocatable，并为日志、监控和网络流量留空间。

对 GPU 节点尤其要谨慎。GPU 利用率很高时，CPU 侧的数据预处理、日志采集和 device plugin 也会消耗资源。如果系统预留不足，表现可能是 GPU 任务异常，而根因在节点系统压力。

预留不是浪费。它是让节点在压力下仍能被管理、被观测、被恢复的安全余量。

五、总结

Kubernetes 节点要为系统组件、Kubernetes 组件和驱逐阈值预留资源，不能把机器规格全部当成业务容量。

系统组件有活路，业务 Pod 才能长期稳定运行。

Kubernetes 预留资源：系统组件也需要活路