阿里云云效技术专家:一文详解kubernetes下5种常见发布模式如何选择

简介: Kubernetes下5场场景应用发布方式的选择,每种发布模式适合什么样的场景,以及如何在阿里云云效上高效落地。

作者:郑云龙,阿里云云效技术专家

Kubernetes面向通用场景提供了非常灵活的应用管理和运维方式,而作为云效CI/CD平台的开发同学,在日常和用户交流过程中,我们经常会被用户问到关于发布的问题,比如不同职能团队之间应该如何配合、发布的最佳实践应该是什么样子的等等。

今天我们就来聊聊Kubernetes下应用发布方式的选择,每种发布模式适合什么样的场景,以及如何在云效上高效落地。

Kubernetes应用

首先我们来看看一般情况下Kubernetes是如何管理应用的。 Kubernetes通过声明式的API,并提供了一系列的资源来满足各种各样的应用运维场景:

• 从应用的角度我们会关注应用容器(Pod),应用配置(ConfigMap/Secret),应用需要持久化的信息(Volume),应用与应用之间的服务发现(Service),以及如何将应用服务暴露给集群外的用户(Ingress)等。

• 从集群运维的角度看,由于应用运行在集群中我们需要控制应用在集群中的权限(ServiceAccount/ClusterRole/Role)使得应用能够以最小所需权限原则在集群中运行,同时运维要管理和配置集群的存储资源(PV/PVC),同时对于资源有限的情况我们还需要管理和控制应用本身的资源暂用以及配额(quata)等等等。

1.png

而在实际场景中由于应用使用的框架(Dubbo/Spring Cloud)的不同,应用对外提供的服务场景不同(后端或者前端),不同的应用可能只需要关注其中的一小部分资源
比如当你采用了像Spring Cloud或者Dubbo这类自带了服务发现的应用开发框架,你可能并不关心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镜像构建或者阿里云镜像仓库触发器(帮助文档:阿里云镜像仓库触发器触发流水线),动态产生要发布的镜像版本

如下所示:

2.png

YAML发布支持任意资源类型,因此适用于如下场景:

1、开发自运维,团队并充分理解和掌握Kubernetes原生的发布策略,希望通过YAML完成应用的升级与发布以及回滚,一般来说应用Git库会包含应用源码,Dockerfile以及部署应用所需的所有YAML文件(在某些情况下,YAML可能是由单独的Git仓库进行管理,以进行细粒度的权限控制)。

2、基础设施运维:运维团队通过Git管理集群的所有基础设施配置,并通过流水线完成集群的统一管理以及配置的同步

更多详细使用介绍请参考:云效Kubernetes YAML发布

**最简单:镜像升级
**

3.png

在和一些云效用户的交流场景中,在也会有用户希望开发团队能够尽可能少的理解Kubernetes相关概念,在这种情况下由专职的运维团队负责完成应用环境的部署和初始化。而开发团队只负责完成代码开发,并通过流水线自动化完成应用镜像构建,并使用该镜像对集群中已有的应用进行升级。开发团队只关心应用的工作负载实例资源。

如下图所示,在云效流水线中我们监听应用代码库的变化,并构建出相应的Docker镜像,而发布阶段只需要指定对集群中实例并关联前序任务产生的镜像即可完成应用的升级发布:
4.png

如上所述,该场景适用于:

• 开发和运维分离:运维团队充分理解Kubernetes的原生发布策略,开发团队只负责产出代码以及应用镜像,由运维团队负责集群中应用的实际运维管理。

关于如何在云效中使用镜像升级能力,请参考:云效Kubernetes镜像升级

过程可控:分批发布

在前面两个小结中,我们都强调用户需要充分理解Kubernetes的原生发布策略,Kubernetes原生的发布策略主要是指RollingUpdate模式,用户通过声明升级策略,如maxSurge和maxUnavailable控制Pod的启动策略以及最大不可用Pod数,来确保即使应用发布出现异常的情况,也能保证服务的基本可用。

