Local SSD Ephemeral Storage

CloudPilot AI can use node-local NVMe SSDs as Kubernetes ephemeral storage. When enabled, ordinary Pod emptyDir volumes, writable container layers, downloaded images, container runtime data, and Pod logs use the local SSD-backed node filesystem. Workloads do not need to format devices, mount disks, use hostPath, or run privileged setup containers.

Local SSD is useful for workloads that need high-throughput, low-latency temporary storage, including:

• build and CI workspaces;
• data processing, sorting, and shuffle operations;
• machine learning data staging;
• local caches;
• temporary database or analytics files; and
• workloads with large container images or heavy writable-layer I/O.

Supported providers

CloudPilot AI automatically updates the NodeClass and its referencing NodePools when this feature is enabled. The NodePool is constrained to instance types that can provide Local SSD-backed ephemeral storage, and the provisioned node advertises the resulting capacity through the standard Kubernetes ephemeral-storage resource.

Node storage layout

GKE and EKS expose the same Kubernetes ephemeral-storage behavior, but they do not use the same physical mount layout:

As a result, downloaded container images, container writable layers, disk-backed emptyDir volumes, container runtime data, and Pod logs use Local SSD on both providers. Workloads should use Kubernetes APIs instead of depending on the provider-specific device or physical mount path.

Image Accelerator compatibility

Local SSD is compatible with CloudPilot Image Accelerator. Image Accelerator reads the node’s existing containerd content store at /var/lib/containerd/io.containerd.content.v1.content through the containerd socket. Because that path is under /var/lib/containerd, image blobs served to peer nodes are stored on Local SSD when this feature is enabled. On a receiving node, containerd writes accelerated image content into that node’s same Local SSD-backed content store. Image Accelerator does not require a separate SSD mount or a duplicate image cache.

Container images, writable layers, emptyDir volumes, and Pod logs share the node’s Local SSD capacity. Keep enough headroom for image downloads, image garbage collection, logs, and system use when setting workload requests and NodePool capacity constraints.

Configure Local SSD in the console

Open Rebalance Configuration, edit or create a NodeClass, and locate Local SSD ephemeral storage in the storage section.

1. Enable Local SSD ephemeral storage.
2. For GKE, either leave Local SSD count blank or enter a count. These modes have different provisioning behavior, as described below.
3. For EKS, select an AL2023 node image. EKS does not expose a Local SSD count field.
4. Save the NodeClass. CloudPilot AI updates every managed NodePool that references it.

Disabling the feature removes CloudPilot-managed Local SSD settings from the NodeClass and its referencing NodePools. Newly provisioned nodes then use the normal boot-disk-backed ephemeral storage path.

GKE provisioning behavior

GKE supports two Local SSD configuration modes. The presence of ephemeralStorageLocalSSD enables the feature; the optional count controls only the manual-attachment path.

Leave Local SSD count blank

Leaving the field blank produces the following NodeClass configuration:

enableLocalSSDEphemeralStorage: true
nodeClassSpec:
  ephemeralStorageLocalSSD: {}

In this mode, CloudPilot AI:

1. considers only machine types that already bundle Local SSD capacity;
2. uses the fixed Local SSD count and capacity defined by the selected machine type;
3. does not request an additional SCRATCH disk in the Compute Engine instance creation request; and
4. includes the bundled storage cost in the machine type price rather than adding a separate Local SSD charge.

This mode is intended for machine types such as c3-standard-4-lssd, where the Local SSD is part of the machine type itself.

Enter Local SSD count

Entering a value produces a configuration such as:

enableLocalSSDEphemeralStorage: true
nodeClassSpec:
  ephemeralStorageLocalSSD:
    count: 1

For a compatible machine type that does not already bundle Local SSD, CloudPilot AI:

1. validates the requested count against the machine family and vCPU-specific GCE Local SSD matrix;
2. attaches that number of auto-deleted NVMe SCRATCH Local SSD disks;
3. adds the regional Local SSD price to the machine offering; and
4. advertises the combined Local SSD capacity as node ephemeral storage.

The configuration schema accepts integers from 1 through 32, but not every count is valid for every machine type. CloudPilot AI excludes machine type and count combinations that GCE does not support. At launch, manual attachment is evaluated for supported variants in the a2, c2, c2d, g2, g4, m1, m3, n1, n2, and n2d families.

The effective candidate sets are therefore:

If the workload requires a minimum amount of scratch space rather than a specific disk count, set a Pod ephemeral-storage request. Karpenter then removes candidates whose allocatable storage cannot satisfy the request. You can also constrain the NodePool to specific machine types when an exact hardware layout is required.

GKE node bootstrap

For both GKE modes, CloudPilot AI enables the GKE node image’s native Local SSD ephemeral-storage path and adds the official node capability label:

cloud.google.com/gke-ephemeral-storage-local-ssd=true

The GKE node image combines and mounts the Local SSD capacity before kubelet starts. The Local SSD-backed filesystem is then used for kubelet, containerd, Pod logs, writable layers, and emptyDir volumes. Some raw capacity is reserved for node system use and eviction safety, so Kubernetes allocatable capacity is lower than the sum of the physical disks.

For more information about the underlying GKE behavior, see Provision and use Local SSD-backed ephemeral storage .

EKS provisioning behavior

EKS uses EC2 instance-store NVMe devices. These devices are part of the EC2 instance type, so CloudPilot AI does not attach disks separately and does not expose a disk count field.

When Local SSD ephemeral storage is enabled, CloudPilot AI:

