Dynamic Boot Disk Sizing

Dynamic boot disk sizing lets CloudPilot AI choose the system disk size for each newly provisioned node instead of assigning one fixed size to every node. It is supported for:

• AWS EBS root volumes
• GCP boot disks
• Azure OS disks

The policy is optional. If it is not configured, CloudPilot AI preserves the existing static disk-size behavior.

Configure the policy

Open Rebalance Configuration, edit or create a NodeClass, and locate the storage settings:

1. Set the provider’s base disk size.
2. Set Dynamic size per vCPU. Leave it empty or set it to 0 if the disk should grow only for workload storage demand.
3. Set Dynamic maximum size to enable the policy.
4. Save the NodeClass.

Clearing Dynamic maximum size disables the policy. A policy change applies to future nodes; it does not resize or replace existing nodes by itself.

The provider-specific fields are:

Policy values are expressed in GiB. On Azure, the existing base field remains named osDiskSizeGB, while dynamic policy calculations use GiB.

How the size is calculated

For a selected instance type, CloudPilot AI first calculates a CPU-based target:

cpuTarget = min(baseSize + perVCPUGiB * vCPUCount, maxSizeGiB)

When the system disk backs Kubernetes ephemeral storage, CloudPilot AI also considers the NodeClaim’s ephemeral-storage request. The resolved disk is the smallest supported size that:

• is at least cpuTarget;
• provides enough allocatable ephemeral storage after kubelet reservations and eviction thresholds; and
• does not exceed maxSizeGiB.

For example, with a 50 GiB base, 5 GiB per vCPU, and a 200 GiB maximum, a 4-vCPU node starts with a 70 GiB CPU target. If the NodeClaim needs more ephemeral storage, CloudPilot AI can increase the disk up to 200 GiB. If the request still cannot fit at the maximum, that instance option is rejected as insufficient capacity.

maxSizeGiB is a cap, not a reason to reject a large-CPU instance. If the CPU formula exceeds the maximum, the CPU target is capped at the maximum. Only actual storage demand that cannot fit within the maximum makes the option ineligible.

Pod requests

Set an ephemeral-storage request when a workload depends on node-local scratch space:

apiVersion: v1
kind: Pod
metadata:
  name: scratch-example
spec:
  containers:
    - name: worker
      image: busybox:1.36
      command: ["sh", "-c", "sleep 3600"]
      resources:
        requests:
          ephemeral-storage: 80Gi
        limits:
          ephemeral-storage: 100Gi

Only resources.requests.ephemeral-storage reserves scheduling capacity. A limit or emptyDir.sizeLimit controls usage but does not replace the request.

Provider examples

AWS

Configure the policy on the root EBS mapping. If there are multiple block device mappings, set rootVolume: true on the mapping that owns the policy. Only one mapping can define volumeSizePolicy.

spec:
  blockDeviceMappings:
    - deviceName: /dev/xvda
      rootVolume: true
      ebs:
        volumeSize: 50Gi
        volumeType: gp3
        volumeSizePolicy:
          perVCPUGiB: 5
          maxSizeGiB: 200

volumeSize is required and remains the base. maxSizeGiB must be at least the base size and must be valid for the selected EBS volume type.

If instanceStorePolicy: RAID0 is enabled and the selected instance has local NVMe storage, Pod ephemeral-storage requests are satisfied by the instance-store filesystem and do not grow the EBS root volume. The root volume still follows the CPU-based target.

GCP

Configure the policy on the boot disk. Only one disk can define sizePolicy, and that disk must have boot: true.

spec:
  disks:
    - sizeGiB: 50
      category: pd-balanced
      boot: true
      sizePolicy:
        perVCPUGiB: 5
        maxSizeGiB: 200

sizeGiB is required and remains the base. maxSizeGiB must be at least the base size.

When Local SSD-backed ephemeral storage is enabled, Pod ephemeral-storage requests constrain Local SSD capacity instead of growing the boot disk. The boot disk still follows the CPU-based target. See Local SSD Ephemeral Storage.

Azure

Configure the policy directly on the AKSNodeClass:

spec:
  osDiskSizeGB: 128
  osDiskSizePolicy:
    perVCPUGiB: 8
    maxSizeGiB: 512

If osDiskSizeGB is omitted, the provider’s 128 GB default is used as the base. maxSizeGiB must be at least the base size and cannot exceed 2048 GiB.

Limits and validation

Cloud-provider and disk-type restrictions still apply. A configured maximum does not guarantee that every instance type, disk type, or region supports that size.

Existing nodes and policy changes

• The policy affects only newly provisioned nodes. Existing disks are not resized in place.
• Changing or removing only the policy does not mark existing NodeClaims as drifted.
• Existing nodes created with dynamic sizing continue to report their actual disk capacity after the policy is edited or removed.
• Nodes created before the policy was enabled keep their original static capacity.
• After the policy is disabled, future nodes return to the configured static base size.

Verify the result

After CloudPilot AI provisions a new node, inspect its Kubernetes-visible storage:

kubectl get node <node-name> \
  -o jsonpath='{.status.capacity.ephemeral-storage}{"\n"}{.status.allocatable.ephemeral-storage}{"\n"}'

Then confirm the root, boot, or OS disk size in the cloud provider console. Kubernetes allocatable storage is normally lower than the raw disk size because the operating system, filesystem, kubelet reservations, and eviction thresholds consume part of the disk.