How does the EndpointSlice improve efficiency over the old Endpoint resource?

General Discussions
1

The original Endpoint had one resource per Service and all the endpoints (ports) of a service were tracked by this resource. This caused issues with scalability as the cluster and services grew.

With the new EndpointSlice, there is an EndpointSlice resource per endpoint per service. I am wondering how does this solve the scalability issue? Each pod in a service supports all the ports (endpoints) opened by the service. That said, won’t each pod find a reference entry in each of the endpointSlice related to that service? Will that not require simultaneous update of multiple EndpointSlice resources every time there is a change in the pod (new addition or deletion)?

Example: Say there is a Service A. It has got 3 pods P1, P2, P3. The Service A has 3 open ports (endpoints). Now each of the pods support these endpoints. So if we are to create one EndpointSlice resource per service, per endpoint (port), then we will have 3 EndpointSlice resources ES1, ES2 and ES3 for the Service A corresponding to each of its endpoints.
Now since each of the pods P1, P2and P3 support all 3 endpoints each of the EndpointSlice ES1, ES2 and ES3 will have a reference to each of the pod’s IP address and port. So in case there is a newly adde pod (with new IP address ofcourse) oran existing pod gets replaces, would these events not require update of all 3 endpoint slice resources? Will this not be more work than before?
How does this improve scalability exactly?

If I am misunderstanding some concept, please let me know. Thank you.

2

You should read the EndpointSlice KEP. https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/20190603-endpointslices

There are a number of reasons but 2 stand out.

  1. there’s a limit to how big any one object can be, and some users hit that limit with Endpoints. EndpointSlice is n:1 with services.

  2. every update to any endpoint in an Endpoints sends the entire Endpoints object to every listener, and we have at least 1 listener per node. Consider a 1000 node cluster and a service with 1000 Endpoints. Each endpoint a couple hundred bytes, let’s call it 100 but that is low. That Endpoints object is 100 kB. A rolling update will send 1000 updates of 100kB each (100Mb) to each of 1000 nodes (100GB). The apiserver is already under pressure, this makes it much worse. EndpointSlice only sends a fraction of the total on each update, and leaves room for further optimization.

Tim

1 Like
3

Thanks @thockin for the explanation and sharing the documentation.

4

In this context, a single pod is a single endpoint, regardless of how many ports.