The Kubernetes project this week released its 1.20 iteration, which is the third and final platform release for the year. The release comes after a difficult year for most and resulted in the alteration of the project’s typical quarterly update cycle and also came just days after a spurious new security issue was found that impacts every version of Kubernetes.

The 1.20 update itself contains 42 total “enhancements” spread among various graduation levels. Most of those were new updates moved to “alpha” status that the project said showed that the “Kubernetes innovation cycle is still trending upward.”

Major themes of the update included the stable version of volume snapshot operations, the kubectl debug feature moving to beta, and a more “graceful” node shutdown moving to alpha that should counter current issues impacting some workloads.

Somewhat controversially, the update also signals the end (or deprecation, in developer speak) of the Dockershim container runtime interface (CRI) for Docker. That move drew some consternation on social media, which the Kubernetes project looked to stem with a well titled “Don’t Panic: Kubernetes and Docker” blog post and corresponding FAQ.

In its own blog post on the move, Docker Inc. explained that the “change primarily impacts operators and administrators for Kubernetes and doesn’t impact developer workflows.” It added that Docker-built images are compliant with the Open Container Initiative (OCI) and fully supported by the Containerd CRI that is now favored in the Kubernetes environment.

And for those still stuck, Mirantis jumped in to partner with Docker Inc. in maintaining the Dockershim CRI as a conformant CRI for the Docker Engine API outside of the Kubernetes project. “This means that you can continue to build Kubernetes based on the Docker Engine as before, just switching from the built in Dockershim to the external one,” the vendor wrote in a blog post.

Outside of the updates, the latest Kubernetes 1.20 release did get the project at least temporarily back on its quarterly update cycle. The previous 1.19 release was delayed by a couple of months due to external events.

“We gave breaks around when we saw the George Floyd protests, and the teams just needed that mental space and time to talk with their families and deal with what was going on, especially in the major cities,” explained 1.19 release lead Taylor Dolezal.

Dolezal added that the release team also provided contributors with time off around the KubeCon + CloudNativeCon Europe event, as well as time to deal with the ongoing impact from the COVID-19 pandemic.

“I think it was just a lot to deal with, and I liked that we were able to come together and agree on hey, let’s take a little bit more time in this release and not burn ourselves out. Because being open source, it’s definitely community focused, and it was nice to not push those people too much or stress them out,” Dolezal said.

The Kubernetes project has since taken the step to see if the community was interested in taking a more relaxed approach to future updates. Stephen Augustus, who is a senior open source engineer at VMware and was co-chair of the recent virtual KubeCon + CloudNativeCon North America 2020 event, took that route as part of his update on the Kubernetes project.

“The KubeCon keynote was essentially to call everyone to request feedback on changing the release cycle,” Augustus said in an interview with SDxCentral. He explained that the current model was to stick with the three-month release cycle for at least the first new release (1.21) of 2021, but that might change by mid-year to accommodate the proposal set out in his keynote.

“I definitely want to take at least at least a month to gather feedback,” Augustus said. “We’ve got some great feedback already, but we want to make sure that we do something that is sustainable for everyone who’s consuming Kubernetes, which is really the ultimate goal.”

Augustus also noted that a possible change could better support users that are getting their Kubernetes services through a managed agreement with a cloud provider.

“It definitely gets interesting when you start thinking through how cloud providers might be consuming it … and so many people are on managed Kubernetes solutions and they're multiple versions back,” Augustus said. “So, how do we accommodate those people too.”

The Kubernetes 1.20 launch also came ignominiously after a security flaw that impacts all versions and does not have a patch was announced.

The CVE-2020-8554 flaw is a man-in-the-middle vulnerability that is labeled a medium-severity risk. Its most significant impact is on multi-tenant clusters and can be exploited by users creating or editing services and pods in a Kubernetes cluster.

Security firm StackRox explained that user would only need basic permissions “such as creating or editing services and pods in a Kubernetes cluster. A user who has these permissions may be able to intercept traffic from other pods in the cluster.”

Since there is not a patch, the security firm recommends that Kubernetes administrators limit cluster permissions, restrict and manually audit external IP usage within a cluster, and also reconsider the use of multi-tenant clusters.

“The impact of this vulnerability is concerning because the reality is that many Kubernetes clusters today are multi-tenant, with many users sharing access to create services, and this issue stems from a design flaw or rather, a lack of accounting for this scenario at the time features were designed,” Wei Lien Dang, co-founder and chief strategy officer at StackRox, noted in the blog post.