k8s教程(pod篇)-升级与回滚

简介: k8s教程(pod篇)-升级与回滚

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].imagenginx: 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命令来实现,必须通过再次提交旧版本配置的方式实现

下面是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被删除、重建,也仍然保 持原来的旧版本。这种分区升级策略通常用于按计划分步骤的系统升级过程中。

05 文末

本文主要讲解了pod的升级与回滚的相关概念与案例,希望能帮助到大家,谢谢大家的阅读,本文完!

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
22天前
|
存储 Kubernetes Docker
【赵渝强老师】Kubernetes中Pod的基础容器
Pod 是 Kubernetes 中的基本单位,代表集群上运行的一个进程。它由一个或多个容器组成,包括业务容器、基础容器、初始化容器和临时容器。基础容器负责维护 Pod 的网络空间,对用户透明。文中附有图片和视频讲解,详细介绍了 Pod 的组成结构及其在网络配置中的作用。
【赵渝强老师】Kubernetes中Pod的基础容器
|
22天前
|
运维 Kubernetes Shell
【赵渝强老师】K8s中Pod的临时容器
Pod 是 Kubernetes 中的基本调度单位,由一个或多个容器组成,包括业务容器、基础容器、初始化容器和临时容器。临时容器用于故障排查和性能诊断,不适用于构建应用程序。当 Pod 中的容器异常退出或容器镜像不包含调试工具时,临时容器非常有用。文中通过示例展示了如何使用 `kubectl debug` 命令创建临时容器进行调试。
|
22天前
|
Kubernetes 调度 容器
【赵渝强老师】K8s中Pod中的业务容器
Pod 是 Kubernetes 中的基本调度单元,由一个或多个容器组成。除了业务容器,Pod 还包括基础容器、初始化容器和临时容器。本文通过示例介绍如何创建包含业务容器的 Pod,并提供了一个视频讲解。示例中创建了一个名为 &quot;busybox-container&quot; 的业务容器,并使用 `kubectl create -f firstpod.yaml` 命令部署 Pod。
|
22天前
|
Kubernetes 容器 Perl
【赵渝强老师】K8s中Pod中的初始化容器
Kubernetes的Pod包含业务容器、基础容器、初始化容器和临时容器。初始化容器在业务容器前运行,用于执行必要的初始化任务。本文介绍了初始化容器的作用、配置方法及优势,并提供了一个示例。
|
22天前
|
存储 Kubernetes 调度
深入理解Kubernetes中的Pod与Container
深入理解Kubernetes中的Pod与Container
27 0
|
22天前
|
Kubernetes Java 调度
Kubernetes中的Pod垃圾回收策略是什么
Kubernetes中的Pod垃圾回收策略是什么
|
22天前
|
存储 Kubernetes 调度
深度解析Kubernetes中的Pod生命周期管理
深度解析Kubernetes中的Pod生命周期管理
|
16天前
|
Kubernetes 监控 Cloud Native
Kubernetes集群的高可用性与伸缩性实践
Kubernetes集群的高可用性与伸缩性实践
52 1
|
2月前
|
JSON Kubernetes 容灾
ACK One应用分发上线:高效管理多集群应用
ACK One应用分发上线,主要介绍了新能力的使用场景
|
2月前
|
Kubernetes 持续交付 开发工具
ACK One GitOps:ApplicationSet UI简化多集群GitOps应用管理
ACK One GitOps新发布了多集群应用控制台,支持管理Argo CD ApplicationSet,提升大规模应用和集群的多集群GitOps应用分发管理体验。