Kubernetes控制器之Deployment

Kubernetes控制器之Deployment
　　官方参考：https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/

　　　　　　　https://www.kubernetes.org.cn/deployment

　　Deployments

　　Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController来方便的管理应用。典型的应用场景包括：
- 定义Deployment来创建Pod和ReplicaSet
- 滚动升级和回滚应用
- 扩容和缩容
- 暂停和继续Deployment
　　你只需要在Deployment中描述你想要的目标状态是什么，Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态。你可以定义一个全新的Deployment，也可以创建一个新的替换旧的Deployment。

　　一个典型的用例如下
- 使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态，看它是成功还是失败。
- 然后，通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet，Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。
- 如果当前状态不稳定，回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision。
- 扩容Deployment以满足更高的负载。
- 暂停Deployment来应用PodTemplateSpec的多个修复，然后恢复上线。
- 根据Deployment 的状态判断上线是否hang住了。
- 清除旧的不必要的ReplicaSet。
　　创建Deployment

　　下面是 Deployment 示例。创建一个 ReplicaSet 展开三个 nginx Pods：

　　该示例为官方示例下载地址是
```
https://raw.githubusercontent.com/kubernetes/website/master/content/zh/examples/controllers/nginx-deployment.yaml
```
　　
```
# cat nginx-deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.15.4
        name: nginx
        ports:
        - containerPort: 80
```
　　也可以通过以下命令生成该yaml文档然后修改
```
# kubectl create deployment nginx-deployment --image=nginx:1.15.4 --dry-run -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: nginx-deployment
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-deployment
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx-deployment
    spec:
      containers:
      - image: nginx:1.15.4
        name: nginx
        resources: {}
status: {}
```
　　在该例中
- 创建名为nginx-deployment的Deployment，由metadata.name字段指示
- Deployment创建3个复制的Pods，由spec.replicas字段指示，该字段可以没有默认即为1
- selector字段定义Deployment如何查找要管理的Pods。在这种情况下只需要在Pod模板(app:nginx)中定义的标签。
```
注意：`matchLabels` 字段是 {key,value} 的映射。单个 {key,value}在 `matchLabels` 映射中的值等效于 `matchExpressions` 的元素，其键字段是“key”，运算符为“In”，值数组仅包含“value”。所有要求，从 `matchLabels` 和 `matchExpressions`，必须满足才能匹配。
```
- template字段包含以下子字段
- Pod使用labels字段标记为app:nginx
- template.spec字段指示Pod运行一个容器nginx
- 创建一个容器并使用name字段将其命名为nginx
　　通过运行以下命令创建Deployment
```
kubectl apply -f nginx-deployment.yaml
```
```
注意：将kubectl的 —record 的flag设置为 true可以在annotation中记录当前命令创建或者升级了该资源。这在未来会很有用，例如，查看在每个Deployment revision中执行了哪些命令。
```
　　--record示例如下

　　运行kubectl get deployments 以检查 Deployment 是否已创建。输出以下内容：
```
# kubectl get deployment
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment         3/3     3            3           48s
```
　　显示以下字段
```
`READY` 3/3左边3是真正运行的副本数右边3是期望的副本数即replicas定义的副本数。
`UP-TO-DATE`显示已更新以实现期望状态的副本数。
`AVAILABLE`显示应用程序可供用户使用的副本数。
`AGE` 显示应用程序运行的时间量。
```
　　要查看Deployment创建的ReplicaSet（rs），运行kubectl get rs输出
```
# kubectl get rs
NAME                                DESIRED   CURRENT   READY   AGE
nginx-deployment-67656986d9         3         3         3       108s
```
　　
```
请注意， ReplicaSet 的名称始终被格式化为`[DEPLOYMENT-NAME]-[RANDOM-STRING]`。随机字符串是随机生成并使用 pod-template-hash 作为种子
```
　　要查看每个Pod自动生成的标签，运行kubectl get pods --show-labels输出
```
# kubectl get pods --show-labels
NAME                                      READY   STATUS    RESTARTS   AGE     LABELS
nginx-deployment-67656986d9-996kk         1/1     Running   0          3m35s   app=nginx,pod-template-hash=67656986d9
nginx-deployment-67656986d9-fgdwz         1/1     Running   0          3m35s   app=nginx,pod-template-hash=67656986d9
nginx-deployment-67656986d9-j8jt8         1/1     Running   0          3m35s   app=nginx,pod-template-hash=67656986d9
```
　　刚创建的Replica Set将保证总是有3个nginx的pod存在。并且创建的Pod名为[DEPLOYMENT-NAME]-[pod-template-hash]-[RANDOM-STRING]
```
注意： 你必须在Deployment中的selector指定正确pod template label（在该示例中是 app = nginx），不要跟其他的controller搞混了（包括Deployment、Replica Set、Replication Controller等）。Kubernetes本身不会阻止你这么做，如果你真的这么做了，这些controller之间会相互打架，并可能导致不正确的行为。
```
　　Pod-template-hash 标签
```
注意：不要更改此标签
```
　　Deployment 控制器将 pod-template-hash 标签添加到 Deployment 创建或使用的每个 ReplicaSet 。

