# AutoScaler on Kubernetes

When a volume is autoscaling, the original EBS volume is replaced by smaller [Datafy-managed volumes](/how-it-works/how-autoscaler-works.md). In a Kubernetes cluster, the [PersistentVolume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) that represents this volume still references the original volume ID. Whenever the matching [PersistentVolumeClaim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 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](/set-up-and-installation/datafy-installation/installation.md#kubernetes-cluster) 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.

{% hint style="success" %}
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
  {% endhint %}

The Datafy proxy sidecar is added to CSI driver pods through a Kubernetes [admission webhook](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) 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.

{% hint style="info" %}
Your existing StorageClasses, IAM roles, and CSI configuration remain unchanged — Datafy works alongside the standard driver, not in place of it.
{% endhint %}

## 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`](https://kubernetes.io/docs/concepts/storage/volume-snapshots/) resources are supported, including the CSI snapshotter integration used by tools like Velero. For details, see [Datafy Snapshots](/volume-lifecycle/datafy-snapshots.md#kubernetes-csi-integration).

## Uninstalling

{% hint style="danger" %}
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](/set-up-and-installation/uninstalling-datafy.md) to prepare correctly.
{% endhint %}

[Deactivating autoscaling](/volume-lifecycle/managing-autoscaling-volumes.md#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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.datafy.io/how-it-works/autoscaler-on-kubernetes.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.