Kubernetes 1.20 Arrives in a Hail of Controversy
The Technical Oversight Committee (TOC) that oversees the development of Kubernetes has approved a 1.20 release of the platform that promises to simplify IT operations tasks while at the same announcing that support for Docker Engine in the platform will be deprecated beginning next year.
However, the potential impact of that decision is being minimized by a decision by Docker Inc. and Mirantis to jointly make the dockershim software, which was created to meld Docker Engine with Kubernetes, available as an independent open source project that both companies will support.
The TOC along with Docker Inc. has been signaling its intention to move away from Docker Engine in favor of an engine for Kubernetes based on Containerd for years. Containerd was donated to the CNCF in 2017 by Docker Inc. to provide a more efficient runtime that is exposed via the Container Runtime Interface (CRI). The dockershim project made the original Docker Engine compatible with the CRI defined by the Kubernetes TOC.
Adam Parco, vice president of engineering for Mirantis, says the continued availability of dockershim should put any controversy surrounding that transition to rest. Miranits acquired Docker Enterprise from Docker Inc., so the two companies are committed to allowing IT teams to sunset Docker Container Engine at their own pace versus a timeline defined by the TOC that oversees Kubernetes.
Jeremy Rickard, a staff engineer for VMware who collaborated on the 1.20 release, adds in the meantime any application created using images that comply with the Open Container Initiative (OCI) specification will continue to run on Kubernetes. The swapping out of Docker Container Engine will have only a minimal impact on IT operations teams most likely over the next approximately two years.
In general, Rickard said most of the new capabilities added to 1.20 are tools that will appeal to those same IT operations teams. Overall, there are 42 enhancements made to Kubernetes, with 16 of them being alpha projects that Rickard says shows there is still room to innovate. Eleven other existing capabilities have graduated to stable with this release, while 15 enhancements are moving from alpha to beta.
Among the alpha capabilities is a graceful node shutdown capability that shuts down pods alongside the Kubernetes cluster, notes Rickard. Today pods will not terminate automatically when the cluster itself shuts down, requiring an administrator to manually intervene.
The IPv4/IPv6 dual stack has been reimplemented to support dual-stack services in this release as well to enable both IPv4 and IPv6 service cluster IP addresses to be assigned to a single service.
Rickard also notes that alpha and beta capabilities added to any release that doesn’t graduate in a timely manner will also start to be deprecated. The goal is to eliminate projects that are deemed as not moving forward in a way that benefits the overall community, he says.
It may be a while before IT teams roll out 1.20 in a production environment. In fact, many organizations are now running multiple versions of Kubernetes spanning various Kubernetes distributions. As part of an effort to limit that potential overhead, Rickard says the TOC is considering moving from four to three major updates per year.
Regardless of what version of Kubernetes an organization is running, managing Kubernetes on a daily basis will still require a fair amount of IT expertise for some time to come.
