Auto-provisioning profiles
Preview: Auto-provisioning profiles are currently in private preview. To enable them on your account, please reach out to Cloudfleet support with your requirements. We are actively working on making this self-service through the API, the console, and the Terraform provider in the very near future.
Auto-provisioning profiles control how the node auto-provisioner behaves when it considers consolidating a Fleet. They give you a knob to trade off aggressive cost optimization against workload disruption, so you can match the auto-provisioner’s behavior to the sensitivity of your workloads.
Background: consolidation
CFKE continuously evaluates whether the current set of nodes in a Fleet is the most efficient way to run your workloads. When it sees that pods could be repacked onto fewer or smaller nodes, it consolidates: pods are evicted from under-utilized nodes, rescheduled onto a tighter footprint, and the freed nodes are removed. Consolidation is the main reason CFKE delivers strong cost efficiency without the user having to right-size anything by hand.
The trade-off is that consolidation involves pod evictions. Workloads that tolerate restarts benefit from aggressive consolidation because they pay a lower infrastructure bill. Workloads that are sensitive to disruption (long-running jobs, stateful services, sessions with warm caches) may prefer a calmer environment, even if it means leaving some headroom on the table.
Available profiles
You can pick the consolidation policy that fits each Fleet:
- Cost-optimized (default): the auto-provisioner consolidates aggressively. It will disrupt and replace under-utilized nodes whenever it detects a cheaper layout, including evicting running pods to repack them onto fewer or smaller nodes. This produces the lowest infrastructure cost but the highest rate of pod evictions.
- Empty-only consolidation: the auto-provisioner only removes nodes that are already empty, for example because their pods finished, scaled down, or moved away on their own. Running pods are never evicted purely for cost optimization. This profile keeps long-running workloads stable at the price of leaving some unused capacity around for longer than the cost-optimized profile would.
Additional profiles will be added as we extend the policy surface.
Picking a profile
The right profile depends on what your workloads look like:
- Stateless services with fast restarts and no warm-cache dependency: the cost-optimized profile is usually the right default. Evictions are cheap and the savings add up.
- Long-running batch jobs, large model training runs, services with expensive warm-up, or workloads with tight SLOs around availability: empty-only consolidation avoids surprise evictions and keeps workloads on stable nodes.
- Mixed clusters: run multiple Fleets, each with its own profile, and use Fleet constraints and pod scheduling rules to direct workloads to the Fleet whose policy fits.
Pod-level controls such as PodDisruptionBudget, terminationGracePeriodSeconds, and the karpenter.sh/do-not-disrupt annotation continue to work alongside profiles. Profiles set the default behavior for the Fleet; pod-level controls fine-tune individual workloads.
Enabling auto-provisioning profiles
Profiles are configured by Cloudfleet during the private preview. To enable a profile, contact Cloudfleet support and share:
- The Fleet you want to apply a profile to.
- The profile you want (cost-optimized or empty-only consolidation).
- Any workloads on the Fleet that are particularly sensitive to disruption, so we can validate the choice fits your environment.
Self-service configuration through the API, the console, and the Terraform provider is on the roadmap and will follow shortly.
Related topics
← Fleets with static capacity
Node regions →