Karpenter CapacityBuffers 完全指南用虚拟占位 Pod 预置节点余量实现 Pod 秒级调度【免费下载链接】karpenter-provider-awsKarpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.项目地址: https://gitcode.com/GitHub_Trending/ka/karpenter-provider-aws导读CapacityBuffers 是 KarpenterKubernetes 节点自动扩缩容组件提供的一项 Alpha 特性用于在集群中预置空闲节点余量spare capacity让工作负载在扩容时无需等待新节点启动即可立即调度。本文基于 Karpenter 仓库官方文档 capacitybuffers.md结合 CRD 定义、Helm 配置与集成测试源码完整讲解 CapacityBuffer 的配置字段、副本计算规则、与 Disruption 的协同方式、状态观测方法及已知限制帮助你在生产集群中正确规划并落地容量缓冲方案。CapacityBuffers 是什么CapacityBuffer 允许你预先配置一批空闲的节点容量使工作负载能够立即调度而无需等待新节点完成启动。它实现了 Kubernetes SIG Autoscaling 的 CapacityBuffer APIautoscaling.x-k8s.io/v1alpha1因此与 Cluster Autoscaler 的 buffer 语义保持兼容。其核心机制是一个只在 Karpenter 调度模拟中存在的虚拟占位 Podvirtual placeholder pod这些虚拟 Pod永远不会被创建为真实的 Kubernetes Pod它们驱动节点预置node provisioning让集群保有富余容量它们参与每一次调度周期scheduling cycle持续维持缓冲水平当真实工作负载消费掉预置容量后缓冲会被自动补充refill。功能状态Alpha。需要通过 Feature Gate 开启默认关闭详见下文如何启用。从 CRD 看 API 设计仓库中的 CRD 定义 autoscaling.x-k8s.io_capacitybuffers.yaml 给出了该资源的完整形态资源位于autoscaling.x-k8s.ioAPI 组当前 serving/storage 版本为v1beta1命名空间级scope: Namespaced资源支持短名cb提供若干额外的打印列additional printer columnsStrategy、PodTemplate、Replicas、ConditionsType、ConditionsStatus、ConditionsReason、Age方便直接用kubectl get capacitybuffers观察状态spec 中podTemplateRef与scalableRef互斥CEL 校验!(has(self.podTemplateRef) has(self.scalableRef))且若设置了podTemplateRef则replicas或limits必须至少设置其一提供status子资源用于上报条件与目标副本数。如何启用 CapacityBuffers由于该特性处于 Alpha 阶段默认关闭需要通过 Feature Gate 打开。官方文档指出使用--feature-gatesCLI 参数或FEATURE_GATES环境变量启用可参考 settings.md 中的 Feature Gates 说明。在 Helm 安装场景下直接修改 charts/karpenter/values.yaml 中的配置项settings: featureGates: # -- capacityBuffer is ALPHA and is disabled by default. # Setting this to true will enable CapacityBuffer support for pre-provisioning spare capacity. capacityBuffer: trueHelm 模板 deployment.yaml 会将该开关注入控制器容器的环境变量- name: FEATURE_GATES value: ReservedCapacity{{ .Values.settings.featureGates.reservedCapacity }},SpotToSpotConsolidation{{ .Values.settings.featureGates.spotToSpotConsolidation }},NodeRepair{{ .Values.settings.featureGates.nodeRepair }},NodeOverlay{{ .Values.settings.featureGates.nodeOverlay }},StaticCapacity{{ .Values.settings.featureGates.staticCapacity }},CapacityBuffer{{ .Values.settings.featureGates.capacityBuffer }}因此升级时只需执行helm upgrade karpenter karpenter/karpenter --namespace karpenter --set settings.featureGates.capacityBuffertrue或以等价方式设置FEATURE_GATES环境变量为CapacityBuffertrue。CRD 由 karpenter-crd 图表一并安装。CapacityBuffer 完整配置示例以下是一个同时定义CapacityBuffer与其配套PodTemplate的完整示例apiVersion: autoscaling.x-k8s.io/v1alpha1 kind: CapacityBuffer metadata: name: web-app-buffer namespace: default spec: provisioningStrategy: buffer.x-k8s.io/active-capacity podTemplateRef: name: web-buffer-template replicas: 5 limits: cpu: 20 memory: 40Gi配套的 PodTemplate与 CapacityBuffer 位于同一命名空间apiVersion: v1 kind: PodTemplate metadata: name: web-buffer-template namespace: default template: spec: containers: - name: placeholder image: public.ecr.aws/eks-distro/kubernetes/pause:3.2 resources: requests: cpu: 2 memory: 4Gi nodeSelector: karpenter.sh/capacity-type: on-demand tolerations: - key: workload-type value: web effect: NoSchedulePodTemplate 的 speccontainers、资源 requests、nodeSelector、tolerations、affinity 等会被用来构造调度模拟中的虚拟 Pod因此它会直接影响虚拟 Pod 被调度到什么样的节点上。注意PodTemplate 中携带的 PVC-backed 卷和 ephemeral 卷会被自动剥离因为不存在真实的 PVC 可做拓扑解析。底层实现验证仓库集成测试 capacitybuffer_test.go 展示了与上述示例一致的真实用法测试创建名为buffer-template的 PodTemplate使用public.ecr.aws/eks-distro/kubernetes/pause:3.2镜像requests 为 1 CPU / 512Mi再创建引用该模板的 CapacityBuffer验证从零节点基线出发时缓冲能够驱动出至少一个新节点且CapacityBuffer状态进入已供给Provisioned状态。这印证了虚拟 Pod 会真实驱动节点预置的核心机制。spec 字段详解spec.provisioningStrategy定义缓冲的工作方式。当前仅支持buffer.x-k8s.io/active-capacity该策略持续维持备用容量并响应工作负载变化。不设置时默认使用该值CRD 中标注了default: buffer.x-k8s.io/active-capacity。spec.podTemplateRef引用同一命名空间下的一个 PodTemplate 资源用于描述单个缓冲块buffer chunk的形态。其 spec 中的 containers、资源请求、nodeSelector、tolerations、affinity 会被用于构造调度模拟中的虚拟 Pod。注意 PVC 卷与 ephemeral 卷会被自动剥离见上。spec.scalableRef引用一个具备 scale 子资源的工作负载。与podTemplateRef互斥。设置后缓冲直接使用该工作负载的 Pod 模板 spec并可通过percentage按比例扩缩。支持的类型apps/v1/Deploymentapps/v1/StatefulSetapps/v1/ReplicaSetspec: scalableRef: apiGroup: apps kind: Deployment name: api-service percentage: 20注意缓冲直接读取工作负载的spec.template.spec无需任何正在运行的 Pod 即可完成初始化对工作负载 spec 的变更会在30 秒内被感知。spec.replicas固定数量的缓冲块buffer chunk。当与percentage同时使用时取二者中的最大值随后由limits封顶最终数量为min(max(replicas, percentage), limits)。spec.percentage以scalableRef当前副本数的百分比来维持缓冲容量仅当设置了scalableRef时适用。绝对数值按向上取整计算且当百分比与可伸缩副本数均大于零时结果最小为 1。例如Deployment 有 10 个副本、percentage为 20 时缓冲维持 2 个块。集成测试should provision buffer with scalableRef正是验证了这一场景一个 10 副本 Deployment 配percentage: 20的缓冲最终CapacityBuffer状态副本数解析为 2参见 capacitybuffer_test.go。spec.limits基于总资源请求量来限制缓冲块数量的资源约束。若未设置其他约束replicas与percentage均缺省则由limits单独决定创建多少个块与replicas和/或percentage组合时limits作为max(replicas, percentage)的上限。spec: podTemplateRef: name: worker-template limits: cpu: 20 memory: 40Gi若每个 Pod 请求 2 CPU 与 4Gi 内存则生成min(20/2, 40/4) 10个缓冲块。副本数量计算规则replicas与percentage通过取最大值合并limits再对其封顶min(max(replicas, percentage), limits)。若replicas与percentage均未设置则由limits单独决定可容纳的块数。配置组合结果仅replicas: 55percentage: 20 10 副本 Deployment2replicas: 5percentage: 8010 副本 Deployment8取 5 与 8 的最大值replicas: 10limits: {cpu: 3}每 Pod 1 CPU3取 10 与 3 的最小值replicas: 5percentage: 80limits: {cpu: 4}10 副本 Deployment每 Pod 1 CPU4min(max(5, 8), 4)仅limits: {cpu: 5}每 Pod 1 CPU5与 Disruption干扰/合并的集成CapacityBuffers 与 Karpenter 的 disruption 系统深度集成确保缓冲容量被保留空节点合并empty consolidation被阻止承载缓冲容量的节点即使没有真实 Pod也不会被当作空节点处理——虚拟缓冲 Pod 阻止了这类合并。节点会被标记为不可合并unconsolidatable原因标记为Node has buffer pods。其余干扰方式照常允许利用率不足合并underutilized consolidation、漂移drift、过期expiry等仍可执行——但替换节点必须仍能容纳虚拟缓冲 Pod因此缓冲会被自动维持。集成测试 capacitybuffer_test.go 中有两个用例专门覆盖该行为should not disrupt buffer nodes when empty在WhenEmptyOrUnderutilized合并策略下缓冲节点在 60 秒内持续不被干扰should clean up buffer nodes after buffer deletion删除 CapacityBuffer 后缓冲驱动的 NodeClaim 会被自动回收清理。状态与可观测性状态条件Status ConditionsCapacityBuffer 通过状态条件帮助判断当前状态并排查问题ReadyForProvisioningTruePod 模板解析成功且目标副本数已计算完成ReadyForProvisioningFalse解析失败——通过 reason 查看具体原因PodTemplateNotFound、ScalableRefNotFound、ResolutionFailedProvisioningTrue所有虚拟 Pod 都能在现有集群容量上放下无需新建节点ProvisioningFalse虚拟 Pod 需要新的容量——正在供给中或受 NodePool 限制约束。状态示例status: conditions: - type: ReadyForProvisioning status: True reason: Resolved message: Pod template resolved successfully - type: Provisioning status: True reason: FitsExistingCapacity message: All 5 virtual pods fit on existing capacity replicas: 5 podTemplateRef: name: web-buffer-template podTemplateGeneration: 3 provisioningStrategy: buffer.x-k8s.io/active-capacity监控缓冲控制器每 30 秒协调一次reconcile每次协调都会更新状态条件让你可以观察到引用的 PodTemplate 或工作负载是否存在且有效容量当前是否已满足还是正在供给新节点当前的目标副本数。在 CRD 中status.podTemplateGeneration被定义为PodTemplate 的已观测 generation用于判断状态是否与期望的spec.podTemplateRef保持一致可作为判断缓冲是否跟随模板更新的依据。限制与注意事项卷剥离PVC-backed 与 ephemeral 卷会从虚拟 Pod 中剥离因为不存在真实 PVC 可用于拓扑解析scalableRef 变更轮询缓冲控制器每 30 秒重新入队requeue——对引用的 Deployment 副本数变更状态最多滞后 30 秒才反映NodePool 限制缓冲虚拟 Pod 受 NodePool 资源 limits 约束。若 NodePool 的 CPU 或内存 limit 被耗尽缓冲容量将无法满足Alpha 状态CapacityBuffers 当前处于 alphaautoscaling.x-k8s.io/v1alpha1API 在未来版本中可能发生变化。结语CapacityBuffers 通过只在调度模拟中存在的虚拟占位 Pod为 Karpenter 集群引入了可预期、可量化的空闲容量预置能力固定的replicas、随工作负载浮动的percentage、以及资源上限limits三者组合提供了从固定缓冲到按比例缓冲再到纯限额缓冲的完整配置矩阵而与 disruption 系统的集成则保证了缓冲节点不被空节点合并误删、缓冲水平始终得到维持。结合 capacitybuffer_test.go 中的集成测试用例你可以在自己的集群中完整复现从零驱动节点供给、消费缓冲、删除缓冲后自动清理的全生命周期行为为关键工作负载打造零等待调度的容量底座。【免费下载链接】karpenter-provider-awsKarpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.项目地址: https://gitcode.com/GitHub_Trending/ka/karpenter-provider-aws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考