Deployment

在k8s中，Pod是最小的创建，管理，可部署单元。但是我们并不会直接去创建Pod，而是通过Deployment来创建Pod，并由Deployment来负责Pod的创建，更新及维护。

Deployment 在Pod 和 ReplicaSet 之上，提供了一个声明式定义（declarative）方法，用来替代以前的ReplicationController 来方便的管理应用。

你只需要在 Deployment 中描述您想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。您可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。

创建Deployment

nginx-deployment.yaml

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

以上示例中：

• 创建名为 nginx-deployment（由 .metadata.name 字段标明）的 Deployment。

• 该 Deployment 创建三个（由 replicas 字段标明）Pod 副本。

• selector 字段定义 Deployment 如何查找要管理的 Pods。 在这个示例中，Deployment通过在 Pod 模板中定义的标签（app: nginx）来确定要管的Pod。

• template字段包含以下子字段：

  • Pod 在 labels 字段定义 app: nginx 标签。
  • Pod 模板（即 .template.spec 字段）指示 Pods 运行一个 nginx 容器， 该容器运行版本为 1.14.2 的 nginx 镜像。
  • 创建一个容器并使用 name 字段将其命名为 nginx。

nginx-deployment.yaml完成后，可以使用kubectl apply -f nginx-deployment.yaml命令来创建Deployment。

要查看Deployment创建结果，可以运行kubectl get deployments命令。

NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         3         3            3           18s

更新Deployment

以更新nginx镜像为例，将nginx镜像从nginx:1.14.2更新为nginx:1.16.1。

1、执行命令更新镜像

kubectl --record deployment.apps/nginx-deployment set image \
   deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1

或者

kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record

执行以上命令后会出现以下类似输出：

deployment.apps/nginx-deployment image updated

也可以利用以下命令直接编辑Deployment

kubectl edit deployment.v1.apps/nginx-deployment

2、查看上线状态

kubectl rollout status deployment/nginx-deployment

输出类似于：

Waiting for rollout to finish: 2 out of 3 new replicas have been updated...

或者

deployment "nginx-deployment" successfully rolled out

更新过程

Deployment 控制器每次注意到新的 Deployment 时，都会创建一个 ReplicaSet 以启动所需的 Pods。 如果更新了 Deployment，则标签匹配 .spec.selector 但模板不匹配 .spec.template 的 Pods 的现有 ReplicaSet 被缩容。最终，新的 ReplicaSet 缩放为 .spec.replicas 个副本， 所有旧 ReplicaSets 缩放为 0 个副本。

当 Deployment 正在上线时被更新，Deployment 会针对更新创建一个新的 ReplicaSet 并开始对其扩容，之前正在被扩容的 ReplicaSet 会被翻转，添加到旧 ReplicaSets 列表 并开始缩容。

例如，假定你在创建一个 Deployment 以生成 nginx:1.14.2 的 5 个副本，但接下来 更新 Deployment 以创建 5 个 nginx:1.16.1 的副本，而此时只有 3 个nginx:1.14.2 副本已创建。在这种情况下，Deployment 会立即开始杀死 3 个 nginx:1.14.2 Pods， 并开始创建 nginx:1.16.1 Pods。它不会等待 nginx:1.14.2 的 5 个副本都创建完成 后才开始执行变更动作。

回滚Deployment

回滚前，先查看Deployment版本历史

kubectl rollout history deployment.v1.apps/nginx-deployment

输出类似于：

deployments "nginx-deployment"
REVISION    CHANGE-CAUSE
1           kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
2           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
3           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true

CHANGE-CAUSE 的内容是从 Deployment 的 kubernetes.io/change-cause 注解复制过来的。 复制动作发生在修订版本创建时。你可以通过以下方式设置 CHANGE-CAUSE 消息：

• 使用 kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1" 为 Deployment 添加注解。
• 追加 --record 命令行标志以保存正在更改资源的 kubectl 命令。
• 手动编辑资源的清单。

1、回滚到上一个版本

kubectl rollout undo deployment.v1.apps/nginx-deployment

2、回滚到指定版本

kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2

缩放Deployment

使用以下命令缩放Deployment：

kubectl scale deployment.v1.apps/nginx-deployment --replicas=10

自动缩放：可以为 Deployment 设置自动缩放器，并基于现有 Pods 的 CPU 利用率选择 要运行的 Pods 个数下限和上限。

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

清理策略

在 Deployment 中设置 .spec.revisionHistoryLimit 字段，可以指定保留此 Deployment 保留多少个旧 ReplicaSet。其余的 ReplicaSet 将在后台被垃圾回收。 默认情况下，此值为 10。

显式将此字段设置为 0 将导致 Deployment 的所有历史记录被清空，因此 Deployment 将无法回滚。

策略

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

重新创建 Deployment

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

滚动更新 Deployment

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

最大不可用 （maxUnavailable）

.spec.strategy.rollingUpdate.maxUnavailable 是一个可选字段，用来指定更新过程中不可用的 Pod 的个数上限。该值可以是绝对数字，也可以是所需 Pods 的百分比（例如，10%）。百分比值会转换成绝对数并去除小数部分。 如果 .spec.strategy.rollingUpdate.maxSurge 为 0，则maxUnavailable值不能为 0。 默认值为 25%。

例如，当此值设置为 30% 时，滚动更新开始时会立即将旧 ReplicaSet 缩容到期望 Pod 个数的70%。 新 Pod 准备就绪后，可以继续缩容旧的 ReplicaSet，然后对新的 ReplicaSet 扩容，确保在更新期间可用的 Pods 总数在任何时候都至少为所需的 Pod 个数的 70%。

最大峰值 （maxSurge）

.spec.strategy.rollingUpdate.maxSurge 是一个可选字段，用来指定可以创建的超出期望 Pod 个数的 Pod 数量。此值可以是绝对数或所需 Pods 的百分比。 如果 MaxUnavailable 为 0，则此值不能为 0。百分比值会通过向上取整转换为绝对数。 此字段的默认值为 25%。

例如，当此值为 30% 时，启动滚动更新后，会立即对新的 ReplicaSet 扩容，同时保证新旧 Pod 的总数不超过所需 Pod 总数的 130%。一旦旧 Pods 被杀死，新的 ReplicaSet 可以进一步扩容， 同时确保更新期间的任何时候运行中的 Pods 总数最多为所需 Pods 总数的 130%。