作者: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 扩展 Kubernetes 网络_第1张图片

默认情况下,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/