Kubernetes typically follows a quarterly release cycle. However, 2020 has been an unprecedented year so far, one that has impacted many contributors and businesses. The Kubernetes community responded to the challenges of 2020 by making some changes to the Kubernetes 1.19 release timeline.
These changes extended the release cycle to allow more release candidates to be built while giving the community more time to focus on the enhancements that would be delivered. Most of the updates represent functional changes, but Kubernetes 1.19 also comes with some important policy enhancements that make it easier to plan for upgrades and will lead to more predictability and stability overall in future releases. Below are some notable enhancements delivered in the 1.19 release. For a rundown of all of the new features, check out the Kubernetes Enhancement Tracking spreadsheet for 1.19 and/or sign up for the CNCF 1.19 Webinar.
New timeline, new testing policies
Kubernetes releases are typically around 12 weeks in length, but the Kubernetes 1.19 release cycle was 20 weeks. The longer code freeze period provided an opportunity to focus on much-needed improvements to Kubernetes CI testing. This resulted in several new policies that greatly reduced failing tests (which threatened to further delay the release), as well as a proposal to create a new reliability working group. These initiatives helped improve stability of the testing infrastructure, in turn making the release itself more stable. Members of the 1.19 release team and the SIG Testing community worked closely together to make this happen.
Like most releases, Kubernetes 1.19 consists of a mix of new enhancements and the further maturation of existing capabilities. There are a total of 34 enhancements. Of these, nine are brand new, 15 are graduating to beta, and 10 are graduating to stable. Kubernetes utilizes gates for alpha and beta features, with alpha features disabled by default and beta features enabled by default. That means you can start using new beta features right away.
Increase Kubernetes support window to one year: Graduating to stable
Upgrading to a new Kubernetes release can be a significant undertaking and, for many organizations, may not be a high priority. Moreover, branches are currently only maintained for the most recent three minor releases. That means running an older, unsupported version of Kubernetes can result in missing out on critical security updates and bug fixes.
In 2019, a survey administered by the Kubernetes Long-Term Support (LTS) Working Group found that more than one-third of respondents were running a version of Kubernetes that was outside of the standard 9-month support window! With Kubernetes 1.19, the support window for Kubernetes releases has been extended from nine months to one year. This extended window will provide organizations with more opportunity to handle major upgrades, as well as providing needed security patches for prior releases for a longer period.
Warning mechanism for use of deprecated APIs: Graduating to beta
One challenge of upgrading Kubernetes is dealing with the removal of deprecated API versions. Kubernetes 1.16, for example, removed a number of API versions that had been deprecated for some time. It can be hard to keep track of deprecations and removals, and many organizations were still using older, deprecated versions when Kubernetes 1.16 was released.
Starting with Kubernetes 1.19, there is a new warning mechanism that will provide cluster users and administrators with a better understanding of how deprecated APIs are being used so as to enable them to better prepare for future upgrades. Toolings like kubectl will issue a warning when a deprecated API version is used, giving users immediate feedback so they can better prioritize updating their Kubernetes resources. A new metric and audit event will also indicate that a deprecated API has been used. Cluster operators can use these alerts to plan upgrades and communicate with users when action needs to be taken.
Require transition from beta: Graduating to stable
When a Kubernetes enhancement reaches beta, it is enabled by default in the Kubernetes API. In the past, features have reached beta and remained in that state for a long time. Starting with Kubernetes 1.19, once an API reaches beta, it has nine months to either reach general availability and deprecate the beta or upgrade to a new beta version and deprecate the previous beta.
This policy will apply to APIs that reach beta in 1.19 along with a number of existing beta APIs, such as PodSecurityPolicy.
Graduate Ingress to V1: Graduating to stable
Ingress is among the features in Kubernetes that have remained in beta for a long time, but in Kubernetes 1.19, it finally graduates to stable! There are also some user-facing changes to Ingress, so please review the Kubernetes 1.19 release notes to ensure you can migrate to the new Ingress API.
Looking ahead to Kubernetes 1.20
Now that Kubernetes 1.19 is here, we can start looking ahead to Kubernetes 1.20! Given the elongated release cycle for Kubernetes 1.19, Kubernetes 1.20 will be the final release of 2020. This cycle will kick off sometime in September, with the release due sometime in December.
Join us
VMware remains committed to being a leader in the upstream Kubernetes community and would love for you to contribute as well. Becoming a member of the Kubernetes Release Team is a great way to contribute to the project, even if you are new to it. There are multiple roles on the team, many of which require no prior development experience; learn more about the various volunteering opportunities available. A call for shadow applications will go out soon to the kubernetes-dev mailing list. You can also subscribe to this issue on Github to follow the process of building the 1.20 release team.
If you’re looking for other places to contribute, check out the shiny new k8s.dev, the Kubernetes site for contributors. There you will find the contributor guide, the community calendar, as well as upcoming news and events. Keep an eye on @k8scontributors for more information.
