k8s教程（pod篇）-升级与回滚

杨林伟

已于 2023-01-04 14:37:20 修改

阅读量3.1k

点赞数 11

分类专栏： # k8s 文章标签： kubernetes 云原生容器化技术

于 2022-12-29 22:00:00 首次发布

本文链接：https://blog.csdn.net/qq_20042935/article/details/128476388

版权

k8s 专栏收录该内容

41 篇文章 45 订阅

订阅专栏

文章目录

01 引言
02 Deployment的升级
03 Deployment的回滚
- 3.1 回滚方式
04 其它
05 文末

01 引言

声明：本文为《Kubernetes权威指南：从Docker到Kubernetes实践全接触（第5版）》的读书笔记

当集群中的某个服务需要升级时，我们需要停止目前与该服务相关的所有
pod，然后下载新版本镜像并创建新的pod。如果集群规模比较大，则这个工作变成了一个挑战，而且先全部停止然后逐步升级的方式会导致较长时间的服务不可用。

kubernetes提供了滚动升级功能来解决上述问题。

如果pod是通过Deployment创建的，则用户可以在运行时修改Deployment的
pod定义(spec.template)或镜像名称，并应用到Deployment对象上，系统即可完成Deployment的rollout动作，rollout可被视为Deployment的自动更新或者自动部署动作，如果在更新过程中发生了错误，则还可以通过回滚操作恢复pod的版本。

02 Deployment的升级

以nginx的deployment为例：

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

可以看到已运行的副本数有3个：
在这里插入图片描述
那么如果想升级nginx的版本为1.9.1，该如何操作呢？

2.1 升级方式

2.1 set image命令

可以通过kubectl set image命令为Deployment设置新的镜像名称:
在这里插入图片描述

2.2 edit 命令

另一种更新的方法是使用kubectl edit命令修改Deployment的配置，将 spec.template.spec.containers[0].image从nginx: 1.7.9更改为nginx:1.9.1:
在这里插入图片描述

2.2 查看过程

镜像名（或pod定义）一旦发生了修改，则将触发系统完成Deployment所有运行pod的滚动升级操作。

可以使用kubectl rollout status命令查看Deployment的更新过程：
在这里插入图片描述

查看当前运行的pod，名称已经更新了：
在这里插入图片描述
查看pod使用的镜像，已经更新为Nginx:1.9.1了：

2.3 升级原理

Deployment升级pod的流程如下：

step1：初始创建Deployment时，系统创建了一个ReplicaSet （nginx–deployment-4o87004473），并按用户的需求创建了3个Pod副本；
step2：更新Deployment时，系统创建了一个新的ReplicaSet（nginx-deployment- 3599678771)，并将其副本数量扩展到1，然后将旧的ReplicaSet缩减为2；
step3：之后,系统继续按照相同的更新策略对新旧两个ReplicaSet进行逐个调整；
step4：最后，新的ReplicaSet运行了3个新版本的Pod副本，旧的ReplicaSet副本数量则缩减为0。

在这里插入图片描述

我们可以使用kubectl describe deployments/nginx-deployment命令仔细观察
Deployment的更新过程：
在这里插入图片描述
运行kubectl get rs命令,查看两个ReplicaSet的最终状态:

在整个升级过程中，系统会保证至少有两个pod可用，并且最多同时运行4个
pod，这是Deployment通过复杂的算法完成的。

Deployment需要确保在整个更新过程中只有一定数量的pod可能处于不可用状态。在默认情况下，Deployment确保可用的pod总数量至少为所需的副本数量(DESIRED)减1，也就是最多1个不可用(maxUnavailables=1)。

Deploymenti还需要确保在整个更新过程中pod的总数量不会超过所需的副本数量太多。在默认情况下，Deployment确保pod的总数量最多比所需的pod数量多1个，也就是最多1个浪涌值（maxSurge=-1)。

Kubernetes从1.6版本开始，maxUnavailable和maxSurgef的默认值将从1、1更新为所需副本数量的25%、25%。这样，在升级过程中，Deployment就能够保证服务不中断，并且副本数量始终维持为用户指定的数量(DESIRED)。

03 Deployment的回滚

如果在Deployment升级过程中出现意外，比如写错新镜像的名称、新镜像还没被放入镜像仓库里、新镜像的配置文件发生不兼容性改变、新镜像的启动参数不对，以及因可能更复杂的依赖关系而导致升级失败等，就需要回退到之前的旧版本，这时就可以用到Deploymentl的回滚功能了。

3.1 回滚方式

我们将Deployment回滚到之前的版本时，只有Deployment的pod模板部分会被修改，在默认情况下，所有Deployment的发布历史记录都被保留在系统中（可以配置历史记录数量)，以便于我们随时进行回滚操作。

注意，在创建Deployment时使用-record参数，就可以在CHANGE-CAUSE列看到每个版本使用的命令了，如果需要查看特定版本的详细信息，则可以加上-revision-=<N>参数：
在这里插入图片描述
现在我们决定撤销本次发布并回滚到上一个部署版本：

