whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[zh] Tidy up and fix links in tasks section (3/10)

Browse Source
This commit is contained in:
Qiming Teng
2020-08-11 16:05:33 +08:00
parent fb6364da0a
commit 1d3f4449a4
6 changed files with 627 additions and 532 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+137 -130
View File
@@ -1,13 +1,19 @@
---
title: Horizontal Pod Autoscaler 演练
content_type: task
weight: 100
---
<!--
reviewers:
- fgrzadkowski
- jszczepkowski
- justinsb
- directxman12
title: Horizontal Pod Autoscaler演练
title: Horizontal Pod Autoscaler Walkthrough
content_type: task
weight: 100
---
-->
<!-- overview -->
@@ -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 版本）。
<!--
This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server. For more information on how Horizontal Pod Autoscaler behaves, see the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/).
-->
本文将引导您了解如何为 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" %}}
<!--
This example requires a running Kubernetes cluster and kubectl, version 1.2 or later.
[metrics-server](https://github.com/kubernetes-incubator/metrics-server/) monitoring needs to be deployed in the cluster
to provide metrics via the resource metrics API, as Horizontal Pod Autoscaler uses this API to collect metrics. The instructions for deploying this are on the GitHub repository of [metrics-server](https://github.com/kubernetes-incubator/metrics-server/), if you followed [getting started on GCE guide](/docs/setup/production-environment/turnkey/gce/),
metrics-server monitoring will be turned-on by default.
-->
本文示例需要一个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 会默认启动。
<!--
To specify multiple resource metrics for a Horizontal Pod Autoscaler, you must have a Kubernetes cluster
@@ -51,36 +55,36 @@ not related to any Kubernetes object you must have a Kubernetes cluster at versi
you must be able to communicate with the API server that provides the external metrics API.
See the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) for more details.
-->
如果需要为 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)。
<!-- steps -->
<!--
## Run & expose php-apache server
-->
## 第一步：运行 php-apache 服务器并暴露服务
## 运行 php-apache 服务器并暴露服务
<!--
To demonstrate Horizontal Pod Autoscaler we will use a custom docker image based on the php-apache image.
The Dockerfile has the following content:
-->
为了演示 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
```
<!--
It defines an index.php page which performs some CPU intensive computations:
-->
它定义一个 index.php 页面来执行一些 CPU 密集型计算：
该文件定义了一个 index.php 页面来执行一些 CPU 密集型计算：
```
<?php
@@ -91,14 +95,16 @@ It defines an index.php page which performs some CPU intensive computations:
echo "OK!";
?>
```
<!--
First, we will start a deployment running the image and expose it as a service:
-->
首先，我们先启动一个 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
<!--
## Create Horizontal Pod Autoscaler
-->
## 创建 Horizontal Pod Autoscaler
<!--
Now that the server is running, we will create the autoscaler using
[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale).
The following command will create a Horizontal Pod Autoscaler that maintains between 1 and 10 replicas of the Pods
@@ -117,18 +120,23 @@ controlled by the php-apache deployment we created in the first step of these in
Roughly speaking, HPA will increase and decrease the number of replicas
(via the deployment) to maintain an average CPU utilization across all Pods of 50%
(since each pod requests 200 milli-cores by [kubectl run](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_run.md), this means average CPU usage of 100 milli-cores).
See [here](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#autoscaling-algorithm) for more details on the algorithm.
See [here](/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) for more details on the algorithm.
-->
现在，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
<!--
We may check the current status of autoscaler by running:
-->
我们可以通过以下命令查看 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 利用率）。
<!--
## Increase load
-->
## 增加负载
<!--
Now, we will see how the autoscaler reacts to increased load.
We will start a container, and send an infinite loop of queries to the php-apache service (please run it in a different terminal):
-->
现在，我们将看到 autoscaler 如何对增加负载作出反应。
## 增加负载
现在，我们将看到 Autoscaler 如何对增加负载作出反应。
我们将启动一个容器，并通过一个循环向 php-apache 服务器发送无限的查询请求（请在另一个终端中运行以下命令）：
```shell
@@ -177,7 +185,7 @@ while true; do wget -q -O- http://php-apache; done
<!--
Within a minute or so, we should see the higher CPU load by executing:
-->
在几分钟时间内，通过以下命令，我们可以看到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 >}}
It may take a few minutes to stabilize the number of replicas. Since the amount
of load is not controlled in any way it may happen that the final number of replicas
will differ from this example.
{{< /note >}}
-->
{{< note >}}
有时最终副本的数量可能需要几分钟才能稳定下来。 由于环境的差异，不同环境中最终的副本数量可能与本示例中的数量不同。
有时最终副本的数量可能需要几分钟才能稳定下来。由于环境的差异，不同环境中最终的副本数量可能与本示例中的数量不同。
{{< /note >}}
<!--
## Stop load
-->
## 停止负载
<!--
We will finish our example by stopping the user load.
In the terminal where we created the container with `busybox` image, terminate
@@ -226,9 +230,11 @@ the load generation by typing `<Ctrl> + C`.
Then we will verify the result state (after a minute or so):
-->
## 停止负载
我们将通过停止负载来结束我们的示例。
在我们创建 busybox 容器的终端中，输入`<Ctrl> + C`来终止负载的产生。
在我们创建 busybox 容器的终端中，输入`<Ctrl> + C` 来终止负载的产生。
然后我们可以再次查看负载状态（等待几分钟时间）：
@@ -251,36 +257,31 @@ php-apache 1 1 1 1 27m
<!--
Here CPU utilization dropped to 0, and so HPA autoscaled the number of replicas back down to 1.
-->
这时，CPU利用率已经降到0，所以 HPA 将自动缩减副本数量至1。
这时，CPU 利用率已经降到 0，所以 HPA 将自动缩减副本数量至 1。
<!--
{{< note >}}
Autoscaling the replicas may take a few minutes.
{{< /note >}}
-->
{{< note >}}
自动伸缩完成副本数量的改变可能需要几分钟的时间。
自动扩缩完成副本数量的改变可能需要几分钟的时间。
{{< /note >}}
<!-- discussion -->
<!--
## Autoscaling on multiple metrics and custom metrics
-->
## 基于多项度量指标和自定义度量指标自动伸缩
<!--
You can introduce additional metrics to use when autoscaling the `php-apache` Deployment
by making use of the `autoscaling/v2beta2` API version.
-->
利用`autoscaling/v2beta2`API版本，您可以在自动伸缩 php-apache 这个 Deployment 时引入其他度量指标。
## 基于多项度量指标和自定义度量指标自动扩缩
利用 `autoscaling/v2beta2` API 版本，你可以在自动扩缩 php-apache 这个 Deployment 时使用其他度量指标。
<!--
First, get the YAML of your HorizontalPodAutoscaler in the `autoscaling/v2beta2` form:
-->
首先，获取`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
<!--
Open the `/tmp/hpa-v2.yaml` file in an editor, and you should see YAML which looks like this:
-->
在编辑器中打开`/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 集群中改变名称。
<!--
You can also specify resource metrics in terms of direct values, instead of as percentages of the
requested value, by using a `target` type of `AverageValue` instead of `AverageUtilization`, and
setting the corresponding `target.averageValue` field instead of the `target.averageUtilization`.
-->
您还可以指定资源度量指标使用绝对数值，而不是百分比，你需要将`target`类型`AverageUtilization`替换成`AverageValue`，同时
将`target.averageUtilization`替换成`target.averageValue`并设定相应的值。
你还可以指定资源度量指标使用绝对数值，而不是百分比，你需要将 `target` 类型 `AverageUtilization` 替换成 `AverageValue`，同时
将 `target.averageUtilization` 替换成 `target.averageValue` 并设定相应的值。
<!--
There are two other types of metrics, both of which are considered *custom metrics*: pod metrics and
object metrics. These metrics may have names which are cluster specific, and require a more
advanced cluster monitoring setup.
-->
还有两种其他类型的度量指标，他们被认为是*custom metrics*（自定义度量指标）：
即 Pod 度量指标和对象度量指标（pod metrics and object metrics）。
还有两种其他类型的度量指标，他们被认为是 *custom metrics*（自定义度量指标）：
即 pod 度量指标和 object 度量指标。
这些度量指标可能具有特定于集群的名称，并且需要更高级的集群监控设置。
<!--
@@ -358,13 +359,13 @@ The first of these alternative metric types is *pod metrics*. These metrics des
are averaged together across pods and compared with a target value to determine the replica count.
They work much like resource metrics, except that they *only* support a `target` type of `AverageValue`.
-->
第一种可选的度量指标类型是 Pod 度量指标。这些指标从某一方面描述了Pod，在不同Pod之间进行平均，并通过与一个目标值比对来确定副本的数量。
它们的工作方式与资源度量指标非常相像，差别是它们仅支持`target` 类型为`AverageValue`。
第一种可选的度量指标类型是 pod 度量指标。这些指标从某一方面描述了Pod，在不同 Pod 之间进行平均，并通过与一个目标值比对来确定副本的数量。
它们的工作方式与资源度量指标非常相像，差别是它们仅支持 `target` 类型为 `AverageValue`。
<!--
Pod metrics are specified using a metric block like this:
-->
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 将会计算每一个指标所提议的副本数量，然后最终选择一个最高值。
<!--
For example, if you had your monitoring system collecting metrics about network traffic,
you could update the definition above using `kubectl edit` to look like this:
-->
比如，如果您的监控系统能够提供网络流量数据，您可以通过`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 个。
<!--
### Autoscaling on more specific metrics
-->
### 多个度量指标下伸缩
<!--
Many metrics pipelines allow you to describe metrics either by name or by a set of additional
descriptors called _labels_. For all non-resource metric types (pod, object, and external,
described below), you can specify an additional label selector which is passed to your metric
pipeline. For instance, if you collect a metric `http_requests` with the `verb`
label, you can specify the following metric block to scale only on GET requests:
-->
许多度量管道允许您通过名称或附加的_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` 的目标对象）。
<!--
### Autoscaling on metrics not related to Kubernetes objects
-->
### 基于Kubernetes以外的度量指标伸缩
<!--
Applications running on Kubernetes may need to autoscale based on metrics that don't have an obvious
relationship to any object in the Kubernetes cluster, such as metrics describing a hosted service with
no direct correlation to Kubernetes namespaces. In Kubernetes 1.10 and later, you can address this use case
with *external metrics*.
-->
运行在 Kubernetes 上的应用程序可能需要基于与 Kubernetes 集群中的任何对象没有明显关系的度量指标进行自动伸缩，
例如那些描述不在 Kubernetes 任何 namespaces 服务的度量指标。
### 基于与 Kubernetes 对象无关的度量指标执行扩缩
运行在 Kubernetes 上的应用程序可能需要基于与 Kubernetes 集群中的任何对象没有明显关系的度量指标进行自动扩缩，
例如那些描述与任何 Kubernetes 名字空间中的服务都无直接关联的度量指标。
在 Kubernetes 1.10 及之后版本中，你可以使用外部度量指标（external metrics）。
<!--
Using external metrics requires knowledge of your monitoring system; the setup is
@@ -545,17 +550,19 @@ the sum of their values is used by the HorizontalPodAutoscaler.
External metrics support both the `Value` and `AverageValue` target types, which function exactly the same
as when you use the `Object` type.
-->
使用外部的度量指标，需要了解你使用的监控系统，相关的设置与使用自定义试题指标类似。
External metrics 可以使用你的监控系统的任何指标来自动伸缩你的集群。你只需要在`metric`块中提供`name` 和 `selector`，同时将类型由`Object`改为`External`。
如果`metricSelector`匹配到多个度量指标，HorizontalPodAutoscaler 将会把它们加和。
External metrics 同时支持`Value`和`AverageValue`类型，这与`Object`类型的度量指标相同。
使用外部度量指标时，需要了解你所使用的监控系统，相关的设置与使用自定义指标时类似。
外部度量指标使得你可以使用你的监控系统的任何指标来自动扩缩你的集群。
你只需要在 `metric` 块中提供 `name` 和 `selector`，同时将类型由 `Object` 改为 `External`。
如果 `metricSelector` 匹配到多个度量指标，HorizontalPodAutoscaler 将会把它们加和。
外部度量指标同时支持 `Value` 和 `AverageValue` 类型，这与 `Object` 类型的度量指标相同。
<!--
For example if your application processes tasks from a hosted queue service, you could add the following
section to your HorizontalPodAutoscaler manifest to specify that you need one worker per 30 outstanding tasks.
-->
例如，如果你的应用程序处理主机上的消息队列，
为了让每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 可以允许访问所有的度量指标。
当暴露这些服务时，系统管理员需要仔细考虑这个问题。
<!--
## Appendix: Horizontal Pod Autoscaler Status Conditions
-->
## 附录：Horizontal Pod Autoscaler状态条件
<!--
When using the `autoscaling/v2beta2` form of the HorizontalPodAutoscaler, you will be able to see
*status conditions* set by Kubernetes on the HorizontalPodAutoscaler. These status conditions indicate
whether or not the HorizontalPodAutoscaler is able to scale, and whether or not it is currently restricted
in any way.
-->
当使用`autoscaling/v2beta2`格式的 HorizontalPodAutoscaler 时，您将可以看到 Kubernetes 为 HorizongtalPodAutoscaler 设置的状态条件（status conditions）。
这些状态条件可以显示当前 HorizontalPodAutoscaler 是否能够执行伸缩以及是否受到一定的限制。
## 附录：Horizontal Pod Autoscaler 状态条件
使用 `autoscaling/v2beta2` 格式的 HorizontalPodAutoscaler 时，你将可以看到
Kubernetes 为 HorizongtalPodAutoscaler 设置的状态条件（Status Conditions）。
这些状态条件可以显示当前 HorizontalPodAutoscaler 是否能够执行扩缩以及是否受到一定的限制。
<!--
The conditions appear in the `status.conditions` field. To see the conditions affecting a HorizontalPodAutoscaler,
we can use `kubectl describe hpa`:
-->
`status.conditions`字段展示了这些状态条件。
可以通过`kubectl describe hpa`命令查看当前影响 HorizontalPodAutoscaler 的各种状态条件信息：
可以通过 `kubectl describe hpa` 命令查看当前影响 HorizontalPodAutoscaler
的各种状态条件信息：
```shell
kubectl describe hpa cm-test
```
```shell
```
Name: cm-test
Namespace: prom
Labels: <none>
@@ -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 所定义的最大或者最小副本数量的限制了。
<!--
## Appendix: Quantities
-->
## 附录：Quantities
<!--
All metrics in the HorizontalPodAutoscaler and metrics APIs are specified using
a special whole-number notation known in Kubernetes as a *quantity*. For example,
the quantity `10500m` would be written as `10.5` in decimal notation. The metrics APIs
@@ -653,27 +660,28 @@ quantities in milli-units otherwise. This means you might see your metric value
between `1` and `1500m`, or `1` and `1.5` when written in decimal notation. See the
[glossary entry on quantities](/docs/reference/glossary?core-object=true#term-quantity) for more information.
-->
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)。
<!--
## Appendix: Other possible scenarios
### Creating the autoscaler declaratively
-->
## 附录：其他可能的情况
<!--
### Creating the autoscaler declaratively
-->
### 使用YAML文件创建 autoscaler
### 使用 YAML 文件以声明式方式创建 Autoscaler
<!--
Instead of using `kubectl autoscale` command to create a HorizontalPodAutoscaler imperatively we
can use the following file to create it declaratively:
-->
除了使用 `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
```