Don’t expect surprises: Kubernetes 1.23 stabilises dual-stack networking, makes progress on PodSecurity

Kubernetes 1.23

The team behind container orchestrator Kubernetes has closed the year with a last feature release, which sees long requested functionality maturing and pushes the project one step closer towards becoming the boring staple it set out to be. 

Kubernetes is a Google-initiated open source project for scheduling and orchestrating containers, and one of the cornerstone projects of the Cloud Native Computing Foundation. Version 1.23 is the third and final release of 2021, following a new slowed down release pace meant to provide end-users with slightly longer support windows and take some pressure off its contributors. 

Looking into the project’s changelog, a big chunk of the extra time seems to have been spent stabilising features, so that for instance the dual-stack networking functionality should now be good for production use.

The feature allows IPv4 and IPv6 communications “in parallel, for both pods and services” and can be used in scenarios which legally require IPv4 only clients and services. To support this behaviour, the service API comes fitted with an ipFamilyPolicy field, which can be set to either SingleStack, PreferDualStack, or RequireDualStack, the default being single-stack.

Teams who have been waiting to use generic ephemeral volumes or version 2 of the HorizontalPodAutoScaler in their production environments should be safe to do so now, as these have been also amongst the features moved to GA status.

With PodSecurityPolicy marked for removal in Kubernetes 1.25, admins will be glad to see its successor, the PodSecurity admission controller, moving into beta status with the 1.23 release. The corresponding feature gate is enabled by default now, and if things progress at the current pace, chances are good PodSecurity will hit its 1.24 target for a stable first release. Big changes aren’t to be expected until then, however the team still needs to collect feedback on the current implementation and work on its conformance test plan to reach its goal.

Structured logging also graduated into beta, which means most log messages from kubelet and the kube-scheduler adhere to a defined standard structure now, which is hoped to help with process automation or analytical tasks. The feature also includes an option to produce logs in JSON format, though there’s still some legwork needed to handle corner cases correctly.

With Kubernetes becoming more and more established, it doesn’t come as a huge surprise that most changes in the feature release focus on stabilisation and not so much adding new functionality to the project. If checked closely, the release notes, however, include a couple of smaller new additions which are definitely worth checking out. 

Command line tool kubectl, for instance, has been fitted with a new events command, which is meant to address issues with kubectl get events and could therefore become a useful debugging tool. According to the design document, kubectl events should provide users with better event sorting capabilities and insight into changes, improve the watch behaviour for events, and offer some sort of event timeline once it is complete. 

Events was added as an extra kubectl subcommand to keep things simple, since extending kubectl get would have impacted the way other resources are handled. Other noteworthy enhancements include a gRPC probe, new metrics for the Priority and Fairness API, validation for custom resources and fields in Kubernetes objects, as well as support for generating client-side binaries for the windows/arm64 platform.

As usual, the Kubernetes team also used the release to clean up the project a bit. This time this means preparing FlexVolume and some klog-specific flags for removal by marking them as deprecated. FlexVolume users are advised to start looking into moving their workloads to the CSI driver before the feature is deleted in one of the coming releases. A full list of removals and deprecations can be found in the v1.23 changelog.