After a slightly prolonged development circle, the Kubernetes project has emitted version 1.19 of the system for managing containerised applications.

Admins and infrastructure folks will be especially pleased to learn that starting with this release the project will offer a full year of patch support instead of the former 9 months. Of course this means more work for the maintainers and testers of the project, who now have to ensure fixes work for an additional version, which could lead to smaller feature updates in the coming versions. 

However, the release cadence proved to be quite tricky to stay on top of, especially for larger enterprises used to year-long planning cycles. A survey carried out last year even suggested that a support window extension like the one now realised could lead to more than 80 per cent of users being on current versions compared to the current 50 to 60 per cent. 

Another change in the workflow of the project is a new policy regarding REST APIs that will take action with the release of version 1.20. To avoid said interfaces staying in beta for too long, the team will now have nine months to either get their APIs to general availability, or release a new beta. If none of the two happened, the REST API will be deprecated with the release following the end of the nine month-countdown.

When using deprecated APIs, Kubernetes 1.19 will now return a warning message which informs users of key dates, such as the likely removal date, and replacement APIs, should there be any available. Kubectl was already updated accordingly, though the more interesting change in the command-line tool might be the addition of two new experimental debugging workflows for workloads and nodes. While mishaps in the former can now be brought to light by creating a container in host namespaces, debugging workloads is meant to become easier by letting users create a copy.

Kubernetes 1.19 features an alpha version of storage capacity tracking, which provides “an API for a CSI driver to report storage capacity and uses that information in the Kubernetes scheduler when choosing a node for a pod.” This is meant to help with dynamic provisioning for local volumes along the line. Examples for other (still in alpha) additions include generic ephemeral volumes, which can be used for scratch storage, and CSI volume health monitoring. 

There’s also a configurable default rule for “Even Pod Spreading” for the scheduler, which is meant to free admins from the tedious task of defining constraints for each pod separately.

Meanwhile, the Kubernetes team was also able to stabilise some features, moving, amongst other things, the Ingress API and secure computing mode into general availability. EndpointSlice, a scalable alternative to the Endpoint API, is now enabled by default, meaning kube-proxy reads from there instead of using Endpoints, which is meant to help scalability in large clusters.

Admins betting on logs having a certain format, for automation purposes for example, should take a minute to study the newly standardised log message structure to make sure their setups keep working as intended after the update. New methods in the klog library, InfoS and ErrorS, are available to enforce the standard. 

More details can be found in the project’s changelog.