Deployment控制器

Deployment控制器官方文档：https://v1-16.docs.kubernetes.io/docs/concepts/workloads/controllers/deployment/ Deployment控制器是K8S的另外一种控制器，它构建于ReplicaSet控制器之上，可以为Pod和ReplicaSet资源提供声明式更新。相比较而言，Pod和ReplicaSet是较低级别的资源，它们很少被直接使用 Deployment控制器资源的主要职责同样是为了保证Pod资源的健康运行，其大部分功能均可通过调用ReplicaSet控制器来实现，同时还增添了部分特性

事件和状态查看：必要时可以查看Deployment对象升级的详细进度和状态
回滚：升级操作完成后发现问题时，支持使用回滚机制将应用返回到前一个或由用户指定的历史记录中的版本上
版本记录：对Deployment对象的每次操作都予以保存，以供后续可能执行的回滚操作使用
暂停和启动：对于每一次升级，都能够随时暂停和启动
多种自动更新方案：一是Recreate，即重建更新机制，全面停止，删除旧有的Pod后用新版本替代；另一个是rollingUpdate，即滚动升级机制，逐步替换旧有的Pod至新的版本

创建Deployment

Deployment是标准的K8S API资源，它构建于ReplicaSet资源之上，于是其spec字段中嵌套使用的字段包含了ReplicaSet控制器支持的replicas、selector、template和minReadySeconds，它也正式利用这些信息完成了其二级资源ReplicaSet对象的创建。下面是一个Deployment控制器资源的配置清单示例

apiVersion: apps/v1
kind: Deployment
metadata:
 name: deploy-damo
spec:
 replicas: 2
 selector:
   matchLabels:
     app: deploy-damo
 template:
   metadata:
     labels:
       app: deploy-damo
   spec:
     containers:
     - name: deploy-busybox
       image: registry.cn-hangzhou.aliyuncs.com/jiangyida/busybox:0.2
       ports:
       - name: http
         containerPort: 80

从上面的内容可以看出，除了控制器类型和名称之外，它与前面ReplicaSet控制器示例中的内容几乎没用什么不同。后面将会讲解如何使用它

[root@k8s-master01 nginx]# kubectl apply -f busybox-deploy.yaml --record
deployment.apps/deploy-damo created
[root@k8s-master01 nginx]#
[root@k8s-master01 nginx]# 
[root@k8s-master01 nginx]# 
[root@k8s-master01 nginx]# kubectl get pods
NAME                           READY   STATUS      RESTARTS   AGE
client                         0/1     Completed   0          11d
deploy-damo-5b9c97f4ff-bvqf2   1/1     Running     0          2m52s
deploy-damo-5b9c97f4ff-lwxhz   1/1     Running     0          2m52s
my-nginx-854bbd7557-xnbn9      1/1     Running     0          10d
rs-2f26b                       1/1     Running     0          9h
rs-wgn2p                       1/1     Running     0          9h
test                           1/1     Running     0          7d
test-nodeselector1             1/1     Running     0          3d9h
[root@k8s-master01 nginx]#

kubectl get deployment命令可以列出创建的Deployment对象及其相关的信息，下面显示的字段中,UP-TO-DATE表示以及达到期望状态的Pod副本数量，AVAILABLE则表示当前处于可用状态的应用程序的数量

[root@k8s-master01 nginx]# kubectl get deployment
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
deploy-damo   2/2     2            2           103s
[root@k8s-master01 nginx]#

Deployment控制器会自动创建相关的ReplicaSet控制器资源，并以”[DEPLOYMENT-NAME]-[POD-TEMPLATE-HAS-VALUE]”格式为其命名，其中的hash值由deployment控制器自动生成。由Deployment创建的ReplicaSet对象会自动使用相同的标签选择器，因此可使用如下的命令查看其相关的信息

