diff --git a/concepts/deployment.md b/concepts/deployment.md index 03c2885f2..05601bb59 100644 --- a/concepts/deployment.md +++ b/concepts/deployment.md @@ -1,8 +1,10 @@ # Deployment +[TOC] + ## 简述 -Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController来方便的管理应用。典型的应用场景包括： +Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController 来方便的管理应用。典型的应用场景包括： - 定义Deployment来创建Pod和ReplicaSet - 滚动升级和回滚应用 @@ -54,25 +56,27 @@ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 kubectl rollout undo deployment/nginx-deployment ``` -## Deployment结构示意图 +## Deployment 结构示意图 参考：https://kubernetes.io/docs/api-reference/v1.6/#deploymentspec-v1beta1-apps ![kubernetes deployment cheatsheet](../images/deployment-cheatsheet.png) -## Deployment概念详细解析 +## Deployment 概念详细解析 本文翻译自kubernetes官方文档：https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/concepts/workloads/controllers/deployment.md 根据2017年5月10日的Commit 8481c02 翻译。 -## Deployment是什么？ +## Deployment 是什么？ Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新。 -你只需要在Deployment中描述你想要的目标状态是什么，Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态。你可以定义一个全新的Deployment，也可以创建一个新的替换旧的Deployment。 +您只需要在 Deployment 中描述您想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。您可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。 -一个典型的用例如下： +**注意**：您不该手动管理由 Deployment 创建的 ReplicaSet，否则您就篡越了 Deployment controller 的职责！下文罗列了 Deployment 对象中已经覆盖了所有的用例。如果未有覆盖您所有需要的用例，请直接在 Kubernetes 的代码库中提 issue。 + +典型的用例如下： - 使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态，看它是成功还是失败。 - 然后，通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet，Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。 @@ -80,11 +84,11 @@ Deployment为Pod和Replica Set（下一代Replication Controller）提供声明 - 扩容Deployment以满足更高的负载。 - 暂停Deployment来应用PodTemplateSpec的多个修复，然后恢复上线。 - 根据Deployment 的状态判断上线是否hang住了。 -- 清除旧的不必要的ReplicaSet。 +- 清除旧的不必要的 ReplicaSet。 -## 创建Deployment +## 创建 Deployment -下面是一个Deployment示例，它创建了一个Replica Set来启动3个nginx pod。 +下面是一个 Deployment 示例，它创建了一个 ReplicaSet 来启动3个 nginx pod。 下载示例文件并执行命令： @@ -93,7 +97,7 @@ $ kubectl create -f docs/user-guide/nginx-deployment.yaml --record deployment "nginx-deployment" created ``` -将kubectl的 `—record` 的flag设置为 `true`可以在annotation中记录当前命令创建或者升级了该资源。这在未来会很有用，例如，查看在每个Deployment revision中执行了哪些命令。 +将kubectl的 `--record` 的 flag 设置为 `true`可以在 annotation 中记录当前命令创建或者升级了该资源。这在未来会很有用，例如，查看在每个 Deployment revision 中执行了哪些命令。 然后立即执行`get`í将获得如下结果： @@ -113,7 +117,7 @@ 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 Set（RS）和Pod已创建。 +我们可以看到Deployment已经创建了3个 replica，所有的 replica 都已经是最新的了（包含最新的pod template），可用的（根据Deployment中的`.spec.minReadySeconds`声明，处于已就绪状态的pod的最少个数）。执行`kubectl get rs`和`kubectl get pods`会显示Replica Set（RS）和Pod已创建。 ```shell $ kubectl get rs @@ -121,7 +125,7 @@ NAME DESIRED CURRENT READY AGE nginx-deployment-2035384211 3 3 0 18s ``` -你可能会注意到Replica Set的名字总是`-`。 +您可能会注意到 ReplicaSet 的名字总是`-`。 ```shell $ kubectl get pods --show-labels @@ -131,29 +135,35 @@ nginx-deployment-2035384211-kzszj 1/1 Running 0 18s app nginx-deployment-2035384211-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211 ``` -刚创建的Replica Set将保证总是有3个nginx的pod存在。 +刚创建的Replica Set将保证总是有3个 nginx 的 pod 存在。 -**注意：** 你必须在Deployment中的selector指定正确pod template label（在该示例中是 `app = nginx`），不要跟其他的controller搞混了（包括Deployment、Replica Set、Replication Controller等）。**Kubernetes本身不会阻止你这么做**，如果你真的这么做了，这些controller之间会相互打架，并可能导致不正确的行为。 +**注意：** 您必须在 Deployment 中的 selector 指定正确 pod template label（在该示例中是 `app = nginx`），不要跟其他的controller搞混了（包括Deployment、Replica Set、Replication Controller 等）。**Kubernetes 本身不会阻止您这么做**，如果您真的这么做了，这些 controller 之间会相互打架，并可能导致不正确的行为。 + +### Pod-template-hash label + +**注意：**这个 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 上。 ## 更新Deployment -**注意：** Deployment的rollout当且仅当Deployment的pod template（例如`.spec.template`）中的label更新或者镜像更改时被触发。其他更新，例如扩容Deployment不会触发rollout。 +**注意：** Deployment 的 rollout 当且仅当 Deployment 的 pod template（例如`.spec.template`）中的label更新或者镜像更改时被触发。其他更新，例如扩容Deployment不会触发 rollout。 -假如我们现在想要让nginx pod使用`nginx:1.9.1`的镜像来代替原来的`nginx:1.7.9`的镜像。 +假如我们现在想要让 nginx pod 使用`nginx:1.9.1`的镜像来代替原来的`nginx:1.7.9`的镜像。 ```shell $ 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`。 +我们可以使用`edit`命令来编辑 Deployment，修改 `.spec.template.spec.containers[0].image` ，将`nginx:1.7.9` 改写成 `nginx:1.9.1`。 ```shell $ kubectl edit deployment/nginx-deployment deployment "nginx-deployment" edited ``` -查看rollout的状态，只要执行： +查看 rollout 的状态，只要执行： ```shell $ kubectl rollout status deployment/nginx-deployment @@ -161,7 +171,7 @@ Waiting for rollout to finish: 2 out of 3 new replicas have been updated... deployment "nginx-deployment" successfully rolled out ``` -Rollout成功后，`get` Deployment： +Rollout 成功后，`get` Deployment： ```shell $ kubectl get deployments @@ -169,13 +179,11 @@ NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 3 3 3 3 36s ``` -UP-TO-DATE的replica的数目已经达到了配置中要求的数目。 +UP-TO-DATE 的 replica 的数目已经达到了配置中要求的数目。 -CURRENT的replica数表示Deployment管理的replica数量，AVAILABLE的replica数是当前可用的replica数量。 +CURRENT 的 replica 数表示 Deployment 管理的 replica 数量，AVAILABLE 的 replica 数是当前可用的replica数量。 -We can run `kubectl get rs` to see that the Deployment updated the Pods by creating a new Replica Set and scaling it up to 3 replicas, as well as scaling down the old Replica Set to 0 replicas. - -我们通过执行`kubectl get rs`可以看到Deployment更新了Pod，通过创建一个新的Replica Set并扩容了3个replica，同时将原来的Replica Set缩容到了0个replica。 +我们通过执行`kubectl get rs`可以看到 Deployment 更新了Pod，通过创建一个新的 ReplicaSet 并扩容了3个 replica，同时将原来的 ReplicaSet 缩容到了0个 replica。 ```shell $ kubectl get rs @@ -184,7 +192,7 @@ nginx-deployment-1564180365 3 3 0 6s nginx-deployment-2035384211 0 0 0 36s ``` -执行 `get pods`只会看到当前的新的pod: +执行 `get pods`只会看到当前的新的 pod: ```shell $ kubectl get pods @@ -194,15 +202,15 @@ nginx-deployment-1564180365-nacti 1/1 Running 0 14s nginx-deployment-1564180365-z9gth 1/1 Running 0 14s ``` -下次更新这些pod的时候，只需要更新Deployment中的pod的template即可。 +下次更新这些 pod 的时候，只需要更新 Deployment 中的 pod 的 template 即可。 -Deployment可以保证在升级时只有一定数量的Pod是down的。默认的，它会确保至少有比期望的Pod数量少一个是up状态（最多一个不可用）。 +Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的，它会确保至少有比期望的Pod数量少一个是up状态（最多一个不可用）。 -Deployment同时也可以确保只创建出超过期望数量的一定数量的Pod。默认的，它会确保最多比期望的Pod数量多一个的Pod是up的（最多1个surge）。 +Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的，它会确保最多比期望的Pod数量多一个的 Pod 是 up 的（最多1个 surge ）。 -**在未来的Kuberentes版本中，将从1-1变成25%-25%。** +**在未来的 Kuberentes 版本中，将从1-1变成25%-25%。** -例如，如果你自己看下上面的Deployment，你会发现，开始创建一个新的Pod，然后删除一些旧的Pod再创建一个新的。当新的Pod创建出来之前不会杀掉旧的Pod。这样能够确保可用的Pod数量至少有2个，Pod的总数最多4个。 +例如，如果您自己看下上面的 Deployment，您会发现，开始创建一个新的 Pod，然后删除一些旧的 Pod 再创建一个新的。当新的Pod创建出来之前不会杀掉旧的Pod。这样能够确保可用的 Pod 数量至少有2个，Pod的总数最多4个。 ```shell $ kubectl describe deployments @@ -228,47 +236,57 @@ Events: 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3 ``` -我们可以看到当我们刚开始创建这个Deployment的时候，创建了一个Replica Set（nginx-deployment-2035384211），并直接扩容到了3个replica。 +我们可以看到当我们刚开始创建这个 Deployment 的时候，创建了一个 ReplicaSet（nginx-deployment-2035384211），并直接扩容到了3个 replica。 -当我们更新这个Deployment的时候，它会创建一个新的Replica Set（nginx-deployment-1564180365），将它扩容到1个replica，然后缩容原先的Replica Set到2个replica，此时满足至少2个Pod是可用状态，同一时刻最多有4个Pod处于创建的状态。 +当我们更新这个 Deployment 的时候，它会创建一个新的 ReplicaSet（nginx-deployment-1564180365），将它扩容到1个replica，然后缩容原先的 ReplicaSet 到2个 replica，此时满足至少2个 Pod 是可用状态，同一时刻最多有4个 Pod 处于创建的状态。 -接着继续使用相同的rolling update策略扩容新的Replica Set和缩容旧的Replica Set。最终，将会在新的Replica Set中有3个可用的replica，旧的Replica Set的replica数目变成0。 +接着继续使用相同的 rolling update 策略扩容新的 ReplicaSet 和缩容旧的 ReplicaSet。最终，将会在新的 ReplicaSet 中有3个可用的 replica，旧的 ReplicaSet 的 replica 数目变成0。 ### Rollover（多个rollout并行） -每当Deployment controller观测到有新的deployment被创建时，如果没有已存在的Replica Set来创建期望个数的Pod的话，就会创建出一个新的Replica Set来做这件事。已存在的Replica Set控制label匹配`.spec.selector`但是template跟`.spec.template`不匹配的Pod缩容。最终，新的Replica Set将会扩容出`.spec.replicas`指定数目的Pod，旧的Replica Set会缩容到0。 +每当 Deployment controller 观测到有新的 deployment 被创建时，如果没有已存在的 ReplicaSet 来创建期望个数的 Pod 的话，就会创建出一个新的 ReplicaSet 来做这件事。已存在的 ReplicaSet 控制 label 与`.spec.selector`匹配但是 template 跟`.spec.template`不匹配的 Pod 缩容。最终，新的 ReplicaSet 将会扩容出`.spec.replicas`指定数目的 Pod，旧的 ReplicaSet 会缩容到0。 -如果你更新了一个的已存在并正在进行中的Deployment，每次更新Deployment都会创建一个新的Replica Set并扩容它，同时回滚之前扩容的Replica Set——将它添加到旧的Replica Set列表，开始缩容。 +如果您更新了一个的已存在并正在进行中的 Deployment，每次更新 Deployment都会创建一个新的 ReplicaSet并扩容它，同时回滚之前扩容的 ReplicaSet ——将它添加到旧的 ReplicaSet 列表中，开始缩容。 -例如，假如你创建了一个有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都创建完成后才开始改变航道。 +例如，假如您创建了一个有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 更新 + +我们通常不鼓励更新 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 中。 ## 回退Deployment -有时候你可能想回退一个Deployment，例如，当Deployment不稳定时，比如一直crash looping。 +有时候您可能想回退一个 Deployment，例如，当 Deployment 不稳定时，比如一直 crash looping。 -默认情况下，kubernetes会在系统中保存前两次的Deployment的rollout历史记录，以便你可以随时回退（你可以修改`revision history limit`来更改保存的revision数）。 +默认情况下，kubernetes 会在系统中保存前两次的 Deployment 的 rollout 历史记录，以便您可以随时回退（您可以修改`revision history limit`来更改保存的revision数）。 -**注意：** 只要Deployment的rollout被触发就会创建一个revision。也就是说当且仅当Deployment的Pod template（如`.spec.template`）被更改，例如更新template中的label和容器镜像时，就会创建出一个新的revision。 +**注意：** 只要 Deployment 的 rollout 被触发就会创建一个 revision。也就是说当且仅当 Deployment 的 Pod template（如`.spec.template`）被更改，例如更新template 中的 label 和容器镜像时，就会创建出一个新的 revision。 -其他的更新，比如扩容Deployment不会创建revision——因此我们可以很方便的手动或者自动扩容。这意味着当你回退到历史revision是，直邮Deployment中的Pod template部分才会回退。 +其他的更新，比如扩容 Deployment 不会创建 revision——因此我们可以很方便的手动或者自动扩容。这意味着当您回退到历史 revision 是，直有 Deployment 中的 Pod template 部分才会回退。 -假设我们在更新Deployment的时候犯了一个拼写错误，将镜像的名字写成了`nginx:1.91`，而正确的名字应该是`nginx:1.9.1`： +假设我们在更新 Deployment 的时候犯了一个拼写错误，将镜像的名字写成了`nginx:1.91`，而正确的名字应该是`nginx:1.9.1`： ```shell $ kubectl set image deployment/nginx-deployment nginx=nginx:1.91 deployment "nginx-deployment" image updated ``` -Rollout将会卡住。 +Rollout 将会卡住。 ```shell $ kubectl rollout status deployments nginx-deployment Waiting for rollout to finish: 2 out of 3 new replicas have been updated... ``` -按住Ctrl-C停止上面的rollout状态监控。 +按住 Ctrl-C 停止上面的 rollout 状态监控。 -你会看到旧的replicas（nginx-deployment-1564180365 和 nginx-deployment-2035384211）和新的replicas （nginx-deployment-3066724191）数目都是2个。 +您会看到旧的 replica（nginx-deployment-1564180365 和 nginx-deployment-2035384211）和新的 replica （nginx-deployment-3066724191）数目都是2个。 ```shell $ kubectl get rs @@ -278,7 +296,7 @@ nginx-deployment-2035384211 0 0 0 36s nginx-deployment-3066724191 2 2 2 6s ``` -看下创建Pod，你会看到有两个新的呃Replica Set创建的Pod处于ImagePullBackOff状态，循环拉取镜像。 +看下创建 Pod，您会看到有两个新的 ReplicaSet 创建的 Pod 处于 ImagePullBackOff 状态，循环拉取镜像。 ```shell $ kubectl get pods @@ -289,7 +307,7 @@ nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s nginx-deployment-3066724191-eocby 0/1 ImagePullBackOff 0 6s ``` -注意，Deployment controller会自动停止坏的rollout，并停止扩容新的Replica Set。 +注意，Deployment controller会自动停止坏的 rollout，并停止扩容新的 ReplicaSet。 ```shell $ kubectl describe deployment @@ -318,11 +336,11 @@ Events: 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 2 ``` -为了修复这个问题，我们需要回退到稳定的Deployment revision。 +为了修复这个问题，我们需要回退到稳定的 Deployment revision。 -### 检查Deployment升级的历史记录 +### 检查 Deployment 升级的历史记录 -首先，检查下Deployment的revision： +首先，检查下 Deployment 的 revision： ```shell $ kubectl rollout history deployment/nginx-deployment @@ -333,9 +351,9 @@ REVISION CHANGE-CAUSE 3 kubectl set image deployment/nginx-deployment nginx=nginx:1.91 ``` -因为我们创建Deployment的时候使用了`—recored`参数可以记录命令，我们可以很方便的查看每次revison的变化。 +因为我们创建 Deployment 的时候使用了`--recored`参数可以记录命令，我们可以很方便的查看每次 revision 的变化。 -查看单个revision的详细信息： +查看单个revision 的详细信息： ```shell $ kubectl rollout history deployment/nginx-deployment --revision=2 @@ -356,7 +374,7 @@ deployments "nginx-deployment" revision 2 ### 回退到历史版本 -现在，我们可以决定回退当前的rollout到之前的版本： +现在，我们可以决定回退当前的 rollout 到之前的版本： ```shell $ kubectl rollout undo deployment/nginx-deployment @@ -370,9 +388,9 @@ $ kubectl rollout undo deployment/nginx-deployment --to-revision=2 deployment "nginx-deployment" rolled back ``` -与rollout相关的命令详细文档见[kubectl rollout](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/user-guide/kubectl/v1.6/#rollout)。 +与 rollout 相关的命令详细文档见[kubectl rollout](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/user-guide/kubectl/v1.6/#rollout)。 -该Deployment现在已经回退到了先前的稳定版本。如你所见，Deployment controller产生了一个回退到revison 2的`DeploymentRollback`的event。 +该 Deployment 现在已经回退到了先前的稳定版本。如您所见，Deployment controller产生了一个回退到revison 2的`DeploymentRollback`的 event。 ```shell $ kubectl get deployment @@ -407,31 +425,31 @@ Events: 29m 2m 2 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3 ``` -### 清理Policy +### 清理 Policy -你可以通过设置`.spec.revisonHistoryLimit`项来指定deployment最多保留多少revison历史记录。默认的会保留所有的revision；如果将该项设置为0，Deployment就不允许回退了。 +您可以通过设置`.spec.revisonHistoryLimit`项来指定 deployment 最多保留多少 revision 历史记录。默认的会保留所有的 revision；如果将该项设置为0，Deployment就不允许回退了。 -## Deployment扩容 +## Deployment 扩容 -你可以使用以下命令扩容Deployment： +您可以使用以下命令扩容 Deployment： ```shell $ kubectl scale deployment nginx-deployment --replicas 10 deployment "nginx-deployment" scaled ``` -假设你的集群中启用了[horizontal pod autoscaling](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough)，你可以给Deployment设置一个autoscaler，基于当前Pod的CPU利用率选择最少和最多的Pod数。 +假设您的集群中启用了[horizontal pod autoscaling](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough)，您可以给 Deployment 设置一个 autoscaler，基于当前 Pod的 CPU 利用率选择最少和最多的 Pod 数。 ```shell $ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80 deployment "nginx-deployment" autoscaled ``` -## 比例扩容 +### 比例扩容 -RollingUpdate Deployment支持同时运行一个应用的多个版本。当你活着autoscaler扩容RollingUpdate Deployment的时候，正在中途的rollout（进行中或者已经暂停的），为了降低风险，Deployment controller将会平衡已存在的活动中的ReplicaSets（有Pod的ReplicaSets）和新加入的replicas。这被称为比例扩容。 +RollingUpdate Deployment 支持同时运行一个应用的多个版本。或者 autoscaler 扩 容 RollingUpdate Deployment 的时候，正在中途的 rollout（进行中或者已经暂停的），为了降低风险，Deployment controller 将会平衡已存在的活动中的 ReplicaSet（有 Pod 的 ReplicaSet）和新加入的 replica。这被称为比例扩容。 -例如，你正在运行中含有10个replica的Deployment。maxSurge=3，maxUnavailable=2。 +例如，您正在运行中含有10个 replica 的 Deployment。maxSurge=3，maxUnavailable=2。 ```shell $ kubectl get deploy @@ -439,7 +457,7 @@ NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 10 10 10 10 50s ``` -你更新了一个镜像，而在集群内部无法解析。 +您更新了一个镜像，而在集群内部无法解析。 ```shell $ kubectl set image deploy/nginx-deployment nginx=nginx:sometag @@ -471,9 +489,9 @@ nginx-deployment-618515232 11 11 11 7m ## 暂停和恢复Deployment -你可以在发出一次或多次更新前暂停一个Deployment，然后再恢复它。这样你就能多次暂停和恢复Deployment，在此期间进行一些修复工作，而不会发出不必要的rollout。 +您可以在发出一次或多次更新前暂停一个 Deployment，然后再恢复它。这样您就能多次暂停和恢复 Deployment，在此期间进行一些修复工作，而不会发出不必要的 rollout。 -例如使用刚刚创建Deployment： +例如使用刚刚创建 Deployment： ```shell $ kubectl get deploy @@ -484,21 +502,21 @@ NAME DESIRED CURRENT READY AGE nginx-2142116321 3 3 3 1m ``` -使用以下命令暂停Deployment： +使用以下命令暂停 Deployment： ```shell $ kubectl rollout pause deployment/nginx-deployment deployment "nginx-deployment" paused ``` -然后更新Deplyment中的镜像： +然后更新 Deplyment中的镜像： ```shell $ kubectl set image deploy/nginx nginx=nginx:1.9.1 deployment "nginx-deployment" image updated ``` -注意新的rollout启动了： +注意新的 rollout 启动了： ```shell $ kubectl rollout history deploy/nginx @@ -511,16 +529,16 @@ NAME DESIRED CURRENT READY AGE nginx-2142116321 3 3 3 2m ``` -你可以进行任意多次更新，例如更新使用的资源： +您可以进行任意多次更新，例如更新使用的资源： ```shell $ kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi deployment "nginx" resource requirements updated ``` -Deployment暂停前的初始状态将继续它的功能，而不会对Deployment的更新产生任何影响，只要Deployment是暂停的。 +Deployment 暂停前的初始状态将继续它的功能，而不会对 Deployment 的更新产生任何影响，只要 Deployment是暂停的。 -最后，恢复这个Deployment，观察完成更新的ReplicaSet已经创建出来了： +最后，恢复这个 Deployment，观察完成更新的 ReplicaSet 已经创建出来了： ```shell $ kubectl rollout resume deploy nginx @@ -548,32 +566,32 @@ nginx-2142116321 0 0 0 2m nginx-3926361531 3 3 3 28s ``` -**注意：** 在恢复Deployment之前你无法回退一个暂停了个Deployment。 +**注意：** 在恢复 Deployment 之前您无法回退一个已经暂停的 Deployment。 -## Deployment状态 +## Deployment 状态 -Deployment在生命周期中有多种状态。在创建一个新的ReplicaSet的时候它可以是 [progressing](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/concepts/workloads/controllers/deployment.md#progressing-deployment) 状态， [complete](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/concepts/workloads/controllers/deployment.md#complete-deployment) 状态，或者[fail to progress](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/concepts/workloads/controllers/deployment.md#failed-deployment)状态。 +Deployment 在生命周期中有多种状态。在创建一个新的 ReplicaSet 的时候它可以是 [progressing](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/concepts/workloads/controllers/deployment.md#progressing-deployment) 状态， [complete](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/concepts/workloads/controllers/deployment.md#complete-deployment) 状态，或者 [fail to progress ](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/concepts/workloads/controllers/deployment.md#failed-deployment)状态。 -### Progressing Deployment +### 进行中的 Deployment -Kubernetes将执行过下列任务之一的Deployment标记为*progressing*状态： +Kubernetes 将执行过下列任务之一的 Deployment 标记为 *progressing* 状态： -- Deployment正在创建新的ReplicaSet过程中。 -- Deployment正在扩容一个已有的ReplicaSet。 -- Deployment正在缩容一个已有的ReplicaSet。 -- 有新的可用的pod出现。 +- Deployment 正在创建新的ReplicaSet过程中。 +- Deployment 正在扩容一个已有的 ReplicaSet。 +- Deployment 正在缩容一个已有的 ReplicaSet。 +- 有新的可用的 pod 出现。 -你可以使用`kubectl rollout status`命令监控Deployment的进度。 +您可以使用`kubectl rollout status`命令监控 Deployment 的进度。 -### Complete Deployment +### 完成的 Deployment -Kubernetes将包括以下特性的Deployment标记为*complete*状态： +Kubernetes 将包括以下特性的 Deployment 标记为 *complete* 状态： -- Deployment最小可用。最小可用意味着Deployment的可用replica个数等于或者超过Deployment策略中的期望个数。 -- 所有与该Deployment相关的replica都被更新到了你指定版本，也就说更新完成。 -- 该Deployment中没有旧的Pod存在。 +- Deployment 最小可用。最小可用意味着 Deployment 的可用 replica 个数等于或者超过 Deployment 策略中的期望个数。 +- 所有与该 Deployment 相关的replica都被更新到了您指定版本，也就说更新完成。 +- 该 Deployment 中没有旧的 Pod 存在。 -你可以用`kubectl rollout status`命令查看Deployment是否完成。如果rollout成功完成，`kubectl rollout status`将返回一个0值的Exit Code。 +您可以用`kubectl rollout status`命令查看 Deployment 是否完成。如果 rollout 成功完成，`kubectl rollout status`将返回一个0值的 Exit Code。 ``` $ kubectl rollout status deploy/nginx @@ -583,29 +601,27 @@ $ echo $? 0 ``` -### Failed Deployment +### 失败的 Deployment -你的Deployment在尝试部署新的ReplicaSet的时候可能卡住，用于也不会完成。这可能是因为以下几个因素引起的： +您的 Deployment 在尝试部署新的 ReplicaSet 的时候可能卡住，用于也不会完成。这可能是因为以下几个因素引起的： - 无效的引用 -- 不可读的probe failure +- 不可读的 probe failure - 镜像拉取错误 - 权限不够 - 范围限制 - 程序运行时配置错误 -探测这种情况的一种方式是，在你的Deployment spec中指定[`spec.progressDeadlineSeconds`](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/concepts/workloads/controllers/deployment.md#progress-deadline-seconds)。`spec.progressDeadlineSeconds` 表示Deployment controller等待多少秒才能确定（通过Deployment status）Deployment进程是卡住的。 +探测这种情况的一种方式是，在您的 Deployment spec 中指定[`spec.progressDeadlineSeconds`](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/concepts/workloads/controllers/deployment.md#progress-deadline-seconds)。`spec.progressDeadlineSeconds` 表示 Deployment controller 等待多少秒才能确定（通过 Deployment status）Deployment进程是卡住的。 -下面的`kubectl`命令设置`progressDeadlineSeconds` 使controller在Deployment在进度卡住10分钟后报告： +下面的`kubectl`命令设置`progressDeadlineSeconds` 使 controller 在 Deployment 在进度卡住10分钟后报告： ``` $ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}' "nginx-deployment" patched ``` -Once the deadline has been exceeded, the Deployment controller adds a with the following attributes to the Deployment's - -当超过截止时间后，Deployment controller会在Deployment的 `status.conditions`中增加一条DeploymentCondition，它包括如下属性： +当超过截止时间后，Deployment controller 会在 Deployment 的 `status.conditions`中增加一条DeploymentCondition，它包括如下属性： - Type=Progressing - Status=False @@ -613,11 +629,11 @@ Once the deadline has been exceeded, the Deployment controller adds a with the 浏览 [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到之前的版本。 +**注意：** kubernetes除了报告`Reason=ProgressDeadlineExceeded`状态信息外不会对卡住的 Deployment 做任何操作。更高层次的协调器可以利用它并采取相应行动，例如，回滚 Deployment 到之前的版本。 -**注意：** 如果你暂停了一个Deployment，在暂停的这段时间内kubernetnes不会检查你指定的deadline。你可以在Deployment的rollout途中安全的暂停它，然后再恢复它，这不会触发超过deadline的状态。 +**注意：** 如果您暂停了一个 Deployment，在暂停的这段时间内kubernetnes不会检查您指定的 deadline。您可以在 Deployment 的 rollout 途中安全的暂停它，然后再恢复它，这不会触发超过deadline的状态。 -你可能在使用Deployment的时候遇到一些短暂的错误，这些可能是由于你设置了太短的timeout，也有可能是因为各种其他错误导致的短暂错误。例如，假设你使用了无效的引用。当你Describe Deployment的时候可能会注意到如下信息： +您可能在使用 Deployment 的时候遇到一些短暂的错误，这些可能是由于您设置了太短的 timeout，也有可能是因为各种其他错误导致的短暂错误。例如，假设您使用了无效的引用。当您 Describe Deployment 的时候可能会注意到如下信息： ``` $ kubectl describe deployment nginx-deployment @@ -661,7 +677,7 @@ status: unavailableReplicas: 2 ``` -最终，一旦超过Deployment进程的deadline，kuberentes会更新状态和导致Progressing状态的原因： +最终，一旦超过 Deployment 进程的 deadline，kuberentes 会更新状态和导致 Progressing 状态的原因： ``` Conditions: @@ -673,7 +689,7 @@ Conditions: ``` -你可以通过缩容Deployment的方式解决配额不足的问题，或者增加你的namespace的配额。如果你满足了配额条件后，Deployment controller就会完成你的Deployment rollout，你将看到Deployment的状态更新为成功状态（`Status=True`并且`Reason=NewReplicaSetAvailable`）。 +您可以通过缩容 Deployment的方式解决配额不足的问题，或者增加您的 namespace 的配额。如果您满足了配额条件后，Deployment controller 就会完成您的 Deployment rollout，您将看到 Deployment 的状态更新为成功状态（`Status=True`并且`Reason=NewReplicaSetAvailable`）。 ``` Conditions: @@ -684,9 +700,9 @@ Conditions: ``` -`Type=Available`、 `Status=True` 以为这你的Deployment有最小可用性。 最小可用性是在Deployment策略中指定的参数。`Type=Progressing` 、 `Status=True`意味着你的Deployment 或者在部署过程中，或者已经成功部署，达到了期望的最少的可用replica数量（查看特定状态的Reason——在我们的例子中`Reason=NewReplicaSetAvailable` 意味着Deployment已经完成）。 +`Type=Available`、 `Status=True` 以为这您的Deployment有最小可用性。 最小可用性是在Deployment策略中指定的参数。`Type=Progressing` 、 `Status=True`意味着您的Deployment 或者在部署过程中，或者已经成功部署，达到了期望的最少的可用replica数量（查看特定状态的Reason——在我们的例子中`Reason=NewReplicaSetAvailable` 意味着Deployment已经完成）。 -你可以使用`kubectl rollout status`命令查看Deployment进程是否失败。当Deployment过程超过了deadline，`kubectl rollout status`将返回非0的exit code。 +您可以使用`kubectl rollout status`命令查看Deployment进程是否失败。当Deployment过程超过了deadline，`kubectl rollout status`将返回非0的exit code。 ``` $ kubectl rollout status deploy/nginx @@ -696,25 +712,25 @@ $ echo $? 1 ``` -### 操作失败的Deployment +### 操作失败的 Deployment -所有对完成的Deployment的操作都适用于失败的Deployment。你可以对它阔／缩容，回退到历史版本，你甚至可以多次暂停它来应用Deployment pod template。 +所有对完成的 Deployment 的操作都适用于失败的 Deployment。您可以对它扩/缩容，回退到历史版本，您甚至可以多次暂停它来应用 Deployment pod template。 ## 清理Policy -你可以设置Deployment中的 `.spec.revisionHistoryLimit` 项来指定保留多少旧的ReplicaSet。 余下的将在后台被当作垃圾收集。默认的，所有的revision历史就都会被保留。在未来的版本中，将会更改为2。 +您可以设置 Deployment 中的 `.spec.revisionHistoryLimit` 项来指定保留多少旧的 ReplicaSet。 余下的将在后台被当作垃圾收集。默认的，所有的 revision 历史就都会被保留。在未来的版本中，将会更改为2。 -**注意：** 将该值设置为0，将导致所有的Deployment历史记录都会被清除，该Deploynent就无法再回退了。 +**注意：** 将该值设置为0，将导致所有的 Deployment 历史记录都会被清除，该 Deployment 就无法再回退了。 ## 用例 -### 金丝雀Deployment +### 金丝雀 Deployment -如果你想要使用Deployment对部分用户或服务器发布release，你可以创建多个Deployment，每个Deployment对应一个release，参照[managing resources](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/concepts/cluster-administration/manage-deployment/#canary-deployments) 中对金丝雀模式的描述。 +如果您想要使用 Deployment 对部分用户或服务器发布 release，您可以创建多个 Deployment，每个 Deployment 对应一个 release，参照 [managing resources](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/concepts/cluster-administration/manage-deployment/#canary-deployments) 中对金丝雀模式的描述。 -## 编写Deployment Spec +## 编写 Deployment Spec -在所有的Kubernetes配置中，Deployment也需要`apiVersion`，`kind`和`metadata`这些配置项。配置文件的通用使用说明查看[部署应用](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/tutorials/stateless-application/run-stateless-application-deployment)，配置容器，和[使用kubeclt管理资源](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/tutorials/object-management-kubectl/object-management)文档。 +在所有的 Kubernetes 配置中，Deployment 也需要`apiVersion`，`kind`和`metadata`这些配置项。配置文件的通用使用说明查看 [部署应用](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/tutorials/stateless-application/run-stateless-application-deployment)，配置容器，和 [使用kubeclt管理资源 ](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/tutorials/object-management-kubectl/object-management)文档。 Deployment也需要 [`.spec` section](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#spec-and-status). @@ -740,9 +756,9 @@ Deployment也需要 [`.spec` section](https://github.com/kubernetes/community/bl 在Pod的template跟`.spec.template`不同或者数量超过了`.spec.replicas`规定的数量的情况下，Deployment会杀掉label跟selector不同的Pod。 -**注意：** 你不应该再创建其他label跟这个selector匹配的pod，或者通过其他Deployment，或者通过其他Controller，例如ReplicaSet和ReplicationController。否则该Deployment会被把它们当成都是自己创建的。Kubernetes不会阻止你这么做。 +**注意：** 您不应该再创建其他label跟这个selector匹配的pod，或者通过其他Deployment，或者通过其他Controller，例如ReplicaSet和ReplicationController。否则该Deployment会被把它们当成都是自己创建的。Kubernetes不会阻止您这么做。 -如果你有多个controller使用了重复的selector，controller们就会互相打架并导致不正确的行为。 +如果您有多个controller使用了重复的selector，controller们就会互相打架并导致不正确的行为。 ### 策略 @@ -754,7 +770,7 @@ Deployment也需要 [`.spec` section](https://github.com/kubernetes/community/bl #### Rolling Update Deployment -`.spec.strategy.type==RollingUpdate`时，Deployment使用[rolling update](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/tasks/run-application/rolling-update-replication-controller) 的方式更新Pod 。你可以指定`maxUnavailable` 和 `maxSurge` 来控制 rolling update 进程。 +`.spec.strategy.type==RollingUpdate`时，Deployment使用[rolling update](https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/tasks/run-application/rolling-update-replication-controller) 的方式更新Pod 。您可以指定`maxUnavailable` 和 `maxSurge` 来控制 rolling update 进程。 ##### Max Unavailable @@ -790,15 +806,15 @@ Deployment也需要 [`.spec` section](https://github.com/kubernetes/community/bl Deployment revision history存储在它控制的ReplicaSets中。 -`.spec.revisionHistoryLimit` 是一个可选配置项，用来指定可以保留的旧的ReplicaSet数量。该理想值取决于心Deployment的频率和稳定性。如果该值没有设置的话，默认所有旧的Replicaset或会被保留，将资源存储在etcd中，是用`kubectl get rs`查看输出。每个Deployment的该配置都保存在ReplicaSet中，然而，一旦你删除的旧的RepelicaSet，你的Deployment就无法再回退到那个revison了。 +`.spec.revisionHistoryLimit` 是一个可选配置项，用来指定可以保留的旧的ReplicaSet数量。该理想值取决于心Deployment的频率和稳定性。如果该值没有设置的话，默认所有旧的Replicaset或会被保留，将资源存储在etcd中，是用`kubectl get rs`查看输出。每个Deployment的该配置都保存在ReplicaSet中，然而，一旦您删除的旧的RepelicaSet，您的Deployment就无法再回退到那个revison了。 -如果你将该值设置为0，所有具有0个replica的ReplicaSet都会被删除。在这种情况下，新的Deployment rollout无法撤销，因为revision history都被清理掉了。 +如果您将该值设置为0，所有具有0个replica的ReplicaSet都会被删除。在这种情况下，新的Deployment rollout无法撤销，因为revision history都被清理掉了。 ### Paused `.spec.paused`是可以可选配置项，boolean值。用来指定暂停和恢复Deployment。Paused和没有paused的Deployment之间的唯一区别就是，所有对paused deployment中的PodTemplateSpec的修改都不会触发新的rollout。Deployment被创建之后默认是非paused。 -## Alternative to Deployments +## Deployment 的替代选择 ### kubectl rolling update