聊聊你可能误解的Kubernetes Deployment滚动更新机制

Author: xidianwangtao@gmail.com

摘要： Kubernetes Deployment滚动更新机制不同于ReplicationController rolling update，Deployment rollout还提供了滚动进度查询，滚动历史记录，回滚等能力，无疑是使用Kubernetes进行应用滚动发布的首选。本博文，将带你聊聊那些容易被大家忽略或者误解的特性。

定义Deployment时与rolling update的相关项

以下面的frontend Deployment为例，重点关注.spec.minReadySeconds,.spec.strategy.rollingUpdate.maxSurge,.spec.strategy.rollingUpdate. maxUnavailable。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: frontend
spec:
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3
      maxUnavailable: 2
  replicas: 25
  template:
    metadata:
      labels:
        app: guestbook
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google-samples/gb-frontend:v4
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        env:
        - name: GET_HOSTS_FROM
          value: dns
          # If your cluster config does not include a dns service, then to
          # instead access environment variables to find service host
          # info, comment out the 'value: dns' line above, and uncomment the
          # line below:
          # value: env
        ports:
        - containerPort: 80

• .spec.minReadySeconds: 新创建的Pod状态为Ready持续的时间至少为.spec.minReadySeconds才认为Pod Available(Ready)。
• .spec.strategy.rollingUpdate.maxSurge: specifies the maximum number of Pods that can be created over the desired number of Pods. The value cannot be 0 if MaxUnavailable is 0. 可以为整数或者百分比，默认为desired Pods数的25%. Scale Up新的ReplicaSet时，按照比例计算出允许的MaxSurge，计算时向上取整(比如3.4，取4)。
• .spec.strategy.rollingUpdate.maxUnavailable: specifies the maximum number of Pods that can be unavailable during the update process. The value cannot be 0 if maxSurge is 0.可以为整数或者百分比，默认为desired Pods数的25%. Scale Down旧的ReplicaSet时，按照比例计算出允许的maxUnavailable，计算时向下取整(比如3.6，取3)。

因此，在Deployment rollout时，需要保证Available(Ready) Pods数不低于 desired pods number - maxUnavailable; 保证所有的Pods数不多于 desired pods number + maxSurge。

滚动更新的流程

Note: A Deployment’s rollout is triggered if and only if the Deployment’s pod template (that is, .spec.template) is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.

我们继续以上面的Deployment为例子，并考虑最常用的情况–更新image（发布新版本）:

kubectl set image deploy frontend php-redis=gcr.io/google-samples/gb-frontend:v3 --record

set image之后，导致Deployment’s Pod Template发生变化，就会触发rollout。我们只考虑RollingUpdate策略（Kubernetes还支持ReCreate更新策略）。通过kubectl get rs -w来watch ReplicaSet的变化。

[root@master03 ~]# kubectl get rs -w
NAME                  DESIRED   CURRENT   READY     AGE
frontend-3114648124   25        25        25        14m
frontend-3099797709   0         0         0         1h
frontend-3099797709   0         0         0         1h
frontend-3099797709   3         0         0         1h
frontend-3114648124   23        25        25        17m
frontend-3099797709   5         0         0         1h
frontend-3114648124   23        25        25        17m
frontend-3114648124   23        23        23        17m
frontend-3099797709   5         0         0         1h
frontend-3099797709   5         3         0         1h
frontend-3099797709   5         5         0         1h
frontend-3099797709   5         5         1         1h
frontend-3114648124   22        23        23        17m
frontend-3099797709   5         5         2         1h
frontend-3114648124   22        23        23        17m
frontend-3114648124   22        22        22        17m
frontend-3099797709   6         5         2         1h
frontend-3114648124   21