Pod控制器Deployment使用详解（更新策略、回滚策略、暂停策略）以及金丝雀发布详解_pod deployment limit

需要注意：
 在学习kubernetes时需要高清RC和deployment两着各自的不同点。
官方建议使用Deployment管理ReplicaSets，而不是直接使用ReplicaSet，这就意味着可能永远不需要直接操作ReplicaSet对象，因此Deployment将会是使用最频繁的资源对象。

创建deploy

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: ikubernetes/myapp:v1
        ports:
        - containerPort: 80
          name: http
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Deployment

更新策略

 使用RS或者RC控制器需要手动分成多步去更新，过程繁杂且容易出错，而deployment却只需要由用户指定在Pod模板中要更改的内容，例如容器镜像的版本，余下的步骤可以自动完成。同时更新规模也需要修改为期望的副本数量，余下的事情交给deployment即可。
 deployment控制器的详细信息中包含了其跟更新策略的相关配置信息。使用describe即可查看，如下：

[root@master redis-demo]# kubectl get deploy -A
NAMESPACE       NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
ingress-nginx   nginx-ingress-controller   1/1     1            1           8d
kube-system     coredns                    2/2     2            2           21d
1
2
3
4

使用describe查看到输出的命令中包含：
strategytype
RollingupdateStrategy
等字段

[root@master redis-demo]# kubectl describe deploy nginx-ingress-controller -n ingress-nginx
Name:                   nginx-ingress-controller
Namespace:              ingress-nginx
CreationTimestamp:      Mon, 02 Dec 2019 17:55:50 +0800
Labels:                 app.kubernetes.io/name=ingress-nginx
                        app.kubernetes.io/part-of=ingress-nginx
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app.kubernetes.io/name=ingress-nginx,app.kubernetes.io/part-of=ingress-nginx
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:           app.kubernetes.io/name=ingress-nginx
                    app.kubernetes.io/part-of=ingress-nginx
  Annotations:      prometheus.io/port: 10254
                    prometheus.io/scrape: true
  Service Account:  nginx-ingress-serviceaccount
  Containers:
   nginx-ingress-controller:
    Image:       quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.24.1
    Ports:       80/TCP, 443/TCP
    Host Ports:  0/TCP, 0/TCP
    Args:
      /nginx-ingress-controller
      --configmap=$(POD_NAMESPACE)/nginx-configuration
      --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
      --udp-services-configmap=$(POD_NAMESPACE)/udp-services
      --publish-service=$(POD_NAMESPACE)/ingress-nginx
      --annotations-prefix=nginx.ingress.kubernetes.io
    Liveness:   http-get http://:10254/healthz delay=10s timeout=10s period=10s #success=1 #failure=3
    Readiness:  http-get http://:10254/healthz delay=0s timeout=10s period=10s #success=1 #failure=3
    Environment:
      POD_NAME:        (v1:metadata.name)
      POD_NAMESPACE:   (v1:metadata.namespace)
    Mounts:           <none>
  Volumes:            <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Progressing    True    NewReplicaSetAvailable
  Available      True    MinimumReplicasAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-ingress-controller-688987f6c9 (1/1 replicas created)
Events:          <none>
[root@master redis-demo]# 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

 Deployment控制器支持两种更新策略：滚动更新（rolling updata）和 重新构建（recreate），默认情况下为滚动更新。重新创建为：先删除所有的Pod再根据新的模板创建新的Pod，中间会导致服务的不可用，用户要么使用的是新版本，要么就是旧版本。
 滚动升级是默认的更新策略，它在删除一些旧版本的Pod的同时补充创建一些新的Pod，更新期间服务不会中断。
 滚动更新期间，应用升级期间还要确保可用的Pod对象数量不低于某些阈值。，确保可以持续处理客户端请求。变动的方式和Pod对象的数量范围将通过==spec.strategy.roollingUpdata.maxSurge和spec.strategy.roollingUpdata.maxunavailable两个属性协同进行定义。两个参数用法如下：

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

maxSurge和maxUnavailable的数量不能同时为0，否则Pod对象的复本数量在符合用户期望的数量后无法做出合理变动以进行滚动更新操作。

 配置时，用户还可以使用 Deployment控制器的 spec.min.Ready.Seconds属性来控制应用升级的速度。新旧更替过程中，新创建的Pod对象一旦成功响应就绪探测即被视作可用，而后即可立即开始下一轮的替换操作。而 spec.minReady.Seconds能够定义在新的Pod对象创建后至少要等待多久才会将其视作就绪，在此期间，更新操作会被阻塞。因此，它可以用来让 Kubernetes在每次创建出Pod资源后都要等上一段时长后再开始下一轮的更替，这个时间长度的理想值是等到Pod对象中的应用已经可以接受并处理请求流量。事实上，一个精心设计的等待时长和就绪性探测能让 Kubernetes系统规避一部分因程序Bug而导致的升级故障。
 Deployment控制器也支持用户保留其滚动更新历史中的旧 Replicase对象版本，如