　　此标签可确保 Deployment 的子 ReplicaSets 不重叠。它通过对 ReplicaSet 的 PodTemplate 进行哈希处理，并使用生成的哈希值添加到 ReplicaSet 选择器、Pod 模板标签,并在 ReplicaSet 可能具有的任何现有 Pod 中。

　　更新Deployment
```
注意： Deployment的rollout当且仅当Deployment的pod template（例如.spec.template）中的label更新或者镜像更改时被触发。其他更新，例如扩容Deployment不会触发rollout。
```
　　安装以下步骤更新Deployment

　　首先修改yaml把nginx版本修改成1.7.9

　　应用一下各项nginx Pods，使用nginx:1.9.1镜像，而不是nginx:1.7.9
```
# kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
deployment.apps/nginx-deployment image updated
```
　　说明：设置更新Deployment名为nginx-deployment镜像的镜像为nginx:1.9.1

　　也可以使用edit命令来编辑Deployment，修改 .spec.template.spec.containers[0].image ，将nginx:1.7.9 改写成nginx:1.9.1。
```
kubectl edit deployment/nginx-deployment
```
　　修改完输出
```
deployment.apps/nginx-deployment edited
```
　　查看rollout的状态，只要执行：
```
# kubectl rollout status deployment/nginx-deployment
deployment "nginx-deployment" successfully rolled out
```
　　rollout成功后查看deployment
```
# kubectl get deployment
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment         3/3     3            3           9m37s
```
　　UP-TO-DATE的replica的数目已经达到了配置中要求的数目。

　　CURRENT的replica数表示Deployment管理的replica数量，AVAILABLE的replica数是当前可用的replica数量。

　　我们通过执行kubectl get rs可以看到Deployment更新了Pod，通过创建一个新的Replica Set并扩容了3个replica，同时将原来的Replica Set缩容到了0个replica。
```
# kubectl get rs
NAME                                DESIRED   CURRENT   READY   AGE
nginx-deployment-54f57cf6bf         0         0         0       12m
nginx-deployment-56f8998dbc         3         3         3       9m6s
```
　　执行 get pods只会看到当前的新的pod:
```
# kubectl get pod
NAME                                      READY   STATUS    RESTARTS   AGE
nginx-deployment-56f8998dbc-8j49x         1/1     Running   0          5m25s
nginx-deployment-56f8998dbc-fpzwt         1/1     Running   0          5m26s
nginx-deployment-56f8998dbc-r2wvp         1/1     Running   0          5m28s
```
　　下次更新这些Pod的时候，只需要更新Deployment中pod的template即可

　　Deployment 可确保在更新时仅关闭一定数量的 Pods。默认情况下，它确保至少 75%所需 Pods 运行（25%最大不可用）。

　　Deployment 还确保仅创建一定数量的 Pods 高于期望的 Pods 数。默认情况下，它可确保最多增加 25% 期望 Pods 数（25%最大增量）。

　　例如，如果仔细查看上述 Deployment ，将看到它首先创建了一个新的 Pod，然后删除了一些旧的 Pods，并创建了新的 Pods。它不会杀死老 Pods，直到有足够的数量新的 Pods 已经出现，并没有创造新的 Pods，直到足够数量的旧 Pods 被杀死。它确保至少 2 个 Pods 可用，并且总共最多 4 个 Pods 可用。

