Mission Accomplished: Kubernetes Is Not a Monorepo. Now Our Work Begins!

Breaking up the Kubernetes monorepo enabled the project to support a larger ecosystem while maintaining reliability and ease of use.

• AWS and GCP tests were kicked off on every single PR to ensure cloud provider functionality and Kubernetes functionality were not broken
• Technical issues and people issues led to the decision to break up the monorepo
• Breaking up the monorepo allowed for architectural improvements and a larger ecosystem
• The burden of testing falls on the component repo, but there is an expectation that the code has worked at some stage
• The goal is to achieve reliability and ease of use while supporting a larger ecosystem

The relationship between the Kubernetes project and the Go team is healthier than ever, and there has been a lot of back and forth regarding Go modules and code sharing between repositories.

Over the past few years kubernetes developers have all been working hard to break up the kubernetes monorepo. Storage, networking, container runtimes and most recently cloud-providers are now independently developed in their own projects and repositories. Broadly, we’ve completed the technical code separation: mission accomplished. But have we made kubernetes harder to install, upgrade and operate? Do we still have the quality we had when there was one version of kubernetes, that was end-to-end tested on multiple clouds on every PR? Must a production-ready kubernetes distribution undo all our hard work and reassemble the monorepo? Join two kOps maintainers as they describe how kOps has tackled these issues - by necessity of maintaining a working kubernetes distribution. Learn how kOps maintainers collaborate with these new projects to help them build towards a coherent kubernetes. The speakers will share their visions of the component-based kubernetes distribution that we are all building, and open a discussion on how we should best build and test it. This won’t happen accidentally; the organizational work is at least as hard as the technical work. But together we can build a reliable and easy kubernetes experience, while allowing more choice and experimentation.