Kubernetes滚动升级

1. 滚动更新 Rolling-update

传统的升级更新，是先将服务全部下线，业务停止后再更新版本和配置，然后重新启动并提供服务。这样的模式已经完全不能满足“时代的需要”了。在并发化、高可用系统普及的今天，服务的升级更新至少要做到“业务不中断”。而滚动更新(Rolling-update)恰是满足这一需求的一种系统更新升级方案。

简单来说，滚动更新就是针对多实例服务的一种不中断服务的更新升级方式。一般情况，对于多实例服务，滚动更新采用对各个实例逐个进行单独更新而非同一时刻对所有实例进行全部更新的方式。“滚动更新”的先进之处在于“滚动”这个概念的引入，笔者觉得它至少有以下两点含义：

“滚动”给人一种“圆”的映像，表意：持续，不中断。“滚动”的理念是一种趋势，我们常见的“滚动发布”、“持续交付”都是“滚动”理念的应用。与传统的大版本周期性发布/更新相比，”滚动”可以让用户更快、更及时地使用上新Feature，缩短市场反馈周期，同时滚动式的发布和更新又会将对用户体验的影响降到最小化。
“滚动”可向前，也可向后。我们可以在更新过程中及时发现“更新”存在的问题，并“向后滚动”，实现更新的回退，可以最大程度上降低每次更新升级的风险。

对于在Kubernetes集群部署的Service来说，Rolling update就是指一次仅更新一个Pod，并逐个进行更新，而不是在同一时刻将该Service下面的所有Pod shutdown，避免将业务中断的尴尬。

2、Service、Deployment、Replica Set、Replication Controllers和Pod之间的关系

对于我们要部署的Application来说，一般是由多个抽象的Service组成。在Kubernetes中，一个Service通过label selector匹配出一个Pods集合，这些Pods作为Service的endpoint，是真正承载业务的实体。而Pod在集群内的部署、调度、副本数保持则是通过Deployment或ReplicationControllers这些高level的抽象来管理的，下面是一幅示意图：

screenshot

新版本的Kubernetes推荐用Deployment替代ReplicationController，在Deployment这个概念下在保持Pod副本数上实际发挥作用的是隐藏在背后的Replica Set。

因此，我们可以看到Kubernetes上Service的rolling update实质上是对Service所匹配出来的Pod集合的Rolling update，而控制Pod部署、调度和副本调度的却又恰恰是Deployment和replication controller，因此后两者才是kubernetes service rolling update真正要面对的实体。

使用`kubectl rolling-update`更新

使用kubectl rolling-update命令的方式，主要是针对使用RC创建的pods。

先来看下面一个示例，创建一个包含4个nginx副本的RC nginx-demo-v1-rc.yml：

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-demo-v1
spec:
  replicas: 4
  selector:
    app: nginx-demo
    ver: v1
  template:
    metadata:
      labels:
        app: nginx-demo
        ver: v1
    spec:
      containers:
        - name: nginx-demo
          image: nginx:1.10.1
          ports:
            - containerPort: 80
              protocol: TCP
          env:
            - name: NGX_DEMO_VER
              value: v1

创建一个service，nginx-demo-svc.yml内容如下：

apiVersion: v1
kind: Service
metadata:
  name: nginx-demo-svc
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: nginx-demo

创建rc和service：

kubectl create -f nginx-demo-v1-rc.yml
kubectl create -f nginx-demo-svc.yml

创建完成以后，可以通过访问任一Pod的环境变量查看NGX_DEMO_VER的值，为v1

现在我们创建一个nginx-demo-v2-rc.yml的文件，来升级现有的pod：

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-demo-v2
spec:
  replicas: 4
  selector:
    app: nginx-demo
    ver: v2
  template:
    metadata:
      labels:
        app: nginx-demo
        ver: v2
    spec:
      containers:
        - name: nginx-demo
          image: nginx:1.11.9
          ports:
            - containerPort: 80
              protocol: TCP
          env:
            - name: NGX_DEMO_VER
              value: v2

