[zh] Resync endpoint-slice page
This commit is contained in:
Qiming Teng
parent
7a44e1a820
commit
062378dc5a
|
|
@ -1,23 +1,13 @@
|
|||
---
|
||||
title: 端点切片（Endpoint Slices）
|
||||
feature:
|
||||
title: 端点切片
|
||||
description: >
|
||||
Kubernetes 集群中网络端点的可扩展跟踪。
|
||||
|
||||
content_type: concept
|
||||
weight: 10
|
||||
weight: 35
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Endpoint Slices
|
||||
feature:
|
||||
title: Endpoint Slices
|
||||
description: >
|
||||
Scalable tracking of network endpoints in a Kubernetes cluster.
|
||||
|
||||
content_type: concept
|
||||
weight: 10
|
||||
weight: 35
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -34,14 +24,50 @@ _端点切片（Endpoint Slices）_ 提供了一种简单的方法来跟踪 Kube
|
|||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Motivation
|
||||
|
||||
The Endpoints API has provided a simple and straightforward way of
|
||||
tracking network endpoints in Kubernetes. Unfortunately as Kubernetes clusters
|
||||
and {{< glossary_tooltip text="Services" term_id="service" >}} have grown to handle and
|
||||
send more traffic to more backend Pods, limitations of that original API became
|
||||
more visible.
|
||||
Most notably, those included challenges with scaling to larger numbers of
|
||||
network endpoints.
|
||||
-->
|
||||
## 动机 {#motivation}
|
||||
|
||||
Endpoints API 提供了在 Kubernetes 跟踪网络端点的一种简单而直接的方法。
|
||||
不幸的是，随着 Kubernetes 集群和 {{< glossary_tooltip text="服务" term_id="service" >}}
|
||||
逐渐开始为更多的后端 Pods 处理和发送请求，原来的 API 的局限性变得越来越明显。
|
||||
最重要的是那些因为要处理大量网络端点而带来的挑战。
|
||||
|
||||
<!--
|
||||
Since all network endpoints for a Service were stored in a single Endpoints
|
||||
resource, those resources could get quite large. That affected the performance
|
||||
of Kubernetes components (notably the master control plane) and resulted in
|
||||
significant amounts of network traffic and processing when Endpoints changed.
|
||||
EndpointSlices help you mitigate those issues as well as provide an extensible
|
||||
platform for additional features such as topological routing.
|
||||
-->
|
||||
由于任一服务的所有网络端点都保存在同一个 Endpoints 资源中，这类资源可能变得
|
||||
非常巨大，而这一变化会影响到 Kubernetes 组件（比如主控组件）的性能，并
|
||||
在 Endpoints 变化时需要处理大量的网络流量和处理。
|
||||
EndpointSlice 能够帮助你缓解这一问题，还能为一些诸如拓扑路由这类的额外
|
||||
功能提供一个可扩展的平台。
|
||||
|
||||
<!--
|
||||
## Endpoint Slice resources {#endpointslice-resource}
|
||||
|
||||
In Kubernetes, an EndpointSlice contains references to a set of network
|
||||
endpoints. The EndpointSlice controller automatically creates Endpoint Slices
|
||||
for a Kubernetes Service when a selector is specified. These Endpoint Slices
|
||||
will include references to any Pods that match the Service selector. Endpoint
|
||||
Slices group network endpoints together by unique Service and Port combinations.
|
||||
endpoints. The control plane automatically creates EndpointSlices
|
||||
for any Kubernetes Service that has a {{< glossary_tooltip text="selector"
|
||||
term_id="selector" >}} specified. These EndpointSlices include
|
||||
references to any Pods that match the Service selector. EndpointSlices group
|
||||
network endpoints together by unique combinations of protocol, port number, and
|
||||
Service name.
|
||||
The name of a EndpointSlice object must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
|
||||
As an example, here's a sample EndpointSlice resource for the `example`
|
||||
Kubernetes Service.
|
||||
|
|
@ -49,10 +75,14 @@ Kubernetes Service.
|
|||
## Endpoint Slice 资源 {#endpointslice-resource}
|
||||
|
||||
在 Kubernetes 中，`EndpointSlice` 包含对一组网络端点的引用。
|
||||
指定选择器后，EndpointSlice 控制器会自动为 Kubernetes 服务创建 EndpointSlice。
|
||||
这些 EndpointSlice 将包含对与服务选择器匹配的所有 Pod 的引用。EndpointSlice 通过唯一的服务和端口组合将网络端点组织在一起。
|
||||
指定选择器后控制面会自动为设置了 {{< glossary_tooltip text="选择算符" term_id="selector" >}}
|
||||
的 Kubernetes 服务创建 EndpointSlice。
|
||||
这些 EndpointSlice 将包含对与服务选择算符匹配的所有 Pod 的引用。
|
||||
EndpointSlice 通过唯一的协议、端口号和服务名称将网络端点组织在一起。
|
||||
EndpointSlice 的名称必须是合法的
|
||||
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
|
||||
|
||||
例如，这里是 Kubernetes服务 `example` 的示例 EndpointSlice 资源。
|
||||
例如，下面是 Kubernetes 服务 `example` 的 EndpointSlice 资源示例。
|
||||
|
||||
```yaml
|
||||
apiVersion: discovery.k8s.io/v1beta1
|
||||
|
|
@ -78,19 +108,25 @@ endpoints:
|
|||
```
|
||||
|
||||
<!--
|
||||
By default, Endpoint Slices managed by the EndpointSlice controller will have no
|
||||
more than 100 endpoints each. Below this scale, Endpoint Slices should map 1:1
|
||||
with Endpoints and Services and have similar performance.
|
||||
By default, the control plane creates and manages EndpointSlices to have no
|
||||
more than 100 endpoints each. You can configure this with the
|
||||
`-max-endpoints-per-slice`
|
||||
{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
|
||||
flag, up to a maximum of 1000.
|
||||
|
||||
Endpoint Slices can act as the source of truth for kube-proxy when it comes to
|
||||
EndpointSlices can act as the source of truth for
|
||||
{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} when it comes to
|
||||
how to route internal traffic. When enabled, they should provide a performance
|
||||
improvement for services with large numbers of endpoints.
|
||||
-->
|
||||
默认情况下，由 EndpointSlice 控制器管理的 Endpoint Slice 将有不超过 100 个端点。
|
||||
低于此比例时，Endpoint Slices 应与 Endpoints 和服务进行 1:1 映射，并具有相似的性能。
|
||||
默认情况下，控制面创建和管理的 EndpointSlice 将包含不超过 100 个端点。
|
||||
你可以使用 {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
|
||||
的 `--max-endpoints-per-slice` 标志设置此值，最大值为 1000。
|
||||
|
||||
当涉及如何路由内部流量时，Endpoint Slices 可以充当 kube-proxy 的真实来源。
|
||||
启用该功能后，在服务的 endpoints 规模庞大时会有可观的性能提升。
|
||||
当涉及如何路由内部流量时，EndpointSlice 可以充当
|
||||
{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}
|
||||
的决策依据。
|
||||
启用该功能后，在服务的端点数量庞大时会有可观的性能提升。
|
||||
|
||||
<!--
|
||||
## Address Types
|
||||
|
|
@ -110,33 +146,222 @@ EndpointSlice 支持三种地址类型：
|
|||
* FQDN (完全合格的域名)
|
||||
|
||||
<!--
|
||||
## Motivation
|
||||
### Topology information {#topology}
|
||||
|
||||
The Endpoints API has provided a simple and straightforward way of
|
||||
tracking network endpoints in Kubernetes. Unfortunately as Kubernetes clusters
|
||||
and Services have gotten larger, limitations of that API became more visible.
|
||||
Most notably, those included challenges with scaling to larger numbers of
|
||||
network endpoints.
|
||||
|
||||
Since all network endpoints for a Service were stored in a single Endpoints
|
||||
resource, those resources could get quite large. That affected the performance
|
||||
of Kubernetes components (notably the master control plane) and resulted in
|
||||
significant amounts of network traffic and processing when Endpoints changed.
|
||||
Endpoint Slices help you mitigate those issues as well as provide an extensible
|
||||
platform for additional features such as topological routing.
|
||||
Each endpoint within an EndpointSlice can contain relevant topology information.
|
||||
This is used to indicate where an endpoint is, containing information about the
|
||||
corresponding Node, zone, and region. When the values are available, the
|
||||
control plane sets the following Topology labels for EndpointSlices:
|
||||
-->
|
||||
## 动机
|
||||
### 拓扑信息 {#topology}
|
||||
|
||||
Endpoints API 提供了一种简单明了的方法在 Kubernetes 中跟踪网络端点。
|
||||
不幸的是，随着 Kubernetes 集群与服务的增长，该 API 的局限性变得更加明显。
|
||||
最值得注意的是，这包含了扩展到更多网络端点的挑战。
|
||||
EndpointSlice 中的每个端点都可以包含一定的拓扑信息。
|
||||
这一信息用来标明端点的位置，包含对应节点、可用区、区域的信息。
|
||||
当这些值可用时，控制面会为 EndpointSlice 设置如下拓扑标签：
|
||||
|
||||
由于服务的所有网络端点都存储在单个 Endpoints 资源中，
|
||||
因此这些资源可能会变得很大。
|
||||
这影响了 Kubernetes 组件（尤其是主控制平面）的性能，并在 Endpoints
|
||||
发生更改时导致大量网络流量和处理。
|
||||
Endpoint Slices 可帮助您缓解这些问题并提供可扩展的
|
||||
附加特性（例如拓扑路由）平台。
|
||||
<!--
|
||||
* `kubernetes.io/hostname` - The name of the Node this endpoint is on.
|
||||
* `topology.kubernetes.io/zone` - The zone this endpoint is in.
|
||||
* `topology.kubernetes.io/region` - The region this endpoint is in.
|
||||
-->
|
||||
* `kubernetes.io/hostname` - 端点所在的节点名称
|
||||
* `topology.kubernetes.io/zone` - 端点所处的可用区
|
||||
* `topology.kubernetes.io/region` - 端点所处的区域
|
||||
|
||||
<!--
|
||||
The values of these labels are derived from resources associated with each
|
||||
endpoint in a slice. The hostname label represents the value of the NodeName
|
||||
field on the corresponding Pod. The zone and region labels represent the value
|
||||
of the labels with the same names on the corresponding Node.
|
||||
-->
|
||||
这些标签的值时根据与切片中各个端点相关联的资源来生成的。
|
||||
标签 `hostname` 代表的是对应的 Pod 的 NodeName 字段的取值。
|
||||
`zone` 和 `region` 标签则代表的是对应的节点所拥有的同名标签的值。
|
||||
|
||||
<!--
|
||||
### Management
|
||||
|
||||
Most often, the control plane (specifically, the endpoint slice
|
||||
{{< glossary_tooltip text="controller" term_id="controller" >}}) creates and
|
||||
manages EndpointSlice objects. There are a variety of other use cases for
|
||||
EndpointSlices, such as service mesh implementations, that could result in other
|
||||
entities or controllers managing additional sets of EndpointSlices.
|
||||
-->
|
||||
### 管理 {#management}
|
||||
|
||||
通常，控制面（尤其是端点切片的 {{< glossary_tooltip text="controller" term_id="controller" >}}）
|
||||
会创建和管理 EndpointSlice 对象。EndpointSlice 对象还有一些其他使用场景，
|
||||
例如作为服务网格（Service Mesh）的实现。这些场景都会导致有其他实体
|
||||
或者控制器负责管理额外的 EndpointSlice 集合。
|
||||
|
||||
<!--
|
||||
To ensure that multiple entities can manage EndpointSlices without interfering
|
||||
with each other, Kubernetes defines the
|
||||
{{< glossary_tooltip term_id="label" text="label" >}}
|
||||
`endpointslice.kubernetes.io/managed-by`, which indicates the entity managing
|
||||
an EndpointSlice.
|
||||
The endpoint slice controller sets `endpointslice-controller.k8s.io` as the value
|
||||
for this label on all EndpointSlices it manages. Other entities managing
|
||||
EndpointSlices should also set a unique value for this label.
|
||||
-->
|
||||
为了确保多个实体可以管理 EndpointSlice 而且不会相互产生干扰，Kubernetes 定义了
|
||||
{{< glossary_tooltip term_id="label" text="标签" >}}
|
||||
`endpointslice.kubernetes.io/managed-by`，用来标明哪个实体在管理某个
|
||||
EndpointSlice。端点切片控制器会在自己所管理的所有 EndpointSlice 上将该标签值设置
|
||||
为 `endpointslice-controller.k8s.io`。
|
||||
管理 EndpointSlice 的其他实体也应该为此标签设置一个唯一值。
|
||||
|
||||
<!--
|
||||
### Ownership
|
||||
|
||||
In most use cases, EndpointSlices are owned by the Service that the endpoint
|
||||
slice object tracks endpoints for. This ownership is indicated by an owner
|
||||
reference on each EndpointSlice as well as a `kubernetes.io/service-name`
|
||||
label that enables simple lookups of all EndpointSlices belonging to a Service.
|
||||
-->
|
||||
### 属主关系 {#ownership}
|
||||
|
||||
在大多数场合下，EndpointSlice 都由某个 Service 所有，（因为）该端点切片正是
|
||||
为该服务跟踪记录其端点。这一属主关系是通过为每个 EndpointSlice 设置一个
|
||||
属主（owner）引用，同时设置 `kubernetes.io/service-name` 标签来标明的，
|
||||
目的是方便查找隶属于某服务的所有 EndpointSlice。
|
||||
|
||||
<!--
|
||||
### EndpointSlice mirroring
|
||||
|
||||
In some cases, applications create custom Endpoints resources. To ensure that
|
||||
these applications do not need to concurrently write to both Endpoints and
|
||||
EndpointSlice resources, the cluster's control plane mirrors most Endpoints
|
||||
resources to corresponding EndpointSlices.
|
||||
-->
|
||||
### EndpointSlice 镜像 {#endpointslice-mirroring}
|
||||
|
||||
在某些场合，应用会创建定制的 Endpoints 资源。为了保证这些应用不需要并发
|
||||
递更改 Endpoints 和 EndpointSlice 资源，集群的控制面将大多数 Endpoints
|
||||
映射到对应的 EndpointSlice 之上。
|
||||
|
||||
<!--
|
||||
The control plane mirrors Endpoints resources unless:
|
||||
|
||||
* the Endpoints resource has a `endpointslice.kubernetes.io/skip-mirror` label
|
||||
set to `true`.
|
||||
* the Endpoints resource has a `control-plane.alpha.kubernetes.io/leader`
|
||||
annotation.
|
||||
* the corresponding Service resource does not exist.
|
||||
* the corresponding Service resource has a non-nil selector.
|
||||
-->
|
||||
控制面对 Endpoints 资源进行映射的例外情况有：
|
||||
|
||||
* Endpoints 资源上标签 `endpointslice.kubernetes.io/skip-mirror` 值为 `true`。
|
||||
* Endpoints 资源包含标签 `control-plane.alpha.kubernetes.io/leader`。
|
||||
* 对应的 Service 资源不存在。
|
||||
* 对应的 Service 的选择算符不为空。
|
||||
|
||||
<!--
|
||||
Individual Endpoints resources may translate into multiple EndpointSlices. This
|
||||
will occur if an Endpoints resource has multiple subsets or includes endpoints
|
||||
with multiple IP families (IPv4 and IPv6). A maximum of 1000 addresses per
|
||||
subset will be mirrored to EndpointSlices.
|
||||
-->
|
||||
每个 Endpoints 资源可能会被翻译到多个 EndpointSlices 中去。
|
||||
当 Endpoints 资源中包含多个子网或者包含多个 IP 地址族（IPv4 和 IPv6）的端点时，
|
||||
就有可能发生这种状况。
|
||||
每个子网最多有 1000 个地址会被镜像到 EndpointSlice 中。
|
||||
|
||||
<!--
|
||||
### Distribution of EndpointSlices
|
||||
|
||||
Each EndpointSlice has a set of ports that applies to all endpoints within the
|
||||
resource. When named ports are used for a Service, Pods may end up with
|
||||
different target port numbers for the same named port, requiring different
|
||||
EndpointSlices. This is similar to the logic behind how subsets are grouped
|
||||
with Endpoints.
|
||||
-->
|
||||
### EndpointSlices 的分布问题 {#distribution-of-endpointslices}
|
||||
|
||||
每个 EndpointSlice 都有一组端口值，适用于资源内的所有端点。
|
||||
当为服务使用命名端口时，Pod 可能会就同一命名端口获得不同的端口号，因而需要
|
||||
不同的 EndpointSlice。这有点像 Endpoints 用来对子网进行分组的逻辑。
|
||||
|
||||
<!--
|
||||
The control plane tries to fill EndpointSlices as full as possible, but does not
|
||||
actively rebalance them. The logic is fairly straightforward:
|
||||
|
||||
1. Iterate through existing EndpointSlices, remove endpoints that are no longer
|
||||
desired and update matching endpoints that have changed.
|
||||
2. Iterate through EndpointSlices that have been modified in the first step and
|
||||
fill them up with any new endpoints needed.
|
||||
3. If there's still new endpoints left to add, try to fit them into a previously
|
||||
unchanged slice and/or create new ones.
|
||||
-->
|
||||
控制面尝试尽量将 EndpointSlice 填满，不过不会主动地在若干 EndpointSlice 之间
|
||||
执行再平衡操作。这里的逻辑也是相对直接的：
|
||||
|
||||
1. 列举所有现有的 EndpointSlices，移除那些不再需要的端点并更新那些已经
|
||||
变化的端点。
|
||||
2. 列举所有在第一步中被更改过的 EndpointSlices，用新增加的端点将其填满。
|
||||
3. 如果还有新的端点未被添加进去，尝试将这些端点添加到之前未更改的切片中，
|
||||
或者创建新切片。
|
||||
|
||||
<!--
|
||||
Importantly, the third step prioritizes limiting EndpointSlice updates over a
|
||||
perfectly full distribution of EndpointSlices. As an example, if there are 10
|
||||
new endpoints to add and 2 EndpointSlices with room for 5 more endpoints each,
|
||||
this approach will create a new EndpointSlice instead of filling up the 2
|
||||
existing EndpointSlices. In other words, a single EndpointSlice creation is
|
||||
preferrable to multiple EndpointSlice updates.
|
||||
-->
|
||||
这里比较重要的是，与在 EndpointSlice 之间完成最佳的分布相比，第三步中更看重
|
||||
限制 EndpointSlice 更新的操作次数。例如，如果有 10 个端点待添加，有两个
|
||||
EndpointSlice 中各有 5 个空位，上述方法会创建一个新的 EndpointSlice 而不是
|
||||
将现有的两个 EndpointSlice 都填满。换言之，与执行多个 EndpointSlice 更新操作
|
||||
相比较，方法会优先考虑执行一个 EndpointSlice 创建操作。
|
||||
|
||||
<!--
|
||||
With kube-proxy running on each Node and watching EndpointSlices, every change
|
||||
to an EndpointSlice becomes relatively expensive since it will be transmitted to
|
||||
every Node in the cluster. This approach is intended to limit the number of
|
||||
changes that need to be sent to every Node, even if it may result with multiple
|
||||
EndpointSlices that are not full.
|
||||
-->
|
||||
由于 kube-proxy 在每个节点上运行并监视 EndpointSlice 状态，EndpointSlice 的
|
||||
每次变更都变得相对代价较高，因为这些状态变化要传递到集群中每个节点上。
|
||||
这一方法尝试限制要发送到所有节点上的变更消息个数，即使这样做可能会导致有
|
||||
多个 EndpointSlice 没有被填满。
|
||||
|
||||
<!--
|
||||
In practice, this less than ideal distribution should be rare. Most changes
|
||||
processed by the EndpointSlice controller will be small enough to fit in an
|
||||
existing EndpointSlice, and if not, a new EndpointSlice is likely going to be
|
||||
necessary soon anyway. Rolling updates of Deployments also provide a natural
|
||||
repacking of EndpointSlices with all Pods and their corresponding endpoints
|
||||
getting replaced.
|
||||
-->
|
||||
在实践中，上面这种并非最理想的分布是很少出现的。大多数被 EndpointSlice 控制器
|
||||
处理的变更都是足够小的，可以添加到某已有 EndpointSlice 中去的。并且，假使无法
|
||||
添加到已有的切片中，不管怎样都会快就会需要一个新的 EndpointSlice 对象。
|
||||
Deployment 的滚动更新为重新为 EndpointSlice 打包提供了一个自然的机会，所有
|
||||
Pod 及其对应的端点在这一期间都会被替换掉。
|
||||
|
||||
<!--
|
||||
### Duplicate endpoints
|
||||
|
||||
Due to the nature of EndpointSlice changes, endpoints may be represented in more
|
||||
than one EndpointSlice at the same time. This naturally occurs as changes to
|
||||
different EndpointSlice objects can arrive at the Kubernetes client watch/cache
|
||||
at different times. Implementations using EndpointSlice must be able to have the
|
||||
endpoint appear in more than one slice. A reference implementation of how to
|
||||
perform endpoint deduplication can be found in the `EndpointSliceCache`
|
||||
implementation in `kube-proxy`.
|
||||
-->
|
||||
### 重复的端点 {#duplicate-endpoints}
|
||||
|
||||
由于 EndpointSlice 变化的自身特点，端点可能会同时出现在不止一个 EndpointSlice
|
||||
中。鉴于不同的 EndpointSlice 对象在不同时刻到达 Kubernetes 的监视/缓存中，
|
||||
这种情况的出现是很自然的。
|
||||
使用 EndpointSlice 的实现必须能够处理端点出现在多个切片中的状况。
|
||||
关于如何执行端点去重（deduplication）的参考实现，你可以在 `kube-proxy` 的
|
||||
`EndpointSlice` 实现中找到。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
@ -144,6 +369,6 @@ Endpoint Slices 可帮助您缓解这些问题并提供可扩展的
|
|||
* [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpoint-slices)
|
||||
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
|
||||
-->
|
||||
* [启用端点切片](/zh/docs/tasks/administer-cluster/enabling-endpointslices)
|
||||
* 阅读[使用服务链接应用](/zh/docs/concepts/services-networking/connect-applications-service/)
|
||||
* 了解[启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices)
|
||||
* 阅读[使用服务连接应用](/zh/docs/concepts/services-networking/connect-applications-service/)
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue