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)
译者:刘博(资深云计算售前架构师)
利用EndpointSlices扩展Kubernetes网络,提供更强的可伸缩性和功能
最新推荐文章于 2024-04-02 14:47:05 发布