.png)
Table of Contents
Kubernetes gives us the primitives to scale workloads elastically, but as any platform engineer knows, the devil is in the details. Scaling isn’t just about pods and deployments — it’s also about nodes, the physical or virtual machines where those pods actually run.
That’s where things start to break down once you leave the warm comfort of managed cloud services.
The Limits of Kubernetes Autoscaling Today
If you’re in a managed environment like AKS or EKS, you can lean on tools like Karpenter for dynamically provisioning nodes when pods can’t be scheduled.
Karpenter is a great tool, but those implementations are tightly bound to the service provider. If you need to autoscale workloads in a private cloud, you’ll end up writing brittle scripts or managing clunky node pools. Running on bare metal? You’re mostly on your own. Trying to span multiple clouds? Now you’re juggling APIs, policies, and scaling models that were never designed to work together.
The reality is that Kubernetes’ elasticity story stops at the provider boundary. Platform teams are left stitching together custom scaling logic — or worse, giving up on autoscaling entirely.
The Over-Provisioning Tax
Without reliable autoscaling, the fallback is obvious: provision for peak demand and accept the waste.
Every platform engineer has seen it:
GPU nodes sitting idle between machine learning training runs.
CI/CD test clusters holding on to compute capacity “just in case.”
Isolated environments over-provisioned because scaling them independently isn’t practical.
This “over-provisioning tax” shows up as wasted compute, inflated cloud bills, and inefficient hardware usage in private datacenters. It’s the opposite of the efficiency Kubernetes was meant to deliver.
The Isolation Challenge
Isolation makes this problem worse — and more necessary.
With the introduction of Private Nodes, vCluster allows teams to join dedicated Kubernetes nodes directly into a virtual cluster. That was a huge step forward: you could finally run workloads in fully isolated, single-tenant environments while still benefiting from vCluster’s lightweight, containerized control plane.
But here’s the catch: once you dedicate nodes to each virtual cluster, you’ve multiplied the scaling problem. Each private node is provisioned and each virtual cluster is added manually. An admin has to ssh into that node and join the virtual cluster by hand.
A Real-World Scenario
Imagine this: your data science team is training GPU-heavy models. During the day, they rely on on-prem GPUs in your private datacenter for compliance reasons. At night, when usage spikes, they want to burst into GKE to grab extra GPU nodes.
On paper, this should be straightforward — Kubernetes promises portability, right? In practice, it’s a nightmare:
GKE can autoscale, but only inside GCP.
Your private cloud GPUs have to be managed manually.
Workload isolation means you can’t just pool everything together — each team needs its own environment.
You’re left cobbling together scripts, juggling two scaling models, and wasting resources in both places just to cover the gaps.
Why We Need Auto Nodes
As Kubernetes adoption spreads into hybrid and multi-cloud setups, and as isolation becomes non-negotiable for secure tenancy, the cracks in the current scaling model are impossible to ignore.
We need a way to bring together:
The isolation of private nodes,
The elasticity of just-in-time autoscaling, and
The portability of an environment-agnostic approach.
We need dynamic scaling with Auto Nodes.
Auto Nodes are just the next step in the evolution of Kubernetes tenancy brought to you by vCluster. In the coming days, we’ll share more about the upcoming Auto Notes feature. Stay up to date on the latest news in the Future of Kubernetes Tenancy Launch Series where we’ll dive into the details of all the exciting new features coming to vCluster.
Don’t miss the Launch Series webinar: Future of K8s Tenancy v0.28 Auto Nodes on September 19 where Mike Petersen, Sr. Technical Marketing Engineer at vCluster, will sit down with Lukas Gentele, CEO and Co-founder of vCluster, and Pascal Breuninger, Technical Team Lead at vCluster, to discuss how Auto Nodes will take us into the future of Kubernetes tenancy.
Auto nodes will be available as part of vCluster v0.28 and vCluster Platform v4.4, which will go live on September 9, 2025.
.png)