什么是deployment 声明式升级应用

前言

环境：centos7.9 docker-ce-20.10.9 kubernetes-version v1.22.6

deployment资源对象

deployment是企业中用的最多的pod控制器。
Deployment为Pod和Replica Set提供声明式更新，只需要在 Deployment 中描述想要的目标状态是什么，，比如pod副本数等，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。

Deployment、ReplicaSet、Pod三者的关系图

通过下面这张图我们可以看得出来，deployment创建/管理ReplicaSet，ReplicaSet创建/管理pod。replicaset的名字其实就deployment的名字+pod模板的哈希值，而pod的名字就是replicaset的名字+随机字符串构成的，这样我们从一个pod的名称就很明显的知道该pod由哪个replicaset创建的以及对应的deployment是哪个：

注意：Deployment滚动更新的实现，依赖的是Kubernetes中的ReplicaSet，Deployment控制器实际操纵的，就是Replicas对象，而不是Pod对象。

创建一个deployment资源

deployment创建/管理ReplicaSet，ReplicaSet创建/管理pod，即deployment不能直接管理pod，它创建了ReplicaSet管理pod

[root@master deployment]# cat deplyment_nginx.yaml  #编写yaml资源文件
apiVersion: apps/v1
kind: Deployment                                    #创建一个deployment对象
metadata: name: deployment-nginxlabels: env: devtiar: frontnamespace: default
spec:replicas: 3                                        #3个pod副本selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- image: nginx:1.7.9name: nginx-containerimagePullPolicy: IfNotPresentports:- name: http containerPort: 80
[root@master deployment]# kubectl create -f deplyment_nginx.yaml --record  #创建deployment
[root@master deployment]# kubectl get deployments.apps deployment-nginx        #查看deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
deployment-nginx   3/3     3            3           29d
[root@master deployment]# kubectl get rs deployment-nginx-79c59dd6d8       #查看rs
NAME                          DESIRED   CURRENT   READY   AGE
deployment-nginx-79c59dd6d8   3         3         3       29d
[root@master deployment]# kubectl describe rs deployment-nginx-79c59dd6d8  #查看rs的详细信息
Name:           deployment-nginx-79c59dd6d8
Namespace:      default
Selector:       app=nginx,pod-template-hash=79c59dd6d8
Labels:         app=nginxpod-template-hash=79c59dd6d8
Annotations:    deployment.kubernetes.io/desired-replicas: 3deployment.kubernetes.io/max-replicas: 4deployment.kubernetes.io/revision: 1
Controlled By:  Deployment/deployment-nginx                 #这里看得出rs是由Deployment/deployment-nginx创建的
Replicas:       3 current / 3 desired
Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:Labels:  app=nginxpod-template-hash=79c59dd6d8                       #pod模板的哈希值Containers:nginx-container:Image:        nginx:1.7.9Port:         80/TCPHost Port:    0/TCPReadiness:    exec [ls /var/ready] delay=5s timeout=2s period=10s #success=1 #failure=3Environment:  <none>Mounts:       <none>Volumes:        <none>
Events:           <none>
[root@master deployment]#
[root@master deployment]# kubectl get pods -l app=nginx
NAME                                 READY   STATUS    RESTARTS      AGE
deployment-nginx-79c59dd6d8-5cfzp    1/1     Running   1 (24h ago)   29d
deployment-nginx-79c59dd6d8-cm2k7    1/1     Running   1 (24h ago)   27d
deployment-nginx-79c59dd6d8-cqjtr    1/1     Running   1 (24h ago)   27d#查看pod的详细信息也可以看得出来pod是由ReplicaSet创建的
[root@master deployment]# kubectl describe  pods deployment-nginx-79c59dd6d8-5cfzp | grep 'Controlled By'
Controlled By:  ReplicaSet/deployment-nginx-79c59dd6d8
[root@master deployment]#

deployment的升级更新策略

Deployment更新一般是指更新镜像版本，deployment支持两种镜像更新策略：重建更新和滚动更新，可以通过strategy参数进行配置，strategy参数用于指定更新的策略，其主要支持两个属性：

