4.4.1　Kubernetes中的灰度发布

Kubernetes自带的rolling-update（滚动升级）功能提供了一种渐进式的更新方法，可以实现在不中断业务的情况下进行应用升级。下面简要回顾一下Kubernetes的升级策略：

spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 2
  minReadySeconds: 5

上述代码定义了一些关键值，如下所示：

·maxSurge：升级过程中最多可以比原先设定多出的pod数量，此值可以为固定值或是比例（%）。例如：maxSurge：1、replicas：5，代表Kubernetes会先开好1个新pod后才删掉一个旧的pod，整个升级过程中最多会有5+1个pod。

·maxUnavailable：最多可以有几个pod处在无法服务的状态，当maxSurge不为零时，此值亦不可为零。例如.maxUnavailable：1，代表Kubernetes整个升级过程中最多会有1个pod处在无法服务的状态。

·minReadySeconds：容器内应用启动时间，Kubernetes会等待设定的时间后才继续进行升级流程，如果没有此值的话，Kubernetes会假设该容器一开完后即可进行服务。

实现滚动升级的方式也有以下几种：kubectl set image、kubectl replace、kubectl rollout。

尽管这种机制能够很好地工作，但只适用于部署的经过适当测试的版本，也就是说，更多适用于蓝/绿发布场景。实际上，Kubernetes中的金丝雀发布将使用具有相同Label的两个部署来完成。在这种情况下，我们不能再使用AutoScaler，因为有由两个独立的AutoScaler来进行控制，不同负载情况下，replicas比例（百分比）可能与所需的比例不同。

无论我们使用一个还是两个部署，使用Kubernetes进行的金丝雀发布都存在一个根本问题：使用实例扩容来管理流量；这是因为版本流量分发和部署在Kubernetes平台中的副本并非独立。所有pod副本，无论版本如何，在kube-proxy循环池中都被相同对待，因此管理特定版本接收的流量的唯一方法是控制副本比例。以小百分比例的金丝雀流量需要许多副本（例如1%将需要至少100个副本）。即使我们可以忽略这个问题，部署方式功能仍然非常有限，因为它只支持简单（随机百分比）金丝雀部署。如果想根据某些特定规则将请求路由到金丝雀版本上，仍然需要另一种解决方案。这就需要用到Istio。