kubernetes Deployment 详解 更新/回滚/缩放/暂停/恢复部署操作_kubectl scale deployment

涉及文档：

• Deployments 官方文档

Deployments 简介：
一个 Deployment 为 Pods 和 ReplicaSets 提供声明式的更新能力。

你负责描述 Deployment 中的 目标状态，而 Deployment 控制器（Controller） 以受控速率更改实际状态， 使其变为期望状态。你可以定义 Deployment 以创建新的 ReplicaSet，或删除现有 Deployment， 并通过新的 Deployment 收放其资源。

以下是 Deployments 的典型用例：

• 创建 Deployment 以将 ReplicaSet 上线。 ReplicaSet 在后台创建 Pods。 检查 ReplicaSet 的上线状态，查看其是否成功。
• 通过更新 Deployment 的 PodTemplateSpec，声明 Pod 的新状态 。 新的 ReplicaSet 会被创建，Deployment 以受控速率将 Pod 从旧 ReplicaSet 迁移到新 ReplicaSet。`` 每个新的 ReplicaSet 都会更新 Deployment 的修订版本。
• 如果 Deployment 的当前状态不稳定，回滚到较早的 Deployment 版本。 每次回滚都会更新 Deployment 的修订版本
• 扩大 Deployment 规模以承担更多负载。
• 暂停 Deployment以应用对 PodTemplateSpec 所作的多项修改， 然后恢复其执行以启动新的上线版本。
• 使用 Deployment 状态 来判定上线过程是否出现停滞。
• 清理较旧的不再需要的 ReplicaSet 。

一、创建 Deployment对象

1、创建Deployment Pod

vim nginx-deployment.yaml
1

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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

2、更新Deployment资源

kubectl  apply -f nginx-deployment.yaml
1

3、检查集群中的 Deployment状态

kubectl   get  deployments.apps
1

所显示的字段有：

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

4、查看 Deployment 创建的 ReplicaSet

 kubectl get rs
1

ReplicaSet 输出中包含以下字段：

• NAME 列出名字空间中 ReplicaSet 的名称
• DESIRED 显示应用的期望副本个数，即在创建 Deployment 时所定义的值。 此为期望状态
• CURRENT 显示当前运行状态中的副本个数
• READY 显示应用中有多少副本可以为用户提供服务
• AGE 显示应用已经运行的时间长度

注意 ReplicaSet 的名称始终被格式化为[Deployment名称]-[随机字符串]。 其中的随机字符串是使用 pod-template-hash 作为种子随机生成的。

二、更新Deployment

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

1、镜像更新触发Deployment

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

- -record ： 标志将所执行的命令写入资源注 kubernetes.io/change-cause 中。 这对于以后的检查是有用的。例如 要查看针对每个 Deployment 修订版本所执行过的命令。

或者使用

kubectl  edit   deployments.apps   nginx-deployment
1

2、要查看上线状态，运行：

kubectl rollout status deployment nginx-deployment	
1

输出类似于：
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
或者
deployment "nginx-deployment" successfully rolled out
1
2
3
4

3、ReplicaSet并将其扩容到 3个副本并将旧 ReplicaSet 缩容到0个副本完成了Pod的更新操作

kubectl get rs
1

• Deployment 可确保在更新时仅关闭一定数量的 Pod。默认情况下，它确保至少所需 Pods 75% 处于运行状态（最大不可用比例为 25%）。

• Deployment 还确保仅所创建 Pod 数量只可能比期望 Pods 数高一点点。 默认情况下，它可确保启动的 Pod 个数比期望个数最多多出 25%（最大峰值 25%）。

• 重点重点：如果仔细查看上述 Deployment， 此文件replicas我这边设置为3，可计算出最大不可用数量1、启动的 Pod 个数比期望个数最多多1个 ，将看到它首先创建了一个新的 Pod，然后删除了一些旧的 Pods， 并创建了新的 Pods。它不会杀死老 Pods，直到有足够的数量新的 Pods 已经出现。 在足够数量的旧 Pods 被杀死前并没有创建新 Pods。它确保至少 2 个 Pod 可用，同时 最多总共 4 个 Pod 可用

4、获取 Deployment 详细信息

kubectl  describe   deployments.apps nginx-deployment
1

三、回滚 Deployment

例如当 Deployment 不稳定时（例如进入反复崩溃状态）。 默认情况下，Deployment 的所有上线记录都保留在系统中，以便可以随时回滚 （你可以通过修改修订历史记录限制来更改这一约束）。

1、镜像更新到1.161

kubectl set image deployment  nginx-deployment nginx=nginx:1.161 --record=true
1

2、更新失败（镜像拉取失败）

kubectl  get  pod
1

说明： Deployment 控制器自动停止有问题的上线过程，并停止对新的 ReplicaSet 扩容。 这行为取决于所指定的 rollingUpdate参数具体为 maxUnavailable默认情况下，Kubernetes 将此值设置为 25%。

3、查看Deployment详细信息：

kubectl describe deployment nginx-deployment
1

4、检查 Deployment 修订历史

kubectl  rollout    history  deployment  nginx-deployment
1

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

假定现在你已决定撤消当前上线并回滚到以前的修订版本

kubectl  rollout  undo  deployment nginx-deployment
1

• 或者，你也可以通过使用 --to-revision 来回滚指定修订版本：

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

再次查看deployment nginx-deployment详细

四、缩放 Deployment

1、nginx-deployment扩容5个副本

kubectl  scale  deployment  --replicas=5 nginx-deployment
1

2、nginx-deployment缩容3个副本

kubectl  scale  deployment  --replicas=3 nginx-deployment
1

3、Pod 的水平自动缩放（前提需要安装插件metrics-server ）

具体可参考文档： kubernetes 自动扩容与缩容pod（metrics-server篇）

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

五、编写 Deployment 规约模板

详细查看文档： [Kubernetes Deployment 规约] (必读)(https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/#writing-a-deployment-spec)

• 副本：.spec.replicas 是指定所需 Pod 的可选字段。它的默认值是1
• 选择算符: .spec.selector 必须匹配 .spec.template.metadata.labels，否则请求会被 API 拒绝。
• 策略: .spec.strategy 策略指定用于用新 Pods 替换旧 Pods 的策略,RollingUpdate 是默认值, 如果 .spec.strategy.type==Recreate，在创建新 Pods 之前，所有现有的 Pods 会被杀死, 常用就是RollingUpdate策略,.spec.strategy.type==RollingUpdate时，采取 滚动更新的方式更新 Pods。你可以指定maxUnavailable 和 maxSurge来控制滚动更新 过程。
• 最大不可用： .spec.strategy.rollingUpdate.maxUnavailable，此值不能为 0。 默认值为 25%。
• 最大峰值：.spec.strategy.rollingUpdate.maxSurge，则此值不能为 0。百分比值会通过向上取整转换为绝对数。此字段的默认值为 25%。
• 进度期限秒数： .spec.progressDeadlineSeconds 这类报告会在资源状态中体现为 Type=Progressing、Status=False、 Reason=ProgressDeadlineExceeded，默认为600秒
• 最短就绪时间: .spec.minReadySeconds Pod 在没有任意容器崩溃情况下的最小就绪时间， 只有超出这个时间 Pod 才被视为可用。默认值为 0
• 修订历史限制: .spec.revisionHistoryLimit 用来设定出于会滚目的所要保留的旧 ReplicaSet 数量,默认情况下，系统保留 10 个旧 ReplicaSe

1、更新新的测试yaml

vim  nginx-deployment.yaml
1

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx				   #需要与.spec.selector标签一致（多标签时至少一个）
spec:
  minReadySeconds: 60		   #就绪时间，使Pod视为可用
  progressDeadlineSeconds: 70  #进度期限秒数,报告会在资源状态
  replicas: 3				   #副本数
  revisionHistoryLimit: 2	   #保留历史记录个数
  strategy:
    rollingUpdate:			  #策略默认RollingUpdate
      maxSurge: 3             #可以创建的超出 期望 Pod 个数的 Pod 数量。
      maxUnavailable: 1       #最大不可用
  selector:
    matchLabels:
      app: nginx			 #需要与.spec.template.metadata.labels标签一致（多标签时至少一个）
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx
  name: nginx-deployment
spec:
  ports:
  - name: nginx
    port: 80			#k8s内部svc虚拟地址的访问端口
    targetPort: 80		#Pod中服务对应的端口
    nodePort: 30088		#对外暴露服务端口
  selector:
    app: nginx
  type: NodePort
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

2、生成资源

kubectl apply -f nginx-deployment.yaml
1

kubectl  describe  deployments.apps  nginx-deployment
1

右边的图Conditions部分信息可以看到在65~66秒，由此可以得到minReadySeconds 只有超出这个时间 Pod 才被视为可用生效，可以自行测试将minReadySeconds 取消或者设置为0，再次生成资源，就会观察到这个状态。

3、测试 progressDeadlineSeconds

Deployment 尝试部署其最新的 ReplicaSet 受挫情况

1、动态更新一个不存在的镜像

kubectl  set  image  deployment  nginx-deployment nginx=nginx:1.20 --record
1

2、再次观察deployment详情


超过截止时间后，Deployment 控制器将添加具有以下属性的 DeploymentCondition 到 Deployment 的 .status.conditions 中：

kubectl get deployment nginx-deployment -o yaml
1

4、恢复到上个版本

kubectl  rollout  undo  deployment nginx-deployment
1

六、暂停、恢复 Deployment

1、清除上面测试的环境

kubectl  delete  -f nginx-deployment.yaml  &&  kubectl  apply -f nginx-deployment.yaml
1

2、更新镜像并且暂停Deployment 滚动更新

kubectl set image deployments nginx-deployment nginx=mirrorgooglecontainers/echoserver:1.10 --record &&  kubectl rollout  pause  deployment  nginx-deployment
1

在此，可以完全显示突出 deployment 的滚动策略。 开始4个创建状态可解析出来，3个是允许超出POd预期个数，还有一个是自身本身的滚动更新出来的Pod。

3、deployment 金丝雀发布访问