Pod|技术周｜容器平台中业务容器更新的那些事_Sets|台中|版本|Replica|业

Part 1
引言
在业务容器化后业务的生命周期管理中，业务更新是比较重要的一块，尤其是互联网类型的业务，业务更新毕竟频发，可能几天就要发布一个版本。本文从Docker、Kubernetes、istio几个平台说起，逐步串联起关于业务容器更新中涉及到的发布技术，如滚动更新、蓝绿部署、灰度发布等。

文章图片

Part 2
Docker中的业务容器更新
根据容器化时间进程，企业最初使用的就是Docker 。 Docker中启动、停止一个容器非常简单，但其实Docker中是没有容器更新的机制的，只能使用最传统的“手工更新” ，也就是先停止旧的容器，再启动新的容器。但这个容器业务更新是有业务停机的时间的，这种只适合于不太重要的测试环境中，对于生产中的容器化业务是不适合的。
Part 3
Kubernetes中的业务容器更新
随时企业化容器里程的发展，容器编排中Kubernetes中在众多容器编排中胜出。本节主要描述Kubernetes中的业务容器化更新， Kubernetes中的业务容器更新方式解决了Docker中“手工更新”的弊端，可以实现业务“无缝”更新，这种更新名称为滚动更新(rolling update) ，可以实现滚动更新是由于Kubernetes中的Deployment和Replica Sets机制。实际上创建 Deployment 之后，也创建了ReplicaSet ，也就是说Deployment 管理着ReplicaSet ，之所以通过Deployment控制Replica Set的主要原因在于支持滚动更新。

文章图片

可以从下图看出Deployment配合Replica Sets的原理。当只有一个版本的时候Deployment只控制的一个Replica Sets ，当需要更新版本时Deployment会再增加一个Replica Sets,然后根据更新策略逐步更新成新的版本，到最后Deplyment只控制了新的Replica Sets 。

文章图片

下面是一个包括滚动更新策略的Depolyment配置文件， strategy部分中type:rollingUpdate表示更新策略为滚动更新，该策略的表示更新版本的过程是渐进性的，分多次进行，每次都只更新少数几个Pod ，直到所有Pod都更新完毕，就像上图中所示的。在rollingUpdate:部分有两个参数可以控制更新的过程：

maxUnavailable表示指定在升级时，最大不可用的pods的值。可以是一个绝对值数字，也可以是个百分比。例如，当这个值指定为30%时，最少可用的Pod为70% ，也就是说，在滚动升级的时候，会先杀掉30%旧的pod ，然后开始启动新pod 。当一个新的Pod被创建，一个旧的Pod就会被销毁。始终保持可用的pod在总量的70% ，直至升级完成。需要说明的是，当maxSurge为0时， maxUnavailable的值不能为0 。
maxSurge表示指定在升级时，最大可以创建多少个pod 。这个值可以是一个绝对值数字，也可以是个百分比。例如，当这个值指定为30%时，也就是说，新旧pod的总量不能超过130% 。简单来讲，就是在滚动升级时，会先启动30%的新的pod 。然后开始杀掉旧的pod ，每当一个旧的pod被杀掉，一个新的pod的会被启动，始终保持总量不超过130% ，直至更新完成。需要说明的是，当maxUnavailable为0时， maxSurge的值不能为0 。

文章图片

Kubernetes中的滚动更新解决了Docker中手动更新业务停机的问题，貌似完美了，但其实是还是有一些问题的。比如前文图中Deployment控制的Replica Sets中的两个版本， Deplyment是无法决定用户访问的是哪一个版本的应用，对于有些业务更新是希望一小部分用户可以访问新的V2版本应用，大部分用户访问旧的V1版本的应用，当小部分用户没有发现应用的BUG等问题，让所有用户都访问新的V2版本的应用（这就是灰度发布），其实滚动更新是做不到，之所有做不到也是由于工作原理导致的。下面我们来看一张图示：

文章图片

有些同学可能想到能不能在应用前面加个负载均衡，由负载均衡控制这个按比例分发流量，正好Kubernetes中POD一般是不提供直接访问的，都是通过Serivce访问POD ，是否可以解决这问题？其实是不能的， Service只能做到简单的负载均衡，也就是现只能两个版本的应用流量各自在 50% 左右。这也是Service机制决定的，在istio中引入了新的机制可以解决这个问题，详细见下一章节。
Part4
istio中的业务容器更新
除了上一章节中提到了滚动更新方式，其实istio中还有一种更新方式就是蓝绿部署。
蓝绿部署(Blue Green Deployment) ，是一种可以保证系统在不间断提供服务的情况下上线的部署方式。
所谓蓝绿部署，是指同时运行两个版本的应用，绿表示当前正在使用的应用，蓝表示将要更新的应用，用户访问的时候，只会让用户访问绿色的应用，此时蓝色的应用还未对外提供服务，还是内部测试阶段，如下图所示：

文章图片

在蓝色的应用测试的没有问题的时候，就需要切换到蓝色的应用了，切换后一段时间蓝色的应用没有问题之后才删除绿色的应用，如果蓝色的有问题，可以再切换回绿色的应用。

文章图片

以一个开源容器产品Kubesphere形像的说明一下蓝绿发布的过程。
可以看到Kubesphere支持蓝绿部署和灰度发布。

文章图片

以演示蓝绿发布为例子，取一个发布任务的名称。

文章图片

选择要实施蓝绿部署的容器业务。

文章图片

指定新的业务容器版本为V2 。

文章图片

选择切换到V2版本。

文章图片

查看蓝绿发布任务，可以看到现在V2版本接管了所有流量。

文章图片

当发现V2版本有问题时，可以让V1版本接管所有流量，就相当于回滚到了V1版本。

文章图片

上一章节中其实提到了灰度发布的场景，灰度发布国外叫金丝雀发布(Canary release) ，其实大致思路就是先让一小部分人访问新的版本(金丝雀版本) ，当这个版本没有问题再让所有人都访问新的版本，如下图所示：

文章图片

温馨提示：
金丝雀发布这个说法其实来自欧美，以前矿工开矿，在下矿洞时面临的一个重要危险就是矿井中的毒气，于是他们想到一个办法来辨别矿井中是否有毒气，矿工们下矿井时随身携带一只金丝雀(Canary) 。
由于金丝雀对毒气的抵抗能力比人类要弱，在毒气环境下会先挂掉起到预警的作用，类比到发布场景中就是由于小部分人充当金丝雀用户，发现新版本中的BUG之类的问题。
灰度发布的过程大致如下:
1.在实践灰度发布之前所有用户访问旧的版本，并在内部测试新的版本。

文章图片

2.觉的新的版本内部测试的差不多了，可以通过控制流量分发比较将如5%的流量分流到新的版本。

文章图片

3.如果新的版本没有没有问题，将100%的流量都分发到新的版本。

文章图片

【Pod|技术周｜容器平台中业务容器更新的那些事】之前提到了Kubernetes中的Service是实现不了按流量比例分发流量的，在istio中可以实现，能实现的原因是istio中引入了新的概念解决这个问题，不再使用Service ，如下图所示：

文章图片

istio中通过引入了VirtualService和DestinationRule解决了Kubernetes中Sevice不能实现灰度发布的问题，所以在istio中执行灰度发布就是修改VirtualService和DestinationRule的配置文件，由于直接看配置文件有些不直观以及介绍这两概念也不是本文章范畴，所以以一个开源容器产品Kubesphere形像的说明一下灰度发布的过程。

文章图片

以演示一个灰度发布为例，选择要发布的业务容器版本为V3 。