1、RollingUpdate 滚动更新，默认策略就是滚动更新，RollingUpdate策略会渐进的删除旧的pod，与此同时创建新的pod，使应用在整个升级的过程中处于可用的状态，并确保其处理请求的能力没有因为升级而有所影响，这就是deployment默认使用的升级策略，升级过程中pod的数量可以在期望副本数的一定区间内浮动，其上限和下线是可配置的，如果应用能够支撑多个版本同时对外提供服务，则推荐使用这个策略升级应用。
2、Recreate，这种策略会一次性删除旧的pod，然后创建新的pod，Recreate策略会在删除旧的pod之后才创建新的pod，如果应用程序不支持多个版本同时在线，那么合适使用这种策略，不过这种策略到导致应用短暂的不可用。

下面这两个参数是对滚动更新而言，即更新策略的type=RollingUpdate生效：maxUnavailable：用来指定在升级过程中不可用pod的最大数量，默认是25%。maxSurge：用来指定在升级过程中可以超过预期的pod的最大数量，默认是25%。

deployment的升级方式、使用 kubectl set image 命令升级

deployment升级，无法就是修改pod模板的镜像版本，而修改pod模板镜像版本有很多命令可以直接操作，如下：

[root@master ~]# kubectl edit deployments.apps deployment-nginx     #使用edit命令在线编辑镜像名称版本
[root@master ~]# kubectl apply  -f deplyment_nginx.yaml            #编辑yaml文件里的镜像名称版本后再apply

但是，我们这次来讲一个更专业的更新镜像版本的命令，即kubectl set image命令。kubectl set image命令主要用于更新一个资源对象里的容器镜像。比如更新 pod (po), replicationcontroller (rc), deployment (deploy), daemonset (ds), statefulset (sts), cronjob (cj), replicaset
(rs)的等资源的镜像版本。

语法：kubectl set image (-f filename | type name) container_name_1=container_image_1 ...
范例:

 # Set a deployment's nginx container image to 'nginx:1.9.1', and its busybox container image to 'busybox'kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1# Update all deployments' and rc's nginx container's image to 'nginx:1.9.1'kubectl set image deployments,rc nginx=nginx:1.9.1 --all# Update image of all containers of daemonset abc to 'nginx:1.9.1'kubectl set image daemonset abc *=nginx:1.9.1# Print result (in yaml format) of updating nginx container image from local file, without hitting the serverkubectl set image -f path/to/file.yaml nginx=nginx:1.9.1 --local -o yaml#升级deloymentkubectl set image deployment/deployment-nginx nginx-container=nginx:1.8kubectl set image deployment/deployment-nginx nginx-container=nginx:1.14kubectl set image deployment/deployment-nginx nginx-container=nginx:latest

kubectl rollout 命令

kubectl rollout 命令主要是针对控制器资源进行管理,比如在升级过程中进行暂停、继续、版本回退、查看状态、查看历史版本等操作， kubectl rollout可以操作的资源对象如下：

deployments
daemonsets
statefulsets

语法：  kubectl rollout SUBCOMMAND [options]

 kubectl rollout可使用下面的子命令：history     显示升级历史版本记录pause       暂停版本升级过程restart     重启版本升级过程resume      继续已经暂停的版本升级过程status      查看当前升级状态undo        回滚到上一版本，可以使用--to-revision回滚到指定的版本示例：# 查看deployment的版本历史kubectl rollout history deployment deployment-nginx# 查看deployment的指定的第1版本信息kubectl rollout history deployment/deployment-nginx --revision=1# 回滚deployment到上一次的版本kubectl rollout undo deployment/deployment-nginx# 回滚deployment到指定的第2版本kubectl rollout undo deployment/deployment-nginx --to-revision=2# 查看daemonset的滚动更新状态kubectl rollout status daemonset/foo# 查看deployment的滚动更新状态kubectl rollout status deployment/deployment-nginx

deployment的升级、回滚原理、使用kubectl rollout undo 命令进行回滚

deployment升级之后，其实背后升级原理是deployment是创建了一个新的ReplicaSet来替代旧的ReplicaSet，这样由新版本ReplicaSet创建的pod就运行了新的应用程序从而实现了版本升级，而回滚原理也是，就是将原来新的ReplicaSet创建的pod删掉，pod数量变成0，然后将指定版本的ReplicaSet重新创建pod，这样就成功实现回滚了。

