健康检查、滚动更新与资源限制

K8s 的自愈能力依赖于两件事：知道 Pod 是否健康（健康检查）和知道如何安全地替换 Pod（滚动更新）。不配置这两项就等于无法真正利用 K8s 的核心优势。

三种探针的用途

完整探针 + 资源限制配置

# 带探针和资源限制的生产级 Deployment 示例
containers:
- name: myapp
image: myapp:1.2.0
# 资源请求与限制
resources:
requests:       # Scheduler 用来决定放哪个节点
memory: "128Mi"
cpu: "100m"   # 100m = 0.1 个 CPU 核
limits:         # 超出则被 OOM Kill / throttle
memory: "256Mi"
cpu: "500m"
# 启动探针（给启动慢的应用用，Spring Boot / JVM 应用）
startupProbe:
httpGet:
path: /health
port: 8080
failureThreshold: 30   # 最多 30 × 10s = 5 分钟等待启动
periodSeconds: 10
# 存活探针（检测死锁、内存泄漏）
livenessProbe:
httpGet:
path: /health/live
port: 8080
initialDelaySeconds: 10
periodSeconds: 15
failureThreshold: 3     # 连失败 3 次才重启
# 就绪探针（检测是否可以接收流量）
readinessProbe:
httpGet:
path: /health/ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
failureThreshold: 2     # 失败 2 次则从 Service 摘除

滚动更新策略配置

# Deployment 的更新策略
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1       # 更新期间最多额外多几个 Pod（不影响 replicas）
maxUnavailable: 0 # 更新期间最少保证可用 Pod 数 = 0 个不可用
# 上面配置含义：先起 1 个新 Pod，等就绪后再杀 1 个旧 Pod（零停机）

# 触发滚动更新（更新镜像）
kubectl set image deploy/myapp myapp=myapp:1.3.0 -n production
# 查看更新进度
kubectl rollout status deploy/myapp -n production
# 查看历史版本（需要 --record 或使用 annotations）
kubectl rollout history deploy/myapp -n production
# 回滚到上一个版本
kubectl rollout undo deploy/myapp -n production
# 回滚到指定版本
kubectl rollout undo deploy/myapp --to-revision=2 -n production

水平自动扩容（HPA）

# 根据 CPU 使用率自动扩缩 Pod 数量
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: myapp-hpa
namespace: production
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60   # CPU 均值超过 60% 则扩容

# 查看 HPA 状态（当前副本数和利用率）
kubectl get hpa -n production

本节执行清单

• [ ] 给应用添加 /health 端点（HTTP 200 表示健康）
• [ ] 配置 readinessProbe，确保无流量进入未就绪的 Pod
• [ ] 设置 resources.requests 和 limits（不设会触发节点资源争抢）
• [ ] 练习一次滚动更新和回滚，确认零停机

下一章：可观测性体系 — Prometheus 与 Grafana