Kubernetes is comprised of a variety of components, yet most end-user interaction with the system flows through the API Server. It is the entrypoint to many of the features that the project has built up over its lifetime, and can be extended to support arbitrary additional functionality. Because of this, the API Server has proved to be a bottleneck in some cases that it was not originally designed to accommodate, or at least accommodate well.
Much of the time when the Kubernetes API Server is not behaving as we expect, especially when it comes to performance, understanding why the system is exhibiting undesirable behavior can be challenging. Though we have access to the source code of the project, navigating it and determining which code paths are being exercised may not be straightforward. Like most complex systems, breaking the code down into smaller components, then building them back up to form the complete picture helps us not only be able to pinpoint where the system is failing much quicker, but also allows us to modify and substitute components to fit our use case.
In this new series, Kubernetes API Server Adventures (“k8s ASA”), we’ll dive into all parts of the API Server, gaining an understanding of how they work, and what other components they interact with. Along the way we’ll experiment with substituting our own components, building tooling, and looking at how other folks have modified it to fit their use cases. Who knows, we might even build our own. 👀