Around the turning of the calendar year, it’s common for us to pause a bit and do some introspection relative to where we’ve been and prognosticate on where we’re going. Something you probably heard said increasingly in 2018 was that “Kubernetes is boring.” That statement is both part fact and part aspirational. When we say that Kubernetes is boring, we want and need that to truly be the case. As of now, however, we still have some work to do.
In December 2018, Brian Grant (one of the key project architects) started the Kubernetes Contributor Summit with the message, “Quality is Job 1.” There are a few aspects of this that I want to highlight:
- Testing: The project overall has exceptionally good testing, especially if you consider the massive technical scope, the size of the codebase, the huge variety of runtime configurations, and the change velocity of the code base. Still, there are exasperating weaknesses that show the need to improve:
- Coverage percentage – lines of code touched in some way during testing
- Coverage quality – test cases touch important lines of code in a meaningful way
- Compatibility: Can you easily upgrade? Can you take a workload definition and have it run on a different cluster? Does “Kubernetes” mean something consistent and is that backed by the project’s conformance tests? We’re not all satisfied with the answers to these questions today and momentum is coalescing around concrete actions for improvement.
- Stability: Kubernetes is a young project in the larger scheme of things. You’ve probably heard “Kubernetes is the Linux of the cloud.” But break that down for a moment. Linux took the better part of a decade to break into the mainstream and it built on a decades-long history of Unix, during which tools, abstractions and development practices were grown and matured. Expect to see something similar with Kubernetes this year as the community adds focus to drive the most core APIs to GA/stable, as well as ensure configuration versioning/stability and backend provider abstractions maturity (e.g.: CRI, CSI, CNI and cloud provider APIs).
- Mindset and engagement: A healthy project needs more than automation that flags breakage early. This need, matched by a culture of responding quickly, requires human and capital resources. Growth in industry adoption of Kubernetes and its steady stream of new features will continue to get the bulk of press coverage this year, but this obscures the story of how Kubernetes is striving toward an ever-higher level of quality software engineering: adoption growth is mirrored by contribution growth.
The people contributing to the Kubernetes project place notable value on these types of improvements. It’s an engineering story that deserves to be told, in addition to just the feature announcements of the day.
Here are some implementation details you might see soon, all related to the above points:
- Splitting the monolith: There is a re-organizing underway in the core repository of Kubernetes. The project has been represented by more than a mono-repo for some time ( https://git.k8s.io/kubernetes vs. https://git.k8s.io/), but there are still many vestiges of the early days and even some areas where the right evolutionary organization change is uncertain. However, there is an explicit goal of establishing stronger architectural boundaries and decoupling logically independent components so that they can independent components operationally. This means they can both mature and innovate at a pace appropriate for themselves, and then you can build a more well-defined dependency relationship between components at the time of integration or consumption, instead of attempting that in a mono-repo.
- Splitting from Google infrastructure: Last year, Google made a significant announcement around funding to shift the project from Google sponsored infra to community (CNCF, members, donors) sponsored. A working group has thus formed to effect this change: WG K8s Infra.
- Kubernetes Enhancement Proposals (KEPs): Modeled after the Python community’s PEP process, this represents a formalization of a best practice we all know yet don’t always do well: planning. It’s hard in all walks of life, but especially in a massive and globally distributed ad-hoc team of thousands of people. KEPs are about insuring major work on the project has a durable record of artifacts and establishing a well-reasoned plan while getting consensus from stakeholders in order to execute and measure the resulting quality.
In 2019, I see a lot of growing up coming for Kubernetes. This shouldn’t be viewed as pejorative: it’s not a good thing, so much as it is a GREAT thing. The Kubernetes project is on a healthy maturation trajectory and its contributors care about continuous improvement. VMware recently joining forces with Heptio reiterates are commitment to this vision. Growing up is about knowing you need to become more sophisticated and robust in our collaboration processes, automation, teams and people—and then doing the hard work to get there.
Stay tuned to the Open Source Blog and follow us on Twitter (@vmwopensource) for all the latest around Kubernetes and the open source community.
