微网站 获取手机号,网站广告调词平台,php wordpress乱码,长沙市建设网站简介#xff1a; Kubernetes下5场场景应用发布方式的选择#xff0c;每种发布模式适合什么样的场景#xff0c;以及如何在阿里云云效上高效落地。
作者#xff1a;郑云龙#xff0c;阿里云云效技术专家
Kubernetes面向通用场景提供了非常灵活的应用管理和运维方式#…简介 Kubernetes下5场场景应用发布方式的选择每种发布模式适合什么样的场景以及如何在阿里云云效上高效落地。
作者郑云龙阿里云云效技术专家
Kubernetes面向通用场景提供了非常灵活的应用管理和运维方式而作为云效CI/CD平台的开发同学在日常和用户交流过程中我们经常会被用户问到关于发布的问题比如不同职能团队之间应该如何配合、发布的最佳实践应该是什么样子的等等。
今天我们就来聊聊Kubernetes下应用发布方式的选择每种发布模式适合什么样的场景以及如何在云效上高效落地。
Kubernetes应用
首先我们来看看一般情况下Kubernetes是如何管理应用的。 Kubernetes通过声明式的API并提供了一系列的资源来满足各种各样的应用运维场景
• 从应用的角度我们会关注应用容器Pod应用配置ConfigMap/Secret应用需要持久化的信息Volume应用与应用之间的服务发现Service以及如何将应用服务暴露给集群外的用户Ingress等。
• 从集群运维的角度看由于应用运行在集群中我们需要控制应用在集群中的权限ServiceAccount/ClusterRole/Role使得应用能够以最小所需权限原则在集群中运行同时运维要管理和配置集群的存储资源(PV/PVC)同时对于资源有限的情况我们还需要管理和控制应用本身的资源暂用以及配额quata等等等。 而在实际场景中由于应用使用的框架Doubbo/Spring Cloud的不同应用对外提供的服务场景不同后端或者前端不同的应用可能只需要关注其中的一小部分资源 比如当你采用了像Spring Cloud或者Doubbo这类自带了服务发现的应用开发框架你可能并不关心Kubernetes所提供的服务发现能力(Service)只需要通过Deployment来部署和管理这些应用实例。 又比如说如果你采用了单独的配置管理中心那ConfigMap/Secret这些可能也不会出现在你的Kubernetes资源清单中。 又比如说如果是一个面向用户前端应用在应用部署是除了Deployment实例以外你还要关系如何将这个服务暴露给外部用户这是就需要相应的Ingress以及Service的资源来描述。
同时在单个应用在整个系统中所处的位置不同又会导致我们对于发布的验证方式也会产生差异比如一个后端微服务的发布我们可能只需要确保发布过程系统不中断即可而对于前端应用我们可能希望发布能够现在一小部分用户上进行验证在线上流量充分测试后再完成整个版本升级。
如上所示对于应用而言采用的技术架构不同提供的服务的方式不同对发布验证方式要求的不同都会导致Kubernetes的使用上产生各种各样的差异而云效为了能够支持这些不同的差异提供了多种多样的发布模式接下来我们就来看看云效下常用的这些发布模式以及他们所适用的场景。
Kubernetes发布模式
最原生YAML发布
顾名思义这是我们在使用Kubernetes时最直接的应用部署方式而在持续交付流水线中我们一般将这些用于描述Kubernetes资源的YAML文件通过Git进行统一版本管理通过云效CI/CD平台监听代码库的变更事件并通过流水线将这些YAML变更同步到集群当中。这种方式也被称为GitOps模式。
在云效当中我们除了支持直接同步YAML到Kubernetes集群以外还扩展了基本的模板能力你可以通过在YAML文件中定义变量占位符如${IMAGE}通过流水线运行是通过Docker镜像构建或者阿里云镜像仓库触发器帮助文档阿里云镜像仓库触发器触发流水线动态产生要发布的镜像版本
如下所示 YAML发布支持任意资源类型因此适用于如下场景
1、开发自运维团队并充分理解和掌握Kubernetes原生的发布策略希望通过YAML完成应用的升级与发布以及回滚一般来说应用Git库会包含应用源码Dockerfile以及部署应用所需的所有YAML文件在某些情况下YAML可能是由单独的Git仓库进行管理以进行细粒度的权限控制。
2、基础设施运维运维团队通过Git管理集群的所有基础设施配置并通过流水线完成集群的统一管理以及配置的同步
更多详细使用介绍请参考云效Kubernetes YAML发布
最简单镜像升级 在和一些云效用户的交流场景中在也会有用户希望开发团队能够尽可能少的理解Kubernetes相关概念在这种情况下由专职的运维团队负责完成应用环境的部署和初始化。而开发团队只负责完成代码开发并通过流水线自动化完成应用镜像构建并使用该镜像对集群中已有的应用进行升级。开发团队只关心应用的工作负载实例资源。
如下图所示在云效流水线中我们监听应用代码库的变化并构建出相应的Docker镜像而发布阶段只需要指定对集群中实例并关联前序任务产生的镜像即可完成应用的升级发布
如上所述该场景适用于
• 开发和运维分离运维团队充分理解Kubernetes的原生发布策略开发团队只负责产出代码以及应用镜像由运维团队负责集群中应用的实际运维管理。
关于如何在云效中使用镜像升级能力请参考云效Kubernetes镜像升级
过程可控分批发布
在前面两个小结中我们都强调用户需要充分理解Kubernetes的原生发布策略Kubernetes原生的发布策略主要是指RollingUpdate模式用户通过声明升级策略如maxSurge和maxUnavailable控制Pod的启动策略以及最大不可用Pod数来确保即使应用发布出现异常的情况也能保证服务的基本可用。 除此由于应用启动往往有一定的耗时如果使用了Kubernetes的服务发现机制我们还需要配置如liveness以及readiness探针来避免应用还在启动过程中就有不在计划内的流量进入到正在启动的实例当中。同时整个发布过程是不可逆的假如认定当前发布出现了异常我们只能通过重新发布的方式来使应用回到可用状态。 而在云效的分批发布中我们以Service为最小发布单元在发布开始阶段我们将基于新版镜像创建出应用的版本V2并根据当前应用的副本总数以及分批数量对新旧两个版本的应用实例分别进行缩容和扩容来控制实际进入到新版应用的流量比例从而可以实现小规模的发布验证在对发布进行充分验证后再逐步完全下线老版应用。
同时批次之间支持暂停和手动恢复让用户可以充分对针对发布过程进行控制。 该模式适用于采用Kubernetes原生的服务发现机制并希望获得相比于原生Kubernetes发布更好过程控制性以及安全性的用户。
更多详细使用介绍请参考帮助文档云效Kubernetes分批发布
外部流量可控Ingress灰度发布
相比于分批发布灰度发布更强调更加可控和安全的线上验证。而灰度发布在Kubernetes中由于应用的部署模式的不同大致分为两种我们首先来说第一种基于Ingress的灰度发布如下所示我们通过Ingress将集群内的服务暴露给外部用户 在发布过程中我们希望能够通过cookie或者header的方式使得特定的用户或者开发人员能够在线上对新版本引用进行验证经过小部分可控的线上流量验证后我们的发布可靠性更好如果出现预期外的问题也可以快速回滚并且整个灰度验证过程对非灰度用户完全不可感知。 在云效流水线的Ingress灰度发布中我们以Ingress作为发布单元当触发部署后将会根据当前Ingress以及其关联的Service/Deployment资源基于新版镜像创建出V2版本的Service/Deployment。 并通过Nginx Ingress的Annoation完成对流量规则声明从而确保只有满足特定特征的流量才能进入到V2版本中当处于灰度状态时流水线将会等待人工验证以触发发布或者或者回滚操作。 关于如何在云效流水线中使用灰度发布请参考帮助文档云效Nginx Ingress灰度发布
该模式适用于采用Ingress对外暴露应用服务并且希望能够通过灰度的方式对发布进行验证
内部流量可控Istio/ASM灰度发布
而在微服务的场景中并不是所有的服务都需要直接暴露给外部用户如下所示 当采用微服务架构我们大部分的后端服务是只暴露与集群内微服务之间通过Kubernetes Service进行相互访问在这种情况下当采用灰度发布模式时我们需要在Service级别进行流量控制已确保指定的流量才进入到灰度的链路而不对正常用户产生影响。 不过由于Kubernetes原生在Service级别并不支持任何的流量控制规则因此我们需要在集群中部署Istio或者采用阿里云ServiceMesh来对服务之间的流量进行细粒度的控制。
如下图所示当使用Kubernetes蓝绿发布模式时可以设置灰度流量规则从而只有当请求中包含指定的Cookie配置的请求转发到灰度版本当中 该模式适用于采用Istio或者阿里云ServiceMesh的Kubernetes用户并且希望能够通过灰度的方式对发布进行验证。
小结
在本文中我们主要介绍了Kubernetes实际中的各种发布模式以及相关的适用场景希望能够帮助用户快速找到适合自己的发布模式当然如果你还有更多更好的交付实践也可以在留言中进行分享。
原文链接
本文为阿里云原创内容未经允许不得转载。