　　获取Deployment更多信息
```
# kubectl describe deployments nginx-deployment
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Fri, 20 Mar 2020 16:01:54 +0800
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 2
                        kubectl.kubernetes.io/last-applied-configuration:
                          {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"app":"nginx"},"name":"nginx-deployment","namespace":"d...
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.9.1
    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:   nginx-deployment-56f8998dbc (3/3 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  53s   deployment-controller  Scaled up replica set nginx-deployment-54f57cf6bf to 3
  Normal  ScalingReplicaSet  8s    deployment-controller  Scaled up replica set nginx-deployment-56f8998dbc to 1
  Normal  ScalingReplicaSet  6s    deployment-controller  Scaled down replica set nginx-deployment-54f57cf6bf to 2
  Normal  ScalingReplicaSet  6s    deployment-controller  Scaled up replica set nginx-deployment-56f8998dbc to 2
  Normal  ScalingReplicaSet  5s    deployment-controller  Scaled down replica set nginx-deployment-54f57cf6bf to 1
  Normal  ScalingReplicaSet  5s    deployment-controller  Scaled up replica set nginx-deployment-56f8998dbc to 3
  Normal  ScalingReplicaSet  3s    deployment-controller  Scaled down replica set nginx-deployment-54f57cf6bf to 0
```
　　可以看到，当第一次创建 Deployment 时，它创建了一个 ReplicaSet （nginx-deployment-54f57cf6bf）并将其直接扩展至 3 个副本。更新 Deployment 时，它创建了一个新的 ReplicaSet （nginx-deployment-56f8998dbc），并将其扩展为 1，然后将旧 ReplicaSet 缩小到 2，以便至少有 2 个 Pod 可用，并且最多创建 4 个 Pod。然后，它继续向上和向下扩展新的和旧的 ReplicaSet ，具有相同的滚动更新策略。最后，将有 3 个可用的副本在新的 ReplicaSet 中，旧 ReplicaSet 将缩小到 0。

　　Rollover（多个rollout并行）　　

　　每当Deployment controller观测到有新的Deployment被创建时，如果没有已存在的ReplicaSet来创建期望个数的Pod的话，就会创建一个新的ReplicaSet来做这件事。如果更新了Deployment,则控制其标签的Pods的现有ReplicaSet匹配.spec.selector但是template跟.spec.tmplate不匹配的Pod缩容。最终，新的ReplicaSet将会扩容出.spec.replicas指定数目的Pod，旧的Replica Set会缩容到0。

　　如果你更新了一个的已存在并正在进行中的Deployment，每次更新Deployment都会创建一个新的Replica Set并扩容它，同时回滚之前扩容的Replica Set——将它添加到旧的Replica Set列表，开始缩容。

　　例如，假设创建一个 Deployment 以创建 nginx:1.7.9 的 5 个副本，然后更新 Deployment 以创建 5 个 nginx:1.9.1 的副本，而此时只有 3 个nginx:1.7.9 的副本已创建。在这种情况下， Deployment 会立即开始杀死3个 nginx:1.7.9 Pods，并开始创建 nginx:1.9.1 Pods。它不等待 nginx:1.7.9 的 5 个副本创建完毕再更新新的副本。

　　使用标签选择器进行更新

　　通常不鼓励更新标签选择器，建议提前规划选择器。在任何情况下，如果需要执行标签选择器更新，请格外小心，并确保已掌握所有的含义。
```
注意：
在 API 版本 apps/v1 中， Deployment 标签选择器在创建后是不可变的。
```
- 选择器添加还需要使用新标签更新 Deployment 规范中的 Pod 模板标签，否则将返回验证错误。此更改是非重叠的，这意味着新的选择器不选择使用旧选择器创建的 ReplicaSets 和 Pod，从而导致弃用所有旧 ReplicaSets 和创建新的 ReplicaSet 。
- 选择器更新更改选择器键中的现有值 – 导致发生与添加相同的行为。
- 选择器删除从 Deployment 选择器中删除现有密钥 – 不需要在Pod 模板标签做任意更改。现有 ReplicaSets 不会孤立，并且不会创建新的 ReplicaSet ，但请注意，已删除的标签仍然存在于任何现有的 Pods 和 ReplicaSets 中。
　　回滚Deployment

