It is a common misconception that Kubernetes is a container orchestrator, after-all the website describes it as:
open-source system for automating deployment, scaling, and management of containerized applications
While this description may be correct, it fails to capture Kubernetes’ true essence.
Kubernetes’ ascension can be more readily explained by the amazing and passionate community that has developed, not for its container orchestration prowess, but for some of the following reasons:
Kubernetes decouples the definition of an application, from how it is deployed. Never before have developers had this common language to describe their applications that is portable to different teams, companies and even clouds.
20 years from now, we may not be using the Kubernetes codebase, but we will almost certainly be using its declarative model for defining applications.
At it’s core Kubernetes is an enterprise-ready, programmable hierarchical control system that consists of dozens of closed feedback loops. These work together to create a system that, while complex at first glance, is transparent, consistent and elegantly simple once you understand the underlying theory.
To learn more about control theory see:
Kubernetes is perhaps one of the few truly open systems. Where else do you get all the major cloud providers, vendors and end-users all collaborating together for a common purpose?
Linux is the next closest open system. However, while there is a lot of collaboration upstream, most of the value is delivered in forked kernels that are maintained by each vendor.
This makes compatibility between vendors possible, not guaranteed in the way Kubernetes is withfree conformance tests.
Governance is usually a synonym for red-tape that slows things down, while not adding much value. The Kubernetes Governance Model is refreshingly different. It’s designed to respect Conway’s Law, pushing decision making down to the people with the most knowledge, while at the same time providing democratically elected steering that keeps the massive ship sailing in the right direction.
As Kubernetes matures, the governance model has adapted to its current form, in which it heavily encourages de-coupling of new work into sub-projects owned by Special Interest Groups (SIGs).
Members of the Kubernetes community have a hierarchy with each level providing different rights - predominantly, the differences lie in who can approve code for merging.
Promotion in the hierarchy is based not on seniority or vendor affiliation, but rather on a democratic process of rewarding people for chopping wood and carrying water - doing the jobs that need doing, not just thefun work.
With the scale at which Kubernetes operates, it is amazing to see the level and quality of communication that prevails. Kubernetes certainly didn’t invent any of these techniques, but it certainly has done a fantastic job of implementing them.
The first thing you notice about the kubernetes communication model is that everything is a pull request or an issue:
The #kubernetes-users slack channel has close to 90k members, making it one of the largest if not the largest channel in the world. Does your company have a slack channel for everyone?
There are dozens of scheduled meetings across all the SIGs and Working Groups (WG) every month. What makes these meetings unique is that they are open to anyone, recorded and published to YouTube with concise minutes that are shared in a public Google doc.
As projects grow, RFP’s become essential to maintaining stability, consistency and speed. Kubernetes Enhancements Proposals (KEPs) have been great at communicating and coordination change, with them even being adopted by projects like kafka.
Kubernetes is a community solving distributed problems, both technical and procedural