如何选择 Kubernetes Deployment 的更新策略？

目录

滚动更新（RollingUpdate）

重建更新（Recreate）

小结

---

Kubernetes Deployment支持两种更新策略：滚动更新（RollingUpdate）和重建更新（Recreate），用户可以根据实际需求选择合适的更新策略。

滚动更新（RollingUpdate）

滚动更新是 Kubernetes Deployment 默认的更新策略，可以在不停止服务的情况下逐步更新应用。在滚动更新过程中，Kubernetes 会逐渐替换旧的 Pods 为新的 Pods，可以确保在更新过程中始终有一定数量的 Pod 处于运行状态，从而实现无缝升级，降低服务中断的风险。

RollingUpdate 策略可以通过以下两个参数进行控制：

• maxUnavailable：在更新过程中允许的最大不可用 Pod 数量，可以是绝对数值（如 1）或百分比（如 50%），设置为百分比时，如果得出的值不是整数，会采取向下取整。例如，如果你有 10 个副本，并设置 maxUnavailable 为 1（或者 10%），那么在任何时间点，最多只能有 1 个 Pod 不可用。
• maxSurge：在更新过程中允许的最大超出期望 Pod 数量，可以是绝对数值（如 1）或百分比（如 50%），设置为百分比时，如果得出的值不是整数，会采取向上取整。例如，如果你有 10 个副本，并设置 maxSurge 为 2（或者 20%），那么在更新过程中，Pod 的数量可以达到 12 个。

看个简单的示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myapp-image:v2

重建更新（Recreate）

重建更新策略会在创建新的 Pod 之前，先将所有旧的 Pod 删除，意味着服务在新 Pods 被创建并准备就绪之前的这段时间内是不可用的。这种方法虽然简单粗暴，但在某些情况下可能是更合适的，例如不能同时运行多个副本的应用场景。

对于 Recreate 策略，不需要额外的配置参数，只需要在 Deployment 的 spec.strategy.type 字段设置为 Recreate 即可。看个简单的示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 10
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myapp-image:v2

小结

如何选择更新策略取决于应用程序的业务逻辑，大多数情况下，RollingUpdate 是首选的更新策略，因为这种策略能够在不停机的情况下更新应用。但是在特定的应用场景下，Recreate 策略也可能是一个合适的选择。