The Cloud Native Computing Foundation (CNCF) and the Kubernetes Release Team recently announced the release of Kubernetes 1.20. This is one of the largest releases with a long list of enhancements, such as volume snapshot operations becoming stable and kubectl debug graduating to beta. There was also much discussion within the community in relation to the dockershim deprecation notice.
InfoQ caught up with Jeremy Rickard, release lead and staff engineer at VMware regarding the Kubernetes 1.20 release. He highlighted the diversity of the release team, which included the first person to lead a release from India, and stated that half of the sub teams were led by women.
This latest release of Kubernetes has continued the focus on project stability, including improving the end-to-end testing of the framework and the visualization of test results. There has also been a conscious effort to slow the release cadence of the project, which has resulted in three releases this year, compared with four in the majority of previous years.
Rickard's primary advice in relation to the dockershim deprecation in this release was not to panic. There has been a lot of confusion visible on social media, but a recently published Kubernetes blog post provides the definitive guide to the deprecation process.
InfoQ: Can you talk specifically about the 1.20 release and the challenges of being the release lead?
Jeremy Rickard: I think 1.20 has been a pretty exciting release. I’ve called it “The Raddest Release”. The mascot ended up being my cat in a funny pose. He’s got this habit of keeping his tongue out all the time and it tends to make people laugh. 2020 has been a really challenging year for people, both personally and professionally, so I wanted to end the year with a bit of humor.
The 1.19 release was extended quite a bit to take some burden off of both contributors and people consuming Kubernetes, given COVID-19 and other things occurring during this year . With the way the calendar worked out, the 1.20 release felt pretty short, overlapping with KubeCon + CloudNativeCon North America 2020 and Thanksgiving in the United States. Despite these constraints, we’ve had the largest release in terms of enhancements (features) in a long time! For comparison, the 1.17 release occurred during roughly the same time of year in 2019. It had 22 enhancements, while this release has more than 40!
I’m particularly excited that for the 1.21 release, Nabarun Pal will be the first person to lead a release from India! I think it is a great sign for the health of the community. We’re also going to have half of the sub teams led by women! I’m really proud of the diversity the release team has.
InfoQ: Can you talk about the controversy associated with deprecating dockershim? Specifically, do application developers have to do something different to continue to run on Kubernetes 1.20 and greater?
Rickard: The great controversy of the release! The first thing I’ll say is DON’T PANIC!
You will still be able to run Docker containers. As this was sort of spiraling out of control on Twitter, Reddit, and Hacker News, the community came together and put together a nice blog post that I’d highly recommend people read: https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/.
An important distinction here is that this deprecation is focused on a pretty specific thing: the Docker runtime... not Docker images/containers.
What is really happening here is that the Kubelet (the component that runs on your nodes) was switched to use the Container Runtime Interface (CRI) many, many releases ago. The Docker engine didn’t implement CRI and got sort of special support with something called the dockershim. That special case is being deprecated and will be removed at some point in the future, probably 1.23 at the earliest. It is really better, from a Kubernetes standpoint, to use one of the CRI implementations, like containerd.
If you’d like to continue running the Docker engine, Mirantis and Docker have partnered to make a fully CRI compatible implementation using the Docker engine: https://github.com/Mirantis/cri-dockerd.
InfoQ: Can you talk about the testing and continuous integration aspects of Kubernetes in as much technical detail as you can?
Rickard: One thing that became a problem during the 1.19 release was many things merged and ended up causing degradation to the overall stability / health of the code base. Viewing the trend of tests highlighted this, but it really required a lot of investigation to get back on track. This time around, we were pretty focused on observing the general trend here and tried to be really proactive and use it as a general picture of health.
In 1.20, lots of great work went into adding end to end tests to focus on improving quality all around, but really close to the end of the release we started to get a lot of failures and the team got really concerned. It turned out that we had some new end-to-end tests for a feature in the release that was very prone to failing due to resource constraints and were generally just not great tests.One thing that I’ve really come to appreciate about the Kubernetes project, from a testing perspective, is that the results of various automated tests are pretty easy to visualize and dig into via https://testgrid.k8s.io/. I think having that visual landing page for seeing the general trend is nice and we’re looking at how we can incorporate something like that on my work team. For example, once we cut the 1.20 branch we were able to visualize trends for what we consider blocking jobs https://testgrid.k8s.io/sig-release-1.20-blocking. This let us drill in and identify the problem tests and get a handle on when it started, and figure out the cause and plan a way forward.
InfoQ: Finally, let’s look at Kubernetes releases in general -- is it possible to have quarterly releases going forward?
Rickard: I think it’s definitely possible to get back to quarterly releases, but I think there is some desire to slow the cadence down some and maybe more permanently align on three releases. There is an issue open on GitHub to discuss this, and I’d encourage people to review and comment: https://github.com/kubernetes/sig-release/issues/1290.
I think the 1.21 release will follow the normal “quarterly” schedule, since a decision hasn’t been made yet, but I think there will be news about the future releases during that cycle. It is hard to know what features/enhancements will land in 1.21.One thing I’d add, is that if people are interested in the release team, or the Kubernetes project in general, there are many ways to get started! You can find some general resources at https://github.com/kubernetes/sig-release/blob/master/release-team/shadows.md and attend the sig-release meetings. You can find info on the meetings https://bit.ly/k8s-sig-release-meeting.
Additional details of the Kubernetes 1.20 release can be found on the Kubernetes blog.
