Kubernetes面向通用场景提供了非常灵活的应用管理和运维方式，而作为云效CI/CD平台的开发同学，在日常和用户交流过程中，我们经常会被用户问到关于发布的问题，比如不同职能团队之间应该如何配合、发布的最佳实践应该是什么样子的等等。本文介绍Kubernetes下应用发布方式的选择，以及每种发布模式适合什么样的场景。
Kubernetes应用
首先我们来看看一般情况下Kubernetes是如何管理应用的。 Kubernetes通过声明式的API，并提供了一系列的资源来满足各种各样的应用运维场景：
从应用的角度我们会关注应用容器（Pod），应用配置（ConfigMap/Secret），应用需要持久化的信息（Volume），应用与应用之间的服务发现（Service），以及如何将应用服务暴露给集群外的用户（Ingress）等。
从集群运维的角度看，由于应用运行在集群中我们需要控制应用在集群中的权限（ServiceAccount/ClusterRole/Role）使得应用能够以最小所需权限原则在集群中运行，同时运维要管理和配置集群的存储资源（PV/PVC），同时对于资源有限的情况我们还需要管理和控制应用本身的资源暂用以及配额（quota）等。
而在实际场景中由于应用使用的框架（Dubbo/Spring Cloud）的不同，应用对外提供的服务场景不同（后端或者前端），不同的应用可能只需要关注其中的一小部分资源。
比如当您采用了像Spring Cloud或者Dubbo这类自带了服务发现的应用开发框架，您可能并不关心Kubernetes所提供的服务发现能力（Service），只需要通过Deployment来部署和管理这些应用实例。又比如说如果您采用了单独的配置管理中心，那ConfigMap/Secret这些可能也不会出现在您的Kubernetes资源清单中。
又比如说，如果是一个面向用户的前端应用，在应用部署时除了Deployment实例以外，您还要关心如何将这个服务暴露给外部用户，这时就需要相应的Ingress以及Service的资源来描述。
同时单个应用在整个系统中所处的位置不同又会导致我们对于发布的验证方式产生差异，比如一个后端微服务的发布，我们可能只需要确保发布过程系统不中断即可，而对于前端应用我们可能希望发布能够先在一小部分用户上进行验证，在线上流量充分测试后，再完成整个版本升级。
如上所示，对于应用而言采用的技术架构不同，提供的服务的方式不同，对发布验证方式要求的不同都会导致Kubernetes的使用上产生各种各样的差异，而云效为了能够支持这些不同的差异提供了多种多样的发布模式，接下来我们就来看看云效下常用的这些发布模式，以及这些发布模式所适用的场景。
最原生：YAML发布模式
顾名思义，这是我们在使用Kubernetes时最直接的应用部署方式，而在持续交付流水线中我们一般将这些用于描述Kubernetes资源的YAML文件通过Git进行统一版本管理，通过云效CI/CD平台监听代码库的变更事件，并通过流水线将这些YAML变更同步到集群当中。这种方式也被称为GitOps模式。
在云效当中，我们除了支持直接同步YAML到Kubernetes集群以外，还扩展了基本的模板能力。您可以通过在YAML文件中定义变量占位符如${IMAGE}，在流水线运行时通过Docker镜像构建或者阿里云镜像仓库触发器，动态产生要发布的镜像版本。
立即体验：云效流水线Flow
如下所示：
YAML发布支持任意资源类型，因此适用于如下场景：
开发自运维：团队充分理解和掌握Kubernetes原生的发布策略，希望通过YAML完成应用的升级与发布以及回滚，一般来说应用Git库会包含应用源码，Dockerfile以及部署应用所需的所有YAML文件（在某些情况下，YAML可能是由单独的Git仓库进行管理，以进行细粒度的权限控制）。
基础设施运维：运维团队通过Git管理集群的所有基础设施配置，并通过流水线完成集群的统一管理以及配置的同步。
更多详细使用介绍请参考：Kubernetes Kubectl 发布。
最简单：镜像升级
在和一些用户的交流场景中，也会有用户希望开发团队能够尽可能少的理解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版本中，当处于灰度状态时，流水线将会等待人工验证，以触发发布或者回滚操作。
该模式适用于：采用Ingress对外暴露应用服务，并且希望能够通过灰度的方式对发布进行验证。
关于如何在云效流水线中使用灰度发布请参考帮助文档：ACK Nginx Ingress 灰度发布。
内部流量可控：Istio/ASM灰度发布
而在微服务的场景中，并不是所有的服务都需要直接暴露给外部用户，如下所示：
当采用微服务架构，我们大部分的后端服务是只暴露于集群内，微服务之间通过Kubernetes Service进行相互访问，在这种情况下，当采用灰度发布模式时，我们需要在Service级别进行流量控制，以确保指定的流量才进入到灰度的链路而不对正常用户产生影响。
不过由于Kubernetes原生在Service级别并不支持任何的流量控制规则，因此我们需要在集群中部署Istio或者采用阿里云ServiceMesh来对服务之间的流量进行细粒度的控制。
如下图所示，当使用Kubernetes蓝绿发布模式时，可以设置灰度流量规则，从而只有当请求中包含指定的Cookie配置的请求转发到灰度版本当中：
该模式适用于：采用Istio或者阿里云ServiceMesh的Kubernetes用户，并且希望能够通过灰度的方式对发布进行验证。
更多使用介绍请参考：Kubernetes 蓝绿发布。