二、什么是 Buffer Operator
Buffer Operator 具有以下特点：
·资源预留：通过配置 Buffer Pod 数量维持指定的资源水位。
·节点级缓冲：每个节点部署零资源 NodeAnchor Pod，利用 Pod Anti-Affinity 机制固定节点，防止 Cluster Autoscaler 在低水位时缩容空节点。
·被动扩容触发：业务 Pod 调度时抢占低优先级占位 Pod，立即获得所需资源。
·动态调整：周期性监控集群可用资源，自动扩缩 Placeholder Pod。
·多云支持：兼容腾讯云 TKE、阿里云 ACK、AWS EKS、Azure AKS 及自建 Kubernetes 集群。
三、为什么选择 Buffer Operator
使用 Buffer Operator，你可以获取以下收益：
·主动扩容：避免被动等待资源不足时才触发扩容，减少业务 Pod 调度延迟。
·资源保障：通过可配置的水位参数灵活控制预留资源量，确保集群始终有足够资源应对突发业务。
·自动化管理：自动计算集群资源使用情况并动态调整占位 Pod，无需人工干预。
·可观测性：内置 Prometheus Metrics 和 OpenTelemetry Traces，支持完善的监控告警。
更多选择理由，请参见产品优势和应用场景。
四、产品架构
Buffer Operator 主要由以下核心组件构成：
·Resource Monitor：监控 Node 和 Pod 资源变化，缓存资源信息，减少 API Server 压力。
·Resource Calculator：计算集群总资源和可用资源，根据水位配置计算需要预留的资源量。
·Placeholder Manager：创建和删除占位 Pod，管理 Pod 的亲和性和反亲和性规则，控制扩缩容频率。
·BufferConfig Controller：监听 BufferConfig CRD 变化，协调各个组件工作，更新 BufferConfig 状态。
架构图如下：
┌─────────────────────────────────────────────────────┐│ Buffer Operator │├─────────────────┬──────────────┬────────────────────┤│ ResourceMonitor │ Calculator │ PlaceholderManager ││ (internal/ │ (internal/ │ (internal/ ││ monitor) │ calculator) │ manager) │├─────────────────┼──────────────┼────────────────────┤│ 监控 Node/Pod │ 计算需要的 │ Build/Scale ││ 资源、节点池 │ buffer-pod │ buffer-pod / ││ │ / NodeAnchor │ NodeAnchor ││ │ 数量 │ Pod (OwnerRef + ││ │ │ Anti-Affinity) │└─────────────────┴──────────────┴────────────────────┘ ↓ ↓ ↓┌─────────────────────────────────────────────────────┐│ Kubernetes Cluster ││ ┌──────────┐ ┌──────────┐ ┌──────────┐ ││ │NodeAnchor│ │BufferPod │ │ Business │ ││ │(zero res)│ │(low prio)│ │ Pod (high)│ ──preempt││ └──────────┘ └──────────┘ └──────────┘ │└─────────────────────────────────────────────────────┘
五、基础概念
| 概念 | 说明 |
| BufferConfig | 自定义资源（CRD），用于定义集群资源缓冲池的行为配置。 |
| Buffer Pod | 实际占用资源的占位 Pod，用于预留 CPU 和内存资源。 |
| NodeAnchor Pod | 每个节点 1 个的零资源占位 Pod，用于支撑节点级别的水位管理。 |
| Placeholder Pod | 占位 Pod 的统称，包含 Buffer Pod 和 NodeAnchor Pod。 |
| PriorityClass | 优先级类，用于区分占位 Pod（低优先级）和业务 Pod（高优先级）。 |
六、相关产品
| 相关产品 | 关系说明 |
| TKE 集群 | Buffer Operator 运行在 TKE 集群中，管理集群资源水位。 |
| Cluster Autoscaler | 配合 Cluster Autoscaler 实现自动扩缩容。 |
| PriorityClass | 依赖 PriorityClass 实现 Pod 优先级抢占机制。 |
八、主动扩容
Buffer Operator 通过预先创建占位 Pod，主动触发 Cluster Autoscaler 扩容，避免在业务高峰时因资源不足导致 Pod 调度失败。相比被动扩容，可将业务 Pod 启动时间从分钟级降低到秒级。
九、灵活配置
支持多种配置方式：
·固定数量模式：维持指定数量的 Buffer Pod。
·自动模式：根据集群资源使用情况自动计算 Buffer Pod 数量。
·节点池级别配置：按节点池分别配置缓冲策略。
十、自动化管理
组件自动完成以下工作：
·周期性监控集群资源使用情况。
·根据配置的水位自动扩缩占位 Pod。
·处理占位 Pod 的异常情况（如 Pod 被意外删除）。
十二、突发业务场景
·目标用户：电商、直播、游戏等业务流量波动较大的用户。
·痛点与需求：业务流量具有明显的波峰波谷特征，波峰时需要快速扩容，传统按需扩容方式延迟较高。
·解决方案：通过 Buffer Operator 预留资源水位，业务 Pod 在波峰时可秒级抢占资源，确保业务连续性。
十三、高可用场景
·目标用户：对服务可用性要求较高的用户。
·痛点与需求：需要确保集群在任何情况下都有足够资源进行故障恢复和容灾切换。
·解决方案：配置 NodeAnchor 确保节点不被意外缩容，同时预留 Buffer Pod 作为资源缓冲，提升集群容错能力。
十四、成本优化场景
·目标用户：需要在保证服务质量的同时优化资源成本的用户。
·痛点与需求：希望在业务低峰期能够缩容节点节省成本，但又担心高峰期资源不足。
·解决方案：通过配置合理的资源水位，在保证业务所需资源的同时，避免过度预留造成资源浪费。
十五、前提条件
在使用 Buffer Operator 之前，请确保满足以下条件：
·已部署 Kubernetes 集群，版本 1.24 或更高。
·已安装 Cluster Autoscaler。
·已创建 PriorityClass（用于区分占位 Pod 和业务 Pod）。
·集群已开启 RBAC 权限控制。
十六、快速开始
创建 BufferConfig CR，定义资源缓冲策略：
apiVersion: buffer.tke.cloud.tencent.com/v1alpha1kind: BufferConfigmetadata: name: default-buffer namespace: defaultspec: bufferPods: number: 2 strategy: fixed nodeBuffer: strategy: node-only count: type: absolute value: 0 placeholderPod: priorityClassName: buffer-priority-low resources: requests: cpu: "100m" memory: "128Mi" bufferPod: priorityClassName: buffer-priority-low resources: requests: cpu: "100m" memory: "128Mi" control: reconcileInterval: 30 scaleUpCooldown: 300 scaleDownCooldown: 600 enableNodeAnchor: true
默认低优先级 PriorityClass（占位 Pod 使用）：
apiVersion: scheduling.k8s.io/v1kind: PriorityClassmetadata: name: buffer-priority-lowvalue: -10globalDefault: falsedescription: "低优先级，用于占位 Pod，可被业务 Pod 抢占"
默认高优先级 PriorityClass（业务 Pod 使用）：
apiVersion: scheduling.k8s.io/v1kind: PriorityClassmetadata: name: business-priority-highvalue: 1000globalDefault: falsedescription: "高优先级，用于业务 Pod，可抢占占位 Pod"
十七、BufferConfig 配置说明
BufferConfig 是 Buffer Operator 的核心自定义资源，用于定义集群资源缓冲池的行为。
十八、CR 结构
BufferConfig 的 API 版本为 buffer.tke.cloud.tencent.com/v1alpha1，CRD 名称为 BufferConfig。
apiVersion: buffer.tke.cloud.tencent.com/v1alpha1kind: BufferConfigmetadata: name: buffer-config-name namespace: namespace-namespec: # Buffer Pod 配置 bufferPods: number: 2 strategy: fixed # 节点级缓冲配置（可选） nodeBuffer: strategy: node-only count: type: absolute value: 0 # 占位 Pod 模板配置 placeholderPod: image: registry.k8s.io/pause:3.9 resources: requests: cpu: "100m" memory: "128Mi" nodeAnchor: priorityClassName: buffer-priority-low bufferPod: resources: requests: cpu: "100m" memory: "128Mi" # 控制参数（可选） control: reconcileInterval: 30 scaleUpCooldown: 300 scaleDownCooldown: 600 enableNodeAnchor: true
十九、spec.bufferPods（必填）
定义需要维持的 Buffer Pod 数量。
| 参数 | 类型 | 必填 | 默认值 | 取值范围 | 说明 |
| number | Integer | 是 | – | ≥0 | 需要维持的 Buffer Pod 数量 |
| strategy | String | 否 | fixed | fixed、auto | 缓冲策略 |
strategy 取值说明：
·fixed：固定数量模式，维持指定数量的 Buffer Pod。
·auto：自动模式，根据集群资源使用情况自动计算 Buffer Pod 数量。
配置示例：
spec: bufferPods: number: 2 strategy: fixed
20、spec.nodeBuffer（可选）
定义节点级缓冲配置。
| 参数 | 类型 | 必填 | 默认值 | 取值范围 | 说明 |
| strategy | String | 否 | both | both、resource-only、node-only | 缓冲策略 |
| count | NodeCountBufferSpec | 是 | – | – | 节点缓冲数量配置 |
| nodePools | []NodePoolBufferSpec | 否 | – | – | 按节点池配置缓冲 |
strategy 取值说明：
·both：同时启用资源缓冲和节点缓冲。
·resource-only：仅启用资源缓冲。
·node-only：仅启用节点缓冲。
count 字段说明：
| 参数 | 类型 | 必填 | 取值范围 | 说明 |
| type | String | 是 | percentage、absolute | 配置类型 |
| value | Integer | 是 | 百分比：0-100；绝对值：节点数量 | 配置值 |
配置示例：
spec: nodeBuffer: strategy: node-only count: type: absolute value: 0
21、spec.placeholderPod（必填）
定义占位 Pod 的配置模板。
| 参数 | 类型 | 必填 | 默认值 | 说明 |
| image | String | 否 | registry.k8s.io/pause:3.9 | 容器镜像 |
| resources | ResourceRequirements | 是 | – | 每个占位 Pod 的资源请求 |
| priorityClassName | String | 否 | – | 优先级类名 |
| nodeSelector | map[string]string | 否 | – | 节点选择器 |
| tolerations | []Toleration | 否 | – | 容忍度 |
| nodeAnchor | NodeAnchorPodSpec | 否 | – | NodeAnchor Pod 配置 |
| bufferPod | BufferPodSpec | 否 | – | Buffer Pod 配置 |
nodeAnchor 字段说明：
NodeAnchor Pod 是每个节点 1 个的零资源占位 Pod，用于支撑节点级别的水位管理。Operator 会自动为 NodeAnchor Pod 添加 cluster-autoscaler.kubernetes.io/safe-to-evict=true annotation，确保 Cluster Autoscaler 能够正常缩容节点。
| 参数 | 类型 | 必填 | 说明 |
| priorityClassName | String | 否 | 优先级类名 |
| nodeSelector | map[string]string | 否 | 节点选择器 |
| tolerations | []Toleration | 否 | 容忍度 |
bufferPod 字段说明：
BufferPod 是实际占用资源的缓冲 Pod。
| 参数 | 类型 | 必填 | 说明 |
| resources | ResourceRequirements | 是 | 每个 Buffer Pod 的资源请求 |
| priorityClassName | String | 否 | 优先级类名 |
| nodeSelector | map[string]string | 否 | 节点选择器 |
| tolerations | []Toleration | 否 | 容忍度 |
注意：当 bufferPod 字段非空时，internal/manager.buildBufferPod 会完全覆盖顶层 placeholderPod 的 nodeSelector / tolerations。因此如果需要指定调度约束，必须在 bufferPod 中重复配置。
配置示例：
spec: placeholderPod: image: registry.k8s.io/pause:3.9 resources: requests: cpu: "100m" memory: "128Mi" priorityClassName: buffer-priority-low nodeSelector: node-pool: "default" tolerations: – key: "node.kubernetes.io/not-ready" operator: "Exists" effect: "NoExecute" tolerationSeconds: 300 nodeAnchor: priorityClassName: buffer-priority-low bufferPod: resources: requests: cpu: "1000m" memory: "2Gi" limits: cpu: "1000m" memory: "2Gi" priorityClassName: buffer-priority-low nodeSelector: node-pool: "default"
22、spec.control（可选）
定义控制参数。
| 参数 | 类型 | 必填 | 默认值 | 取值范围 | 说明 |
| reconcileInterval | Integer | 否 | 30 | ≥10 | 调谐间隔（秒） |
| scaleUpCooldown | Integer | 否 | 300 | ≥0 | 扩容冷却时间（秒） |
| scaleDownCooldown | Integer | 否 | 600 | ≥0 | 缩容冷却时间（秒） |
| enableNodeAnchor | *bool | 否 | true | true、false | 是否启用 NodeAnchor |
注意：enableNodeAnchor 使用指针类型（*bool），以便用户显式设置为 false。如果使用普通 bool + omitempty，false 值会在 JSON 编码时被丢弃，导致 apiserver 重新应用 kubebuilder 默认值（true）。
配置示例：
spec: control: reconcileInterval: 30 scaleUpCooldown: 300 scaleDownCooldown: 600 enableNodeAnchor: true
23、spec.nodeBuffer.nodePools（可选）
按节点池分别配置缓冲策略。适用于多个节点池、每个节点池资源规格不同的场景。
| 参数 | 类型 | 必填 | 说明 |
| name | String | 是 | 节点池名称（匹配节点标签） |
| nodeSelector | map[string]string | 是 | 用于识别节点池的标签选择器 |
| count | NodeCountBufferSpec | 是 | 该节点池的缓冲配置 |
配置示例：
spec: bufferPods: number: 0 nodeBuffer: strategy: both nodePools: – name: "cpu-pool" nodeSelector: node-pool: "cpu-pool" count: type: absolute value: 2 – name: "memory-pool" nodeSelector: node-pool: "memory-pool" count: type: percentage value: 20
25、场景一：固定数量缓冲 Pod
适用于明确知道需要预留多少资源的场景。
spec: bufferPods: number: 4 strategy: fixed placeholderPod: bufferPod: resources: requests: cpu: "1000m" memory: "2Gi"
26、场景二：按节点池分别配置缓冲
适用于多个节点池、每个节点池资源规格不同的场景。
spec: bufferPods: number: 0 nodeBuffer: strategy: both nodePools: – name: "cpu-pool" nodeSelector: node-pool: "cpu-pool" count: type: absolute value: 2 – name: "memory-pool" nodeSelector: node-pool: "memory-pool" count: type: percentage value: 20
27、场景三：仅启用 NodeAnchor（零资源占位）
适用于只需要保证节点不被 Cluster Autoscaler 缩容、但不需要预留实际资源的场景。
spec: bufferPods: number: 0 nodeBuffer: strategy: node-only control: enableNodeAnchor: true
28、监控与告警
Buffer Operator 暴露 Prometheus metrics 在 :8080/metrics 端点，支持以下监控指标：
29、调谐相关指标
| 指标名称 | 类型 | 说明 |
| buffer_operator_reconcile_duration_seconds | Histogram | 调谐耗时分布 |
| buffer_operator_reconcile_total | Counter | 调谐总次数 |
| buffer_operator_reconcile_errors_total | Counter | 调谐错误次数 |
30、资源相关指标
| 指标名称 | 类型 | 说明 |
| buffer_operator_placeholder_pods_current | Gauge | 当前占位 Pod 数量 |
| buffer_operator_placeholder_pods_desired | Gauge | 期望占位 Pod 数量 |
| buffer_operator_cluster_cpu_total_cores | Gauge | 集群总 CPU 核数 |
| buffer_operator_cluster_memory_total_bytes | Gauge | 集群总内存字节数 |
| buffer_operator_cluster_cpu_available_cores | Gauge | 可用 CPU 核数 |
| buffer_operator_cluster_memory_available_bytes | Gauge | 可用内存字节数 |
31、推荐告警规则
groups: – name: buffer-operator rules: # 调谐失败率过高 – alert: BufferOperatorHighReconcileErrorRate expr: rate(buffer_operator_reconcile_errors_total[5m]) > 0.1 for: 5m labels: severity: warning annotations: summary: "Buffer Operator 调谐失败率过高" # 占位 Pod 数量偏差 – alert: BufferOperatorPlaceholderMismatch expr: abs(buffer_operator_placeholder_pods_current – buffer_operator_placeholder_pods_desired) > 5 for: 10m labels: severity: warning annotations: summary: "占位 Pod 实际数量与期望数量偏差过大"
32、Pod 标签约定
由 Operator 管理的所有 Placeholder Pod 都会带上以下标签：
| 标签 | 取值 | 用途 |
| buffer.tke.cloud.tencent.com/placeholder | "true" | 标识 Placeholder Pod |
| buffer.tke.cloud.tencent.com/placeholder-type | buffer-pod / node-anchor | 区分类别 |
| buffer.tke.cloud.tencent.com/config | BufferConfig 名称 | 反查所属 CR |
34、配置限制
| 限制项 | 限制说明 |
| reconcileInterval | 最小值为 10 秒 |
| scaleUpCooldown | 无下限，建议设置为 300 秒（5 分钟） |
| scaleDownCooldown | 无下限，建议设置为 600 秒（10 分钟） |
| nodeBuffer.count.type 为 percentage 时 | value 取值范围为 0-100 |
35、环境要求
| 限制项 | 限制说明 |
| Kubernetes 版本 | 1.24 或更高 |
| Cluster Autoscaler | 必须已部署并正常运行 |
| RBAC | 需要授予 nodes、pods 的读取权限，以及 pods 的创建/删除权限 |
37、Buffer Pod 和 NodeAnchor Pod 有什么区别？
Buffer Pod 是实际占用资源的占位 Pod，用于预留 CPU 和内存资源，供业务 Pod 抢占使用。
NodeAnchor Pod 是每个节点 1 个的零资源占位 Pod，用于支撑节点级别的水位管理，防止 Cluster Autoscaler 在低水位时缩容空节点。
38、如何配置业务 Pod 抢占占位 Pod？
业务 Pod 需要配置高优先级 PriorityClass（例如 business-priority-high，value 为 1000），而占位 Pod 使用低优先级 PriorityClass（例如 buffer-priority-low，value 为 -10）。当集群资源不足时，业务 Pod 会自动抢占占位 Pod 的资源。
39、enableNodeAnchor 设置为 false 后，节点还会被缩容吗？
是的。enableNodeAnchor 设置为 false 后，Operator 不会创建 NodeAnchor Pod，节点将失去占位保护，Cluster Autoscaler 可能会在资源不足时缩容节点。
40、如何查看 BufferConfig 的运行状态？
执行以下命令查看 BufferConfig 状态：
kubectl get bufferconfig <name> -n <namespace> -o yaml
状态信息包含在 status 字段中，包括：
·conditions：BufferConfig 状态条件
·statistics：资源统计信息
·lastScaleTime：最后一次扩缩容时间
·lastScaleDirection：最后一次扩缩容方向