Kubernetes is NOT Scary, Complex or Even Confusing
For the last several months, I’ve been working with the Kubernetes Cluster Ops SIG to create an Operators’ Guide. The first deliverables for that guide, the graphics shown above, have been helping us to show that Kubernetes is really a pretty simple architecture.
We’re doing this work to correct a common misconception about the complexity of Kubernetes. The platform is really very elegant with relatively few moving parts. If that is true, what feeds this the fiction of Kubernetes complexity?
Unlike the platform itself, the routine pre-requisite tasks needed to build a Kubernetes cluster are complex and hard.
Those were the tasks that made Kelsey Hightower’s “Kubernetes the Hard Way” setup guide actually hard. It’s developers lack of exposure and patience in common cluster operations tasks like creating a secure communication (TLS), configuring load balancers, running daemon services and other environment prep tasks that lead to this perception. In fact, the rise of Docker is the rebellion against this type of work!
Multi-node operations is hard: that’s why we want platforms like Kubernetes.
There are few short-cuts for multi-node operational tasks like building a public key infrastructure (PKI), load balancer configuration, installing Docker correctly, configuring services in systemd or upstart, and creating a functional software defined network. And that does not even consider sequence sensitive tasks like expanding or upgrading a cluster. Since the Kubernetes will not work without all this heavy lifting, it’s no wonder that a simple three tier platform gets a reputation as complex.
One complicating factor is that Kubernetes, rightly, requires encrypted Transport Layer Security (TLS) communication. Dropping this requirement would simplify prerequisites but compromise default security.
Kubernetes cluster node maps.
Is there a fix? Yes, if we acknowledge that the platform underlay (aka “ready state”) is a different problem than the cluster installation.
The reality is that all multi-node clusters suffer from the same complexity problem. We’ve heard the same thing about OpenStack for years. The reason that a fix remains elusive is that the problems cannot be addressed in the platform alone. The good news is that these underlay challenges are shared by all platforms and can be addressed in best practice ways. In fact, it is much harder to solve them when the overlays attempt clever short-cuts (like roll-your-own-PKI) to bypass basic cluster building needs.
Can the platform make an impact on this problem? With documentation, yes!
Documentation with clear configuration requirements and boundaries helps limit the integration surfaces. It also helps clearly identify underlay needs so that we can build operations automation around them because there are multiple valid ways to do this work.
Platforms need to trust their communities to solve address their underlay needs. We’re already seeing this happen in Kubernetes. Since there are multiple right ways, it may look messy or fragmented. I believe allowing the ecosystem to work independently is the fastest way for us to converge to the right patterns.
Kubernetes is pretty simple — let’s not bring underlay complexity into the project.
