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 才能长期稳定运行。