Kubernetes — the standardization platform
While Kubernetes brings many new aspects to any infrastructure, one of it is always the hidden champion: standardization.
What doesn’t fit into the Kuberverse has a hard time to be adapted, but if so, you can be sure it follows the Kubernetes and cloud native paradigms. What I often observe in my projects is the point of realization when the users understand how seamlessly enhancing features play together and build on each other. Adopting Kubernetes looks like a massive overhead driver, and it can be, yet, the new capabilities it enforces typically outperform the additional effort.
This all plays so well together because of standardization.
Kubernetes API — gatekeeper, control power and bottleneck
At the Kubernetes API, many things come together; objects, verbs, resource types and their URIs. What doesn’t exist in this model can’t be handled, so if it exists, it follows a specific schema.
Now, it is not very precise to say that the API of Kubernetes does everything. Looking into the details, you must be aware of different components within Kubernetes, which communicate with each other over an event-driven pattern. For me, it was an eye-opening moment when I understood that every component (scheduler, controller, API, etc.) is writing a continuous stream of events into the etcd database and, at the same time, are reading all of the relevant events to react on them potentially.
However, to make this work, everything that wants to live within Kubernetes, also needs to adhere to these specifications. This standardization is loved by many and not understood by many more. But it is the secret sauce of why we see so many different solutions utilizing each other, even though they are unaware of each other.
Looking into the slightly escalated landscape around Kubernetes, you will clearly understand that this is a success model.
Build on what you get with Custom Resource Definitions
So what do you do if you want to create something new either for a new open source project or just for your internal application? You can define your very own Custom Resource Definition (CRD), which leverages the given schema and allow you to bring into Kubernetes your own new resource, which ultimately could be (theoretically) understood by random other projects built on Kubernetes too.
With a CRD and your controller/operator, you can create a new component that lives and breathes Kubernetes. It can be integrated and read the same event streams as other components do. From here, only your imagination is the limit. Sounds like much effort? I have already seen dozens of such integrations; whether they made sense or not, you can get them up and running quite fast due to some frameworks that help you get things started.
Creating your project on/in Kubernetes needs two simple pieces: a CRD definition, which is a simple yaml file and a controller, typically in the form of an operator, which reacts on any trigger you have defined.
How about a resource that reboots your cluster whenever some clap on your medium article?
The surrounding ecosystem gets standardized too
Due to its loosely coupled nature, it is not enough to have that high level of standardization only within Kubernetes. Further essential parts that can fully mass up your clusters agreed on standards for themself.
This ensures interoperability, exchangeability and stability. Yet, there is often the concern that because of standardization, further development and innovation will slow down. But for some reason, this isn’t the case for projects in the Kuberverse. Whether we are talking about:
- the Open Container Initiative (OCI), which specifies how container formats and runtimes have to look like
- the Container Network Interface (CNI), which implements networking for containers
- the Service Mesh Interface (SMI), providing a specification of the most common service mesh use cases for traffic policies, telemetry and management
- the Container Runtime Interface (CRI), tells how to implement container runtimes and enables the kublet to plugin various different runtimes
- the Container Storage Interface (CSI), which tells how to implement storage solutions into a container orchestration platform
None of them slowed down the development, I even would say they gave a new momentum to it.
Every one of those specifications, definitions and clarifications allows new tools to adopt fast and give the chance to existing solutions, like the different storage technologies, to seamlessly integrate with Kubernetes, without re-inventing their core technology. And so providing you the same trustful experience you had so far.
Whether you like that term or not, Kubernetes is a trend (standards) setter for the good and the bad.
Adopting Kubernetes means changing how to implement your systems, which is a challenge for most of your teams and will take time.
But the ecosystem of Kubernetes does everything possible to provide a safe, reliable and universal environment and platform, to build platforms and applications. In fact, if I look back to where we come from, we never had something similar, not in homogeneous nor heterogeneous system landscapes.
That’s why I build on this cloud native ecosystem.
