EndpointSlices是一个令人兴奋的新API，它提供了Endpoints API的可扩展和可扩张的替代方案。EndpointSlice跟踪Pod服务后面的IP地址，端口，准备情况和拓扑信息。
在Kubernetes(https://www.alauda.cn/product/detail/id/240.html) 1.19中，默认情况下从EndpointSlices中通过kube-proxy读取启用了此功能，而非Endpoints。尽管这个更改看起来不起眼，但它可以使大型群集中的可伸缩性得到显著改善。它还在将来的Kubernetes版本中启用了重要的新功能，例如拓扑路由感知。
1 Eendpoints API的可扩展性限制
使用Endpoints API，一个服务只有一个Endpoints资源。这意味着它需要为支持相应服务的每个Pod存储IP地址和端口（网络端点）。这导致使用巨大的API资源。为了解决此问题，kube-proxy在每个节点上运行，并监视Endpoints资源的任何更新。如果在Endpoints资源中甚至只有一个网络端口发生更改，则整个对象也必须发送到每个实例的kube-proxy。
Endpoints API的另一个限制是，它限制了可以为服务跟踪的网络端点的数量。存储在etcd中的对象的默认大小限制为1.5MB。在某些情况下，这可能会将Endpoints资源限制为5,000个Pod IP。对于大多数用户而言，这不是问题，但是对于服务接近此大小的用户而言，这将成为一个重大问题。
为了说明这些问题的严重性，举一个简单的例子是有帮助的。考虑具有5,000个Pod的服务，它最终可能具有1.5MB的Endpoints资源。如果该列表中的单个网络Endpoints都发生了更改，则将需要将完整的Endpoints资源分配给群集中的每个节点。在具有3,000个节点的大型群集中，这成为一个很大的问题。每次更新将涉及跨集群发送4.5GB数据（1.5MB Endpoints * 3,000个节点）。这几乎足以填满DVD，并且每次Endpoints更改都会发生这种情况。想象一下，如果滚动更新会导致全部5,000个Pod都被替换-传输的数据量超过22TB（或5,000 DVD）。
2 使用EndpointSlice API拆分端点
EndpointSlice API旨在通过类似于分片的方法来解决此问题。我们没有使用单个Endpoints资源跟踪服务的所有Pod IP，而是将它们拆分为多个较小的EndpointSlice。
考虑一个示例，其中一个服务后端有15个Pod。我们最终将获得一个跟踪所有端点的单个Endpoints资源。如果将EndpointSlices配置为每个存储5个端点，我们最终将获得3个不同的端点EndpointSlices：
默认情况下，EndpointSlices每个存储多达100个端点，尽管可以使用kube-controller-manager上的--max-endpoints-per-slice标志进行配置。EndpointSlices将可扩展性提高了10倍。该API大大提高了网络可伸缩性。现在，当添加或删除Pod时，只需更新1个小的EndpointSlice。当单个Service有成百上千的Pod时，这种差异变得非常明显。
可能更重要的是，既然服务的所有Pod IP都不需要存储在单个资源中，那么我们就不必担心etcd中存储的对象的大小限制。EndpointSlices已用于将服务扩展到超过100,000个网络端点。
所有这些都与kube-proxy所做的一些重大性能改进结合在一起。当大规模使用EndpointSlices时，用于端点更新的数据将大大减少，并且kube-proxy应该更快地更新iptables或ipvs规则。除此之外，服务现在可以扩展到至少任何以前的限制的10倍。
3 EendpointSlices启用新功能
作为Kubernetes(https://www.alauda.cn/product/detail/id/240.html) v1.16中的alpha功能引入的EndpointSlices旨在在将来的Kubernetes版本中启用一些令人兴奋的新功能。这可能包括双栈服务，拓扑路由感知和端点子设置。
双栈服务是一项与EndpointSlices一起开发的令人兴奋的新功能。他们将同时使用IPv4和IPv6地址作为服务，并依靠EndpointSlices上的addressType字段按IP系列跟踪这些地址。
拓扑感知路由将更新kube-proxy，以在同一区域或区域内完成路由请求。这利用了为EndpointSlice中的每个端点存储的拓扑字段。作为对此的进一步改进，我们正在探索端点子集的潜力。这将允许kube-proxy只观看EndpointSlices的子集。例如，这可以与拓扑路由感知结合使用，以便kube-proxy仅需监视包含同一区域内端点的EndpointSlice。这将提供另一个非常重要的可伸缩性改进。
4 这对Endpoints API意味着什么?
尽管EndpointSlice API为Endpoints API提供了更新和更可扩展的替代方案，但是Endpoints API将继续被认为是普遍可用且稳定的。为Endpoints API计划的最重要的更改将涉及开始截断Endpoints，否则将遇到可伸缩性问题。
Endpoints API并没有消失，但是许多新功能将依赖于EndpointSlice API。为了利用EndpointSlices提供的新的可伸缩性和功能，当前使用Endpoints的应用程序可能在将来考虑支持EndpointSlices。
原文链接：
Scaling Kubernetes Networking With EndpointSlices
https://kubernetes.io/blog/202 ... ices/
作者: Rob Scott(Google)
译者：刘博（资深云计算售前架构师）