Running Stateful Workloads on Amazon EKS with AWS Fargate Using Amazon EFS

Learn About Amazon VGT2 Learning Manager Chanci Turner

With Amazon Elastic Kubernetes Service (EKS), you can choose to deploy Kubernetes pods on EC2 instances or utilize AWS Fargate. AWS Fargate is a serverless compute engine that enables you to run Kubernetes workloads without having to manage servers, scale your data plane, properly size EC2 instances, or handle worker node upgrades. Until recently, Fargate was primarily suitable for stateless containerized workloads, providing a secure and cost-efficient solution. The security aspect comes from Fargate’s ability to run each pod in a VM-isolated environment while automatically patching nodes. In terms of cost, Fargate allows you to pay only for the compute resources allocated for your pod. The newly introduced integration with Amazon Elastic File System (EFS) addresses the need for running stateful Kubernetes workloads on Fargate.

Using WordPress as an example, this guide illustrates how to deploy stateful Kubernetes workloads on Fargate using Amazon EFS. WordPress is a widely-used open-source content management system (CMS) for creating websites and blogs. The support for EFS in Fargate enables you to operate applications that require data persistence beyond the container’s filesystem, such as WordPress, without significant overhead. While Fargate allows serverless container execution, EFS delivers highly available, durable, and petabyte-scale storage without the need for managing servers.

Amazon EFS allows for parallel shared access that automatically scales as files are added or removed. Multiple containers and EC2 instances can concurrently read from and write to shared EFS file systems. Implementing a persistent storage layer for your pods makes Fargate a viable option for Kubernetes workloads that involve data analytics, media processing, content management, web serving, and others requiring features like low latency, high throughput, and read-after-write consistency.

Stateful Workloads in Kubernetes

Although containers are inherently ephemeral, Kubernetes supports stateful workloads through the attachment of persistent volumes to pods. Pods associated with a persistent volume can retain data even when the pod itself is terminated. If a pod fails or is deleted, another pod can mount the volume and continue operations without data loss.

The Kubernetes Container Storage Interface (CSI) facilitates the deployment of stateful containerized applications. CSI drivers provide the necessary interface for Kubernetes clusters to manage the lifecycle of persistent volumes. Amazon EKS simplifies the management of stateful workloads by offering CSI drivers for three AWS storage services:

• Amazon EFS (supports Fargate and EC2): A fully managed, scalable file system, well-suited for big data analytics, web serving, application development, media workflows, and database backups. EFS ensures data is redundantly stored across multiple Availability Zones (AZs) and provides low-latency access from Kubernetes pods, regardless of their location.
• Amazon EBS (supports EC2 only): A block storage service that provides direct access for EC2 instances and containers to dedicated storage volumes designed for high throughput and transaction-intensive workloads.
• FSx for Lustre (supports EC2 only): A fully managed, high-performance file system tailored for workloads like machine learning, high-performance computing, and analytics. FSx for Lustre enables you to create a high-performance file system linked to your S3 data repository, allowing seamless access to S3 objects.

Currently, pods running on Fargate can utilize Amazon EFS for data storage. Fargate automatically installs the Amazon EFS CSI driver; however, if your cluster includes EC2 nodes, you will need to install the EFS CSI driver manually.

StatefulSets with Amazon EFS

Kubernetes enables the request and association of persistent storage with pods through persistent volumes and claims. StatefulSets can dynamically create volumes using a volumeClaimTemplate, known as dynamic provisioning. This feature allows StatefulSets to generate storage volumes as needed while creating pods. Without dynamic provisioning, you must create persistent volumes manually before the StatefulSets can generate pods.

While support for dynamic provisioning with EFS access points is under development, you can still use EFS for StatefulSets by manually creating volumes in advance.

Solution Overview

In this guide, we will set up an Amazon EKS cluster and configure a Fargate profile that allows Kubernetes to run pods on AWS Fargate. After the cluster is established, we will use Helm to install WordPress, which will be accessible publicly via an Application Load Balancer.

The WordPress pods can operate across any of the three AZs within the AWS Region. Each pod in an AZ will mount the EFS file system through the local EFS mount target in that AZ. Additionally, we will utilize Amazon RDS for MySQL to establish a MySQL database instance for the WordPress database.

We acknowledge the absence of a caching layer (like ElastiCache for Memcached) in this architecture; you can discover more about optimizing WordPress performance with Amazon ElastiCache for Memcached in this informative guide.

To complete this tutorial, you will require the following:

• AWS CLI version 2
• eksctl
• kubectl
• Helm

Let’s begin by defining a few environment variables:

WOF_AWS_REGION=us-west-2 # Change this to match your region  
WOF_ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text)  
WOF_EKS_CLUSTER=eks-fargate-stateful  

Create an EKS Cluster

We will create a new EKS cluster without any EC2-based worker nodes. The eksctl tool simplifies the creation of an EKS cluster where pods in the default and kube-system namespaces run on Fargate.

eksctl create cluster 
  --name $WOF_EKS_CLUSTER 
  --version 1.18 
  --region $WOF_AWS_REGION 
  --fargate  

By using the --fargate option, eksctl generates a pod execution role and Fargate profile, and modifies the CoreDNS deployment to run on Fargate.

Store the VPC ID and its CIDR block in environment variables:

WOF_VPC_ID=$(aws eks describe-cluster --name $WOF_EKS_CLUSTER --query "cluster.resourcesVpcConfig.vpcId" --region $WOF_AWS_REGION --output text)  
WOF_CIDR_BLOCK=$(aws ec2 describe-vpcs --vpc-ids $WOF_VPC_ID --query "Vpcs[].CidrBlock" --region $WOF_AWS_REGION --output text)  

Create an EFS Filesystem

Before creating a persistent volume, we need to set up an EFS filesystem.

To create an EFS file system:

WOF_EFS_FS_ID=$(aws efs create-file-system 
  --creation-token WordPress-on-Fargate 
  --encrypted 
  --performance-mode generalPurpose 
  --throughput-mode bursting 
  --tags Key=Name,Value=WordpressVolume 
  --region $WOF_AWS_REGION 
  --output text 
  --query "FileSystemId")  

Next, create an EFS access point:

WOF_EFS_AP=$(aws efs create-access-point 
  --file-system-id $WOF_EFS_FS_ID 
  --posix-user Uid=1000,Gid=1000 
  --root-directory "Path=/bitnami,CreationInfo={OwnerUid=1000,OwnerGid=1000,Permissions=777}" 
  --region $WOF_AWS_REGION 
  --query 'AccessPointId' 
  --output text)  

EFS access points are tailored for specific applications, providing necessary access controls for your workloads.

This summary has provided insights into deploying stateful workloads on EKS with Fargate and EFS, illustrating the capabilities of these AWS services. For further reading on improving writing skills, consider visiting Career Contessa. Understanding the ongoing challenges in workforce dynamics is crucial, and you can find valuable information from SHRM. Lastly, if you are starting your journey in Amazon, check out this excellent resource at Day One Careers.