My Learnings about AWS Fargate with EKS

Introduction

Over the recent years, containerization has been on the uprise. Many applications have been modernised with the use of containerization and container orchestration platforms like Kubernetes offerings on the various Cloud Service Providers (CSP). This has allowed businesses to build, deploy and manage their applications rapidly.

The Kubernetes offerings that I have worked with would usually require the user to manage the worker nodes, and sometimes even the system nodes. This usually results in potential downtime of the clusters when the team is attempting to perform system updates to the cluster nodes. However, recently, I have come across an offering from AWS which tries to manage the underlying nodes for the user, so the user of the EKS platform can focus on building the application. This service is known as Fargate and is available for both EKS and ECS.

For the past couple of months, I have been trying to deepen my understanding of how Fargate works with EKS as it differs from my initial understanding of Kubernetes Clusters. In this blog post, I will share my learnings and understanding of Fargate, taking references from the EKS workshop and I will share my thoughts about what I think are the possible use-cases of Fargate. This blog assumes that the reader has some basic understanding of containers and Kubernetes.

What is Fargate

EKS Fargate + EC2 setup (Source)

Fargate is a serverless compute engine which works with ECS and EKS where the management of the underlying VM is performed by AWS and the user only needs to manage the development and deployment of the application. It removes the need for the user to provision and manage EC2 instances on their own.

During the setup of Fargate, the user will configure at least one (or more) Fargate profile which specifies the criteria for pods to be scheduled onto Fargate.

During the deployment of the application, the user mainly needs to specify the following:

- CPU requests and limits

- Memory requests and limits

- Number of replicas

- Label that matches the Fargate profile criteria

When the pods are scheduled onto Fargate, the pods will then be scheduled onto a microVM which matches the nearest Fargate Resource Configuration. The list of available resource configurations is listed below.

Table of available resource configurations in Fargate (Source)

Difference between EKS Fargate and EKS EC2

Now this is the subject that had me confused and piqued my interest, as the approach of how pods are scheduled in Fargate disrupted my understanding of how pods are scheduled in vanilla EKS EC2 setups.

Let us start with some obvious differences between the 2 models:

- Infrastructure: Fargate does not require you to provision your cluster’s EC2 / Autoscaling Group (ASG) instances, but if you go with the traditional EC2 approach, you will need to provision the work node EC2 instances for your cluster.

- Pricing Model: Both EC2 and Fargate have vastly different pricing models, where EC2 allows On-demand, Savings Plan and Spot Instances, while Fargate is generally based on On-demand and Compute Savings Plan.

- Pod Scheduling: When going with the EC2/ASG approach, one is able to schedule multiple pods on a single worker node to optimize utilization of the node resources. In Fargate, each pod is scheduled on a microVM, i.e. multiple pods will not exist on the same VM.

Example of how pod allocation when Fargate is used

Other notable differences of Fargate include:

- Daemon sets are not supported.

- GPU instances not supported.

- Privileged containers not supported (though this is a best practice for containers in production).

- Only private subnets are supported.

- Only the Amazon VPC CNI plugin for EKS can be used with Fargate nodes.

You will be able to find more details in the following link.

When using Fargate, as mentioned earlier, the user needs to create a Fargate profile to specify what type of pods will be scheduled on Fargate.

System Updates in Fargate

As mentioned in earlier in this post, one of the common Kubernetes problems that Fargate tries to solve is to remove the need for users to maintain system updates to cluster nodes. Fargate achieves this by managing system updates on Fargate nodes. This does not fully eliminate potential downtimes or service disruptions, but if proper precautions are taken, they are minimized.

AWS will automatically update the underlying EKS Fargate infrastructure as soon as possible when patches and bug fixes are available. If an existing pod is known to be running on an older patch version, EKS might take action to reschedule the pod, so that it runs on the latest patch version and security updates.

As this may result in service disruption, it is highly recommended to configure Pod Disruption Budgets (PDB) for the deployment and to run the deployment with multiple replicas. EKS will make use of the Eviction API to drain and reschedule the affected pods, so the eviction process will respect the configured PDB and reduce the number of pods that are down at any one time.

If eviction of a pod fails, EKS will generate and publish an event which notifies the user of the failed eviction, the cause of failure and the next scheduled time for another eviction attempt. This allows the user to have time to take action to resolve the issue. If the next eviction attempt still fails, the existing pods will then be deleted, so that the newly rescheduled pods can run with the latest updates.

When can Fargate be used

Now I would like to highlight that even though there are some limitations with Fargate, it is still applicable in certain production use-cases. Firstly, when one sets up EKS, you do not need to commit to using either EC2/ASG or Fargate. You can actually use both in hybrid to cover all your production use-cases.

What type of use-cases can we consider Fargate for:

1. Microservice-based applications

2. Batch processing

3. ML applications that require large amounts of memory/CPU. (The pod configuration can specify a larger size for the ML application to run on)

If a daemon set is not required or GPU instances are not required and if the user does not have the capability to self-manage EKS cluster nodes, one can consider the use of Fargate. You should also perform your cost analysis to decide which technology makes sense for you. If you are just spinning up a cronjob to perform some batch processing, Fargate may be a viable and cheaper option as you are being charged for the amount of time and resource used by the application.

How can I get started with Fargate on EKS

Reference: Getting started with AWS Fargate using Amazon EKS — Amazon EKS

Now that you have decided to use Fargate on EKS, the steps that you have to take are:

1. Create a Fargate Pod execution role. This role is created if you use eksctl with the — fargate flag.

2. Create a Fargate profile for the cluster and define your pod selection criteria, it can be based on namespace or label selectors.

Sample Fargate Profile (eks-fargate-profile.yaml)

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: $EKS_CLUSTER_NAME
  region: $AWS_REGION

fargateProfiles:
- name: <profile-name>
  selectors:
  - namespace: <namespace>
    labels:
      fargate: 'yes'
  subnets:
  - $PRIVATE_SUBNET_1
  - $PRIVATE_SUBNET_2
  - $PRIVATE_SUBNET_3
  podExecutionRoleARN: $FARGATE_IAM_PROFILE_ARN

Command to apply the above profile

cat ~/eks-fargate-profile.yaml \
| envsubst \
| eksctl create fargateprofile -f -

Command to verify that the profile has been created

aws eks describe-fargate-profile \
    --cluster-name $EKS_CLUSTER_NAME \
    --fargate-profile-name <profile-name>

Once both steps are done, you should be ready to update your deployment manifests and deploy the pods that you want to be running on Fargate.

Closing

This is a summary of what I have learnt about Fargate and EKS over the past couple of months when it 1st piqued my interest. In my journey, I learnt that with the implementation of a Serverless approach, Fargate has enabled me as a K8S user to focus purely on the application and I didn’t need to worry on infrastructure level updates, which enabled me to minimize the number of instance where my nodes needed to have downtime.

I’ve also learnt that though it is a useful and new technology, there are specific use-cases where Fargate can and cannot be used for. It is useful for stateless microservice, short running batch jobs or even applications which may require huge amounts of memory or CPU resources.

I am sure that there is still more to deep-dive into this interesting technology. I would definitely like to experiment on how the GitOps Toolkit will behavior in a Fargate cluster and this would be something that I will look into sometime in the near future. Thank you.