Kubernetes 1.17 Release Arrives

December 10, 2019 Mike Vizard containers, kubernetes, Kubernetes 1.17, sidecars, storage, technical oversight committee

The Technical Oversight Committee (TOC) responsible for developing Kubernetes today announced the availability of the 1.17 release, which adds 22 enhancements. Of the enhancements, 14 are features that have now been deemed stable, while four features have moved from alpha to beta. There are only four enhancements, including support for topology-aware routing services, moving into alpha with this release.

Arguably, the most important capabilities being moved along in this release is dual-stack support for IPv4 and IPv6 networking protocols and a beta version of tools for migrating existing “in tree” approaches to managing storage to the Container Storage Interface (CSI), which was developed to integrate external storage systems to Kubernetes. A tool that enables IT teams to capture volume snapshots of persistent storage volumes has also advanced to the beta stage.

In addition, labels for instances of Kubernetes that can be applied to cloud services has become generally available with this release. Those labels will make it possible to write specifications for Kubernetes that are more portable across multiple cloud computing services.

Guinevere Saenger, the technology lead for the release and a software engineer for GitHub, said the Kubernetes 1.17 release started out with 44 proposed additions. However, given the holiday season and the timing of the recent KubeCon + CloudNativeCon 2019 conference, the TOC membership voted to move updates to many of these projects to a future release.

The most critical feature not being advanced in this release is support for containers deployed as sidecars, says Saenger. That capability will make it possible to extend the functionality of one container running on Kubernetes to another container. Outside of Kubernetes clusters, however, containers deployed as sidecars have already been widely employed.

In general, Saenger says Kubernetes needs more contributions from end users who have deployed Kubernetes in production environments to identify bugs that need to be fixed and potential new use cases. There are plenty of vendors contributing to Kubernetes. However, most of the engineering teams from vendors are not running application workloads on Kubernetes themselves.

The challenge many IT teams are starting to encounter with greater frequency is that each instance of a Kubernetes cluster tends to be a “snowflake.” IT teams are finding themselves managing clusters that are running different versions of Kubernetes. Some of those earlier releases of Kubernetes can be updated to add support for specific features. However, operationalizing Kubernetes at scale is clearly the next major challenge for IT organizations.

Right now, there are more than 100 certified instances of Kubernetes. While a handful account for well over 90% of the instances of Kubernetes deployed in production environments, IT teams will soon find themselves most likely employing two or more distributions of Kubernetes running in the cloud and on-premises as well. It may be a while before IT organizations define the best set of DevOps processes for managing Kubernetes clusters. However, it’s clear that backlog of microservices-based applications destined to be deployed on those Kubernetes clusters is building.