zh-trans:/docs/tasks/administer-federation/hpa.md & /docs/tasks/administer-cluster/extended-resource-node.md (#12432)
* configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * configure-aggregation-layer.md * Update configure-aggregation-layer.md * . * . * . * . * . * . * . * . * configure-aggregation-layer.md * . * . * Update configure-aggregation-layer.md * . * . * . * . * .
This commit is contained in:
MJ-CJM
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
6ed905830f
commit
aee361495b
@@ -0,0 +1,368 @@
|
||||
---
|
||||
title: 为节点发布扩展资源
|
||||
content_template: templates/task
|
||||
---
|
||||
<!--
|
||||
---
|
||||
title: Advertise Extended Resources for a Node
|
||||
content_template: templates/task
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
This page shows how to specify extended resources for a Node.
|
||||
Extended resources allow cluster administrators to advertise node-level
|
||||
resources that would otherwise be unknown to Kubernetes.
|
||||
-->
|
||||
本文展示了如何为节点指定扩展资源。 扩展资源允许集群管理员发布节点级别的资源，这些资源在不进行发布的情况下无法被 Kubernetes 感知。
|
||||
|
||||
{{< feature-state state="stable" >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!--
|
||||
## Get the names of your Nodes
|
||||
|
||||
```shell
|
||||
kubectl get nodes
|
||||
```
|
||||
|
||||
Choose one of your Nodes to use for this exercise.
|
||||
-->
|
||||
## 获取您的节点名称
|
||||
|
||||
```shell
|
||||
kubectl get nodes
|
||||
```
|
||||
|
||||
选择您的一个节点用于此练习。
|
||||
|
||||
<!--
|
||||
## Advertise a new extended resource on one of your Nodes
|
||||
|
||||
To advertise a new extended resource on a Node, send an HTTP PATCH request to
|
||||
the Kubernetes API server. For example, suppose one of your Nodes has four dongles
|
||||
attached. Here's an example of a PATCH request that advertises four dongle resources
|
||||
for your Node.
|
||||
|
||||
```shell
|
||||
PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
|
||||
Accept: application/json
|
||||
Content-Type: application/json-patch+json
|
||||
Host: k8s-master:8080
|
||||
|
||||
[
|
||||
{
|
||||
"op": "add",
|
||||
"path": "/status/capacity/example.com~1dongle",
|
||||
"value": "4"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
Note that Kubernetes does not need to know what a dongle is or what a dongle is for.
|
||||
The preceding PATCH request just tells Kubernetes that your Node has four things that
|
||||
you call dongles.
|
||||
|
||||
Start a proxy, so that you can easily send requests to the Kubernetes API server:
|
||||
|
||||
```
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
In another command window, send the HTTP PATCH request.
|
||||
Replace `<your-node-name>` with the name of your Node:
|
||||
|
||||
```shell
|
||||
curl --header "Content-Type: application/json-patch+json" \
|
||||
--request PATCH \
|
||||
--data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \
|
||||
http://localhost:8001/api/v1/nodes/<your-node-name>/status
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
In the preceding request, `~1` is the encoding for the character / in
|
||||
the patch path. The operation path value in JSON-Patch is interpreted as a
|
||||
JSON-Pointer. For more details, see
|
||||
[IETF RFC 6901](https://tools.ietf.org/html/rfc6901), section 3.
|
||||
{{< /note >}}
|
||||
|
||||
The output shows that the Node has a capacity of 4 dongles:
|
||||
|
||||
```
|
||||
"capacity": {
|
||||
"cpu": "2",
|
||||
"memory": "2049008Ki",
|
||||
"example.com/dongle": "4",
|
||||
```
|
||||
|
||||
Describe your Node:
|
||||
|
||||
```
|
||||
kubectl describe node <your-node-name>
|
||||
```
|
||||
|
||||
Once again, the output shows the dongle resource:
|
||||
|
||||
```yaml
|
||||
Capacity:
|
||||
cpu: 2
|
||||
memory: 2049008Ki
|
||||
example.com/dongle: 4
|
||||
```
|
||||
|
||||
Now, application developers can create Pods that request a certain
|
||||
number of dongles. See
|
||||
[Assign Extended Resources to a Container](/docs/tasks/configure-pod-container/extended-resource/).
|
||||
-->
|
||||
## 在您的一个节点上发布一种新的扩展资源
|
||||
|
||||
为在一个节点上发布一种新的扩展资源，需要发送一个 HTTP PATCH 请求到 Kubernetes API server。 例如：假设您的一个节点上带有四个 dongle 资源。下面是一个 PATCH 请求的示例， 该请求为您的节点发布四个 dongle 资源。
|
||||
|
||||
```shell
|
||||
PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
|
||||
Accept: application/json
|
||||
Content-Type: application/json-patch+json
|
||||
Host: k8s-master:8080
|
||||
|
||||
[
|
||||
{
|
||||
"op": "add",
|
||||
"path": "/status/capacity/example.com~1dongle",
|
||||
"value": "4"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
注意：Kubernetes 不需要了解 dongle 资源的含义和用途。 前面的 PATCH 请求仅仅告诉 Kubernetes 您的节点拥有四个您称之为 dongle 的东西。
|
||||
|
||||
启动一个代理（proxy），以便您可以很容易地向 Kubernetes API server 发送请求：
|
||||
|
||||
```
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
在另一个命令窗口中，发送 HTTP PATCH 请求。 用您的节点名称替换 `<your-node-name>`：
|
||||
|
||||
```shell
|
||||
curl --header "Content-Type: application/json-patch+json" \
|
||||
--request PATCH \
|
||||
--data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \
|
||||
http://localhost:8001/api/v1/nodes/<your-node-name>/status
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
在前面的请求中，`~1` 为 patch 路径中 “/” 符号的编码。JSON-Patch 中的操作路径值被解析为 JSON 指针。 更多细节，请查看 [IETF RFC 6901](https://tools.ietf.org/html/rfc6901) 的第 3 部分。
|
||||
{{< /note >}}
|
||||
|
||||
输出显示该节点的 dongle 资源容量（capacity）为 4：
|
||||
|
||||
```
|
||||
"capacity": {
|
||||
"cpu": "2",
|
||||
"memory": "2049008Ki",
|
||||
"example.com/dongle": "4",
|
||||
```
|
||||
|
||||
描述您的节点：
|
||||
|
||||
```
|
||||
kubectl describe node <your-node-name>
|
||||
```
|
||||
|
||||
输出再次展示了 dongle 资源：
|
||||
|
||||
```yaml
|
||||
Capacity:
|
||||
cpu: 2
|
||||
memory: 2049008Ki
|
||||
example.com/dongle: 4
|
||||
```
|
||||
|
||||
现在，应用开发者可以创建请求一定数量 dongle 资源的 Pod 了。 参见[将扩展资源分配给容器](/docs/tasks/configure-pod-container/extended-resource/)。
|
||||
|
||||
<!--
|
||||
## Discussion
|
||||
|
||||
Extended resources are similar to memory and CPU resources. For example,
|
||||
just as a Node has a certain amount of memory and CPU to be shared by all components
|
||||
running on the Node, it can have a certain number of dongles to be shared
|
||||
by all components running on the Node. And just as application developers
|
||||
can create Pods that request a certain amount of memory and CPU, they can
|
||||
create Pods that request a certain number of dongles.
|
||||
|
||||
Extended resources are opaque to Kubernetes; Kubernetes does not
|
||||
know anything about what they are. Kubernetes knows only that a Node
|
||||
has a certain number of them. Extended resources must be advertised in integer
|
||||
amounts. For example, a Node can advertise four dongles, but not 4.5 dongles.
|
||||
-->
|
||||
## 讨论
|
||||
|
||||
扩展资源类似于内存和 CPU 资源。 例如，正如一个节点拥有一定数量的内存和 CPU 资源， 它们被节点上运行的所有组件共享，该节点也可以拥有一定数量的 dongle 资源， 这些资源同样被节点上运行的所有组件共享。 此外，正如应用开发者可以创建请求一定数量的内存和 CPU 资源的 Pod， 他们也可以创建请求一定数量 dongle 资源的 Pod。
|
||||
|
||||
扩展资源对 Kubernetes 是不透明的。 Kubernetes 不知道扩展资源含义相关的任何信息。 Kubernetes 只了解一个节点拥有一定数量的扩展资源。 扩展资源必须以整形数量进行发布。 例如，一个节点可以发布 4 个 dongle 资源，但是不能发布 4.5 个。
|
||||
|
||||
<!--
|
||||
### Storage example
|
||||
|
||||
Suppose a Node has 800 GiB of a special kind of disk storage. You could
|
||||
create a name for the special storage, say example.com/special-storage.
|
||||
Then you could advertise it in chunks of a certain size, say 100 GiB. In that case,
|
||||
your Node would advertise that it has eight resources of type
|
||||
example.com/special-storage.
|
||||
|
||||
```yaml
|
||||
Capacity:
|
||||
...
|
||||
example.com/special-storage: 8
|
||||
```
|
||||
|
||||
If you want to allow arbitrary requests for special storage, you
|
||||
could advertise special storage in chunks of size 1 byte. In that case, you would advertise
|
||||
800Gi resources of type example.com/special-storage.
|
||||
|
||||
```yaml
|
||||
Capacity:
|
||||
...
|
||||
example.com/special-storage: 800Gi
|
||||
```
|
||||
|
||||
Then a Container could request any number of bytes of special storage, up to 800Gi.
|
||||
-->
|
||||
### 存储示例
|
||||
|
||||
假设一个节点拥有一种特殊类型的磁盘存储，其容量为 800 GiB。 您可以为该特殊存储创建一个名称， 如 example.com/special-storage。 然后您就可以按照一定规格的块（如 100 GiB）对其进行发布。 在这种情况下，您的节点将会通知它拥有八个 example.com/special-storage 类型的资源。
|
||||
|
||||
```yaml
|
||||
Capacity:
|
||||
...
|
||||
example.com/special-storage: 8
|
||||
```
|
||||
|
||||
如果您想要允许针对特殊存储任意（数量）的请求，您可以按照 1 byte 大小的块来发布特殊存储。 在这种情况下，您将会发布 800Gi 数量的 example.com/special-storage 类型的资源。
|
||||
|
||||
```yaml
|
||||
Capacity:
|
||||
...
|
||||
example.com/special-storage: 800Gi
|
||||
```
|
||||
|
||||
然后，容器就能够请求任意数量（多达 800Gi）字节的特殊存储。
|
||||
|
||||
<!--
|
||||
## Clean up
|
||||
|
||||
Here is a PATCH request that removes the dongle advertisement from a Node.
|
||||
|
||||
```shell
|
||||
PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
|
||||
Accept: application/json
|
||||
Content-Type: application/json-patch+json
|
||||
Host: k8s-master:8080
|
||||
|
||||
[
|
||||
{
|
||||
"op": "remove",
|
||||
"path": "/status/capacity/example.com~1dongle",
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
Start a proxy, so that you can easily send requests to the Kubernetes API server:
|
||||
|
||||
```
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
In another command window, send the HTTP PATCH request.
|
||||
Replace `<your-node-name>` with the name of your Node:
|
||||
|
||||
```shell
|
||||
curl --header "Content-Type: application/json-patch+json" \
|
||||
--request PATCH \
|
||||
--data '[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]' \
|
||||
http://localhost:8001/api/v1/nodes/<your-node-name>/status
|
||||
```
|
||||
|
||||
Verify that the dongle advertisement has been removed:
|
||||
|
||||
```
|
||||
kubectl describe node <your-node-name> | grep dongle
|
||||
```
|
||||
-->
|
||||
## 清理
|
||||
|
||||
这里是一个从节点移除 dongle 资源发布的 PATCH 请求。
|
||||
|
||||
```shell
|
||||
PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
|
||||
Accept: application/json
|
||||
Content-Type: application/json-patch+json
|
||||
Host: k8s-master:8080
|
||||
|
||||
[
|
||||
{
|
||||
"op": "remove",
|
||||
"path": "/status/capacity/example.com~1dongle",
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
启动一个代理，以便您可以很容易地向 Kubernetes API server 发送请求：
|
||||
|
||||
```
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
在另一个命令窗口中，发送 HTTP PATCH 请求。 用您的节点名称替换 `<your-node-name>`：
|
||||
|
||||
```shell
|
||||
curl --header "Content-Type: application/json-patch+json" \
|
||||
--request PATCH \
|
||||
--data '[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]' \
|
||||
http://localhost:8001/api/v1/nodes/<your-node-name>/status
|
||||
```
|
||||
|
||||
验证 dongle 资源的发布已经被移除：
|
||||
|
||||
```
|
||||
kubectl describe node <your-node-name> | grep dongle
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
### For application developers
|
||||
|
||||
* [Assign Extended Resources to a Container](/docs/tasks/configure-pod-container/extended-resource/)
|
||||
|
||||
### For cluster administrators
|
||||
|
||||
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
|
||||
-->
|
||||
### 针对应用开发人员
|
||||
|
||||
* [将扩展资源分配给容器](/docs/tasks/configure-pod-container/extended-resource/)
|
||||
|
||||
### 针对集群管理员
|
||||
|
||||
* [为 Namespace 配置最小和最大内存约束](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
* [为 Namespace 配置最小和最大 CPU 约束](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,292 @@
|
||||
---
|
||||
title: 联邦横向 Pod 伸缩器 (HPA)
|
||||
content_template: templates/task
|
||||
---
|
||||
<!--
|
||||
---
|
||||
title: Federated Horizontal Pod Autoscalers (HPA)
|
||||
content_template: templates/task
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state state="alpha" >}}
|
||||
|
||||
{{< note >}}
|
||||
{{< include "federation-current-state.md" >}}
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
This guide explains how to use federated horizontal pod autoscalers (HPAs) in the federation control plane.
|
||||
|
||||
HPAs in the federation control plane are similar to the traditional [Kubernetes
|
||||
HPAs](/docs/tasks/run-application/horizontal-pod-autoscale/), and provide the same functionality.
|
||||
Creating an HPA targeting a federated object in the federation control plane ensures that the
|
||||
desired number of replicas of the target object are scaled across the registered clusters,
|
||||
instead of a single cluster. Also, the control plane keeps monitoring the status of each
|
||||
individual HPA in the federated clusters and ensures the workload replicas move where they are
|
||||
needed most by manipulating the min and max limits of the HPA objects in the federated clusters.
|
||||
-->
|
||||
本指南介绍了如何在联邦控制平面中使用联邦横向 pod 自动伸缩器 （HPAs）。
|
||||
|
||||
联邦控制平面中的 HPA 与传统的 [Kubernetes HPA](/docs/tasks/run-application/horizontal-pod-autoscale/) 非常相似，提供相同的功能。
|
||||
在联邦控制平面中针对联邦对象创建的 HPA 将保证目标对象的期望副本在所有注册集群上进行伸缩，而不是在单个集群上。此外，控制平面持续监控联邦集群中单个 HPA 的状态，通过操作联邦集群中 HPA 对象的最小和最大限制值来确保工作副本被移动到最需要的地方。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
<!--
|
||||
* {{< include "federated-task-tutorial-prereqs.md" >}}
|
||||
* You are also expected to have a basic
|
||||
[working knowledge of Kubernetes](/docs/setup/) in
|
||||
general and [HPAs](/docs/tasks/run-application/horizontal-pod-autoscale/) in particular.
|
||||
|
||||
The federated HPA is an alpha feature. The API is not enabled by default on the
|
||||
federated API server. To use this feature, the user or the admin deploying the federation control
|
||||
plane needs to run the federated API server with option `--runtime-config=api/all=true` to
|
||||
enable all APIs, including alpha APIs. Additionally, the federated HPA only works
|
||||
when used with CPU utilization metrics.
|
||||
-->
|
||||
* {{< include "federated-task-tutorial-prereqs.md" >}}
|
||||
* 通常您还应当拥有基本的 [Kubernetes 应用知识](/docs/setup/)，特别是 [HPA](/docs/tasks/run-application/horizontal-pod-autoscale/) 。
|
||||
|
||||
联邦 HPA 是一个 alpha 特性。默认情况下该 API 没有在联邦 API server 上启用。要使用此特性，部署联邦控制平面的用户或管理员需要使用 `--runtime-config=api/all=true` 选项运行联邦 API server 以启用所有 API（包括 alpha API）。此外，联邦 HPA 只能和 CPU 使用率度量一起使用。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!--
|
||||
## Creating a federated HPA
|
||||
|
||||
The API for federated HPAs is 100% compatible with the
|
||||
API for traditional Kubernetes HPA. You can create an HPA by sending
|
||||
a request to the federation API server.
|
||||
|
||||
You can do that with [kubectl](/docs/user-guide/kubectl/) by running:
|
||||
|
||||
```shell
|
||||
cat <<EOF | kubectl --context=federation-cluster create -f -
|
||||
apiVersion: autoscaling/v1
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: php-apache
|
||||
namespace: default
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
apiVersion: apps/v1beta1
|
||||
kind: Deployment
|
||||
name: php-apache
|
||||
minReplicas: 1
|
||||
maxReplicas: 10
|
||||
targetCPUUtilizationPercentage: 50
|
||||
EOF
|
||||
```
|
||||
|
||||
The `--context=federation-cluster` flag tells `kubectl` to submit the
|
||||
request to the federation API server instead of sending it to a Kubernetes
|
||||
cluster.
|
||||
|
||||
Once a federated HPA is created, the federation control plane partitions and
|
||||
creates the HPA in all underlying Kubernetes clusters. As of Kubernetes V1.7,
|
||||
[cluster selectors](/docs/tasks/administer-federation/cluster/#clusterselector-annotation)
|
||||
can also be used to restrict any federated object, including the HPAs in a subset
|
||||
of clusters.
|
||||
|
||||
You can verify the creation by checking each of the underlying clusters. For example, with a context named `gce-asia-east1a`
|
||||
configured in your client for your cluster in that zone:
|
||||
|
||||
```shell
|
||||
kubectl --context=gce-asia-east1a get HPA php-apache
|
||||
```
|
||||
|
||||
The HPA in the underlying clusters will match the federation HPA
|
||||
except in the number of min and max replicas. The federation control plane ensures that the sum of max replicas in each cluster matches the specified
|
||||
max replicas on the federated HPA object, and the sum of minimum replicas will be greater
|
||||
than or equal to the minimum specified on the federated HPA object.
|
||||
|
||||
{{< note >}}
|
||||
A particular cluster cannot have a minimum replica sum of 0.
|
||||
{{< /note >}}
|
||||
-->
|
||||
## 创建联邦 HPA
|
||||
|
||||
联邦 HPA 的 API 100% 兼容传统 Kubernetes HPA 的 API。您可以通过向联邦 API server 发送请求来创建 HPA。
|
||||
|
||||
您可以使用 [kubectl](/docs/user-guide/kubectl/) 运行命令：
|
||||
|
||||
```shell
|
||||
cat <<EOF | kubectl --context=federation-cluster create -f -
|
||||
apiVersion: autoscaling/v1
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: php-apache
|
||||
namespace: default
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
apiVersion: apps/v1beta1
|
||||
kind: Deployment
|
||||
name: php-apache
|
||||
minReplicas: 1
|
||||
maxReplicas: 10
|
||||
targetCPUUtilizationPercentage: 50
|
||||
EOF
|
||||
```
|
||||
|
||||
`--context=federation-cluster` 参数告诉 `kubectl` 将请求提交到联邦 API server 而不是发送给某一个 Kubernetes 集群。
|
||||
|
||||
一旦创建了联邦 HPA，联邦控制平面就会对其进行分区，并在所有基础集群中创建 HPA。从 Kubernetes v1.7 开始，[cluster selectors](/docs/tasks/administer-federation/cluster/#clusterselector-annotation) 同样可以用来限制任何联邦对象，包括集群子集中的 HPA。
|
||||
|
||||
您可以通过检查每个基础集群来验证创建是否成功。例如，您的客户端配置了名为 `gce-asia-east1a` 的上下文，集群处于该区域中：
|
||||
|
||||
```shell
|
||||
kubectl --context=gce-asia-east1a get HPA php-apache
|
||||
```
|
||||
|
||||
除了最小和最大副本的数量之外，基础集群中的 HPA 将与联邦 HPA 相匹配。联邦控制平面将保证每个集群的最大副本数总和等于联邦 HPA 对象的最大副本数，并且最小副本总和大于等于联邦 HPA 对象的最小副本数。
|
||||
|
||||
{{< note >}}
|
||||
集群的最小副本总和不能为 0。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Spreading HPA min and max replicas in underlying clusters
|
||||
|
||||
By default, first max replicas are spread equally in all the underlying clusters, then min replicas are distributed to those clusters that received their maximum value. This means
|
||||
that each cluster will get an HPA if the specified max replicas are greater than
|
||||
the total clusters participating in this federation, and some clusters will be
|
||||
skipped if specified max replicas are less than the total clusters participating
|
||||
in the federation.
|
||||
|
||||
For example: if you have 3 registered clusters and you create a federated HPA with
|
||||
`spec.maxReplicas = 9`, and `spec.minReplicas = 2`, then each HPA in the 3 clusters
|
||||
will get `spec.maxReplicas=3` and `spec.minReplicas = 1`.
|
||||
|
||||
Currently the default distribution is only available on the federated HPA, but in the
|
||||
future, users preferences could also be specified to control and/or restrict this
|
||||
distribution.
|
||||
-->
|
||||
### 在基础集群中分发 HPA 的最小和最大副本数
|
||||
|
||||
默认情况下，首先将最大副本数在所有基础集群中平均分布，然后再将最小副本数分发给已接收了最大副本数的集群。这意味着，如果指定的最大副本数大于联邦的集群数，则每个集群都将获得一个 HPA。反之，如果指定的最大副本数小于联邦的集群数，则会跳过某些集群。
|
||||
|
||||
举例说明：如果您有3个注册集群，并且您使用参数 `spec.maxReplicas = 9` 和 `spec.minReplicas = 2` 创建了一个联邦 HPA，那么3个集群中的每个 HPA 都将获得 `spec.maxReplicas=3` 和 `spec.minReplicas = 1` 的参数。
|
||||
|
||||
目前，联邦 HPA 仅可以使用默认的分发机制，但在将来，用户将可以设置偏好来控制和/或限制分发过程。
|
||||
|
||||
<!--
|
||||
## Updating a federated HPA
|
||||
|
||||
You can update a federated HPA as you would update a Kubernetes
|
||||
HPA; however, for a federated HPA, you must send the request to
|
||||
the federation API server instead of sending it to a specific Kubernetes cluster.
|
||||
The Federation control plane ensures that whenever the federated HPA is
|
||||
updated, it updates the corresponding HPA in all underlying clusters to
|
||||
match it.
|
||||
|
||||
If your update includes a change in the number of replicas, the federation
|
||||
control plane will change the number of replicas in underlying clusters to
|
||||
ensure that the sum of the max and min replicas remains matched as specified
|
||||
in the previous section.
|
||||
-->
|
||||
## 更新联邦 HPA
|
||||
|
||||
您可以像更新 Kubernetes HPA 一样更新联邦 HPA；但是，对于联邦 HPA 您必须将请求发送给联邦 API server 而不是发送到一个特定的 Kubernetes 集群。联邦控制平面将保证在联邦 HPA 被更新后，它会对所有基础集群中与之对应的 HPA 进行更新。
|
||||
|
||||
如果您的更新修改了副本数量，联邦控制平面将修改基础集群中的副本数量，保证最小副本总数和最大副本总数仍然符合要求正如前文所述。
|
||||
|
||||
<!--
|
||||
## Deleting a federated HPA
|
||||
|
||||
You can delete a federated HPA as you would delete a Kubernetes
|
||||
HPA; however, for a federated HPA, you must send the request to
|
||||
the federation API server instead of to a specific Kubernetes cluster.
|
||||
|
||||
{{< note >}}
|
||||
For the federated resource to be deleted from all underlying clusters, [cascading deletion](/docs/concepts/cluster-administration/federation/#cascading-deletion) should be used.
|
||||
{{< /note >}}
|
||||
|
||||
For example, you can do that using `kubectl` by running:
|
||||
|
||||
```shell
|
||||
kubectl --context=federation-cluster delete HPA php-apache
|
||||
```
|
||||
-->
|
||||
## 删除联邦 HPA
|
||||
|
||||
您可以像删除 Kubernetes HPA 一样删除联邦 HPA；但是，对于联邦 HPA， 您必须将请求发送给联邦 API server 而不是发送到一个特定的 Kubernetes 集群。
|
||||
|
||||
{{< note >}}
|
||||
如果要删除所有基础集群中的联邦资源，应该使用 [级联删除](/docs/concepts/cluster-administration/federation/#cascading-deletion)。
|
||||
{{< /note >}}
|
||||
|
||||
例如，您可以使用 `kubectl` 运行命令：
|
||||
|
||||
```shell
|
||||
kubectl --context=federation-cluster delete HPA php-apache
|
||||
```
|
||||
|
||||
<!--
|
||||
## Alternative ways to use federated HPA
|
||||
|
||||
To a federation user interacting with federated control plane (or simply federation),
|
||||
the interaction is almost identical to interacting with a normal Kubernetes cluster (but
|
||||
with a limited set of APIs that are federated). As both Deployments and
|
||||
HorizontalPodAutoscalers are now federated, `kubectl` commands like `kubectl run`
|
||||
and `kubectl autoscale` work on federation. Given this fact, the mechanism specified in
|
||||
[horizontal pod autoscaler walkthrough](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)
|
||||
will also work when used with federation.
|
||||
Care however will need to be taken that when
|
||||
[generating load on a target deployment](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#step-three-increase-load),
|
||||
it should be done against a specific federated cluster (or multiple clusters) not the federation.
|
||||
-->
|
||||
## 使用联邦 HPA 的其他方法
|
||||
|
||||
对于和联邦控制平面（或简称联邦）交互的用户，这种交互几乎和与一个普通 Kubernetes 集群的交互完全相同（但只能使用有限的联邦 API 集合）。由于目前 Deployment 和 HorizontalPodAutoscaler 都有联邦版本，类似 `kubectl run` 和 `kubectl autoscale` 的 `kubectl` 命令都可以在联邦上运行。鉴于这个事实，[horizontal pod autoscaler walkthrough](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) 中指定的机制同样可以在联邦中运行。但也需要注意，当[在目标 deployment 上生成负载](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#step-three-increase-load) 时，应该针对一个特定的联邦集群（或多个集群）而不是整个联邦。
|
||||
|
||||
<!--
|
||||
## Conclusion
|
||||
|
||||
The use of federated HPA is to ensure workload replicas move to the cluster(s) where
|
||||
they are needed most, or in other words where the load is beyond expected threshold.
|
||||
The federated HPA feature achieves this by manipulating the min and max replicas on the
|
||||
HPAs it creates in the federated clusters. It does not directly monitor the target
|
||||
object metrics from the federated clusters. It actually relies on the in-cluster HPA
|
||||
controllers to monitor the metrics and update relevant fields. The in-cluster HPA
|
||||
controller monitors the target pod metrics and updates the fields like desired
|
||||
replicas (after metrics based calculations) and current replicas (observing the
|
||||
current status of in cluster pods). The federated HPA controller, on the other hand,
|
||||
monitors only the cluster-specific HPA object fields and updates the min replica and
|
||||
max replica fields of those in cluster HPA objects, which have replicas matching thresholds.
|
||||
|
||||
For example, if a cluster has both desired replicas and current replicas the same as the max replicas,
|
||||
and averaged current CPU utilization still higher than the target CPU utilization (all of which
|
||||
are fields on local HPA object), then the target app in this cluster
|
||||
needs more replicas, and the scaling is currently restricted by max replicas set on this local
|
||||
HPA object. In such a scenario, the federated HPA controller scans all clusters and tries to
|
||||
find clusters which do not have such a condition (meaning the desired replicas are less
|
||||
than the max, and current averaged CPU utilization is lower then the threshold). If it finds such
|
||||
a cluster, it reduces the max replica on the HPA in this cluster and increases the max replicas
|
||||
on the HPA in the cluster which needed the replicas.
|
||||
|
||||
There are many other similar conditions which the federated HPA controller checks and moves the max
|
||||
replicas and min replicas around the local HPAs in federated clusters to eventually ensure that
|
||||
the replicas move (or remain) in the cluster(s) which need them.
|
||||
|
||||
For more information, see ["federated HPA design proposal"](https://github.com/kubernetes/community/pull/593).
|
||||
-->
|
||||
## 结论
|
||||
|
||||
使用联邦 HPA 是为了保证工作副本移动到最需要它们的地方，换句话说，是移动到负载超过期望阈值的地方。联邦 HPA 功能通过操作其在联邦集群中创建的 HPA 的最小和最大副本数来实现此目的。它并不直接监控联邦集群中目标对象的度量值，实际上依赖于集群内部的 HPA 控制器来监控目标 pod 的度量值并更新相关字段。集群内部的 HPA 控制器监控目标 pod 的度量值并更新相关字段，如期望的副本数（在基于度量的计算之后）和当前副本数（通过观察集群中 pod 的当前状态）。另一方面，联邦 HPA 控制器只监控集群特定的 HPA 对象字段并更新集群中 HPA 对象的最小和最大副本数字段，这些对象的副本数和阈值匹配。
|
||||
|
||||
例如，如果一个集群同时拥有期望副本数和当前副本数，其值与最大副本数相同，但当前 CPU 的平均利用率仍然高于目标使用率（它们都是本地 HPA 对象上的字段）时，集群中的目标应用程序就需要更多的副本，但是扩容动作被本地 HPA 对象上设置的最大副本数限制。在这种场景下，联邦 HPA 控制器将会扫描所有集群并尝试查找没有这种条件的集群（意思是期望副本数小于最大值且当前 CPU 平均使用率低于阈值）。如果找到了这样的集群，它会减少该集群中 HPA 的最大副本数，并增加最需要副本的集群上的 HPA 的最大副本数。
|
||||
|
||||
还存在许多类似的情况导致联邦 HPA 控制器检查并移动联邦集群中本地 HPA 的最大和最小副本数，以确保副本最终移动（或保留）到最需要它们的集群中。
|
||||
|
||||
更多相关信息请参考["联邦 HPA 设计提议"](https://github.com/kubernetes/community/pull/593)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user