Kubernetes 1.23 Stabilizes Dual Stack Networking and Advances on PodSecurity • DEVCLASS


The team behind the Kubernetes Container Orchestrator closed the year with a latest release of feature, which sees long-requested features mature and pushes the project one step closer to becoming the boring staple it was meant to be. to be.

Kubernetes is an open source project initiated by Google for the planning and orchestration of containers, and one of the flagship projects of the Cloud Native Computing Foundation. Version 1.23 is the third and final release for 2021, following a new, slower release pace intended to provide end users with slightly longer support windows and take the pressure off its contributors.

Look at the project changelog, a lot of the extra time seems to have been spent on stabilizing functionality, so for example, dual-stack networking functionality should now be suitable for production use.

The feature enables IPv4 and IPv6 communications “in parallel, for pods and services” and can be used in scenarios that legally require IPv4 clients and services only. To support this behavior, the Service API is equipped with an ipFamilyPolicy field, which can be set to SingleStack, PreferDualStack, or RequireDualStack, the default being single-stack.

Teams that have been waiting to use generic ephemeral volumes or version 2 of HorizontalPodAutoScaler in their production environments should be able to do so safely now, as they are also part of the features that have moved to GA status.

With PodSecurityPolicy marked for removal in Kubernetes 1.25, admins will be happy to see its successor, the PodSecurity admission controller, go into beta with version 1.23. The corresponding feature gate is on by default now, and if things are progressing at the current rate, there’s a good chance PodSecurity will hit its goal of 1.24 for a stable first release. Big changes aren’t expected until then, but the team has yet to gather feedback on the current implementation and work on their compliance test plan to achieve their goal.

Structured logging has also moved to beta, which means that most log messages from kubelet and the kube-scheduler now adhere to a defined standard structure, which should help with process automation or analytical tasks. The feature also includes an option to output logs in JSON format, although there is still work to be done to properly handle corner cases.

With Kubernetes becoming more established, it’s no surprise that most of the feature release changes focus on stabilizing and not adding new features to the project. If checked closely, however, the release notes include a few new, smaller additions that are definitely worth checking out.

The kubectl command-line tool, for example, has been equipped with a new events command, intended to troubleshoot issues with get kubectl events, and therefore could become a useful debugging tool. According to the design document, kubectl events should provide users with better event sorting capabilities and preview changes, improve event monitoring behavior, and provide some sort of event timeline after it is completed.

Events have been added as an additional kubectl subcommand to simplify matters, as extending kubectl get would have impacted how other resources are handled. Other notable improvements include a gRPC probe, new metrics for the Priority and Fairness API, validation of resources and custom fields in Kubernetes objects, and support for client-side binaries for the platform. -form windows / arm64.

As usual, the Kubernetes team also used the release to clean up the project a bit. This time it means preparing FlexVolume and some klog-specific flags for deletion by marking them as obsolete. FlexVolume users are advised to start considering moving their workloads to the CSI driver before the functionality is removed in any of the future releases. A full list of deletions and deprecations can be found in v1.23 changelog.