AI 辅助的 K8s 资源配额推荐：从经验估算到数据驱动

一、资源配额的经验主义困境：超配浪费与欠配风险

Kubernetes 中，Pod 的资源请求（Requests）和限制（Limits）设置直接影响集群的资源利用率和应用稳定性。但资源配额的设置至今仍高度依赖经验：CPU Requests 设高了导致集群资源浪费（平均利用率仅 20-30%），设低了导致 Pod 调度失败或被 OOMKilled。一个 100 节点的集群，如果每个 Pod 的 CPU Requests 平均超配 50%，意味着浪费了 50 个节点的算力。

传统做法是根据压测数据或历史监控手动调整配额，但这种方法有两个根本缺陷：一是无法覆盖所有工作负载模式（如周期性流量波动、突发流量），二是调整频率低（通常按月或按季度），无法及时响应业务变化。AI 辅助的资源配额推荐方案，核心思路是：基于历史监控数据，通过时序预测和异常检测，自动推荐最优的资源配额，并持续跟踪推荐效果。

二、资源配额推荐的架构设计与预测模型

资源配额推荐的核心挑战是：如何在"资源浪费"和"OOM 风险"之间找到最优平衡点。CPU 资源是可压缩的（超限后节流），内存资源是不可压缩的（超限后 OOMKill）。因此，CPU Requests 推荐侧重于"保证 P95 延迟下的最低配额"，而 Memory Limits 推荐侧重于"覆盖 P99.9 内存峰值加上安全裕度"。

flowchart TB
    A[Prometheus 监控数据] --> B[数据预处理]
    B --> C[缺失值填充]
    B --> D[异常点剔除]
    B --> E[周期性检测]

    C --> F[时序预测模型]
    D --> F
    E --> F

    F --> G[CPU 用量预测]
    F --> H[内存用量预测]

    G --> I[CPU Requests 推荐: P50 + 缓冲]
    G --> J[CPU Limits 推荐: P99 + 突发裕度]
    H --> K[Memory Requests 推荐: P95]
    H --> L[Memory Limits 推荐: P99.9 + 安全裕度]

    I --> M[推荐结果聚合]
    J --> M
    K --> M
    L --> M

    M --> N[推荐报告生成]
    N --> O[人工审核]
    O --> P[应用到 K8s 配置]

    P --> Q[效果跟踪与反馈]
    Q --> A

上图展示了从监控数据到推荐结果的完整流程。关键设计点在于"效果跟踪与反馈"——推荐不是一次性的，而是持续跟踪推荐效果，根据实际运行数据调整预测模型参数。

三、生产级实现：资源配额推荐引擎

# resource_recommender.py — K8s 资源配额推荐引擎
import numpy as np
from dataclasses import dataclass
from typing import List, Tuple, Optional
from datetime import datetime, timedelta

@dataclass
class ResourceRecommendation:
    workload_name: str
    namespace: str
    cpu_request_millicores: int
    cpu_limit_millicores: int
    memory_request_mib: int
    memory_limit_mib: int
    confidence: float  # 推荐置信度 0-1
    reason: str

@dataclass
class MetricSample:
    timestamp: datetime
    cpu_usage_millicores: float
    memory_usage_mib: float