[root@master deployment]# kubectl get rs
NAME                                DESIRED   CURRENT   READY   AGE
deployment-nginx-65b57dccf4         0         0         0       39m     #旧版本的rs的pod都是0
deployment-nginx-65f6846d8b         0         0         0       41m     #旧版本的rs的pod都是0
deployment-nginx-7bb7db669d         3         3         3       27m     #当前版本的rs的pod是3
deployment-nginx-7dfd97b4dc         0         0         0       28m     #旧版本的rs的pod都是0
[root@master deployment]#
#查看所有历史升级版本
[root@master deployment]# kubectl rollout history deploment/deployment-nginx
#指定查看第3个版本，有详细信息，能看到镜像的版本
[root@master deployment]# kubectl rollout history deployment/deployment-nginx --revision=3
# 回滚deployment到上一次的版本
[root@master deployment]# kubectl rollout undo deployment/deployment-nginx
# 回滚deployment到指定的第2版本
[root@master deployment]# kubectl rollout undo deployment/deployment-nginx --to-revision=2

kubectl rollout history 查看历史版本信息

[root@master deployment]# kubectl rollout history deployment/deployment-nginx   #看到版本号,但看不出来具体什么变更
deployment.apps/deployment-nginx
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>
4        <none>
[root@master deployment]# kubectl rollout history deployment/deployment-nginx --revision=3    #指定查看第3个版本，有详细信息
deployment.apps/deployment-nginx with revision #3
Pod Template:Labels:       app=nginxpod-template-hash=7dfd97b4dcContainers:nginx-container:Image:      nginx:1.14Port:       80/TCPHost Port:  0/TCPEnvironment:        <none>Mounts:     <none>Volumes:      <none>
[root@master deployment]# kubectl rollout history deployment/deployment-nginx --revision=4    #指定查看第4个版本，有详细信息
deployment.apps/deployment-nginx with revision #4
Pod Template:Labels:       app=nginxpod-template-hash=7bb7db669dContainers:nginx-container:Image:      nginx:latestPort:       80/TCPHost Port:  0/TCPEnvironment:        <none>Mounts:     <none>Volumes:      <none>

暂停滚动升级、恢复滚动升级

#升级的时候立即暂停升级
[root@master ~]# kubectl set image deployment/deployment-nginx nginx-container=nginx:1.8 && kubectl rollout pause deployment/deployment-nginx
#查看rs的变化
[root@master ~]# kubectl get rs
NAME                                DESIRED   CURRENT   READY   AGE
deployment-nginx-65f6846d8b         3         3         3       39s     #原来的pod数据也没变
deployment-nginx-65b57dccf4         1         1         1       14s     #新产生了一个pod
#查看滚动升级的状态
[root@master ~]# kubectl rollout status  deployment/deployment-nginx
Waiting for deployment "deployment-nginx" rollout to finish: 1 out of 3 new replicas have been updated...# 可以看到，以上使用kubectl rollout pause 命令暂停了升级，而已经产生的新pod 仍然可以接收客户端的请求，这样，一部分流量就会被分流到新
# pod，如果用户用的没有问题，那么就可以继续升级，这就是金丝雀发布。#恢复升级
[root@master deployment]# kubectl rollout resume deployment/deployment-nginx
deployment.apps/deployment-nginx resumed
#可以看到现在升级已经完成，新的rs的pod已经是3个，旧的rs的pod是0个
[root@master ~]# kubectl  get rs
NAME                                DESIRED   CURRENT   READY   AGE
deployment-nginx-65b57dccf4         3         3         3       8m9s
deployment-nginx-65f6846d8b         0         0         0       8m34s
[root@master ~]#

历史版本数量限制，使用revisionHistoryLimit参数

我们知道了deployment升级原理是通过创建新的replicaset实现，回滚原理是通过将当前版本的replicaset创建的pods删掉，然后重新创建指定版本的replicaset的pods来实现回滚，但是当升级的次数越来越多了，就会存在越来越多的replicaset，kubernetes提供revisionHistoryLimit参数来限制历史版本数量，如下：

