I’m privileged to be the release manager for Kubernetes 1.12. As of now, we’re about halfway through our quarterly release cycle, so I thought it might be interesting to share a few observations about what we’ve been doing this time around.
What’s new in Kubernetes 1.12
I’ll start off by addressing the question I’m asked most often at the moment: What’s going to be in the 1.12 release?
This kind of question makes any release manager a bit nervous, but especially in open source. Indeed, we’ve stopped running features-related posts on the Kubernetes blog early in the release cycle. Posting too early about what’s planned for each new release leads readers to see these as firm commitments, rather than aspirations subject to the vagaries of open source practice.
But I can tell you that there are 66 features on my current list of likely changes. Of course, not all of them will make it in. Some are small and have a narrow interest, and many are just coming in at their initial alpha status. We are, however, just past the point of what we call “feature freeze,” where we try and stop committing to additional new features and focus on getting everything that we have already committed to working. So, there are a few larger items that are both fairly likely to make it in and might be of general interest.
For Kubernetes 1.12, a few notable general trends from my perspective are:
- Enhancing kubeadm towards stable/GA status, although we’re not expecting kubeadm to fully hit that milestone in 1.12
- Security enhancements like the addition of pod sandboxing, where we’re looking at a possible alpha of “RuntimeClass” in 1.12
- New storage features that are expanding what is possible for stateful workloads
- Multiple advances in autoscaling (vertical, horizontal and cloud-provider specific)
- Better multi-platform support and Windows containers graduating to stable
Leveraging continuous integration
One thing that we do as we move through each release is evolve the release process. Kubernetes typically comes together in a quarterly release cadence. That sounds like a waterfall process – where a release is planned, worked on and then stabilized over a period of weeks before the next release cycle starts up.
However, in such a large open source project, the line really blurs between releases to the point that we have people working on new features nearly all of the time. This increases the importance of what we call a CI (continuous integration) signal, the information that our continual test coverage gives us. We always have a period at the end of any release cycle for stabilization but starting with version 1.11, we’ve really tried to ensure that we always keep that CI signal green.
What we don’t want is people to just throw in a bunch of code for a month or two and then spend the next month fixing the bugs. Instead, we aim to always have tests running that are giving us a green light. When new code comes in, our quality criteria is that the new code does not destabilize the project.
Going forward we’ll still have code freezes, where the only things going into the master branch are either bug fixes or reliably good and previously accepted features. But our goal is that the code freeze periods can be a lot shorter because we have this focus on ongoing stability. The result is that we’re getting more agile and better able to keep things moving all the time.
The team
The third thing I want to talk about is how we’re shifting our team structure this time around to accommodate more people in shadow roles.
Kubernetes is managed by a volunteer team occupying 10 lead roles. For this cycle, we have a total of 26 shadows, which is more shadows per lead than we’ve had in the past. Shadowing offers newer contributors exposure to the management process so that they can learn how we do things and then take on lead positions in subsequent releases.
But why have multiple shadows for each position? Well, in the past we’ve had people shadow and then get super busy in their professional lives and need to withdraw from leading in the next cycle. That’s meant existing leads have had to stay on when they hadn’t planned to, or we’ve had to pull in volunteers who haven’t been through the shadowing process yet.
With two or three shadows for pretty much every role, we now have a higher likelihood of having somebody ready to step into that role next time around.
This gradual turnover in the release team also reflects the commitment that I see and want to further encourage in the Kubernetes community—one of inclusion. Sometimes even the hottest projects don’t give a lot of thought to sustainability. But you can’t assume that your momentum will always exist. We’re making a very deliberate effort to lay the groundwork for long-term sustainability and maintaining a healthy, vibrant community.
Google-independent releases
The final thing I want to mention is that we’ve changed the mechanics of doing our build and release in terms of publishing artifacts out on the web. Historically, this had to be done by a Google employee. But the folks at Google have been working on updating and enhancing their behind-the-scenes automation so that a community member can do it. The post-release patch manager for the 1.11 release wasn’t a Google employee, but had worked there until fairly recently. For the Kubernetes 1.12 release, we have for the first time a release manager who has never worked at Google: my VMware colleague Doug MacEachern.
It’s a volunteer position that takes both a lot of work and puts you in the firing line when things go awry, so I’m really grateful to Doug for taking on the job for the first time. I’m also really grateful to the people at Google doing their hard work behind-the-scenes to update build automation and help the community take up this mantle.
Get involved!
Amazing people generously volunteering their time are, of course, what makes open source possible. And while we tend to think about open source contributions in terms of adding new code, the roles played by project managers are essential, too.
If you think that’s a roll you might like to take on at some point, the Kubernetes community runs a number of mentoring initiatives, including a monthly meeting where we have an ask-me-anything type section interviewing the project’s contributors about what they do. I got to be featured just recently, so check that out if you are interested.
I’ll also be talking about project management, the release process and building community at the Open Source Summit in Vancouver later this month. If you aren’t able to get there, there will be panels on these subjects at the two major Kubernetes conferences coming up this fall in Shanghai and Seattle. Both KubeCons also start with an initial day of orientation and mentoring for prospective new contributors.
About the author
Tim is a software engineer with over 20 years of open source development experience. He is currently a member of VMware’s Open Source Technology Center, acting as an open source developer advocate and contributing to upstream projects such as Kubernetes, where most recently he served as the Kubernetes 1.12 release team lead. In his past, he’s worked on the Linux kernel, device drivers, distributions, software updates, Android, OpenStack and an open source golang-based orchestrator for containers and a VM that wasn’t Kubernetes.
For more insights into Kubernetes 1.12, be sure to visit the Open Source Blog and follow us on Twitter (@vmwopensource).