　　有时，可能需要回滚 Deployment ；例如，当 Deployment 不稳定时，例如循环崩溃。

　　默认情况下，kubernetes会在系统中保存前两次的Deployment的rollout历史记录，以便你可以随时会退（你可以修改revision history limit来更改保存的revision数）
```
注意： 只要Deployment的rollout被触发就会创建一个revision。也就是说当且仅当Deployment的Pod template（如.spec.template）被更改，例如更新template中的label和容器镜像时，就会创建出一个新的revision。
```
　　其他的更新，比如扩容Deployment不会创建revision——因此我们可以很方便的手动或者自动扩容。

　　例如修改副本数由3修改成5再查看revision是没有新的revision的
```
# kubectl rollout history deployment/nginx-deployment --record
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         <none>
```
　　假设我们在更新Deployment的时候犯了一个拼写错误，将镜像的名字写成了nginx:1.91，而正确的名字应该是nginx:1.9.1：
```
# kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record
deployment.apps/nginx-deployment image updated
```
　　Rollout将会卡住
```
# kubectl rollout status deployment nginx-deployment 
Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
```
　　按住Ctrl-C停止上面的rollout状态监控。

　　查看ReplicaSet
```
# kubectl get rs
NAME                                DESIRED   CURRENT   READY   AGE
nginx-deployment-54f57cf6bf         3         3         3       5m20s
nginx-deployment-84fdd4f88c         1         1         0       2m
```
　　查看创建的 Pod，看到由新 ReplicaSet 创建的 1 个 Pod 卡在镜像拉取循环中。
```
# kubectl get pod
NAME                                      READY   STATUS             RESTARTS   AGE
nginx-deployment-54f57cf6bf-67bhs         1/1     Running            0          6m1s
nginx-deployment-54f57cf6bf-dgrw7         1/1     Running            0          6m43s
nginx-deployment-54f57cf6bf-n5mjc         1/1     Running            0          6m43s
nginx-deployment-84fdd4f88c-cmzw6         0/1     ImagePullBackOff   0          3m23s
```
　　注意，Deployment controller会自动停止坏的rollout，并停止扩容新的Replica Set。

　　获取deploym描述信息
```
# kubectl describe deployment nginx-deployment
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Fri, 20 Mar 2020 16:51:44 +0800
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 2
                        kubectl.kubernetes.io/last-applied-configuration:
                          {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"app":"nginx"},"name":"nginx-deployment","namespace":"d...
Selector:               app=nginx
Replicas:               3 desired | 1 updated | 4 total | 3 available | 1 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.91
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    ReplicaSetUpdated
OldReplicaSets:  nginx-deployment-54f57cf6bf (3/3 replicas created)
NewReplicaSet:   nginx-deployment-84fdd4f88c (1/1 replicas created)
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  9m34s  deployment-controller  Scaled up replica set nginx-deployment-54f57cf6bf to 3
  Normal  ScalingReplicaSet  8m52s  deployment-controller  Scaled up replica set nginx-deployment-54f57cf6bf to 5
  Normal  ScalingReplicaSet  6m45s  deployment-controller  Scaled down replica set nginx-deployment-54f57cf6bf to 3
  Normal  ScalingReplicaSet  6m14s  deployment-controller  Scaled up replica set nginx-deployment-84fdd4f88c to 1
```
　　为了修复这个问题，我们需要回退到稳定的Deployment revision。

