[zh-cn] Resync endpoint-slices.md
Michael
windsonsea
parent
db8ca26cbd
commit
b4aab7e4f6
|
|
@ -21,8 +21,8 @@ _EndpointSlices_ provide a simple way to track network endpoints within a
|
|||
Kubernetes cluster. They offer a more scalable and extensible alternative to
|
||||
Endpoints.
|
||||
-->
|
||||
_端点切片（EndpointSlices）_ 提供了一种简单的方法来跟踪 Kubernetes 集群中的网络端点
|
||||
（network endpoints）。它们为 Endpoints 提供了一种可伸缩和可拓展的替代方案。
|
||||
**端点切片（EndpointSlices）** 提供了一种简单的方法来跟踪 Kubernetes 集群中的网络端点（network endpoints）。
|
||||
它们为 Endpoints 提供了一种可扩缩和可拓展的替代方案。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -39,10 +39,9 @@ network endpoints.
|
|||
-->
|
||||
## 动机 {#motivation}
|
||||
|
||||
Endpoints API 提供了在 Kubernetes 跟踪网络端点的一种简单而直接的方法。
|
||||
不幸的是，随着 Kubernetes 集群和 {{< glossary_tooltip text="服务" term_id="service" >}}
|
||||
逐渐开始为更多的后端 Pods 处理和发送请求，原来的 API 的局限性变得越来越明显。
|
||||
最重要的是那些因为要处理大量网络端点而带来的挑战。
|
||||
Endpoints API 提供了在 Kubernetes 中跟踪网络端点的一种简单而直接的方法。遗憾的是，随着 Kubernetes
|
||||
集群和{{< glossary_tooltip text="服务" term_id="service" >}}逐渐开始为更多的后端 Pod 处理和发送请求，
|
||||
原来的 API 的局限性变得越来越明显。最重要的是那些因为要处理大量网络端点而带来的挑战。
|
||||
|
||||
<!--
|
||||
Since all network endpoints for a Service were stored in a single Endpoints
|
||||
|
|
@ -59,26 +58,26 @@ EndpointSlice 能够帮助你缓解这一问题，
|
|||
还能为一些诸如拓扑路由这类的额外功能提供一个可扩展的平台。
|
||||
|
||||
<!--
|
||||
## Endpoint Slice resources {#endpointslice-resource}
|
||||
## EndpointSlice resources {#endpointslice-resource}
|
||||
|
||||
In Kubernetes, an EndpointSlice contains references to a set of network
|
||||
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
|
||||
references to all the Pods that match the Service selector. EndpointSlices group
|
||||
network endpoints together by unique combinations of protocol, port number, and
|
||||
Service name.
|
||||
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.
|
||||
-->
|
||||
## Endpoint Slice 资源 {#endpointslice-resource}
|
||||
## EndpointSlice 资源 {#endpointslice-resource}
|
||||
|
||||
在 Kubernetes 中，`EndpointSlice` 包含对一组网络端点的引用。
|
||||
指定选择器后控制面会自动为设置了 {{< glossary_tooltip text="选择算符" term_id="selector" >}}
|
||||
的 Kubernetes Service 创建 EndpointSlice。
|
||||
控制面会自动为设置了{{< glossary_tooltip text="选择算符" term_id="selector" >}}的
|
||||
Kubernetes Service 创建 EndpointSlice。
|
||||
这些 EndpointSlice 将包含对与 Service 选择算符匹配的所有 Pod 的引用。
|
||||
EndpointSlice 通过唯一的协议、端口号和 Service 名称将网络端点组织在一起。
|
||||
EndpointSlice 的名称必须是合法的
|
||||
|
|
@ -100,7 +99,7 @@ ports:
|
|||
port: 80
|
||||
endpoints:
|
||||
- addresses:
|
||||
- "10.1.2.3"
|
||||
- "10.1.2.3"
|
||||
conditions:
|
||||
ready: true
|
||||
hostname: pod-1
|
||||
|
|
@ -111,7 +110,7 @@ endpoints:
|
|||
<!--
|
||||
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`
|
||||
`--max-endpoints-per-slice`
|
||||
{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
|
||||
flag, up to a maximum of 1000.
|
||||
|
||||
|
|
@ -125,12 +124,12 @@ improvement for services with large numbers of endpoints.
|
|||
的 `--max-endpoints-per-slice` 标志设置此值，最大值为 1000。
|
||||
|
||||
当涉及如何路由内部流量时，EndpointSlice 可以充当
|
||||
{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}
|
||||
{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}
|
||||
的决策依据。
|
||||
启用该功能后，在服务的端点数量庞大时会有可观的性能提升。
|
||||
|
||||
<!--
|
||||
## Address Types
|
||||
### Address types
|
||||
|
||||
EndpointSlices support three address types:
|
||||
|
||||
|
|
@ -138,7 +137,7 @@ EndpointSlices support three address types:
|
|||
* IPv6
|
||||
* FQDN (Fully Qualified Domain Name)
|
||||
-->
|
||||
## 地址类型
|
||||
### 地址类型
|
||||
|
||||
EndpointSlice 支持三种地址类型：
|
||||
|
||||
|
|
@ -157,7 +156,6 @@ The three conditions are `ready`, `serving`, and `terminating`.
|
|||
EndpointSlice API 存储了可能对使用者有用的、有关端点的状况。
|
||||
这三个状况分别是 `ready`、`serving` 和 `terminating`。
|
||||
|
||||
|
||||
<!--
|
||||
#### Ready
|
||||
|
||||
|
|
@ -171,7 +169,7 @@ Services will always have the `ready` condition set to `true`.
|
|||
#### Ready（就绪）
|
||||
|
||||
`ready` 状况是映射 Pod 的 `Ready` 状况的。
|
||||
处于运行中的 Pod，它的 `Ready` 状况被设置为 `True`，应该将此 EndpointSlice 状况也设置为 `true`。
|
||||
对于处于运行中的 Pod，它的 `Ready` 状况被设置为 `True`，应该将此 EndpointSlice 状况也设置为 `true`。
|
||||
出于兼容性原因，当 Pod 处于终止过程中，`ready` 永远不会为 `true`。
|
||||
消费者应参考 `serving` 状况来检查处于终止中的 Pod 的就绪情况。
|
||||
该规则的唯一例外是将 `spec.publishNotReadyAddresses` 设置为 `true` 的 Service。
|
||||
|
|
@ -180,7 +178,7 @@ Services will always have the `ready` condition set to `true`.
|
|||
<!--
|
||||
#### Serving
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
`serving` is identical to the `ready` condition, except it does not account for terminating states.
|
||||
Consumers of the EndpointSlice API should check this condition if they care about pod readiness while
|
||||
|
|
@ -188,7 +186,7 @@ the pod is also terminating.
|
|||
-->
|
||||
#### Serving（服务中）
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
`serving` 状况与 `ready` 状况相同，不同之处在于它不考虑终止状态。
|
||||
如果 EndpointSlice API 的使用者关心 Pod 终止时的就绪情况，就应检查此状况。
|
||||
|
|
@ -205,7 +203,7 @@ for terminating pods independent of the existing semantics for `ready`.
|
|||
尽管 `serving` 与 `ready` 几乎相同，但是它是为防止破坏 `ready` 的现有含义而增加的。
|
||||
如果对于处于终止中的端点，`ready` 可能是 `true`，那么对于现有的客户端来说可能是有些意外的，
|
||||
因为从始至终，Endpoints 或 EndpointSlice API 从未包含处于终止中的端点。
|
||||
出于这个原因，`ready` 对于处于终止中的端点 _总是_ `false`，
|
||||
出于这个原因，`ready` 对于处于终止中的端点 **总是** `false`，
|
||||
并且在 v1.20 中添加了新的状况 `serving`，以便客户端可以独立于 `ready`
|
||||
的现有语义来跟踪处于终止中的 Pod 的就绪情况。
|
||||
{{< /note >}}
|
||||
|
|
@ -213,19 +211,18 @@ for terminating pods independent of the existing semantics for `ready`.
|
|||
<!--
|
||||
#### Terminating
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
`Terminating` is a condition that indicates whether an endpoint is terminating.
|
||||
For pods, this is any pod that has a deletion timestamp set.
|
||||
-->
|
||||
#### Terminating（终止中）
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
`Terminating` 是表示端点是否处于终止中的状况。
|
||||
对于 Pod 来说，这是设置了删除时间戳的 Pod。
|
||||
|
||||
|
||||
<!--
|
||||
### Topology information {#topology}
|
||||
|
||||
|
|
@ -257,8 +254,8 @@ the dedicated fields `nodeName` and `zone`.
|
|||
|
||||
<!--
|
||||
Setting arbitrary topology fields on the `endpoint` field of an `EndpointSlice`
|
||||
resource has been deprecated and is not supported in the v1 API.
|
||||
Instead, the v1 API supports setting individual `nodeName` and `zone` fields.
|
||||
resource has been deprecated and is not supported in the v1 API.
|
||||
Instead, the v1 API supports setting individual `nodeName` and `zone` fields.
|
||||
These fields are automatically translated between API versions. For example, the
|
||||
value of the `"topology.kubernetes.io/zone"` key in the `topology` field in
|
||||
the v1beta1 API is accessible as the `zone` field in the v1 API.
|
||||
|
|
@ -281,7 +278,7 @@ entities or controllers managing additional sets of EndpointSlices.
|
|||
-->
|
||||
### 管理 {#management}
|
||||
|
||||
通常，控制面（尤其是端点切片的 {{< glossary_tooltip text="控制器" term_id="controller" >}}）
|
||||
通常，控制面（尤其是端点切片的{{< glossary_tooltip text="控制器" term_id="controller" >}}）
|
||||
会创建和管理 EndpointSlice 对象。EndpointSlice 对象还有一些其他使用场景，
|
||||
例如作为服务网格（Service Mesh）的实现。
|
||||
这些场景都会导致有其他实体或者控制器负责管理额外的 EndpointSlice 集合。
|
||||
|
|
@ -296,10 +293,10 @@ The endpoint slice controller sets `endpointslice-controller.k8s.io` as the valu
|
|||
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 而且不会相互产生干扰，
|
||||
Kubernetes 定义了{{< glossary_tooltip term_id="label" text="标签" >}}
|
||||
`endpointslice.kubernetes.io/managed-by`，用来标明哪个实体在管理某个 EndpointSlice。
|
||||
端点切片控制器会在自己所管理的所有 EndpointSlice 上将该标签值设置为
|
||||
`endpointslice-controller.k8s.io`。
|
||||
管理 EndpointSlice 的其他实体也应该为此标签设置一个唯一值。
|
||||
|
||||
|
|
@ -355,8 +352,8 @@ 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）的端点时，
|
||||
每个 Endpoints 资源可能会被转译到多个 EndpointSlices 中去。
|
||||
当 Endpoints 资源中包含多个子网或者包含多个 IP 协议族（IPv4 和 IPv6）的端点时，
|
||||
就有可能发生这种状况。
|
||||
每个子网最多有 1000 个地址会被镜像到 EndpointSlice 中。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue