当前位置： 代码迷 >> 综合 >> kubernetes Deployment 详解 更新/回滚/缩放/暂停/恢复部署操作
  详细解决方案

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

热度：71   发布时间：2023-11-09 18:41:28.0

涉及文档：

  • 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

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2ports:- containerPort: 80

2、更新Deployment资源

kubectl  apply -f nginx-deployment.yaml

3、检查集群中的 Deployment状态

kubectl   get  deployments.apps

在这里插入图片描述
所显示的字段有：

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

4、查看 Deployment 创建的 ReplicaSet

 kubectl get rs

在这里插入图片描述
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

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

kubectl  edit   deployments.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

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

kubectl get rs

在这里插入图片描述

  • 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

在这里插入图片描述

三、回滚 Deployment

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

1、镜像更新到1.161

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

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

kubectl  get  pod

在这里插入图片描述
在这里插入图片描述

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

3、查看Deployment详细信息：

kubectl describe deployment nginx-deployment

在这里插入图片描述

4、检查 Deployment 修订历史

kubectl  rollout    history  deployment  nginx-deployment

在这里插入图片描述

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

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

kubectl  rollout  undo  deployment nginx-deployment

在这里插入图片描述

  • 或者，你也可以通过使用 --to-revision 来回滚指定修订版本：
kubectl  rollout  undo  deployment nginx-deployment --to-revision=2

再次查看deployment nginx-deployment详细
在这里插入图片描述

四、缩放 Deployment

1、nginx-deployment扩容5个副本

kubectl  scale  deployment  --replicas=5 nginx-deployment

在这里插入图片描述

2、nginx-deployment缩容3个副本

kubectl  scale  deployment  --replicas=3 nginx-deployment

在这里插入图片描述

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

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

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

五、编写 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

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx				   #需要与.spec.selector标签一致（多标签时至少一个）
spec:minReadySeconds: 60 #就绪时间，使Pod视为可用progressDeadlineSeconds: 70 #进度期限秒数,报告会在资源状态replicas: 3 #副本数revisionHistoryLimit: 2 #保留历史记录个数strategy:rollingUpdate:			  #策略默认RollingUpdatemaxSurge: 3 #可以创建的超出 期望 Pod 个数的 Pod 数量。maxUnavailable: 1 #最大不可用selector:matchLabels:app: nginx			 #需要与.spec.template.metadata.labels标签一致（多标签时至少一个）template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2ports:- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:labels:app: nginxname: nginx-deployment
spec:ports:- name: nginxport: 80 #k8s内部svc虚拟地址的访问端口targetPort: 80 #Pod中服务对应的端口nodePort: 30088 #对外暴露服务端口selector:app: nginxtype: NodePort

2、生成资源

kubectl apply -f nginx-deployment.yaml

kubectl  describe  deployments.apps  nginx-deployment

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

3、测试 progressDeadlineSeconds

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

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

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

2、再次观察deployment详情
在这里插入图片描述
在这里插入图片描述
超过截止时间后，Deployment 控制器将添加具有以下属性的 DeploymentCondition 到 Deployment 的 .status.conditions 中：

kubectl get deployment nginx-deployment -o yaml

在这里插入图片描述

4、恢复到上个版本

kubectl  rollout  undo  deployment nginx-deployment

在这里插入图片描述

六、暂停、恢复 Deployment

1、清除上面测试的环境

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

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

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

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

3、deployment 金丝雀发布访问

  相关解决方案

代码迷 - 您身边的软件异常，代码异常，编程异常助手（发现，解决，分享）
Copyright © 2009-2013 DAIMAMI.COM. All rights reserved.