作者：Rob Scott
翻译：Bach（才云）
校对：星空下的文仔（才云）、bot（才云）
EndpointSlice 是一个新 API，它提供了 Endpoint API 可伸缩和可拓展的替代方案。EndpointSlice 会跟踪 Service Pod 的 IP 地址、端口、readiness 和拓扑信息。
在 Kubernetes v1.19 中，此功能将默认启用：从 EndpointSlice （不是 Endpoint）中读取 kube-proxy。尽管这个更改看起来并不起眼，但实际上它能让大型集群的可伸缩性得到显着提高。另外，它还与 Kubernetes 未来版本中的重要新功能有关，例如 Topology Aware Routing。
K8sMeetup
Endpoint API 可伸缩性限制
如果使用 Endpoint API，Service 只有一个 Endpoint 资源。这意味着它需要为 Service 的每个 Pod 都存储好 IP 地址和端口（网络端点），这需要大量的 API 资源。另外，kube-proxy 会在每个节点上运行，并监控 Endpoint 资源的任何更新。如果 Endpoint 资源中有一个端口发生更改，那么整个对象都会分发到 kube-proxy 的每个实例。
Endpoint API 另一个局限是，它会限制跟踪 Service 的网络端点数量。一般存储在 etcd 中的对象默认大小限制为 1.5MB。在某些情况下，它会将 Endpoint 资源限制为 5000 个 Pod IP。对于大多数用户而言，这没什么关系，但是对于接近这个大小的 Service 而言，就有大问题了。
为了说明这些问题的严重程度，这里举一个简单的例子。如果一个 Service 有 5000 个 Pod，它如果有 1.5MB 的 Endpoint 资源。当该列表中的某个网络端点发生了变化，那么就要将完整的 Endpoint 资源分发给集群中的每个节点。在具有 3000 个节点的大型集群中，这会是个很大的问题。每次更新将跨集群发送 4.5GB 的数据（1.5MB3000，即 Endpoint 大小 节点个数），并且每次端点更新都要发送这么多数据。想象一下，如果进行一次滚动更新，共有 5000 个 Pod 全部被替换，那么传输的数据量将超过 22 TB。
K8sMeetup
EndpointSlice API 拆分 Endpoint
EndpointSlice API 旨在通过类似于分片的方法来解决该问题。我们不跟踪 Service Pod IP 的单个 Endpoint 资源，而是将它们拆分为多个较小的 EndpointSlice。
举个例子，现在有 15 个 Pod 在支持一个 Service，那么就有跟踪这些的一个 Endpoint 资源。如果将 EndpointSlice 配置为每个 EndpointSlice 存储 5 个端点，就得到了 3 个不同的 EndpointSlice：
默认情况下，EndpointSlice 每个存储能多达 100 个端点，我们可以使用 kube-controller-manager 的 --max-endpoints-per-slice 标签进行配置。
K8sMeetup
EndpointSlice 提升 10 倍可伸缩性
EndpointSlice API 大大提高了网络的可伸缩性，因为现在添加或删除 Pod 时，只需更新 1 个小的 EndpointSlice。尤其是成百上千个 Pod 支持单个 Service 时，差异将非常明显。
更重要的是，既然 Service 的所有 Pod IP 都不需要存储在单个资源中，那么我们就不必担心 etcd 中存储对象的大小限制。EndpointSlice 可以用于扩展到超过 10 万个网络端点的 Service。
当这些与 kube-proxy 的一些重大性能改进结合在一起后，再大规模地使用 EndpointSlice 时，用于端点更新的数据将大大减少，kube-proxy 还可以更快更新 iptables 和 ipvs 规则。这样，Service 现在的可伸缩性能达到以前的至少 10 倍。
K8sMeetup
EndpointSlice 有关新功能
作为 Kubernetes v1.16 中的 alpha 功能引入的 EndpointSlice 在 Kubernetes 未来版本中，会和一些令人兴奋的新功能有关，例如 dual-stack Service、topology aware routing 和 endpoint subsetting。
Dual-stack Service 是一项与 EndpointSlice 一起开发的新功能。它们利用 IPv4 和 IPv6 地址提供 Service，并依靠 EndpointSlice 上的 addressType 字段按 IP 系列跟踪这些地址。
Topology aware routing 会更新 kube-proxy 以 prefer 同一区域或区域内的路由请求。这使用了为 EndpointSlice 端点存储的拓扑字段。另外，目前还在探索 endpoint subsetting 的潜力，未来 kube-proxy 将只允许观察 EndpointSlice 的子集。这可以与 topology aware routing 结合使用，这样 kube-proxy 只需要监控包含同一区域内端点的 EndpointSlice，这将提供另一个非常显着的可伸缩性改进。
K8sMeetup
这对 Endpoint API 意味着什么？
尽管 EndpointSlice API 为 Endpoint API 提供了更强伸缩性的替代方案，但是 Endpoint API 目前还被认为是普遍可用且稳定的选择。Endpoint API 最重要的更改计划需要包括 truncate Endpoint，否则肯定会遇到可伸缩性问题。
Endpoint API 不会就此消失，但许多新功能会依赖于 EndpointSlice API。为了利用 EndpointSlice 提供的可伸缩性和新功能，当前在使用 Endpoint 的应用程序可能会在未来考虑使用 EndpointSlice。
原文地址：https://kubernetes.io/blog/2020/09/02/scaling-kubernetes-networking-with-endpointslices/