📚 课程目录第3章容量基线定义

3. 容量基线定义

在灰度发布流水线中，容量基线是描述服务在稳定运行状态下所需最小资源供给能力的数字化快照。它并非静态的固定值，而是随业务周期、版本特性、集群水位动态调整的基准线。容量基线留痕的本质，是在灰度批次推进的每个关键节点，将当前服务的副本数、资源规格、弹性策略等要素记录为可追溯的版本化数据，用于回滚对比、容量规划与异常溯源。

3.1 什么是容量基线

容量基线是服务在特定版本、特定流量模型下，为满足 SLO（服务等级目标）所需的最小资源供给集合。它包含三个核心维度：

静态容量：由 Deployment/StatefulSet 定义的固定副本数与 Pod 资源请求/限制。
动态容量：由 HPA（Horizontal Pod Autoscaler）定义的弹性伸缩策略与阈值。
边界容量：集群节点资源余量、QoS 等级、Pod 调度约束等隐性限制。

实践要点：容量基线不是“当前运行值”，而是“经过验证的安全值”。灰度批次每推进一个阶段（如 10% → 50% → 100%），都应重新采集并留痕一次基线，确保回滚时能精确恢复到上一验证点的容量状态。

  容量基线 vs 资源配额：资源配额（ResourceQuota）是集群维度的硬限制，容量基线是服务维度的软基准。前者防止资源滥用，后者保障发布安全。

3.2 容量基线的组成要素

容量基线由三个相互关联的要素构成，任何一项缺失都会导致基线不完整，无法在灰度发布中提供可靠的容量参考。

3.2.1 副本数（Replicas）

副本数是容量基线的第一要素，直接决定服务能同时处理多少请求。在灰度发布中，副本数需要区分以下场景：

场景	副本数策略	留痕要求
稳定运行态	满足日常峰值流量的最小副本数	记录当前实际运行副本数
灰度发布态	新版本副本数 = 基线副本数 × 灰度比例	记录灰度批次各阶段的副本数
回滚态	恢复到上一验证点的副本数	从基线记录中读取历史副本数
弹性伸缩态	HPA 动态调整后的实际副本数	记录伸缩前后的副本数变化

常见误区：部分团队只记录 Deployment 的 YAML 中定义的 replicas 字段，忽略了 HPA 动态调整后的实际副本数。容量基线留痕应同时记录“期望副本数”和“实际副本数”，两者在弹性场景下可能不一致。

3.2.2 资源请求/限制（Requests & Limits）

资源请求与限制定义了每个 Pod 实例能获得的 CPU 和内存资源量。在容量基线中，这两个值直接影响集群调度决策和 Pod 运行稳定性。

参数	含义	对容量的影响	留痕建议
requests.cpu	Pod 启动时保证获得的 CPU 资源	决定调度时节点能否容纳该 Pod	记录每个容器的 requests 值
limits.cpu	Pod 可使用的 CPU 上限	限制突发 CPU 使用，影响性能	记录 limits 与 requests 的比例
requests.memory	Pod 启动时保证获得的内存资源	决定调度时节点能否容纳该 Pod	记录每个容器的 requests 值
limits.memory	Pod 可使用的内存上限	超过后触发 OOMKill，影响稳定性	记录 limits 与 requests 的比例

  资源比例黄金法则：生产环境建议 limits/requests 比例不超过 2:1（CPU）和 1.5:1（内存）。比例过大会导致节点超卖严重，触发资源竞争；比例过小则浪费集群资源。容量基线留痕时应同时记录这个比例值。

3.2.3 HPA 策略（Horizontal Pod Autoscaler）

HPA 是容量基线的动态调节器，它根据实时指标自动调整副本数。在灰度发布中，HPA 策略的留痕尤为重要，因为新版本的资源消耗模式可能与旧版本不同，导致弹性行为异常。

HPA 策略的核心参数包括：

minReplicas / maxReplicas：弹性伸缩的上下边界，定义容量的安全区间。
metrics：触发伸缩的指标，常见的有 CPU 使用率、内存使用率、QPS、请求延迟等。
targetValue / targetAverageValue：指标的阈值，超过则扩容，低于则缩容。
behavior：扩缩容行为配置，包括稳定窗口、冷却时间、策略等。

3.3 容量基线 YAML 示例

以下是一个完整的容量基线记录示例，包含副本数、资源请求/限制、HPA 策略三个要素：

apiVersion: v1
kind: ConfigMap
metadata:
  name: capacity-baseline-v1.2.3
  namespace: production
  labels:
    app: order-service
    baseline-version: "1.2.3"
    grayscale-phase: "100%"
data:
  # 副本数基线
  replicas: |
    desired: 12
    actual: 12
    minAllowed: 6
    maxAllowed: 24
  
  # 资源请求/限制基线
  resources: |
    containers:
      - name: order-service
        requests:
          cpu: "500m"
          memory: "512Mi"
        limits:
          cpu: "1000m"
          memory: "768Mi"
  
  # HPA 策略基线
  hpa: |
    minReplicas: 6
    maxReplicas: 24
    metrics:
      - type: Resource
        resource:
          name: cpu
          target:
            type: Utilization
            averageUtilization: 70
      - type: Resource
        resource:
          name: memory
          target:
            type: Utilization
            averageUtilization: 80
    behavior:
      scaleDown:
        stabilizationWindowSeconds: 300
        policies:
          - type: Percent
            value: 10
            periodSeconds: 60
      scaleUp:
        stabilizationWindowSeconds: 0
        policies:
          - type: Percent
            value: 100
            periodSeconds: 60
          - type: Pods
            value: 4
            periodSeconds: 60
        selectPolicy: Max

留痕最佳实践：将容量基线存储为 ConfigMap 或自定义资源（CRD），并关联到对应的 Deployment 版本。每次灰度批次推进前，自动生成当前基线的快照 ConfigMap，命名格式建议为 capacity-baseline-{version}-{phase}，便于后续检索和回滚。

3.4 容量基线变更触发条件

在灰度发布流水线中，以下场景必须触发容量基线的重新采集与留痕：

触发事件	变更类型	留痕动作
灰度批次推进（如 10% → 50%）	副本数变化	记录新批次的副本数与资源使用率
HPA 策略调整	动态容量变化	记录策略变更前后的完整配置
资源请求/限制修改	静态容量变化	记录新旧资源规格对比
集群节点扩缩容	边界容量变化	记录节点数量与资源总量
版本回滚	容量恢复	从历史基线中恢复容量配置

关键提醒：容量基线留痕不是一次性工作，而是伴随灰度发布全生命周期的持续动作。每次变更都应在流水线中插入“基线采集”步骤，确保留痕数据与发布进度严格对齐。