Arrival of Kubernetes 1.34 Simplifies Raft of Management Challenges
The Technical Oversight Committee (TOC) for Kubernetes today released an update to the platform that adds and revises application programming interfaces (APIs) to resolve a range of performance, management and cybersecurity challenges.
Vyom Yadav, release lead for Kubernetes 1.34 and security engineer for Canonical, said this latest update, dubbed Of Wind & Will (O’ WaW), is well-rounded in the sense that there are additions that address a wide range of challenges, including new stable capabilities such as Dynamic Resource Allocation (DRA), which makes it possible to flexibly categorize, request, and use, for example, graphics processing units (GPUs) or other types of custom hardware added to a Kubernetes cluster.
Other capabilities that are now stable include an ability to create replacement pods only when the previous pod is fully terminated, a mechanism to cancel storage volume expansions, a Sleep action for PreStop and PostStart lifecycle hooks that enables containers to shut down more gracefully, and a Linux node swap capability that prevents workloads from being abruptly terminated when pods run out of memory.
In total, there are 58 enhancements, with 13 of them representing net new capabilities that are being alpha tested, including KYAML, a dialect of YAML specifically designed for Kubernetes.
There is also a Resource Health Status tool for DRA that improves observability by exposing the health status of devices allocated to a pod and an alternative extended resource mapping tool for describing resource capacity and consumption. Additionally, a DRAConsumableCapacity feature gate will allow resource drivers to share the same device, or a slice of a device.
Kubernetes 1.34 also adds, in alpha, a ContainerRestartRules feature gate that makes it possible to apply a restartPolicy for each container within a Pod along with an EnvFiles feature gate that provides the ability to declare environment variables at runtime.
Also in alpha is a built-in mechanism for Pods to obtain X.509 certificates via PodCertificateRequests.
Capabilities that were previously added have been elevated to beta to define specific resource requirements for pods to reduce over provisioning of infrastructure and a Snapshottable API server cache that now starts without snapshots. Instead, it creates a new snapshot on every watch event and keeps them until it detects that an etcd key-value store is compacted or if cache is full with events older than 75 seconds. If the provided resourceVersion is unavailable, the server will fallback to etcd.
Other capabilities in beta include an ability to limit requests at the pod-level resource requests, an updated kubelet’s API to monitor how Pod resources are allocated through DRA, and a more secure implementation of kubelet credential providers API for pulling private container images without exposing secrets.
Finally, the TOC also announced that a forthcoming 1.36 release of the platform will be the last to support the containerd runtime.
Of course, many IT teams are still running clusters based on much earlier versions of Kubernetes. Each of them will need to determine to what degree it makes sense to upgrade their clusters or simply start over by tearing them down altogether in favor of running a more recent Long Term Release (LTR) version of Kubernetes, noted Yadav.
Regardless of approach, the one thing that is certain is the older the version of Kubernetes running in a production environment, the more difficult it will be to maintain and secure.
