diff --git a/content/zh/docs/concepts/services-networking/endpoint-slices.md b/content/zh/docs/concepts/services-networking/endpoint-slices.md index 447caae39c..05f808a1a9 100644 --- a/content/zh/docs/concepts/services-networking/endpoint-slices.md +++ b/content/zh/docs/concepts/services-networking/endpoint-slices.md @@ -52,11 +52,11 @@ 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 能够帮助你缓解这一问题，还能为一些诸如拓扑路由这类的额外 -功能提供一个可扩展的平台。 +由于任一 Service 的所有网络端点都保存在同一个 Endpoints 资源中， +这类资源可能变得非常巨大，而这一变化会影响到 Kubernetes +组件（比如主控组件）的性能，并在 Endpoints 变化时产生大量的网络流量和额外的处理。 +EndpointSlice 能够帮助你缓解这一问题， +还能为一些诸如拓扑路由这类的额外功能提供一个可扩展的平台。 -在 v1 API 中，逐个端点设置的 `topology` 实际上被去除，以鼓励使用专用 -的字段 `nodeName` 和 `zone`。 +在 v1 API 中，逐个端点设置的 `topology` 实际上被去除， +以鼓励使用专用的字段 `nodeName` 和 `zone`。 -对 `EndpointSlice` 对象的 `endpoint` 字段设置任意的拓扑结构信息这一操作已被 -废弃，不再被 v1 API 所支持。取而代之的是 v1 API 所支持的 `nodeName` 和 `zone` +对 `EndpointSlice` 对象的 `endpoint` 字段设置任意的拓扑结构信息这一操作已被废弃， +不再被 v1 API 所支持。取而代之的是 v1 API 所支持的 `nodeName` 和 `zone` 这些独立的字段。这些字段可以在不同的 API 版本之间自动完成转译。 -例如，v1beta1 API 中 `topology` 字段的 `topology.kubernetes.io/zone` 取值可以 -在 v1 API 中通过 `zone` 字段访问。 +例如，v1beta1 API 中 `topology` 字段的 `topology.kubernetes.io/zone` +取值可以在 v1 API 中通过 `zone` 字段访问。 {{< /note >}} ### 属主关系 {#ownership} -在大多数场合下，EndpointSlice 都由某个 Service 所有，（因为）该端点切片正是 -为该服务跟踪记录其端点。这一属主关系是通过为每个 EndpointSlice 设置一个 -属主（owner）引用，同时设置 `kubernetes.io/service-name` 标签来标明的， -目的是方便查找隶属于某服务的所有 EndpointSlice。 +在大多数场合下，EndpointSlice 都由某个 Service 所有， +（因为）该端点切片正是为该服务跟踪记录其端点。这一属主关系是通过为每个 EndpointSlice +设置一个属主（owner）引用，同时设置 `kubernetes.io/service-name` 标签来标明的， +目的是方便查找隶属于某 Service 的所有 EndpointSlice。 ### EndpointSlice 镜像 {#endpointslice-mirroring} -在某些场合，应用会创建定制的 Endpoints 资源。为了保证这些应用不需要并发 -的更改 Endpoints 和 EndpointSlice 资源，集群的控制面将大多数 Endpoints +在某些场合，应用会创建定制的 Endpoints 资源。为了保证这些应用不需要并发的更改 +Endpoints 和 EndpointSlice 资源，集群的控制面将大多数 Endpoints 映射到对应的 EndpointSlice 之上。 -控制面尝试尽量将 EndpointSlice 填满，不过不会主动地在若干 EndpointSlice 之间 -执行再平衡操作。这里的逻辑也是相对直接的： +控制面尝试尽量将 EndpointSlice 填满，不过不会主动地在若干 EndpointSlice +之间执行再平衡操作。这里的逻辑也是相对直接的： -1. 列举所有现有的 EndpointSlices，移除那些不再需要的端点并更新那些已经 - 变化的端点。 +1. 列举所有现有的 EndpointSlices，移除那些不再需要的端点并更新那些已经变化的端点。 2. 列举所有在第一步中被更改过的 EndpointSlices，用新增加的端点将其填满。 3. 如果还有新的端点未被添加进去，尝试将这些端点添加到之前未更改的切片中， 或者创建新切片。 @@ -403,11 +402,11 @@ 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 创建操作。 +这里比较重要的是，与在 EndpointSlice 之间完成最佳的分布相比，第三步中更看重限制 +EndpointSlice 更新的操作次数。例如，如果有 10 个端点待添加，有两个 EndpointSlice +中各有 5 个空位，上述方法会创建一个新的 EndpointSlice 而不是将现有的两个 +EndpointSlice 都填满。换言之，与执行多个 EndpointSlice 更新操作相比较， +方法会优先考虑执行一个 EndpointSlice 创建操作。 -由于 kube-proxy 在每个节点上运行并监视 EndpointSlice 状态，EndpointSlice 的 -每次变更都变得相对代价较高，因为这些状态变化要传递到集群中每个节点上。 -这一方法尝试限制要发送到所有节点上的变更消息个数，即使这样做可能会导致有 -多个 EndpointSlice 没有被填满。 +由于 kube-proxy 在每个节点上运行并监视 EndpointSlice 状态，EndpointSlice +的每次变更都变得相对代价较高，因为这些状态变化要传递到集群中每个节点上。 +这一方法尝试限制要发送到所有节点上的变更消息个数，即使这样做可能会导致有多个 +EndpointSlice 没有被填满。 -在实践中，上面这种并非最理想的分布是很少出现的。大多数被 EndpointSlice 控制器 -处理的变更都是足够小的，可以添加到某已有 EndpointSlice 中去的。并且，假使无法 -添加到已有的切片中，不管怎样都会快就会需要一个新的 EndpointSlice 对象。 -Deployment 的滚动更新为重新为 EndpointSlice 打包提供了一个自然的机会，所有 -Pod 及其对应的端点在这一期间都会被替换掉。 +在实践中，上面这种并非最理想的分布是很少出现的。大多数被 EndpointSlice +控制器处理的变更都是足够小的，可以添加到某已有 EndpointSlice 中去的。 +并且，假使无法添加到已有的切片中，不管怎样都会快就会需要一个新的 +EndpointSlice 对象。Deployment 的滚动更新为重新为 EndpointSlice +打包提供了一个自然的机会，所有 Pod 及其对应的端点在这一期间都会被替换掉。 -* 阅读[使用服务连接应用](/zh/docs/concepts/services-networking/connect-applications-service/) +* 阅读[使用 Service 连接到应用](/zh/docs/concepts/services-networking/connect-applications-service/)