5.png

除此,由于应用启动往往有一定的耗时,如果使用了Kubernetes的服务发现机制,我们还需要配置如liveness以及readiness探针,来避免应用还在启动过程中就有不在计划内的流量进入到正在启动的实例当中。同时整个发布过程是不可逆的,假如认定当前发布出现了异常我们只能通过重新发布的方式来使应用回到可用状态。

6.png

而在云效的分批发布中,我们以Service为最小发布单元,在发布开始阶段我们将基于新版镜像创建出应用的版本V2,并根据当前应用的副本总数以及分批数量,对新旧两个版本的应用实例分别进行缩容和扩容,来控制实际进入到新版应用的流量比例,从而可以实现小规模的发布验证,在对发布进行充分验证后再逐步完全下线老版应用。

同时批次之间支持暂停和手动恢复让用户可以充分对针对发布过程进行控制。

7.png

该模式适用于:采用Kubernetes原生的服务发现机制,并希望获得相比于原生Kubernetes发布更好过程控制性以及安全性的用户。

更多详细使用介绍,请参考帮助文档:云效Kubernetes分批发布

外部流量可控:Ingress灰度发布

相比于分批发布灰度发布更强调更加可控和安全的线上验证。而灰度发布在Kubernetes中由于应用的部署模式的不同大致分为两种,我们首先来说第一种,基于Ingress的灰度发布,如下所示,我们通过Ingress将集群内的服务暴露给外部用户:

8.png

在发布过程中我们希望能够通过cookie或者header的方式使得特定的用户或者开发人员,能够在线上对新版本引用进行验证,经过小部分可控的线上流量验证后,我们的发布可靠性更好,如果出现预期外的问题,也可以快速回滚,并且整个灰度验证过程对非灰度用户完全不可感知。

9.png

云效流水线的Ingress灰度发布中,我们以Ingress作为发布单元,当触发部署后,将会根据当前Ingress以及其关联的Service/Deployment资源,基于新版镜像创建出V2版本的Service/Deployment。 并通过Nginx Ingress的Annoation完成对流量规则声明,从而确保只有满足特定特征的流量才能进入到V2版本中,当处于灰度状态时,流水线将会等待人工验证,以触发发布或者或者回滚操作。

10.png

关于如何在云效流水线中使用灰度发布请参考帮助文档:云效Nginx Ingress灰度发布

该模式适用于:采用Ingress对外暴露应用服务,并且希望能够通过灰度的方式对发布进行验证

内部流量可控:Istio/ASM灰度发布

而在微服务的场景中,并不是所有的服务都需要直接暴露给外部用户,如下所示:

11.png

当采用微服务架构,我们大部分的后端服务是只暴露与集群内,微服务之间通过Kubernetes Service进行相互访问,在这种情况下,当采用灰度发布模式时,我们需要在Service级别进行流量控制,已确保指定的流量才进入到灰度的链路而不对正常用户产生影响。

12.png

不过由于Kubernetes原生在Service级别并不支持任何的流量控制规则,因此我们需要在集群中部署Istio或者采用阿里云ServiceMesh来对服务之间的流量进行细粒度的控制。
13.png

如下图所示,当使用Kubernetes蓝绿发布模式时,可以设置灰度流量规则,从而只有当请求中包含指定的Cookie配置的请求转发到灰度版本当中:

14.png

该模式适用于:采用Istio或者阿里云ServiceMesh的Kubernetes用户,并且希望能够通过灰度的方式对发布进行验证。

更多使用介绍请参考:云效Kubernetes灰度发布

小结

在本文中,我们主要介绍了Kubernetes实际中的各种发布模式以及相关的适用场景,希望能够帮助用户快速找到适合自己的发布模式,当然如果你还有更多更好的交付实践,也可以在留言中进行分享。

如果你对云效流水线感兴趣,前往 云效流水线 即可免费使用。

