{"id":307,"date":"2026-04-14T04:53:00","date_gmt":"2026-04-14T04:53:00","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=307"},"modified":"2026-04-14T04:53:00","modified_gmt":"2026-04-14T04:53:00","slug":"provsion-persistent-volume-on-eks","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=307","title":{"rendered":"How to Provision Persistent Volume on EKS Cluster"},"content":{"rendered":"

In this blog we will look at detailed steps to provision different types of persistent volume on AWS EKS using recommended EBS CSI Driver.<\/p>

At the end of the guide, you will learn about the following.<\/p>

  1. Understand EBS CSI Driver Workflow in volume provisioning.<\/li>
  2. Create custom StorageClass<\/li>
  3. Provision volume using StorageClass<\/li>
  4. Creating default StorageClass using annotation.<\/li>
  5. Enabling CSI Driver in existing clusters.<\/li><\/ol>

    Lets get started.<\/p>

    Setup Prerequisites<\/h2>

    The prerequisites to follow this guide are as follows:<\/p>

    1. EKS Cluster<\/a> v1.30 or later<\/li>
    2. eksctl utility installed on your workstation<\/li>
    3. AWS CLI installed with admin privileges to EKS service.<\/li><\/ol>

      EBS CSI Driver Workflow<\/h2>

      The following workflow explains how the EBS CSI works with the Pod Identity Agent Plugin to provision a persistent EBS volume from the AWS Cloud for EKS.<\/p>

      \"the<\/figure>\n\n
        \n
      1. The developer creates a Persistent Volume Claim (PVC)<\/strong> to get the required persistent storage for the Application Pod. The volume type and FS type will be mentioned in the StorageClass<\/strong> object.<\/li>\n\n\n
      2. The request is ro<\/span>uted from the Kubernetes API server<\/strong> in the control plane and then routed to the EBS CSI Controller<\/strong> to provision storage.<\/li>\n\n\n
      3. The EBS CSI Controller<\/strong> needs to access the AWS EBS API<\/strong> to provision the EBS volume<\/strong>,<\/strong> so the EKS Pod Identity Plugin<\/strong> will provide the temporary <\/span>credentials to the controller.<\/li>\n\n\n
      4. The controller will validate the request and communicate with the AWS to provision an EBS volume.<\/li>\n\n\n
      5. After provisioning the EBS volume, the EBS CSI Controller will get the EBS Volume ID<\/strong> and update the Persistent Volume. By the way, since it is dynamic provisioning, the PV will automatically be created. <\/li>\n\n\n
      6. Also, the EBS Volume will not be attached to any Nodes until the Application Pod deployment, but the PV and PVC will be bound. <\/li>\n\n\n
      7. When the Application Pod is created with the PVC, the EBS CSI Node driver<\/strong>, which is available in each node, requests that the provisioned EBS volume be attached to the particular node where the Application Pod will be run.<\/li>\n\n\n
      8. Once the Node mounting is successfully completed, the CSI Node driver will get the node’s EBS mount path from the AWS API, and then the Pod will start with the volume. <\/li>\n<\/ol>\n\n

        EKS Cluster With and Without CSI Driver<\/h2>

        The key requirement<\/strong> for provisioning volumes with EBS is the EBS CSI Driver. Also it requires IAM privileges to manage EBS volumes for Persistent Volumes.<\/p>

        You can follow our EKS cluster creation using eksctl<\/a> guide to spin up a cluster with EBS CSI Driver and associated IAM roles using pod Identity agent.<\/p>

        The following configuration in the eksctl YAML enables required permissions for EBS CSI Driver.<\/p>

        addons:\n  - name: aws-ebs-csi-driver\n    version: latest\n  - name: eks-pod-identity-agent\n    version: latest\n\naddonsConfig:    \n   autoApplyPodIdentityAssociations: true<\/code><\/pre>
        If you have an existing EKS cluster but don’t have the EBS CSI Driver,<\/strong> the installation step is provided in the later section of this guide.<\/p>
        Assuming you already have an EKS cluster with the EBS CSI Driver Plugin, you can start from step 1<\/strong> to provision the Persistent Volume.<\/p>
        Provision Storage Class<\/h2>
        We all know that the AWS EBS<\/strong> Volumes are zone-based,<\/strong> so keep that in mind if you provision an EBS volume as persistent storage for your Pods<\/strong> in the EKS<\/strong> Cluster.<\/p>
        The Node<\/strong> and the EBS volume<\/strong> should be in the same availability zone<\/strong>. Choosing the type of EBS is also really important because it can affect the performance of your application or service.<\/p>
        EBS provides different types of storage, such as General-Purpose (SSD), Provisioned IOPS (SSD), Throughput-Optimized (HDD), Cold (HDD), and EBS Magnetic (HDD).<\/strong><\/p>
        When choosing the storage type<\/strong>, consider IOPS (Input\/Output Operations Per Second) and Throughput. If the application handles a high amount of transactional workloads such as Databases, then IOPS<\/strong> should be high.<\/p>
        In the EBS SSD-based storage types such as General Purpose (gp2, gp3) and Provisioned IOPS (Io1, Io2)<\/strong> have high IOPS<\/strong>, and can almost handle 16,000 to 256,000  Input\/Output Per Second.<\/strong><\/p>
        If the requirement is to store a larger amount of data for analysis or processing then HDD-based storage options would be good, and in this, Throughput Optimized (St1), Cold (Sc1) and Magnetic (standard)<\/strong> are the available options.<\/p>
        I am creating a Storage Class<\/strong> with one of the high IOPS EBS volume types, which is Provisioned IOPS SSD (io2)<\/strong><\/p>
        cat <<EOF > ebs-io2-volume.yaml\nkind: StorageClass\napiVersion: storage.k8s.io\/v1\nmetadata:\n  name: io2-volume\nprovisioner: ebs.csi.aws.com\nparameters:\n  type: io2\n  iopsPerGB: \"50\"  \n  fsType: ext4    \nvolumeBindingMode: Immediate\nEOF<\/code><\/pre>
        I am using the volumeBindingMode<\/strong> as Immediate<\/strong> so that when someone creates a Persistent Volume Claim (PVC) that matches this Storage Class configuration, the PV and PVC will be immediately bound once the volume is provisioned.<\/p>
        Another option is WaitForFirstConsumer<\/strong>. In this, the bounding process waits until the pod is created because the Pod configuration should also match this configuration.<\/p>
        To deploy this configuration, use the following command.<\/p>
        kubectl apply -f ebs-io2-volume.yaml<\/code><\/pre>
        If you check the available StorageClasses<\/strong>, you will see the new one on the list.<\/p>
        kubectl get storageclass<\/code><\/pre>
        \"listing<\/figure>
        In most cases, we create a Persistent Volume(PV) first, then a Persistent Volume Claim (PVC) to get the required storage from the Persistent Volume. <\/p>
        In this case, we don’t need PV but directly provision the volume only with a Persistent volume Claim<\/strong>, which is known as dynamic provisioning. <\/strong><\/p>
        Create Persistent volume Claim<\/h2>
        Now, we can create a PersistentVolumeClaim<\/strong> manifest io2-pvc.yaml<\/code> with the required storage size, I am providing 12GB of storage for testing purposes. <\/p>
        cat <<EOF > io2-pvc.yaml\nkind: PersistentVolumeClaim\napiVersion: v1\nmetadata:\n  name: my-pvc\nspec:\n  accessModes:\n    - ReadWriteOnce\n  storageClassName: io2-volume\n  resources:\n    requests:\n      storage: 12Gi\nEOF<\/code><\/pre>
        Here, you would have noticed the accessModes<\/strong> value is ReadWriteOnce<\/strong>; this means that only one Node (Volume attached node) can read and write on the volume because I have already mentioned that the EBS volumes are zone-specified<\/strong>.<\/p>
        Various access modes are available, but not every storage type supports all these access modes.<\/p>
        The available access modes are.<\/p>
        1. ReadWriteOnce<\/strong>: This mode is suitable if only one node performs the read and write in the volume.<\/li>
        2. ReadOnlyMany<\/strong>: This mode is suitable if many nodes need to read the contents but not to write.<\/li>
        3. ReadWriteMany<\/strong>: This mode is for both; many nodes can read and write on the volume.<\/li>
        4. ReadWriteOncePod<\/strong>: This mode is the same as the first one but is not a node; a pod can read and write on the volume.<\/li><\/ol>
          To deploy this configuration, use the following command.<\/p>
          kubectl apply -f io2-pvc.yaml<\/code><\/pre>
          Once the configuration is properly done, we can list the available PersistentVolumeClaims<\/strong> on our Cluster.<\/p>
          kubectl get pvc<\/code><\/pre>
          \"the<\/figure>
          This output ensures that the EBS volume<\/strong> is successfully created. We can also see other details such as capacity, access modes, storage class, etc.<\/p>
          We can see this provisioned volume from the AWS console<\/strong> as well.<\/p>
          \"listing<\/figure>
          The EBS<\/strong> volume is in an Available state<\/strong>, so we can attach this as persistent volumes in the Pods.<\/p>
          Attach Persistent Volume to a Pod<\/h2>
          Now lets attach the created volume to a pod and validate it.<\/p>
          For testing purposes, I am creating an Nginx deployment and attaching the \/usr\/share\/nginx\/html<\/code> directory of the container to the EBS volume.<\/p>
          cat <<EOF > deployment.yaml\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: io2-volume-deployment\n  labels:\n    app: io2-app\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: io2-app\n  template:\n    metadata:\n      labels:\n        app: io2-app\n    spec:\n      containers:\n        - name: io2-container\n          image: nginx:latest\n          ports:\n            - containerPort: 80\n          volumeMounts:\n            - name: io2-volume\n              mountPath: \/usr\/share\/nginx\/html\n      volumes:\n        - name: io2-volume\n          persistentVolumeClaim:\n            claimName: my-pvc\nEOF<\/code><\/pre>
          kubectl apply -f deployment.yaml<\/code><\/pre>
          If we check the EBS volume state in the AWS console after the successful deployment, it will be in use.<\/p>
          When creating the PVC, the EBS volume will be provisioned and when create a Pod with the PVC, the EBS volume will be attached with the node where the Pod is going to run.<\/blockquote>
          This way, we can permanently store the data on the EBS volumes.<\/p>
          Creating Default Storage Class<\/h2>
          Up to version 1.29, Amazon EKS automatically identified gp2 as its default StorageClass. With EKS 1.30, Amazon stopped specifying a default storage class.<\/p>
          So on any cluster 1.30+, you need to set this up yourself.<\/p>
          To set a storage class as default, you need to explicitly annotate it as the default:storageclass.kubernetes.io\/is-default-class: \"true\"<\/code><\/strong>Only then the unbound PVCs start getting provisioned.<\/p>
          For example, here is the storage class manifest to make gp3 volumes as default storage class.<\/p>
          apiVersion: storage.k8s.io\/v1\nkind: StorageClass\nmetadata:\n  name: gp3\n  annotations:\n    storageclass.kubernetes.io\/is-default-class: \"true\"\nprovisioner: ebs.csi.aws.com\nvolumeBindingMode: WaitForFirstConsumer\nallowVolumeExpansion: true\nparameters:\n  type: gp3\n  fsType: ext4\n  encrypted: \"true\"<\/code><\/pre>
          Setup the EBS CSI Driver in Existing EKS Cluster<\/h2>
          If you have an existing EKS cluster without the EBS CSI Driver<\/strong> and Pod Identity Agent<\/strong> plugin for this hands-on, you can install and configure them using the following steps.<\/p>
          Before provisioning the EBS volume in the EKS cluster, we need to set up the Amazon EBS CSI Driver<\/strong> on the cluster.<\/p>
          Step 1: Check IAM OIDC Provider Integration<\/h3>
          Note<\/strong>: If OIDC has already been added to your cluster, you can ignore this step.<\/blockquote>
          The EBS CSI driver needs dedicated IAM privileges to provision EBS volumes when requested for PVCs.<\/p>
          However, you can use the OIDC provider<\/strong> to add IAM Permission to the EKS Pods.<\/p>
          When we create an EKS Cluster, an OIDC provider ID<\/strong> is also generated.<\/p>
          You can get it from the Identity Providers<\/strong> section in the IAM portal, as shown below.<\/p>
          \"oidc<\/figure>
          Let’s list the available clusters in the AWS account, us-west-2 region.<\/p>
          aws eks list-clusters --region us-west-2<\/code><\/pre>
          This will show you the available clusters in the particular region.<\/p>
          Set the Region<\/strong> and the Cluster Name<\/strong> as environment variables.<\/p>
          export REGION=us-west-2\nexport CLUSTER_NAME=terraform-eks-cluster-poc<\/code><\/pre>
          Check whether the IAM OIDC Provider<\/strong> is associated with the cluster or use the following command to associate the OIDC<\/strong> provider.<\/p>
          eksctl utils associate-iam-oidc-provider --region=$REGION --cluster=$CLUSTER_NAME --approve<\/code><\/pre>
          You will get the prompt IAM Open ID Connect provider is already associated with cluster<\/code> If the OIDC association is already present in the cluster.<\/p>
          Step 2: Install AWS EBS CSI Driver<\/h3>
          Use the following command to install the EBS CSI Driver on the EKS Cluster.<\/p>
          eksctl create addon --cluster $CLUSTER_NAME --region $REGION --name aws-ebs-csi-driver<\/code><\/pre>
          The EBS CSI add-on<\/strong> will be created with the necessary permissions, as seen in the AWS Console.<\/p>
          \"listing<\/figure>
          Important Note: <\/strong>The current IAM permissions are attached to the drivers using the IAM Role for Service Account (IRSA) method. However, the IRSA method is deprecated, so we will use the Pod Identity Agent to assign IAM roles to pods, which will be done in the next step<\/blockquote>
          The IAM Role and Policy will be automatically created for the CSI Driver. As shown below, you can check them from the IAM console.<\/p>
          \"the<\/figure>
          You can view all the permissions if you click the +<\/code> symbol of the Policy.<\/p>
          If you check the Trust relationships<\/strong>, you will see the following information related to the OIDC.<\/p>
          \"the<\/figure>
          The EBS CSI Driver runs as Pods in the Cluster, so let’s check the running Pods.<\/p>
          kubectl get pods -n kube-system<\/code><\/pre>
          \"the<\/figure>
          I have four-node clusters, which is why the four CSI Node Drivers are running.<\/p>
          The EBS CSI Controller<\/strong> Pods will deploy on any of the Nodes. The EBS CSI Node Drivers<\/strong> is a DaemonSet<\/a> and will be available in each worker node.<\/p>
          Now that the Amazon EBS CSI <\/strong>Plugin has been successfully installed. <\/p>
          we can provision the EBS volumes from the EKS Cluster.<\/strong><\/p>
          If we describe the EBS CSI Driver’s Service Account, we can see the annotation of the AWS IAM Role.<\/p>
          kubectl -n kube-system describe sa ebs-csi-controller-sa<\/code><\/pre>
          \"the<\/figure>
          Step 3: Migrate to Pod Identity<\/h3>
          However, providing AWS IAM Permissions to a Pod using IRSA<\/strong> is deprecated, so we are migrating this to the EKS Pod Identity Agent<\/strong>.<\/p>
          First, we need to ensure the Pod Identity Agent Plugin<\/strong> is installed in the EKS Cluster.<\/p>
          aws eks list-addons --cluster-name $CLUSTER_NAME<\/code><\/pre>
          \"the<\/figure>
          If the Plugin is not available, install it using the following command.<\/p>
          aws eks create-addon --cluster-name $CLUSTER_NAME --addon-name eks-pod-identity-agent<\/code><\/pre>
          Once the Pod Identity Agent is available, we can migrate everything from IRSA<\/strong> to Pod Identity<\/strong>.<\/p>
          eksctl utils migrate-to-pod-identity --cluster $CLUSTER_NAME --approve<\/code><\/pre>
          After the successful migration, we can list the Pod Identity Associations<\/strong>.<\/p>
          eksctl get podidentityassociation --cluster $CLUSTER_NAME<\/code><\/pre>
          or<\/p>
          aws eks list-pod-identity-associations --cluster-name $CLUSTER_NAME<\/code><\/pre>
          \"the<\/figure>
          Now, we cannot see the annotation in the Service Account.<\/p>
          \"the<\/figure>
          We can see some changes if we check the Trust relationship<\/strong> of the IAM Role<\/strong>, which is related to the Pod Identity Agent.<\/p>
          \"the<\/figure>
          We can even check the add-on’s update history and ensure the Pod Identity Association is properly configured.<\/p>
          \"the<\/figure>
          Now the EBS CSI Driver is successfully installed on the existing EKS cluster with the Pod Identity Agent, and is ready to provision the EBS volumes for the EKS cluster.<\/p>
          Conclusion<\/h3>
          This will help your EKS Pod data be permanently stored in the EBS volumes and give you an overall idea of the EBS CSI Driver and its configurations.<\/p>
          Choose the appropriate volume type for your workload. Depending on the underlying storage you choose for the persistent storage, some configurations will be changed in the StorageClass<\/strong> manifest.<\/p>
          Always remember to back up the storage. In EBS, we can take snapshots or use the AWS Backup service to take backups. We can also try third-party backup options.<\/p>
          If you are looking for NFS based storage solution, check out the EFS on EKS<\/a> guide for the full setup. <\/p>\n
          Ngu\u1ed3n:<\/strong> How to Provision Persistent Volume on EKS Cluster \u2014 DevOpsCube<\/a><\/p>","protected":false},"excerpt":{"rendered":"
          Source: https:\/\/devopscube.com\/provsion-persistent-volume-on-eks\/<\/p>\n","protected":false},"author":1,"featured_media":308,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-307","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/307","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=307"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/307\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/308"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=307"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=307"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=307"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}