共计 2472 个字符，预计需要花费 7 分钟才能阅读完成。
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)
译者：刘博（资深云计算售前架构师）
