Kubernetes version 1.31 is scheduled for 13 August 2024. Now widely deployed and increasingly validated through community adoption and contribution, this open source container orchestration technology was originally designed by Google. It was placed with the Cloud Native Computing Foundation (CNCF) for stewardship as the foundation’s seed technology at its inception. Kubernetes releases currently occur three times a year and the lifecycle of each enhancement falls into three central phases: enhancement definition; implementation; and stabilisation. With Kubernetes version 1.31 now set to form part of the operational cloud stack in enterprises everywhere, what do we need to think about in relation to this fundamental technology’s current path?
The Kubernetes project pages tell us that this is an open source and agile project, with feature planning and implementation happening at all time. Given the project’s scale and its globally distributed developer base, it is critical to project velocity to not rely on a “trailing stabilisation phase”… rather then, the project works by having “continuous integration testing” which is designed to help ensure the technology is always stable so that individual commits can be flagged as having broken something, if and when needed.
Kubernetes versions are logically labelled under the numerical naming convention x.y.z, where x is the major version, y is the minor version and z is the patch version.
Red Hat: new workloads
“Red Hat is excited about the release of Kubernetes 1.31,” said Mike Barrett, VP and general manager of Red Hat Hybrid Platforms. “Many in our community believe Kubernetes was originally designed for the world’s web services and existing application patterns. However, this year, AI and machine learning have emerged as significant new workloads, requiring different demands on the Kubernetes platform.”
In Kubernetes 1.31, Barrett says we are seeing highlight improvements in the Dynamic Resource Allocation (DRA) implementation, which simplifies requesting and sharing machine-level resources like GPUs in a distributed system.
“Enhancements in GPU management, device selection and scheduler behaviour improve user and administrator coordination,” he said. “Additionally, Custom Resource Field Selectors and Authorize with Selectors enable secure targeting of specific nodes for hardware accelerators, critical for inference workloads. These features collectively enhance Kubernetes 1.31’s ability to securely run AI workloads, a development we are very excited about.”
Craig Box, senior director of developer relations at Solo & CNCF governing board member is similarly upbeat. He suggests that Kubernetes’ mature design as a host for APIs means that the community is able to do much of its work outside of the regular release cycle.
Iterate at your own pace
“One of the largest advances to Kubernetes over the past five years has been the Gateway API; conceived of as an ‘ingress v2’, it was developed as an external API, rather than being tightly coupled to the core,” said Box. “That means it can iterate at its own pace and version 1.1 was released in between Kubernetes 1.30 and 1.31. It can be installed onto any of the most recent five versions of Kubernetes, reducing the need for users to upgrade clusters to use its new features. Getting on board with the Gateway API simplifies the configuration of service mesh and means you can use one language to configure dozens of supported projects.”
Head of developer relations at New Relic Jemiah Sius concurs with Solo’s Box and says that to enhance the adoption and usage of Kubernetes 1.31, reducing complexity and lowering the barrier to entry should be a top priority and will be key for attracting less experienced users.
“By introducing features like improved default configurations, continual improvement of documentation, streamlined deployment processes and advanced security measures, Kubernetes can become more accessible for new users while providing the tools for seasoned professionals to build and maintain robust and resilient applications. Enhancements in scalability, multi-cluster management and native support for serverless workloads will further drive its adoption across diverse industry sectors,” suggests Sius.
A Kubernetes wish list
For many developers, the most ‘missed feature’ thus far was the sidecar container designation, which was made available in version 1.29 and we can also note that volume snapshots are already available as CRDs but only for CSI drivers. Thinking about what he would like to see brought to the table, cofounder and CTO of Daytona Vedran Jukic says that cross-cluster networking can now be achieved via kubefed or a service mesh, but built-in multi-cluster management would be a great addition.
“Additionally, zero trust networking, better auditing, and reporting are always goals to strive for. I would like the ability to change the Storage Class of existing Persistent Volumes (PVs) and improved handling of stateful workloads in terms of scaling and updating,” said Jukic. “Regarding volume backups, setting up and managing volume snapshots and backups in Kubernetes often requires third-party tools and extensive configuration, which lack native automation for routine tasks. While Kubernetes has a VolumeSnapshot API, more robust and feature-rich native support would be beneficial, including better integration with various storage providers.”
His comments also resonate with Rashmi Agrawal, vice president of engineering for application modernization at Rocket Software. Noting that ‘we’ [developers] today depend heavily on Kubernetes Clusters to build and maintain test environments for enterprise products with different cloud providers, Agrawal still has an eye on the future for this technology.
A more cloud-neutral future
“The performance optimizations that Kubernetes 1.31 brings in will help us make the overall deployment of our test environments more scalable and efficient in terms of resource utilization and response times, improving overall productivity,” he said. “Additionally, refined observability tools with this new version would help us maintain and monitor our cluster deployments better. With 1.31, Kubernetes would be even more cloud-neutral which would help us build something for our customers to ease out deployments of our products across different cloud providers’ infrastructure more effectively and quickly. Security improvements in this version would help us with compliance activities.”
It is these comments on the possibility of an (even) more ubiquitous Kubernetes are validated and help to steer (pun intended) it towards an even more open universe of open source that sees the technology evolve to a more cloud-neutral status (something that has been happening since version 1.26), then this must be a good thing.
If this progression happens in line with the community also tackling the perpetual perception of complexity, we may really be defining where Kubernetes goes next. When we feel like Kubernetes is free enough to be cloud-neutral enough to unshackle itself from being tied to specific cloud platforms with the proprietary code responsibilities that this entails… then Kubernetes may truly be able to set sail on the open seas.
