K8s Deployment 滚动更新全攻略：Recreate vs RollingUpdate，玩转 maxSurge 和 maxUnavailable

K8s Deployment 滚动更新全攻略：Recreate vs RollingUpdate，玩转 maxSurge 和 maxUnavailable

作为一名 Kubernetes 应用发布工程师，你是否经常为了应用的平滑升级而绞尽脑汁？ Kubernetes Deployment 提供的滚动更新策略，无疑是解决这个问题的利器。本文将深入剖析 Deployment 的两种核心更新策略：Recreate 和 RollingUpdate，带你玩转 maxSurge 和 maxUnavailable 参数，最终实现应用的优雅升级。

1. 认识 Deployment：应用发布的基石

在深入滚动更新策略之前，我们先来简单回顾一下 Deployment 的作用。Deployment 是 Kubernetes 中用于管理 Pod 的一种资源对象，它能够确保在集群中运行指定数量的 Pod 副本，并提供声明式的更新方式。简单来说，Deployment 就像一个“指挥官”，负责应用的部署、扩缩容、更新等操作。

2. 滚动更新策略：平滑升级的关键

滚动更新策略是指在更新应用版本时，Deployment 会逐步替换旧版本的 Pod，而不是一次性全部替换。这种方式可以最大限度地减少应用停机时间，保证用户体验。

Kubernetes Deployment 提供了两种主要的滚动更新策略：

• Recreate： 先删除所有旧的 Pod，再创建新的 Pod。
• RollingUpdate： 逐步替换旧的 Pod，同时保持一定数量的 Pod 处于运行状态。

下面我们将分别深入探讨这两种策略的实现原理、优缺点以及适用场景。

3. Recreate 策略：简单粗暴，适用于对停机时间不敏感的应用

3.1 实现原理

Recreate 策略的实现原理非常简单：

1. Deployment 收到更新指令后，会先删除所有旧版本的 Pod。
2. 删除完成后，Deployment 会创建新的 Pod，并启动新的应用版本。

3.2 优缺点

优点：

• 简单易懂： 实现方式简单直接，容易理解和配置。
• 彻底清除旧版本： 可以避免旧版本应用残留导致的问题。

缺点：

• 存在停机时间： 在删除旧 Pod 和创建新 Pod 之间存在停机时间，这会导致服务中断。

3.3 适用场景

Recreate 策略适用于以下场景：

• 对停机时间不敏感的应用： 例如，非核心业务的后台任务、测试环境等。
• 需要彻底清除旧版本应用的应用： 例如，存在缓存冲突、配置不兼容等问题的应用。

3.4 配置示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v1

在上面的示例中，strategy.type 被设置为 Recreate，表示使用 Recreate 策略进行更新。

4. RollingUpdate 策略：优雅平滑，适用于对停机时间敏感的应用

4.1 实现原理

RollingUpdate 策略的实现原理相对复杂一些，它通过逐步替换旧版本的 Pod，来保证服务的连续性。

1. Deployment 收到更新指令后，会先创建一个或多个新的 Pod（具体数量由 maxSurge 参数决定）。
2. 新的 Pod 启动并准备就绪后，Deployment 会删除一个或多个旧的 Pod（具体数量由 maxUnavailable 参数决定）。
3. Deployment 会重复步骤 2，直到所有旧的 Pod 都被新的 Pod 替换。

4.2 核心参数：maxSurge 和 maxUnavailable

RollingUpdate 策略的平滑性很大程度上取决于 maxSurge 和 maxUnavailable 这两个参数的配置。

• maxSurge： 指定在更新过程中，可以超过期望 Pod 数量的最大 Pod 数量或百分比。例如，如果期望的 Pod 数量是 3，maxSurge 设置为 1，那么在更新过程中，最多可以有 4 个 Pod 运行。
• maxUnavailable： 指定在更新过程中，可以有多少个 Pod 处于不可用状态。例如，如果期望的 Pod 数量是 3，maxUnavailable 设置为 1，那么在更新过程中，至少要有 2 个 Pod 处于运行状态。

4.3 优缺点

优点：

• 零停机时间： 在更新过程中，始终保持一定数量的 Pod 处于运行状态，从而实现零停机时间。
• 平滑过渡： 逐步替换旧的 Pod，可以降低更新过程中的风险。

缺点：

• 配置复杂： 需要合理配置 maxSurge 和 maxUnavailable 参数，才能达到最佳效果。
• 更新速度较慢： 相比 Recreate 策略，RollingUpdate 策略的更新速度较慢。

4.4 适用场景

RollingUpdate 策略适用于以下场景：

• 对停机时间敏感的应用： 例如，核心业务的在线服务、支付系统等。
• 需要平滑过渡的应用： 例如，大型应用、复杂应用等。

