使用 EndpointSlice 扩展 Kubernetes 网络

在 Kubernetes v1.19 中，此功能将默认启用：从 EndpointSlice （不是 Endpoint）中读取 kube-proxy。尽管这个更改看起来并不起眼，但实际上它能让大型集群的可伸缩性得到显着提高。另外，它还与 Kubernetes 未来版本中的重要新功能有关，例如 Topology Aware Routing。

如果使用 Endpoint API，Service 只有一个 Endpoint 资源。这意味着它需要为 Service 的每个 Pod 都存储好 IP 地址和端口（网络端点），这需要大量的 API 资源。另外，kube-proxy 会在每个节点上运行，并监控 Endpoint 资源的任何更新。如果 Endpoint 资源中有一个端口发生更改，那么整个对象都会分发到 kube-proxy 的每个实例。

EndpointSlice API 旨在通过类似于分片的方法来解决该问题。我们不跟踪 Service Pod IP 的单个 Endpoint 资源，而是将它们拆分为多个较小的 EndpointSlice。

默认情况下，EndpointSlice 每个存储能多达 100 个端点，我们可以使用 kube-controller-manager 的 --max-endpoints-per-slice 标签进行配置。

EndpointSlice API 大大提高了网络的可伸缩性，因为现在添加或删除 Pod 时，只需更新 1 个小的 EndpointSlice。尤其是成百上千个 Pod 支持单个 Service 时，差异将非常明显。

作为 Kubernetes v1.16 中的 alpha 功能引入的 EndpointSlice 在 Kubernetes 未来版本中，会和一些令人兴奋的新功能有关，例如 dual-stack Service、topology aware routing 和 endpoint subsetting。

Topology aware routing 会更新 kube-proxy 以 prefer 同一区域或区域内的路由请求。这使用了为 EndpointSlice 端点存储的拓扑字段。另外，目前还在探索 endpoint subsetting 的潜力，未来 kube-proxy 将只允许观察 EndpointSlice 的子集。这可以与 topology aware routing 结合使用，这样 kube-proxy 只需要监控包含同一区域内端点的 EndpointSlice，这将提供另一个非常显着的可伸缩性改进。

尽管 EndpointSlice API 为 Endpoint API 提供了更强伸缩性的替代方案，但是 Endpoint API 目前还被认为是普遍可用且稳定的选择。Endpoint API 最重要的更改计划需要包括 truncate Endpoint，否则肯定会遇到可伸缩性问题。