目录
相关文章
|
6天前
|
弹性计算 人工智能 Serverless
阿里云ACK One:注册集群云上节点池(CPU/GPU)自动弹性伸缩,助力企业业务高效扩展
在当今数字化时代,企业业务的快速增长对IT基础设施提出了更高要求。然而,传统IDC数据中心却在业务存在扩容慢、缩容难等问题。为此,阿里云推出ACK One注册集群架构,通过云上节点池(CPU/GPU)自动弹性伸缩等特性,为企业带来全新突破。
|
22天前
|
专有云 Serverless 持续交付
亚太唯一,阿里云再度入选Gartner®容器管理魔力象限领导者
Gartner正式发布 2024《容器管理魔力象限》报告,阿里云再度成为中国唯一一家入选「领导者象限」的科技公司。
|
11天前
|
Kubernetes Cloud Native 开发者
云原生技术入门:Kubernetes和Docker的协作之旅
【10月更文挑战第22天】在数字化转型的浪潮中,云原生技术成为推动企业创新的重要力量。本文旨在通过浅显易懂的语言,引领读者步入云原生的世界,着重介绍Kubernetes和Docker如何携手打造弹性、可扩展的云环境。我们将从基础概念入手,逐步深入到它们在实际场景中的应用,以及如何简化部署和管理过程。文章不仅为初学者提供入门指南,还为有一定基础的开发者提供实践参考,共同探索云原生技术的无限可能。
21 3
|
18天前
|
人工智能 专有云 Serverless
亚太唯一!阿里云再度入选Gartner®容器管理魔力象限领导者
亚太唯一!阿里云再度入选Gartner®容器管理魔力象限领导者
92 2
|
2月前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
3年前的云栖大会,我们发布分布式云容器平台ACK One,随着3年的发展,很高兴看到ACK One在混合云,分布式云领域帮助到越来越多的客户,今天给大家汇报下ACK One 3年来的发展演进,以及如何帮助客户解决分布式领域多云多集群管理的挑战。
阿里云容器服务 ACK One 分布式云容器企业落地实践
|
1月前
|
Kubernetes Cloud Native 云计算
云原生时代的技术演进:Kubernetes与微服务架构的完美融合
随着云计算技术的飞速发展,云原生概念逐渐深入人心。本文将深入探讨云原生技术的核心——Kubernetes,以及它如何与微服务架构相结合,共同推动现代软件架构的创新与发展。文章不仅剖析了Kubernetes的基本工作原理,还通过实际案例展示了其在微服务部署和管理中的应用,为读者提供了一条清晰的云原生技术应用路径。
62 2
|
1月前
|
运维 Kubernetes Cloud Native
云原生技术入门:Kubernetes的奇妙之旅
【9月更文挑战第34天】在数字化浪潮中,云原生技术如Kubernetes已经成为IT行业的重要力量。本文旨在通过浅显易懂的方式,向初学者揭示Kubernetes的核心概念、架构设计及其在实际业务中的应用价值,帮助读者快速理解并掌握这一技术,为进一步深入学习和实践打下坚实基础。
51 1
|
2月前
|
存储 Kubernetes 关系型数据库
阿里云ACK备份中心,K8s集群业务应用数据的一站式灾备方案
阿里云ACK备份中心,K8s集群业务应用数据的一站式灾备方案
|
2月前
|
人工智能 运维 监控
阿里云ACK容器服务生产级可观测体系建设实践
阿里云ACK容器服务生产级可观测体系建设实践
|
2月前
|
Cloud Native 持续交付 Docker
云原生技术入门与实践:Docker容器化部署示例
【9月更文挑战第25天】在数字化转型的浪潮下,云原生技术成为推动企业创新的重要力量。本文旨在通过浅显易懂的语言,为初学者揭示云原生技术的核心概念及其应用价值。我们将以Docker容器为例,逐步引导读者了解如何将应用程序容器化,并在云端高效运行。这不仅是对技术趋势的跟随,更是对资源利用和开发效率提升的探索。
60 4