---

一、Deployment简介

Deployment为Pod和ReplicaSet提供了一个声明式定义方法，在Kubernets中是一种资源控制器，用来替代以前的ReplicationController来方便管理应用，典型的应用场景包括：

• 定义Deployment来创建Pod和ReplicaSet
• 滚动升级和回滚应用
• 扩容和缩容
• 暂停和继续Deployment

二、使用Deployment部署nginx

实验环境：

• K8s集群可以正常使用
• K8s可以正常从镜像仓库拉取镜像

1.编写yaml文件使用Deployment

代码如下：

[root@k8s-master test]# cat nginx-deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
 selector:                                    #定义标签选择器
  matchLabels:                                #定义匹配的标签，必须要设置
   app: nginx                                 #匹配的目标标签     
 replicas: 3                                  #开启Pod的数量
 template:                                    #定义模板，必须定义，模板是起到描述要创建的pod的作用
  metadata:                                   #定义模板元数据
    labels:                                   #定义模板label，Deployment.spec.template.metadata.labels   
     app : nginx                              #定义标签，必须等于 matchLabels 定义的标签

  spec:                                     
   containers:
   - image: msxt.harbor.com/k8s/nginx:1.18.0    #我的镜像是从本地的Harbor上拉取
     name: nginx                                 #镜像名称
     ports:
     - containerPort: 80                         #定义容器使用的端口

上面是使用Deployment控制器部署nginx

运行yaml文件

kubectl apply -f nginx-deployment.yaml 

查看Deployment状态

kubectl get deployment

查看pod

kubectl get pods

pod正在运行，接下来暴露端口，让用户可以通过外网进行访问。

---

2、使用Service暴露nginx端口

代码如下：

[root@k8s-master test]# cat service.yaml 
apiVersion: v1        
kind: Service              #kind类型Service
metadata:                  #类型元数据
 name: nginx-service       #元数据名称
spec: 
 selector:                 #定义标签选择器
  app: nginx               #这里填写的nginx要跟Deployment的标签名称一致才能进行匹配
 ports:                     #开启一个端口参数
 - protocol: TCP            #定义TCP协议
   port: 80                 #定义Service端口
   targetPort: 80           #目标Pod的端口
   nodePort: 31000          #node节点暴露的SSL端口
 type: NodePort             ##NodePort表示在宿主机打开一个监听端口；service的类型，定义服务的访问方式，默认为ClusterIP(不会再宿主机打开一个监听端口，只为k8s内部提供服务)，service.spec.type
 

运行Service.yaml文件暴露端口

kubectl apply -f service.yaml

获取service信息

kubectl get svc

之后在任意节点上访问http://127.0.0.1:31000端口即可

三、滚动升级和回滚版本

1、滚动升级

复制部署Deployment的yaml文件

 [root@k8s-master test]# cp nginx-deployment.yaml nginx-deployment-v2.yaml

编辑nginx-deployment-v2.yaml文件
代码如下：

[root@k8s-master test]# cat  nginx-deployment-v2.yaml 
apiVersion: apps/v1                
kind: Deployment                         
metadata:
  name: nginx-deploy                         
spec:      
 minReadySeconds: 5                        #在原有的基础上新增
 strategy:                                 #在原有的基础上新增  
 type: RollingUpdate                       #在原有的基础上新增
  rollingUpdate:                           #在原有的基础上新增
    maxSurge: 1                            #在原有的基础上新增
    maxUnavailable: 1                      #在原有的基础上新增
 selector:
  matchLabels:
   app: nginx
 replicas: 3
 template:
  metadata:
    labels:
     app : nginx

  spec:
   containers:
   - image: msxt.harbor.com/k8s/nginx:1.18.0          #改成要升级的镜像版本，其他不变
     name: nginx        
     ports:
     - containerPort: 80

字段解释：
minReadySeconds
Kubernetes在等待设置的时间后才进行升级
如果没有设置该值，Kubernetes会假设该容器启动起来后就提供服务了，所以这个可以设置的保守一些，比如我们的服务启动从3-20秒不等，我可以设置成30秒，这样防止pod启动了但是服务还没准备好导致系统不可用。

maxSurge
升级过程中最多可以比原先设置多出的POD数量
例如：maxSurage=1，replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD，整个升级过程中最多会有5+1个POD。

maxUnavaible
升级过程中最多有多少个POD处于无法提供服务的状态，当maxSurge不为0时，该值也不能为0，最好和maxSurge保持一致。
例如：maxUnavaible=1，则表示Kubernetes整个升级过程中最多会有1个POD处于无法服务的状态，可以保证有足够的pod（或者认为是足够的性能）提供服务。

---

滚动升级命令

修改了Yaml文件执行：

kubectl apply -f nginx-deployment-v2.yaml

查看滚动升级状态

kubectl rollout status deployment nginx-deploy

暂停升级

kubectl rollout pause deployment nginx-deploy

恢复升级

kubectl rollout resume deployment nginx-deploy

升级后查看Pod和Rs的信息

[root@k8s-master test]# kubectl get pods

可以看到现在查询的Pod运行时间都在40s左右，说明是刚启动的Pod

再来看看Rs的情况
这里会有两个nginx-Deployment

为什么会有两个?
因为Deployment的回滚操作就是由Rs找到以上的版本，Rs不会删除之前部署的版本，除非人工设置或人工删除掉以前的版本，但长期保留过早的版本会占用系统资源，所有保留的版本历史还是需要设置

现在很显然Rs已经部署了一套新的nginxPod

也可以查看详细信息

 kubectl describe deployment nginx-deploy

这里的镜像变成1.18.0
底下的信息就是Pod替换掉的信息

接下来进行访问nginx测试是否升级成功
在任意节点访问http://127.0.0.1:31000
访问可能会有延迟，耐心等待

进入容器里查看nginx版本
查看pod，随便选取一个pod进入

[root@k8s-master test]# kubectl get pods

进入容器

[root@k8s-master test]# kubectl exec -it nginx-deploy-7669c9d749-f5dv6 -- /bin/bash

查看nginx版本

nginx -v 

滚动升级完成

2、回滚版本

我们已经能够滚动平滑的升级我们的Deployment了，但是如果升级后的POD出了问题该怎么办？我们能够想到的最好最快的方式当然是回退到上一次能够提供正常工作的版本，Deployment就为我们提供了回滚机制

查看之前历史版本，在这里我显示3和4，是因为我之前做过所以有保存的历史。

kubectl rollout history deployment nginx-deploy

查看某一次的revison信息

[root@k8s-master test]# kubectl rollout history deployment nginx-deploy --revision=3

–revision=3 这里表示的是查看第三个历史版本信息

下面就是滚动升级前的版本信息。

接下来进行回滚操作
回滚到某一版本

kubectl rollout undo deployment nginx-deploy --to-revision=3

如果不加–to-revision=3参数，就默认回滚到上一个版本

回滚完成后，查看Rs信息
可以看到Rs的deploy已经回到第一个了，代表回滚成功

接着进行验证
访问nginx地址：http://127.0.0.1:31000

再进入容器查看nginx版本
要重新查看pod，因为已经把新的Pod更换成之前的了。

已经回滚回来了。