#使用revisionHistoryLimit参数限制保存的历史版本,当超过设置的数值,旧的replicaset就会被删掉,revisionHistoryLimit默认值是10
[root@master deployment]# kubectl explain deployment.spec.revisionHistoryLimit

滚动升级策略的maxSurge和maxUnavailable属性

# maxSurge参数表示允许超过期望副本数最大比例（或最大值）
[root@master deployment]# kubectl explain  deployments.spec.strategy.rollingUpdate.maxSurge
#maxUnavailable参数表示不可用副本数最大比例（或最大值）
[root@master deployment]# kubectl explain  deployments.spec.strategy.rollingUpdate.maxUnavailable

maxSurge：和期望ready的副本数比，超过期望副本数最大比例（或最大值），这个值调的越大，副本更新速度越快。
maxUnavailable：和期望ready的副本数比，不可用副本数最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑；

minReadySecond参数指定至少要成功运行多久后，才能将pod视为可用

minReadySecond属性指定新创建的pod至少要成功运行多久之后，才能将其视为可用，minReadySecond的主要功能是避免部署出错版本的应用，而不只是单纯的减慢部署速度。

[root@master ~]# kubectl explain  deployment.spec.minReadySeconds       #默认值是0，即只要新pod就绪就认为可用

一般设置就绪探针，如果一个新的pod运行出错，并在minReadySecond时间内它的就绪探针出现失败，那么新版本的滚动更新将被阻止。
通过minReadySecond属性可以让pod就绪之后继续等待n秒，然后继续执行滚动升级，来减缓升级的过程。
如果只定义就绪探针而没有正确设置minReadySecond，那么一旦有一次就绪探针调用成功，变回认为新的pod已经处于可用状态，因此最好适当的设置minReadySecond的值。

progressDeadlineSeconds参数，为滚动升级配置超时失败时间

使用progressDeadlineSeconds可以配置滚动升级的超时时间，默认是600s即10分钟，如果超过该progressDeadlineSeconds设定的时间，滚动升级仍未完成，则升级被视为失败，升级过程自动取消。

[root@master ~]# kubectl explain  deployment.spec.progressDeadlineSeconds

注意：人为使用kubectl rollout pause 命令暂停的升级过程不能被视为超时。

deployment缩容、扩容

1、直接编辑yaml文件里面的replicas字段，然后kubectl apply -f deplyment_nginx.yaml即可；或者在线编辑pod控制器修改replicas字段亦可。

2、使用kubectl scale命令直接缩容、扩容，命令有如下这些：

 # Scale a replica set named 'foo' to 3kubectl scale --replicas=3 rs/foo# Scale a resource identified by type and name specified in "foo.yaml" to 3kubectl scale --replicas=3 -f foo.yaml# If the deployment named mysql's current size is 2, scale mysql to 3kubectl scale --current-replicas=2 --replicas=3 deployment/mysql# Scale multiple replication controllerskubectl scale --replicas=5 rc/foo rc/bar rc/baz# Scale stateful set named 'web' to 3kubectl scale --replicas=3 statefulset/web#对deployment进行扩容、缩容[root@master deployment]# kubectl scale --replicas=5 deployment/deployment-nginx

deployment应用下线

如果确认应用不在提供服务，可将用于下线，如上：
1、如果是yaml部署的，删除yaml文件即可，kubectl delete -f xx.yaml (会把该yaml创建的资源都删除)
2、命令行删除：kubectl delete deployment/deployment-nginx

总结

