扩缩容与高可用¶
Kubernetes 能维护副本、滚动发布和自动扩缩,但应用是否高可用取决于副本分布、健康检查、资源容量、依赖架构和故障演练。
Deployment 滚动发布¶
kubectl set image deployment/order-service \
app=registry.example.com/order-service:1.4.1 -n order
kubectl rollout status deployment/order-service -n order
kubectl rollout history deployment/order-service -n order
kubectl rollout undo deployment/order-service -n order
maxUnavailable: 0 需要集群有额外容量创建 Surge Pod。Readiness 必须真实反映可接流量状态,否则滚动完成也可能把错误版本全部放量。
HPA¶
HPA 根据 CPU、内存或自定义指标调整 Deployment/StatefulSet 副本数。
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: order-service
namespace: order
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: order-service
minReplicas: 3
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
CPU Utilization 以 request 为基准;未设置 CPU request 时 HPA 计算会受影响。扩容速度还受镜像拉取、应用启动、Readiness 和节点剩余容量限制。
VPA 与节点扩缩容¶
VPA 调整 Pod requests/limits,部分模式会重建 Pod;节点自动扩缩负责增减 Node。HPA、VPA 和节点扩缩组合前要明确各自控制变量,避免同时围绕 CPU 产生冲突或扩容链路过慢。
PodDisruptionBudget¶
PDB 限制节点 drain、集群升级等自愿中断期间可同时不可用的副本数:
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: order-service
namespace: order
spec:
minAvailable: 2
selector:
matchLabels:
app: order-service
PDB 不保护节点宕机、应用 OOM 或容器崩溃等非自愿中断,也不增加副本。设置过严可能让 drain 永远无法完成。
故障域分散¶
至少把多副本分散到不同节点;有多可用区时再按 zone 分散。使用 Pod Anti-Affinity 或 Topology Spread Constraints,并确认 Label 与实际故障域一致。
高可用检查¶
| 层次 | 问题 |
|---|---|
| Pod | 是否至少 2 个副本,是否分散节点,Probe 是否正确 |
| Node | 宕机后其他节点是否有容量承接 |
| 网络入口 | Controller/LB 是否多副本和多节点 |
| 存储 | Volume 能否在故障节点后重新挂载,数据是否有副本/备份 |
| 数据库/中间件 | 应用副本增加不代表依赖已高可用 |
| 发布 | 新旧版本是否兼容,失败能否停止并回退 |
常见问题¶
| 现象 | 优先检查 |
|---|---|
| HPA 不扩容 | 指标 API、requests、目标指标、maxReplicas |
| 已扩副本但请求仍慢 | 下游瓶颈、Service/入口、线程/连接池、节点资源 |
| drain 被 PDB 阻塞 | 当前 Ready 副本、PDB selector、minAvailable/maxUnavailable |
| 多副本仍一起故障 | 是否集中在同一节点/可用区;公共依赖是否单点 |
| 滚动发布卡住 | Readiness、资源容量、镜像、maxSurge/maxUnavailable |