What's New in the Kubernetes 1.28 Second Release

From its humble beginnings, Kubernetes’ growth story continues to be a testament to the power of open-source collaboration, and its current 1.28 second release is certainly no exception. It’s not just a product of ingenious coding but also the sweat and night oil of a global community – from seasoned industry stalwarts to students just making their debut in the open-source world. Everyone in the ecosystem has helped played a role in turning Kubernetes into the forest of versatility it is today.

The industry’s evolution is also a strong reflection of Kubernetes’ journey thus far. As demands grew and challenges became intricate, Kubernetes adapted, evolved, and matured. Its ability to align with the industry’s changing needs showcases its resilience and the relentless efforts of its community. The wider Kubernetes ecosystem is not merely about technology; it’s about people and their undying spirit of innovation and collaboration.

New Features in Kubernetes v1.28

Let’s journey through the array of new and evolving features that Kubernetes v1.28, affectionately termed ‘Planternetes’, offers, each embodying the spirit of collective advancement and ecosystem contributions:

Changes in Supported Skew: Kubernetes v1.28 has broadened the skew between node and control plane components from n-2 to n-3, facilitating compatibility between the oldest node components like kubelet and the newest control plane ones. This adaptation benefits operators who prioritize minimizing node maintenance to reduce disruptions to long-running workloads. With the yearly support period, users can now upgrade thrice annually to align with the latest supported minor version. Notably, v1.28 allows operators to upgrade node versions only once a year while still receiving upstream support, eliminating the previously required double upgrade within close intervals.

Non-Graceful Node Shutdown Recovery: If a node unexpectedly halts due to hardware malfunctions or an unresponsive operating system, the new feature in v1.28 ensures stateful workloads seamlessly restart on an alternate node. However, if the shutdown isn’t detected, StatefulSet pods might linger in a ‘terminating’ state. Additionally, storage complications emerge as previous VolumeAttachments hinder PersistentVolumes from connecting to a functional node, potentially impeding StatefulSet applications. These pods risk being indefinitely ‘Terminating’ unless the malfunctioning node rejuvenates.

CustomResourceDefinition Validation Rules: Incorporating the Common Expression Language (CEL) for custom resource validation has transformed the landscape. This not only streamlines the CRD creation trajectory but also significantly curtails complexities, embodying Kubernetes’ eternal commitment to simplification.

ValidatingAdmissionPolicies Beta: The Common Expression language for admission control offers in-process validation to the Kubernetes API server, serving as an alternative to validating admission webhooks. Leveraging the foundation set by the CRD Validation Rules feature from version 1.25, this focuses on robust policy enforcement capabilities. It streamlines the implementation of customized policies and promotes adherence to best practices in Kubernetes. To utilize this, ensure the admissionregistration.k8s.io/v1beta1 API group and the ValidatingAdmissionPolicy feature gate are enabled in your cluster.

Swap Support on Linux: The new addition brings controlled swap support to nodes, enabling Kubernetes users to conduct tests and contribute data for enhanced cluster functionalities using swap. This caters to both node administrators seeking node-level performance tuning and stability, as well as application developers whose applications gain from utilizing swap memory.

Mixed Version Proxy: During upgrades or changes leading to mixed-version API servers, not every server can serve every resource at every version. With Kubernetes v1.28, the mixed version proxy in the API server’s aggregation layer steps in. This proxy identifies requests the local server doesn’t recognize but another in the control plane can support. It then transparently redirects the request to a compatible server, shielding the client from any disparities. This alpha feature is pivotal in hiding such server version skews from client-side interactions during cluster updates.

Control Plane Components – Code Reorganization: Kubernetes developers are undertaking a revamp of the kube-apiserver’s code, introducing a new staging repository that integrates elements of k/apiserver. This repository will encompass an enhanced, selectively curated subset of kube-apiserver functions for greater reusability. As this transformation progresses, it will culminate in a standalone git repository, spotlighting generic functions derived from the Kubernetes’ API server.