[root@k8s-master01 nginx]# kubectl get rs -l "app=deploy-damo"
NAME                     DESIRED   CURRENT   READY   AGE
deploy-damo-5b9c97f4ff   2         2         2       7m58s
[root@k8s-master01 nginx]
如果deployment控制器设置的标签与之前使用的rs标签相同，会发现rs与deployemtn并不会冲突
[root@k8s-master01 nginx]# kubectl get pods -l "app=rs-damo" -L app
NAME                           READY   STATUS    RESTARTS   AGE     APP
deploy-damo-5b9c97f4ff-bvqf2   1/1     Running   0          76s     rs-damo
deploy-damo-5b9c97f4ff-lwxhz   1/1     Running   0          2m28s   rs-damo
rs-2f26b                       1/1     Running   0          93m     rs-damo
rs-wgn2p                       1/1     Running   0          93m     rs-damo
[root@k8s-master01 nginx]#

相关的Pod对象的信息可以用相似的命令进行获取，下面的命令结果中，Pod对象的名称遵循ReplicaSet控制器的命名格式，它以ReplicaSet控制器的名称为前缀，后跟5位随机字符

[root@k8s-master01 nginx]# kubectl get pods -l "app=deploy-damo" -L app
NAME                           READY   STATUS    RESTARTS   AGE     APP
deploy-damo-5b9c97f4ff-bvqf2   1/1     Running   0          3m47s   deploy-damo
deploy-damo-5b9c97f4ff-lwxhz   1/1     Running   0          3m47s   deploy-damo
[root@k8s-master01 nginx]#

由此印证了Deployment借助于ReplicaSet管理Pod资源的机制，于是可以得知，其大部分管理操作与ReplicaSet相同。不过，Deployment也有ReplicaSet所不具备的部分高级共，这其中最著名的当属其自动滚动更新的机制

更新策略

如前面所述，ReplicaSet控制器的应用更新需要手动分成多步并以特定的次序进行，过程复杂且容易出错，而Deployment却只需要由用户指定在Pod模板中要改动的内容，例如，容器的镜像版本，剩余的步骤可交由其自动完成，同样，更新应用程序的规模也只需要修改期望的Pod副本数量，余下的事情交给Deployment控制器即可

Deployment控制器详细信息中包含了其更新策略的相关配置信息，如deploy-damo控制器资源，kubectl describe命令中输出的”StrategyType”和”RollingUpdateStrategy”字段等

