文章目录
- 一、基本介绍
- 二、应用程序生命周期
- 2.1 部署应用
- 2.2 应用升级
- 2.2.1 修改YAML文件升级（交互式）
- 2.2.2 命令指定镜像版本升级（免交互式）
- 2.2.3 调用vim升级
- 2.3 滚动升级
- 2.3.1 升级流程
- 2.4 应用回滚
- 2.4.1 查看历史发布版本
- 2.4.2 回滚到上一个版本
- 2.4.3 回滚到指定版本
- 2.4.4 验证升级时会访问到新、老两个版本
- 2.5 水平扩缩容
一、基本介绍
基本了解：
- Deployment是最常用的K8s工作负载控制器（Workload Controllers），实际项目部署调试中必用资源之一，所以必须要熟练掌握deploy资源的使用。
- 它是K8s的一个抽象概念，用于更高级层次对象，部署和管理Pod。
- 其他控制器还有DaemonSet、StatefulSet等，不同控制器针对不同的需求服务，比如网页服务、微服务、集群服务、监控服务等，在不同的场景使用可以达到不同的效果。
主要功能：
- 管理Pod和ReplicaSet
- 具有上线部署、副本设定、滚动升级、回滚等功能。
- 应用场景：网站、API、微服务。
deploy在项目中的使用情况：
- 项目的大概流程是，项目立项—>开发团队开发程序——>测试人员进行业务测试——>运维人员部署项目服务——>运维现场调试升级服务或服务回滚——>功能调试完毕，项目闭环
- 在整个流程中，deploy资源都会被高频率的使用到，所以我们需要掌握它的核心功能使用，如何部署应用？如何升级应用？又如何回滚版本？
二、应用程序生命周期
- 这里使用nginx服务来模拟在项目中如何对应用进行部署、升级和回滚。
- 模拟步骤：
- 先部署一个1.16版本的nginx服务。
- 将1.16版本升级到1.17版本，模拟升级。
- 将1.17版本回滚到1.16版本，模拟回滚。
2.1 部署应用
1.编写yaml文件。
[root@k8s-master bck]# cat web666.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: wen666
namespace: test
spec:
replicas: 3
selector:
matchLabels:
app: wen666
template:
metadata:
labels:
app: wen666
spec:
containers:
- name: web
image: nginx:1.16
---
apiVersion: v1
kind: Service
metadata:
name: wen666
namespace: test
spec:
selector:
app: wen666
ports:
- protocol: TCP
port: 80
targetPort: 80
type: NodePort
2.导入yaml文件。
[root@k8s-master bck]# kubectl apply -f web666.yaml
3.查看暴露端口访问网页，此时的nginx版本是1.16。
2.2 应用升级
3种镜像升级方式：
- 修改yaml文件里镜像版本，再命令导入yaml即可升级，kubectl apply -f xxx.yaml
- 直接命令行指定镜像版本免交互式升级，kubectl set image deployment 【deployment名称】【容器名称】=nginx:1.17
- 使用系统编辑器打开，kubectl edit deployment deployment名称】
2.2.1 修改YAML文件升级（交互式）
1.修改yaml文件镜像版本为1.17
2.再次执行apply，导入yaml文件
[root@k8s-master bck]# kubectl apply -f web666.yaml
3.访问网页查看nginx版本为1.17版本。
2.2.2 命令指定镜像版本升级（免交互式）
1.命令升级，指定镜像版本，升级成1.18。
[root@k8s-master bck]# kubectl set image deployment wen666 -n test web=nginx:1.18
2.刷新网页，此时ginx版本为1.18。
2.2.3 调用vim升级
1.命令交互式升级。
[root@k8s-master bck]# kubectl edit deployment wen666 -n test
2.找到镜像版本，修改成1.19，保存升级。
3.访问网页，查看nginx版本为1.19
2.3 滚动升级
主流的发布方案：
- 滚动升级：滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级到新版本。
- 蓝绿升级：将目标服务器分为两组，先升级一组上线没问题后再升级另一组。
- 灰度升级：按照一定百分比升级，例如先升级10%，继续50%，最后剩下的40%。
共同特点：
- 新旧版本平滑过度，用户无感知。
- 以前都是瀑布式升级，一次性升级所有服务器上的服务会导致诸多问题，比如存在升级失败导致的灾难性的数据丢失、爆发性的流量激增导致用户体感降低，等等。
滚动升级模型图：
2.3.1 升级流程
实现原理：
- 我们对pod里的应用升级是使用deployment资源，过程中有个叫做副本集的replicaset资源去完成升级动作。
- 滚动升级时，先升级一小部分Pod，成功后再升级一部分Pod，最终完成所有Pod升级，整个过程始终有Pod在运行，从而保证了业务的连续性。
rs概念：
- replicaset，副本集，简称rs，主要维护Pod副本数量，不断对比当前Pod数量与期望Pod数量。
rs用途：
- deployment每次发布都会创建一个RS作为记录，用于实现滚动升级和回滚。
rs工作原理：
- rs是帮deploy管理pod容器的，对其监控、创建和删除。
- 当超过deploy.yaml里指定的目标容器数量时，则删除多余容器；当小于目标数量时，则创建容器。
滚动升级流程：
- 创建的deploy资源后，就会创建一个rs去维护其下的pod容器，所以升级之前就有一个rs。如下图，rs-1为原本就存在，rs-2为滚动升级时新创建的。rs-1下的3个pod都是正常运行，等待后面的升级，而rs-2刚开始创建时就只有一个正在运行的pod。
- 滚动升级时，先进入deploy阶段1，新生成一个rs-2，rs-2正常创建一个新pod，等这个新pod创建运行成功后，rs-1就缩减一个pod，此时rs-1就只有2个pod。
- 之后进入deploy阶段2，rs-2创建第2个新pod，此时rs-2共有2个pod，一个是刚刚升级完的pod正常运行，一个是正在创建的pod2，而rs-1会在rs-2成功创建第2个pod后再次缩减一个pod，此时rs-1就剩下1个pod。
- 接下来进入deploy阶段3，rs-2创建第3个新pod，创建运行成功后rs-1缩减最后一个pod，此时rs-1就没有pod，而rs-2就有3个新pod，滚动升级完成。
相关命令：
- kubectl get rs #查看RS记录。
- kubectl rollout history deployment 【deploy名称】 #版本对应RS记录。
1.新建一个应用，nginx1.17版本。
[root@k8s-master bck]# kubectl apply -f web666.yaml
2.将1.17版本升级到1.18版本。
[root@k8s-master bck]# kubectl set image deployment wen666 web=nginx:1.18
3.此时镜像版本为1.18，查看rs副本集会有2个，c9结尾代表1.18版本的，86结尾代表1.17版本。
4.将1.18版本升级到1.19版本。
[root@k8s-master bck]# kubectl set image deployment wen666 web=nginx:1.19
5.此时查看副本集RS记录，96结尾的是1.19版本。
6.查看升级流程版本记录。
wen666-696f688c86 # 初次部署1.17版本，3个副本。
wen666-5c899556c9 # 部署1.18版本。
1.17 ————> 1.18升级流程:
1、新建RS，wen666-5c899556c9，并设置副本为1
2、缩容RS，wen666-696f688c86， 副本数由3到2
3、扩容RS，wen666-5c899556c9，副本数由1到2
4、缩容RS，wen666-696f688c86， 副本数由2到1
5、扩容RS，wen666-5c899556c9，副本数由2到3
6、缩容RS，wen666-696f688c86， 副本数由1到0
7.验证rs版本
[root@k8s-master ~]# kubectl get rs
[root@k8s-master ~]# kubectl describe rs wen666-5c899556c9
8.此时1.19————>1.20，查看rs运转流程。若新建第一个pod没成功，则不会继续往下继续创建。
2.4 应用回滚
回滚用途：
- 当项目升级失败时，可以恢复到上一个正常版本。
常用命令：
- kubectl rollout history deployment/web # 查看历史发布版本
- kubectl rollout undo deployment/web # 回滚到上一个版本
- kubectl rollout undo deployment/web --to-revision=2 # 回滚历史指定版本
注意事项：
- 回滚是重新部署某一次部署时的状态，即当时版本所有配置
2.4.1 查看历史发布版本
1.查看发布历史版本记录。
[root@k8s-master ~]# kubectl rollout history deployment wen666
2.显示版本发布记录。
2.4.2 回滚到上一个版本
1.升级1.20版本时失败了。
2.回滚到上一个版本。
[root@k8s-master bck]# kubectl rollout undo deployment wen666
3.查看回滚RS记录流程。
2.4.3 回滚到指定版本
1.查看历史版本记录。
[root@k8s-master ~]# kubectl rollout history deployment wen666
2.查看rs版本对应关系。
[root@k8s-master ~]# kubectl describe $(kubectl get rs -o name)|egrep "revision:|Image:"
3.此时回滚到历史1.19版本。
[root@k8s-master ~]# kubectl rollout undo deployment wen666 --to-revision=3
4.访问网页验证
2.4.4 验证升级时会访问到新、老两个版本
- 版本升级时，会访问到新版本，也会访问到老版本。直到所有的Pod都被替换成新版本，所以会一直能访问到网页。
1.循环访问网页，注意查看版本。
[root@k8s-master ~]# for i in {1..1000} ;do sleep 1 ;curl -I http://192.168.130.145:32659;done
2.升级到1.21版本。
[root@k8s-master bck]# kubectl set image deployment wen666 web=nginx:1.21 --record=true
3.查看访问网页返回的版本，会存在老版本和新版本都能访问到的情况，直到所有的pod都跟换成新rs后，才会一直访问成新版本。
2.5 水平扩缩容
基本了解：
- 水平扩缩容就是对pod副本数量进行增加或减少，依次提高并发。
- pod副本数量是由yaml文件里的replicas值决定，若创建deploy时没有指定副本数则默认创建一个副本。
概念图：
1.给deploy副本增加到10个。
[root@k8s-master ~]# kubectl scale deploy wen666 -n test --replicas=10
2.给deploy副本减少到5个。
[root@k8s-master ~]# kubectl scale deploy wen666 -n test --replicas=5
![[面试题] 判断二维空间中一点是否在旋转矩形内部](https://img-blog.csdnimg.cn/1964d59bcacc4fd48835628ba3881bef.png)
