https://thenewstack.io/kubernetes-1-20-lands-with-44-enhancements/

Kubernetes 1.20 has launched, marking just the third release of the open source container orchestration software for the year. With 44 enhancements, including 11 graduating to stable, 15 moving to beta, 16 entering alpha, and a couple of deprecations, the release is larger than average, in part due to the longer time frame involved.

“If you look back at 1.19, it should have been the second release of four. Typically Kubernetes has gone through this process of quarterly releases and 1.19 was pretty prolonged. It kind of overlapped with a lot of things happening in the world — COVID, unrest in the U.S. — and we had a really prolonged code freeze as part of that,” said Kubernetes release lead and staff engineer at VMWare Jeremy Rickard.

While the release cadence may have been altered by external factors, Rickard pointed to an ongoing discussion in the Kubernetes release special interest group (SIG), noting that there were good reasons to perhaps stick with three, instead of four, yearly releases moving forward.

“I think there’s a lot of pressure to keep up with things from a backward compatibility standpoint, and what number of releases stay in support,” said Rickard. “Generally, it’s been like, three releases are in support, and once you fall off of that train, you lose things, like whenever CVEs come out, you don’t necessarily get patches for those. There’s a lot of pressure to keep up with those releases. It’s also a lot of overhead on the release teams, just a lot of toil.”

The question of release cadence currently remains up for discussion, but Rickard said he expects the issue to be resolved by the time Kubernetes 1.21 is released, which will begin its cycle in January and should be released around March, similarly to 1.18 last year.

As for feature enhancements, Rickard said that stabilizing some long-running features was a big focus of 1.20. Examples included a CronJobs update with a new version of the controller, and steps taken toward Container Runtime Interface (CRI) compatibility, with the deprecation of Dockershim. These follow a decision made with Kubernetes 1.19 that features couldn’t sit idle in beta indefinitely but rather had to follow some sort of timeline.

“Both of those things have been around since about the same time frame. They’ve been there for a long, long time. We have this new process that came in with 1.19, where things can’t remain in beta forever. There’s a lot of things that are in that bucket,” said Rickard. “Certain things like that just tend to sit and people pick dependencies on them, and then, later on, it’s harder to make changes to those because people have taken those dependencies. They either have to graduate to GA or stable, or they have to be replaced by a new beta version, or they then have to be deprecated. One of those three things has to happen.”

On the point of the Dockershim deprecation, the Kubernetes team has written both a blog post as well as a dedicated FAQ page to answer any questions, though right now the only effect in 1.20 will be a deprecation warning for end users.

Other features included in 1.20 are volume snapshot operations moving to stable, kubectl debug entering beta, the introduction of a graceful node shutdown feature, and an update to IPv4/IPv6 support, which allows for a dual-stack.

“The great thing about dual-stack is that previously IPv6 had been supported and you can run IPv6-based clusters, or you can run IPv4 clusters, but you couldn’t do the two together. It’s an either/or in previous worlds,” said Rickard. “The dual-stack feature is really great because it allows you to do both and say, ‘Hey, this existing set of things can continue to run as IPv4, we’ve got this new stuff that we’re going to run as IPv6, it’s cool, they can coexist.’ We can also expose services as both, as another transition mechanism between the world of the past and the world of the future.”

Looking ahead, Rickard said he sees a push toward stability as a continued theme, alongside an effort toward greater support for Windows. He also noted an in-progress effort to increase transparency into what’s coming down the pipeline for future releases.

“Right now, a lot of the work about determining what’s going to land in the release is a really, really manual process. You go through GitHub issues, and you say ‘Do you plan on landing this in 1.20 or not?’ If you want to come and see what’s going to land in 1.21, it’s not really transparent. It’s kind of hard to piece all these things together. One of the things we want to do is make that more transparent,” said Rickard.

For future releases, he said, SIG Release is working on defining a process where people will define metadata, and then that data will be used to build a dashboard showing what releases were released when, or what versions they are planned for.

The Cloud Native Computing Foundation, which manages Kubernetes, and VMware are sponsors of The New Stack.