From c44f50decf35cfa98b9734ad59eb221aea665b13 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sun, 10 Apr 2022 20:11:46 +0800 Subject: [PATCH] [zh] Resync deployment page --- .../workloads/controllers/deployment.md | 634 ++++++++++++------ 1 file changed, 414 insertions(+), 220 deletions(-) diff --git a/content/zh/docs/concepts/workloads/controllers/deployment.md b/content/zh/docs/concepts/workloads/controllers/deployment.md index 0f6ea1846f..d4ef2b43a8 100644 --- a/content/zh/docs/concepts/workloads/controllers/deployment.md +++ b/content/zh/docs/concepts/workloads/controllers/deployment.md @@ -24,8 +24,8 @@ weight: 10 A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/). --> -一个 _Deployment_ 为 {{< glossary_tooltip text="Pods" term_id="pod" >}} -和 {{< glossary_tooltip term_id="replica-set" text="ReplicaSets" >}} +一个 Deployment 为 {{< glossary_tooltip text="Pod" term_id="pod" >}} +和 {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}} 提供声明式的更新能力。 -{{< note >}} 不要管理 Deployment 所拥有的 ReplicaSet 。 如果存在下面未覆盖的使用场景，请考虑在 Kubernetes 仓库中提出 Issue。 {{< /note >}} @@ -58,17 +58,19 @@ The following are typical use cases for Deployments: * [创建 Deployment 以将 ReplicaSet 上线](#creating-a-deployment)。 ReplicaSet 在后台创建 Pods。 检查 ReplicaSet 的上线状态，查看其是否成功。 * 通过更新 Deployment 的 PodTemplateSpec，[声明 Pod 的新状态](#updating-a-deployment) 。 新的 ReplicaSet 会被创建，Deployment 以受控速率将 Pod 从旧 ReplicaSet 迁移到新 ReplicaSet。 每个新的 ReplicaSet 都会更新 Deployment 的修订版本。 + * 如果 Deployment 的当前状态不稳定，[回滚到较早的 Deployment 版本](#rolling-back-a-deployment)。 每次回滚都会更新 Deployment 的修订版本。 * [扩大 Deployment 规模以承担更多负载](#scaling-a-deployment)。 @@ -84,7 +86,7 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up --> ## 创建 Deployment {#creating-a-deployment} -下面是 Deployment 示例。其中创建了一个 ReplicaSet，负责启动三个 `nginx` Pods： +下面是一个 Deployment 示例。其中创建了一个 ReplicaSet，负责启动三个 `nginx` Pods： {{< codenew file="controllers/nginx-deployment.yaml" >}} @@ -125,17 +127,17 @@ In this example: * `template` 字段包含以下子字段： - * Pod 被使用 `labels` 字段打上 `app: nginx` 标签。 + * Pod 被使用 `.metadata.labels` 字段打上 `app: nginx` 标签。 * Pod 模板规约（即 `.template.spec` 字段）指示 Pods 运行一个 `nginx` 容器， 该容器运行版本为 1.14.2 的 `nginx` [Docker Hub](https://hub.docker.com/)镜像。 - * 创建一个容器并使用 `name` 字段将其命名为 `nginx`。 + * 创建一个容器并使用 `.spec.template.spec.containers[0].name` 字段将其命名为 `nginx`。 - {{< note >}} - 你可以设置 `--record` 标志将所执行的命令写入资源注解 `kubernetes.io/change-cause` 中。 - 这对于以后的检查是有用的。例如，要查看针对每个 Deployment 修订版本所执行过的命令。 - {{< /note >}} -2. 运行 `kubectl get deployments` 检查 Deployment 是否已创建。如果仍在创建 Deployment， - 则输出类似于： +2. 运行 `kubectl get deployments` 检查 Deployment 是否已创建。 + 如果仍在创建 Deployment，则输出类似于： ``` - NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE - nginx-deployment 3 0 0 0 1s + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 0/3 0 0 1s ``` * `NAME` 列出了集群中 Deployment 的名称。 - * `READY` 显示应用程序的可用的 _副本_ 数。显示的模式是“就绪个数/期望个数”。 + * `READY` 显示应用程序的可用的“副本”数。显示的模式是“就绪个数/期望个数”。 * `UP-TO-DATE` 显示为了达到期望状态已经更新的副本数。 * `AVAILABLE` 显示应用可供用户使用的副本数。 * `AGE` 显示应用程序运行的时间。 @@ -216,8 +211,8 @@ Follow the steps given below to create the above Deployment: 4. 几秒钟后再次运行 `kubectl get deployments`。输出类似于： ``` - NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE - nginx-deployment 3 3 3 3 18s + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 3/3 3 3 18s ``` 注意 ReplicaSet 的名称始终被格式化为`[Deployment名称]-[随机字符串]`。 - 其中的随机字符串是使用 pod-template-hash 作为种子随机生成的。 + 其中的随机字符串是使用 `pod-template-hash` 作为种子随机生成的。 6. 要查看每个 Pod 自动生成的标签，运行 `kubectl get pods --show-labels`。返回以下输出： @@ -279,17 +275,17 @@ Follow the steps given below to create the above Deployment: --> 所创建的 ReplicaSet 确保总是存在三个 `nginx` Pod。 - {{< note >}} + 你必须在 Deployment 中指定适当的选择算符和 Pod 模板标签（在本例中为 `app: nginx`）。 标签或者选择算符不要与其他控制器（包括其他 Deployment 和 StatefulSet）重叠。 -Kubernetes 不会阻止你这样做，但是如果多个控制器具有重叠的选择算符，它们可能会发生冲突 -执行难以预料的操作。 +Kubernetes 不会阻止你这样做，但是如果多个控制器具有重叠的选择算符， +它们可能会发生冲突执行难以预料的操作。 {{< /note >}} ### Pod-template-hash 标签 - {{< note >}} + 不要更改此标签。 {{< /note >}} -Deployment 控制器将 `pod-template-hash` 标签添加到 Deployment 所创建或收留的 -每个 ReplicaSet 。 +Deployment 控制器将 `pod-template-hash` 标签添加到 Deployment +所创建或收留的每个 ReplicaSet 。 ## 更新 Deployment {#updating-a-deployment} +{{< note >}} -{{< note >}} 仅当 Deployment Pod 模板（即 `.spec.template`）发生改变时，例如模板的标签或容器镜像被更新， -才会触发 Deployment 上线。 -其他更新（如对 Deployment 执行扩缩容的操作）不会触发上线动作。 +才会触发 Deployment 上线。其他更新（如对 Deployment 执行扩缩容的操作）不会触发上线动作。 {{< /note >}} 按照以下步骤更新 Deployment： @@ -344,8 +340,7 @@ is changed, for example if the labels or container images of the template are up 1. 先来更新 nginx Pod 以使用 `nginx:1.16.1` 镜像，而不是 `nginx:1.14.2` 镜像。 ```shell - kubectl --record deployment.apps/nginx-deployment set image \ - deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 + kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 ``` - 输出类似于： - - ``` - deployment.apps/nginx-deployment image updated + kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 ``` - 或者，可以 `edit` Deployment 并将 `.spec.template.spec.containers[0].image` 从 - `nginx:1.14.2` 更改至 `nginx:1.16.1`。 - - ```shell - kubectl edit deployment.v1.apps/nginx-deployment - ``` - - 输出类似于： ``` - deployment.apps/nginx-deployment edited + deployment/nginx-deployment image updated + ``` + + + 或者，可以对 Deployment 执行 `edit` 操作并将 `.spec.template.spec.containers[0].image` 从 + `nginx:1.14.2` 更改至 `nginx:1.16.1`。 + + ```shell + kubectl edit deployment/nginx-deployment + ``` + + + 输出类似于： + + ``` + deployment/nginx-deployment edited ``` + 输出类似于： ``` @@ -414,9 +415,9 @@ Get more details on your updated Deployment: * 在上线成功后，可以通过运行 `kubectl get deployments` 来查看 Deployment： 输出类似于： - ```shell - NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE - nginx-deployment 3 3 3 3 36s + ```ini + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 3/3 3 3 36s ``` + 输出类似于： ``` @@ -448,7 +451,9 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas. kubectl get pods ``` - + 输出类似于： ``` @@ -480,12 +485,14 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas. For example, if you look at the above Deployment closely, you will see that it first created a new Pod, then deleted some old Pods, and created new ones. It does not kill old Pods until a sufficient number of new Pods have come up, and does not create new Pods until a sufficient number of old Pods have been killed. - It makes sure that at least 2 Pods are available and that at max 4 Pods in total are available. + It makes sure that at least 2 Pods are available and that at max 4 Pods in total are available. In case of + a Deployment with 4 replicas, the number of Pods would be between 3 and 5. --> 例如，如果仔细查看上述 Deployment ，将看到它首先创建了一个新的 Pod，然后删除了一些旧的 Pods， 并创建了新的 Pods。它不会杀死老 Pods，直到有足够的数量新的 Pods 已经出现。 - 在足够数量的旧 Pods 被杀死前并没有创建新 Pods。它确保至少 2 个 Pod 可用，同时 - 最多总共 4 个 Pod 可用。 + 在足够数量的旧 Pods 被杀死前并没有创建新 Pods。它确保至少 2 个 Pod 可用， + 同时最多总共 4 个 Pod 可用。 + 当 Deployment 设置为 4 个副本时，Pod 的个数会介于 3 和 5 之间。 + 输出类似于： ``` @@ -541,18 +550,33 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas. - 可以看到，当第一次创建 Deployment 时，它创建了一个 ReplicaSet（nginx-deployment-2035384211） + 可以看到，当第一次创建 Deployment 时，它创建了一个 ReplicaSet（`nginx-deployment-2035384211`） 并将其直接扩容至 3 个副本。更新 Deployment 时，它创建了一个新的 ReplicaSet - （nginx-deployment-1564180365），并将其扩容为 1，然后将旧 ReplicaSet 缩容到 2， - 以便至少有 2 个 Pod 可用且最多创建 4 个 Pod。 + （nginx-deployment-1564180365），并将其扩容为 1，等待其就绪；然后将旧 ReplicaSet 缩容到 2， + 将新的 ReplicaSet 扩容到 2 以便至少有 3 个 Pod 可用且最多创建 4 个 Pod。 然后，它使用相同的滚动更新策略继续对新的 ReplicaSet 扩容并对旧的 ReplicaSet 缩容。 最后，你将有 3 个可用的副本在新的 ReplicaSet 中，旧 ReplicaSet 将缩容到 0。 +{{< note >}} + +Kubernetes 在计算 `availableReplicas` 数值时不考虑终止过程中的 Pod， +`availableReplicas` 的值一定介于 `replicas - maxUnavailable` 和 `replicas + maxSurge` 之间。 +因此，你可能在上线期间看到 Pod 个数比预期的多，Deployment 所消耗的总的资源也大于 +`replicas + maxSurge` 个 Pod 所用的资源，直到被终止的 Pod 所设置的 +`terminationGracePeriodSeconds` 到期为止。 +{{< /note >}} + -### 更改标签选择算符 +### 更改标签选择算符 {#label-selector-updates} 通常不鼓励更新标签选择算符。建议你提前规划选择算符。 -在任何情况下，如果需要更新标签选择算符，请格外小心，并确保自己了解 -这背后可能发生的所有事情。 +在任何情况下，如果需要更新标签选择算符，请格外小心， +并确保自己了解这背后可能发生的所有事情。 +{{< note >}} -{{< note >}} 在 API 版本 `apps/v1` 中，Deployment 标签选择算符在创建后是不可变的。 {{< /note >}} @@ -643,6 +667,7 @@ By default, all of the Deployment's rollout history is kept in the system so tha 默认情况下，Deployment 的所有上线记录都保留在系统中，以便可以随时回滚 （你可以通过修改修订历史记录限制来更改这一约束）。 +{{< note >}} -{{< note >}} Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版本。 这意味着仅当 Deployment 的 Pod 模板（`.spec.template`）发生更改时，才会创建新修订版本 -- 例如，模板的标签或容器镜像发生变化。 @@ -667,14 +691,14 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版 `nginx:1.161` 而不是 `nginx:1.16.1`： ```shell - kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true + kubectl set image deployment/nginx-deployment nginx=nginx:1.161 --record=true ``` 输出类似于： - ```shell - deployment.apps/nginx-deployment image updated + ``` + deployment/nginx-deployment image updated ``` {{< note >}} + Deployment 控制器自动停止有问题的上线过程，并停止对新的 ReplicaSet 扩容。 这行为取决于所指定的 rollingUpdate 参数（具体为 `maxUnavailable`）。 默认情况下，Kubernetes 将此值设置为 25%。 {{< /note >}} * 获取 Deployment 描述信息： @@ -762,7 +784,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版 输出类似于： - ```shell + ``` Name: nginx-deployment Namespace: default CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700 @@ -822,18 +844,18 @@ Follow the steps given below to check the rollout history: 1. 首先，检查 Deployment 修订历史： ```shell - kubectl rollout history deployment.v1.apps/nginx-deployment + kubectl rollout history deployment/nginx-deployment ``` 输出类似于： - ```shell + ``` deployments "nginx-deployment" REVISION CHANGE-CAUSE - 1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true - 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true - 3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true + 1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml + 2 kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 + 3 kubectl set image deployment/nginx-deployment nginx=nginx:1.161 ``` - * 使用 `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"` 为 Deployment 添加注解。 - * 追加 `--record` 命令行标志以保存正在更改资源的 `kubectl` 命令。 + * 使用 `kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` + 为 Deployment 添加注解。 * 手动编辑资源的清单。 + 输出类似于： - ```shell + ``` deployments "nginx-deployment" revision 2 Labels: app=nginx pod-template-hash=1159050644 - Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true + Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 Containers: nginx: Image: nginx:1.16.1 @@ -893,10 +916,12 @@ Follow the steps given below to rollback the Deployment from the current version 1. 假定现在你已决定撤消当前上线并回滚到以前的修订版本： ```shell - kubectl rollout undo deployment.v1.apps/nginx-deployment + kubectl rollout undo deployment/nginx-deployment ``` - + 输出类似于： ``` @@ -909,10 +934,12 @@ Follow the steps given below to rollback the Deployment from the current version 或者，你也可以通过使用 `--to-revision` 来回滚到特定修订版本： ```shell - kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2 + kubectl rollout undo deployment/nginx-deployment --to-revision=2 ``` - + 输出类似于： ``` @@ -922,14 +949,15 @@ Follow the steps given below to rollback the Deployment from the current version - 与回滚相关的指令的更详细信息，请参考 [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)。 + 与回滚相关的指令的更详细信息，请参考 + [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)。 - 现在，Deployment 正在回滚到以前的稳定版本。正如你所看到的，Deployment 控制器生成了 - 回滚到修订版本 2 的 `DeploymentRollback` 事件。 + 现在，Deployment 正在回滚到以前的稳定版本。正如你所看到的，Deployment + 控制器生成了回滚到修订版本 2 的 `DeploymentRollback` 事件。 + 输出类似于： - ```shell - NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE - nginx-deployment 3 3 3 3 30m + ``` + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 3/3 3 3 30m ``` + 输出类似于： ``` @@ -966,7 +998,7 @@ Follow the steps given below to rollback the Deployment from the current version CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500 Labels: app=nginx Annotations: deployment.kubernetes.io/revision=4 - kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true + kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 Selector: app=nginx Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable StrategyType: RollingUpdate @@ -1014,10 +1046,12 @@ You can scale a Deployment by using the following command: 你可以使用如下指令缩放 Deployment： ```shell -kubectl scale deployment.v1.apps/nginx-deployment --replicas=10 +kubectl scale deployment/nginx-deployment --replicas=10 ``` - + 输出类似于： ``` @@ -1030,14 +1064,16 @@ in your cluster, you can setup an autoscaler for your Deployment and choose the Pods you want to run based on the CPU utilization of your existing Pods. --> 假设集群启用了[Pod 的水平自动缩放](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)， -你可以为 Deployment 设置自动缩放器，并基于现有 Pods 的 CPU 利用率选择 -要运行的 Pods 个数下限和上限。 +你可以为 Deployment 设置自动缩放器，并基于现有 Pod 的 CPU 利用率选择要运行的 +Pod 个数下限和上限。 ```shell -kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80 +kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80 ``` - + 输出类似于： ``` @@ -1062,7 +1098,8 @@ Deployment 控制器会平衡现有的活跃状态的 ReplicaSets（含 Pods 的 -例如，你正在运行一个 10 个副本的 Deployment，其 [maxSurge](#max-surge)=3，[maxUnavailable](#max-unavailable)=2。 +例如，你正在运行一个 10 个副本的 Deployment，其 +[maxSurge](#max-surge)=3，[maxUnavailable](#max-unavailable)=2。 + 输出类似于： ``` @@ -1086,10 +1125,12 @@ For example, you are running a Deployment with 10 replicas, [maxSurge](#max-surg * 更新 Deployment 使用新镜像，碰巧该镜像无法从集群内部解析。 ```shell - kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag + kubectl set image deployment/nginx-deployment nginx=nginx:sometag ``` - + 输出类似于： ``` @@ -1106,7 +1147,10 @@ For example, you are running a Deployment with 10 replicas, [maxSurge](#max-surg ```shell kubectl get rs ``` - + + 输出类似于： ``` @@ -1142,7 +1186,10 @@ the new replicas become healthy. To confirm this, run: ```shell kubectl get deploy ``` - + + 输出类似于： ``` @@ -1159,7 +1206,9 @@ The rollout status confirms how the replicas were added to each ReplicaSet. kubectl get rs ``` - + 输出类似于： ```shell @@ -1169,27 +1218,37 @@ nginx-deployment-618515232 11 11 11 7m ``` -## 暂停、恢复 Deployment {#pausing-and-resuming-a-deployment} +## 暂停、恢复 Deployment 的上线过程 {#pausing-and-resuming-a-deployment} -你可以在触发一个或多个更新之前暂停 Deployment，然后再恢复其执行。 +在你更新一个 Deployment 的时候，或者计划更新它的时候， +你可以在触发一个或多个更新之前暂停 Deployment 的上线过程。 +当你准备行应用这些变更时，你可以重新恢复 Deployment 上线过程。 这样做使得你能够在暂停和恢复执行之间应用多个修补程序，而不会触发不必要的上线操作。 * 例如，对于一个刚刚创建的 Deployment： - 获取 Deployment 信息： + + 获取该 Deployment 信息： ```shell kubectl get deploy ``` - + + 输出类似于： ``` @@ -1197,17 +1256,21 @@ apply multiple fixes in between pausing and resuming without triggering unnecess nginx 3 3 3 3 1m ``` - + 获取上线状态： ```shell kubectl get rs ``` - + 输出类似于： - ```shell + ``` NAME DESIRED CURRENT READY AGE nginx-2142116321 3 3 3 1m ``` @@ -1215,13 +1278,15 @@ apply multiple fixes in between pausing and resuming without triggering unnecess -* 使用如下指令暂停运行： +* 使用如下指令暂停上线： ```shell - kubectl rollout pause deployment.v1.apps/nginx-deployment + kubectl rollout pause deployment/nginx-deployment ``` - + 输出类似于： ```shell @@ -1234,10 +1299,12 @@ apply multiple fixes in between pausing and resuming without triggering unnecess * 接下来更新 Deployment 镜像： ```shell - kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 + kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 ``` - + 输出类似于： ``` @@ -1250,28 +1317,30 @@ apply multiple fixes in between pausing and resuming without triggering unnecess * 注意没有新的上线被触发： ```shell - kubectl rollout history deployment.v1.apps/nginx-deployment + kubectl rollout history deployment/nginx-deployment ``` 输出类似于： - ```shell + ``` deployments "nginx" REVISION CHANGE-CAUSE 1 ``` -* 获取上线状态确保 Deployment 更新已经成功： +* 获取上线状态验证现有的 ReplicaSet 没有被更改： ```shell kubectl get rs ``` - + 输出类似于： ```shell @@ -1285,10 +1354,12 @@ apply multiple fixes in between pausing and resuming without triggering unnecess * 你可以根据需要执行很多更新操作，例如，可以要使用的资源： ```shell - kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi + kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi ``` - + 输出类似于： ``` @@ -1296,25 +1367,27 @@ apply multiple fixes in between pausing and resuming without triggering unnecess ``` - 暂停 Deployment 之前的初始状态将继续发挥作用，但新的更新在 Deployment 被 - 暂停期间不会产生任何效果。 + 暂停 Deployment 上线之前的初始状态将继续发挥作用，但新的更新在 Deployment + 上线被暂停期间不会产生任何效果。 -* 最终，恢复 Deployment 执行并观察新的 ReplicaSet 的创建过程，其中包含了所应用的所有更新： +* 最终，恢复 Deployment 上线并观察新的 ReplicaSet 的创建过程，其中包含了所应用的所有更新： ```shell - kubectl rollout resume deployment.v1.apps/nginx-deployment + kubectl rollout resume deployment/nginx-deployment ``` - - 输出： + + 输出类似于这样： - ```shell + ``` deployment.apps/nginx-deployment resumed ``` @@ -1327,7 +1400,9 @@ apply multiple fixes in between pausing and resuming without triggering unnecess kubectl get rs -w ``` - + 输出类似于： ``` @@ -1357,7 +1432,9 @@ apply multiple fixes in between pausing and resuming without triggering unnecess kubectl get rs ``` - + 输出类似于： ``` @@ -1366,10 +1443,10 @@ apply multiple fixes in between pausing and resuming without triggering unnecess nginx-3926361531 3 3 3 28s ``` +{{< note >}} -{{< note >}} 你不可以回滚处于暂停状态的 Deployment，除非先恢复其执行状态。 {{< /note >}} @@ -1396,7 +1473,7 @@ Kubernetes marks a Deployment as _progressing_ when one of the following tasks i 执行下面的任务期间，Kubernetes 标记 Deployment 为 _进行中（Progressing）_： +当上线过程进入“Progressing”状态时，Deployment 控制器会向 Deployment 的 +`.status.conditions` 中添加包含下面属性的状况条目： + +* `type: Progressing` +* `status: "True"` +* `reason: NewReplicaSetCreated` | `reason: FoundNewReplicaSet` | `reason: ReplicaSetUpdated` + @@ -1430,6 +1518,25 @@ updates you've requested have been completed. * 与 Deployment 关联的所有副本都可用。 * 未运行 Deployment 的旧副本。 + +当上线过程进入“Complete”状态时，Deployment 控制器会向 Deployment 的 +`.status.conditions` 中添加包含下面属性的状况条目： + +* `type: Progressing` +* `status: "True"` +* `reason: NewReplicaSetAvailable` + + +这一 `Progressing` 状况的状态值会持续为 `"True"`，直至新的上线动作被触发。 +即使副本的可用状态发生变化（进而影响 `Available` 状况），`Progressing` 状况的值也不会变化。 + + 输出类似于： ``` @@ -1511,35 +1627,46 @@ deployment.apps/nginx-deployment patched Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following attributes to the Deployment's `.status.conditions`: --> -超过截止时间后，Deployment 控制器将添加具有以下属性的 DeploymentCondition 到 +超过截止时间后，Deployment 控制器将添加具有以下属性的 Deployment 状况到 Deployment 的 `.status.conditions` 中： * Type=Progressing * Status=False * Reason=ProgressDeadlineExceeded + +这一状况也可能会比较早地失败，因而其状态值被设置为 `"False"`， +其原因为 `ReplicaSetCreateError`。 +一旦 Deployment 上线完成，就不再考虑其期限。 + 参考 -[Kubernetes API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) +[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) 获取更多状态状况相关的信息。 +{{< note >}} -{{< note >}} 除了报告 `Reason=ProgressDeadlineExceeded` 状态之外，Kubernetes 对已停止的 Deployment 不执行任何操作。更高级别的编排器可以利用这一设计并相应地采取行动。 例如，将 Deployment 回滚到其以前的版本。 +{{< /note >}} -如果你暂停了某个 Deployment，Kubernetes 不再根据指定的截止时间检查 Deployment 进展。 +{{< note >}} + +如果你暂停了某个 Deployment 上线，Kubernetes 不再根据指定的截止时间检查 Deployment 进展。 你可以在上线过程中间安全地暂停 Deployment 再恢复其执行，这样做不会导致超出最后时限的问题。 {{< /note >}} @@ -1638,18 +1765,18 @@ Conditions: ``` -`Type=Available` 加上 `Status=True` 意味着 Deployment 具有最低可用性。 +`type: Available` 加上 `status: True` 意味着 Deployment 具有最低可用性。 最低可用性由 Deployment 策略中的参数指定。 -`Type=Progressing` 加上 `Status=True` 表示 Deployment 处于上线过程中，并且正在运行， +`type: Progressing` 加上 `status: True` 表示 Deployment 处于上线过程中，并且正在运行， 或者已成功完成进度，最小所需新副本处于可用。 请参阅对应状况的 Reason 了解相关细节。 -在我们的案例中 `Reason=NewReplicaSetAvailable` 表示 Deployment 已完成。 +在我们的案例中 `reason: NewReplicaSetAvailable` 表示 Deployment 已完成。 ### 对失败 Deployment 的操作 {#operating-on-a-failed-deployment} @@ -1709,11 +1836,11 @@ it is 10. Deployment 的多少个旧有 ReplicaSet。其余的 ReplicaSet 将在后台被垃圾回收。 默认情况下，此值为 10。 +{{< note >}} -{{< note >}} 显式将此字段设置为 0 将导致 Deployment 的所有历史记录被清空，因此 Deployment 将无法回滚。 {{< /note >}} @@ -1726,23 +1853,23 @@ can create multiple Deployments, one for each release, following the canary patt --> ## 金丝雀部署 {#canary-deployment} -如果要使用 Deployment 向用户子集或服务器子集上线版本，则可以遵循 -[资源管理](/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments) +如果要使用 Deployment 向用户子集或服务器子集上线版本， +则可以遵循[资源管理](/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments) 所描述的金丝雀模式，创建多个 Deployment，每个版本一个。 ## 编写 Deployment 规约 {#writing-a-deployment-spec} 同其他 Kubernetes 配置一样， Deployment 需要 `apiVersion`，`kind` 和 `metadata` 字段。 -有关配置文件的其他信息，请参考 -[部署 Deployment ](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、配置容器和 -[使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/)等相关文档。 +有关配置文件的其他信息，请参考[部署 Deployment](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、 +配置容器和[使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/)等相关文档。 `.spec.template` 是一个 [Pod 模板](/zh/docs/concepts/workloads/pods/#pod-templates)。 它和 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的语法规则完全相同。 @@ -1794,6 +1921,34 @@ allowed, which is the default if not specified. `.spec.replicas` 是指定所需 Pod 的可选字段。它的默认值是1。 + +如果你对某个 Deployment 执行了手动扩缩操作（例如，通过 +`kubectl scale deployment deployment --replicas=X`）， +之后基于清单对 Deployment 执行了更新操作（例如通过运行 +`kubectl apply -f deployment.yaml`），那么通过应用清单而完成的更新会覆盖之前手动扩缩所作的变更。 + + +如果一个 [HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) +（或者其他执行水平扩缩操作的类似 API）在管理 Deployment 的扩缩， +则不要设置 `.spec.replicas`。 + + +恰恰相反，应该允许 Kubernetes +{{< glossary_tooltip text="控制面" term_id="control-plane" >}}来自动管理 +`.spec.replicas` 字段。 + 在 API `apps/v1`版本中，`.spec.selector` 和 `.metadata.labels` 如果没有设置的话， 不会被默认设置为 `.spec.template.metadata.labels`，所以需要明确进行设置。 @@ -1825,14 +1980,14 @@ Pods with `.spec.template` if the number of Pods is less than the desired number 的总数超过 `.spec.replicas` 的设置时，Deployment 会终结之。 如果 Pods 总数未达到期望值，Deployment 会基于 `.spec.template` 创建新的 Pod。 +{{< note >}} -{{< note >}} -你不应直接创建、或者通过创建另一个 Deployment，或者创建类似 ReplicaSet -或 ReplicationController 这类控制器来创建标签与此选择算符匹配的 Pod。 +你不应直接创建与此选择算符匹配的 Pod，也不应通过创建另一个 Deployment 或者类似于 +ReplicaSet 或 ReplicationController 这类控制器来创建标签与此选择算符匹配的 Pod。 如果这样做，第一个 Deployment 会认为它创建了这些 Pod。 Kubernetes 不会阻止你这么做。 {{< /note >}} @@ -1864,6 +2019,23 @@ All existing Pods are killed before new ones are created when `.spec.strategy.ty 如果 `.spec.strategy.type==Recreate`，在创建新 Pods 之前，所有现有的 Pods 会被杀死。 +{{< note >}} + +这只会确保为了升级而创建新 Pod 之前其他 Pod 都已终止。如果你升级一个 Deployment， +所有旧版本的 Pod 都会立即被终止。控制器等待这些 Pod 被成功移除之后， +才会创建新版本的 Pod。如果你手动删除一个 Pod，其生命周期是由 ReplicaSet 来控制的， +后者会立即创建一个替换 Pod（即使旧的 Pod 仍然处于 Terminating 状态）。 +如果你需要一种“最多 n 个”的 Pod 个数保证，你需要考虑使用 +[StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)。 +{{< /note >}} + `.spec.strategy.rollingUpdate.maxUnavailable` 是一个可选字段，用来指定 -更新过程中不可用的 Pod 的个数上限。该值可以是绝对数字（例如，5），也可以是 -所需 Pods 的百分比（例如，10%）。百分比值会转换成绝对数并去除小数部分。 +更新过程中不可用的 Pod 的个数上限。该值可以是绝对数字（例如，5），也可以是所需 +Pods 的百分比（例如，10%）。百分比值会转换成绝对数并去除小数部分。 如果 `.spec.strategy.rollingUpdate.maxSurge` 为 0，则此值不能为 0。 默认值为 25%。 @@ -1901,8 +2073,8 @@ down further, followed by scaling up the new ReplicaSet, ensuring that the total at all times during the update is at least 70% of the desired Pods. --> 例如，当此值设置为 30% 时，滚动更新开始时会立即将旧 ReplicaSet 缩容到期望 Pod 个数的70%。 -新 Pod 准备就绪后，可以继续缩容旧有的 ReplicaSet，然后对新的 ReplicaSet 扩容，确保在更新期间 -可用的 Pods 总数在任何时候都至少为所需的 Pod 个数的 70%。 +新 Pod 准备就绪后，可以继续缩容旧有的 ReplicaSet，然后对新的 ReplicaSet 扩容， +确保在更新期间可用的 Pods 总数在任何时候都至少为所需的 Pod 个数的 70%。 ##### 最大峰值 {#max-surge} -`.spec.strategy.rollingUpdate.maxSurge` 是一个可选字段，用来指定可以创建的超出 -期望 Pod 个数的 Pod 数量。此值可以是绝对数（例如，5）或所需 Pods 的百分比（例如，10%）。 +`.spec.strategy.rollingUpdate.maxSurge` 是一个可选字段，用来指定可以创建的超出期望 +Pod 个数的 Pod 数量。此值可以是绝对数（例如，5）或所需 Pods 的百分比（例如，10%）。 如果 `MaxUnavailable` 为 0，则此值不能为 0。百分比值会通过向上取整转换为绝对数。 此字段的默认值为 25%。 @@ -1934,8 +2106,8 @@ total number of Pods running at any time during the update is at most 130% of de `.spec.progressDeadlineSeconds` is an optional field that specifies the number of seconds you want to wait for your Deployment to progress before the system reports back that the Deployment has -[failed progressing](#failed-deployment) - surfaced as a condition with `Type=Progressing`, `Status=False`. -and `Reason=ProgressDeadlineExceeded` in the status of the resource. The Deployment controller will keep +[failed progressing](#failed-deployment) - surfaced as a condition with `type: Progressing`, `status: False`. +and `reason: ProgressDeadlineExceeded` in the status of the resource. The Deployment controller will keep retrying the Deployment. In the future, once automatic rollback will be implemented, the Deployment controller will roll back a Deployment as soon as it observes such a condition. --> @@ -1943,8 +2115,8 @@ controller will roll back a Deployment as soon as it observes such a condition. `.spec.progressDeadlineSeconds` 是一个可选字段，用于指定系统在报告 Deployment [进展失败](#failed-deployment) 之前等待 Deployment 取得进展的秒数。 -这类报告会在资源状态中体现为 `Type=Progressing`、`Status=False`、 -`Reason=ProgressDeadlineExceeded`。Deployment 控制器将持续重试 Deployment。 +这类报告会在资源状态中体现为 `type: Progressing`、`status: False`、 +`reason: ProgressDeadlineExceeded`。Deployment 控制器将持续重试 Deployment。 将来，一旦实现了自动回滚，Deployment 控制器将在探测到这样的条件时立即回滚 Deployment。 ### 最短就绪时间 {#min-ready-seconds} -`.spec.minReadySeconds` 是一个可选字段，用于指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间， +`.spec.minReadySeconds` 是一个可选字段，用于指定新创建的 Pod +在没有任意容器崩溃情况下的最小就绪时间， 只有超出这个时间 Pod 才被视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。 -要了解何时 Pod 被视为就绪，可参考[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。 +要了解何时 Pod 被视为就绪， +可参考[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。 +* 了解 [Pod](/zh/docs/concepts/workloads/pods)。 +* [使用 Deployment 运行一个无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。 +* `Deployment` 是 Kubernetes REST API 中的一个顶层资源。 + 阅读 {{< api-reference page="workload-resources/deployment-v1" >}} + 对象定义，以了解 Deployment 的 API 细节。 +* 阅读 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/) + 了解如何使用它来在可能出现干扰的情况下管理应用的可用性。 +