入门Kubernetes - 滚动升级/回滚
入门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 AGEk8sweb-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-CAUSE1 kubectl.exe apply --filename=k8s-dep.yaml --record=true2 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- kubectl rollout undo deployment/k8sweb-deployment --to-revision=
c）配置历史记录保存数量
可以在 Deployment 配置文件中通过 revisionHistoryLimit 属性增加 revision 数量。
strategy: rollingUpdate: maxSurge: % maxUnavailable: % type: RollingUpdate
在配置时，用户还可以使用Deployment控制器的spec.minReadySeconds属性来控制应用升级的速度。新旧更替过程中，新创建的Pod对象一旦成功响应就绪探测即被认为是可用状态，然后进行下一轮的替换。
而spec.minReadySeconds能够定义在新的Pod对象创建后至少需要等待多长的时间才能会被认为其就绪，在该段时间内，更新操作会被阻塞。
总结：
本次对k8s中Deployment、ReplicaSet、Pod之间的关系有了更深的理解，并通过配置实现了滚动升级、回滚的效果。后续还将继续对k8s的其他特性继续学习。
来源https://www.cnblogs.com/cwsheng/p/14969804.html