What’s new in Kubernetes 1.28: Sidecar containers and fewer disruptions
Kubernetes 1.28—codename “Planternetes”—dropped on August 15th. The release brings 12 enhancements to Stable status, including several that should mark significant quality of life improvements.
Let’s take a look at some of the most notable changes and enhancements:
Expanded control plane and node version skew
First off, Kubernetes has expanded the supported skew between control plane and node versions by one minor version.
Previously, worker node versions could lag two minor versions behind a control plane on the latest supported release. Now nodes can run three minor releases behind, giving teams a little more runway for upgrades—which will be especially welcome to operators who want to minimize disruption of nodes with critical workloads.
Recovery from non-graceful node shutdown (GA)
Speaking of minimizing disruption, an enhancement for recovery from non-graceful node shutdown is graduating to Stable. This lets stateful workloads fail over to a new node if the original hits a major snag like an OS or hardware crash. The now-graduated recovery feature can even be helpful in some cases of intentional node shutdown where the kubelet might not have registered the shutdown.
Previously, pods belonging to a StatefulSet could get stuck in a Terminating state indefinitely. With this new stable enhancement, you can mark a node as out-of-service, clean up the mess from the old node, and initiate recovery to the new one.
Retroactive default storage class (GA)
Another nice quality of life feature graduating to stable is the automatic assignment of a default StorageClass for PersistentVolumeClaims, in cases where you don’t provide a value. This feature is also retroactive, so the control plane goes back and does the same thing for any existing PVC without a StorageClassName.
API awareness of sidecar containers (alpha)
One really interesting new alpha feature enables users to define sidecar containers in specifications. This new feature gate helps set an appropriate lifecycle for sidecar containers in multi-container pods that might help in configuration, networking, log and metrics collection, and so on, and will be particularly useful in sidecar-heavy realms like service mesh. Check out our blog on this new feature to learn more.
Job policy options for pod replacement (alpha)
When running certain workloads—including popular machine learning systems like Tensorflow—it’s important to ensure that a terminating pod is completely terminated before instantiating a replacement. But that’s not the default behavior.
With this alpha enhancement, a new field for Jobs makes it possible to specify whether a replacement pod should be spun up as soon as its predecessor begins to terminate, as usual, or once it has completed the termination process. This provides more flexibility for managing those finicky workloads as well as tuning systems to remain within a very specific band of resource usage.
There are more features to explore – if you’re interested, check out the official release blog.