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

最新推荐文章于 2024-09-13 11:58:48 发布

还是那片西瓜吗

最新推荐文章于 2024-09-13 11:58:48 发布

阅读量9.8k

点赞数 1

分类专栏： kubernetes 初级篇

本文链接：https://blog.csdn.net/qq_37377136/article/details/109141843

版权

kubernetes 初级篇专栏收录该内容

41 篇文章 12 订阅

订阅专栏

涉及文档：

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-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

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-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

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。