kubectl rollout undo deployment/nginx-deployment 
deployment "nginx-deployment" rolled back

这样，该Deployment就回滚到之前的稳定版本了，可以从Deployment的事件信息中查看到回滚到版本2的操作过程：
在这里插入图片描述

04 其它

4.1 暂停和恢复Deployment的部署操作

通过kubectl rollout pause命令暂停Deployment的更新操作:

kubectl rollout pause deployment/nginx-deployment 

deployment "nginx-deployment" paused

然后修改Deployment的镜像信息:

kubectl set image deploy/nginx-deployment nginx=nginx:1.9.1 

deployment "nginx-deployment"image updated

查看Deployment的历史记录，发现并没有触发新的Deployment部署操作：
在这里插入图片描述
最后，恢复这个Deployment的部署操作：

$ kubectl rollout resume deploy nginx-deployment 
deployment "nginx-deployment"resumed

可以看到一个新的ReplicaSet被创建出来了：
在这里插入图片描述

4.2 其他管理对象的更新策略

4.2.1 DaemonSet的更新策略

目前DaemonSet的升级策略（updateStrategy)包括两种：

升级策略	描述
OnDelete	DaemonSet的默认升级策略，与1.5及之前版本的Kubernetes保持一致。当使用OnDelete作为升级策略时，在创建好新的DaemonSeti配置之后，新的Pod并不会被自动创建，直到用户手动删除旧版本的Pod，才触发新建操作，即只有手工删除了DaemonSet创建的Pod副本，新的Pod 副本才会被创建出来。如果不设置updateStrategy的值，则在Kubernetes 1.6之后的版本中会被作为updateStrategyl的默认设置
RollingUpdate	从Kubernetes1.6版本开始引入。当使用RollingUpdate作为升级策略对DaemonSeti进行更新时，旧版本的Pod将被自动"杀掉"，然后自动创建新版本的DaemonSet Pod。整个过程与普通Deployment的滚动升级一样是可控的。不过有两点不同于普通Pod的滚动升级：一是目前Kubernetes还不支持查看和管理DaemonSetl的更新历史记录；二是DaemonSet的回滚(Rollback)并不能如同Deployment一样直接通过kubectl rollback命令来实现，必须通过再次提交旧版本配置的方式实现

升级策略

描述

OnDelete

DaemonSet的默认升级策略，与1.5及之前版本的Kubernetes保持一致。当使用OnDelete作为升级策略时，在创建好新的DaemonSeti配置之后，新的Pod并不会被自动创建，直到用户手动删除旧版本的Pod，才触发新建操作，即只有手工删除了DaemonSet创建的Pod副本，新的Pod 副本才会被创建出来。如果不设置updateStrategy的值，则在Kubernetes 1.6之后的版本中会被作为updateStrategyl的默认设置

RollingUpdate

从Kubernetes1.6版本开始引入。当使用RollingUpdate作为升级策略对DaemonSeti进行更新时，旧版本的Pod将被自动"杀掉"，然后自动创建新版本的DaemonSet Pod。整个过程与普通Deployment的滚动升级一样是可控的。不过有两点不同于普通Pod的滚动升级：一是目前Kubernetes还不支持查看和管理DaemonSetl的更新历史记录；二是DaemonSet的回滚(Rollback)并不能如同Deployment一样直接通过kubectl rollback命令来实现，必须通过再次提交旧版本配置的方式实现

下面是DaemonSet采用RollingUpdate升级策略的YAML定义:

apiversion: apps/v1
kind: DaemonSet
metadata: 
	name: goldpinger
spec:
	updatestrategy:
		type: RollingUpdate

4.2.2 StatefulSet的更新策略

StatefulSet实现了RollingUpdate、OnDelete和Partitioned这几种策略，以保证StatefulSet中各Pod有序地、逐个地更新，并且能够保留更新历史，也能回滚到某个历史版本（如果用户未设置updateStrategy字段，则系统默认使用RollingUpdate策略）:

策略	描述
RollingUpdate	StatefulSet Controller会删除并创建StatefulSet：相关的每个Pod对象，其处理顺序与StatefulSet终止Pod的顺序一致，即从序号最大的Pod开始重建，每次更新一个Pod
OrderedReady	可能在更新过程中发生一些意外，从而导致StatefulSet陷入奔溃状态，此时需要用户手动修复
OnDelete	StatefulSet Controller并不会自动更新StatefulSet中的Pod实例，而是需要用户手动删除这些Pod并触发StatefulSet Controller创建新的Pod实例来弥补，因此这其实是一种手动升级模式
Partitioned	在这种模式下，用户指定一个序号，StatefulSet中序号大于等于此序号的Pod实例会全部被升级，小于此序号的Pod实例则保留旧版本不变，即使这些Pod被删除、重建，也仍然保持原来的旧版本。这种分区升级策略通常用于按计划分步骤的系统升级过程中。