一文读懂 Kubernetes 部署策略

在这篇文章中，我们将深入研究 Kubernetes 部署概念和一些常见策略，了解每种策略的优缺点。合适的部署策略使我们能够在发布应用程序时最大限度地减少停机时间、增强客户体验并提高可靠性。

什么是 Kubernetes 部署策略？

Kubernetes 部署是一种声明性语句，通常在 YAML 文件中配置，用于定义应用程序生命周期以及如何管理对该应用程序的更新。

当将应用程序部署到 K8s 集群时，所选择的部署策略将决定如何将应用程序从旧版本更新到新版本。某些策略可能会导致停机时间，而其他策略则可能引入测试概念并允许用户分析。本文将介绍两种常用的基本 K8s 部署策略：

• 重新创建（Recreating）

• 滚动更新（Rolling）

以下策略被认为是“高级部署策略”，因为可以以多种方式控制流量的流向：

• 蓝/绿（Blue/Green）

• 金丝雀（Canary）

• A/B

• 影子部署（Shadow Deployment）

K8s 使用滚动更新策略作为默认策略，但在某些情况下可能不适用。让我们详细讨论每种策略！

1. 重新创建部署（Recreate Deployment）

重新创建部署会终止所有的 Pod，并用新版本的 Pod 替换它们。这在旧版本和新版本的应用程序不能同时运行的情况下很有用。使用此策略产生的停机时间取决于应用程序关闭和启动所需的时间。由于完全替换，应用程序状态也会完全更新。

示例如下，type=Recreate 表示为重新创建

spec:  replicas: 10  strategy:    type: Recreate

2. 滚动更新部署（Rolling Deployment）

滚动更新是 K8s 的默认部署方式，旨在减少集群的停机时间。滚动更新会将运行旧版本应用程序的 Pod 逐步替换为新版本，而无需停机。

为了实现这一点，要使用就绪探针（Readiness probes）

就绪探针监视应用程序何时变为可用状态。如果探针失败，流量将不会发送到该 Pod。这些探针用于需要在就绪之前执行部分初始化步骤的应用程序，比如数据库链接、缓存数据初始化，应用的发布注册等操作。

一旦就绪探针检测到新版本应用程序可用，旧版本应用程序将被删除。如果出现问题，可以停止部署并回滚到上一个版本，避免整个集群的停机时间。由于每个 Pod 逐个替换，对于较大的集群，部署需要一定的时间。如果在另一个部署完成之前触发了新的部署，版本将更新为新部署中指定的版本，并且尚未部署成功的先前部署版本将被忽略。

触发滚动更新部署的条件是 Pod 规范中的某些更改，例如更新 Pod 的镜像、环境变量或标签。可以使用命令 kubectl set image 来更新 Pod 镜像。

yaml 文件的 Spec: -> strategy: 部分可以使用两个参数来细化部署：maxSurge 和 maxUnavailable。这两个参数可以指定为百分比或绝对数值。当使用水平 Pod 自动缩放时，应使用百分比。

• maxSurge 指定部署允许同时创建的最大 Pod 数量。

• maxUnavailable 指定在部署期间允许不可用的最大 Pod 数量。

例如，下面的配置要求有 10 个副本，最多同时创建 3 个副本，允许在部署期间有 1 个副本不可用：

spec:  replicas: 10  strategy:    type: RollingUpdate    rollingUpdate:      maxSurge: 3      maxUnavailable: 1

3.蓝/绿部署（Blue/Green Deployment）

蓝/绿部署涉及将新的应用程序版本（绿色）与旧版本（蓝色）一起部署。通过服务选择器对象作为负载均衡器，当新应用程序（绿色）经过测试和验证后，将流量引导到新应用程序而不是旧应用程序。蓝/绿部署可能会造成成本增加，因为在部署期间需要启动两倍数量的应用程序资源。

为了实现这一点，我们需要设置一个在部署之前的服务。例如，对于名为 web-app 的应用程序的 v1.0.0 版本的蓝色部署，yaml 文件中的服务选择器部分可能如下所示：

kind: Servicemetadata: name: web-app-01 labels:   app: web-appselector:   app: web-app   version: v1.0.0

蓝色 web-app 的部署如下：

kind: Deploymentmetadata:  name: web-app-01spec:  template:        metadata:           labels:             app: web-app             version: "v1.0.0"

当我们想要将流量引导到应用程序的新（绿色）版本时，我们更新 manifest 文件以指向新版本 v2.0.0。

kind: Servicemetadata: name: web-app-02 labels:   app: web-appselector:   app: web-app   version: v2.0.0

绿色应用程序的部署如下：

kind: Deploymentmetadata:  name: web-app-02spec:  template:        metadata:           labels:             app: web-app             version: "v2.0.0"

4. 影子部署（Shadow Deployment）

金丝雀与“影子部署”一词可以互换使用。

影子部署是一种策略，其中新版本的应用程序与现有的生产版本一起部署，主要用于监控和测试目的。在影子部署中，用户流量不会主动路由到新版本。这对于测试新功能的生产负载特别有用。

这种技术比较复杂，需要特殊要求，尤其是出口流量。例如，有一个商品，您想调用支付服务进行影子测试，最终可能会让客户为他们的订单支付两次，所以复杂性比较高

5. 金丝雀部署（Canary Deployments）

金丝雀部署可用于让一部分用户测试应用程序的新版本，或者在对新版本的功能性没有完全信心时使用。新版本的一个副本与旧版本一起发布，其中旧版本应用程序为大部分用户提供服务，而新版本应用程序为一小部分测试用户提供服务。如果新部署成功，则将其逐渐扩展到更多用户。

例如，在一个具有 100 个运行的 Pod 的 K8s 集群中，有 95 个运行着应用程序的 v1.0.0 版本，而有 5 个运行着新的 v2.0.0 版本。95% 的用户将被路由到旧版本，而 5% 的用户将被路由到新版本。为此，我们使用并行的两个部署，可以分别进行扩展。

旧应用程序的 yaml 文件中的 spec 部分可能如下所示:

spec:  replicas: 95

新应用程序的 yaml 文件中的 spec 部分可能如下所示：

spec:  replicas: 5

在上面的示例中，运行 100 个 Pod 可能是不切实际的。更好的方法是使用负载均衡器，如 NGINX、HAProxy 或 Traefik，或者使用类似 Istio、Hashicorp Consul 或 Linkrd 的服务网格，他们可以提供对流量的更好控制。

6. A/B 部署

与金丝雀部署类似，使用 A/B 部署，我们可以基于一些目标参数（通常是 HTTP 标头或 cookie 等）定位给定的用户，并根据权重在不同版本之间分配流量。这种技术被广泛用于测试某个特定功能的转化率，然后选择转化率最高的版本进行最终部署。

这种方法通常基于收集的用户行为数据，并用于做出更好的业务决策。在 A/B 测试期间，用户通常不会被告知新功能，以便进行真实的测试，并可以比较使用旧版本和新版本的用户之间的体验。由于额外的测试期和用户体验分析，使用 A/B 部署进行部署速度可能会较慢。

可以使用 Istio 和 Flagger 自动化进行 A/B 部署。

总结

在本文中，我们讨论了 6 种常见的 K8s 部署策略。在决定如何部署或升级您的应用程序时，如何使用这些策略，以及使用哪些工具来实现每种策略是非常重要的。