【K8S】 Deployment滚动升级机制

前言

很久之前官方就已经推荐使用Deployment代替Replication Controller(rc)了，Deployment继承了rc的全部功能外，还可以查看升级详细进度和状态，当升级出现问题的时候，可以使用回滚操作回滚到指定的版本，每一次对Deployment的操作，都会保存下来，变能方便的进行回滚操作了，另外对于每一次升级都可以随时暂停和启动，拥有多种升级方案：Recreate删除现在的Pod，重新创建；RollingUpdate滚动升级，逐步替换现有Pod，对于生产环境的服务升级，显然这是一种最好的方式。

创建Deployment

可以看出一个Deployment拥有多个Replica Set，而一个Replica Set拥有一个或多个Pod。一个Deployment控制多个rs主要是为了支持回滚机制，每当Deployment操作时，Kubernetes会重新生成一个Replica Set并保留，以后有需要的话就可以回滚至之前的状态。下面创建一个Deployment，它创建了一个Replica Set来启动3个nginx pod，yaml文件如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  namespace: default
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

将上面内容保存为: nginx-deployment.yaml，执行命令:
然后执行一下命令查看刚刚创建的Deployment:

以看到Deployment已经创建了3个Replica Set了，执行下面的命令查看rs和pod:

上面的Deployment的yaml文件中的replicas:3将会保证我们始终有3个POD在运行。

滚动升级Deployment

将刚刚保存的yaml文件中的nginx镜像修改为nginx:1.14.1，然后在spec下面添加滚动升级策略：

minReadySeconds: 5
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate

minReadySeconds:

minReadySeconds字段定义了这个等待时间的最小值，以秒为单位。在这段时间内，Kubernetes监视容器的运行状况，以确保它已经成功启动并能够正常工作。只有在等待时间达到minReadySeconds之后，Pod才会被标记为"Ready"，并且可以开始接收流量。

通过设置适当的minReadySeconds值，可以确保在将流量路由到新创建或更新的Pod之前，给容器足够的时间来完成初始化和启动过程，以避免过早地将流量发送到尚未完全准备好的容器。这对于确保应用程序的稳定性和可靠性非常重要。

注意，minReadySeconds字段是可选的，如果未指定，则使用默认值为0，这意味着Pod将立即被标记为"Ready"，并开始接收流量。

maxSurge:

升级过程中最多可以比原先设置多出的POD数量
例如：maxSurage=1，replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD，整个升级过程中最多会有5+1个POD。

maxUnavaible:

升级过程中最多有多少个POD处于无法提供服务的状态
当maxSurge不为0时，该值也不能为0
例如：maxUnavaible=1，则表示Kubernetes整个升级过程中最多会有1个POD处于无法服务的状态。

然后执行命令进行更新发布：

$ kubectl apply -f nginx-deployment.yaml
deployment "nginx-deploy" configured

然后我们可以使用rollout命令：
查看状态：

kubectl rollout status deployment/nginx-deploy

升级结束后，继续查看rs的状态：

根据AGE我们可以看到离我们最近的当前状态是：3，和我们的yaml文件是一致的，证明升级成功了。用describe命令可以查看升级的全部信息：

回滚Deployment

我们已经能够滚动平滑的升级我们的Deployment了，但是如果升级后的POD出了问题该怎么办？我们能够想到的最好最快的方式当然是回退到上一次能够提供正常工作的版本，Deployment就为我们提供了回滚机制。

首先，查看Deployment的升级历史：

kubectl rollout history deployment nginx-deploy
deployments "nginx-deploy"
REVISION  CHANGE-CAUSE
1   <none>
2   <none>
3   kubectl apply --filename=Desktop/nginx-deployment.yaml --record=true

从上面的结果可以看出在执行Deployment升级的时候最好带上record参数，便于我们查看历史版本信息。同样我们可以使用下面的命令查看单个REVISION的信息：

kubectl rollout history deployment nginx-deploy --revision=3
deployment.apps/nginx-deploy with revision #3
Pod Template:
  Labels:       app=nginx
        pod-template-hash=6f746dd8fb
  Containers:
   nginx:
    Image:      nginx:1.13.3
    Port:       80/TCP
    Host Port:  0/TCP
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

假如现在要直接回退到当前版本的前一个版本：

kubectl rollout undo deployment nginx-deploy
deployment.apps/nginx-deploy rolled back

当然也可以用revision回退到指定的版本：

kubectl rollout undo deployment nginx-deploy --to-revision=4

注意清除机制

Kubernetes默认是会将Deployments的每次改动操作生成一个新的RS，并保存下来的。不过你可以设置参数.spec.revisonHistoryLimit来来指定Deployment最多保留多少revision 历史记录。如果将该项设置为0，Deployment就不允许回退了。

目录CONTENT