实战背景
Kubernetes 原生的 HPA(Horizontal Pod Autoscaler)基于当前指标(如 CPU、内存、自定义指标)进行扩缩容,存在响应滞后的问题。对于流量具有明显周期性的业务(如电商促销、早晚高峰),可以训练时序预测模型,提前几分钟甚至几小时预测流量峰值,从而实现预测性扩容,降低延迟和故障风险。
整体架构
Prometheus -> 历史指标采集 -> 特征工程 -> 模型训练
|
v
当前指标 -> 推理服务 -> 预测未来流量 -> 自定义扩缩容决策器 -> K8s API
主要组件包括:
- 指标采集模块:从 Prometheus 拉取历史 QPS/CPU/内存数据。
- 特征工程模块:处理时间序列,生成训练样本。
- 模型训练模块:使用时序预测算法训练模型。
- 推理服务:对外提供预测接口。
- 扩容决策器:根据预测结果决定目标副本数。
- 执行器:调用 K8s API 修改 Deployment 副本数。
数据准备与特征工程
时序预测的核心是构造高质量的训练数据。常用特征包括:
| 特征类型 | 示例 |
|---|---|
| 时间特征 | 小时、星期、是否节假日 |
| 滞后特征 | 过去 1h、过去 24h 的 QPS |
| 滑动统计 | 过去 7 天同一时刻均值、标准差 |
| 外部特征 | 营销活动、版本发布 |
import pandas as pd
df = pd.read_csv('qps.csv', parse_dates=['timestamp'], index_col='timestamp')
df['hour'] = df.index.hour
df['dayofweek'] = df.index.dayofweek
df['qps_lag_1h'] = df['qps'].shift(1)
df['qps_lag_24h'] = df['qps'].shift(24)
df['qps_roll_mean_7d'] = df['qps'].shift(24).rolling(window=7*24).mean()
df = df.dropna()
模型选择与训练
根据数据规模和业务特点,可选择不同的时序预测模型:
| 模型 | 适用场景 |
|---|---|
| ARIMA / SARIMA | 数据量小、趋势和季节性明显 |
| Prophet | 需要解释性强、包含节假日效应 |
| LSTM / GRU | 数据量大、非线性关系复杂 |
| XGBoost / LightGBM | 特征工程丰富、需要快速训练 |
| Transformers(如 PatchTST) | 长序列、高精度需求 |
以 Prophet 为例:
from prophet import Prophet
train = df.reset_index().rename(columns={'timestamp': 'ds', 'qps': 'y'})
model = Prophet(yearly_seasonality=False, daily_seasonality=True)
model.fit(train)
future = model.make_future_dataframe(periods=60, freq='min')
forecast = model.predict(future)
模型服务化部署
训练好的模型需要部署为推理服务,供扩容决策器调用。常用方案:
- Flask/FastAPI:轻量快速,适合内部服务。
- KServe / Seldon Core:云原生模型服务框架,支持自动扩缩容、A/B 测试。
- MLflow Serving:与 MLflow 模型仓库集成。
FastAPI 示例:
from fastapi import FastAPI
from pydantic import BaseModel
import joblib
app = FastAPI()
model = joblib.load('qps_forecaster.pkl')
class Input(BaseModel):
steps: int = 30
@app.post('/predict')
def predict(input: Input):
future = model.make_future_dataframe(periods=input.steps, freq='min')
forecast = model.predict(future)
return forecast[['ds', 'yhat', 'yhat_lower', 'yhat_upper']].tail(input.steps).to_dict()
扩容决策与执行
扩容决策器根据预测结果计算目标副本数。常见策略:
def desired_replicas(predicted_qps, qps_per_pod, max_replicas, min_replicas):
desired = int(math.ceil(predicted_qps / qps_per_pod))
return max(min_replicas, min(desired, max_replicas))
执行器通过 client-go 或 kubectl 修改 Deployment:
kubectl scale deployment api-gateway --replicas=10
也可以开发自定义 Controller,监听预测服务结果并自动调整副本。
与 HPA 的联动
Kubernetes 1.18+ 支持 HPA 的 behavior 字段,可以设置扩容和缩容的稳定窗口与速率。预测性扩容可以与 HPA 结合:
- 预测扩容:在流量高峰到来前主动扩容。
- HPA 兜底:基于实时 CPU/内存做精细调整。
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: api-gateway-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: api-gateway
minReplicas: 3
maxReplicas: 50
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60
behavior:
scaleUp:
stabilizationWindowSeconds: 0
policies:
- type: Percent
value: 100
periodSeconds: 15
MLOps 流程
将模型训练、验证、部署纳入 MLOps 流水线:
- 数据版本化:使用 DVC 管理训练数据。
- 实验追踪:使用 MLflow 记录超参数与指标。
- 模型注册:将最佳模型注册到模型仓库。
- CI/CD 集成:代码变更触发重新训练与部署。
- 监控与漂移检测:持续监控预测质量,发现数据漂移后重训。
总结
基于流量预测的自动扩容是 AIOps 在资源优化领域的典型应用。通过将时序预测模型与 Kubernetes 弹性伸缩结合,可以实现从"被动响应"到"主动预防"的转变,显著提升系统稳定性与资源利用效率。