EndpointSlices

EndpointSlice API

在 Kubernetes 中，EndpointSlice 包含对一组网络端点的引用。控制平面会自动为具有 selector 指定的 Kubernetes Service 创建 EndpointSlices。这些 EndpointSlices 包括对与 Service selector 匹配的所有 Pod 的引用。EndpointSlices 通过 IP 族、协议、端口号和服务名称的唯一组合将网络端点分组在一起。EndpointSlice 对象的名称必须是有效的 DNS 子域名。

例如，这是一个由 example Kubernetes Service 拥有的 EndpointSlice 对象示例。

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: example-abc
  labels:
    kubernetes.io/service-name: example
addressType: IPv4
ports:
  - name: http
    protocol: TCP
    port: 80
endpoints:
  - addresses:
      - "10.1.2.3"
    conditions:
      ready: true
    hostname: pod-1
    nodeName: node-1
    zone: us-west2-a

默认情况下，控制平面创建和管理 EndpointSlices，每个 EndpointSlice 最多包含 100 个端点。您可以使用 --max-endpoints-per-slice kube-controller-manager 标志配置此值，最高可达 1000。

EndpointSlices 作为 kube-proxy 在如何路由内部流量方面的事实来源。

地址类型

EndpointSlices 支持两种地址类型

• IPv4
• IPv6

每个 EndpointSlice 对象代表特定的 IP 地址类型。如果您的 Service 通过 IPv4 和 IPv6 均可用，则至少会有两个 EndpointSlice 对象（一个用于 IPv4，一个用于 IPv6）。

条件

EndpointSlice API 存储有关端点的条件信息，这些信息可能对使用者有用。这三个条件是 serving、terminating 和 ready。

Serving

serving 条件表示端点当前正在提供响应，因此应将其用作 Service 流量的目标。对于由 Pod 支持的端点，这映射到 Pod 的 Ready 条件。

Terminating

terminating 条件表示端点正在终止。对于由 Pod 支持的端点，当 Pod 首先被删除时（即，当它收到删除时间戳时，但容器很可能在退出之前），会设置此条件。

Service 代理通常会忽略 terminating 端点，但如果所有可用端点都处于 terminating 状态，它们可能会将流量路由到同时处于 serving 和 terminating 状态的端点。（这有助于确保在底层 Pod 的滚动更新期间不会丢失任何 Service 流量。）

Ready

ready 条件本质上是检查“serving 且不 terminating”的快捷方式（尽管对于 spec.publishNotReadyAddresses 设置为 true 的 Service，它始终为 true）。

拓扑信息

EndpointSlice 中的每个端点都可以包含相关的拓扑信息。拓扑信息包括端点的位置以及对应节点和区域的信息。这些信息可在 EndpointSlice 上的以下每个端点字段中获得

• nodeName - 此端点所在的节点名称。
• zone - 此端点所在的区域。

管理

最常见的情况是，控制平面（特别是端点切片 controller）创建和管理 EndpointSlice 对象。还有许多其他 EndpointSlice 的用例，例如服务网格实现，这些用例可能导致其他实体或控制器管理额外的 EndpointSlice 集。

为了确保多个实体可以管理 EndpointSlice 而不会相互干扰，Kubernetes 定义了 label endpointslice.kubernetes.io/managed-by，它指示管理 EndpointSlice 的实体。端点切片控制器将 endpointslice-controller.k8s.io 设置为它管理的所有 EndpointSlice 的此标签的值。其他管理 EndpointSlice 的实体也应为该标签设置一个唯一值。

所有权

在大多数情况下，EndpointSlice 由它跟踪端点的 Service 拥有。这种所有权通过 EndpointSlice 上的所有者引用以及一个 kubernetes.io/service-name 标签指示，该标签可以轻松查找属于 Service 的所有 EndpointSlice。

EndpointSlice 分发

每个 EndpointSlice 都有适用于资源内所有端点的端口集。当 Service 使用命名端口时，Pod 最终可能会为同一个命名端口获得不同的目标端口号，从而需要不同的 EndpointSlice。

控制平面尝试尽可能地填充 EndpointSlice，但不主动重新平衡它们。逻辑相当简单

1. 迭代现有的 EndpointSlice，删除不再需要的端点并更新已更改的匹配端点。
2. 迭代第一步中修改过的 EndpointSlice，并用任何需要的新端点填充它们。
3. 如果仍然有新的端点需要添加，请尝试将它们放入以前未更改的切片中和/或创建新的切片。

重要的是，第三步优先考虑限制 EndpointSlice 更新，而不是完美地填充 EndpointSlice 分布。例如，如果有 10 个新的端点要添加，并且 2 个 EndpointSlice 具有 5 个可用端点的空间，则此方法将创建一个新的 EndpointSlice，而不是填充 2 个现有的 EndpointSlice。换句话说，单个 EndpointSlice 创建优于多个 EndpointSlice 更新。

由于 kube-proxy 在每个节点上运行并监视 EndpointSlice，因此 EndpointSlice 的任何更改都变得相对昂贵，因为它将被传输到集群中的每个节点。这种方法旨在限制需要发送到每个节点的更改数量，即使这可能会导致多个未完全填充的 EndpointSlice。

在实践中，这种不太理想的分布应该很少见。EndpointSlice 控制器处理的大多数更改都足够小，可以放入现有的 EndpointSlice 中，如果不能，那么很快就需要一个新的 EndpointSlice 了。部署的滚动更新也为所有 Pod 及其相应的端点提供了一种自然的 EndpointSlice 重打包方式。

重复端点

由于 EndpointSlice 更改的性质，端点可能在同一时间出现在多个 EndpointSlice 中。这自然发生在不同 EndpointSlice 对象的更改以不同的时间到达 Kubernetes 客户端监视/缓存时。

EndpointSlice 镜像

EndpointSlice API 是较旧的 Endpoints API 的替代品。为了与期望 kube-proxy 基于 Endpoints 资源路由流量的旧控制器和用户工作负载保持兼容，集群的控制平面会将大多数用户创建的 Endpoints 资源镜像到相应的 EndpointSlice。

(但是，此功能与 Endpoints API 的其余部分一样，已被弃用。手动为无选择器 Service 指定端点的用户应直接创建 EndpointSlice 资源，而不是创建 Endpoints 资源并允许它们被镜像。)

控制平面会镜像 Endpoints 资源，除非

• Endpoints 资源具有设置为 true 的 endpointslice.kubernetes.io/skip-mirror 标签。
• Endpoints 资源具有 control-plane.alpha.kubernetes.io/leader 注解。
• 相应的 Service 资源不存在。
• 相应的 Service 资源具有非空的 selector。

单个 Endpoints 资源可能会转换为多个 EndpointSlice。如果 Endpoints 资源具有多个子集或包含具有多个 IP 族（IPv4 和 IPv6）的端点，则会发生这种情况。每个子集最多将镜像 1000 个地址到 EndpointSlice。

接下来

• 请遵循 使用 Service 连接应用程序 教程
• 阅读 API 参考 以了解 EndpointSlice API
• 阅读 API 参考 以了解 Endpoints API