Default StorageClass Enhancement: If a storageClassName isn’t specified for a PersistentVolumeClaim (PVC) in Kubernetes, the system will automatically assign one. This applies not only to new PVCs but also to any existing PVCs lacking a defined storageClassName. While earlier Kubernetes versions exhibited similar behavior, in Kubernetes v1.28, this feature becomes innate and perpetually active, marking its progression to stable or general availability status.

Pod Replacement Policy for Jobs: In Kubernetes 1.28, the Job API has a new field allowing users to choose when new Pods are created: either immediately as old Pods start terminating or after they’ve fully ended. This addresses issues in machine learning frameworks like Tensorflow and JAX where premature pod replacements clashed with lingering predecessors, potentially leading to unwanted scale-ups in resource-constrained clusters.

A New Dawn for Sidecars

Finally making its debut in Kubernetes 1.28 as an alpha feature after much debate, the sidecar KEP introduces nuanced mechanisms to manage container lifecycles, designed with sidecars in mind. This means sidecar containers, designated as “background containers,” start their mission before other containers and conclude only after their companions have finished their tasks. This addresses a majority of the challenges previously faced and makes sidecar management more intuitive and streamlined.

Visualize a pod as a thriving plant. In Kubernetes 1.28, sidecar containers are akin to the sturdy stakes that support a plant, ensuring the blossoming flowers (primary containers) are held upright and displayed beautifully. Their allure stems not just from their supportive role but the elegance with which they nurture growth.

Some things to note when it comes to sidecar containers:

Developer Independence: Instead of amending the application’s core code, a sidecar provides all the necessary auxiliary functions, leaving the application code untouched and uncluttered. Whether your application speaks Python, Go, or any other language, the sidecar’s multilingual proficiency ensures seamless augmentation.

Operational and Security Synergy: The bond between a sidecar and its primary application is almost symbiotic. Operating within the confines of the same pod, a sidecar container inherits the privileges, constraints, and life cycle of the main application, ensuring a unified operational and security front.

Platform-Level Innovations: The sidecar model isn’t just an operational enhancement. It’s a platform for innovation. Beyond the application’s business logic, sidecars open the door to a multitude of platform-level capabilities, laying the groundwork for features that were once thought complex or even unattainable.

Sidecar Challenges

Sidecars have found their mascot in service meshes. Imagine a service mesh as a sophisticated orchestra, and sidecars as its talented musicians, adeptly managing networking tasks, from the intricate dance of mutual TLS between pods to the harmonious symphonies of cross-cluster communication.

However, it’s not all sunshine and roses. Seasoned Kubernetes wranglers would recount the tales of challenges faced in days (and releases) gone by:

Pod Restart Conundrum: The immutable nature of pods in Kubernetes meant that any modification to a sidecar required a full restart of the pod. Although manageable, it’s akin to changing the tires of a car by buying a new car.

Termination Troubles: Sidecars, for all their charm, lacked elegance when it came to graceful terminations. This often resulted in job pods overstaying their welcome.

Startup Sync Snares: A well-coordinated startup is essential. But, sidecars and primary containers sometimes found themselves out of sync, causing potential operational hiccups.

Just scratching the Planternetes surface

Each enhancement and every intricate detail added to Kubernetes speaks volumes about the unwavering commitment and synergy of its expansive community. The journey of Kubernetes isn’t simply marked by technological achievements; it’s a rich tapestry woven from the shared dreams and ambitions of countless contributors. Together, they tirelessly work towards sculpting technology that is increasingly efficient, adaptable, and centered around the needs of its users.

As the realm of Kubernetes continues to expand, opportunities for participation and innovation beckon. Whether you’re a seasoned developer or just beginning your journey, your contributions can help sculpt the future of the wider ecosystem. What better way to familiarize oneself than hands-on experience? Register for a free Lumigo account and deploy Kubernetes 1.28 in a test environment alongside our Kubernetes operator (which can auto trace an entire namespace in a single bound), and experience the prowess of the v1.28 release firsthand.