From 1d3f4449a4653d1eec735dcc697b005393dc0924 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Tue, 11 Aug 2020 16:05:33 +0800 Subject: [PATCH] [zh] Tidy up and fix links in tasks section (3/10) --- .../zh/docs/concepts/architecture/nodes.md | 2 +- .../workloads/controllers/statefulset.md | 2 + .../tasks/run-application/configure-pdb.md | 425 +++++++++++------- .../force-delete-stateful-set-pod.md | 127 +++--- .../horizontal-pod-autoscale-walkthrough.md | 267 +++++------ .../horizontal-pod-autoscale.md | 336 +++++++------- 6 files changed, 627 insertions(+), 532 deletions(-) diff --git a/content/zh/docs/concepts/architecture/nodes.md b/content/zh/docs/concepts/architecture/nodes.md index ac6d1f3e95..00e221aec1 100644 --- a/content/zh/docs/concepts/architecture/nodes.md +++ b/content/zh/docs/concepts/architecture/nodes.md @@ -252,7 +252,7 @@ kubectl describe node <节点名称> The usage of these fields varies depending on your cloud provider or bare metal configuration. --> -### 地址 {#addresses} +### 地址 {#addresses} 这些字段的用法取决于你的云服务商或者物理机配置。 diff --git a/content/zh/docs/concepts/workloads/controllers/statefulset.md b/content/zh/docs/concepts/workloads/controllers/statefulset.md index 100343be99..a827581250 100644 --- a/content/zh/docs/concepts/workloads/controllers/statefulset.md +++ b/content/zh/docs/concepts/workloads/controllers/statefulset.md @@ -254,6 +254,8 @@ the StatefulSet. +## 部署和扩缩保证 {#deployment-and-scaling-guarantees} * For a StatefulSet with N replicas, when Pods are being deployed, they are created sequentially, in order from {0..N-1}. * When Pods are being deleted, they are terminated in reverse order, from {N-1..0}. diff --git a/content/zh/docs/tasks/run-application/configure-pdb.md b/content/zh/docs/tasks/run-application/configure-pdb.md index faeba16c3c..5fb983c4ee 100644 --- a/content/zh/docs/tasks/run-application/configure-pdb.md +++ b/content/zh/docs/tasks/run-application/configure-pdb.md @@ -1,71 +1,71 @@ --- -title: 指定应用程序的中断预算（Disruption Budget） +title: 为应用程序设置干扰预算（Disruption Budget） content_type: task weight: 110 --- - +--> - - -本文展示了如何限制应用程序的并发中断数量，在允许集群管理员管理集群节点的同时保证高可用。 - - +nodes. +--> +本文展示如何限制应用程序的并发干扰数量，在允许集群管理员管理集群节点的同时保证高可用。 ## {{% heading "prerequisites" %}} - - -* 用户是 Kubernetes 集群中有高可用需求的应用的所有者。 - - -* 用户应了解如何部署 [无状态应用](/docs/tasks/run-application/run-stateless-application-deployment/) -和/或 [有状态应用](/docs/tasks/run-application/run-replicated-stateful-application/)。 - - -* 用户应当已经阅读过关于 [Pod 中断](/docs/concepts/workloads/pods/disruptions/) 的文档。 - - -* 用户应当与集群所有者或服务提供者确认其遵从 Pod 中断预算（Pod Disruption Budgets）的规则。 - - + +* 你是 Kubernetes 集群中某应用的所有者，该应用有高可用要求。 +* 你应了解如何部署[无状态应用](.zh/docs/tasks/run-application/run-stateless-application-deployment/) + 和/或[有状态应用](/zh/docs/tasks/run-application/run-replicated-stateful-application/)。 +* 你应当已经阅读过关于 [Pod 干扰](/zh/docs/concepts/workloads/pods/disruptions/) 的文档。 +* 用户应当与集群所有者或服务提供者确认其遵从 Pod 干扰预算（Pod Disruption Budgets）的规则。 - -## 用 PodDisruptionBudget 来保护应用 + +1. Create the PDB object from the YAML file. +--> +## 用 PodDisruptionBudget 来保护应用 1. 确定想要使用 PodDisruptionBudget (PDB) 来保护的应用。 -1. 考虑应用对中断的反应。 +1. 考虑应用对干扰的反应。 1. 以 YAML 文件形式定义 PDB 。 1. 通过 YAML 文件创建 PDB 对象。 - - - + ## 确定要保护的应用 - 用户想要保护通过内置的 Kubernetes 控制器指定的应用，这是最常见的使用场景： - Deployment @@ -73,24 +73,34 @@ specified by one of the built-in Kubernetes controllers: --> - ReplicaSet - StatefulSet - -在这种情况下，在控制器的 `.spec.selector` 字段中做记录，并在 PDB 的 `.spec.selector` 字段中加入同样的选择器。 + +在这种情况下，在控制器的 `.spec.selector` 字段中做记录，并在 PDB 的 +`.spec.selector` 字段中加入同样的选择算符。 - -用户也可以用 PDB 来保护不受上述控制器控制的 pod，或任意组（arbitrary groups）的 pod， 但是正如 [任意控制器和选择器](#arbitrary-controllers-and-selectors) 中描述的，这里存在一些限制。 +described in [Arbitrary Controllers and Selectors](#arbitrary-controllers-and-selectors). +--> +用户也可以用 PDB 来保护不受上述控制器控制的 Pod，或任意的 Pod 集合，但是正如 +[任意控制器和选择算符](#arbitrary-controllers-and-selectors)中描述的，这里存在一些限制。 - -## 考虑应用对中断的反应 + -确定在自发中断时，多少实例可以在短时间内同时关闭。 +Decide how many instances can be down at the same time for a short period +due to a voluntary disruption. +--> +## 考虑应用对干扰的反应 - - Possible Solution 2: set minAvailable to quorum-size (e.g. 3 when scale is 5). (Allows more disruptions at once). - Restartable Batch Job: - Concern: Job needs to complete in case of voluntary disruption. - - Possible solution: Do not create a PDB. The Job controller will create a replacement pod. --> - + - Possible solution: Do not create a PDB. The Job controller will create a replacement pod. +--> - 无状态的前端： - - 关注：不能降低服务能力 10% 以上。 - - 解决方案：例如，使用 PDB，指定其 minAvailable 值为 90%。 + - 关注：不能降低服务能力 10% 以上。 + - 解决方案：例如，使用 PDB，指定其 minAvailable 值为 90%。 - 单实例有状态应用： - - 关注：不要在不通知的情况下终止该应用。 - - 可能的解决方案 1：不使用 PDB，并忍受偶尔的停机。 - - 可能的解决方案 2：设置 maxUnavailable=0 的 PDB。意为（Kubernetes 范畴之外的） 集群操作人员需要在终止应用前与用户协商，协商后准备停机，然后删除 PDB 表示准备中断，后续再重新创建。 -- 多实例有状态应用， 如 Consul、ZooKeeper 或 etcd： - - 关注：不要将实例数量减少至低于仲裁规模（below quorum），否则将写入失败。 - - 可能的解决方案 1：设置 maxUnavailable 值为 1 (适用于不同规模的应用)。 - - 可能的解决方案 2：设置 minAvailable 值为仲裁规模（例如规模为 5 时设置为 3）。 (允许每次更多的中断)。 + - 关注：不要在不通知的情况下终止该应用。 + - 可能的解决方案 1：不使用 PDB，并忍受偶尔的停机。 + - 可能的解决方案 2：设置 maxUnavailable=0 的 PDB。 + 意为（Kubernetes 范畴之外的）集群操作人员需要在终止应用前与用户协商， + 协商后准备停机，然后删除 PDB 表示准备接受干扰，后续再重新创建。 +- 多实例有状态应用，如 Consul、ZooKeeper 或 etcd： + - 关注：不要将实例数量减少至低于仲裁规模，否则将出现写入失败。 + - 可能的解决方案 1：设置 maxUnavailable 值为 1 (适用于不同规模的应用)。 + - 可能的解决方案 2：设置 minAvailable 值为仲裁规模（例如规模为 5 时设置为 3）。 + (允许同时出现更多的干扰)。 - 可重新启动的批处理任务： - - 关注： 自发中断的情况下，需要确保任务完成。 - - 可能的解决方案：不创建 PDB。 任务控制器会创建一个替换的 pod。 + - 关注：自发干扰的情况下，需要确保任务完成。 + - 可能的解决方案：不创建 PDB。 任务控制器会创建一个替换 Pod。 - + ### 指定百分比时的舍入逻辑 - `minAvailable` 或 `maxUnavailable` 的值可以表示为整数或百分比。 - -- 指定整数时，它表示许多Pod。 例如，如果将minAvailable设置为10，那么即使在中断期间，也必须始终有10个Pod可用。 - -- 通过将值设置为百分比的字符串表示形式（例如“50％”）来指定百分比时，它表示总 Pod 数的百分比。例如，如果将 "minUnavailable" 设置为“50％”，则只有50％的 Pod 可以中断。 + disruption. +--> +- 指定整数值时，它表示 Pod 个数。例如，如果将 minAvailable 设置为 10， + 那么即使在干扰期间，也必须始终有 10 个Pod可用。 +- 通过将值设置为百分比的字符串表示形式（例如 “50％”）来指定百分比时，它表示占总 Pod 数的百分比。 + 例如，如果将 "minUnavailable" 设置为 “50％”，则干扰期间只允许 50％ 的 Pod 不可用。 - -如果将值指定为百分比，则可能无法映射到确切数量的 Pod 。例如，如果您有 7 个 Pod ，并且你将 `minAvailable` 设置为 `"50％"`，这不清楚是 3 个 Pod 或 4 个 Pod 必须可用。 -Kubernetes 向上取整到最接近的整数，因此在这种情况下，必须有 4 个 Pod 。 -您可以检查控制此行为的[代码](https://github.com/kubernetes/kubernetes/blob/23be9587a0f8677eb8091464098881df939c44a9/pkg/controller/disruption/disruption.go#L539)。 +that controls this behavior. +--> +如果将值指定为百分比，则可能无法映射到确切数量的 Pod。例如，如果你有 7 个 Pod， +并且你将 `minAvailable` 设置为 `"50％"`，具体是 3 个 Pod 或 4 个 Pod 必须可用 +并非显而易见。 +Kubernetes 采用向上取整到最接近的整数的办法，因此在这种情况下，必须有 4 个 Pod。 +你可以检查控制此行为的 +[代码](https://github.com/kubernetes/kubernetes/blob/23be9587a0f8677eb8091464098881df939c44a9/pkg/controller/disruption/disruption.go#L539)。 - + ## 指定 PodDisruptionBudget - 一个 `PodDisruptionBudget` 有 3 个字段： - -* 标签选择器 `.spec.selector` ，用于指定其所作用的 pod 集合， 该字段为必须字段。 -* `.spec.minAvailable` 表示驱逐后仍然保证可用的 pod 数量。即使因此影响到 pod 驱逐（即该条件在和 pod 驱逐发生冲突时优先保证）。 - `minAvailable` 值可以是绝对值，也可以是百分比。 -* `.spec.maxUnavailable` （Kubernetes 1.7 及更高的版本中可用）表示驱逐后允许不可用的 pod 的最大数量。 -其值可以是绝对值或是百分比。 +* `.spec.maxUnavailable` (available in Kubernetes 1.7 and higher) which is a description +of the number of pods from that set that can be unavailable after the eviction. +It can be either an absolute number or a percentage. +--> +* 标签选择算符 `.spec.selector` 用于指定其所作用的 Pod 集合，该字段为必需字段。 +* `.spec.minAvailable` 表示驱逐后仍须保证可用的 Pod 数量。即使因此影响到 Pod 驱逐 + （即该条件在和 Pod 驱逐发生冲突时优先保证）。 + `minAvailable` 值可以是绝对值，也可以是百分比。 +* `.spec.maxUnavailable` （Kubernetes 1.7 及更高的版本中可用）表示驱逐后允许不可用的 + Pod 的最大数量。其值可以是绝对值或是百分比。 -{{< note >}} - -对于1.8及更早的版本：当你用 `kubectl` 命令行工具创建 `PodDisruptionBudget`对象时，如果既未指定 `minAvailable` 也未指定 `maxUnavailable`， -则 `minAvailable` 字段有一个默认值1。 +default value of 1 if neither `minAvailable` nor `maxUnavailable` is specified. +--> +{{< note >}} +对于1.8及更早的版本：当你用 `kubectl` 命令行工具创建 `PodDisruptionBudget` 对象时， +如果既未指定 `minAvailable` 也未指定 `maxUnavailable`， +则 `minAvailable` 字段有一个默认值 1。 {{< /note >}} - -用户在同一个 `PodDisruptionBudget` 中只能够指定 `maxUnavailable` 和 `minAvailable` 中的一个。`maxUnavailable` -只能够用于控制存在相应控制器的 pod 的驱逐（即不受控制器控制的 pod 不在 `maxUnavailable` 控制范围内）。在下面的示例中， -“所需副本” 指的是相应控制器的 `scale`， 控制器对 `PodDisruptionBudget` 所选择的 pod 进行管理。 +`PodDisruptionBudget`. +--> +用户在同一个 `PodDisruptionBudget` 中只能够指定 `maxUnavailable` 和 `minAvailable` 中的一个。 +`maxUnavailable` 只能够用于控制存在相应控制器的 Pod 的驱逐（即不受控制器控制的 Pod 不在 +`maxUnavailable` 控制范围内）。在下面的示例中， +“所需副本” 指的是相应控制器的 `scale`，控制器对 `PodDisruptionBudget` 所选择的 Pod 进行管理。 - -示例 1：设置 `minAvailable` 值为 5 的情况下，驱逐时需保证 PodDisruptionBudget 的 `selector` 选中的 pod 中 5 个 或 5 个以上处于健康状态。 + +示例 1：设置 `minAvailable` 值为 5 的情况下，驱逐时需保证 PodDisruptionBudget 的 `selector` +选中的 Pod 中 5 个或 5 个以上处于健康状态。 - -示例 2：设置 `minAvailable` 值为 30% 的情况下，驱逐时需保证 pod 所需副本的至少 30% 处于健康状态。 + +示例 2：设置 `minAvailable` 值为 30% 的情况下，驱逐时需保证 Pod 所需副本的至少 30% 处于健康状态。 - + 示例 3：设置 `maxUnavailable` 值为 5 的情况下，驱逐时需保证所需副本中最多 5 个处于不可用状态。 -Example 4: With a `maxUnavailable` of 30%, evictions are allowed as long as no more than 30% + +示例 4：设置 `maxUnavailable` 值为 30% 的情况下，驱逐时需保证所需副本中最多 30% 处于不可用状态。 - -在典型用法中，中断预算会被用于一个控制器管理的一组 pod 中——例如：一个 ReplicaSet 或 StatefulSet 中的 pod。 + +在典型用法中，干扰预算会被用于一个控制器管理的一组 Pod 中 —— 例如：一个 ReplicaSet 或 StatefulSet +中的 Pod。 -{{< note >}} - -注意：中断预算并不能真正保证指定数量/百分比的 pod 一直处于运行状态。例如： 当 pod 集合的 -规模处于预算指定的最小值时，承载集合中某个 pod 的节点发生了故障，这样就导致集合中可用 pod 的 -数量低于预算指定值。预算只能够针对自发的驱逐提供保护，而不能针对所有 pod 不可用的诱因。 +voluntary evictions, not all causes of unavailability. +--> +{{< note >}} +干扰预算并不能真正保证指定数量/百分比的 Pod 一直处于运行状态。例如： 当 Pod 集合的 +规模处于预算指定的最小值时，承载集合中某个 Pod 的节点发生了故障，这样就导致集合中可用 Pod 的 +数量低于预算指定值。预算只能够针对自发的驱逐提供保护，而不能针对所有 Pod 不可用的诱因。 {{< /note >}} - -设置 `maxUnavailable` 值为 0% （或 0 ）或设置 `minAvailable` 值为 100% （或等于副本数） 可能会 -阻塞节点，导致资源耗尽。按照 `PodDisruptionBudget` 的语义，这是允许的。 + +设置 `maxUnavailable` 值为 0%（或 0）或设置 `minAvailable` 值为 100%（或等于副本数） +可能会阻塞节点，导致资源耗尽。按照 `PodDisruptionBudget` 的语义，这是允许的。 - -用户可以在下面看到 pod 中断预算定义的示例，它们与带有 `app: zookeeper` 标签的 pod 相匹配： + +用户可以在下面看到 pod 干扰预算定义的示例，它们与带有 `app: zookeeper` 标签的 pod 相匹配： - + 使用 minAvailable 的PDB 示例： {{< codenew file="policy/zookeeper-pod-disruption-budget-minavailable.yaml" >}} - + 使用 maxUnavailable 的 PDB 示例（Kubernetes 1.7 或更高的版本）： {{< codenew file="policy/zookeeper-pod-disruption-budget-maxunavailable.yaml" >}} - -例如，如果上述 `zk-pdb` 选择的是一个规格为 3 的 StatefulSet 对应的 pod，那么上面两种规范的含义完全相同。 +automatically responds to changes in the number of replicas of the corresponding controller. +--> +例如，如果上述 `zk-pdb` 选择的是一个规格为 3 的 StatefulSet 对应的 Pod， +那么上面两种规范的含义完全相同。 推荐使用 `maxUnavailable` ，因为它自动响应控制器副本数量的变化。 + ## 创建 PDB 对象 - -用户可以通过类似 `kubectl create -f mypdb.yaml` 的命令来创建 PDB。 +你可以通过类似 `kubectl apply -f mypdb.yaml` 的命令来创建 PDB。 - + PDB 对象无法更新，必须删除后重新创建。 + ## 检查 PDB 的状态 - 使用 kubectl 来确认 PDB 被创建。 - -假设用户的名字空间下没有匹配 `app: zookeeper` 的 pod，用户会看到类似下面的信息： + +假设用户的名字空间下没有匹配 `app: zookeeper` 的 Pod，用户会看到类似下面的信息： ```shell kubectl get poddisruptionbudgets ``` ``` -NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE -zk-pdb 2 0 7s +NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE +zk-pdb 2 N/A 0 7s ``` - -假设有匹配的 pod (比如说 3 个), 那么用户会看到类似下面的信息： + +假设有匹配的 Pod (比如说 3 个), 那么用户会看到类似下面的信息： ```shell kubectl get poddisruptionbudgets ``` ``` -NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE -zk-pdb 2 1 7s +NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE +zk-pdb 2 N/A 1 7s + ``` - -`ALLOWED-DISRUPTIONS` 值非 0 意味着中断控制器已经感知到相应的 pod， 对匹配的 pod 进行统计，并更新了 PDB 的状态。 + +`ALLOWED-DISRUPTIONS` 值非 0 意味着干扰控制器已经感知到相应的 Pod，对匹配的 Pod 进行统计， +并更新了 PDB 的状态。 - 用户可以通过以下命令获取更多 PDB 状态相关信息： ```shell kubectl get poddisruptionbudgets zk-pdb -o yaml ``` + ```yaml apiVersion: policy/v1beta1 kind: PodDisruptionBudget metadata: - creationTimestamp: 2017-08-28T02:38:26Z + anntation: {} + creationTimestamp: "2020-03-04T04:22:56Z" generation: 1 name: zk-pdb … status: currentHealthy: 3 - desiredHealthy: 3 - disruptedPods: null + desiredHealthy: 2 disruptionsAllowed: 1 expectedPods: 3 observedGeneration: 1 ``` - -## 任意控制器和选择器 + -如果用户只使用与内置的应用控制器（Deployment、ReplicationController、ReplicaSet 和 StatefulSet） -对应的 PDB，也就是 PDB 的选择器与 控制器的选择器相匹配，那么可以跳过这一节。 +with the PDB selector matching the controller's selector. +--> +## 任意控制器和选择算符 {#arbitrary-controllers-and-selectors} - -用户可以使用这样的 PDB：它对应的 pod 可能由其他类型的控制器控制，可能由 "operator" 控制， -也可能为“裸的（不受控制器控制）” pod，但该类 PDB 存在以下限制： +如果你只使用与内置的应用控制器（Deployment、ReplicationController、ReplicaSet 和 StatefulSet） +对应的 PDB，也就是 PDB 的选择算符与 控制器的选择算符相匹配，那么可以跳过这一节。 + +你可以使用这样的 PDB：它对应的 Pod 可能由其他类型的控制器控制，可能由 "operator" 控制， +也可能为“裸的（不受控制器控制）” Pod，但该类 PDB 存在以下限制： + + - 只能够使用 `.spec.minAvailable` ，而不能够使用 `.spec.maxUnavailable。` - 只能够使用整数作为 `.spec.minAvailable` 的值，而不能使用百分比。 - -用户可以令选择器选择一个内置控制器所控制 pod 的子集或父集。然而，当名字空间下存在多个 PDB 时， -用户必须小心，保证 PDB 的选择器之间不重叠。 - - +to create PDBs whose selectors overlap. +--> +你可以令选择算符选择一个内置控制器所控制 Pod 的子集或父集。 +然而，当名字空间下存在多个 PDB 时，用户必须小心，保证 PDB 的选择算符之间不重叠。 diff --git a/content/zh/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/zh/docs/tasks/run-application/force-delete-stateful-set-pod.md index 3a401d617a..c2e678d93c 100644 --- a/content/zh/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/zh/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -1,16 +1,10 @@ --- -reviewers: -- bprashanth -- erictune -- foxish -- smarterclayton title: 强制删除 StatefulSet 类型的 Pods content_type: task weight: 70 --- +--> -本文介绍了如何删除 StatefulSet 管理的部分 pods，并且解释了这样操作时需要记住的注意事项。 - +This page shows how to delete Pods which are part of a {{< glossary_tooltip text="stateful set" term_id="StatefulSet" >}}, and explains the considerations to keep in mind when doing so. +--> +本文介绍了如何删除 {{< glossary_tooltip text="StatefulSet" term_id="StatefulSet" >}} +管理的 Pods，并且解释了这样操作时需要记住的注意事项。 ## {{% heading "prerequisites" %}} - +--> * 这是一项相当高级的任务，并且可能会违反 StatefulSet 固有的某些属性。 * 继续任务之前，请熟悉下面列举的注意事项。 - - + +In normal operation of a StatefulSet, there is **never** a need to force delete a StatefulSet Pod. The [StatefulSet controller](/docs/concepts/workloads/controllers/statefulset/) is responsible for creating, scaling and deleting members of the StatefulSet. It tries to ensure that the specified number of Pods from ordinal 0 through N-1 are alive and ready. StatefulSet ensures that, at any time, there is at most one Pod with a given identity running in a cluster. This is referred to as *at most one* semantics provided by a StatefulSet. +--> ## StatefulSet 注意事项 - -在 StatefulSet 的正常操作中，**永远不**需要强制删除 StatefulSet 管理的 pod。StatefulSet 控制器负责创建，扩容和删除 StatefulSet 管理的 pods。它尝试确保从序号 0 到 N-1 指定数量的 pods 处于活动状态并准备就绪。StatefulSet 确保在任何时候，集群中最多只有一个具有给定标识的 pod。这就是所谓的由 StatefulSet 提供的*最多一个*的语义。 +在 StatefulSet 的正常操作中，**永远不**需要强制删除 StatefulSet 管理的 Pod。 +[StatefulSet 控制器](/zh/docs/concepts/workloads/controllers/statefulset/)负责创建、 +扩缩和删除 StatefulSet 管理的 Pods。它尝试确保指定数量的从序数 0 到 N-1 的 Pod +处于活跃状态并准备就绪。StatefulSet 确保在任何时候，集群中最多只有一个具有给定标识的 Pod。 +这就是所谓的由 StatefulSet 提供的*最多一个（At Most One）*的语义。 -应谨慎进行手动强制删除操作，因为它可能会违反 StatefulSet 固有的至多一个的语义。StatefulSets 可用于运行分布式和集群级的应用，这些应用需要稳定的网络标识和可靠的存储。这些应用通常配置为具有固定标识固定数量的成员集合。具有相同身份的多个成员可能是灾难性的，并且可能导致数据丢失 (e.g. 基于 quorum 系统中的脑裂场景)。 +--> +应谨慎进行手动强制删除操作，因为它可能会违反 StatefulSet 固有的至多一个的语义。 +StatefulSets 可用于运行分布式和集群级的应用，这些应用需要稳定的网络标识和可靠的存储。 +这些应用通常配置为具有固定标识固定数量的成员集合。 +具有相同身份的多个成员可能是灾难性的，并且可能导致数据丢失 (例如：票选系统中的脑裂场景)。 -## 删除 Pods - -您可以使用下面的命令执行优雅地删除 pod: +--> +## 删除 Pods {#delete-pods} + +你可以使用下面的命令执行体面地删除 Pod: ```shell kubectl delete pods @@ -74,52 +69,69 @@ kubectl delete pods -为了使上面的方法能够正常终止，Pod **一定不能**设置 `pod.Spec.TerminationGracePeriodSeconds` 为 0。将 `pod.Spec.TerminationGracePeriodSeconds` 设置为 0s 的做法是不安全的，强烈建议 StatefulSet 类型的 pods 不要使用。优雅删除是安全的，并且会在 kubelet 从 apiserver 中删除名称之前确保 [优雅地关闭 pod ](/docs/user-guide/pods/#termination-of-pods)。 +--> +为了让上面操作能够体面地终止 Pod，Pod **一定不能** 设置 `pod.Spec.TerminationGracePeriodSeconds` 为 0。 +将 `pod.Spec.TerminationGracePeriodSeconds` 设置为 0s 的做法是不安全的，强烈建议 StatefulSet 类型的 +Pod 不要使用。体面删除是安全的，并且会在 kubelet 从 API 服务器中删除资源名称之前确保 +[体面地结束 pod ](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。 -Kubernetes (1.5 版本或者更新版本)不会因为一个 Node 无法访问而删除 pods。在无法访问节点上运行的 pods 在[超时](/docs/admin/node/#node-condition)后会进入'Terminating' 或者 'Unknown' 状态。当用户尝试优雅删除无法访问节点上的 pod 时，pods 也可能会进入这些状态。从 apiserver 中删除处于这些状态 pod 的唯一方法如下： +--> +Kubernetes（1.5 版本或者更新版本）不会因为一个节点无法访问而删除 Pod。 +在无法访问的节点上运行的 Pod 在 +[超时](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-condition) +后会进入'Terminating' 或者 'Unknown' 状态。 +当用户尝试体面地删除无法访问的节点上的 Pod 时 Pod 也可能会进入这些状态。 +从 API 服务器上删除处于这些状态 Pod 的仅有可行方法如下： - * Node 对象被删除(要么您删除, 或者[Node Controller](/docs/admin/node))。
- * 无响应节点上的 kubelet 开始响应，杀死 pod 并从 apiserver 中移除该条目。
- * 用户强制删除 pod。 +--> +* 删除 Node 对象（要么你来删除, 要么[节点控制器](/zh/docs/concepts/architecture/nodes/#node-controller) + 来删除） +* 无响应节点上的 kubelet 开始响应，杀死 Pod 并从 API 服务器上移除 Pod 对象 +* 用户强制删除 pod -推荐使用第一种或者第二种方法。如果确认节点已经不可用了 (比如，永久断开网络，断电等)，则删除 Node 对象。如果节点遇到网裂，请尝试解决该问题或者等待其解决。当网裂愈合时，kubelet 将完成 pod 的删除并从 apiserver 中释放其名字。 +--> +推荐使用第一种或者第二种方法。如果确认节点已经不可用了 (比如，永久断开网络、断电等)， +则应删除 Node 对象。 +如果节点遇到网裂问题，请尝试解决该问题或者等待其解决。 +当网裂愈合时，kubelet 将完成 Pod 的删除并从 API 服务器上释放其名字。 -通常，pod 一旦不在节点上运行，或者管理员删除了节点，系统就会完成删除。你可以通过强制删除 pod 来覆盖它。 +--> +通常，Pod 一旦不在节点上运行，或者管理员删除了节点，系统就会完成其删除动作。 +你也可以通过强制删除 Pod 来绕过这一机制。 -### 强制删除 - -强制删除**不要**等待来自 kubelet 的确认 pod 已被终止。无论强制删除是否成功杀死了 pod，它都会立即从 apiserver 中释放该名字。这将让 StatefulSet 控制器创建一个具有相同标识的替换 pod；这可能导致正在运行 pod 的重复，并且如果所述 pod 仍然可以与 StatefulSet 的成员通信，则将违反 StatefulSet 旨在保证的最多一个的语义。 +--> +### 强制删除 {#force-deletion} + +强制删除**不会**等待来自 kubelet 对 Pod 已终止的确认消息。 +无论强制删除是否成功杀死了 Pod，它都会立即从 API 服务器中释放该名字。 +这将让 StatefulSet 控制器创建一个具有相同标识的替身 Pod；因而可能导致正在运行 Pod 的重复， +并且如果所述 Pod 仍然可以与 StatefulSet 的成员通信，则将违反 StatefulSet 所要保证的 +最多一个的语义。 -当你强制删除 StatefulSet 类型的 pod 时，你要确保有问题的 pod 不会再和 StatefulSet 管理的其他 pods通信，并且可以安全地释放其名字以便创建替换 pod。 +--> +当你强制删除 StatefulSet 类型的 Pod 时，你要确保有问题的 Pod 不会再和 StatefulSet 管理的其他 +Pod 通信并且可以安全地释放其名字以便创建替代 Pod。 -如果要使用 kubectl version >= 1.5 强制删除 pod，请执行下面命令： +--> +如果要使用 kubectl 1.5 以上版本强制删除 Pod，请执行下面命令： ```shell kubectl delete pods --grace-period=0 --force @@ -127,16 +139,17 @@ kubectl delete pods --grace-period=0 --force -如果您使用 kubectl <= 1.4 的任何版本，则应省略 `--force` 选项： +--> +如果你使用 kubectl 的 1.4 以下版本，则应省略 `--force` 选项： ```shell kubectl delete pods --grace-period=0 ``` + -如果在这些命令后 pod 仍处于`Unknown`状态，请使用以下命令从集群中删除 pod: +--> +如果在这些命令后 Pod 仍处于 `Unknown` 状态，请使用以下命令从集群中删除 Pod: ```shell kubectl patch pod -p '{"metadata":{"finalizers":null}}' @@ -144,17 +157,15 @@ kubectl patch pod -p '{"metadata":{"finalizers":null}}' +--> 请始终谨慎地执行强制删除 StatefulSet 类型的 pods，并完全了解所涉及地风险。 - ## {{% heading "whatsnext" %}} - -进一步了解[调试 StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/)。 +--> +进一步了解[调试 StatefulSet](/zh/docs/tasks/debug-application-cluster/debug-stateful-set/)。 diff --git a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 58ee1d72a2..1dd802ae11 100644 --- a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -1,13 +1,19 @@ --- +title: Horizontal Pod Autoscaler 演练 +content_type: task +weight: 100 +--- + + @@ -16,32 +22,30 @@ Horizontal Pod Autoscaler automatically scales the number of pods in a replication controller, deployment or replica set based on observed CPU utilization (or, with beta support, on some other, application-provided metrics). --> -Horizontal Pod Autoscaler 可以根据CPU利用率自动伸缩 replication controller、deployment 或者 replica set 中的Pod数量 +Horizontal Pod Autoscaler 可以根据 CPU 利用率自动扩缩 ReplicationController、Deployment 或者 ReplicaSet 中的 Pod 数量 （也可以基于其他应用程序提供的度量指标，目前这一功能处于 beta 版本）。 -本文将引导您了解如何为 php-apache 服务器配置和使用 Horizontal Pod Autoscaler。 -更多 Horizontal Pod Autoscaler 的信息请参阅 [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/)。 - - - - +本文将引领你了解如何为 php-apache 服务器配置和使用 Horizontal Pod Autoscaler。 +更多 Horizontal Pod Autoscaler 的信息请参阅 +[Horizontal Pod Autoscaler 用户指南](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)。 ## {{% heading "prerequisites" %}} - -本文示例需要一个1.2或者更高版本的可运行的 Kubernetes 集群以及 kubectl。 -[metrics-server](https://github.com/kubernetes-incubator/metrics-server/) 也需要部署到集群中， -它可以通过 resource metrics API 对外提供度量数据，Horizontal Pod Autoscaler 正是根据此 API 来获取度量数据，部署方法请参考 [metrics-server](https://github.com/kubernetes-incubator/metrics-server/) 。 -如果你正在使用GCE，按照 [getting started on GCE guide](/docs/setup/production-environment/turnkey/gce/) 操作，metrics-server 会默认启动。 +本文示例需要一个运行中的 Kubernetes 集群以及 kubectl，集群中还要部署 1.2 或更高 +版本的 [Metrics 服务器](https://github.com/kubernetes-incubator/metrics-server/)。 +Metrics 服务器可以通过资源度量值 API 对外提供度量数据，Horizontal Pod Autoscaler +正是根据此 API 来获取度量数据。 +部署方法请参考 [metrics-server](https://github.com/kubernetes-incubator/metrics-server/) 。 +如果你正在使用 GCE，按照 [GCE 指南中的入门说明](/zh/docs/setup/production-environment/turnkey/gce/) 操作，metrics-server 会默认启动。 -如果需要为 Horizontal Pod Autoscaler 指定多种资源度量指标，您的 Kubernetes 集群以及 kubectl 至少需要达到1.6版本。 -此外，如果要使用自定义度量指标，您的Kubernetes 集群还必须能够与提供这些自定义指标的API服务器通信。 -最后，如果要使用与 Kubernetes 对象无关的度量指标，则 Kubernetes 集群版本至少需要达到1.10版本，同样，需要保证集群能够与提供这些外部指标的API服务器通信。 -更多详细信息，请参阅[Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)。 - - +如果需要为 Horizontal Pod Autoscaler 指定多种资源度量指标，你的 Kubernetes 集群以及 kubectl 至少需要达到 1.6 版本。 +此外，如果要使用自定义度量指标，你的 Kubernetes 集群还必须能够与提供这些自定义指标 +的 API 服务器通信。 +最后，如果要使用与 Kubernetes 对象无关的度量指标，则 Kubernetes 集群版本至少需要 +达到 1.10 版本，同样，需要保证集群能够与提供这些外部指标的 API 服务器通信。 +更多详细信息，请参阅[Horizontal Pod Autoscaler 用户指南](/zh/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)。 -## 第一步：运行 php-apache 服务器并暴露服务 +## 运行 php-apache 服务器并暴露服务 -为了演示 Horizontal Pod Autoscaler，我们将使用一个基于 php-apache 镜像的定制 Docker 镜像。 -Dockerfile 内容如下： +为了演示 Horizontal Pod Autoscaler，我们将使用一个基于 php-apache 镜像的定制 Docker 镜像。 Dockerfile 内容如下： ``` FROM php:5-apache COPY index.php /var/www/html/index.php RUN chmod a+rx index.php ``` + -它定义一个 index.php 页面来执行一些 CPU 密集型计算： +该文件定义了一个 index.php 页面来执行一些 CPU 密集型计算： ``` ``` + -首先，我们先启动一个 deployment 来运行这个镜像并暴露一个服务: +首先，我们先启动一个 Deployment 来运行这个镜像并暴露一个服务： ```shell kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80 ``` + ``` service/php-apache created deployment.apps/php-apache created @@ -106,10 +112,7 @@ deployment.apps/php-apache created -## 创建 Horizontal Pod Autoscaler - -现在，php-apache服务器已经运行，我们将通过 [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) 命令创建 Horizontal Pod Autoscaler。 -以下命令将创建一个 Horizontal Pod Autoscaler 用于控制我们上一步骤中创建的 deployment，使 Pod 的副本数量在维持在1到10之间。 -大致来说，HPA 将通过增加或者减少 Pod 副本的数量（通过 Deployment ）以保持所有 Pod 的平均CPU利用率在50%以内 -（由于每个 Pod 通过 [kubectl run](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_run.md) -申请了200 milli-cores CPU，所以50%的 CPU 利用率意味着平均 CPU 利用率为100 milli-cores）。 -相关算法的详情请参阅[here](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#autoscaling-algorithm)。 +## 创建 Horizontal Pod Autoscaler + +现在，php-apache 服务器已经运行，我们将通过 +[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) +命令创建 Horizontal Pod Autoscaler。 +以下命令将创建一个 Horizontal Pod Autoscaler 用于控制我们上一步骤中创建的 +Deployment，使 Pod 的副本数量维持在 1 到 10 之间。 +大致来说，HPA 将通过增加或者减少 Pod 副本的数量（通过 Deployment）以保持所有 Pod 的平均 CPU 利用率在 50% 以内（由于每个 Pod 通过 `kubectl run` 请求 200 毫核的 CPU） +，这意味着平均 CPU 利用率为 100 毫核）。 +相关算法的详情请参阅[文档](/zh/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)。 ```shell kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10 ``` + ``` horizontalpodautoscaler.autoscaling/php-apache autoscaled ``` @@ -136,11 +144,12 @@ horizontalpodautoscaler.autoscaling/php-apache autoscaled -我们可以通过以下命令查看 autoscaler 的状态： +我们可以通过以下命令查看 Autoscaler 的状态： ```shell kubectl get hpa ``` + ``` NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s @@ -151,19 +160,18 @@ php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 Please note that the current CPU consumption is 0% as we are not sending any requests to the server (the ``CURRENT`` column shows the average across all the pods controlled by the corresponding deployment). --> -请注意在上面的命令输出中，当前的CPU利用率是0%，这是由于我们尚未发送任何请求到服务器 -（``CURRENT`` 列显示了相应 deployment 所控制的所有 Pod 的平均 CPU 利用率）。 +请注意当前的 CPU 利用率是 0%，这是由于我们尚未发送任何请求到服务器 +（``CURRENT`` 列显示了相应 Deployment 所控制的所有 Pod 的平均 CPU 利用率）。 -## 增加负载 - -现在，我们将看到 autoscaler 如何对增加负载作出反应。 +## 增加负载 + +现在，我们将看到 Autoscaler 如何对增加负载作出反应。 我们将启动一个容器，并通过一个循环向 php-apache 服务器发送无限的查询请求（请在另一个终端中运行以下命令）： ```shell @@ -177,7 +185,7 @@ while true; do wget -q -O- http://php-apache; done -在几分钟时间内，通过以下命令，我们可以看到CPU负载升高了： +一分钟时间左右之后，通过以下命令，我们可以看到 CPU 负载升高了： ```shell kubectl get hpa @@ -192,7 +200,8 @@ php-apache Deployment/php-apache/scale 305% / 50% 305% 1 10 Here, CPU consumption has increased to 305% of the request. As a result, the deployment was resized to 7 replicas: --> -这时，由于请求增多，CPU利用率已经升至305%。 可以看到，deployment 的副本数量已经增长到了7： +这时，由于请求增多，CPU 利用率已经升至 305%。 +可以看到，Deployment 的副本数量已经增长到了 7： ```shell kubectl get deployment php-apache @@ -203,22 +212,17 @@ php-apache 7 7 7 7 19m ``` {{< note >}} -有时最终副本的数量可能需要几分钟才能稳定下来。 由于环境的差异，不同环境中最终的副本数量可能与本示例中的数量不同。 +有时最终副本的数量可能需要几分钟才能稳定下来。由于环境的差异，不同环境中最终的副本数量可能与本示例中的数量不同。 {{< /note >}} -## 停止负载 - +## 停止负载 + 我们将通过停止负载来结束我们的示例。 -在我们创建 busybox 容器的终端中，输入` + C`来终止负载的产生。 +在我们创建 busybox 容器的终端中，输入` + C` 来终止负载的产生。 然后我们可以再次查看负载状态（等待几分钟时间）： @@ -251,36 +257,31 @@ php-apache 1 1 1 1 27m -这时，CPU利用率已经降到0，所以 HPA 将自动缩减副本数量至1。 +这时，CPU 利用率已经降到 0，所以 HPA 将自动缩减副本数量至 1。 {{< note >}} -自动伸缩完成副本数量的改变可能需要几分钟的时间。 +自动扩缩完成副本数量的改变可能需要几分钟的时间。 {{< /note >}} - - -## 基于多项度量指标和自定义度量指标自动伸缩 - -利用`autoscaling/v2beta2`API版本，您可以在自动伸缩 php-apache 这个 Deployment 时引入其他度量指标。 +## 基于多项度量指标和自定义度量指标自动扩缩 + +利用 `autoscaling/v2beta2` API 版本，你可以在自动扩缩 php-apache 这个 Deployment 时使用其他度量指标。 -首先，获取`autoscaling/v2beta2`格式的 HorizontalPodAutoscaler 的YAML文件： +首先，将 HorizontalPodAutoscaler 的 YAML 文件改为 `autoscaling/v2beta2` 格式： ```shell kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml @@ -289,7 +290,7 @@ kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml -在编辑器中打开`/tmp/hpa-v2.yaml`： +在编辑器中打开 `/tmp/hpa-v2.yaml`： ```yaml apiVersion: autoscaling/v2beta2 @@ -332,25 +333,25 @@ the only other supported resource metric is memory. These resources do not chan to cluster, and should always be available, as long as the `metrics.k8s.io` API is available. --> 需要注意的是，`targetCPUUtilizationPercentage` 字段已经被名为 `metrics` 的数组所取代。 -CPU利用率这个度量指标是一个*resource metric*(资源度量指标)，因为它表示容器上指定资源的百分比。 -除CPU外，您还可以指定其他资源度量指标。默认情况下，目前唯一支持的其他资源度量指标为内存。 -只要`metrics.k8s.io` API存在，这些资源度量指标就是可用的，并且他们不会在不同的Kubernetes集群中改变名称。 +CPU 利用率这个度量指标是一个 *resource metric*（资源度量指标），因为它表示容器上指定资源的百分比。 +除 CPU 外，你还可以指定其他资源度量指标。默认情况下，目前唯一支持的其他资源度量指标为内存。 +只要 `metrics.k8s.io` API 存在，这些资源度量指标就是可用的，并且他们不会在不同的 Kubernetes 集群中改变名称。 -您还可以指定资源度量指标使用绝对数值，而不是百分比，你需要将`target`类型`AverageUtilization`替换成`AverageValue`，同时 -将`target.averageUtilization`替换成`target.averageValue`并设定相应的值。 +你还可以指定资源度量指标使用绝对数值，而不是百分比，你需要将 `target` 类型 `AverageUtilization` 替换成 `AverageValue`，同时 +将 `target.averageUtilization` 替换成 `target.averageValue` 并设定相应的值。 -还有两种其他类型的度量指标，他们被认为是*custom metrics*（自定义度量指标）： -即 Pod 度量指标和对象度量指标（pod metrics and object metrics）。 +还有两种其他类型的度量指标，他们被认为是 *custom metrics*（自定义度量指标）： +即 pod 度量指标和 object 度量指标。 这些度量指标可能具有特定于集群的名称，并且需要更高级的集群监控设置。 -第一种可选的度量指标类型是 Pod 度量指标。这些指标从某一方面描述了Pod，在不同Pod之间进行平均，并通过与一个目标值比对来确定副本的数量。 -它们的工作方式与资源度量指标非常相像，差别是它们仅支持`target` 类型为`AverageValue`。 +第一种可选的度量指标类型是 pod 度量指标。这些指标从某一方面描述了Pod，在不同 Pod 之间进行平均，并通过与一个目标值比对来确定副本的数量。 +它们的工作方式与资源度量指标非常相像，差别是它们仅支持 `target` 类型为 `AverageValue`。 -Pod 度量指标通过如下代码块定义： +pod 度量指标通过如下代码块定义： ```yaml type: Pods @@ -385,11 +386,11 @@ metric from the API. With `AverageValue`, the value returned from the custom met by the number of pods before being compared to the target. The following example is the YAML representation of the `requests-per-second` metric. --> -第二种可选的度量指标类型是对象度量指标。相对于描述 Pod，这些度量指标用于描述一个在相同名字空间(namespace)中的其他对象。 -请注意这些度量指标用于描述这些对象，并非从对象中获取。 -对象度量指标支持的`target`类型包括`Value`和`AverageValue`。如果是`Value`类型，target值将直接与API返回的度量指标比较， -而`AverageValue`类型，API返回的度量指标将按照 Pod 数量拆分，然后再与target值比较。 -下面的 YAML 文件展示了一个表示`requests-per-second`的度量指标。 +第二种可选的度量指标类型是对象（object）度量指标。相对于描述 Pod，这些度量指标用于描述一个在相同名字空间中的其他对象。 +请注意这些度量指标用于描述这些对象，并非从对象中获取指标。 +对象度量指标支持的 `target` 类型包括 `Value` 和 `AverageValue`。如果是 `Value` 类型，`target` 值将直接与 API 返回的度量指标比较， +而对于 `AverageValue` 类型，API 返回的度量值将按照 Pod 数量拆分，然后再与 `target` 值比较。 +下面的 YAML 文件展示了一个表示 `requests-per-second` 的度量指标。 ```yaml type: Object @@ -410,14 +411,15 @@ If you provide multiple such metric blocks, the HorizontalPodAutoscaler will con The HorizontalPodAutoscaler will calculate proposed replica counts for each metric, and then choose the one with the highest replica count. --> -如果您指定了多个上述类型的度量指标，HorizontalPodAutoscaler 将会依次考量各个指标。 +如果你指定了多个上述类型的度量指标，HorizontalPodAutoscaler 将会依次考量各个指标。 HorizontalPodAutoscaler 将会计算每一个指标所提议的副本数量，然后最终选择一个最高值。 -比如，如果您的监控系统能够提供网络流量数据，您可以通过`kubectl edit`命令将上述 Horizontal Pod Autoscaler 的定义更改为： +比如，如果你的监控系统能够提供网络流量数据，你可以通过 `kubectl edit` 命令 +将上述 Horizontal Pod Autoscaler 的定义更改为： ```yaml apiVersion: autoscaling/v2beta1 @@ -483,24 +485,26 @@ Then, your HorizontalPodAutoscaler would attempt to ensure that each pod was con 50% of its requested CPU, serving 1000 packets per second, and that all pods behind the main-route Ingress were serving a total of 10000 requests per second. --> -然后，您的 HorizontalPodAutoscaler 将会尝试确保每个Pod的CPU利用率在50%以内，每秒能够服务1000个数据包请求， -并确保所有在Ingress后的Pod每秒能够服务的请求总数达到10000个。 +这样，你的 HorizontalPodAutoscaler 将会尝试确保每个 Pod 的 CPU 利用率在 50% 以内， +每秒能够服务 1000 个数据包请求， +并确保所有在 Ingress 后的 Pod 每秒能够服务的请求总数达到 10000 个。 -### 多个度量指标下伸缩 - -许多度量管道允许您通过名称或附加的_labels_来描述度量指标。对于所有非资源类型度量指标(pod、object和后面将介绍的external)， -，可以额外指定一个标签选择器。例如，如果你希望收集包含`verb`标签的`http_requests`度量指标， -你可以在 GET 请求中指定需要的度量指标，如下所示： +### 基于更确定的度量值来扩缩 + +许多度量流水线允许你通过名称或附加的_标签_来描述度量指标。 +对于所有非资源类型度量指标（pod、object 和后面将介绍的 external）， +可以额外指定一个标签选择算符。例如，如果你希望收集包含 `verb` 标签的 +`http_requests` 度量指标，可以按如下所示设置度量指标块，使得扩缩操作仅针对 +GET 请求执行： ```yaml type: Object @@ -517,23 +521,24 @@ match multiple series. The selector is additive, and cannot select metrics that describe objects that are **not** the target object (the target pods in the case of the `Pods` type, and the described object in the case of the `Object` type). --> -这个选择器使用与 Kubernetes 标签选择器相同的语法。 -如果名称和标签选择器匹配到多个系列，监测管道会决定如何将多个系列合并成单个值。 -选择器是附加的，它不会选择目标以外的对象（类型为`Pods`的目标和类型为`Object`的目标）。 +这个选择算符使用与 Kubernetes 标签选择算符相同的语法。 +如果名称和标签选择算符匹配到多个系列，监测管道会决定如何将多个系列合并成单个值。 +选择算符是可以累加的，它不会选择目标以外的对象（类型为 `Pods` 的目标 Pods 或者 +类型为 `Object` 的目标对象）。 -### 基于Kubernetes以外的度量指标伸缩 - -运行在 Kubernetes 上的应用程序可能需要基于与 Kubernetes 集群中的任何对象没有明显关系的度量指标进行自动伸缩， -例如那些描述不在 Kubernetes 任何 namespaces 服务的度量指标。 +### 基于与 Kubernetes 对象无关的度量指标执行扩缩 + +运行在 Kubernetes 上的应用程序可能需要基于与 Kubernetes 集群中的任何对象没有明显关系的度量指标进行自动扩缩， +例如那些描述与任何 Kubernetes 名字空间中的服务都无直接关联的度量指标。 +在 Kubernetes 1.10 及之后版本中，你可以使用外部度量指标（external metrics）。 -使用外部的度量指标，需要了解你使用的监控系统，相关的设置与使用自定义试题指标类似。 -External metrics 可以使用你的监控系统的任何指标来自动伸缩你的集群。你只需要在`metric`块中提供`name` 和 `selector`，同时将类型由`Object`改为`External`。 -如果`metricSelector`匹配到多个度量指标，HorizontalPodAutoscaler 将会把它们加和。 -External metrics 同时支持`Value`和`AverageValue`类型，这与`Object`类型的度量指标相同。 +使用外部度量指标时，需要了解你所使用的监控系统，相关的设置与使用自定义指标时类似。 +外部度量指标使得你可以使用你的监控系统的任何指标来自动扩缩你的集群。 +你只需要在 `metric` 块中提供 `name` 和 `selector`，同时将类型由 `Object` 改为 `External`。 +如果 `metricSelector` 匹配到多个度量指标，HorizontalPodAutoscaler 将会把它们加和。 +外部度量指标同时支持 `Value` 和 `AverageValue` 类型，这与 `Object` 类型的度量指标相同。 -例如，如果你的应用程序处理主机上的消息队列， -为了让每30个任务有1个worker，你可以将下面的内容添加到 HorizontalPodAutoscaler 的配置中。 +例如，如果你的应用程序处理来自主机上消息队列的任务， +为了让每 30 个任务有 1 个工作者实例，你可以将下面的内容添加到 +HorizontalPodAutoscaler 的配置中。 ```yaml - type: External @@ -573,34 +580,37 @@ When possible, it's preferable to use the custom metric target types instead of easier for cluster administrators to secure the custom metrics API. The external metrics API potentially allows access to any metric, so cluster administrators should take care when exposing it. --> -如果可能，还是推荐 custom metric 而不是 external metrics，因为这便于让系统管理员加固 custom metrics API。 -而 external metrics API 可以允许访问所有的度量指标，当暴露这些服务时，系统管理员需要仔细考虑这个问题。 +如果可能，还是推荐定制度量指标而不是外部度量指标，因为这便于让系统管理员加固定制度量指标 API。 +而外部度量指标 API 可以允许访问所有的度量指标。 +当暴露这些服务时，系统管理员需要仔细考虑这个问题。 -## 附录：Horizontal Pod Autoscaler状态条件 - -当使用`autoscaling/v2beta2`格式的 HorizontalPodAutoscaler 时，您将可以看到 Kubernetes 为 HorizongtalPodAutoscaler 设置的状态条件（status conditions）。 -这些状态条件可以显示当前 HorizontalPodAutoscaler 是否能够执行伸缩以及是否受到一定的限制。 +## 附录：Horizontal Pod Autoscaler 状态条件 + +使用 `autoscaling/v2beta2` 格式的 HorizontalPodAutoscaler 时，你将可以看到 +Kubernetes 为 HorizongtalPodAutoscaler 设置的状态条件（Status Conditions）。 +这些状态条件可以显示当前 HorizontalPodAutoscaler 是否能够执行扩缩以及是否受到一定的限制。 `status.conditions`字段展示了这些状态条件。 -可以通过`kubectl describe hpa`命令查看当前影响 HorizontalPodAutoscaler 的各种状态条件信息： +可以通过 `kubectl describe hpa` 命令查看当前影响 HorizontalPodAutoscaler +的各种状态条件信息： ```shell kubectl describe hpa cm-test ``` -```shell + +``` Name: cm-test Namespace: prom Labels: @@ -633,18 +643,15 @@ you may wish to raise or lower the minimum or maximum replica count constraints HorizontalPodAutoscaler. --> 对于上面展示的这个 HorizontalPodAutoscaler，我们可以看出有若干状态条件处于健康状态。 -首先，`AbleToScale` 表明 HPA 是否可以获取和更新伸缩信息，以及是否存在阻止伸缩的各种回退条件。 -其次，`ScalingActive` 表明HPA是否被启用（即目标的副本数量不为零） 以及是否能够完成伸缩计算。 +首先，`AbleToScale` 表明 HPA 是否可以获取和更新扩缩信息，以及是否存在阻止扩缩的各种回退条件。 +其次，`ScalingActive` 表明 HPA 是否被启用（即目标的副本数量不为零） 以及是否能够完成扩缩计算。 当这一状态为 `False` 时，通常表明获取度量指标存在问题。 -最后一个条件 `ScalingLimitted` 表明所需伸缩的值被 HorizontalPodAutoscaler 所定义的最大或者最小值所限制（即已经达到最大或者最小伸缩值）。 -这通常表明您可能需要调整 HorizontalPodAutoscaler 所定义的最大或者最小副本数量的限制了。 +最后一个条件 `ScalingLimitted` 表明所需扩缩的值被 HorizontalPodAutoscaler 所定义的最大或者最小值所限制（即已经达到最大或者最小扩缩值）。 +这通常表明你可能需要调整 HorizontalPodAutoscaler 所定义的最大或者最小副本数量的限制了。 -## 附录：Quantities - -HorizontalPodAutoscaler 和 metrics api 中的所有的度量指标使用 Kubernetes 中称为 *quantity* （）殊整数表示。 -例如，数量`10500m`用十进制表示为`10.5`。 -如果可能的话，metrics api 将返回没有后缀的整数，否则返回以千分单位的数量。 -这意味着您可能会看到您的度量指标在`1`和`1500m`之间波动，或者在十进制记数法中的`1`和`1.5`。 -更多信息，请参阅[度量术语](/docs/reference/glossary?core-object=true#term-quantity) +## 附录：量纲 + +HorizontalPodAutoscaler 和 度量指标 API 中的所有的度量指标使用 Kubernetes 中称为 *quantity* （量纲）的特殊整数表示。 +例如，数量 `10500m` 用十进制表示为 `10.5`。 +如果可能的话，度量指标 API 将返回没有后缀的整数，否则返回以千分单位的数量。 +这意味着你可能会看到你的度量指标在 `1` 和 `1500m` （也就是在十进制记数法中的 `1` 和 `1.5`）之间波动。 +更多信息，请参阅[度量术语](/docs/reference/glossary?core-object=true#term-quantity)。 ## 附录：其他可能的情况 - -### 使用YAML文件创建 autoscaler +### 使用 YAML 文件以声明式方式创建 Autoscaler -除了使用 `kubectl autoscale` 命令，也可以文件创建 HorizontalPodAutoscaler ： +除了使用 `kubectl autoscale` 命令，也可以文件创建 HorizontalPodAutoscaler： {{< codenew file="application/hpa/php-apache.yaml" >}} @@ -682,11 +690,10 @@ We will create the autoscaler by executing the following command: --> 使用如下命令创建 autoscaler： - - ```shell kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml ``` + ``` horizontalpodautoscaler.autoscaling/php-apache created ``` diff --git a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md index 10966fdf4d..717640bb86 100644 --- a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -1,13 +1,9 @@ --- -reviewers: -- fgrzadkowski -- jszczepkowski -- directxman12 -title: Pod 水平自动伸缩 +title: Pod 水平自动扩缩 feature: - title: 水平伸缩 + title: 水平扩缩 description: > - 使用一个简单的命令、一个UI或基于CPU使用情况自动对应用程序进行伸缩。 + 使用一个简单的命令、一个UI或基于CPU使用情况自动对应用程序进行扩缩。 content_type: concept weight: 90 @@ -22,10 +18,11 @@ in a replication controller, deployment or replica set based on observed CPU uti support, on some other application-provided metrics). Note that Horizontal Pod Autoscaling does not apply to objects that can't be scaled, for example, DaemonSets. --> -Pod 水平自动伸缩（Horizontal Pod Autoscaler）特性， -可以基于CPU利用率自动伸缩 replication controller、deployment和 replica set 中的 pod 数量，（除了 CPU 利用率）也可以 -基于其他应程序提供的度量指标[custom metrics](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md)。 -pod 自动缩放不适用于无法缩放的对象，比如 DaemonSets。 +Pod 水平自动扩缩（Horizontal Pod Autoscaler） +可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment 和 ReplicaSet 中的 Pod 数量。 +除了 CPU 利用率，也可以基于其他应程序提供的[自定义度量指标](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md) +来执行自动扩缩。 +Pod 自动扩缩不适用于无法扩缩的对象，比如 DaemonSet。 -Pod 水平自动伸缩特性由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为。 -控制器会周期性的获取平均 CPU 利用率，并与目标值相比较后来调整 replication controller 或 deployment 中的副本数量。 - - - +Pod 水平自动扩缩特性由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为。 +控制器会周期性的调整副本控制器或 Deployment 中的副本数量，以使得 Pod 的平均 CPU +利用率与用户所设定的目标值匹配。 -## Pod 水平自动伸缩工作机制 +## Pod 水平自动扩缩工作机制 -![水平自动伸缩示意图](/images/docs/horizontal-pod-autoscaler.svg) +![水平自动扩缩示意图](/images/docs/horizontal-pod-autoscaler.svg) -Pod 水平自动伸缩的实现是一个控制循环，由 controller manager 的 `--horizontal-pod-autoscaler-sync-period` 参数 -指定周期（默认值为15秒）。 +Pod 水平自动扩缩器的实现是一个控制回路，由控制器管理器的 `--horizontal-pod-autoscaler-sync-period` 参数指定周期（默认值为 15 秒）。 -每个周期内，controller manager 根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。 -controller manager 可以从 resource metrics API（每个pod 资源指标）和 custom metrics API（其他指标）获取指标。 +每个周期内，控制器管理器根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。 +控制器管理器可以从资源度量指标 API（按 Pod 统计的资源用量）和自定义度量指标 API（其他指标）获取度量值。 -* 对于每个 pod 的资源指标（如 CPU），控制器从资源指标 API 中获取每一个 HorizontalPodAutoscaler 指定 -的 pod 的指标，然后，如果设置了目标使用率，控制器获取每个 pod 中的容器资源使用情况，并计算资源使用率。 -如果使用原始值，将直接使用原始数据（不再计算百分比）。 -然后，控制器根据平均的资源使用率或原始值计算出缩放的比例，进而计算出目标副本数。 +* 对于按 Pod 统计的资源指标（如 CPU），控制器从资源指标 API 中获取每一个 + HorizontalPodAutoscaler 指定的 Pod 的度量值，如果设置了目标使用率， + 控制器获取每个 Pod 中的容器资源使用情况，并计算资源使用率。 + 如果设置了 target 值，将直接使用原始数据（不再计算百分比）。 + 接下来，控制器根据平均的资源使用率或原始值计算出扩缩的比例，进而计算出目标副本数。 - -需要注意的是，如果 pod 某些容器不支持资源采集，那么控制器将不会使用该 pod 的 CPU 使用率。 -下面的[算法细节](#algorithm-details)章节将会介绍详细的算法。 + --> + 需要注意的是，如果 Pod 某些容器不支持资源采集，那么控制器将不会使用该 Pod 的 CPU 使用率。 + 下面的[算法细节](#algorithm-details)章节将会介绍详细的算法。 -* 如果 pod 使用自定义指示，控制器机制与资源指标类似，区别在于自定义指标只使用原始值，而不是使用率。 +* 如果 Pod 使用自定义指示，控制器机制与资源指标类似，区别在于自定义指标只使用 + 原始值，而不是使用率。 * 如果pod 使用对象指标和外部指标（每个指标描述一个对象信息）。 - 这个指标将直接跟据目标设定值相比较，并生成一个上面提到的缩放比例。在 `autoscaling/v2beta2` 版本API中， - 这个指标也可以根据 pod 数量平分后再计算。 + 这个指标将直接跟据目标设定值相比较，并生成一个上面提到的扩缩比例。 + 在 `autoscaling/v2beta2` 版本API中，这个指标也可以根据 Pod 数量平分后再计算。 -通常情况下，控制器将从一系列的聚合 API（`metrics.k8s.io`、`custom.metrics.k8s.io`和`external.metrics.k8s.io`） -中获取指标数据。 -`metrics.k8s.io` API 通常由 metrics-server（需要额外启动）提供。 -可以从[metrics-server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server) 获取更多信息。 +通常情况下，控制器将从一系列的聚合 API（`metrics.k8s.io`、`custom.metrics.k8s.io` +和 `external.metrics.k8s.io`）中获取度量值。 +`metrics.k8s.io` API 通常由 Metrics 服务器（需要额外启动）提供。 +可以从 [metrics-server](/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server) 获取更多信息。 另外，控制器也可以直接从 Heapster 获取指标。 {{< note >}} @@ -125,13 +121,13 @@ for instructions. The HorizontalPodAutoscaler can also fetch metrics directly fr -自 Kubernetes 1.11起，从 Heapster 获取指标特性已废弃。 +自 Kubernetes 1.11 起，从 Heapster 获取指标特性已废弃。 {{< /note >}} -关于指标 API 更多信息，请参考[Support for metrics APIs](#support-for-metrics-apis)。 +关于指标 API 更多信息，请参考[度量值指标 API 的支持](#support-for-metrics-apis)。 -自动缩放控制器使用 scale sub-resource 访问相应可支持缩放的控制器（如replication controllers、deployments 和 replica sets）。 +自动扩缩控制器使用 scale 子资源访问相应可支持扩缩的控制器（如副本控制器、 +Deployments 和 ReplicaSet）。 `scale` 是一个可以动态设定副本数量和检查当前状态的接口。 -更多关于 scale sub-resource 的信息，请参考[这里](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource). +关于 scale 子资源的更多信息，请参考[这里](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource). -### 算法细节 - -从最基本的角度来看，pod 水平自动缩放控制器跟据当前指标和期望指标来计算缩放比例。 +### 算法细节 {#algorithm-details} + +从最基本的角度来看，Pod 水平自动扩缩控制器跟据当前指标和期望指标来计算扩缩比例。 ``` -期望副本数 = ceil[当前副本数 * ( 当前指标 / 期望指标 )] +期望副本数 = ceil[当前副本数 * (当前指标 / 期望指标)] ``` -例如，当前指标为`200m`，目标设定值为`100m`,那么由于`200.0 / 100.0 == 2.0`， +例如，当前度量值为 `200m`，目标设定值为 `100m`，那么由于 `200.0/100.0 == 2.0`， 副本数量将会翻倍。 -如果当前指标为`50m`，副本数量将会减半，因为`50.0 / 100.0 == 0.5`。 -如果计算出的缩放比例接近1.0（跟据`--horizontal-pod-autoscaler-tolerance` 参数全局配置的容忍值，默认为0.1）， -将会放弃本次缩放。 +如果当前指标为 `50m`，副本数量将会减半，因为`50.0/100.0 == 0.5`。 +如果计算出的扩缩比例接近 1.0 +（跟据`--horizontal-pod-autoscaler-tolerance` 参数全局配置的容忍值，默认为 0.1）， +将会放弃本次扩缩。 如果 HorizontalPodAutoscaler 指定的是`targetAverageValue` 或 `targetAverageUtilization`， -那么将会把指定pod的平均指标做为`currentMetricValue`。 -然而，在检查容忍度和决定最终缩放值前，我们仍然会把那些无法获取指标的pod统计进去。 +那么将会把指定 Pod 度量值的平均值做为 `currentMetricValue`。 +然而，在检查容忍度和决定最终扩缩值前，我们仍然会把那些无法获取指标的 Pod 统计进去。 -所有被标记了删除时间戳(Pod正在关闭过程中)的 pod 和 失败的 pod 都会被忽略。 - -如果某个 pod 缺失指标信息，它将会被搁置，只在最终确定缩值时再考虑。 +所有被标记了删除时间戳（Pod 正在关闭过程中）的 Pod 和 失败的 Pod 都会被忽略。 + +如果某个 Pod 缺失度量值，它将会被搁置，只在最终确定扩缩数量时再考虑。 -当使用 CPU 指标来缩放时，任何还未就绪（例如还在初始化）状态的 pod *或* 最近的指标为就绪状态前的 pod， -也会被搁置 +当使用 CPU 指标来扩缩时，任何还未就绪（例如还在初始化）状态的 Pod *或* 最近的指标 +度量值采集于就绪状态前的 Pod，该 Pod 也会被搁置。 -由于受技术限制，pod 水平缩放控制器无法准确的知道 pod 什么时候就绪， -也就无法决定是否暂时搁置该 pod。 -`--horizontal-pod-autoscaler-initial-readiness-delay` 参数（默认为30s），用于设置 pod 准备时间， -在此时间内的 pod 统统被认为未就绪。 -`--horizontal-pod-autoscaler-cpu-initialization-period`参数（默认为5分钟），用于设置 pod 的初始化时间， -在此时间内的 pod，CPU 资源指标将不会被采纳。 +由于受技术限制，Pod 水平扩缩控制器无法准确的知道 Pod 什么时候就绪， +也就无法决定是否暂时搁置该 Pod。 +`--horizontal-pod-autoscaler-initial-readiness-delay` 参数（默认为 30s）用于设置 Pod 准备时间， +在此时间内的 Pod 统统被认为未就绪。 +`--horizontal-pod-autoscaler-cpu-initialization-period` 参数（默认为5分钟） +用于设置 Pod 的初始化时间， +在此时间内的 Pod，CPU 资源度量值将不会被采纳。 -在排除掉被搁置的 pod 后，缩放比例就会跟据`currentMetricValue / desiredMetricValue`计算出来。 +在排除掉被搁置的 Pod 后，扩缩比例就会跟据`currentMetricValue/desiredMetricValue` +计算出来。 -如果有任何 pod 的指标缺失，我们会更保守地重新计算平均值， -在需要缩小时假设这些 pod 消耗了目标值的 100%， -在需要放大时假设这些 pod 消耗了0%目标值。 -这可以在一定程度上抑制伸缩的幅度。 +如果缺失任何的度量值，我们会更保守地重新计算平均值， +在需要缩小时假设这些 Pod 消耗了目标值的 100%， +在需要放大时假设这些 Pod 消耗了 0% 目标值。 +这可以在一定程度上抑制扩缩的幅度。 -此外，如果存在任何尚未就绪的pod，我们可以在不考虑遗漏指标或尚未就绪的pods的情况下进行伸缩， -我们保守地假设尚未就绪的pods消耗了试题指标的0%，从而进一步降低了伸缩的幅度。 +此外，如果存在任何尚未就绪的 Pod，我们可以在不考虑遗漏指标或尚未就绪的 Pod 的情况下进行扩缩， +我们保守地假设尚未就绪的 Pod 消耗了试题指标的 0%，从而进一步降低了扩缩的幅度。 -在缩放方向（缩小或放大）确定后，我们会把未就绪的 pod 和缺少指标的 pod 考虑进来再次计算使用率。 -如果新的比率与缩放方向相反，或者在容忍范围内，则跳过缩放。 -否则，我们使用新的缩放比例。 +在扩缩方向（缩小或放大）确定后，我们会把未就绪的 Pod 和缺少指标的 Pod 考虑进来再次计算使用率。 +如果新的比率与扩缩方向相反，或者在容忍范围内，则跳过扩缩。 +否则，我们使用新的扩缩比例。 注意，平均利用率的*原始*值会通过 HorizontalPodAutoscaler 的状态体现（ -即使使用了新的使用率，也不考虑未就绪 pod 和 缺少指标的 pod)。 +即使使用了新的使用率，也不考虑未就绪 Pod 和 缺少指标的 Pod)。 如果创建 HorizontalPodAutoscaler 时指定了多个指标， -那么会按照每个指标分别计算缩放副本数，取最大的进行缩放。 -如果任何一个指标无法顺利的计算出缩放副本数（比如，通过 API 获取指标时出错）， -那么本次缩放会被跳过。 +那么会按照每个指标分别计算扩缩副本数，取最大的进行扩缩。 +如果任何一个指标无法顺利的计算出扩缩副本数（比如，通过 API 获取指标时出错）， +那么本次扩缩会被跳过。 -最后，在 HPA 控制器执行缩放操作之前，会记录缩放建议信息（scale recommendation）。 +最后，在 HPA 控制器执行扩缩操作之前，会记录扩缩建议信息。 控制器会在操作时间窗口中考虑所有的建议信息，并从中选择得分最高的建议。 -这个值可通过 kube-controller-manager 服务的启动参数 `--horizontal-pod-autoscaler-downscale-stabilization` 进行配置， -默认值为 5min。 +这个值可通过 `kube-controller-manager` 服务的启动参数 `--horizontal-pod-autoscaler-downscale-stabilization` 进行配置， +默认值为 5 分钟。 这个配置可以让系统更为平滑地进行缩容操作，从而消除短时间内指标值快速波动产生的影响。 -## API 对象 - +## API 对象 {#api-object} + HorizontalPodAutoscaler 是 Kubernetes `autoscaling` API 组的资源。 -在当前稳定版本（`autoscaling/v1`）中只支持基于CPU指标的缩放。 +在当前稳定版本（`autoscaling/v1`）中只支持基于 CPU 指标的扩缩。 -在 beta 版本（`autoscaling/v2beta2`），引入了基于内存和自定义指标的缩放。 -在`autoscaling/v2beta2`版本中新引入的字段在`autoscaling/v1`版本中基于 annotation 实现。 +API 的 beta 版本（`autoscaling/v2beta2`）引入了基于内存和自定义指标的扩缩。 +在 `autoscaling/v2beta2` 版本中新引入的字段在 `autoscaling/v1` 版本中以注解 +的形式得以保留。 -更多有关 API 对象的信息，请查阅[HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)。 +创建 HorizontalPodAutoscaler 对象时，需要确保所给的名称是一个合法的 +[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +有关 API 对象的更多信息，请查阅[HorizontalPodAutoscaler 对象设计文档](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)。 -## 使用 kubectl 操作 Horizontal Pod Autoscaler - -与其他 API 资源类似，`kubectl` 也标准支持 Pod 自动伸缩。 -我们可以通过 `kubectl create` 命令创建一个自动伸缩对象， -通过 `kubectl get hpa` 命令来获取所有自动伸缩对象， -通过 `kubectl describe hpa` 命令来查看自动伸缩对象的详细信息。 +## kubectl 对 Horizontal Pod Autoscaler 的支持 + +与其他 API 资源类似，`kubectl` 以标准方式支持 HPA。 +我们可以通过 `kubectl create` 命令创建一个 HPA 对象， +通过 `kubectl get hpa` 命令来获取所有 HPA 对象， +通过 `kubectl describe hpa` 命令来查看 HPA 对象的详细信息。 最后，可以使用 `kubectl delete hpa` 命令删除对象。 -此外，还有个简便的命令 `kubectl autoscale` 来创建自动伸缩对象。 +此外，还有个简便的命令 `kubectl autoscale` 来创建 HPA 对象。 例如，命令 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80` 将会为名 -为 *foo* 的 replication set 创建一个自动伸缩对象， -对象目标CPU使用率为 `80%`，副本数量配置为 2 到 5 之间。 +为 *foo* 的 ReplicationSet 创建一个 HPA 对象， +目标 CPU 使用率为 `80%`，副本数量配置为 2 到 5 之间。 -## 滚动升级时缩放 - - -目前在 Kubernetes 中，可以针对 replication controllers 或 deployment 执行 -滚动升级[rolling update](/docs/tasks/run-application/rolling-update-replication-controller/)，他们会为你管理底层副本数。 -Pod 水平缩放只支持后一种：Horizontal Pod Autoscaler 会被绑定到 deployment 对象中，Horizontal Pod Autoscaler 设置副本数量时， -deployment 会设置底层副本数。 +## 滚动升级时扩缩 {#autoscaling-during-roling-update} + +目前在 Kubernetes 中，可以针对 ReplicationController 或 Deployment 执行 +滚动更新，它们会为你管理底层副本数。 +Pod 水平扩缩只支持后一种：HPA 会被绑定到 Deployment 对象， +HPA 设置副本数量时，Deployment 会设置底层副本数。 -当使用 replication controllers 执行滚动升级时， Horizontal Pod Autoscaler 不能工作， -也就是说你不能将 Horizontal Pod Autoscaler 绑定到某个 replication controller -再执行滚动升级（例如使用 `kubectl rolling-update` 命令）。 -Horizontal Pod Autoscaler 不能工作的原因是，Horizontal Pod Autoscaler 无法绑定到滚动升级时创建的新副本。 +通过直接操控副本控制器执行滚动升级时，HPA 不能工作， +也就是说你不能将 HPA 绑定到某个 RC 再执行滚动升级 +（例如使用 `kubectl rolling-update` 命令）。 +HPA 不能工作的原因是它无法绑定到滚动更新时所新创建的副本控制器。 -## 冷却/延迟 - -当使用 Horizontal Pod Autoscaler 管理一组副本缩放时， -有可能因为指标动态的变化造成副本数量频繁的变化，有时这被称为 *抖动*。 +## 冷却/延迟支持 + +当使用 Horizontal Pod Autoscaler 管理一组副本扩缩时， +有可能因为指标动态的变化造成副本数量频繁的变化，有时这被称为 +*抖动（Thrashing）*。 -从 v1.6 版本起，集群操作员可以开启某些 `kube-controller-manager` 全局的参数来缓和这个问题。 +从 v1.6 版本起，集群操作员可以调节某些 `kube-controller-manager` 的全局参数来 +缓解这个问题。 -从 v1.12 开始，算法调整后，就不用这么做了。 +从 v1.12 开始，算法调整后，扩容操作时的延迟就不必设置了。 -- `--horizontal-pod-autoscaler-downscale-stabilization`: 这个 `kube-controller-manager` 的参数表示缩容冷却时间。 - 即自从上次缩容执行结束后，多久可以再次执行缩容，默认时间是5分钟(`5m0s`)。 +- `--horizontal-pod-autoscaler-downscale-stabilization`: + `kube-controller-manager` 的这个参数表示缩容冷却时间。 + 即自从上次缩容执行结束后，多久可以再次执行缩容，默认时间是 5 分钟(`5m0s`)。 -{{< note >}} -当启用这个参数时，集群操作员需要明白其可能的影响。 -如果延迟（冷却）时间设置的太长，那么 Horizontal Pod Autoscaler 可能会不能很好的改变负载。 -如果延迟（冷却）时间设备的太短，那么副本数量有可能跟以前一样抖动。 +{{< note >}} +当调整这些参数时，集群操作员需要明白其可能的影响。 +如果延迟（冷却）时间设置的太长，Horizontal Pod Autoscaler 可能会不能很好的改变负载。 +如果延迟（冷却）时间设置的太短，那么副本数量有可能跟以前一样出现抖动。 {{< /note >}} -## 多指标支持 - -在 Kubernetes 1.6 支持了基于多个指标进行缩放。 +## 多指标支持 {#support-for-multiple-metrics} + +Kubernetes 1.6 开始支持基于多个度量值进行扩缩。 你可以使用 `autoscaling/v2beta2` API 来为 Horizontal Pod Autoscaler 指定多个指标。 -Horizontal Pod Autoscaler 会跟据每个指标计算，并生成一个缩放建议。 -幅度最大的缩放建议会被采纳。 +Horizontal Pod Autoscaler 会跟据每个指标计算，并生成一个扩缩建议。 +幅度最大的扩缩建议会被采纳。 -## 自定义指标支持 -{{< note >}} - -在 Kubernetes 1.2 增加的 alpha 的缩放支持基于特定的 annotation。 -自从 Kubernetes 1.6 起，由于缩放 API 的引入，这些 annotation 就不再支持了。 -虽然收集自定义指标的旧方法仍然可用，但是 Horizontal Pod Autoscaler 调度器将不会再使用这些指标， -同时，Horizontal Pod Autoscaler 也不再使用之前的用于指定用户自定义指标的 annotation 了。 +## 自定义指标支持 {#support-for-custom-metrics} + +{{< note >}} +在 Kubernetes 1.2 增加了支持基于使用特殊注解表达的、特定于具体应用的扩缩能力， +此能力处于 Alpha 阶段。 +从 Kubernetes 1.6 起，由于新的 autoscaling API 的引入，这些 annotation 就被废弃了。 +虽然收集自定义指标的旧方法仍然可用，Horizontal Pod Autoscaler 调度器将不会再使用这些度量值。 +同时，Horizontal Pod Autoscaler 也不再使用之前用于指定用户自定义指标的注解。 {{< /note >}} -关于指标 API 的要求，请查阅 [Support for metrics APIs](#support-for-metrics-apis)。 +关于指标 API 的要求，请参阅[对 Metrics API 的支持](#support-for-metrics-apis)。 -## 指标 API - -默认情况下，HorizontalPodAutoscaler 控制器会从一系列的 API 中请求指标数据。 -集群管理员需要确保下述条件，以保证这些 API 可以访问： +## 对 Metrics API 的支持 {#support-for-metrics-apis} + +默认情况下，HorizontalPodAutoscaler 控制器会从一系列的 API 中检索度量值。 +集群管理员需要确保下述条件，以保证 HPA 控制器能够访问这些 API： -* [API aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 已开启 - - - -* 相应的 API 已注册： - - * 资源指标会使用 `metrics.k8s.io` API，一般由 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 提供。 - 它可以做为集群组件启动。 - * 用户指标会使用 `custom.metrics.k8s.io` API。 - 它由其他厂商的“适配器”API 服务器提供。 - 确认你的指标管道，或者查看 [list of known solutions](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)。 - * 外部指标会使用 `external.metrics.k8s.io` API。可能由上面的用户指标适配器提供。 - - +* 启用了 [API 聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) +* 相应的 API 已注册： + + * 对于资源指标，将使用 `metrics.k8s.io` API，一般由 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 提供。 + 它可以做为集群插件启动。 + * 对于自定义指标，将使用 `custom.metrics.k8s.io` API。 + 它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供。 + 确认你的指标流水线，或者查看[已知方案列表](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)。 + * 对于外部指标，将使用 `external.metrics.k8s.io` API。可能由上面的自定义指标适配器提供。 * `--horizontal-pod-autoscaler-use-rest-clients` 参数设置为 `true` 或者不设置。 - 如果设置为 false，则会切换到基于 Heapster 的自动缩放，这个特性已经被弃用了。 + 如果设置为 false，则会切换到基于 Heapster 的自动扩缩，这个特性已经被弃用了。 -更多关于指标来源以及其区别，请参阅相关的设计文档， +关于指标来源以及其区别的更多信息，请参阅相关的设计文档， [the HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md)、 -[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md)和 +[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md) 和 [external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md)。 -如何使用它们的示例，请参考 -[the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics) -和 [the walkthrough for using external metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)。 - - +关于如何使用它们的示例，请参考 +[使用自定义指标的教程](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics) +和[使用外部指标的教程](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)。 ## {{% heading "whatsnext" %}} - -* 设计文档：[Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md). -* kubectl 自动缩放命令： [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). -* 使用示例：[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). - +* 设计文档：[Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md) +* `kubectl autoscale` 命令： [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). +* 使用示例：[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).