配置保守的更新策略

保守更新策略

如果对稳定性要求较高，可以设置比较保守的滚动更新策略：

1. 保持足够多的可用副本数量。避免在滚动时可以正常处理请求的 Pod 数量减少导致部分请求因后端 Pod 处理不过来而异常。
2. 减缓发版速度。一方面可以避免新版应用引入难以发现的问题快速扩散，方便发现后及时回滚恢复；另一方面，如果使用 LB 直通 Pod，更新过程中，云厂商的 service-controller 或 cloud-controller-manager 组件会更新 LB 的后端 rs，这个过程是异步的，在某些极端场景下，可能出现 LB 后端的 rs 还没更新，旧的 Pod 副本已经被销毁了，从而导致流量转发到已销毁的 Pod 而引发异常。
3. 给新副本留预热时间。新副本启动时，多给应用一些时间进行准备，避免某些应用虽然探测接口返回就绪，但实际处理能力还没跟上，过早转发请求过来可能导致异常。

配置示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
    rollingUpdate: # 单个串行升级，等新副本 ready 后才开始销毁旧副本
      maxUnavailable: 0
      maxSurge: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          startupProbe:
            httpGet:
              path: /
              port: 80
            successThreshold: 5 # 新副本启动时，连续探测成功多次后才交给 readinessProbe 探测
            periodSeconds: 5
          readinessProbe:
            httpGet:
              path: /
              port: 80
            successThreshold: 1 # 运行过程中探测 1 次成功就认为 ready，可在抖动导致异常后快速恢复服务
            periodSeconds: 5