The co-creator of Kubernetes, Joe Beda, has admitted that the container orchestration tool continues to be tricky to learn and that community efforts should focus on making the technology as “boring” as the Linux kernel to drive the next wave of industry adoption.
“Kubernetes is now the anchor for a broader ecosystem and ways of thinking about deploying and managing applications,” said Beda, in a recent virtual ask-me-anything session with BrightTalk. That’s a far cry from Kubernetes’s origin days. “We didn’t foresee that,” he admits.
Beda has two goals for Kubernetes now that it is a key technology for enterprise developers. One is to make Kubernetes as foundational as the Linux kernel, by becoming a stable, capable platform you can just count on.
The second is to build exciting new capabilities on top of that foundation. “People are building amazing things on [Kubernetes]. The features we do add will enable really interesting things, and there is already a slew of projects that build on and around and for Kubernetes,” he said.
Beda wrote one of the first commits for Kubernetes back in 2014 and is now a principal engineer at VMware, after a 10-year stint at Google. During the course of the conversation he confronted two other key questions facing the popular open source project.
Why is Istio separate from Kubernetes?
One really interesting question for Beda was why the open source service mesh Istio, which is commonly paired with Kubernetes and was also primarily built by Google engineers, has not been integrated more deeply with Kubernetes.
Google has been unwilling to donate Istio or fully contribute to it in the open with the Cloud Native Computing Foundation, the organization that Google turned Kubernetes over to when it open sourced the technology. Instead, Google wants to keep “higher control over Istio,” Beda said.
Another reason the two projects remain distinct, according to Beda, is because there are other ways than Istio to implement a service mesh, such as Linkerd and Microsoft’s Open Service Mesh. In some cases, there’s no need to deploy a service mesh with Kubernetes at all.
Is Kubernetes too difficult to learn?
YAML configuration files are often the bogeyman when it comes to complaints about Kubernetes’s steep learning curve. Beda admitted that “YAML was a stopgap until we found the right way, but there is no single right way — that’s like asking what is the right programming language? It depends on what you want to do and the environment you are in.”
That being said, there are efforts to make YAML more declarative and less intimidating for newcomers, such as Helm charts that combine packaging and deployment in a single integrated experience, and CDK for Kubernetes, which also attempts to abstract some of that difficulty away.
Beda also admitted that running Kubernetes on bare metal continues to be a challenge for those brave enough to try it. “Managing Kubernetes on bare metal is difficult. The easiest way is with programmable infrastructure underneath you, like Terraform, Ansible, or Cluster API,” he said.
Turning to infrastructure-as-code in this way allows developers to manage multiple clusters for more automated builds and greater malleability. “Through automation and this nimbleness, you make things more reliable. Instead of a single hand-tweaked cluster, you have a set of clusters that are self-managed with more fluidity to move things around and push things and roll back faster,” Beda said.
Beda also pushed back against the general notion that Kubernetes should be made easier by reducing the complexity that comes from its innate flexibility. “The beauty of Kubernetes is there are no gatekeepers, no one telling you what you can’t do or how to use it. That is part of the open source ethos. That flexibility is one of its strengths,” he said.