class ResourceRecommender:
    """基于历史监控数据的资源配额推荐引擎"""

    def __init__(self, safety_margin: float = 0.15):
        # safety_margin: 安全裕度比例，用于覆盖预测误差
        self.safety_margin = safety_margin

    def recommend(
        self,
        samples: List[MetricSample],
        workload_name: str,
        namespace: str
    ) -> ResourceRecommendation:
        if len(samples) < 100:
            return self._fallback_recommendation(
                workload_name, namespace, "数据量不足，使用保守推荐"
            )

        cpu_values = np.array([s.cpu_usage_millicores for s in samples])
        mem_values = np.array([s.memory_usage_mib for s in samples])

        # CPU 推荐：基于百分位数
        # 设计意图：CPU 是可压缩资源，超限后节流而非 OOM，
        # 因此 Requests 可以设为较低百分位，Limits 设为较高百分位
        cpu_request = float(np.percentile(cpu_values, 50))  # P50
        cpu_limit = float(np.percentile(cpu_values, 99))    # P99

        # 内存推荐：基于百分位数 + 安全裕度
        # 设计意图：内存是不可压缩资源，超限后 OOMKill，
        # 因此 Limits 必须覆盖极端峰值并留有安全裕度
        mem_request = float(np.percentile(mem_values, 95))   # P95
        mem_limit = float(np.percentile(mem_values, 99.9))   # P99.9

        # 应用安全裕度
        cpu_request *= (1 + self.safety_margin)
        cpu_limit *= (1 + self.safety_margin)
        mem_request *= (1 + self.safety_margin)
        mem_limit *= (1 + self.safety_margin)

        # 计算推荐置信度：基于数据量和波动性
        confidence = self._calculate_confidence(cpu_values, mem_values)

        return ResourceRecommendation(
            workload_name=workload_name,
            namespace=namespace,
            cpu_request_millicores=max(int(cpu_request), 50),   # 最低 50m
            cpu_limit_millicores=max(int(cpu_limit), 100),      # 最低 100m
            memory_request_mib=max(int(mem_request), 64),       # 最低 64Mi
            memory_limit_mib=max(int(mem_limit), 128),          # 最低 128Mi
            confidence=confidence,
            reason=f"基于 {len(samples)} 个样本的百分位推荐"
        )

    def _calculate_confidence(
        self, cpu_values: np.ndarray, mem_values: np.ndarray
    ) -> float:
        """计算推荐置信度：数据量越大、波动越小，置信度越高"""
        # 数据量因子：至少 1000 个样本才达到满分
        volume_score = min(len(cpu_values) / 1000, 1.0) * 0.4

        # 稳定性因子：变异系数越小，置信度越高
        cpu_cv = np.std(cpu_values) / max(np.mean(cpu_values), 1)
        mem_cv = np.std(mem_values) / max(np.mean(mem_values), 1)
        stability_score = max(0, 1 - (cpu_cv + mem_cv) / 2) * 0.3

        # 周期性因子：如果能检测到周期性模式，置信度更高
        periodicity_score = self._detect_periodicity(cpu_values) * 0.3

        return min(volume_score + stability_score + periodicity_score, 1.0)

    def _detect_periodicity(self, values: np.ndarray) -> float:
        """简单周期性检测：基于自相关函数"""
        if len(values) < 200:
            return 0.0

        # 计算滞后 24 小时（假设采样间隔 5 分钟，即 288 个点）的自相关
        lag = min(288, len(values) // 2)
        mean = np.mean(values)
        var = np.var(values)
        if var == 0:
            return 0.0

        autocorr = np.correlate(
            values[:len(values)-lag] - mean,
            values[lag:] - mean
        )[0] / (var * (len(values) - lag))

        return max(0, min(autocorr, 1.0))

    def _fallback_recommendation(
        self, workload_name: str, namespace: str, reason: str
    ) -> ResourceRecommendation:
        """保守推荐：数据不足时使用较高的默认值"""
        return ResourceRecommendation(
            workload_name=workload_name,
            namespace=namespace,
            cpu_request_millicores=100,
            cpu_limit_millicores=500,
            memory_request_mib=128,
            memory_limit_mib=512,
            confidence=0.3,
            reason=reason
        )

四、边界分析与架构权衡

AI 辅助资源配额推荐在生产落地中需要正视以下 Trade-off：

推荐精度与数据量的依赖。百分位推荐需要至少 7 天的监控数据才能覆盖完整的工作日/周末周期。新部署的工作负载没有历史数据，只能使用保守的默认值。建议对新工作负载先设置较高的配额，运行 7 天后再根据推荐调整。

突发流量的处理。百分位推荐基于历史数据，无法预测突发流量（如促销活动、热点事件）。如果 CPU Limits 设为 P99，突发流量超过 P99 时会被节流，导致延迟飙升。解决方案是在推荐基础上增加"突发裕度"（如 P99 × 1.5），或使用 VPA（Vertical Pod Autoscaler）的自动调整能力。

推荐频率与稳定性。频繁调整资源配额会导致 Pod 重建（修改 Requests/Limits 需要重启 Pod），影响服务稳定性。建议推荐频率不超过每周一次，且每次调整幅度不超过当前值的 30%，避免剧烈波动。

适用边界：资源配额推荐最适合长期运行的在线服务（Web API、微服务）。对于批处理任务（CronJob、Data Pipeline）和短生命周期 Pod，推荐效果有限，因为历史数据不足以建立稳定的统计模型。

五、总结

AI 辅助的 K8s 资源配额推荐，将配额设置从"经验估算"推进到"数据驱动"。核心方法：CPU 基于百分位推荐（Requests P50、Limits P99），内存基于百分位加安全裕度（Requests P95、Limits P99.9），置信度评估综合数据量、稳定性和周期性。落地建议：第一，收集至少 7 天的监控数据后再生成推荐；第二，为内存 Limits 设置足够的安全裕度，OOMKill 的代价远大于内存浪费；第三，推荐频率控制在每周一次，调整幅度不超过 30%。关键原则：推荐的目的是减少浪费而非消除浪费——100% 的资源利用率意味着没有弹性空间，任何突发都会导致故障。