🥇Kubernetes 中的部署策略：滚动、重新创建、蓝/绿、金丝雀、深色（A/B 测试）| 专业主机

笔记翻译： Weaveworks 的概述介绍了最流行的应用程序部署策略，并展示了如何使用 Kubernetes Flagger 运算符来实现最先进的策略。它以简单的语言编写，并包含可视化图表，即使是新手工程师也能理解问题。

该图取自另一则评论容器解决方案中制定的推出策略

当今开发云原生应用程序的最大挑战之一是加快部署速度。在微服务方法中，开发人员已经使用并设计了完全模块化的应用程序，允许不同的团队同时编写代码并对应用程序进行更改。

更短、更频繁的部署具有以下优点：

上市时间缩短。
新功能更快地到达用户手中。
用户反馈更快地到达开发团队。这意味着团队可以更快地添加功能并解决问题。
开发人员士气提高：开发中的功能越多，使用起来就越有趣。

但随着发布频率的增加，对应用程序的可靠性或用户体验产生负面影响的可能性也会增加。这就是为什么运营和 DevOps 团队以最小化产品和用户风险的方式构建流程和管理部署策略非常重要。（您可以了解更多关于 CI/CD 管道自动化这里.)

在这篇文章中，我们将讨论 Kubernetes 中的各种部署策略，包括滚动部署和更高级的方法，例如金丝雀部署及其变体。

部署策略

您可以根据您的目标使用多种不同类型的部署策略。例如，您可能需要对某个环境进行更改以进行进一步测试，或者对用户/客户端的子集进行更改，或者您可能需要在制作功能之前进行有限的用户测试 公开的.

滚动（逐步、“滚动”部署）

这是 Kubernetes 中的标准部署策略。它会逐渐将旧版本应用程序的 pod 替换为新版本的 pod，而无需集群停机。

Kubernetes 等待新的 Pod 准备好工作（使用以下命令检查它们）准备测试），然后再开始卷起旧的。如果出现问题，可以中止此滚动更新，而无需停止整个集群。在描述部署类型的 YAML 文件中，新映像将替换旧映像：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: awesomeapp
    spec:
      containers:
        - name: awesomeapp
          image: imagerepo-user/awesomeapp:new
          ports:
            - containerPort: 8080

可以在清单文件中指定翻转更新参数：

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

重新创造

在这种最简单的部署类型中，旧的 Pod 会被一次性全部杀死并替换为新的 Pod：

相应的清单看起来像这样：

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

蓝/绿（蓝绿部署）

蓝绿部署策略（有时也称为红/黑）涉及同时部署应用程序的旧版本（绿色）和新版本（蓝色）。发布两个版本后，普通用户可以访问绿色版本，而蓝色版本可供 QA 团队通过单独的服务或直接端口转发来自动化测试：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

蓝色（新）版本测试通过并批准发布后，服务切换至该版本，绿色（旧）版本折叠：

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

金丝雀（金丝雀部署）

金丝雀部署与蓝绿部署类似，但具有更好的控制和使用进步循序渐进的方法。这种类型包括几种不同的策略，包括“秘密”发布和 A/B 测试。

当需要尝试一些新功能时（通常是在应用程序的后端），可以使用此策略。该方法的本质是创建两个几乎相同的服务器：一个为几乎所有用户提供服务，另一个具有新功能，仅为一小部分用户提供服务，然后对它们的工作结果进行比较。如果一切顺利，新版本将逐步推广到整个基础设施。

虽然这个策略可以专门使用 Kubernetes 来实现，用新的 pod 替换旧的 pod，但使用像 Istio 这样的服务网格要方便和简单得多。

例如，您在 Git 中可能有两个不同的清单：带有标签 0.1.0 的常规清单和带有标签 0.2.0 的金丝雀清单。通过更改 Istio 虚拟网关清单中的权重，您可以控制这两个部署之间的流量分配：

有关使用 Istio 实施金丝雀部署的分步指南，请参阅使用 Istio 的 GitOps 工作流程. (笔记。翻译。：我们还将有关金丝雀部署的材料翻译成 Istio 这里.)

使用 Weaveworks Flagger 进行金丝雀部署

Weaveworks 标记者允许您轻松有效地管理金丝雀部署。

Flagger 自动化了与他们的合作。它使用 Istio 或 AWS App Mesh 来路由和交换流量，并使用 Prometheus 指标来分析结果。此外，金丝雀部署的分析可以通过 webhook 进行补充，以进行验收测试、负载测试和任何其他类型的检查。

基于 Kubernetes 部署，以及必要时的 pod 水平扩展 (HPA)，Flagger 创建对象集（Kubernetes 部署、ClusterIP 服务和 Istio 或 App Mesh 虚拟服务）来分析和实施金丝雀部署：

实现控制循环 （控制回路）,Flagger逐渐将流量切换到金丝雀服务器，同时测量关键性能指标，例如成功的HTTP请求百分比、平均请求持续时间和Pod健康状况。根据KPI（关键绩效指标）分析，金丝雀要么增长，要么崩溃，分析结果发布在Slack中。该过程的描述和演示可以在材料中找到 App Mesh 的渐进式交付.

黑暗（隐藏）或 A/B 部署

隐形部署是金丝雀策略的另一种变体（顺便说一句，Flagger 也可以使用它）。隐形部署和金丝雀部署之间的区别在于，隐形部署处理前端，而不是像金丝雀部署那样处理后端。

这些部署的另一个名称是 A/B 测试。新功能并未向所有用户提供，而是仅向有限的一部分用户提供。通常，这些用户不知道他们是先锋测试人员（因此称为“隐形部署”）。

使用功能开关 （功能切换） 和其他工具，您可以监控用户如何与新功能交互，他们是否参与其中，或者他们是否发现新用户界面令人困惑，以及其他类型的指标。

Flagger 和 A/B 部署

除了基于权重的路由之外，Flagger 还可以根据 HTTP 参数将流量路由到金丝雀服务器。在 A/B 测试中，您可以使用 HTTP 标头或 cookie 来定位特定的用户群。这对于需要会话绑定到服务器的前端应用程序尤其有效 （会话亲和力）。更多信息可以在 Flagger 文档中找到。

作者很感激斯特凡·普罗丹，Weaveworks 工程师（也是 Flagger 的创建者），了解所有这些令人惊叹的部署模式。

译者PS

另请阅读我们的博客：

来源： habr.com

Kubernetes 中的部署策略：滚动、重新创建、蓝/绿、金丝雀、深色（A/B 测试）