图5-10所示，这赋予了控制器进行应用回滚的能力:用户可按需回滚到指定的历史版本。
控制器可保存的历史版本数量由“ spec revision History Limit”属性进行定义。当然，也只有保存于 revision历史中的 Replicase版本可用于回滚，因此，用户要习惯性地在更新操作时指定保留旧版本。

为了在保存版本升级的历史，需要在创建deployment对象时在命令中使用"–record"选项

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

升级策略

 修改Pod模板相关的配置参数便能完成 Deployment控制器资源的更新。由于是声明式配置，因此对 Deployment控制器资源的修改尤其适合使用 apply和 patch命令来进行;当然，如果仅是修改容器镜像，“ set image”命令更为易用。
创建Pod

[root@master nginx-demo]# kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
myapp-deployment-869b99788d-fp74z   1/1     Running   0          29s
myapp-deployment-869b99788d-jddnr   1/1     Running   0          29s
myapp-deployment-869b99788d-qkqmt   1/1     Running   0          29s
1
2
3
4
5

 接下来通过更新此前创建的 Deployment控制器 deploy-example来了解更新操作过程的执行细节，为了使得升级过程更易于观测，这里先使用“ kubectl patch”命令为其specmin Ready Seconds字段定义一个等待时长，例如8s:
修改配置，更换镜像

[root@master nginx-demo]# kubectl patch deployments myapp-deployment -p '{"spec":{"minReadySeconds":8}}'
deployment.extensions/myapp-deployment patched (change)
[root@master nginx-demo]# kubectl set image deployments myapp-deployment myapp=ikubernetes/myapp:v2
deployment.extensions/myapp-deployment image updated
1
2
3
4

patch命令的补丁形式为Json格式，以-p选项指定，上面命令中的’{“spec”:{“minReadySeconds”:8}}‘表示设置spec.minReady.Seconds属性的值。若要改变 myapp- deploy中 myapp容器的镜像，也可使用 patch命令，如’{“spec”: {“contianers”: [“name”: “myapp”,“image”“ikubernetes/myapp: v2”]}}’，不过修改容器镜像有更加简单的专有命令‘set image’
查看状态

[root@master nginx-demo]# kubectl rollout status deployments myapp-deployment
Waiting for deployment "myapp-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "myapp-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "myapp-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "myapp-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "myapp-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "myapp-deployment" rollout to finish: 1 old replicas are pending termination...
deployment "myapp-deployment" successfully rolled out
[root@master nginx-demo]# kubectl get deployments myapp-deployment --watch
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
myapp-deployment   3/3     3            3           9m44s
1
2
3
4
5
6
7
8
9
10
11

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

[root@master nginx-demo]# kubectl get replicasets -l app=myapp
NAME                          DESIRED   CURRENT   READY   AGE
myapp-deployment-7c5bf99bbf   3         3         3       100s
myapp-deployment-869b99788d   0         0         0       10m

[root@master nginx-demo]# kubectl get pods -l app=myapp
NAME                                READY   STATUS    RESTARTS   AGE
myapp-deployment-7c5bf99bbf-jkktz   1/1     Running   0          96s
myapp-deployment-7c5bf99bbf-skpbn   1/1     Running   0          115s
myapp-deployment-7c5bf99bbf-zxhx7   1/1     Running   0          2m14s
1
2
3
4
5
6
7
8
9
10

测试显示已经更换了版本v2

[root@master nginx-demo]# curl $(kubectl get pods myapp-deployment-7c5bf99bbf-jkktz -o go-template={{.status.podIP}})
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>
1
2

关于金丝雀发布

扩展知识

矿井中的金丝雀
 17世纪，英国工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯气体，金丝雀也会停止歌唱；当瓦斯含量查过一定限度时，人类依然毫无察觉，而金丝雀却早已毒发身亡。当时在采矿设备相对简陋的情况下，工人们每次下井都会带上一直金丝雀作为瓦斯检测工具，以便在危险状况下紧急撤离。

发布规则

 在更新时执行暂停操作，通过Service或Ingress资源和相关的路由策略将部分用户的请求流量引入到这些新的Pod之上进行发布验证，运行一段时间后，如果确定没有问题，即可使用kubectl roollout resume"命令继续滚动更新过程。

发布流程

回滚策略

1：kubectl rollout history 检查Deployment部署历史
2：kubectl rollout undo deployment/… --revision=2

暂停策略

kubectl roollout pause deployment/…