[root@k8s-master01 nginx]# kubectl describe deployment deploy-damo
Name:                   deploy-damo
Namespace:              default
CreationTimestamp:      Mon, 15 Jun 2020 19:20:31 +0800
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 1
                        kubectl.kubernetes.io/last-applied-configuration:
                          {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"name":"deploy-damo","namespace":"default"},"spec":{"replicas":2,...
Selector:               app=deploy-damo
Replicas:               2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=deploy-damo
  Containers:
   deploy-busybox:
    Image:        registry.cn-hangzhou.aliyuncs.com/jiangyida/busybox:0.2
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   deploy-damo-5b9c97f4ff (2/2 replicas created)
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  4m11s  deployment-controller  Scaled up replica set deploy-damo-5b9c97f4ff to 5
  Normal  ScalingReplicaSet  2m5s   deployment-controller  Scaled down replica set deploy-damo-5b9c97f4ff to 2
[root@k8s-master01 nginx]#

Deployment控制器支持两种更新策略：滚动更新（rolling update）和重建创建（recreate），默认是滚动更新。重新创建更新类似于前面中的ReplicaSet的第一种更新方式，即首先删除现有的Pod对象，而后由控制器基于新模板重新创建出新版本资源对象。通常，只应该在应用的新版本不兼容运行时才会使用recreate策略，因为它会导致应用替换期间暂时不可用，好处在于它不存在中间状态，用户访问到的要么是新版本，要么是旧版本

滚动升级是默认的更新策略，它在删除一部分旧版本Pod资源的同时，补充创建一部分新版本的Pod资源进行应用升级，其优势是升级期间，容器中应用提供的服务不会中断，但要求应用程序能够应对新旧版本同时工作的情形，例如新旧版本兼容同一个数据库方案等。不过，更新操作期间，不同客户端得到的响应内容可能会来自不同版本的应用

Deployment控制器的滚动更新操作并非在同一个ReplicaSet控制器对象下删除并创建Pod资源，而是将它们分置于两个不同的控制器之下：旧控制器的Pod对象数量不断减少的同时，新控制器的Pod对象数量不断增加，直到旧控制器不再拥有Pod对象，而新控制器的副本数量变得完全符合期望值，如下图

滚动更新时，应用升级期间还要确保可用的Pod对象数量不低于某阈值以确保可用持续处理客户端的服务请求，变动的方式和Pod对象的数量范围将通过spec.strategy.rollingUpdate.maxSurge和spec.strategy.rollingUpdate.maxUnavailable两个属性协同进行定义，它们的功能如下

maxSurge：指定升级期间存在的总Pod对象数量最多可以超出期望值的个数，其值可用是0或者正整数，也可以是一个期望值的百分比；例如，如果期望值为3，当前的属性值为1，则表示Pod对象的总数不能超过4个
maxUnavailable：升级期间正常可用的Pod副本数（包括新旧版本）最多不能低于期望值的个数，也可以是一个期望值的百分比；默认值为1，该值意味着如果期望值是3，则升级期间至少要有两个Pod对象处于正常提供服务的状态

注意：maxSurge和maxUnavailable属性的值不可同时为0，否则Pod对象的副本数量在符合用户的期望值后无法做出合理变动以进行滚动更新

配置时，用户还可以使用Deployment控制器的spec.minReadySeconds属性来控制应用升级的速度，新旧更替过程中，新创建的Pod对象一旦成功响应就绪探测即被视作可用，而后即可立即开始下一轮的替换操作。而spec.minReadySeconds能够定义在新的Pod对象创建后至少要等待多久才会将其视作就绪，在此期间，更新操作会被阻塞。因此，它可用用来让K8S在每次创建出Pod资源后都要等上一段时长后再开始下一轮的更替，这个时间长度的理想值是等到Pod对象中的应用以及可用接收并处理请求流量。事实上，一个精心设计的等待时长和就绪性探测能让K8S系统规避一部分因程序BUG而导致的升级故障

Deployment控制器也支持用户保留其滚动更新历史中的旧ReplicaSet对象版本，这赋予了控制器进行应用回滚的能力：用户可按需回滚到指定的历史版本。控制器可保存的历史版本数量由spec.revisionHitsoryLimit属性进行定义。当然，也只有保存于revision历史中的ReplicaSet版本可用于回滚，因此，用户要习惯性的在更新操作时指定保留版本

注意：为了保存版本升级的历史，需要在创建Deployment对象时在命令中使用--record选项

尽管滚动更新以节约系统资源著称，但它也存在一些劣势。直接改动现有环境，会使系统引入不确定风险，而且升级过程出现问题后，执行回滚操作也会较为缓慢。有鉴于此，金丝雀部署可能是较为理想的实现方式，当然，如果不考虑系统资源的可用性，那么传统的蓝绿部署也是不错的选择

升级deployment

修改Pod模板相关的配置参数便能完成Deployment控制器资源的更新。由于是声明式配置，因此对deployment控制器资源的修改尤其适合使用apply和patch命令来进行；当然，如果仅仅只是修改容器镜像“set imgae”命令更为易用解下来通过更新之前创建的Deployment控制器deploy-damo来了解更新操作过程的执行细节，为了使得升级过程便于观测，这里先使用kubectl patch命令为其spec.minReadySeconds字段定义一个等待时长

[root@k8s-master01 nginx]# kubectl explain deployment.spec.minReadySeconds
KIND:     Deployment
VERSION:  apps/v1
FIELD:    minReadySeconds <integer>
DESCRIPTION:
     Minimum number of seconds for which a newly created pod should be ready
     without any of its container crashing, for it to be considered available.
     Defaults to 0 (pod will be considered available as soon as it is ready)
[root@k8s-master01 nginx]#
[root@k8s-master01 nginx]# kubectl patch deployment deploy-damo -p '{"spec": {"minReadySeconds": 5}}'
deployment.apps/deploy-damo patched
[root@k8s-master01 nginx]#

patch命令的补丁形式为json格式，以-p选项指定，上面命令中的’{“spec”: {“minReadySeconds”: 5}}’表示设置spec.minReadySeconds属性的值。入要改变deploy-damo中容器的镜像，也可以使用patch命令，如’{“spec”: {“containers”:[“name”:”deploy-damo”,”image”:”registry.cn-hangzhou.aliyuncs.com/jiangyida/busybox:0.1”]}}’，不过，修改容器镜像更为简单的专用命令为”set image” 注意：修改Deployment控制器的minReadySeconds、replicas和strategy等字段的值并不会触发Pod资源的更新，因为它们不属于模板的内嵌字段，对现存的Pod对象不会产生任何影响

接着，使用”registry.cn-hangzhou.aliyuncs.com/jiangyida/busybox:0.2”镜像，修改Pod模板的容器镜像，启动Deployment控制器的滚动更新过程

[root@k8s-master01 nginx]# kubectl set image deployment deploy-damo deploy-busybox=registry.cn-hangzhou.aliyuncs.com/jiangyida/busybox:0.2 --record
deployment.apps/deploy-damo image updated
[root@k8s-master01 nginx]#

使用kubect rollout status命令可用于打印滚动更新过程中的状态信息

[root@k8s-master01 nginx]# kubectl rollout status deployment deploy-damo
deployment "deploy-damo" successfully rolled out
[root@k8s-master01 nginx]#

还可以使用kubectl get deployment --watch命令监控其更新过程中Pod对象的变动过程

[root@k8s-master01 nginx]# kubectl get deployment deploy-damo --watch
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
deploy-damo   1/2     2            1           4h35m
deploy-damo   2/2     2            2           4h35m

滚动更新时，deploy-damo控制器会创建一个新的ReplicaSet控制器对象来管控新版本的Pod对象，升级完成后，旧版本的ReplicaSet会保留在历史记录中，但其此前的管控Pod对象将会被删除

[root@k8s-master01 nginx]# kubectl get rs -l app=deploy-damo
NAME                     DESIRED   CURRENT   READY   AGE
deploy-damo-5b9c97f4ff   0         0         0       4h37m
deploy-damo-76969596fd   2         2         2       5m53s
[root@k8s-master01 nginx]#

deploy-damo控制器管控的Pod资源对象也将随之更新为新版的ReplicaSet名称deploy-damo-76969596fd，为前缀的Pod副本，命令结果如下

[root@k8s-master01 nginx]# kubectl get pods -l app=deploy-damo
NAME                           READY   STATUS    RESTARTS   AGE
deploy-damo-5b9c97f4ff-bvqf2   1/1     Running   0          8m19s
deploy-damo-5b9c97f4ff-lwxhz   1/1     Running   0          8m19s
[root@k8s-master01 nginx]#

通过上述结果可用看到Pod已经处于READY状态，可以从集群的任意节点发起访问

[root@k8s-master01 nginx]# kubectl get pods -l app=deploy-damo -o wide
NAME                           READY   STATUS    RESTARTS   AGE     IP            NODE            NOMINATED NODE   READINESS GATES
deploy-damo-5b9c97f4ff-bvqf2   1/1     Running   0          8m31s   10.244.38.8   172.18.15.114   <none>           <none>
deploy-damo-5b9c97f4ff-lwxhz   1/1     Running   0          8m31s   10.244.38.7   172.18.15.114   <none>           <none>
[root@k8s-master01 nginx]#
[root@k8s-node01 cert]# curl 10.244.38.8
this is test Version V1 V1 V1 V1 V1
[root@k8s-node01 cert]#

金丝雀发布

Deployment控制器还支持自定义控制更新过程中的滚动节奏，如“暂停(pause)”或“继续(resume)”更新操作，尤其是借助于前文讲到的maxSurge和maxUnavailable属性还能够实现更为精巧的过程控制。比如，待第一批新的Pod资源创建完成之后立即暂停更新过程，此时，仅存在一小部分新版本的应用，主体部分还是旧的版本。然后，再根据用户特征精心筛选出小部分用户的请求路由至新版的Pod应用，并持续观察其是否能稳定的按期望的方式运行。确定没用问题后再继续完成余下Pod资源的滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布

直接发布新应用版本的在线发布形式中，金丝雀发布是一种较为妥当的方式。不过，这里只设计其部署操作的相关步骤，发布方式则通常依赖于具体的环境设置。解下来说明如何在K8S上使用Deployment控制器实现金丝雀部署

为了尽可能的降低现有系统及其容量的影响，金丝雀发布过程通常建议采用“先添加，再删除，且可用Pod资源对象总数不低于期望值”的方式进行。首次添加的Pod对象数量取决于其接入的第一批请求的规则及单个Pod的承载能力，视具体需求而定，为了能够简单的说明问题，接下来采用首批添加1个Pod资源的方式。将Deployment控制器的maxSurge属性的值设置为1，并将maxUnavailable属性的值设置为0

[root@k8s-master01 nginx]# kubectl patch deployment deploy-damo -p '{"spec": {"strategy":{"rollingUpdate":{"maxSurge": 1,"maxUnavailable": 0}}}}'
deployment.apps/deploy-damo patched
[root@k8s-master01 nginx]#

解下来，启动deploy-damo控制器的更新过程，在修改响应容器的镜像版本后立即暂停更新进度，它会在启动第一批新版本Pod对象的创建操作之后转为暂停状态。需要注意的是，这里之所以能够在第一批更新启动后就暂停，有赖于此前为maxReadySeconds属性设置的时长，因此用户要在命令启动后的此时长指定的时间范围内启动暂停操作，如下图。当然，对kubectl命令来说，也可以直接以&&符合在shell中连接两个命令

[root@k8s-master01 nginx]# kubectl set image deployment deploy-damo deploy-busybox=registry.cn-hangzhou.aliyuncs.com/jiangyida/busybox:0.1 --record && kubectl rollout pause deployment deploy-damo
deployment.apps/deploy-damo image updated
deployment.apps/deploy-damo paused
[root@k8s-master01 nginx]#

通过其状态查看命令可用得到，在创建完一个新版本的Pod资源后滚动更新操作暂停

[root@k8s-master01 nginx]# kubectl rollout status deployment deploy-damo
Waiting for deployment "deploy-damo" rollout to finish: 1 out of 2 new replicas have been updated...
[root@k8s-master01 nginx]#
并且可用看到当前有3个Pod副本在运行，而我们replicas定义的是2个
[root@k8s-master01 nginx]# kubectl get pods -l app=deploy-damo
NAME                           READY   STATUS        RESTARTS   AGE
deploy-damo-5b9c97f4ff-bvqf2   1/1     Terminating   0          9m49s
deploy-damo-5b9c97f4ff-lwxhz   1/1     Terminating   0          9m49s
deploy-damo-76969596fd-8vzjs   1/1     Running       0          18s
deploy-damo-76969596fd-k2l5r   1/1     Running       0          24s
[root@k8s-master01 nginx]#

相关的Pod列表也可能显示旧版本的ReplicaSet的所有Pod副本扔在正常运行，新版的ReplicaSet也包含一个Pod副本，但最多不超过期望值的1个，deploy-damo原有的期望值为2，因此总数不超过3个。此时，通过Service或ingress资源及相关的路由策略等设定，即可将一部分用户的流量引入到这些Pod之上进行发布验证。运行一段时间后，如果确认没问题，既可以使用kubectl rollout resume命令继续此前的滚动更新过程

[root@k8s-master01 nginx]# kubectl rollout resume deployment deploy-damo
deployment.apps/deploy-damo resumed
[root@k8s-master01 nginx]#

使用kubectl rollout status命令监控到滚动更新过程完成后，即可通过deploy-damo控制器及其ReplicaSet和Pod对象的相关信息了解其结果状态

[root@k8s-master01 nginx]# kubectl rollout status deployment deploy-damo
deployment "deploy-damo" successfully rolled out
[root@k8s-master01 nginx]#
通过如下可以看到，旧的Pod已经进入terminating状态，而新的Pod也已经READY
[root@k8s-master01 nginx]# kubectl get pods
NAME                           READY   STATUS        RESTARTS   AGE
client                         0/1     Completed     0          11d
deploy-damo-5b9c97f4ff-lwxhz   0/1     Terminating   0          10m
deploy-damo-76969596fd-8vzjs   1/1     Running       0          39s
deploy-damo-76969596fd-k2l5r   1/1     Running       0          45s
my-nginx-854bbd7557-xnbn9      1/1     Running       0          10d
rs-2f26b                       1/1     Running       0          9h
rs-wgn2p                       1/1     Running       0          9h
test                           1/1     Running       0          7d1h
test-nodeselector1             1/1     Running       0          3d9h
[root@k8s-master01 nginx]#

然而，如果“金丝雀”遭遇不幸，那么回滚操作变成了解下来的任务

回滚Deployment控制器下的应用发布

若因各自原因导致滚动更新无法正常运行，如镜像文件获取失败”金丝雀”遇险等，则应该将应用回滚到之前的版本，或者回滚到由用户指定的版本。Deployment控制器的回滚操作可用使用kkubectl rollout undo命令完成等回滚完成后，验证deploy-damo的ReplicaSet控制器对象是否已恢复到指定的历史版本以确保其回滚正常完成

1.可用看到目前使用的镜像版本是busybox:0.1
[root@k8s-master01 nginx]# kubectl get deployment deploy-damo -o wide
NAME          READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS       IMAGES                                                    SELECTOR
deploy-damo   2/2     2            2           10m   deploy-busybox   registry.cn-hangzhou.aliyuncs.com/jiangyida/busybox:0.1   app=deploy-damo
[root@k8s-master01 nginx]#
2.使用undo回滚
[root@k8s-master01 nginx]# kubectl rollout undo deployment deploy-damo
deployment.apps/deploy-damo rolled back
[root@k8s-master01 nginx]#
[root@k8s-master01 nginx]# kubectl get pods
NAME                           READY   STATUS        RESTARTS   AGE
client                         0/1     Completed     0          11d
deploy-damo-5b9c97f4ff-mvw4l   1/1     Terminating   0          2m8s
deploy-damo-5b9c97f4ff-srkcp   1/1     Terminating   0          2m14s
deploy-damo-76969596fd-6mkxm   1/1     Running       0          12s
deploy-damo-76969596fd-dp6pq   1/1     Running       0          5s
my-nginx-854bbd7557-xnbn9      1/1     Running       0          10d
rs-2f26b                       1/1     Running       0          9h
rs-wgn2p                       1/1     Running       0          9h
test                           1/1     Running       0          7d
test-nodeselector1             1/1     Running       0          3d8h
[root@k8s-master01 nginx]#
可用看到回退到了busybox:v2
[root@k8s-master01 nginx]# kubectl get deployment deploy-damo -o wide
NAME          READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS       IMAGES                                                    SELECTOR
deploy-damo   2/2     2            2           11m   deploy-busybox   registry.cn-hangzhou.aliyuncs.com/jiangyida/busybox:0.2   app=deploy-damo
[root@k8s-master01 nginx]#

如果想要回滚到指定的历史版本，可用在kubectl rollout undo命令上使用--to-revision选项指定revision号即可回滚到指定的历史版本

[root@k8s-master01 nginx]# kubectl rollout history deployment deploy-damo
deployment.apps/deploy-damo 
REVISION  CHANGE-CAUSE
2         <none>
4         kubectl set image deployment deploy-damo deploy-busybox=registry.cn-hangzhou.aliyuncs.com/jiangyida/busybox:0.1 --record=true
5         kubectl set image deployment deploy-damo deploy-busybox=registry.cn-hangzhou.aliyuncs.com/jiangyida/busybox:0.2 --record=true
[root@k8s-master01 nginx]#

比如回滚到revision号为4的记录

[root@k8s-master01 nginx]# kubectl rollout undo deployment deploy-damo --to-revision=4
deployment.apps/deploy-damo rolled back
[root@k8s-master01 nginx]#
[root@k8s-master01 nginx]# kubectl get pods -l app=deploy-damo
NAME                           READY   STATUS        RESTARTS   AGE
deploy-damo-5b9c97f4ff-t7kkc   1/1     Terminating   0          82s
deploy-damo-5b9c97f4ff-xlsbn   1/1     Terminating   0          88s
deploy-damo-76969596fd-h26v2   1/1     Running       0          15s
deploy-damo-76969596fd-nc6kg   1/1     Running       0          8s
[root@k8s-master01 nginx]#
[root@k8s-master01 nginx]# kubectl get deployment deploy-damo -o wide
NAME          READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS       IMAGES                                                    SELECTOR
deploy-damo   2/2     2            2           12m   deploy-busybox   registry.cn-hangzhou.aliyuncs.com/jiangyida/busybox:0.1   app=deploy-damo
[root@k8s-master01 nginx]#

回滚操作中，其revision记录中的信息也会发生变动,回滚操作会呗当作一次滚动更新追加进历史记录中，而被回滚的条目则会被删除。需要注意的是，如果当前的滚动更新过程处于“暂停”状态，那么回滚操作旧需要先将Pod模板的版本改回到之前的版本，然后“继续”更新，否则，就会一直处于暂停状态而无法回滚

扩容和缩容

通过修改.spec.replicas即可修改Deployment控制器中的Pod资源的副本数量，它将实时作用于控制器并直接生效。Deployment控制器是声明式配置，repicas属性的值可直接修改资源配置文件，然后使用kubectl apply进行应用，也可以使用kubectl edit对其进行实时修改。而前一种方式能够将修改结果予以长期留存另外,kubectl scale是专用于扩展某些控制器类型的应用规模的命令，包括Deployment和Job等。而Deployment通过repicaSet控制其Pod资源，因此扩缩容的方式是相同的，除了命令直接作用的资源对象有所不同之外。

1.将replicas修改为5个
[root@k8s-master01 nginx]# cat busybox-deploy.yaml |grep replicas
  replicas: 5
[root@k8s-master01 nginx]#
2.然后重新应用
[root@k8s-master01 nginx]# kubectl apply -f busybox-deploy.yaml --record
deployment.apps/deploy-damo configured
[root@k8s-master01 nginx]#
3.查看Pod资源
[root@k8s-master01 nginx]# kubectl get pods -l app=deploy-damo
NAME                           READY   STATUS    RESTARTS   AGE
deploy-damo-5b9c97f4ff-9cf96   1/1     Running   0          68s
deploy-damo-5b9c97f4ff-jjwxf   1/1     Running   0          68s
deploy-damo-5b9c97f4ff-mjrnl   1/1     Running   0          68s
deploy-damo-5b9c97f4ff-n4ztf   1/1     Running   0          29m
deploy-damo-5b9c97f4ff-rkjpw   1/1     Running   0          29m
[root@k8s-master01 nginx]#
或者可用使用如下命令修改replicas字段
[root@k8s-master01 nginx]# kubectl edit deployment deploy-damo
或者可以使用scale进行扩展伸缩
[root@k8s-master01 nginx]# kubectl scale deployment deploy-damo --replicas=3
deployment.apps/deploy-damo scaled
[root@k8s-master01 nginx]#

Kubernetes

关于Pod控制器(三)之Deployment控制器

Deployment控制器

创建Deployment

更新策略

升级deployment

金丝雀发布

回滚Deployment控制器下的应用发布

扩容和缩容