使用EndpointSlices扩展Kubernetes网络

作者: 罗伯·斯科特(Google)

端点切片是一个令人兴奋的新API,它提供了Endpoints API的可扩展和可扩展的替代方案。 EndpointSlice跟踪支持服务的Pod的IP地址,端口,准备情况和拓扑信息。

在Kubernetes 1.19中,默认情况下启用此功能,并从中读取kube-proxy 端点切片 而不是端点。尽管这将大部分是无形的更改,但它应导致大型群集中的可伸缩性得到显着改善。它还在将来的Kubernetes版本中启用了重要的新功能,例如 拓扑感知路由.

端点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的端点资源。如果该列表中的单个网络端点都发生了更改,则需要将完整的端点资源分配给群集中的每个节点。在具有3,000个节点的大型群集中,这成为一个很大的问题。每次更新将涉及跨集群发送4.5GB数据(1.5MB端点* 3,000个节点)。这几乎足以填满DVD,并且每次端点更改都会发生这种情况。想象一下,如果滚动更新会导致全部5,000个Pod都被替换-传输的数据量超过22TB(或5,000 DVD)。

使用EndpointSlice API拆分端点

EndpointSlice API旨在通过类似于分片的方法来解决此问题。我们没有使用单个Endpoints资源跟踪服务的所有Pod IP,而是将它们拆分为多个较小的EndpointSlice。

考虑一个示例,其中一个服务由15个容器支持。我们最终将获得一个跟踪所有端点的单个Endpoints资源。如果将EndpointSlices配置为每个存储5个端点,则最终将得到3个不同的EndpointSlices: EndpointSlices

By default, 端点切片 store as many as 100 endpoints each, though this can be configured with the --max-endpoints-per-slice flag on kube-controller-manager.

端点切片将可扩展性提高了10倍

该API大大提高了网络可伸缩性。现在,当添加或删除Pod时,只需更新1个小的EndpointSlice。当成百上千的Pod支持单个Service时,这种差异变得非常明显。

可能更重要的是,既然服务的所有Pod IP都不需要存储在单个资源中,那么我们不必担心etcd中存储的对象的大小限制。 端点切片已用于将服务扩展到超过100,000个网络端点。

所有这些都与kube-proxy所做的一些重大性能改进结合在一起。当大规模使用EndpointSlices时,用于端点更新的数据将大大减少,并且kube-proxy应该更快地更新iptables或ipvs规则。除此之外,服务现在可以扩展到至少任何以前的限制的10倍。

端点切片启用新功能

端点切片在Kubernetes v1.16中作为Alpha功能引入,旨在在将来的Kubernetes版本中启用一些令人兴奋的新功能。这可能包括双栈服务,拓扑感知路由和端点子设置。

双栈服务是一项令人兴奋的新功能,已与EndpointSlices一起开发。他们将同时使用IPv4和IPv6地址作为服务,并依靠EndpointSlices上的addressType字段按IP系列跟踪这些地址。

拓扑感知路由将更新kube-proxy,以偏爱同一区域或区域内的路由请求。这利用了为EndpointSlice中的每个端点存储的拓扑字段。作为对此的进一步改进,我们正在探索端点子集的潜力。这将允许kube-proxy只观看EndpointSlices的子集。例如,这可以与拓扑感知路由结合使用,以便kube-proxy仅需监视包含同一区域内端点的EndpointSlice。这将提供另一个非常重要的可伸缩性改进。

这对Endpoints API意味着什么?

尽管EndpointSlice API为Endpoints API提供了更新和更可扩展的替代方案,但是Endpoints API将继续被认为是普遍可用且稳定的。为Endpoints API计划的最重要的更改将涉及开始截断Endpoints,否则将遇到可伸缩性问题。

Endpoints API不会消失,但是许多新功能将依赖于EndpointSlice API。为了利用EndpointSlices提供的新的可伸缩性和功能,当前使用Endpoints的应用程序可能会希望在将来考虑支持EndpointSlices。