1、Deployment、ReplicaSet、Pod三者的关系
deployment创建/管理ReplicaSet，ReplicaSet创建/管理pod。replicaset的名字其实就deployment的名字+pod模板的哈希值，而pod的名字就是
replicaset的名字+随机字符串构成的，这样我们从一个pod的名称就很明显的知道该pod由哪个replicaset创建的以及对应的deployment是哪个。2、deployment的升级更新策略
deployment支持两种镜像更新策略：重建更新和滚动更新，可以通过strategy参数进行配置，strategy参数主要支持两个属性：
(1)、RollingUpdate 滚动更新，默认策略就是滚动更新，RollingUpdate策略会渐进的删除旧的pod，与此同时创建新的pod，使应用在整个升级的过
程中处于可用的状态，并确保其处理请求的能力没有因为升级而有所影响，这就是deployment默认使用的升级策略，升级过程中pod的数量可以在期望副
本数的一定区间内浮动，其上限和下线是可配置的，如果应用能够支撑多个版本同时对外提供服务，则推荐使用这个策略升级应用。
(2)、Recreate，这种策略会一次性删除旧的pod，然后创建新的pod，Recreate策略会在删除旧的pod之后才创建新的pod，如果应用程序不支持多个版
本同时在线，那么合适使用这种策略，不过这种策略到导致应用短暂的不可用。下面这两个参数是对滚动更新策略而言，即更新策略的type=RollingUpdate生效：maxUnavailable：用来指定在升级过程中不可用pod的最大数量，默认是25%。maxSurge：用来指定在升级过程中可以超过预期的pod的最大数量，默认是25%。3、deployment的升级方式
[root@master ~]# kubectl edit deployments.apps deployment-nginx        #使用edit命令在线编辑镜像名称版本
[root@master ~]# kubectl apply  -f deplyment_nginx.yaml            #编辑yaml文件里的镜像名称版本后再apply
#使用kubectl set image 命令对镜像进行升级
[root@master ~]# kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.14、kubectl rollout 命令kubectl rollout 可使用下面的子命令：history     显示升级历史版本记录pause       暂停版本升级过程restart     重启版本升级过程resume      继续已经暂停的版本升级过程status      查看当前升级状态undo        回滚到上一版本，可以使用--to-revision回滚到指定的版本# 查看deployment的版本历史
[root@master ~]# kubectl rollout history deployment deployment-nginx
# 查看deployment的指定的第1版本信息
[root@master ~]# kubectl rollout history deployment/deployment-nginx --revision=1
# 回滚deployment到上一次的版本
[root@master ~]# kubectl rollout undo deployment/deployment-nginx
# 回滚deployment到指定的第2版本
[root@master ~]# kubectl rollout undo deployment/deployment-nginx --to-revision=2
# 查看daemonset的滚动更新状态
[root@master ~]# kubectl rollout status daemonset/foo
# 查看deployment的滚动更新状态
[root@master ~]# kubectl rollout status deployment/deployment-nginx5、deployment的升级、回滚原理
deployment升级之后，其实背后升级原理是deployment是创建了一个新的ReplicaSet来替代旧的ReplicaSet，这样由新版本ReplicaSet创建的pod就
运行了新的应用程序从而实现了版本升级，而回滚原理也是，就是将原来新的ReplicaSet创建的pod删掉，pod数量变成0，然后将指定版本ReplicaSet
重新创建pod，这样就成功实现回滚了。6、revisionHistoryLimit、minReadySecond、progressDeadlineSeconds属性
使用revisionHistoryLimit参数限制保存的历史版本,当超过设置的数值,旧的replicaset就会被删掉,revisionHistoryLimit默认值是10
[root@master deployment]# kubectl explain deployment.spec.revisionHistoryLimitminReadySecond参数指定至少要成功运行多久后，才能将pod视为可用
[root@master ~]# kubectl explain  deployment.spec.minReadySeconds      #默认值是0，即只要新pod就绪就认为可用progressDeadlineSeconds参数，为滚动升级配置超时失败时间，默认是600s即10分钟，如果超过该progressDeadlineSeconds设定的时间，滚动
升级仍未完成，则升级被视为失败，升级过程自动取消。
[root@master ~]# kubectl explain  deployment.spec.progressDeadlineSeconds
注意：人为使用kubectl rollout pause 命令暂停的升级过程不能被视为超时。7、deployment的缩容、扩容
直接编辑yaml文件里面的replicas字段，然后`kubectl apply -f deplyment_nginx.yaml`即可；或者在线编辑pod控制器修改replicas字段亦可；
[root@master ~]# kubectl scale --replicas=5 deployment/deployment-nginx                       #对deployment进行扩容、缩容