kubernetes之Deployment详解

Deployment概述

Deployment是kubernetes中最常用的资源对象，为ReplicaSet和Pod的创建提供了一种声明式的定义方法，在Deployment对象中描述一个期望的状态，Deployment控制器就会按照一定的控制速率把实际状态改成期望状态，通过定义一个Deployment控制器会创建一个新的ReplicaSet控制器，通过ReplicaSet创建pod，删除Deployment控制器，也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源.

Deployment的典型用例

1、创建 Deployment 将 ReplicaSet 上线，ReplicaSet 在后台创建 Pod。 检查 ReplicaSet 的上线状态，查看其是否成功。

注：Deployment并不直接控制Pod，而是通过ReplicaSet 来管理pod

2、使用 Deployment 状态来判定上线过程是否出现停滞。

3、支持版本的滚动更新和版本回退

创建Deployment

下面是一个 Deployment 示例。其中创建了一个 ReplicaSet，负责启动三个 nginx Pod：

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

在该例中：

1、创建了一个名为 nginx-deployment（由 .metadata.name 字段标明）的 Deployment。 该名称将成为后续创建 ReplicaSet 和 Pod 的命名基础。

2、该 Deployment 创建一个 ReplicaSet，它创建三个（由 .spec.replicas 字段标明）Pod 副本，spec.replicas指定pod的副本数。

3、.spec.selector 字段定义所创建的 ReplicaSet 如何查找要管理的 Pod，相当于pod的选择器。.spec.selector.matchLabels为匹配规则，上面例子就会匹配label中app为nginx的pod

4、.spec.template为模板配置，当副本数量不足时，会根据模板的配置创建pod副本，.spec.template.labels为设置pod的label标签，.spec.template.spec.containers[0].name为创建的容器名，.spec.template.spec.containers[0].image为创建副本使用的镜像

注：Deployment 的标签或者选择算符不要与其他控制器重叠

创建好Deployment 文件后，我们就可以使用kubectl apply -f来创建Deployment 了

kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml

运行 kubectl get deployments 检查 Deployment 是否已创建。 如果仍在创建 Deployment，则输出类似于：

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   0/3     0            0           1s

NAME ：列出了名字空间中 Deployment 的名称。
READY ：显示应用程序的可用的“副本”数。显示的模式是“就绪个数/期望个数”。
UP-TO-DATE： 显示为了达到期望状态已经更新的副本数。
AVAILABLE ：显示应用可供用户使用的副本数。
AGE： 显示应用程序运行的时间。

要查看 Deployment 创建的 ReplicaSet（rs），可以运行 kubectl get rs。 输出类似于：

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-75675f5897   3         3         3       18s

要查看每个 Pod 自动生成的标签，可以运行 kubectl get pods --show-labels

更新 Deployment

仅当 Deployment Pod 模板（即 .spec.template）发生改变时，例如模板的标签或容器镜像被更新， 才会触发 Deployment 上线。其他更新（如对 Deployment 执行扩缩容的操作）不会触发上线动作。

我们要修改Deployment 的一些配置可以直接修改Deployment 文件，如下我们修改Deployment 的镜像

kubectl edit deployment/nginx-deployment

直接将原来的nginx:1.14.2 更改至 nginx:1.16.1即可

    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1
        ports:
        - containerPort: 80

修改完成后输出类似于：

deployment.apps/nginx-deployment edited

可以使用kubectl rollout status命令查看Deployment的更新过程：

kubectl rollout  status deployment/nginx-deployment

修改后再使用kubectl get deployments 命令查看deployment的状态

使用kubectl describe deployments可以看到deployment的详细信息，和我们的更新过程

下面是我修改镜像后发生的Events

Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  7m54s  deployment-controller  Scaled up replica set nginx-deployment-9456bbbf9 to 3
  Normal  ScalingReplicaSet  4m43s  deployment-controller  Scaled up replica set nginx-deployment-ff6655784 to 1
  Normal  ScalingReplicaSet  80s    deployment-controller  Scaled down replica set nginx-deployment-9456bbbf9 to 2
  Normal  ScalingReplicaSet  80s    deployment-controller  Scaled up replica set nginx-deployment-ff6655784 to 2
  Normal  ScalingReplicaSet  75s    deployment-controller  Scaled down replica set nginx-deployment-9456bbbf9 to 1
  Normal  ScalingReplicaSet  75s    deployment-controller  Scaled up replica set nginx-deployment-ff6655784 to 3
  Normal  ScalingReplicaSet  68s    deployment-controller  Scaled down replica set nginx-deployment-9456bbbf9 to 0

