一、基本介绍

基本了解：

• Deployment是最常用的K8s工作负载控制器（Workload Controllers），实际项目部署调试中必用资源之一，所以必须要熟练掌握deploy资源的使用。
• 它是K8s的一个抽象概念，用于更高级层次对象，部署和管理Pod。
• 其他控制器还有DaemonSet、StatefulSet等，不同控制器针对不同的需求服务，比如网页服务、微服务、集群服务、监控服务等，在不同的场景使用可以达到不同的效果。

主要功能：

• 管理Pod和ReplicaSet
• 具有上线部署、副本设定、滚动升级、回滚等功能。
• 应用场景：网站、API、微服务。

deploy在项目中的使用情况：

1. 项目的大概流程是，项目立项—>开发团队开发程序——>测试人员进行业务测试——>运维人员部署项目服务——>运维现场调试升级服务或服务回滚——>功能调试完毕，项目闭环
2. 在整个流程中，deploy资源都会被高频率的使用到，所以我们需要掌握它的核心功能使用，如何部署应用？如何升级应用？又如何回滚版本？

二、应用程序生命周期

• 这里使用nginx服务来模拟在项目中如何对应用进行部署、升级和回滚。
• 模拟步骤：
  1. 先部署一个1.16版本的nginx服务。
  2. 将1.16版本升级到1.17版本，模拟升级。
  3. 将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种镜像升级方式：

1. 修改yaml文件里镜像版本，再命令导入yaml即可升级，kubectl apply -f xxx.yaml
2. 直接命令行指定镜像版本免交互式升级，kubectl set image deployment 【deployment名称】【容器名称】=nginx:1.17
3. 使用系统编辑器打开，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%。

共同特点：

1. 新旧版本平滑过度，用户无感知。
2. 以前都是瀑布式升级，一次性升级所有服务器上的服务会导致诸多问题，比如存在升级失败导致的灾难性的数据丢失、爆发性的流量激增导致用户体感降低，等等。

滚动升级模型图：

2.3.1 升级流程

实现原理：

• 我们对pod里的应用升级是使用deployment资源，过程中有个叫做副本集的replicaset资源去完成升级动作。
• 滚动升级时，先升级一小部分Pod，成功后再升级一部分Pod，最终完成所有Pod升级，整个过程始终有Pod在运行，从而保证了业务的连续性。

rs概念：

• replicaset，副本集，简称rs，主要维护Pod副本数量，不断对比当前Pod数量与期望Pod数量。

rs用途：

• deployment每次发布都会创建一个RS作为记录，用于实现滚动升级和回滚。

rs工作原理：

1. rs是帮deploy管理pod容器的，对其监控、创建和删除。
2. 当超过deploy.yaml里指定的目标容器数量时，则删除多余容器；当小于目标数量时，则创建容器。
   

滚动升级流程：

1. 创建的deploy资源后，就会创建一个rs去维护其下的pod容器，所以升级之前就有一个rs。如下图，rs-1为原本就存在，rs-2为滚动升级时新创建的。rs-1下的3个pod都是正常运行，等待后面的升级，而rs-2刚开始创建时就只有一个正在运行的pod。
2. 滚动升级时，先进入deploy阶段1，新生成一个rs-2，rs-2正常创建一个新pod，等这个新pod创建运行成功后，rs-1就缩减一个pod，此时rs-1就只有2个pod。
3. 之后进入deploy阶段2，rs-2创建第2个新pod，此时rs-2共有2个pod，一个是刚刚升级完的pod正常运行，一个是正在创建的pod2，而rs-1会在rs-2成功创建第2个pod后再次缩减一个pod，此时rs-1就剩下1个pod。
4. 接下来进入deploy阶段3，rs-2创建第3个新pod，创建运行成功后rs-1缩减最后一个pod，此时rs-1就没有pod，而rs-2就有3个新pod，滚动升级完成。
   

相关命令：

1. kubectl get rs #查看RS记录。
2. 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 # 回滚历史指定版本

注意事项：

1. 回滚是重新部署某一次部署时的状态，即当时版本所有配置

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