执行更新操作：

kubectl rolling-update nginx-demo-svc -f nginx-demo-v2-rc.yml

需要注意的是，在执行滚动升级时，两个版本的yml文件区别：

RC的名字不能与旧的RC名字相同
在selector中应至少有一个label与旧的RC的label不同，以标识其为新的RC。

我们可以通过如下操作来查看更新的完整过程：

kubectl rolling-update nginx-demo-v1 --udpate-period=10s -f nginx-demo-v2-rc.yml

当所有旧的pod被新的Pod替换完成以后，更新完成。

使用kubectl rolling-update实现滚动更新的不足：

rolling-update的逻辑是由kubectl发出N条命令到APIServer完成的，很可能因为网络原因导致update中断
需要创建一个新的rc，名字与要更新的rc不能一样
回滚还需要执行rolling-update，只是用老的版本替换新的版本
service执行的rolling-update在集群中没有记录，后续无法跟踪rolling-update历史

现如今，RC的方式已经被Deployment替代。

Deployment 的`rolling-update`

kubernetes的Deployment是一个更高级别的抽象。Deployment会创建一个Replica Set，用来保证Deployment中的Pod的副本数。要rolling-update deployment中的Pod，只需要修改Deployment自己的yml文件并应用即可。这个修改会创建一个新的Replica Set，在增加这个新RS的pod数的同时，减少旧RS的pod，直至完全升级。而这一切都发生在Server端，并不需要kubectl参与。

创建一个Deployment yml文件nginx-demo-dm.yml：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx-demo
  minReadySeconds: 10
  template:
    metadata:
      labels:
        app: nginx-demo
        version: v1
    spec:
      containers:
        - name: deployment-demo
          image: nginx:1.10.1
          ports:
            - containerPort: 80
              protocol: TCP

创建该deployment：

kubect create -f nginx-demo-dm.yml --record

然后我们可以直接修改该deployment文件，如下：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx-demo
  minReadySeconds: 10
  template:
    metadata:
      labels:
        app: nginx-demo
        version: v2
    spec:
      containers:
        - name: deployment-demo
          image: nginx:1.11.9
          ports:
            - containerPort: 80
              protocol: TCP

一共就改了两个地方，将version改为了v2，将nginx镜像从1.10.1改到了1.11.9，执行如下操作应用更改：

kubectl apply -f nginx-demo-dm.yml --record

这个时候，我们可以通过执行kubectl get rs来查看到rs的变化，以确认是否在执行升级。也可以通过kubectl describe deployment nginx-demo来查看详细的rolling-update的过程。还可以通过kubectl rollout status deployment/nginx-demo来查看更新状态。

除了使用apply方式来应用更改以外，还有另外一种方式可以直接升级。就是通过kubectl edit nginx-demo-dm.yml来编辑deployment文件，保存以后，不需要执行apply，就会自动完成升级。

我们可以注意到，在执行deployment的操作时，使用了一个--record参数，这个参数是用来告诉apiserver记录update的历史。可以通过如下命令来查看update历史：

kubectl rollout history deployment nginx-demo

查看指定revision的详细信息：

kubectl rollout history deployment hello-deployment --revision=2

需要说明的是，在升级完成以后，旧的RS也不会被删除，这些信息都会存储到server端，以方便回滚。

deployment下的pod的回滚操作相当简单，直接执行rollout undo即可将deployment回滚到record中记录的上一个revision：

kubectl rollout undo deployment nginx-demo

执行如下操作，回滚到指定版本：

kubectl rollout undo deployment hello-deployment --to-version=2

Kubernetes滚动升级

1. 滚动更新 Rolling-update

2、Service、Deployment、Replica Set、Replication Controllers和Pod之间的关系

使用kubectl rolling-update更新

Deployment 的rolling-update

昵称

使用`kubectl rolling-update`更新

Deployment 的`rolling-update`