The highlighted Feature

The feature I want to highlight in this 1.28 release is  the sidecar support refered in in KEP #753.

Running Sidecars in Kubernetes; Pre and Post 1.28 Release

Pre Kubernetes 1.28

Until the 1.28 release Kubernetes did not have a concept of sidecars. The term "sidecar" was more of a pattern than a built in feature. Sidecars were containers that operated alongside the main application container within the same pod. They were utilized to enhance the functionality of the application without necessitating any modifications to its code. However this approach presented challenges;

Pod Restart; Upgrading a sidecar necessitated restarting the pod, including the application container.

Job Termination; Kubernetes did not provide a means to signal termination to the sidecar, which caused complications with jobs that were expected to terminate upon completion.

Startup Race Conditions; Kubernetes did not guarantee the order in which regular containers started potentially causing issues if the main application relied on initialization of the sidecar.

Post Kubernetes 1.28

With the introduction of the KEP #753 in version 1.28 significant changes have been implemented. This KEP formally incorporates sidecars into the Kubernetes API addressing many of these aforementioned challenges;

Container Ordering; In Kubernetes 1.28 and onwards new functionality allows for specifying an ordered initialization and termination sequence, for containers, including sidecars. This resolves any race conditions during startup.
Ending a Job; The introduction of the sidecar functionality offers a solution, to the problem of Jobs running indefinitely by providing a way to signal the sidecar when it should terminate.

Managing Pods; The update provides control, over pod behavior allowing for precise management of sidecars without impacting the main application container.

About the Author