kubernetes-handbook/concepts/deployment.md

820 lines
43 KiB
Markdown
Raw Normal View History

2017-05-14 19:39:33 +08:00
# Deployment
2017-05-14 19:08:56 +08:00
2017-05-18 15:24:07 +08:00
## 简述
Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义(declarative)方法用来替代以前的ReplicationController 来方便的管理应用。典型的应用场景包括:
2017-05-14 19:08:56 +08:00
- 定义Deployment来创建Pod和ReplicaSet
- 滚动升级和回滚应用
- 扩容和缩容
- 暂停和继续Deployment
比如一个简单的nginx应用可以定义为
```yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
```
扩容:
```
kubectl scale deployment nginx-deployment --replicas 10
```
如果集群支持 horizontal pod autoscaling 的话还可以为Deployment设置自动扩展
```
kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
```
更新镜像也比较简单:
```
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
```
回滚:
```
kubectl rollout undo deployment/nginx-deployment
```
2017-05-18 15:24:07 +08:00
## Deployment 结构示意图
2017-07-09 16:33:39 +08:00
参考https://kubernetes.io/docs/api-reference/v1.6/#deploymentspec-v1beta1-apps
![kubernetes deployment cheatsheet](../images/deployment-cheatsheet.png)
## Deployment 概念详细解析
2017-05-18 15:24:07 +08:00
2017-08-04 13:30:10 +08:00
本文翻译自kubernetes官方文档https://kubernetes.io/docs/concepts/workloads/controllers/deployment.md
2017-05-18 15:24:07 +08:00
根据2017年5月10日的Commit 8481c02 翻译。
## Deployment 是什么?
2017-05-18 15:24:07 +08:00
Deployment为Pod和Replica Set下一代Replication Controller提供声明式更新。
您只需要在 Deployment 中描述您想要的目标状态是什么Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。您可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。
**注意**:您不该手动管理由 Deployment 创建的 ReplicaSet否则您就篡越了 Deployment controller 的职责!下文罗列了 Deployment 对象中已经覆盖了所有的用例。如果未有覆盖您所有需要的用例,请直接在 Kubernetes 的代码库中提 issue。
2017-05-18 15:24:07 +08:00
典型的用例如下:
2017-05-18 15:24:07 +08:00
- 使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态看它是成功还是失败。
- 然后通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSetDeployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。
- 如果当前状态不稳定回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision。
- 扩容Deployment以满足更高的负载。
- 暂停Deployment来应用PodTemplateSpec的多个修复然后恢复上线。
- 根据Deployment 的状态判断上线是否hang住了。
- 清除旧的不必要的 ReplicaSet。
2017-05-18 15:24:07 +08:00
## 创建 Deployment
2017-05-18 15:24:07 +08:00
下面是一个 Deployment 示例,它创建了一个 ReplicaSet 来启动3个 nginx pod。
2017-05-18 15:24:07 +08:00
下载示例文件并执行命令:
2018-02-20 17:58:16 +08:00
```bash
2017-08-04 13:30:10 +08:00
$ kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record
2017-05-18 15:24:07 +08:00
deployment "nginx-deployment" created
```
将kubectl的 `--record` 的 flag 设置为 `true`可以在 annotation 中记录当前命令创建或者升级了该资源。这在未来会很有用,例如,查看在每个 Deployment revision 中执行了哪些命令。
2017-05-18 15:24:07 +08:00
2017-08-04 10:33:20 +08:00
然后立即执行 `get` 将获得如下结果:
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 0 0 0 1s
```
输出结果表明我们希望的repalica数是3根据deployment中的`.spec.replicas`配置当前replica数 `.status.replicas`是0, 最新的replica数`.status.updatedReplicas`是0可用的replica数`.status.availableReplicas`是0。
过几秒后再执行`get`命令,将获得如下输出:
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 18s
```
我们可以看到Deployment已经创建了3个 replica所有的 replica 都已经是最新的了包含最新的pod template可用的根据Deployment中的`.spec.minReadySeconds`声明处于已就绪状态的pod的最少个数。执行`kubectl get rs`和`kubectl get pods`会显示Replica SetRS和Pod已创建。
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-2035384211 3 3 0 18s
```
您可能会注意到 ReplicaSet 的名字总是`<Deployment>-<pod templatehash>`。
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-2035384211-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211
```
刚创建的Replica Set将保证总是有3个 nginx 的 pod 存在。
2017-08-04 10:38:00 +08:00
**注意:** 您必须在 Deployment 中的 selector 指定正确的 pod template label在该示例中是 `app = nginx`),不要跟其他的 controller 的 selector 中指定的 pod template label 搞混了(包括 Deployment、Replica Set、Replication Controller 等)。**Kubernetes 本身并不会阻止您任意指定 pod template label **,但是如果您真的这么做了,这些 controller 之间会相互打架,并可能导致不正确的行为。
2017-05-18 15:24:07 +08:00
### Pod-template-hash label
2017-08-01 11:42:38 +08:00
**注意**:这个 label 不是用户指定的!
注意上面示例输出中的 pod label 里的 pod-template-hash label。当 Deployment 创建或者接管 ReplicaSet 时Deployment controller 会自动为 Pod 添加 pod-template-hash label。这样做的目的是防止 Deployment 的子ReplicaSet 的 pod 名字重复。通过将 ReplicaSet 的 PodTemplate 进行哈希散列,使用生成的哈希值作为 label 的值,并添加到 ReplicaSet selector 里、 pod template label 和 ReplicaSet 管理中的 Pod 上。
2017-05-18 15:24:07 +08:00
## 更新Deployment
**注意:** Deployment 的 rollout 当且仅当 Deployment 的 pod template例如`.spec.template`中的label更新或者镜像更改时被触发。其他更新例如扩容Deployment不会触发 rollout。
2017-05-18 15:24:07 +08:00
假如我们现在想要让 nginx pod 使用`nginx:1.9.1`的镜像来代替原来的`nginx:1.7.9`的镜像。
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
deployment "nginx-deployment" image updated
```
我们可以使用`edit`命令来编辑 Deployment修改 `.spec.template.spec.containers[0].image` ,将`nginx:1.7.9` 改写成 `nginx:1.9.1`
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl edit deployment/nginx-deployment
deployment "nginx-deployment" edited
```
查看 rollout 的状态,只要执行:
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out
```
Rollout 成功后,`get` Deployment
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 36s
```
UP-TO-DATE 的 replica 的数目已经达到了配置中要求的数目。
2017-05-18 15:24:07 +08:00
CURRENT 的 replica 数表示 Deployment 管理的 replica 数量AVAILABLE 的 replica 数是当前可用的replica数量。
2017-05-18 15:24:07 +08:00
我们通过执行`kubectl get rs`可以看到 Deployment 更新了Pod通过创建一个新的 ReplicaSet 并扩容了3个 replica同时将原来的 ReplicaSet 缩容到了0个 replica。
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 3 3 0 6s
nginx-deployment-2035384211 0 0 0 36s
```
执行 `get pods`只会看到当前的新的 pod:
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-khku8 1/1 Running 0 14s
nginx-deployment-1564180365-nacti 1/1 Running 0 14s
nginx-deployment-1564180365-z9gth 1/1 Running 0 14s
```
下次更新这些 pod 的时候,只需要更新 Deployment 中的 pod 的 template 即可。
2017-05-18 15:24:07 +08:00
Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的它会确保至少有比期望的Pod数量少一个是up状态最多一个不可用
2017-05-18 15:24:07 +08:00
Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的它会确保最多比期望的Pod数量多一个的 Pod 是 up 的最多1个 surge )。
2017-05-18 15:24:07 +08:00
**在未来的 Kuberentes 版本中将从1-1变成25%-25%。**
2017-05-18 15:24:07 +08:00
例如,如果您自己看下上面的 Deployment您会发现开始创建一个新的 Pod然后删除一些旧的 Pod 再创建一个新的。当新的Pod创建出来之前不会杀掉旧的Pod。这样能够确保可用的 Pod 数量至少有2个Pod的总数最多4个。
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl describe deployments
Name: nginx-deployment
Namespace: default
CreationTimestamp: Tue, 15 Mar 2016 12:01:06 -0700
Labels: app=nginx
Selector: app=nginx
Replicas: 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created)
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
36s 36s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3
23s 23s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1
23s 23s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2
23s 23s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3
```
我们可以看到当我们刚开始创建这个 Deployment 的时候,创建了一个 ReplicaSetnginx-deployment-2035384211并直接扩容到了3个 replica。
2017-05-18 15:24:07 +08:00
当我们更新这个 Deployment 的时候,它会创建一个新的 ReplicaSetnginx-deployment-1564180365将它扩容到1个replica然后缩容原先的 ReplicaSet 到2个 replica此时满足至少2个 Pod 是可用状态同一时刻最多有4个 Pod 处于创建的状态。
2017-05-18 15:24:07 +08:00
接着继续使用相同的 rolling update 策略扩容新的 ReplicaSet 和缩容旧的 ReplicaSet。最终将会在新的 ReplicaSet 中有3个可用的 replica旧的 ReplicaSet 的 replica 数目变成0。
2017-05-18 15:24:07 +08:00
### Rollover多个rollout并行
每当 Deployment controller 观测到有新的 deployment 被创建时,如果没有已存在的 ReplicaSet 来创建期望个数的 Pod 的话,就会创建出一个新的 ReplicaSet 来做这件事。已存在的 ReplicaSet 控制 label 与`.spec.selector`匹配但是 template 跟`.spec.template`不匹配的 Pod 缩容。最终,新的 ReplicaSet 将会扩容出`.spec.replicas`指定数目的 Pod旧的 ReplicaSet 会缩容到0。
2017-05-18 15:24:07 +08:00
如果您更新了一个的已存在并正在进行中的 Deployment每次更新 Deployment都会创建一个新的 ReplicaSet并扩容它同时回滚之前扩容的 ReplicaSet ——将它添加到旧的 ReplicaSet 列表中,开始缩容。
2017-05-18 15:24:07 +08:00
例如假如您创建了一个有5个`niginx:1.7.9` replica的 Deployment但是当还只有3个`nginx:1.7.9`的 replica 创建出来的时候您就开始更新含有5个`nginx:1.9.1` replica 的 Deployment。在这种情况下Deployment 会立即杀掉已创建的3个`nginx:1.7.9`的 Pod并开始创建`nginx:1.9.1`的 Pod。它不会等到所有的5个`nginx:1.7.9`的 Pod 都创建完成后才开始改变航道。
### Label selector 更新
2018-01-16 15:48:27 +08:00
我们通常不鼓励更新 label selector我们建议事先规划好您的 selector。
任何情况下,只要您想要执行 label selector 的更新,请一定要谨慎并确认您已经预料到所有可能因此导致的后果。
- 增添 selector 需要同时在 Deployment 的 spec 中更新新的 label否则将返回校验错误。此更改是不可覆盖的这意味着新的 selector 不会选择使用旧 selector 创建的 ReplicaSet 和 Pod从而导致所有旧版本的 ReplicaSet 都被丢弃,并创建新的 ReplicaSet。
- 更新 selector即更改 selector key 的当前值,将导致跟增添 selector 同样的后果。
- 删除 selector即删除 Deployment selector 中的已有的 key不需要对 Pod template label 做任何更改,现有的 ReplicaSet 也不会成为孤儿,但是请注意,删除的 label 仍然存在于现有的 Pod 和 ReplicaSet 中。
2017-05-18 15:24:07 +08:00
## 回退Deployment
有时候您可能想回退一个 Deployment例如当 Deployment 不稳定时,比如一直 crash looping。
2017-05-18 15:24:07 +08:00
默认情况下kubernetes 会在系统中保存前两次的 Deployment 的 rollout 历史记录,以便您可以随时回退(您可以修改`revision history limit`来更改保存的revision数
2017-05-18 15:24:07 +08:00
**注意:** 只要 Deployment 的 rollout 被触发就会创建一个 revision。也就是说当且仅当 Deployment 的 Pod template如`.spec.template`被更改例如更新template 中的 label 和容器镜像时,就会创建出一个新的 revision。
2017-05-18 15:24:07 +08:00
2018-02-14 10:28:47 +08:00
其他的更新,比如扩容 Deployment 不会创建 revision——因此我们可以很方便的手动或者自动扩容。这意味着当您回退到历史 revision 时,只有 Deployment 中的 Pod template 部分才会回退。
2017-05-18 15:24:07 +08:00
假设我们在更新 Deployment 的时候犯了一个拼写错误,将镜像的名字写成了`nginx:1.91`,而正确的名字应该是`nginx:1.9.1`
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.91
deployment "nginx-deployment" image updated
```
Rollout 将会卡住。
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl rollout status deployments nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
```
按住 Ctrl-C 停止上面的 rollout 状态监控。
2017-05-18 15:24:07 +08:00
您会看到旧的 replicanginx-deployment-1564180365 和 nginx-deployment-2035384211和新的 replica nginx-deployment-3066724191数目都是2个。
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 2 2 0 25s
nginx-deployment-2035384211 0 0 0 36s
nginx-deployment-3066724191 2 2 2 6s
```
看下创建 Pod您会看到有两个新的 ReplicaSet 创建的 Pod 处于 ImagePullBackOff 状态,循环拉取镜像。
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-70iae 1/1 Running 0 25s
nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s
nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s
nginx-deployment-3066724191-eocby 0/1 ImagePullBackOff 0 6s
```
注意Deployment controller会自动停止坏的 rollout并停止扩容新的 ReplicaSet。
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl describe deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700
Labels: app=nginx
Selector: app=nginx
Replicas: 2 updated | 3 total | 2 available | 2 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
OldReplicaSets: nginx-deployment-1564180365 (2/2 replicas created)
NewReplicaSet: nginx-deployment-3066724191 (2/2 replicas created)
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-1564180365 to 2
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 2
```
为了修复这个问题,我们需要回退到稳定的 Deployment revision。
2017-05-18 15:24:07 +08:00
### 检查 Deployment 升级的历史记录
2017-05-18 15:24:07 +08:00
首先,检查下 Deployment 的 revision
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment":
REVISION CHANGE-CAUSE
2017-08-04 13:30:10 +08:00
1 kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml--record
2017-05-18 15:24:07 +08:00
2 kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
3 kubectl set image deployment/nginx-deployment nginx=nginx:1.91
```
2017-11-14 10:59:23 +08:00
因为我们创建 Deployment 的时候使用了`--record`参数可以记录命令,我们可以很方便的查看每次 revision 的变化。
2017-05-18 15:24:07 +08:00
查看单个revision 的详细信息:
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl rollout history deployment/nginx-deployment --revision=2
deployments "nginx-deployment" revision 2
Labels: app=nginx
pod-template-hash=1159050644
Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
Containers:
nginx:
Image: nginx:1.9.1
Port: 80/TCP
QoS Tier:
cpu: BestEffort
memory: BestEffort
Environment Variables: <none>
No volumes.
```
### 回退到历史版本
现在,我们可以决定回退当前的 rollout 到之前的版本:
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl rollout undo deployment/nginx-deployment
deployment "nginx-deployment" rolled back
```
也可以使用 `--revision`参数指定某个历史版本:
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment "nginx-deployment" rolled back
```
2017-08-04 13:30:10 +08:00
与 rollout 相关的命令详细文档见[kubectl rollout](https://kubernetes.io/docs/user-guide/kubectl/v1.6/#rollout)。
2017-05-18 15:24:07 +08:00
该 Deployment 现在已经回退到了先前的稳定版本。如您所见Deployment controller产生了一个回退到revison 2的`DeploymentRollback`的 event。
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 30m
$ kubectl describe deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700
Labels: app=nginx
Selector: app=nginx
Replicas: 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created)
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
30m 30m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 2
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-1564180365 to 2
2m 2m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-3066724191 to 0
2m 2m 1 {deployment-controller } Normal DeploymentRollback Rolled back deployment "nginx-deployment" to revision 2
29m 2m 2 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3
```
### 清理 Policy
2017-05-18 15:24:07 +08:00
您可以通过设置`.spec.revisonHistoryLimit`项来指定 deployment 最多保留多少 revision 历史记录。默认的会保留所有的 revision如果将该项设置为0Deployment就不允许回退了。
2017-05-18 15:24:07 +08:00
## Deployment 扩容
2017-05-18 15:24:07 +08:00
您可以使用以下命令扩容 Deployment
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl scale deployment nginx-deployment --replicas 10
deployment "nginx-deployment" scaled
```
2017-08-04 13:30:10 +08:00
假设您的集群中启用了[horizontal pod autoscaling](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough),您可以给 Deployment 设置一个 autoscaler基于当前 Pod的 CPU 利用率选择最少和最多的 Pod 数。
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
deployment "nginx-deployment" autoscaled
```
### 比例扩容
2017-05-18 15:24:07 +08:00
RollingUpdate Deployment 支持同时运行一个应用的多个版本。或者 autoscaler 扩 容 RollingUpdate Deployment 的时候,正在中途的 rollout进行中或者已经暂停的为了降低风险Deployment controller 将会平衡已存在的活动中的 ReplicaSet有 Pod 的 ReplicaSet和新加入的 replica。这被称为比例扩容。
2017-05-18 15:24:07 +08:00
例如您正在运行中含有10个 replica 的 Deployment。maxSurge=3maxUnavailable=2。
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 10 10 10 10 50s
```
您更新了一个镜像,而在集群内部无法解析。
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl set image deploy/nginx-deployment nginx=nginx:sometag
deployment "nginx-deployment" image updated
```
镜像更新启动了一个包含ReplicaSet nginx-deployment-1989198191的新的rollout但是它被阻塞了因为我们上面提到的maxUnavailable。
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1989198191 5 5 0 9s
nginx-deployment-618515232 8 8 8 1m
```
然后发起了一个新的Deployment扩容请求。autoscaler将Deployment的repllica数目增加到了15个。Deployment controller需要判断在哪里增加这5个新的replica。如果我们没有谁用比例扩容所有的5个replica都会加到一个新的ReplicaSet中。如果使用比例扩容新添加的replica将传播到所有的ReplicaSet中。大的部分加入replica数最多的ReplicaSet中小的部分加入到replica数少的ReplciaSet中。0个replica的ReplicaSet不会被扩容。
在我们上面的例子中3个replica将添加到旧的ReplicaSet中2个replica将添加到新的ReplicaSet中。rollout进程最终会将所有的replica移动到新的ReplicaSet中假设新的replica成为健康状态。
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 15 18 7 8 7m
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1989198191 7 7 0 7m
nginx-deployment-618515232 11 11 11 7m
```
## 暂停和恢复Deployment
您可以在发出一次或多次更新前暂停一个 Deployment然后再恢复它。这样您就能多次暂停和恢复 Deployment在此期间进行一些修复工作而不会发出不必要的 rollout。
2017-05-18 15:24:07 +08:00
例如使用刚刚创建 Deployment
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 3 3 3 3 1m
[mkargaki@dhcp129-211 kubernetes]$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-2142116321 3 3 3 1m
```
使用以下命令暂停 Deployment
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl rollout pause deployment/nginx-deployment
deployment "nginx-deployment" paused
```
然后更新 Deplyment中的镜像
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl set image deploy/nginx nginx=nginx:1.9.1
deployment "nginx-deployment" image updated
```
注意新的 rollout 启动了:
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl rollout history deploy/nginx
deployments "nginx"
REVISION CHANGE-CAUSE
1 <none>
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-2142116321 3 3 3 2m
```
您可以进行任意多次更新,例如更新使用的资源:
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi
deployment "nginx" resource requirements updated
```
Deployment 暂停前的初始状态将继续它的功能,而不会对 Deployment 的更新产生任何影响,只要 Deployment是暂停的。
2017-05-18 15:24:07 +08:00
最后,恢复这个 Deployment观察完成更新的 ReplicaSet 已经创建出来了:
2017-05-18 15:24:07 +08:00
2018-02-20 17:58:16 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl rollout resume deploy nginx
deployment "nginx" resumed
$ KUBECTL get rs -w
NAME DESIRED CURRENT READY AGE
nginx-2142116321 2 2 2 2m
nginx-3926361531 2 2 0 6s
nginx-3926361531 2 2 1 18s
nginx-2142116321 1 2 2 2m
nginx-2142116321 1 2 2 2m
nginx-3926361531 3 2 1 18s
nginx-3926361531 3 2 1 18s
nginx-2142116321 1 1 1 2m
nginx-3926361531 3 3 1 18s
nginx-3926361531 3 3 2 19s
nginx-2142116321 0 1 1 2m
nginx-2142116321 0 1 1 2m
nginx-2142116321 0 0 0 2m
nginx-3926361531 3 3 3 20s
^C
$ KUBECTL get rs
NAME DESIRED CURRENT READY AGE
nginx-2142116321 0 0 0 2m
nginx-3926361531 3 3 3 28s
```
**注意:** 在恢复 Deployment 之前您无法回退一个已经暂停的 Deployment。
2017-05-18 15:24:07 +08:00
## Deployment 状态
2017-05-18 15:24:07 +08:00
2017-08-04 13:30:10 +08:00
Deployment 在生命周期中有多种状态。在创建一个新的 ReplicaSet 的时候它可以是 [progressing](https://kubernetes.io/docs/concepts/workloads/controllers/deployment.md#progressing-deployment) 状态, [complete](https://kubernetes.io/docs/concepts/workloads/controllers/deployment.md#complete-deployment) 状态,或者 [fail to progress ](https://kubernetes.io/docs/concepts/workloads/controllers/deployment.md#failed-deployment)状态。
2017-05-18 15:24:07 +08:00
### 进行中的 Deployment
2017-05-18 15:24:07 +08:00
Kubernetes 将执行过下列任务之一的 Deployment 标记为 *progressing* 状态:
2017-05-18 15:24:07 +08:00
- Deployment 正在创建新的ReplicaSet过程中。
- Deployment 正在扩容一个已有的 ReplicaSet。
- Deployment 正在缩容一个已有的 ReplicaSet。
- 有新的可用的 pod 出现。
2017-05-18 15:24:07 +08:00
您可以使用`kubectl rollout status`命令监控 Deployment 的进度。
2017-05-18 15:24:07 +08:00
### 完成的 Deployment
2017-05-18 15:24:07 +08:00
Kubernetes 将包括以下特性的 Deployment 标记为 *complete* 状态:
2017-05-18 15:24:07 +08:00
- Deployment 最小可用。最小可用意味着 Deployment 的可用 replica 个数等于或者超过 Deployment 策略中的期望个数。
- 所有与该 Deployment 相关的replica都被更新到了您指定版本也就说更新完成。
- 该 Deployment 中没有旧的 Pod 存在。
2017-05-18 15:24:07 +08:00
您可以用`kubectl rollout status`命令查看 Deployment 是否完成。如果 rollout 成功完成,`kubectl rollout status`将返回一个0值的 Exit Code。
2017-05-18 15:24:07 +08:00
2018-01-16 15:48:27 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl rollout status deploy/nginx
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
$ echo $?
0
```
### 失败的 Deployment
2017-05-18 15:24:07 +08:00
2018-02-22 08:34:07 +08:00
您的 Deployment 在尝试部署新的 ReplicaSet 的时候可能卡住,永远也不会完成。这可能是因为以下几个因素引起的:
2017-05-18 15:24:07 +08:00
- 无效的引用
- 不可读的 probe failure
2017-05-18 15:24:07 +08:00
- 镜像拉取错误
- 权限不够
- 范围限制
- 程序运行时配置错误
2017-08-04 13:30:10 +08:00
探测这种情况的一种方式是,在您的 Deployment spec 中指定[`spec.progressDeadlineSeconds`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment.md#progress-deadline-seconds)。`spec.progressDeadlineSeconds` 表示 Deployment controller 等待多少秒才能确定(通过 Deployment statusDeployment进程是卡住的。
2017-05-18 15:24:07 +08:00
下面的`kubectl`命令设置`progressDeadlineSeconds` 使 controller 在 Deployment 在进度卡住10分钟后报告
2017-05-18 15:24:07 +08:00
2018-01-16 15:48:27 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
"nginx-deployment" patched
```
当超过截止时间后Deployment controller 会在 Deployment 的 `status.conditions`中增加一条DeploymentCondition它包括如下属性
2017-05-18 15:24:07 +08:00
- Type=Progressing
- Status=False
- Reason=ProgressDeadlineExceeded
浏览 [Kubernetes API conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#typical-status-properties) 查看关于status conditions的更多信息。
**注意:** kubernetes除了报告`Reason=ProgressDeadlineExceeded`状态信息外不会对卡住的 Deployment 做任何操作。更高层次的协调器可以利用它并采取相应行动,例如,回滚 Deployment 到之前的版本。
2017-05-18 15:24:07 +08:00
**注意:** 如果您暂停了一个 Deployment在暂停的这段时间内kubernetnes不会检查您指定的 deadline。您可以在 Deployment 的 rollout 途中安全的暂停它然后再恢复它这不会触发超过deadline的状态。
2017-05-18 15:24:07 +08:00
您可能在使用 Deployment 的时候遇到一些短暂的错误,这些可能是由于您设置了太短的 timeout也有可能是因为各种其他错误导致的短暂错误。例如假设您使用了无效的引用。当您 Describe Deployment 的时候可能会注意到如下信息:
2017-05-18 15:24:07 +08:00
2018-01-16 15:48:27 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl describe deployment nginx-deployment
<...>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True ReplicaSetUpdated
ReplicaFailure True FailedCreate
<...>
```
执行 `kubectl get deployment nginx-deployment -o yaml`Deployement 的状态可能看起来像这个样子:
```yaml
status:
availableReplicas: 2
conditions:
- lastTransitionTime: 2016-10-04T12:25:39Z
lastUpdateTime: 2016-10-04T12:25:39Z
message: Replica set "nginx-deployment-4262182780" is progressing.
reason: ReplicaSetUpdated
status: "True"
type: Progressing
- lastTransitionTime: 2016-10-04T12:25:42Z
lastUpdateTime: 2016-10-04T12:25:42Z
message: Deployment has minimum availability.
reason: MinimumReplicasAvailable
status: "True"
type: Available
- lastTransitionTime: 2016-10-04T12:25:39Z
lastUpdateTime: 2016-10-04T12:25:39Z
message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota:
object-counts, requested: pods=1, used: pods=3, limited: pods=2'
reason: FailedCreate
status: "True"
type: ReplicaFailure
observedGeneration: 3
replicas: 2
unavailableReplicas: 2
```
最终,一旦超过 Deployment 进程的 deadlinekuberentes 会更新状态和导致 Progressing 状态的原因:
2017-05-18 15:24:07 +08:00
2018-01-16 15:48:27 +08:00
```bash
2017-05-18 15:24:07 +08:00
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing False ProgressDeadlineExceeded
ReplicaFailure True FailedCreate
```
您可以通过缩容 Deployment的方式解决配额不足的问题或者增加您的 namespace 的配额。如果您满足了配额条件后Deployment controller 就会完成您的 Deployment rollout您将看到 Deployment 的状态更新为成功状态(`Status=True`并且`Reason=NewReplicaSetAvailable`)。
2017-05-18 15:24:07 +08:00
2018-01-16 15:48:27 +08:00
```bash
2017-05-18 15:24:07 +08:00
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
```
`Type=Available``Status=True` 以为这您的Deployment有最小可用性。 最小可用性是在Deployment策略中指定的参数。`Type=Progressing` 、 `Status=True`意味着您的Deployment 或者在部署过程中或者已经成功部署达到了期望的最少的可用replica数量查看特定状态的Reason——在我们的例子中`Reason=NewReplicaSetAvailable` 意味着Deployment已经完成
2017-05-18 15:24:07 +08:00
您可以使用`kubectl rollout status`命令查看Deployment进程是否失败。当Deployment过程超过了deadline`kubectl rollout status`将返回非0的exit code。
2017-05-18 15:24:07 +08:00
2018-01-16 15:48:27 +08:00
```bash
2017-05-18 15:24:07 +08:00
$ kubectl rollout status deploy/nginx
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
error: deployment "nginx" exceeded its progress deadline
$ echo $?
1
```
### 操作失败的 Deployment
2017-05-18 15:24:07 +08:00
所有对完成的 Deployment 的操作都适用于失败的 Deployment。您可以对它扩/缩容,回退到历史版本,您甚至可以多次暂停它来应用 Deployment pod template。
2017-05-18 15:24:07 +08:00
## 清理Policy
您可以设置 Deployment 中的 `.spec.revisionHistoryLimit` 项来指定保留多少旧的 ReplicaSet。 余下的将在后台被当作垃圾收集。默认的,所有的 revision 历史就都会被保留。在未来的版本中将会更改为2。
2017-05-18 15:24:07 +08:00
**注意:** 将该值设置为0将导致所有的 Deployment 历史记录都会被清除,该 Deployment 就无法再回退了。
2017-05-18 15:24:07 +08:00
## 用例
### 金丝雀 Deployment
2017-05-18 15:24:07 +08:00
2017-08-04 13:30:10 +08:00
如果您想要使用 Deployment 对部分用户或服务器发布 release您可以创建多个 Deployment每个 Deployment 对应一个 release参照 [managing resources](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments) 中对金丝雀模式的描述。
2017-05-18 15:24:07 +08:00
## 编写 Deployment Spec
2017-05-18 15:24:07 +08:00
2017-08-04 13:30:10 +08:00
在所有的 Kubernetes 配置中Deployment 也需要`apiVersion``kind`和`metadata`这些配置项。配置文件的通用使用说明查看 [部署应用](https://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment/),配置容器,和 [使用 kubectl 管理资源 ](https://kubernetes.io/docs/tutorials/object-management-kubectl/object-management/) 文档。
2017-05-18 15:24:07 +08:00
Deployment也需要 [`.spec` section](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#spec-and-status).
### Pod Template
`.spec.template``.spec`中唯一要求的字段。
2017-08-04 13:30:10 +08:00
`.spec.template` 是 [pod template](https://kubernetes.io/docs/user-guide/replication-controller/#pod-template). 它跟 [Pod](https://kubernetes.io/docs/user-guide/pods)有一模一样的schema除了它是嵌套的并且不需要`apiVersion` 和 `kind`字段。
2017-05-18 15:24:07 +08:00
2017-08-04 13:30:10 +08:00
另外为了划分Pod的范围Deployment中的pod template必须指定适当的label不要跟其他controller重复了参考[selector](https://kubernetes.io/docs/concepts/workloads/controllers/deployment.md#selector))和适当的重启策略。
2017-05-18 15:24:07 +08:00
2017-08-04 13:30:10 +08:00
[`.spec.template.spec.restartPolicy`](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle) 可以设置为 `Always` , 如果不指定的话这就是默认配置。
2017-05-18 15:24:07 +08:00
### Replicas
`.spec.replicas` 是可以选字段指定期望的pod数量默认是1。
### Selector
2017-08-04 13:30:10 +08:00
`.spec.selector`是可选字段,用来指定 [label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels) 圈定Deployment管理的pod范围。
2017-05-18 15:24:07 +08:00
如果被指定, `.spec.selector` 必须匹配 `.spec.template.metadata.labels`否则它将被API拒绝。如果 `.spec.selector` 没有被指定, `.spec.selector.matchLabels` 默认是 `.spec.template.metadata.labels`
在Pod的template跟`.spec.template`不同或者数量超过了`.spec.replicas`规定的数量的情况下Deployment会杀掉label跟selector不同的Pod。
**注意:** 您不应该再创建其他label跟这个selector匹配的pod或者通过其他Deployment或者通过其他Controller例如ReplicaSet和ReplicationController。否则该Deployment会被把它们当成都是自己创建的。Kubernetes不会阻止您这么做。
2017-05-18 15:24:07 +08:00
如果您有多个controller使用了重复的selectorcontroller们就会互相打架并导致不正确的行为。
2017-05-18 15:24:07 +08:00
### 策略
`.spec.strategy` 指定新的Pod替换旧的Pod的策略。 `.spec.strategy.type` 可以是"Recreate"或者是 "RollingUpdate"。"RollingUpdate"是默认值。
#### Recreate Deployment
`.spec.strategy.type==Recreate`在创建出新的Pod之前会先杀掉所有已存在的Pod。
#### Rolling Update Deployment
2017-08-04 13:30:10 +08:00
`.spec.strategy.type==RollingUpdate`Deployment使用[rolling update](https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller) 的方式更新Pod 。您可以指定`maxUnavailable` 和 `maxSurge` 来控制 rolling update 进程。
2017-05-18 15:24:07 +08:00
##### 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
2017-08-04 13:30:10 +08:00
`.spec.progressDeadlineSeconds` 是可选配置项用来指定在系统报告Deployment的[failed progressing](https://kubernetes.io/docs/concepts/workloads/controllers/deployment.md#failed-deployment) ——表现为resource的状态中`type=Progressing`、`Status=False`、 `Reason=ProgressDeadlineExceeded`前可以等待的Deployment进行的秒数。Deployment controller会继续重试该Deployment。未来在实现了自动回滚后 deployment controller在观察到这种状态时就会自动回滚。
2017-05-18 15:24:07 +08:00
如果设置该参数,该值必须大于 `.spec.minReadySeconds`
### Min Ready Seconds
2017-08-04 13:30:10 +08:00
`.spec.minReadySeconds`是一个可选配置项用来指定没有任何容器crash的Pod并被认为是可用状态的最小秒数。默认是0Pod在ready后就会被认为是可用状态。进一步了解什么什么后Pod会被认为是ready状态参阅 [Container Probes](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
2017-05-18 15:24:07 +08:00
### Rollback To
`.spec.rollbackTo` 是一个可以选配置项用来配置Deployment回退的配置。设置该参数将触发回退操作每次回退完成后该值就会被清除。
#### Revision
2017-08-25 14:49:14 +08:00
`.spec.rollbackTo.revision`是一个可选配置项用来指定回退到的revision。默认是0意味着回退到上一个revision。
2017-05-18 15:24:07 +08:00
### Revision History Limit
Deployment revision history存储在它控制的ReplicaSets中。
`.spec.revisionHistoryLimit` 是一个可选配置项用来指定可以保留的旧的ReplicaSet数量。该理想值取决于心Deployment的频率和稳定性。如果该值没有设置的话默认所有旧的Replicaset或会被保留将资源存储在etcd中是用`kubectl get rs`查看输出。每个Deployment的该配置都保存在ReplicaSet中然而一旦您删除的旧的RepelicaSet您的Deployment就无法再回退到那个revison了。
2017-05-18 15:24:07 +08:00
如果您将该值设置为0所有具有0个replica的ReplicaSet都会被删除。在这种情况下新的Deployment rollout无法撤销因为revision history都被清理掉了。
2017-05-18 15:24:07 +08:00
### Paused
`.spec.paused`是可以可选配置项boolean值。用来指定暂停和恢复Deployment。Paused和没有paused的Deployment之间的唯一区别就是所有对paused deployment中的PodTemplateSpec的修改都不会触发新的rollout。Deployment被创建之后默认是非paused。
## Deployment 的替代选择
2017-05-18 15:24:07 +08:00
### kubectl rolling update
2017-08-04 13:30:10 +08:00
[Kubectl rolling update](https://kubernetes.io/docs/user-guide/kubectl/v1.6/#rolling-update) 虽然使用类似的方式更新Pod和ReplicationController。但是我们推荐使用Deployment因为它是声明式的客户端侧具有附加特性例如即使滚动升级结束后也可以回滚到任何历史版本。