4.5 配置示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  selector:
    matchLabels:
      app: my-app
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v2

在上面的示例中，strategy.type 被设置为 RollingUpdate，表示使用 RollingUpdate 策略进行更新。rollingUpdate.maxSurge 被设置为 1，表示在更新过程中，最多可以有 4 个 Pod 运行。rollingUpdate.maxUnavailable 被设置为 1，表示在更新过程中，至少要有 2 个 Pod 处于运行状态。

5. 深入理解 maxSurge 和 maxUnavailable

maxSurge 和 maxUnavailable 这两个参数是 RollingUpdate 策略的核心，理解它们的含义和作用至关重要。

5.1 maxSurge 的配置技巧

maxSurge 用于控制更新过程中额外创建的 Pod 数量，它可以设置为一个绝对值或一个百分比。

• 绝对值： 表示额外创建的 Pod 的最大数量。例如，maxSurge: 2 表示最多额外创建 2 个 Pod。
• 百分比： 表示额外创建的 Pod 的最大数量占期望 Pod 数量的百分比。例如，maxSurge: 25% 表示最多额外创建期望 Pod 数量的 25% 的 Pod。

配置建议：

• 如果集群资源充足，可以适当增加 maxSurge 的值，以加快更新速度。
• 如果集群资源紧张，可以适当减小 maxSurge 的值，以降低资源消耗。
• 在生产环境中，建议使用百分比来配置 maxSurge，这样可以更好地适应 Pod 数量的变化。

5.2 maxUnavailable 的配置技巧

maxUnavailable 用于控制更新过程中可以处于不可用状态的 Pod 数量，它可以设置为一个绝对值或一个百分比。

• 绝对值： 表示可以处于不可用状态的 Pod 的最大数量。例如，maxUnavailable: 1 表示最多可以有 1 个 Pod 处于不可用状态。
• 百分比： 表示可以处于不可用状态的 Pod 的最大数量占期望 Pod 数量的百分比。例如，maxUnavailable: 25% 表示最多可以有期望 Pod 数量的 25% 的 Pod 处于不可用状态。

配置建议：

• 为了保证服务的可用性，应尽量减小 maxUnavailable 的值。
• 如果应用对可用性要求不高，可以适当增加 maxUnavailable 的值，以加快更新速度。
• 在生产环境中，建议使用百分比来配置 maxUnavailable，这样可以更好地适应 Pod 数量的变化。

5.3 如何选择合适的 maxSurge 和 maxUnavailable 值？

选择合适的 maxSurge 和 maxUnavailable 值，需要综合考虑以下因素：

• 集群资源： 集群资源是否充足？
• 应用可用性要求： 应用对可用性要求有多高？
• 更新速度要求： 是否需要在最短时间内完成更新？

一般来说，可以遵循以下原则：

• 高可用性，低更新速度： 减小 maxUnavailable 的值，减小 maxSurge 的值。
• 低可用性，高更新速度： 增加 maxUnavailable 的值，增加 maxSurge 的值。
• 均衡策略： 根据实际情况，选择合适的 maxSurge 和 maxUnavailable 值，以达到可用性和更新速度的平衡。

6. 滚动更新的实践技巧

除了合理配置 maxSurge 和 maxUnavailable 参数外，还可以通过以下技巧来优化滚动更新：

• 使用 Readiness Probe： Readiness Probe 用于检测 Pod 是否准备好接收流量。在滚动更新过程中，只有当新的 Pod 通过 Readiness Probe 检测后，才会开始替换旧的 Pod。这可以有效避免将未准备好的 Pod 暴露给用户。
• 使用 PreStop Hook： PreStop Hook 是在 Pod 被删除之前执行的命令或脚本。可以在 PreStop Hook 中执行一些清理工作，例如，优雅关闭连接、保存未完成的任务等。这可以避免因 Pod 突然停止而导致的数据丢失或服务中断。
• 监控更新过程： 通过 Kubernetes Dashboard、Prometheus 等工具，可以实时监控滚动更新的进度和状态。这可以帮助及时发现和解决问题。

7. 总结

滚动更新是 Kubernetes Deployment 中一项非常重要的功能，它可以帮助我们实现应用的平滑升级，保证服务的连续性。本文深入剖析了 Recreate 和 RollingUpdate 两种滚动更新策略的实现原理、优缺点以及适用场景，并详细讲解了 maxSurge 和 maxUnavailable 参数的配置技巧。希望本文能够帮助你更好地理解和使用 Kubernetes Deployment 的滚动更新功能，从而提升应用的发布效率和质量。

作为一名 Kubernetes 应用发布工程师，熟练掌握滚动更新策略，是你的必备技能！ 记住，没有最好的策略，只有最适合你的策略。根据实际情况，选择合适的滚动更新策略和参数配置，才能达到最佳效果。