带有舵图的蓝绿色部署 [英] Blue Green Deployment with Helm Charts

问题描述

我们可以使用带有'Helm Charts'的应用程序

We Could deploy applications using 'Helm Charts' with

helm install --name the-release  helm/the-service-helm --namespace myns

然后，我们使用

helm upgrade --recreate-pods the-release helm/the-service-helm --namespace myns

是否可以使用头盔图表" 实现 蓝色/绿色" 部署?

Is there a way to use 'Helm Charts' to achieve 'Blue/Green' Deployments?

推荐答案

让我们从定义开始吧

由于存在许多部署策略，所以从定义开始.

Let's start from definitions

Since there are many deployment strategies, let's start from the definition.

根据马丁花:

蓝绿色部署方法通过确保您拥有两个尽可能相同的生产环境来做到这一点.在任何时候，其中一个(例如蓝色)都处于活动状态.准备新版本的软件时，您将在绿色环境中进行最后的测试阶段.一旦软件在绿色环境中运行，您就可以切换路由器，以便所有传入请求都进入绿色环境-蓝色的请求现在处于空闲状态.

The blue-green deployment approach does this by ensuring you have two production environments, as identical as possible. At any time one of them, let's say blue for the example, is live. As you prepare a new release of your software you do your final stage of testing in the green environment. Once the software is working in the green environment, you switch the router so that all incoming requests go to the green environment - the blue one is now idle.

在Helm中不建议使用

Blue/Green.但是有解决方法

• 根据头盔问题#3518 ，不建议使用Helm进行blue/green或canary部署.

  Blue/Green is not recommended in Helm. But there are workaround solutions

  • As per to helm issue #3518, it's not recommended to use Helm for blue/green or canary deployment.

    至少有3种基于Helm的解决方案，请参见下文

    There are at least 3 solutions based on top of Helm, see below

    但是该情况下有Helm图表.

    However there is a Helm chart for that case.

    头盔本身不适合这种情况.看到他们的解释:

    Helm itself is not intended for the case. See their explanation:

    直接支持头盔中的蓝色/绿色部署模式·问题#3518·头盔/头盔

    Helm在传统软件包管理器的意义上工作更多，以一种优雅的方式将图表从一个版本升级到另一个版本(这要归功于pod liveness/readiness探针和部署更新策略)，就像人们对上班.与升级工作流的程序包管理器风格相比，蓝色/绿色部署是完全不同的野兽.蓝色/绿色在工具链中的地位更高，因为围绕这些部署的用例需要采用进/出策略，逐步的流量迁移和回滚.因此，我们认为蓝色/绿色部署对于Helm而言是超出范围的，尽管在幕后利用Helm的工具(或类似istio之类的东西)更有可能能够处理该用例.

    Helm works more in the sense of a traditional package manager, upgrading charts from one version to the next in a graceful manner (thanks to pod liveness/readiness probes and deployment update strategies), much like how one expects something like apt upgrade to work. Blue/green deployments are a very different beast compared to the package manager style of upgrade workflows; blue/green sits at a level higher in the toolchain because the use cases around these deployments require step-in/step-out policies, gradual traffic migrations and rollbacks. Because of that, we decided that blue/green deployments are something out of scope for Helm, though a tool that utilizes Helm under the covers (or something parallel like istio) could more than likely be able to handle that use case.

    基于Helm

    的其他解决方案

    至少有三种基于Helm的解决方案，对其进行了描述和比较

    Other solutions based on Helm

    There are at least three solution based on top of Helm, described and compared here:

    • 发货人
    • Istio
    • Flagger .
    • Shipper
    • Istio
    • Flagger.

    bookingcom/shipper :使用Helm的Kubernetes本机多集群金丝雀或蓝绿色产品 >

    bookingcom/shipper: Kubernetes native multi-cluster canary or blue-green rollouts using Helm

    它通过依赖Helm并使用Helm Charts作为配置部署的单位来做到这一点.发货人的Application对象提供了一个界面，用于指定图表的值，就像helm命令行工具一样. 发货人直接从ChartM库(如ChartMuseum)中使用Charts，并将对象本身安装到集群中.它具有很好的属性，可以使用常规的Kubernetes身份验证和RBAC控件来管理对Shipper API的访问.

    It does this by relying on Helm, and using Helm Charts as the unit of configuration deployment. Shipper's Application object provides an interface for specifying values to a Chart just like the helm command line tool. Shipper consumes Charts directly from a Chart repository like ChartMuseum, and installs objects into clusters itself. This has the nice property that regular Kubernetes authentication and RBAC controls can be used to manage access to Shipper APIs.

    使用Helm进行Kubernetes本地多群集金丝雀或蓝绿色卷展

    Kubernetes native multi-cluster canary or blue-green rollouts using Helm

    您可以尝试像这样:

    kubectl create -f <(istioctl kube-inject -f cowsay-v1.yaml) # deploy v1
    

    kubectl create -f <(istioctl kube-inject -f cowsay-v2.yaml) # deploy v1
    

    Flagger .

    Flagger小组编写了指南:蓝色/绿色部署-Flagger 本指南向您展示如何使用Flagger和Kubernetes自动执行蓝色/绿色部署

    Flagger.

    There is guide written by Flagger team: Blue/Green Deployments - Flagger This guide shows you how to automate Blue/Green deployments with Flagger and Kubernetes

    此外，按照 Kamol Hasan 的建议，您可以尝试以下图表:

    Also, as Kamol Hasan recommended, you can try that chart: puneetsaraswat/HelmCharts/blue-green.

    blue.yml示例

    {{ if .Values.blue.enabled }}
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: {{ template "blue-green.fullname" . }}-blue
      labels:
        release: {{ .Release.Name }}
        chart: {{ .Chart.Name }}-{{ .Chart.Version }}
        app: {{ template "blue-green.name" . }}
    spec:
      replicas: {{ .Values.replicaCount }}
      template:
        metadata:
          labels:
            app: {{ template "blue-green.name" . }}
            release: {{ .Release.Name }}
            slot: blue
        spec:
          containers:
            - name: {{ template "blue-green.name" . }}-blue
              image: nginx:stable
              imagePullPolicy: IfNotPresent
              ports:
                - name: http
                  containerPort: 80
                  protocol: TCP
              # This (and the volumes section below) mount the config map as a volume.
              volumeMounts:
                - mountPath: /usr/share/nginx/html
                  name: wwwdata-volume
          volumes:
            - name: wwwdata-volume
              configMap:
                name: {{ template "blue-green.fullname" . }}
    {{ end }}
    

    中等博客文章:使用头盔的蓝色/绿色部署图表

    这篇关于带有舵图的蓝绿色部署的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！