Kubernetes development has been moving at breakneck speeds for some time. Along with that, much of the development has been happening in a monorepo. It’s normal for the project to merge 150 pull requests a week into the monorepo, with peaks much higher than that.

Until recently, the monorepo has been the place where much of the Kubernetes feature development has happened. A recent example can be seen in the Workload API controllers. These controllers started off in Kubernetes in an alpha state, went through multiple iterations of beta, and were finally released as stable in Kubernetes 1.9. The life cycle of development happened in core.

The Problem

It’s not sustainable or good for competition to have everything in core. Ecosystems around other platforms have shown the benefits of layering on additions.

Imagine the case where every implementation for every hosting solution and cloud provider had to be built into Kubernetes and stored in the monorepo? How much code would that require? This isn’t something to imagine but a state Kubernetes got itself into.

Or, imagine two groups – possibly at two different companies – having competing ideas how to do something. You couldn’t get every idea into core. And, debating direction may get the whole space locked up in committee debates rather than development.

If Kubernetes were a small community this might not be a problem. But, the Kubernetes community has grown in the number of contributors, number of users, and number of people with ideas that often compete with others ideas.

Note, if you want to see this growth in the form of graphs consider taking a look at dev stats for the Kubernetes community.

The Shift

To accommodate the amount of development and innovation going on a subtle shift has been happening that’s now become more of the norm.

1. The features being added to core Kubernetes are those that enable others to extend or add on to it. One example, of many, is Custom Resource Definitions (CRD).
2. New features, which would have typically been built into core Kubernetes, are being asked to start out as ecosystem projects instead. If they gain wide adoption and can be run everywhere, from small to multi-cluster setups, there may possibly be a path to core.

The idea is a slower moving stable core along with space for innovation and competition outside of core.

Change To Reality

Change doesn’t happen all at once. It takes time. This change in direction isn’t new but is now coming to a head. For months discussions have been had around how the shift works and is communicated. It’s long past the “should we do it” stage.

Yet, it’s not to the point where everything is worked out. What does it look like to move something developed in a CRD to core? We know this needs to be solved but it’s not happened, yet.

The point we’re at now is one of starting new features in the ecosystem. The last SIG Architecture meeting highlights two examples of this:

• Adding timezone handling to CronJobs was brought before SIG Architecture. Due to handling of timezone database (and changing daylight savings time), dealing with multi-cluter workloads, and other issues, the ask was to work this out in the ecosystem.
• Discussion has come up around a grouping object for Applications that includes metadata. This could be similar to some things Helm does today. The direction is shifting to be pretty strong around doing this in the ecosystem.

These changes aren’t limited to new features, either. Changes are coming to existing features and setups as well. One example of this is that cloud provider code is being broken out of the monorepo.

Stability And Ecosystem

This shift, I believe, will lead to a more stable Kubernetes foundation and more opportunities for competition within the ecosystem. It turns container management into boring infrastructure, in a similar way containers themselves being boring, so that innovation can happen on the next rung up the ladder.