　　检查升级历史记录
```
注意：检查历史记录需要在创建的Deployment的时候加了参数--record否则历史记录只记录version号，记录历史命令为none
```
　　
```
# kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=nginx-deployment.yaml --record=true
2         kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record=true
```
　　查看修改历史的详细信息，查看version为2的详细信息
```
# kubectl rollout history deployment/nginx-deployment --revision=2
deployment.apps/nginx-deployment with revision #2
Pod Template:
  Labels:	app=nginx
	pod-template-hash=84fdd4f88c
  Annotations:	kubernetes.io/change-cause: kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record=true
  Containers:
   nginx:
    Image:	nginx:1.91
    Port:	80/TCP
    Host Port:	0/TCP
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>
```
　　回滚到上一次的修改
```
# kubectl rollout undo deployment/nginx-deployment
deployment.apps/nginx-deployment rolled back
```
　　或者，可以通过使用 `--to-revision` 来回滚到特定修改版本：
```
# kubectl rollout undo deployment/nginx-deployment  --to-revision=2
deployment.apps/nginx-deployment rolled back
```
　　检查回滚是否成功Deployment是否正常运行
```
# kubectl get deployment nginx-deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           8m19s
```
　　获取Deployment描述信息
```
# kubectl describe deployment nginx-deployment
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Fri, 20 Mar 2020 17:07:51 +0800
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 5
                        kubectl.kubernetes.io/last-applied-configuration:
                          {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{"kubernetes.io/change-cause":"kubectl apply --filename=nginx-deploy...
                        kubernetes.io/change-cause: kubectl apply --filename=nginx-deployment.yaml --record=true
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.7.9
    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:   nginx-deployment-54f57cf6bf (3/3 replicas created)
Events:
  Type    Reason             Age                    From                   Message
  ----    ------             ----                   ----                   -------
  Normal  ScalingReplicaSet  9m25s                  deployment-controller  Scaled up replica set nginx-deployment-54f57cf6bf to 3
  Normal  ScalingReplicaSet  3m49s (x2 over 9m17s)  deployment-controller  Scaled up replica set nginx-deployment-84fdd4f88c to 1
  Normal  ScalingReplicaSet  2m35s (x2 over 5m54s)  deployment-controller  Scaled down replica set nginx-deployment-84fdd4f88c to 0
```
　　你可以通过设置.spec.revisonHistoryLimit项来指定deployment最多保留多少revison历史记录。默认的保留2次revision；如果将该项设置为0，Deployment就不允许回退了。

　　缩放Deployment

　　可以使用如下指令缩放 Deployment
```
# kubectl scale deployment/nginx-deployment --replicas=10
deployment.apps/nginx-deployment scaled
```
　　假设你的集群中启用了horizontal pod autoscaling，你可以给Deployment设置一个autoscaler，基于当前Pod的CPU利用率选择最少和最多的Pod数。
```
kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80
```
　　比例缩放

　　RollingUpdate Deployment支持同时运行一个应用的多个版本。当你活着autoscaler扩容RollingUpdate Deployment的时候，正在中途的rollout（进行中或者已经暂停的），为了降低风险，Deployment controller将会平衡已存在的活动中的ReplicaSets（有Pod的ReplicaSets）和新加入的replicas。这被称为比例扩容。

　　例如，你真在运行的10个ReplicaSet的Deployment 。maxSurge=3，maxUnavailable=2即最多增加为3 最大不可用为2

　　maxSurge和maxUnavailable默认百分百为25% 可以编辑修改如此例副本数为10则maxSurge修改为30% maxUnavailable修改为20%

　　查看Deployment包含10个ReplicaSet修改参数以后maxSurge=3，maxUnavailable=2。
```
# kubectl get deploy
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment         10/10   10           10          17m
```
　　更新了一个镜像，而在集群内部无法解析
```
# kubectl set image deploy/nginx-deployment nginx=ngina:sametag
deployment.apps/nginx-deployment image updated
```
　　镜像更新启动了一个包含ReplicaSet 名称为nginx-deployment-55866c9bf7的rollout，但是它被阻塞了，因为前面提到的maxUnavailable最大不可用为2最大增加maxSurge为3所以新的ReplicaSet有5个Pod阻塞了
```
# kubectl get rs
NAME                                DESIRED   CURRENT   READY   AGE
nginx-deployment-54f57cf6bf         8         8         8       18m
nginx-deployment-55866c9bf7         5         5         0       14m
```
　　查看Pod

