Kubernetes Is Not Just About Containers — It’s About the API
“Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation.”
That statement might have been a good description when the project started. Today, the situation is very different, although not necessarily in an obvious way. Kubernetes is not used to manage only containerized workloads and services. We can use Kubernetes to manage virtual machines, through projects like KubeVirt. We can use ORKA to manage macOS machines and applications. Kubernetes has been creating and managing external load balancers through Services for a while now. The list of the types of resources that Kubernetes manages is increasing, so we cannot say anymore that it is a platform for managing containerized workloads and services. So, if that’s not it, what is it? Or, to be more precise, what is the main feature Kubernetes gives us?
Kubernetes is all about the API and its ability to receive events and to have controllers that listen to those events.
The API itself was designed to be extensible, and it is becoming universal. Those are the main reasons why projects like KubeVirt and ORKA chose Kubernetes to manage things that are not containers. They did that mostly because of the capabilities of Kubernetes API, and the general need users have for a common API that can manage (almost) everything.
If the Kubernetes API is becoming the de-facto standard, it is interesting to think about what that might mean for us today or in the near future. Generally speaking, we need to manage infrastructure and applications running on top of it. Those are the two main areas that the Kubernetes API can cover.
As far as applications are concerned, two things are becoming apparent. We are adopting (or have already adopted) immutability, which means that the prevalent way to package our applications is images. We need processes that will convert those images into containers, VMs, or whichever other runtime format we might use; then figure out where is the most optimum place to run them and make sure that the desired state is maintained at (almost) all times. That chapter of the story is finished. Even though we will continue seeing significant improvements in this area, it will likely be based on usability rather than the primary goals.
Right now, the more exciting aspect is infrastructure.
If the Kubernetes API is becoming universal and de-facto standard, it stands to reason that we should leverage it not only for applications but also for infrastructure. That is, I believe, the next frontier. Bringing infrastructure management into the Kubernetes API will convert it into a truly universal de-facto standard.
One might say that “using Kubernetes API to manage our infrastructure is not a good enough reason to switch away from our favorite tool.” However, that would be shortsighted, because that same API is the main aspect that contributed to having the biggest ecosystem ever created. A significant percentage of innovation today is centered around Kubernetes. Most projects were converted to work inside of Kubernetes. The majority of those made during the last couple of years were designed specifically to take the advantages we get from running inside Kubernetes and utilizing its API. As a result, the projects that would be designed to manage our infrastructure utilizing the Kubernetes API would allow us to use the same API for everything; and so leverage better than others the ecosystem we have around Kubernetes.
The closest candidate we have for a tool that would act as Infrastructure-as-Code (IaC) leveraging the power behind Kubernetes API is Crossplane. We can manage it through our favorite tools, like Helm or Kustomize. If we want to use it following GitOps principles, we could combine it with Argo CD or a similar tool. If, instead, we would like to trigger pipeline builds whenever we change the definitions stored in Git, we could use one of the Kubernetes-native solutions — like Codefresh. Or, if we would like to monitor how it behaves, we could fetch metrics from Prometheus.
Can we do all those and many other things with Infrastructure-as-Code (IaC) tools that were not designed to leverage the Kubernetes API? We certainly can. But, in those cases, we are not getting all the benefits Kubernetes provides. Whether Crossplane will be the next big solution for managing infrastructure is yet to be seen. Nevertheless, once we do get to a place where the Kubernetes API is widely used to manage both applications and infrastructure, it will become a universal API for (almost) everything. That day is coming because we are all adopting Kubernetes — not because it runs containers, but because of its API.
