官方参考：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，因为它是声明式的，客户端侧，具有附加特性，例如即使滚动升级结束后也可以回滚到任何历史版本。