入门Kubernetes - 滚动升级/回滚
一、前言
上一篇文章中对yaml文件格式进行了解,并对k8s中各种主要资源通过yaml创建时的定义模板。接来下就进一步学习k8s的各种特点。并应用在示例中。
接下来先实现.Net Core Api程序版本滚动升级、回滚,并在过程中进一步的对k8s进行了解
二、滚动升级
1、推送新版本服务镜像v3到docker hub。
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 的版本来实现。如下图:
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 名字 + 随机字符串。
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
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的其他特性继续学习。