Introduction:
In the world of Kubernetes, managing persistent storage for applications can be challenging. However, with the integration of Amazon Elastic Block Store (EBS) and Amazon Elastic Kubernetes Service (EKS), this process becomes streamlined and efficient. In this blog, we’ll explore how to set up EBS storage classes in EKS and launch pods that utilize these volumes, ensuring data persistence and reliability for your applications.
Understanding EBS Storage Classes:
Amazon EBS provides block-level storage volumes that can be attached to EC2 instances. In Kubernetes, storage classes define the type and properties of the storage that pods can request. By configuring EBS storage classes, you can dynamically provision EBS volumes for your Kubernetes workloads based on predefined policies.
Setting Up EKS and EBS Integration As Persistent Storage 👇:
1. Launching EKS Cluster:
Begin by creating an Amazon EKS cluster using the AWS Management Console or CLI. This cluster will serve as the foundation for our Kubernetes environment. We are using eksctl tool for this.
- You can use any of the below command.
eksctl create cluster --kubeconfig cluster1.config
OR
eksctl.exe create cluster --name basic-cluster --region us-west-1 --version 1.25 --nodegroup-name ng-basic --instance-types t2.micro --nodes 2 --nodes-min 1 --nodes-max 5 --node-volume-size 40 --node-volume-type gp2 --enable-ssm --ssh-access --instance-name eks-workernode --managed --kubeconfig Cluster1.config
- The command
--kubeconfig <file-name>will save the credentials or user-information in this file that will connect you to your cluster. - Once it is done, you can confirm the creation via this command.
eksctl get cluster
eksctl get nodegroup --cluster <cluster-name>
2. Modifying IAM Role:
To allow EKS to manage EBS volumes on our behalf, modify an IAM role with the necessary permissions. This role ensures secure communication between EKS and EBS.
- To get the IAM role that is already been created by the eksctl, run the following command.
kubectl get configmap -n kube-system --kubeconfig Cluster1.config
kubectl describe configmap aws-auth -n kube-system --kubeconfig Cluster1.config
- Go to the IAM dashboard and select this IAM role and modify it by attaching the
ec2fullaccesspolicy.
3. Launching Provisioner:
Deploy the EBS CSI driver provisioner as a Kubernetes daemon set. This provisioner dynamically creates EBS volumes in response to persistent volume claims (PVCs) from pods.
- For this run the following command to deploy the EBS CSI driver.
kubectl apply -f "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-1.30" --kubeconfig Cluster1.config
- Verify the deployment with the following command.
kubectl get pods -n kube-system -l app.kubernetes.io/name=aws-ebs-csi-driver --kubeconfig Cluster1.config
Deploying Pods with Persistent Storage:
1. Configuring Storage Class:
Define a storage class in Kubernetes that specifies the provisioner as “kubernetes.io/aws-ebs-csi.com” and includes parameters such as volume type, size, and encryption settings.
- Below are the content of the storage class file.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ebs-sc
provisioner: ebs.csi.aws.com
# Below mode will not create pv even after creating pvc until some pod is associated with that pvc
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
fsType: ext4- Apply this file to create storage class.
kubectl apply -f <file-name> --kubeconfig Cluster1.config
2. Creating Persistent Volume Claim:
Define a PVC in Kubernetes that requests storage from the EBS storage class. This PVC specifies the desired storage capacity and access mode required by the application.
- Below is the content of the file that will create pvc resource.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ebs-sc-pvc
namespace: default
spec:
accessModes:
- ReadWriteMany
storageClassName: ebs-sc
resources:
requests:
storage: 4Gi
- Check whether it is created or not.
kubectl get pvc --kubeconfig Cluster1.config
- But it is not yet bounded because of the volume binding mode in storage class, this will only be bounded when some pod will use this.
3. Deploying Application Pods:
Launch pods that require persistent storage and reference the PVC created earlier. These pods automatically mount the EBS volume and can read from or write to it as needed.
- Below are the yaml code for launching the pod.
apiVersion: v1
kind: Pod
metadata:
name: app
spec:
containers:
- name: app
image: centos
command: ["/bin/sh"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: ebs-sc-pvc- Launch it with following command.
kubectl apply -f <file-name>.yaml
- And you will see that as soon as it is created the pv that is persistent volume will automatically created and pvc will be bounded to it.
- Go manually to the ec2-console and see the storage of the node where this pod was launched.
Limitations of EBS as Persistent Volume:
While EBS volumes offer numerous benefits, including reliability and scalability, they also come with certain limitations:
- Availability Zones Bound: EBS volumes are tied to specific AWS Availability Zones, limiting their availability in multi-zone deployments.
- Performance Variability: Performance of EBS volumes can vary based on volume type and instance type, impacting application performance.
- Cost Considerations: EBS volumes incur costs based on usage and storage capacity, requiring careful planning to optimize costs in Kubernetes environments.
Conclusion:
By integrating Amazon EBS with Amazon EKS and leveraging Kubernetes storage classes, you can simplify the management of persistent storage in your containerized applications. This approach offers scalability, flexibility, and reliability, ensuring your applications have access to the storage they need while running on Kubernetes. Explore the power of EBS and EKS today to enhance your Kubernetes storage strategy! 🚀🔒
