共计 2438 个字符，预计需要花费 7 分钟才能阅读完成。
作者：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://mp.weixin.qq.com/s/KRlvrth1X5ZaOukW9HxDVA