　　然后发起了一个新的Deployment扩容请求。autoscaler将Deployment的repllica数目增加到了15个。Deployment controller需要判断在哪里增加这5个新的replica。如果我们没有用比例扩容，所有的5个replica都会加到一个新的ReplicaSet中。如果使用比例扩容，新添加的replica将传播到所有的ReplicaSet中。大的部分加入replica数最多的ReplicaSet中，小的部分加入到replica数少的ReplciaSet中。0个replica的ReplicaSet不会被扩容。
```
# kubectl scale --replicas=15 deploy/nginx-deployment
deployment.apps/nginx-deployment scaled
```
　　在该例中有4个replica加入到旧ReplicaSet中新的ReplicaSet有3个
```
# kubectl get deploy
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment         12/15   8            12          29m
[root@localhost deployment]# kubectl get rs
NAME                                DESIRED   CURRENT   READY   AGE
nginx-deployment-54f57cf6bf         12        12        12      29m
nginx-deployment-55866c9bf7         8         8         0       25m
```
　　通过Pod的运行时间可以区分加入新旧ReplicaSet的副本数

　　暂停和恢复Deployment

　　可以在触发一个或多个更新之前暂停 Deployment ，然后继续它。这允许在暂停和恢复之间应用多个修补程序，而不会触发不必要的rollout。

　　例如对于一个刚刚创建的Deployment获取Deployment信息
```
# kubectl get deploy
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment         3/3     3            3           3s
```
　　获取rs
```
# kubectl get rs
NAME                                DESIRED   CURRENT   READY   AGE
nginx-deployment-54f57cf6bf         3         3         3       35s
```
　　使用以下命令暂停Deployment
```
# kubectl rollout pause deploy/nginx-deployment
deployment.apps/nginx-deployment paused
```
　　更新镜像
```
# kubectl set image deploy/nginx-deployment nginx=nginx:1.9.1
deployment.apps/nginx-deployment image updated
```
　　查看rollout没有记录
```
# kubectl rollout history deploy/nginx-deployment
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         <none>
```
　　恢复Deployment
```
# kubectl rollout resume deploy/nginx-deployment
deployment.apps/nginx-deployment resumed
```
```
注意：
暂停的 Deployment 不可以回滚，除非恢复它以后。
暂停的Deployment管理的Pod功能正常运行
```
　　Deployment状态

　　Deployment在生命周期中有多种状态。在创建一个新的ReplicaSet的时候它可以是 progressing 状态， complete 状态，或者fail to progress状态。

　　Progressing Deployment

　　Kubernetes将执行过下列任务之一的Deployment标记为progressing状态：
- Deployment正在创建新的ReplicaSet过程中。
- Deployment正在扩容一个已有的ReplicaSet。
- Deployment正在缩容一个已有的ReplicaSet。
- 有新的可用的pod出现。
　　你可以使用kubectl roullout status命令监控Deployment的进度。

　　Complete Deployment

　　Kubernetes将包括以下特性的Deployment标记为complete状态：
- Deployment最小可用。最小可用意味着Deployment的可用replica个数等于或者超过Deployment策略中的期望个数。
- 所有与该Deployment相关的replica都被更新到了你指定版本，也就说更新完成。
- 该Deployment中没有旧的Pod存在。
　　你可以用kubectl rollout status命令查看Deployment是否完成。如果rollout成功完成，kubectl rollout status将返回一个0值的Exit Code。
```
# kubectl rollout status deploy/nginx-deployment
deployment "nginx-deployment" successfully rolled out
[root@localhost deployment]# echo $?
0
```
　　Failed Deployment
- 无效的引用
- 不可读的probe failure
- 镜像拉取错误
- 权限不够
- 范围限制
- 程序运行时配置错误
　　探测这种情况的一种方式是，在你的Deployment spec中指定spec.progressDeadlineSeconds。spec.progressDeadlineSeconds表示Deployment controller等待多少秒才能确定（通过Deployment status）Deployment进程是卡住的。

　　下面的kubectl命令设置progressDeadlineSeconds 使controller在Deployment在进度卡住10分钟后报告：
```
# kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
```
　　PS：默认的参数值就是600秒，可以使用以下命令查看
```
kubectl edit deploy/nginx-deployment
```
　　超过截止时间后， Deployment 控制器将添加具有以下属性到 Deployment 的 .status.conditions ：
- Type=Progressing
- Status=False
- Reason=ProgressDeadlineExceeded
  注意： kubernetes除了报告Reason=ProgressDeadlineExceeded状态信息外不会对卡住的Deployment做任何操作。更高层次的协调器可以利用它并采取相应行动，例如，回滚Deployment到之前的版本。注意：如果你暂停了一个Deployment，在暂停的这段时间内kubernetnes不会检查你指定的deadline。你可以在Deployment的rollout途中安全的暂停它，然后再恢复它，这不会触发超过deadline的状态。
  清理策略
