原始端点的每个服务都有一个资源，服务的所有端点(端口(都由此资源跟踪。随着群集和服务的增长，这会导致可伸缩性出现问题。
使用新的 EndpointSlice，每个服务的终结点都有一个 EndpointSlice 资源。我想知道这如何解决可扩展性问题？服务中的每个 Pod 都支持该服务打开的所有端口(端点(。也就是说，每个 Pod 不会在每个与该服务相关的 endpointSlice 中找到引用条目吗？这是否不需要在每次容器中发生更改(新添加或删除(时同时更新多个 EndpointSlice 资源？
示例：假设有一个服务 A。它有3个豆荚P1，P2，P3。服务 A 有 3 个开放端口(终结点(。现在，每个 Pod 都支持这些终结点。因此，如果我们要为每个服务、每个端点(端口(创建一个 EndpointSlice 资源，那么我们将为服务 A 提供 3 个 EndpointSlice 资源 ES1、ES2 和 ES3，对应于其每个端点。 现在，由于每个 Pod P1、P2 和 P3 都支持所有 3 个端点，因此每个 EndpointSlice ES1、ES2 和 ES3 都将引用每个 Pod 的 IP 地址和端口。因此，如果有一个新添加的 pod(当然具有新的 IP 地址(或现有 Pod 被替换，这些事件是否不需要更新所有 3 个端点切片资源？这不会比以前工作更多吗？ 这究竟如何提高可扩展性？
每个服务只有一个endpointslice对象。因此，在您的示例中，只有一个endpointslice对象将具有所有 3 个 pod ip 和端口，它将通过唯一的service和port组合将网络endpoints分组在一起。
在此处阅读有关早期终结点对象面临的问题类型的详细信息。
官方 KEP 讨论了端点和端点切片 API 之间的一些性能比较。
前面的终结点对象如下所示
Subsets:
Addresses: 192.168.238.108,192.168.238.109,192.168.238.110
如您所见，服务的端点对象包含该服务的所有单个端点。因此，每当添加/更新/删除服务中的单个 Pod 时，整个端点对象(甚至包括其他未更改的端点(都会重新计算、写入存储并发送到所有读取器。
新的终结点切片对象如下所示
Ports:
Name Port Protocol
---- ---- --------
http-queueadm 8022 TCP
http-autometric 9090 TCP
http-usermetric 9091 TCP
http 8012 TCP
Endpoints:
- Addresses: 192.168.238.108
Conditions:
Ready: true
Hostname: <unset>
TargetRef: Pod/helloworld-go-rk4j8-deployment-588ccc679b-4spkx
Topology: kubernetes.io/hostname=ip-10-0-0-92
- Addresses: 192.168.238.110
Conditions:
Ready: true
Hostname: <unset>
TargetRef: Pod/helloworld-go-rk4j8-deployment-588ccc679b-tdq24
Topology: kubernetes.io/hostname=ip-10-0-0-92
- Addresses: 192.168.238.109
Conditions:
Ready: true
Hostname: <unset>
TargetRef: Pod/helloworld-go-rk4j8-deployment-588ccc679b-bfxb8
Topology: kubernetes.io/hostname=ip-10-0-0-92
如您所见，端点是分组的，因此当发生变化时，即添加/更新/删除服务中的单个 pod，只能更新相关组，而不是更新整个对象，从而提高性能。