2. 集群容量评估基础

2.1 容量评估的核心目标

集群容量评估不是简单的“够不够用”判断，而是一个系统化的工程决策过程。其核心目标可以归纳为以下四个层次：

2.2 关键性能指标（KPI）体系

在基于 CAPI（Cluster API）的集群中，容量评估需要覆盖控制面、工作节点和集群整体三个维度。以下是指标体系的核心构成：

2.2.1 资源利用率指标

2.2.2 容量饱和度指标

• 可调度 Pod 数量占比：当前已调度 Pod 数 / 集群最大 Pod 数（受节点 IP 和 CNI 限制）
• 节点资源碎片率：无法被任何待调度 Pod 使用的剩余资源比例
• 控制面 etcd 存储使用率：超过 8GB 需关注，超过 10GB 告警
• API Server 请求 QPS 与延迟：P99 延迟超过 1s 表示控制面过载

2.3 容量评估的常见误区

以下是在实际容量评估工作中反复出现的典型错误，需要特别警惕：

2.4 容量评估流程框架

下图展示了从数据采集到决策输出的完整容量评估流程：

2.5 容量评估的量化模型

在实际工程中，我们使用以下量化模型来评估集群容量健康度：

# 集群容量健康度评分模型（简化版）
# 评分范围：0（危险）~ 100（健康）

def cluster_capacity_health_score(metrics):
    score = 100
    
    # 1. CPU 利用率扣分（权重 30%）
    cpu_util = metrics['cpu_util_p99']
    if cpu_util > 85:
        score -= 30 * (cpu_util - 85) / 15  # 85%→100% 线性扣分
    
    # 2. 内存利用率扣分（权重 25%）
    mem_util = metrics['mem_util_p99']
    if mem_util > 85:
        score -= 25 * (mem_util - 85) / 15
    
    # 3. 控制面 etcd 存储扣分（权重 20%）
    etcd_size = metrics['etcd_db_size_gb']
    if etcd_size > 8:
        score -= 20 * (etcd_size - 8) / 2  # 8GB→10GB 线性扣分
    
    # 4. 资源碎片率扣分（权重 15%）
    fragmentation = metrics['resource_fragmentation_rate']
    if fragmentation > 0.3:
        score -= 15 * (fragmentation - 0.3) / 0.4
    
    # 5. 网络延迟扣分（权重 10%）
    latency = metrics['network_latency_p99_ms']
    if latency > 5:
        score -= 10 * (latency - 5) / 10
    
    return max(0, min(100, score))

2.6 容量评估的持续化机制

容量评估不是一次性活动，需要建立持续化机制：

• 实时监控层：Grafana 仪表盘展示核心 KPI，设置 P1/P2/P3 告警规则
• 日评估层：自动生成容量日报，关注变化趋势和异常节点
• 周评估层：人工评审容量报告，调整扩容计划和调度策略
• 月评估层：全面容量复盘，优化评估模型和阈值

通过建立分层评估机制，既能快速响应突发容量事件，又能从长期趋势中识别系统性风险，真正实现基于 CAPI 的集群容量精细化管理。