　　可以在 Deployment 中设置 .spec.revisionHistoryLimit ，以指定保留多少此 Deployment 的 ReplicaSets。其余的将在后台进行垃圾回收。默认情况下，是10。
```
注意： 将该值设置为0，将导致所有的Deployment历史记录都会被清除，该Deploynent就无法再回退了。
```
　　编写Deployment脚本

　　在所有的Kubernetes配置中，Deployment也需要apiVersion，kind和metadata这些配置项。

　　Pod Template

　　.spec仅需要.spec.template和.spec.selector.

　　.spec.template是 pod template. 它跟 Pod有一模一样的schema，除了它是嵌套的并且不需要apiVersion 和 kind字段。

　　另外为了划分Pod的范围，Deployment中的pod template必须指定适当的label（不要跟其他controller重复了）和适当的重启策略。

　　.spec.template.spec.restartPolicy 可以设置为 Always , 如果不指定的话这就是默认配置。

　　Replicas

　　.spec.replicas是可选字段，指定期望的副本即Pod数量，默认是1。

　　Selector

　　.spec.selector是可选字段，用来指定 label selector ，圈定Deployment管理的pod范围。

　　如果被指定， .spec.selector 必须匹配 .spec.template.metadata.labels，否则它将被API拒绝。

　　在 API apps/v1版本中，.spec.selector 和 .metadata.labels 不会被默认设置为 .spec.template.metadata.labels，如果没有设置的话。所以需要明确进行设置。同时在 apps/v1版本中， Deployment 创建后 .spec.selector 是可变的

　　如下所示需要匹配

　　在Pod的template跟.spec.template不同或者数量超过了.spec.replicas规定的数量的情况下，Deployment会杀掉label跟selector不同的Pod。
```
注意：
不应创建其标签与此选择器匹配的 Pods，或者直接创建另一个 Deployment ，或通过创建其他控制器（如 ReplicaSet 或复制控制器）。如果这样做，第一个 Deployment 认为它创建了这些其他 Pods。Kubernetes 不会阻止你这么做。
```
　　如果有多个具有重叠选择器的控制器，则控制器之间会因冲突而故障。

　　策略

　　.spec.strategy 指定新的Pod替换旧的Pod的策略。 .spec.strategy.type 可以是”Recreate”或者是 “RollingUpdate”。”RollingUpdate”是默认值。

　　Recreate Deployment

　　.spec.strategy.type==Recreate时，在创建出新的Pod之前会先杀掉所有已存在的Pod。

　　Rolling Update Deployment

　　.spec.strategy.type==RollingUpdate时，Deployment使用rolling update 的方式更新Pod 。你可以指定maxUnavailable 和maxSurge 来控制 rolling update 进程。

　　Max Unavailable

　　.spec.strategy.rollingUpdate.maxUnavailable 是可选配置项，用来指定在升级过程中不可用Pod的最大数量。该值可以是一个绝对值（例如5），也可以是期望Pod数量的百分比（例如10%）。通过计算百分比的绝对值向下取整。如果.spec.strategy.rollingUpdate.maxSurge 为0时，这个值不可以为0。默认值是1。

　　例如，该值设置成30%，启动rolling update后旧的ReplicatSet将会立即缩容到期望的Pod数量的70%。新的Pod ready后，随着新的ReplicaSet的扩容，旧的ReplicaSet会进一步缩容，确保在升级的所有时刻可以用的Pod数量至少是期望Pod数量的70%。

　　Max Surge

　　.spec.strategy.rollingUpdate.maxSurge 是可选配置项，用来指定可以超过期望的Pod数量的最大个数。该值可以是一个绝对值（例如5）或者是期望的Pod数量的百分比（例如10%）。当MaxUnavailable为0时该值不可以为0。通过百分比计算的绝对值向上取整。默认值是1。

例如，该值设置成30%，启动rolling update后新的ReplicatSet将会立即扩容，新老Pod的总数不能超过期望的Pod数量的130%。旧的Pod被杀掉后，新的ReplicaSet将继续扩容，旧的ReplicaSet会进一步缩容，确保在升级的所有时刻所有的Pod数量和不会超过期望Pod数量的130%。

