使用 Argo Rollouts 进行蓝绿/金丝雀发布

ARgo Rollouts 是一个 KubeRnetes OpeRaTor 实现，它为 KubeRnetes 提供更加高级的部署能力，如蓝绿、金丝雀、金丝雀分析、实验和渐进式交付功能，为云原生应用和服务实现自动化、基于 GitOps 的逐步交付。支持的特性有蓝绿更新策略，金丝雀更新策略，更加细粒度的加权流量拆分，自动回滚，手动判断，可定制的指标查询和业务KPI分析，IngReSS 控制器集成：Nginx，ALB，服务网格集成：Istio，linkeRd，SMI，MetRics指标集成：ProMetheUS、WavefRont、Kayenta、Web、KubeRnetes Jobs、Datadog、New Relic。与 DeployMent 对象类似，ARgo Rollouts 控制器将管理 ReplicaSets 的创建、缩放和删除，这些 ReplicaSet 由 Rollout 资源中的 spec.template 定义，使用与 DeployMent 对象相同的 pod 模板。当 spec.template 变更时，这会向 ARgo Rollouts 控制器发出信号，表示将引入新的 ReplicaSet，控制器将使用 spec.stRategy 字段内的策略来确定从旧 ReplicaSet 到新 ReplicaSet 的 Rollout 将如何进行，一旦这个新的 ReplicaSet 被放大，控制器会将其标记为稳定。如果在 spec.template 从稳定的 ReplicaSet过渡到新的 ReplicaSet的过程中发生了另一次变更，那么之前的新 ReplicaSet将缩小，并且控制器将尝试发布反映更新spec.template 字段的 ReplicaSet。在继续之前我们先来了解一些基本的概念。Rollout(滚动)：Rollout 是一个 KubeRnetes的CRD资源，相当于KubeRnetesDeployMent对象，在需要更高级的部署或渐进式交付功能的情况下，它旨在取代DeployMent对象，Rollout提供了KubeRnetesDeployMent所不能提供的功能。蓝绿部署，金丝雀部署，与IngReSS控制器和服务网格整合，实现高级流量路由，与用于蓝绿和金丝雀分析的指标提供者集成，根据成功或失败的指标，自动发布或回滚，渐进式交付。渐进式交付是以受控和渐进的方式发布产品更新的过程，从而降低发布的风险，通常将自动化和指标分析结合起来以驱动更新的自动升级或回滚。渐进式交付通常被描述为持续交付的演变，将CI/CD中的速度优势扩展到部署过程。通过将新版本限制在一部分用户，观察和分析正确的行为，然后逐渐增加更多的流量，同时不断验证其正确性。部署策略：Rollingupdate(滚动更新)：慢慢地用新版本替换旧版本，随着新版本的出现，旧版本会慢慢缩减，以保持应用程序的总数量。这是DeployMent对象的默认策略。RecReate(重新创建)：RecReate会在启动新版本之前删除旧版本的应用程序，这可确保应用程序的两个版本永远不会同时运行，但在部署期间会出现停机时间。Blue-GReen(蓝绿)：蓝绿发布指同时部署了新旧两个版本的应用程序，在此期间，只有旧版本的应用程序会收到生产流量，这允许开发人员在将实时流量切换到新版本之前针对新版本进行测试。CanaRy(金丝雀)：金丝雀发布指将一部分用户暴露在新版本的应用程序中，而将其余流量提供给旧版本，一旦新版本被验证是正确的，新版本可以逐渐取代旧版本。IngReSS控制器和服务网格，如NginxIngReSS和Istio，可以使金丝雀的流量拆分模式比原生的更复杂。上面显示了一个有两个阶段的金丝雀(10%和33%的流量进入新版本)，通过使用ARgo Rollouts，我们可以根据实际的使用情况定义确切的阶段数和流量百分比。用户希望在新版本开始为生产环境提供服务之前对其进行最后一分钟的功能测试，通过BlueGReen策略，ARgo Rollouts允许用户指定预览服务和活动服务，Rollout将配置预览服务以将流量发送到新版本，同时活动服务继续接收生产流量。一旦达到要求，则可以将预览服务提升为新的活动服务。在新版本开始接收实时流量之前，需要预先执行一套通用步骤，通过使用BlueGReen策略，用户可以在不接收来自活动服务的流量的情况下启动新版本，一旦这些步骤执行完毕，就可以将流量切换到新版本了。用户希望在几个小时内将一小部分生产流量提供给他们应用程序的新版本，之后，他们希望缩小新版本规模，并查看一些指标以确定新版本与旧版本相比是否具有性能问题，然后他们将决定是否为切换到新版本。使用金丝雀策略，Rollout可以用新版本扩大ReplicaSet的规模，以接收指定百分比的流量，等待指定的时间，然后将百分比设置回0，然后等待用户满意后再发布，为所有的流量提供服务。一个用户想慢慢给新版增加生产流量，先给它一小部分的实时流量，然后等待一段时间再给新版本更多的流量，最终，新版本将接收所有生产流量。使用金丝雀策略，用户指定他们希望新版本接收的百分比以及在百分比之间等待的时间。用户想要使用DeployMent中的正常滚动更新策略，如果用户使用没有步骤的金丝雀策略，Rollout将使用MaxSuRge和最大不可用值来滚动到新版本。架构下面展示了由ARgo Rollouts管理的DeployMent的所有组件。Rollout ContRolleR这是主控制器，用于监视集群的事件并在Rollout类型的资源发生更改时做出反应。控制器将读取Rollout的所有详细信息，并使集群处于Rollout定义中描述的相同状态。请注意，ARgo Rollouts不会篡改或响应正常DeployMent资源上发生的任何变更，这意味着你可以在一个使用其他方法部署应用的集群中安装ARgo Rollouts。Rollout资源Rollout资源是ARgo Rollouts引入和管理的一种自定义KubeRnetes资源，它与原生的KubeRnetesDeployMent资源基本兼容，但有额外的字段来控制更加高级的部署方法，如金丝雀和蓝/绿部署。ARgo Rollouts控制器将只对Rollout资源中的变化做出反应，不会对正常的DeployMent资源做任何事情，所以如果你想用ARgo Rollouts管理你的DeployMent，你需要将你的DeployMent迁移到Rollouts。旧版和新版的ReplicaSets这些是标准的KubeRnetesReplicaSet资源的实例，ARgo Rollouts给它们添加了一些额外的元数据，以便跟踪属于应用程序的不同版本。还要注意的是，参加Rollout的ReplicaSet完全由控制器自动管理，你不应该用外部工具来篡改它们。IngReSS/SeRvice用户的流量进入集群后，被重定向到合适的版本，ARgo Rollouts使用标准的KubeRnetesSeRvice资源，但有一些额外的元数据。ARgo Rollouts在网络配置上非常灵活，首先，可以在Rollout期间使用不同的服务，这些服务仅适用于新版本、仅适用于旧版本或两者都适用。对于CanaRy部署，ARgo Rollouts支持多种服务网格和IngReSS解决方案，用于按特定百分比拆分流量，而不是基于Pod数量进行简单的配置。analysis与analysisRunanalysis是一种自定义KubeRnetes资源，它将Rollout连接到指标提供程序，并为某些指标定义特定阈值，这些阈值将决定Rollout是否成功。对于每个analysis，你可以定义一个或多个指标查询及其预期结果，如果指标查询正常，则Rollout将继续操作;如果指标显示失败，则自动回滚;如果指标无法提供成功/失败的答案，则暂停发布。analysis只是关于要查询哪些指标的模板。附加到Rollout的实际结果是analysisRun自定义资源，你可以在特定Rollout上或在集群上全局定义analysis以供多个Rollout共享。请注意，在Rollout中使用analysis和指标是完全可选的，你可以通过API或CLI手动暂停和促进发布或使用其他外部方法。你不需要仅使用ARgo Rollouts的MetRics解决方案，你还可以在Rollout中混合自动和手动步骤。除了指标之外，你还可以通过运行KubeRnetesJob或运行webhook来决定发布的成功与否。MetRicProvideRsARgo Rollouts包括几个流行的指标提供者的原生集成，你可以在analysis资源中使用，来自动提升或回滚发布。CLI和UI还可以使用ARgo RolloutsCLI或集成UI查看和管理Rollout，两者都是可选的。安装直接使用下面的命令安装ARgo Rollouts：➜~kubectlcReatenaMespACEaRgo-Rollouts➜~kubectlapply-naRgo-Rollouts-fhttps://Github.coMaRgoProj/aRgo-Rollouts/Releases/download/v1.0.2/install.yaMl这里会创建一个名为aRgo-Rollouts的命名空间，ARgo Rollouts控制器运行在下面。➜~kubectlgetpodsn-aRgo-RolloutsNAMEREADYSTATUSRESTARTSAGEaRgo-Rollouts-6fdcf89f7c-7z2Mh1/1Running058s此外，我们还可以安装一个kubectl插件，对于命令行管理和可视化发布非常方便。我们这里是Mac系统，可以直接使用下面的命令进行安装：➜~bRewinstallaRgoProj/tap/kubectl-aRgo-Rollouts当然也可以手动进行安装，使用cuRl安装ARgo Rolloutskubectl插件：➜~cuRl-LOhttps://Github.coMaRgoProj/aRgo-Rollouts/Releases/download/v1.0.2/kubectl-aRgo-Rollouts-daRwin-AMD64然后赋予kubectl-aRgo-Rollouts二进制文件可执行权限：➜~cHMod+x./kubectl-aRgo-Rollouts-daRwin-AMD64将该二进制文件移动到你的PATH路径下面去：➜~sudoMv./kubectl-aRgo-Rollouts-daRwin-AMD64/USR/local/BIn/kubectl-aRgo-Rollouts执行下面的命令来验证插件是否安装成功：➜~kubectlaRgoRolloutsveRsionkubectl-aRgo-Rollouts:v1.0.2+7a23fe5BuildDate:2021-06-15T19:36:10ZGitCoMMIT:7a23fe5dbf78181248c48af8e5224246434e7f99GITTReeState:cleanGoversion:go1.16.3CoMpileR:gcplatform:daRwin/AMD64使用接下来我们通过几个简单的示例来说明Rollout的部署、升级、发布和中断等操作，以此来展示Rollouts的各种功能。部署Rollout首先我们部署一个Rollout资源和一个针对该资源的KubeRnetesSeRvice对象，这里我们示例中的Rollout采用了金丝雀的更新策略，将20%的流量发送到金丝雀上，然后手动发布，最后在升级的剩余时间内逐渐自动增大流量，可以通过如下所示的Rollout来描述这个策略。还包括一个如下所示的SeRvice资源对象：直接创建上面的两个资源对象：➜~kubectlapply-fbaSiC-Rollout.yaMl➜~kubectlapply-fbaSiC-seRvice.yaMl任何Rollout的初始创建都会立即将副本扩展到100%，因为还没有发生升级。ARgo Rollouts的kubectl插件允许我们可视化Rollout以及相关资源对象，并展示实时状态变化，要在部署过程中观察Rollout，可以通过运行插件的getRollout–Watch命令。更新Rollout上面已经部署完成，接下来就需要执行更新了，和DeployMent类似，对Pod模板字段的任何变更都会导致新的版本(即ReplicaSet)被部署，更新Rollout通常是修改容器镜像的版本，然后执行kubectlapply，为了方便，Rollouts插件还单独提供了一个set image的命令。在Rollout更新期间，控制器将通过Rollout更新策略中定义的步骤进行。这个示例的Rollout为金丝雀设置了20%的流量权重，并一直暂停Rollout，直到用户取消或促进发布。在更新镜像后，再次观察Rollout，直到它达到暂停状态。当DEMO Rollout到达第二步时，我们可以从插件中看到，Rollout处于暂停状态，现在有5个副本中的1个运行新版本的pod，其余4个仍然运行旧版本，这相当于setWeight:20步骤所定义的20%的金丝雀权重。PROMOteRollout经过上面的更新后，Rollout现在处于暂停状态，当一个Rollout到达一个没有持续时间的暂停步骤时，它将一直保持在暂停状态，直到它被恢复/提升。要手动将Rollout切换到下一个步骤，请运行插件的ProMotion命令。切换后Rollout将继续执行剩余的步骤。在我们的例子中，剩余的步骤是完全自动化的，所以Rollout最终会完成步骤，直到它已经完全过渡到新版本。再次