1. requires an AL2023 node image;
2. sets EC2NodeClass.spec.instanceStorePolicy to RAID0;
3. adds a NodePool requirement for karpenter.k8s.aws/instance-local-nvme > 0;
4. selects only EC2 instance types that include local NVMe instance-store capacity; and
5. lets Karpenter and AL2023 nodeadm combine the devices as RAID0 for kubelet, containerd, and Pod log storage.

The RAID device is exposed by the node bootstrap as /dev/md/0 and mounted at /mnt/k8s-disks/0. The number and size of the underlying devices are fixed by the chosen EC2 instance type, and their cost is already included in that instance type’s price.

To control EKS Local SSD capacity, constrain the allowed EC2 instance types in the NodePool and set appropriate Pod ephemeral-storage requests. For details about the underlying policy, see Karpenter EC2NodeClass instance store policy .

Use Local SSD from a workload

Applications consume Local SSD through standard Kubernetes ephemeral-storage APIs. A workload needs to do two separate things:

1. Select a Local SSD-enabled node when SSD-backed storage is required. The CloudPilot-managed label is cloudpilot.ai/ephemeral-storage-local-ssd: "true".
2. Declare an ephemeral-storage request so the scheduler reserves enough node capacity, then use either a disk-backed emptyDir volume or the container writable layer for the actual data.

An ephemeral-storage request does not create or mount a filesystem by itself. Use a normal emptyDir volume when the application needs a dedicated path such as /scratch. Kubelet creates the volume under its Local SSD-backed data directory and mounts it into the container. Writes to the container root filesystem also use the Local SSD-backed containerd writable layer, but emptyDir is recommended for explicit scratch paths and size management.

The following example selects a CloudPilot-managed Local SSD node, reserves 10 GiB of ephemeral storage, and mounts a disk-backed emptyDir at /scratch:

apiVersion: v1
kind: Pod
metadata:
  name: local-ssd-example
spec:
  nodeSelector:
    cloudpilot.ai/ephemeral-storage-local-ssd: "true"
  containers:
    - name: workload
      image: alpine:3.22
      command: ["sh", "-c", "dd if=/dev/zero of=/scratch/test.bin bs=1M count=1024 && sleep 3600"]
      resources:
        requests:
          cpu: "1"
          memory: 1Gi
          ephemeral-storage: 10Gi
        limits:
          ephemeral-storage: 20Gi
      volumeMounts:
        - name: scratch
          mountPath: /scratch
  volumes:
    - name: scratch
      emptyDir:
        sizeLimit: 20Gi

In this example:

• resources.requests.ephemeral-storage: 10Gi is used by the scheduler when selecting a node. Without a request, Kubernetes does not reserve scratch capacity for the Pod.
• resources.limits.ephemeral-storage: 20Gi sets the Pod’s local ephemeral-storage limit. Kubelet can evict the Pod if its measured writable-layer, log, and disk-backed emptyDir usage exceeds the limit.
• emptyDir.sizeLimit: 20Gi limits this specific volume, but it does not reserve capacity during scheduling. Use the resource request for scheduling guarantees.
• mountPath: /scratch is the application-visible path. The workload does not need to know whether the underlying node uses a GKE-managed NVMe device or an EKS RAID0 device.

Do not set emptyDir.medium: Memory when the data must use Local SSD. That option creates a memory-backed tmpfs volume and consumes node memory instead of SSD capacity.

No device path, filesystem command, CSI volume, hostPath, or privileged container is required. You can confirm the mounted capacity from the running Pod:

kubectl exec local-ssd-example -- df -h /scratch

For more information, see the Kubernetes documentation for local ephemeral-storage requests and limits  and emptyDir volumes.

Live validation results

The GKE path was validated end to end on live GKE Standard clusters in us-central1-a. Both tests used ordinary Pod emptyDir volumes and fio direct I/O, with three rounds per operation.

GKE with one explicitly attached Local SSD

The comparison used two otherwise matching n2-standard-4 nodes with a 50 GB pd-balanced boot disk. The Local SSD NodeClass specified count: 1, which attached one 375 GB NVMe Local SSD.

Kubernetes allocatable ephemeral storage increased from 17,754,861,087 bytes on the baseline node to 301,982,796,416 bytes on the Local SSD node. The workload’s /scratch path was backed by /dev/nvme0n1, and the Pod contained no device or mount setup.

GKE with bundled Local SSD and count omitted

The bundled-mode comparison used c3-standard-4 as the boot-disk baseline and c3-standard-4-lssd as the Local SSD variant. Both had 4 vCPU and 16 GiB memory; the -lssd type included one bundled 375 GB NVMe Local SSD. The Compute Engine instance request contained no additional SCRATCH disk request.

The EKS provisioning path uses Karpenter’s native AL2023 instanceStorePolicy: RAID0 behavior. A comparable CloudPilot live fio benchmark is not yet published, so this page does not claim an EKS performance multiplier. Validate the selected EC2 instance types and workload pattern in a staging environment before production rollout.

Operational considerations

• Configuration changes affect newly provisioned or replaced nodes. Plan node replacement through the normal Rebalance Configuration disruption and availability controls.
• Set realistic ephemeral-storage requests and limits. Without a request, the scheduler cannot reserve scratch capacity for the workload.
• Local SSD capacity is not added to the boot disk capacity when Local SSD-backed ephemeral storage is enabled; Kubernetes schedules against the Local SSD-backed node filesystem.
• For GKE, do not combine ephemeralStorageLocalSSD with a legacy disk entry whose category is local-ssd.
• For EKS, AL2023 is currently required by the CloudPilot configuration flow.
• Local SSD and instance-store data do not survive node replacement. Applications must be able to recreate or redownload the data.
• Keep sufficient NodePool diversity and disruption budgets so that a Local SSD machine-type capacity shortage does not block all workload provisioning.