Slice up Your API with Kubernetes EndpointSlices for Cluster Network Bottlenecks

Kubernetes has a lot of tricks up its sleeve. In fact, said shirt was tailored for an octopus, so it has six sleeves, each filled with a bevy of tricks. And with each new release, there are new features to delight and amaze developers.

Of course, along with those numerous features comes a level of difficulty not found in other technologies currently being employed by businesses across the globe. The developers of Kubernetes understand how challenging their container orchestrator is. As well, they are very keen on making sure Kubernetes does the one thing businesses demand of it — scale. To that end, they go to great lengths to bring about features that will ease the difficulties when deployed at scale.

One such feature is EndpointSlices.

What are EndpointSlices?

In simplest terms, EndpointSlices make it possible (and simple) to track network endpoints within a Kubernetes cluster.

Hold up. What are endpoints?

Within the realm of Kubernetes, an endpoint is any object that gets IP addresses of individual pods assigned to it. That endpoint is then referenced by a Kubernetes service, such that the service holds a record of the internal IP addresses of the pods so that communication can occur. Pods expose themselves to a service, via endpoints.

Endpoints are necessary to serve as an abstraction layer, in order to make it possible for a Kubernetes service to ensure distribution of traffic to pods.

Problem is, as Kubernetes has grown more complex, it is now required to send more and more traffic to backend Pods. As this evolution occurred, the limitations of the original Endpoints API have been revealed. The biggest issue was that of scaling.

Because all network endpoints for each service was stored in a single Endpoint, those resources could grow to an unacceptable size, which had a negative effect on Kubernetes performance. In other words, as your network endpoints grew more numerous, your ability to scale your deployments was impacted.

To mitigate that problem, EndpointSlices was created.

What’s the Problem?

Consider this: The more you scale, the harder things get. And, as we’ve explained, one aspect of Kubernetes that doesn’t scale well is Endpoints. But imagine you’ve deployed a Service that sits before a large number of Pods. Your Service includes an Endpoints object that houses both the IP address and port number of every one of those Pods.

Here’s where the problem occurs: Every time you add or remove a Pod from the Service, the entire Endpoints object gets updated and is sent across the network to every node. When that Endpoint object is at scale, the traffic caused by this places those nodes under a massive load.

That’s where EndpointSlices comes into play.

Instead of using that Endpoints object (containing an ever-growing amount of IP addresses and port number), as of Kubernetes v1.17 (beta), it’s cut up into smaller slices (hence the name). Those slices (being smaller in nature) help to mitigate the load caused by very large Endpoints objects. To be specific (at least as of v1.17), each Endpoint “Slice” will house the network details for up to 100 Pods. That’s the limit.

How does that work in real time? Say you have your Service deployment that contains a massive amount of Pods. Should you delete one of those Pods, Kubernetes will only re-cut the slice that contains details about that Pod. When the slice updates across the network, it will only contain information for, you guessed it, up to 100 Pods, so the cluster network isn’t choked.

In the end, your deployments will enjoy:

• Lower network traffic.
• Less labor placed on nodes and the control plane.
• Better performance and reliability at scale.

How EndpointSlices Is Implemented

EndpointSlices is worked into your manifests, using the kind declaration like so:

By default, the control plane will ensure the EndpointSlices will have no more than 100 endpoints each. However, you can specify this amount, using the –max-endpoints-per-slice flag (used with the Kubernetes controller manager daemon), up to 100 endpoints.

A sample EndpointSlice resource looks like this:

Conclusion

If you work with Kubernetes at scale, EndpointSlices just might be the best thing to happen to Kubernetes since BreadSlices. Remember, however, this feature is still in beta. If you’d like to learn more about this exciting inclusion to the world of scalable Kubernetes, check out the official EndpointSlices information page.

Feature image by CHUTTERSNAP on Unsplash.