　　Progress Deadline Seconds

　　.spec.progressDeadlineSeconds 是可选配置项，用来指定在系统报告Deployment的failed progressing ——表现为resource的状态中type=Progressing、Status=False、 Reason=ProgressDeadlineExceeded前可以等待的Deployment进行的秒数。Deployment controller会继续重试该Deployment。未来，在实现了自动回滚后， deployment controller在观察到这种状态时就会自动回滚。

如果设置该参数，该值必须大于 .spec.minReadySeconds。

　　Min Ready Seconds

　　.spec.minReadySeconds是一个可选配置项，用来指定没有任何容器crash的Pod并被认为是可用状态的最小秒数。默认是0（Pod在ready后就会被认为是可用状态）。进一步了解什么什么后Pod会被认为是ready状态。

　　Rollback To

　　.spec.rollbackTo 是一个可以选配置项，用来配置Deployment回退的配置。设置该参数将触发回退操作，每次回退完成后，该值就会被清除。
　　Revision

　　.spec.rollbackTo.revision是一个可选配置项，用来指定回退到的revision。默认是0，意味着回退到历史中最老的revision。

　　Revision History Limit

　　Deployment revision history存储在它控制的ReplicaSets中。

　　.spec.revisionHistoryLimit 是一个可选配置项，用来指定可以保留的旧的ReplicaSet数量。该理想值取决于心Deployment的频率和稳定性。如果该值没有设置的话，默认所有旧的Replicaset或会被保留，将资源存储在etcd中，是用kubectl get rs查看输出。每个Deployment的该配置都保存在ReplicaSet中，然而，一旦你删除的旧的RepelicaSet，你的Deployment就无法再回退到那个revison了。

如果你将该值设置为0，所有具有0个replica的ReplicaSet都会被删除。在这种情况下，新的Deployment rollout无法撤销，因为revision history都被清理掉了。

　　Paused

　　.spec.paused是可以可选配置项，boolean值。用来指定暂停和恢复Deployment。Paused和没有paused的Deployment之间的唯一区别就是，所有对paused deployment中的PodTemplateSpec的修改都不会触发新的rollout。Deployment被创建之后默认是非paused。

　　Deployment的替代方案

　　Kubectl rolling update 虽然使用类似的方式更新Pod和ReplicationController。但是我们推荐使用Deployment，因为它是声明式的，客户端侧，具有附加特性，例如即使滚动升级结束后也可以回滚到任何历史版本。

　　

　　　　
相关阅读:
js中的异常处理
 CSS3之box-sizing属性
 AJAX
NaN与Null与undefiined的关系
 跳转语句之continue与break
npm火速上手
 程序里面的‘脑筋急转弯’
css伪元素::before与::after
常用正则表达式、JS中的正则以及ES6的扩展
 git
原文地址：https://www.cnblogs.com/minseo/p/12532336.html

Kubernetes控制器之Deployment

Deployments

创建Deployment

Pod-template-hash 标签

更新Deployment

Rollover（多个rollout并行）

使用标签选择器进行更新

回滚Deployment

检查升级历史记录

回滚到上一次的修改

比例缩放

暂停和恢复Deployment

Deployment状态

Progressing Deployment

Complete Deployment

Failed Deployment

清理策略

编写Deployment脚本

Pod Template

Replicas

Selector

策略

Progress Deadline Seconds

Min Ready Seconds

Rollback To

Revision History Limit

Paused

Deployment的替代方案

　　Deployments

　　创建Deployment

　　Pod-template-hash 标签

　　更新Deployment

　　Rollover（多个rollout并行）　　

　　使用标签选择器进行更新

　　回滚Deployment

　　检查升级历史记录

　　回滚到上一次的修改

　　比例缩放

　　暂停和恢复Deployment

　　Deployment状态

　　Progressing Deployment

　　Complete Deployment

　　Failed Deployment

　　编写Deployment脚本

　　Pod Template

　　Replicas

　　Selector

　　策略

　　Progress Deadline Seconds

　　Min Ready Seconds

　　Rollback To

　　Revision History Limit

　　Paused

　　Deployment的替代方案