入门Kubernetes - 滚动升级/回滚

时间:2021-12-30 02:35:25

一、前言

 上一篇文章中对yaml文件格式进行了解,并对k8s中各种主要资源通过yaml创建时的定义模板。接来下就进一步学习k8s的各种特点。并应用在示例中。

 接下来先实现.Net Core Api程序版本滚动升级、回滚,并在过程中进一步的对k8s进行了解

二、滚动升级

 1、推送新版本服务镜像v3到docker hub。  

  入门Kubernetes - 滚动升级/回滚

 2、实现k8s中滚动升级:

  新建k8sweb-dep.yaml文件,用于创建Deployment资源:

apiVersion: apps/v1
kind: Deployment #定义Kubernetes资源的类型为Deployment
metadata:
name: k8sweb-deployment #定义资源的名称
spec:
replicas: 3 #定义运行Pod数量
selector:
matchLabels: #定义该部署匹配哪些Pod
name: k8sweb #定义Pod名称
template:
metadata: #定义指定Pod的模板
labels: #根据模板创建的Pod会被贴上该标签,与上面的matchLabels对应
name: k8sweb
spec:
containers: #容器定义
- name: k8sweb #容器名
image: cwsheng/k8sdemoweb:latest #镜像地址
ports:
- containerPort: 80
imagePullPolicy: IfNotPresent #不是最新则拉取

  表面上本次Deployment指定创建3个Pod、1个Deployment资源,实际上在Deployment和Pod中间还有ReplicaSet。

  Deployment 实际上一个两层控制器,Deployment 控制 ReplicaSet,ReplicaSet 控制 Pod。ReplicaSet 有版本区分,滚动更新的能力就是基于 ReplicaSet 的版本来实现。如下图:

  入门Kubernetes - 滚动升级/回滚

 a)执行命令:

kubectl apply -f k8sweb-dep.yaml

 b)查看 deployment状态:

kubectl get deployments

  结果如下:

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
k8sweb-deployment 3/3 3 3 54m
  • READY:当前处于 Running 状态的 Pod 的个数/用户期望的 Pod 个数(配置文件设置的 replicas 值);
  • UP-TO-DATE:当前处于最新版本的 Pod 个数(Pod 的 Spec 部分与 Deployment 里 Pod 模板里定义的完全一致),在滚动更新过程中会有不一致的阶段;
  • AVAILABLE:当前可用的 Pod 个数。

 c)查看上图中说描述的ReplicaSet资源:

kubectl describe replicaset

  结果如下:可以看出:Pod是由ReplicaSet控制着(创建、删除)、ReplicaSet则由Deployment控制 。结果和上图相同

  可发现:ReplicaSet 的名字是由 Deployment 名字 + 随机字符串,Pod 的名字是由 ReplicaSet 名字 + 随机字符串

  入门Kubernetes - 滚动升级/回滚

 d)滚动更新

  该更新实际上是更新Pod中镜像版本。

  修改deployment文件中镜像文件进行更新,修改文件名加上版本号(k8s-dep-v3.yaml)

apiVersion: apps/v1
kind: Deployment #定义Kubernetes资源的类型为Deployment
metadata:
name: k8sweb-deployment #定义资源的名称
spec:
replicas: 3 #定义运行Pod数量
selector:
matchLabels: #定义该部署匹配哪些Pod
name: k8sweb #定义Pod名称
template:
metadata: #定义指定Pod的模板
labels: #根据模板创建的Pod会被贴上该标签,与上面的matchLabels对应
name: k8sweb
spec:
containers: #容器定义
- name: k8sweb #容器名
image:cwsheng/k8sdemoweb:v3 #镜像地址
ports:
- containerPort: 80
imagePullPolicy: IfNotPresent #不是最新则拉取

  重新执行命令

kubectl apply -f k8s-dep-v3.yaml --record

  --record的作用是将当前命令记录到 revision 记录中,这样我们就可以知道每个 revison 对应的是哪个配置文件。

  查看事件看资源如何变化:

kubectl describe deployment k8sweb-deployment

  入门Kubernetes - 滚动升级/回滚

  Deployment 控制器根据修改后的 Pod 模板,创建新的 ReplicaSet(k8sweb-deployment-6594dd8ff7),Pod 数默认是 0,然后老的 ReplicaSet (k8sweb-deployment-954845689)Pod 数逐渐减少,

  新的 ReplicaSet 的 Pod 数逐渐增加,两个过程交替进行,新的增加一个,老的减少一个,直到全部升级完成。

  查看ReplicaSet状态:旧的ReplicaSet的Pod 已经缩减为 0 个,新的 ReplicaSet 的 Pod 扩展为 3 个,每次配置修改重新部署都可能创建一个新的 ReplicaSet

PS F:\coding\project\k8s.demo\k8s> kubectl get rs
NAME DESIRED CURRENT READY AGE
k8sweb-deployment-6594dd8ff7 0 0 0 2m14s
k8sweb-deployment-954845689 3 3 3 116s

三、回滚升级

 回滚操作前,需要知道当前的版本记录情况:

 rollout 命令:

命令 说明
history 显示 rollout 历史
pause 标记提供的 resource 为中止状态
resume 继续一个停止的 resource
status 显示 rollout 的状态
undo 撤销上一次的 rollout

 a)通过命令:kubectl rollout history 查看历史版本。

PS F:\coding\project\k8s.demo\k8s> kubectl rollout history deployment.apps/k8sweb-deployment
deployment.apps/k8sweb-deployment
REVISION CHANGE-CAUSE
1 kubectl.exe apply --filename=k8s-dep.yaml --record=true
2 kubectl.exe apply --filename=k8s-dep-v3.yaml --record=true

  CHANGE-CAUSE 为命令内容。--record=true才会存储,否则为空:<none> 

 b)通过命令:kubectl rollout undo 将deployment回滚到指定的版本

#指定恢复到上一个版本
kubectl rollout undo deployment/k8sweb-deployment #恢复到指定版本1
kubectl rollout undo deployment/k8sweb-deployment --to-revision=1

 c)配置历史记录保存数量

  可以在 Deployment 配置文件中通过 revisionHistoryLimit 属性增加 revision 数量。

#……
spec:
replicas: 3
revisionHistoryLimit: 10 #Deployment revision history存储在它控制的ReplicaSets中。默认保存记录5个
strategy: #设置更新策略
rollingUpdate: #RollingUpdate更新设置
maxSurge: 25% #指定可以超过期望的Pod数量的最大数量。可以是一个绝对值(例如5)或者是期望的Pod数量的百分比(例如10%)。当MaxUnavailable为0时该值不可以为0。通过百分比计算的绝对值向上取整。默认值是1。
maxUnavailable: 25% #指定在升级过程中不可用Pod的最大数量。该值可以是一个绝对值(例如5),也可以是期望Pod数量的百分比(例如10%)。通过计算百分比的绝对值向下取整.
                     #如果.spec.strategy.rollingUpdate.maxSurge 为0时,这个值不可以为0。默认值是1。
type: RollingUpdate #Recreate:重建式更新(首先删除现有的Pod对象,然后由控制器基于新模板重新创建新版本资源对象),rollingUpdate:滚动更新
#……

在配置时,用户还可以使用Deployment控制器的spec.minReadySeconds属性来控制应用升级的速度。新旧更替过程中,新创建的Pod对象一旦成功响应就绪探测即被认为是可用状态,然后进行下一轮的替换。
而spec.minReadySeconds能够定义在新的Pod对象创建后至少需要等待多长的时间才能会被认为其就绪,在该段时间内,更新操作会被阻塞。

总结:

 本次对k8s中Deployment、ReplicaSet、Pod之间的关系有了更深的理解,并通过配置实现了滚动升级、回滚的效果。后续还将继续对k8s的其他特性继续学习。