Kubernetes is steamrolling ahead with great new features. It’s important to check the changelog frequently, not only to see what’s coming up, but also to catch bugs and security patches that matter to most users.

kubernetes/CHANGELOG/CHANGELOG-1.33.md at master · kubernetes/kubernetes

I would like to focus today on the features that interest me the most and why I find them useful.

In-place pod vertical scaling

Let’s start with my most-awaited one. There are many settings in pods that are immutable. It means that once the pod has been scheduled (usually through a Deployment or StatefulSet) cannot be modified, and it must be replaced by another one with the changed settings. You do this by modifying the Deployment or StatefulSet and allowing it to roll out the new pods.

One of the settings that is very useful to be able to modify in-flight (no pod restarts) is the memory and CPU usage.

Why is this important to me? More often than not, the amount of memory or CPU that a pod is going to consume is predictable based on historic trends and adjusted using resource requests a limits. This is, in general, a good practice to avoid pods consuming more resources than they require and affecting other workloads in the cluster.

However, on some occasions, you may need to adjust some pods without restating them due to, for example, one-off traffic increases, and you don’t want to affect your clients whilst you do it.

Another common example is using tools that promise cost savings by adjusting memory and CPU settings, such as Vertical Pod Autoscaling. These tools often adjust aggressively, causing frequent pod restarts. Now, pods don't need to be restarted, allowing you to effectively eliminate wasted costs.

Sidecar containers

A sidecar container is a helper container that runs in the same Pod as the main application container. It adds extra features like logging, monitoring, security, or data syncing without changing the main app’s code.

A very common example of this for you to better visualise it is a pod that runs a NodeJS application, but you want to front it with a customised proxy like NGinX.

With Kubernetes 1.33, native sidecar containers are supported. This introduces a new restart policy, Always, for init containers. These containers start before regular containers, continue running for the entire lifetime of the pod, and only terminate after all other containers have exited. This change provides clear lifecycle management for sidecars, removing the need for custom scripts or startup delays. It also improves reliability and observability, making it easier to understand pod behaviour and better supporting use cases such as service meshes, log collection, and monitoring agents.  

Topology-Aware Routing

Topology-Aware Routing is a feature that improves how traffic is routed to services based on the location (topology) of the client and the endpoints. It’s especially useful in multi-zone or multi-region clusters where cross-zone traffic can be costly or introduce latency.

It allows Kubernetes to prefer endpoints that are "closer" to the client, typically in the same zone or region, when routing traffic to a service.

trafficDistribution: PreferClose: This new setting in Kubernetes 1.33 tells kube-proxy to prioritise endpoints in the same zone as the client.

‍

Why is this feature important for me and my customers?

Most of our customers are running their clusters in multiple regions and zone to high availability. This may be using a Cloud provider, a European provider or on-premises data centers.

If you are in the cloud using one of the hyperscalers you’ll probably notice that the latency is quite low between zones but this may not always be the case depending on where you have your cluster running. This feature allows you to keep the traffic between pods in the same zone or region local reducing the latency in your traffic.

Courtesy of Cilium 1.16 - High-Performance Networking With Netkit, Gateway API Gamma Support, BGPV2 and More!

In Kubernetes 1.33 with topology-aware routing, another important factor is that many cloud providers charge fees for data traffic moving between zones or regions. By keeping traffic within the same zone or region where your clients are running, you can significantly reduce these cross-zone or cross-region data transfer costs. This approach helps lower your overall cloud expenses while improving application performance by minimising unnecessary data movement outside of the local zone or region.

User namespaces

Security… don’t get me started. It’s 2025, AI is plotting to take over the world, and I’m still here fighting the good fight to make sure our customers stick to security principles and don’t get lazy.

A pod running as root inside a container has the equivalent of system administrator privileges. This means it can perform any action on the container and can potentially affect the host system if it escapes the container isolation. Root access allows reading/modifying system files, installing malware, opening any network connections, and more, unrestricted by typical user-level permission boundaries.

What’s more, if a root pod has mounts to host directories (e.g., hostPath volumes like /var/log), it can manipulate or read host files, including sensitive data such as /etc/passwd or SSH keys, thereby facilitating privilege escalation or lateral movement.

Kubernetes v1.33 just flipped the switch on user namespaces by default. Basically, it’s like giving containers fake IDs so when they act like root inside, the host sees them as regular, non-threatening users. This means even if a container goes rogue and claims it’s the boss inside, it can’t boss the host around.

Conclusion

There are a few more features we could explore, such as the HorizontalPodAutoscaler’s tolerance settings, though I personally lean toward using KEDA instead. It’s worth keeping in mind that Kubernetes upgrades aren’t just about shiny new features. They’re also critical for security. I know the process can be tedious and sometimes tricky, but it’s a task that shouldn’t be put off.

Contact our team for a free consultation to discuss how we can tailor our approach to your specific needs and challenges.

I, for one, welcome our new robot overlords

‍