Kubernetes 1.35 “Timbernetes” is here. You shouldn’t have to fight to use it.

Kubernetes 1.35, code-named “Timbernetes,” is now shipping. For those of us running large-scale production workloads, this is a significant release. Among the 60+ enhancements, the standout for me is the stable support for in-place vertical resource scaling.

This is a massive quality-of-life improvement for anyone managing stateful services or Java applications. Being able to resize CPU and memory for live Pods without a restart means no more disruptive blips just because you needed to tweak a resource limit. It changes how we operate databases and caches. You can finally tune capacity on the fly without the traditional penalty of temporary capacity loss or cold caches.

But there is a reality check we need to address.

With every major Kubernetes version, the gap between “available” and “usable” grows. Innovation brings complexity. Along with the breakthroughs in 1.35 come the inevitable chores: handling the retirement of legacy controllers, moving off cgroup v1, and navigating a minefield of alpha flags and beta graduations.

For the average platform team, adopting 1.35 isn’t just a matter of clicking “upgrade.” It requires careful planning, checking for deprecated APIs, and rigorous validation to ensure your existing manifests don’t break. It turns your smartest infrastructure engineers into release managers, forcing them to spend cycles on maintenance rather than building the platform your developers actually need.

We take a different approach at Control Plane.

I’ve always believed that infrastructure should be invisible. You shouldn’t have to become an expert in the Kubernetes changelog to benefit from its innovations.

As soon as Kubernetes 1.35 ships, we integrate it into our Universal Control Plane topology. We absorb the operational burden of the upgrade so you don’t have to. Here is what that looks like in practice:

We handle the compatibility matrix. We validate the new release against the cloud providers and runtimes. We deal with the API deprecations and the cgroup shifts. By the time 1.35 capabilities reach your workload, the “breaking changes” have already been resolved at our platform level.

You get the features immediately. You can start using in-place vertical scaling right away. There is no waiting period while your internal team builds a safe upgrade path or creates a new test cluster. We make the capabilities available to your workloads, whether you are running on AWS, GCP, Azure, or on-prem.

The operational experience is uniform. Whether you are a massive SRE organization or a lean startup, you get the same enterprise-grade stability. You don’t need to maintain bespoke upgrade pipelines or complex feature-flagging logic to stay current.

Kubernetes is not slowing down. It is going to keep getting more capable, and consequently, more complex. The vertical scaling in Timbernetes is just one example of how the project is evolving to solve real operational pain points.

But the burden of keeping pace shouldn’t be yours. We built Control Plane to handle the complexity of the infrastructure so you can focus on the complexity of your business.

Enjoy the new features in 1.35. We’ll handle the rest.