前言
Kubernetes作为非常流行的容器编排引擎已经逐渐成为容器交付的标准，为了解决标准化交付的问题，Kubernetes抽象了多种概念来代表不同的交付内容。
例如，不同应用场景的服务载体可以通过Deployment、DaemonSet、StatefulSet、CronJob来抽象；网络接入层可以通过Service进行抽象；服务配置可以通过ConfigMap或者Secret进行抽象等等。有了多种交付内容的抽象，开发者可以很简单将自身的应用交付进行拆分，变成多种抽象的组合，实现代码即交付。
分批发布
一个标准的应用可以抽象为网络、服务载体与存储，而一次应用的变更通常主要是针对服务载体进行的变更。但是如果我们只变更服务载体而操作网络会导致应用可能会出现服务中断等现象。为了解决上述的场景，我们通常会推荐使用不同的发布方式来解决，例如蓝绿发布解决零宕机发布的问题、金丝雀发布解决无差别快速验证的问题。
但是这些发布方式在Kubernetes中怎么使用呢？因为Kubernetes中抽象是非常原子的，而通常带有发布方式的变更过程需要组合服务载体和网络两种资源的变化。在标准的Kubernetes中是无法支持的，在开源社区中Helm或许是一个答案，而今天我们要给大家介绍一种更简单的方案，阿里云容器服务Kubernetes中的分批发布功能。（注意：目前仅支持1.9.3及以上的版本。）
分批发布顾名思义是通过分批的方式进行应用零宕机快速验证的方式。分批发布功能是基于Kubernetes中的CRD(CustomResourceDefinition)进行定义的，包含一个Service和一个StatefulSet，分批发布的过程同时操作了服务载体和网络，实现了应用的分批次发布、接入层快速变更、快速验证、发布继续、发布回滚、历史版本回滚等功能。
上图是一个分三批的分批发布流程，在发布时第一批次的Pod会进行新版本的变更，当第一批次的所有Pod都处在运行态的时候，service会进行流量的切换，将所有流量打到第一批次的Pod上面，进行快速验证，如果没有问题则继续发布，如果有问题可以立即进行回滚，整个过程无流量中断。
操作步骤
- 控制台选择左侧菜单中的
发布，右侧点击创建分批发布按钮。如果按钮是灰色的，可以参考升级连接进行升级。
- 填写相关配置
此时查看分批发布详情，可以看到4个nginx Pod已经都启动完毕，关联的服务也生成完毕，发布处在未开始状态。
- 接下点击右上角的
新建变更，来进行一次分批发布的变更
- 再次查看
分批发布详情，可以看到未开始中的Pod为2个，已完成的Pod为2个，表示分批发布第一个批次已完成。分批发布的整体状态处在 等待部署完成 (总共 2 个批次，当前处在第 1 个批次，当前批次状态为已完成)。
- 此时点击
继续按钮会发布下一个批次，如果点击回滚按钮，那么此时会回滚掉刚才的版本。当发布完成后。点击历史，可以进行历史版本的回滚。
总结
分批发布功能主要是为了解决快速无流量损失的验证，与蓝绿发布相比更节省资源，目前暂时只支持页面操作，后续会开放yaml文件编辑，支持更复杂的操作。
