Fleets with static capacity

Preview: Fleets with static capacity 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.

A standard Fleet provisions nodes elastically based on workload demand: nodes are added when pods need them and removed when they are no longer required. Fleets with static capacity extend this model with a reserved baseline. You can declare that a Fleet should always keep a fixed number of nodes of a specific instance type, cloud, and region available, similar to a traditional Kubernetes node pool.

When to use static capacity

Elastic provisioning is the most cost-efficient default, but some workloads need capacity to be ready before traffic arrives. Static capacity is suitable when:

  • Latency-sensitive services must respond within milliseconds and cannot wait for a new node to boot during scale-up.
  • Cold-start-intolerant applications, such as long-warm-up JVMs or large model servers, need pre-warmed nodes to absorb load spikes.
  • Reserved instance commitments with a cloud provider need to be matched by always-on nodes to capture the discount.
  • Predictable baseline workloads run continuously and benefit from reserved capacity at a known cost rather than fluctuating elastic provisioning.
  • Strict failover requirements mandate that replacement capacity is available immediately, without a provisioning delay.

For workloads that scale up and down with traffic, regular auto-provisioned Fleets remain the better choice.

How static capacity works

A Fleet with static capacity holds two layers of nodes:

  1. Static nodes: a fixed-size pool of nodes with a specific instance type in a specific cloud and region. CFKE keeps this pool at the requested size, replacing nodes that fail or are removed by the cloud provider.
  2. Auto-provisioned nodes (optional): elastic capacity provisioned on top of the static pool when pod demand exceeds what the static nodes can serve.

Static and auto-provisioned capacity coexist in the same cluster. You can run a Fleet with only static capacity, only auto-provisioned capacity, or a mix, and you can have multiple Fleets with different mixes in the same cluster. This makes it straightforward to combine, for example, a reserved baseline of 10 latency-critical nodes with elastic burst capacity for batch jobs.

Pods schedule onto static nodes the same way they schedule onto auto-provisioned ones, using the same Kubernetes scheduling rules. From the pod’s perspective there is no difference between the two; the distinction only affects how CFKE manages the underlying infrastructure.

What you specify

When you set up static capacity, you provide:

  • Number of nodes to keep running at all times.
  • Instance type for those nodes, for example m7i.xlarge on AWS or cpx41 on Hetzner Cloud.
  • Cloud and region where the nodes should live.
  • Optionally, labels and taints to apply to the static nodes so workloads can target or avoid them.

Static capacity respects the Fleet’s constraints, so the instance type, cloud, and region you choose must fall within whatever the Fleet is allowed to provision.

Enabling static capacity

Static capacity is configured by Cloudfleet during the private preview. To enable it, contact Cloudfleet support and share:

  • The Fleet you want to add static capacity to.
  • The instance type, cloud, region, and number of nodes you need.
  • Any labels or taints you want applied to the static nodes.
  • Whether the Fleet should also keep auto-provisioned capacity for elastic scaling.

Self-service configuration through the API, the console, and the Terraform provider is on the roadmap and will follow shortly.

Previous
← Fleet constraints
Next
Auto-provisioning profiles →
On this page