News

Kubernetes 1.19 Released After a Productive Delay

• By John K. Waters
• September 8, 2020

The second release this year of the Kubernetes container orchestration platform, version 1.19, which arrived a bit later than expected, comes with 34 enhancements and a much needed extension of its standard patch support window from nine months to a full year.

The Kubernetes release team typically follows a quarterly release cycle, but the past few months have seen a paralyzing pandemic and world-wide social unrest that slowed the process around this release to a record 20 weeks. The team slowed things down, they said in a blog post, to allow more release candidates to be built and to give the community time to focus on enhancements during a period of disruption.

"The 1.19 release was quite different from a regular release due to COVID-19, the George Floyd protests, and several other global events that we experienced as a release team," they wrote. "Due to these events, we made the decision to adjust our timeline and allow the SIGs, Working Groups, and contributors more time to get things done. The extra time also allowed for people to take time to focus on their lives outside of the Kubernetes project, and ensure their mental wellbeing was in a good place."

"Contributors are the heart of Kubernetes," they added, "not the other way around. The Kubernetes code of conduct asks that people be excellent to one another and despite the unrest in our world, we saw nothing but greatness and humility from the community."

The new longer support window might be the most significant change in this release. It was sparked by a survey conducted in early 2019 by the Long Term Support (LTS) working group, which found that a "significant subset" of Kubernetes end-users were failing to upgrade within the nine-month support period. This and other survey responses led to the conclusion that 30% of users would be able to keep their deployments on supported versions if the patch support period were extended, whether the users are on self-build or commercially vendored distributions.

"An extension would thus lead to more than 80% of users being on supported versions, instead of the 50-60% we have now," the team wrote. "A yearly support period provides the cushion end-users appear to desire, and is more in harmony with familiar annual planning cycles. From Kubernetes version 1.19 on, the support window will be extended to one year."

Of the 34 enhancements in this release, 10 are moving to stable, 15 are in beta, and 9 are in alpha.

 Storage capacity tracking, one of the new alpha features, adds an API for a container storage interface (CSI) driver to report storage capacity and uses that information in the Kubernetes scheduler when choosing a node for a pod. (Kubernetes doesn't run containers directly, but wraps one or more containers into a higher-level structure called a pod.) This feature serves as a stepping stone for supporting dynamic provisioning for local volumes and other volume types that are more capacity constrained, the team said.

Another alpha feature, generic ephemeral volumes, allows any existing storage driver that supports dynamic provisioning to be used as an ephemeral volume with the volume's lifecycle bound to the Pod. It can be used to provide scratch storage that is different from the root disk--persistent memory, for example--or a separate local disk on that node. All StorageClass parameters for volume provisioning are supported. All features supported with PersistentVolumeClaims are supported, such as storage capacity tracking, snapshots and restore, and volume resizing.

The Ingress API is also now generally available (GA). "The API itself has been available in beta for so long that it has attained de facto GA status through usage and adoption (both by users and by load balancer / ingress controller providers)," the release team said in its blog post. "Abandoning it without a full replacement is not a viable approach. It is clearly a useful API and captures a non-trivial set of use cases. At this point, it seems more prudent to declare the current API as something the community will support as a V1, codifying its status, while working on either a V2 Ingress API or an entirely different API with a superset of features."

The team also added some observations about the longer release cycle of Kubernetes 1.19. Traditionally, the process provides 3-4 weeks between the call for enhancements and Enhancements Freeze, which ends the phase in which contributors can acknowledge whether a particular feature will be part of the cycle. This release cycle provided five weeks for the same milestone. Their conclusion: "The extended duration gave the contributors more time to plan and decide about the graduation of their respective features."

"Contributors were provided with 40% more time to work on their features, resulting in reduced fatigue and more to think through about the implementation," they wrote. "We also noticed a considerable reduction in last-minute hustles. There were also a lesser number of exception requests this cycle - 6 compared to 14 the previous release cycle."

A complete list of the enhancements in Kubernetes 1.19 and their stages of development is available online.