16.8.6 容量规划与SLO/SLI评估
容量规划与SLO/SLI评估面向“可用性、性能、成本”三者平衡，在Kubernetes中需结合资源模型、业务增长与错误预算进行量化管理，并用可执行的监控与压测闭环验证。
原理草图（容量规划闭环）
核心概念
- SLI（Service Level Indicator）：成功率、延迟、吞吐、饱和度等量化指标。
- SLO（Service Level Objective）：SLI目标阈值，如99.9%成功率、P95<300ms。
- SLA：对外承诺，通常高于SLO。
- 错误预算：允许失败比例，SLO=99.9%则错误预算=0.1%。
容量规划输入指标
- 业务侧：峰值QPS、日/周季节性、活动流量、增长率。
- 资源侧：CPU/内存/存储/网络带宽、P95/P99延迟、饱和度。
- Kubernetes侧：Requests/Limits、Pod副本数、节点规格与数量、多可用区策略。
规划方法与步骤（含示例与命令）#
1. 基线测量（监控数据提取）#
示例：用PromQL提取P95延迟与错误率
# P95延迟（以nginx_ingress为例）
histogram_quantile(0.95, sum(rate(nginx_ingress_controller_request_duration_seconds_bucket[5m])) by (le))
# 5xx错误率
sum(rate(nginx_ingress_controller_requests{status=~"5.."}[5m]))
/
sum(rate(nginx_ingress_controller_requests[5m]))
期望效果：得到稳定期的P95/P99与错误率作为基线。
2. 负载模型（QPS-资源曲线）#
示例：压测并观测CPU/内存
# 1) 安装hey进行压测（示例：Linux）
wget https://hey-release.s3.us-east-2.amazonaws.com/hey_linux_amd64 -O /usr/local/bin/hey
chmod +x /usr/local/bin/hey
# 2) 对服务压测（60s，200并发）
hey -z 60s -c 200 http://svc.example.svc.cluster.local/
# 3) 监控Pod资源曲线
kubectl top pod -n app
期望效果：QPS上升时CPU/内存变化趋势明确，找到瓶颈拐点。
3. 容量估算（Requests/Limits与副本）#
示例：估算并设定Requests/Limits
# /tmp/app-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app
namespace: app
spec:
replicas: 3
selector:
matchLabels:
app: app
template:
metadata:
labels:
app: app
spec:
containers:
- name: app
image: nginx:1.25
resources:
requests:
cpu: "500m"
memory: "512Mi"
limits:
cpu: "1"
memory: "1Gi"
kubectl apply -f /tmp/app-deploy.yaml
命令解释：Requests用于调度，Limits是上限；cpu可超卖但内存不建议。
4. 冗余与容灾（N+1策略）#
示例：跨可用区调度
# /tmp/app-pod-affinity.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-az
namespace: app
spec:
replicas: 3
selector:
matchLabels:
app: app-az
template:
metadata:
labels:
app: app-az
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: app-az
containers:
- name: app
image: nginx:1.25
kubectl apply -f /tmp/app-pod-affinity.yaml
期望效果：Pod均匀分布在不同AZ，单AZ故障仍可用。
5. 弹性策略（HPA示例）#
# /tmp/app-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: app-hpa
namespace: app
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: app
minReplicas: 3
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
kubectl apply -f /tmp/app-hpa.yaml
kubectl get hpa -n app
期望效果：CPU超过70%自动扩容，降低SLO风险。
6. 压测验证（SLO达标检查）#
示例：压测期间SLI检查
# 压测后查看错误率与P95延迟
# Prometheus UI中执行PromQL，或用curl查询API
期望效果：错误率低于错误预算阈值，P95符合SLO。
Kubernetes资源模型与调度影响#
- Requests决定调度，Limits决定上限；高Requests降低密度但更稳。
- CPU可超卖，内存不宜超卖，避免OOM。
- QoS策略：Guaranteed > Burstable > BestEffort，关键服务建议Guaranteed或高Requests。
SLI指标建议（含示例）#
成功率
sum(rate(http_requests_total{status!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
P95延迟
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
饱和度（CPU节流率）
sum(rate(container_cpu_cfs_throttled_seconds_total[5m]))
/
sum(rate(container_cpu_usage_seconds_total[5m]))
SLO制定与错误预算管理（示例）#
SLO模板
- 99.9%可用性（每月允许约43分钟不可用）
- P95延迟 < 300ms，P99 < 800ms
错误预算燃烧监测示例（PromQL）
# 错误预算燃烧率（近1h错误率 / 允许错误率）
(
sum(rate(http_requests_total{status=~"5.."}[1h]))
/
sum(rate(http_requests_total[1h]))
)
/
0.001
期望效果：燃烧率>1表示错误预算被超额消耗，应暂停发布或扩容。
常见排错与诊断（命令示例）#
- OOM频繁
kubectl describe pod -n app app-xxxxx | grep -A5 -i oom
kubectl top pod -n app
处理：增大memory requests/limits，优化内存泄漏。
- CPU节流导致延迟
kubectl top pod -n app
# 结合PromQL查看CPU节流率
处理：提高CPU limits或拆分热点实例。
- HPA不生效
kubectl describe hpa -n app app-hpa
kubectl get --raw /apis/metrics.k8s.io/v1beta1/namespaces/app/pods
处理：确认metrics-server运行正常、指标可用。
实战建议#
- 对API Server、etcd、ingress、存储单独建立SLO与容量指标。
- 建立“容量看板”：利用率、请求/限制、错误预算燃烧、扩缩容事件。
- 结合灰度发布与预扩容，避免冷启动抖动。
练习#
- 为你的业务选择1个核心SLI（如成功率），制定SLO并计算错误预算。
- 使用hey对服务压测60秒，记录QPS与P95延迟，并估算单Pod容量。
- 开启HPA并模拟CPU负载，观察副本扩缩容是否满足SLO。