Amazon EBS CSI Driver

The Amazon EBS CSI Driver is a standard interface that allows Amazon Elastic Kubernetes Service (EKS) clusters to manage the full lifecycle of Amazon EBS volumes as persistent storage for containers. It replaces the older, deprecated "in-tree" Kubernetes storage plugin with a more flexible, decoupled model. 

Key Features

• Dynamic Provisioning: Automatically creates and attaches EBS volumes when a PersistentVolumeClaim (PVC) is made.
• Volume Lifecycle Management: Handles the creation, attachment, mounting, and deletion of volumes.
• Resizing & Snapshots: Supports online volume resizing (for gp3 and others) and taking volume snapshots for data backup.
• EKS Auto Mode Support: In EKS Auto Mode, routine block storage tasks are automated, and you don't even need to manually install the driver. 

Deployment Methods

You can install and manage the driver through several channels: 

• EKS Managed Add-on (Recommended): Simplifies installation and updates via the AWS Console, CLI, or Terraform.
• Helm Chart: Provides highly customizable installation options.
• Kustomize: Direct deployment using manifests from the official GitHub repository. 

Core Requirements

• IAM Permissions: The driver requires an IAM role with the AmazonEBSCSIDriverPolicy to interact with EBS resources.
• Service Accounts: Typically uses IAM Roles for Service Accounts (IRSA) to securely provide AWS credentials to the driver pods.
• Compatibility: Supports Linux and Windows worker nodes, as well as ARM64 architectures.

Driver Components

The driver is typically deployed into the kube-system namespace and consists of two main parts: 

• Controller Deployment: Runs as a set of replicas (ebs-csi-controller) to communicate with the AWS EC2 API and manage volume operations.
• Node DaemonSet: Runs on every worker node (ebs-csi-node) to handle the actual mounting and unmounting of volumes to pods on that specific host. 

In the Amazon EBS CSI driver architecture, the ebs-csi-controller and ebs-csi-node are the two primary components that work together to manage the lifecycle of EBS volumes in a Kubernetes cluster.

Core Feature Differences

ebs-csi-controller

• Deployment Type: 
• Deployment (typically 2 replicas for HA)
• Main Function: 
• Control Plane operations: Creating, deleting, attaching, and detaching volumes
• AWS Interaction: 
• Calls the AWS EC2 API to manage EBS resources
• IAM Permissions: 
• Requires an IAM role with permissions like ec2:CreateVolume and ec2:AttachVolume

ebs-csi-node

• Deployment Type: 
• DaemonSet (runs on every worker node)
• Main Function: 
• Node-level operations: Mounting and unmounting volumes to the local filesystem
• AWS Interaction: 
• Interacts with the local OS (privileged system calls) to handle block devices
• IAM Permissions: 
• Generally requires fewer/no AWS API permissions, as it mostly performs local mount actions

How They Work Together

• Provisioning & Attachment: When you create a PersistentVolumeClaim (PVC), the ebs-csi-controller watches the request and calls the AWS API to create the EBS volume and attach it to the correct EC2 instance.
• Mounting: Once the volume is physically attached to the EC2 instance, the ebs-csi-node pod running on that specific node detects the new block device and mounts it into the container’s path so your application can use it. 

Key Considerations

• Security: For better security, you can schedule the ebs-csi-controller on hardened management nodes, while the ebs-csi-node must run everywhere your workloads need storage.
• Fargate: You can run the controller on Fargate nodes, but the ebs-csi-node (as a DaemonSet) only runs on EC2 instances.
• Troubleshooting: If a volume fails to "attach," check the controller logs; if it fails to "mount" or "format," check the node logs.

Pods for both the ebs-csi-controller and ebs-csi-node typically share the same value for the app.kubernetes.io/name label. 

In standard deployments (such as via the official Helm chart or EKS add-on), both components use this label to identify that they belong to the same overarching application: the Amazon EBS CSI Driver.

Label Comparisons

While they share the same application name, they use the app.kubernetes.io/component label to distinguish between their specific roles.

Label Key                           ebs-csi-controller Pods     ebs-csi-node Pods

------------                                  ------------------------------    ----------------------

app.kubernetes.io/name           aws-ebs-csi-driver       aws-ebs-csi-driver

app.kubernetes.io/instance   aws-ebs-csi-driver       aws-ebs-csi-driver

app.kubernetes.io/component   csi-driver (or controller)     csi-driver (or node)

app (Legacy label)                   ebs-csi-controller               ebs-csi-node

How to Verify in Your Cluster

You can check these labels yourself using kubectl. This is useful if you are writing Prometheus rules or network policies that need to target the entire driver or just one part of it. 

To see labels for all EBS CSI pods:

kubectl get pods -n kube-system -l app.kubernetes.io/name=aws-ebs-csi-driver --show-labels

To target only the controller:

kubectl get pods -n kube-system -l app=ebs-csi-controller

---