可以看到，更新 Deployment 时，它创建了一个新的 ReplicaSet （nginx-deployment-ff6655784 ），并将其扩容为 1，等待其就绪；然后将旧 ReplicaSet 缩容到 2， 将新的 ReplicaSet 扩容到 2 以便至少有 3 个 Pod 可用且最多创建 4 个 Pod。 然后，它使用相同的滚动更新策略继续对新的 ReplicaSet 扩容并对旧的 ReplicaSet 缩容。 最后，你将有 3 个可用的副本在新的 ReplicaSet 中，旧 ReplicaSet 将缩容到 0。

回滚 Deployment

有时，你可能想要回滚 Deployment；例如，当 Deployment 不稳定时（例如进入反复崩溃状态）。 默认情况下，Deployment 的所有上线记录都保留在系统中，以便可以随时回滚 。

注：只有当Deployment 的 Pod 模板（.spec.template）发生更改时，才会创建新修订版本 – 例如，模板的标签或容器镜像发生变化。其他更新，如 Deployment 的扩缩容操作不会创建 Deployment 修订版本。 换言之，当你回滚到较早的修订版本时，只有 Deployment 的 Pod 模板部分会被回滚。

比如，我们上面更新了nginx的镜像，发现新版本的nginx不好用，想要回退到之前的版本，那么我们就可以选择回滚到之前的Deployment版本

1、检查 Deployment 上线历史

kubectl rollout history deployment/nginx-deployment

输出类似于：

deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

2、查看修订历史的详细信息，运行：

kubectl rollout history deployment/nginx-deployment --revision=2

根据历史版本的详细信息，我们找到我们需要的版本

3、回滚到之前的修订版本

kubectl rollout undo deployment/nginx-deployment --to-revision=1

注：使用 --to-revision 来回滚到特定版本

如果我们只是想回退到上一版本，那么直接使用下面命令即可

kubectl rollout undo deployment/nginx-deployment

4、检查回滚是否成功以及 Deployment 是否正在运行，运行：

kubectl get deployment nginx-deployment

输出类似于：

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           30m

看READY列，是否已经全部启动

5、获取 Deployment 描述信息：

查看Deployment 的详细信息，看我们的镜像版本是否正确回退

kubectl describe deployment nginx-deployment

扩缩 Deployment

你可以使用如下指令扩缩 Deployment的副本，–replicas指定副本数：

kubectl scale deployment/nginx-deployment --replicas=10

输出类似于：

deployment.apps/nginx-deployment scaled

假设集群启用了Pod 的水平自动缩放， 你可以为 Deployment 设置自动缩放器，并基于现有 Pod 的 CPU 利用率选择要运行的 Pod 个数下限和上限。

kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80

暂停、恢复 Deployment 的上线过程

使用如下指令暂停上线：

kubectl rollout pause deployment/nginx-deployment

我们在暂停了Deployment 的上线后，就可以进行一系列的更新操作，然后再恢复上线，避免不必要的上线操作

恢复 Deployment 上线：

kubectl rollout resume deployment/nginx-deployment

Deployment 更新策略

.spec.strategy 策略指定用于用新 Pod 替换旧 Pod 的策略。 .spec.strategy.type 可以是 “Recreate” 或 “RollingUpdate”。“RollingUpdate” 是默认值。

Recreate
如果 .spec.strategy.type==Recreate，在创建新 Pod 之前，所有现有的 Pod 会被杀死。

RollingUpdate
Deployment 会在 .spec.strategy.type==RollingUpdate时，采取 滚动更新的方式更新 Pod。你可以指定 maxUnavailable 和 maxSurge 来控制滚动更新 过程。

maxUnavailable：表示在进行滚动更新期间允许的最大不可用Pod数量。例如，如果设置为1，则在进行滚动更新时，允许有一个Pod处于不可用状态。默认情况下，maxUnavailable被设置为25%。

maxSurge：表示超出所需副本数的最大Pod数量。例如，如果当前Deployment对象需要5个Pod，并将maxSurge设置为1，则最多允许6个Pod运行。这一策略可以确保在进行滚动更新时，新版本的Pod可以逐渐替换旧版本的Pod，同时保持应用程序的可用性。