Kubernetes version 1.28, just came out. The latest version is called Planternetes, in part because a lot of the maintainers of Kubernetes are getting really into the idea of ensuring that Kubernetes is running as effectively and efficiently as possible.
In this post, I highlight a few of the great features and updates in version 1.28, their impact, and how they make the lives of engineers better and easier. For more information about the Kubernetes v1.28 release, you can check out the link here.
1. Sidecar Support
Sidecar support is arguably one of the most awaited features in Kubernetes.
When sidecar containers are discussed, it means that there is more than one container inside of a Pod. From a management perspective, a Kubernetes Pod is the smallest unit available to manage. What that means is you manage Pods, not the containers inside of the Pod. A sidecar container means a container running inside of a Pod that’s separate from the application container.
Sidecar containers are very popular for supporting features like logging mechanisms or using a Service Mesh. For example, with a Service Mesh, the sidecar container contains the configurations/policies from the Service Mesh to embed into the Pod.
The biggest problem with sidecar containers is race conditions. One container is expected to start for the other container to work properly, but it doesn’t so there’s some type of failure or bug that needs a work-around. With the new sidecar KEP, there’s a sort of “background container” that runs to avoid the race condition.
2. Swap On Linux
Since its inception, Kubernetes has not supported swapping on Linux. Swapping is the ability to use hard drive space as memory/RAM if you run out of available memory/RAM on your server. This means that if you create a Kubernetes cluster, you have to turn off swapping. This could be done with sudo swapoff -a which isn’t hard coded because it resets as soon as you restart the server, or you could turn it off permanently.
Although swapping shouldn’t be used as an alternative to proper memory/RAM in every case, it is good to have if you run out of memory faster than expected and need time to upgrade the memory. The other scenario is developers could be testing a new app or an update to an existing app and it takes more memory than originally expected, which means they would have to use swap. Unfortunately, Kubernetes never supported it.
In v1.28, that’s changing. Beta support for memory swapping is now available. Please note that this is still beta, so there may be some unexpected bugs that will need to be patched.
3. Supported Skew Versions
Kubernetes has notoriously been a major headache when upgrading. Whether it’s a Managed Kubernetes Service or an on-prem Kubernetes service, most engineers end up running into issues when they upgrade.
One of the things that can help from an upgrade perspective is the ability to now be one minor version behind between the Control Planes and the Worker Nodes. Originally, Control Planes and Worker Nodes had to be on the same version of Kubernetes and they have to be upgraded separately as it’s different binaries.
Now, you can upgrade the Control Plane components by themselves. Once you confirm all of that has gone well, you can plan for, prep, and upgrade the Worker Node components.
This helps from a stress perspective as the Worker Node is where the workloads (Pods, Deployments, Services, etc.) are running, so this feature now gives engineers the ability to stagger their upgrades vs having to do it all in one shot.
Although it’s now possible, you should still plan to upgrade the Worker Nodes as quickly as possible after the Control Plane.
4. CRD Updates
One of the most important reasons why engineers use Kubernetes, outside of it being the standard for container management, is customization. The whole idea of Kubernetes is to extend the API and work with it in any way you’d like. This could be anything from creating a new workflow to creating a new tool that runs on Kubernetes.
One of the most used ways of doing this is via a Custom Resource Definition (CRD).
Originally, engineers would have to write a webhook to validate the resources within the CRD using the Common Expression Language (CEL). Now, with Kubernetes v1.28, you can add validation expressions directly to the CRD. That way, you don’t have to worry about writing any extra/external code for the webhook as it’s all done directly in the API definition.
