AutoScaler on Kubernetes

Learn how Datafy AutoScaler integrates with the AWS EBS CSI driver — what gets installed, how volume requests are translated, and what happens after uninstall

When a volume is autoscaling, the original EBS volume is replaced by smaller Datafy-managed volumes. In a Kubernetes cluster, the PersistentVolume that represents this volume still references the original volume ID. Whenever the matching PersistentVolumeClaim requires an action at the volume level (such as attaching, mounting, or detaching), the AWS EBS CSI driver, which handles EBS volume operations in Kubernetes, cannot find the correct volume to act on.

Datafy bridges this gap with a conversion layer that intercepts requests received by the CSI driver and translates them to the underlying Datafy-managed volumes. For volumes Datafy does not manage, requests pass through unchanged.

Installing Datafy on Kubernetes

Installing AutoScaler on a Kubernetes cluster adds three main components to your cluster:

• Datafy agent — datafy-agent DaemonSet, with one pod per node. Performs the same functions as in non-Kubernetes environments: monitoring utilization, orchestrating grow and shrink operations, and managing the virtualization layer.

• Datafy controller — datafy-controller Deployment. Tracks volume state and manages the integration with the CSI driver.

• Datafy proxy — datafy-proxy sidecar container added to each ebs-csi-controller and ebs-csi-node pod. Intercepts and translates CSI driver requests for managed volumes.

To verify your installation, check that the following are present in your cluster:

• datafy-agent DaemonSet in the datafy-agent namespace, with one pod running per node

• datafy-controller Deployment in the datafy-agent namespace, running

• ebs-csi-controller and ebs-csi-node pods (in the EBS CSI driver's namespace) each contain a datafy-proxy container

The Datafy proxy sidecar is added to CSI driver pods through a Kubernetes admission webhook that the controller registers. The webhook adds the sidecar whenever a CSI driver pod starts — initial install, version upgrade, or routine restart — so the integration is preserved across CSI driver updates without manual reconfiguration. The controller also re-adds the sidecar if the ebs-csi-controller Deployment or ebs-csi-node DaemonSet drifts.

Your existing StorageClasses, IAM roles, and CSI configuration remain unchanged — Datafy works alongside the standard driver, not in place of it.

Volume Operations

The cluster operations you'd typically perform on autoscaling volumes work the same as on any other PersistentVolume — the Datafy proxy translates each request to the underlying volumes, and the standard CSI driver carries out the AWS calls using its existing IAM credentials.

• Pod rescheduling — when a pod moves between nodes during a drain, rolling update, eviction, or rescaling, the CSI sidecar translates the detach and re-attach calls, and the Datafy agent on each node tears down or sets up the virtualization layer. From the application's perspective, this is identical to a standard pod rescheduling event.

• Snapshots and backups — Kubernetes VolumeSnapshot resources are supported, including the CSI snapshotter integration used by tools like Velero. For details, see Datafy Snapshots.

Uninstalling

Deactivate autoscaling on all managed volumes before uninstalling. If Datafy is removed while volumes are still under autoscaling, those volumes will not be accessible. Follow the uninstall guide to prepare correctly.

Deactivating autoscaling copies the data back to a new standard EBS volume. That new volume has a different ID than the one the PersistentVolume still references, so a 1:1 translation between the two is still required for the volume to remain accessible. For this reason, to keep your volumes accessible, uninstalling does not remove every Datafy component at once.

When you uninstall AutoScaler from a cluster that had autoscaling volumes:

• The Datafy agent is removed.

• The Datafy controller and the datafy-proxy sidecar containers remain on the cluster, performing the 1:1 translation for any PersistentVolume that was previously managed.

As those PersistentVolumes are removed from the cluster — for example, when their workloads are recycled or replaced — the number of translations needed shrinks. Once no PersistentVolume requires translation, the controller removes itself and the CSI sidecar containers. From that point on, the CSI driver operates exactly as it did before Datafy was installed.

PersistentVolumes, PersistentVolumeClaims, and application data remain intact throughout.