Deploying a Production-Style Amazon EKS Cluster on Fargate with AWS Load Balancer Controller
A comprehensive guide on deploying a Kubernetes application on Amazon EKS using AWS Fargate and exposing it via an Application Load Balancer.
Stock photo for illustration only, not from the actual event
- Run all workloads on AWS Fargate without managing worker nodes
- Configure OpenID Connect and a dedicated Fargate profile for the game-2048 namespace
- Troubleshoot common Helm repository issues and Fargate IMDS access limitations
This technical guide details the process of deploying a Kubernetes application on Amazon Elastic Kubernetes Service (EKS) leveraging AWS Fargate, while routing traffic through an Application Load Balancer (ALB) managed by the AWS Load Balancer Controller. By running all application workloads directly on AWS Fargate, system administrators completely bypass the overhead of managing underlying worker nodes.
Before diving into the deployment steps, verify that all necessary command-line utilities are installed and properly configured on your local machine:
- AWS CLI (verify via
aws --version) - Kubectl (verify via
kubectl version --client) - Eksctl (verify via
eksctl version) - Helm (verify via
helm version)
Additionally, the IAM user executing the deployment must be granted specific AWS managed policies. These include permissions to create and manage EKS clusters, allow EKS to interact with other AWS services, handle node and Fargate operations, permit Kubernetes components to pull container images from ECR, and create IAM roles, service accounts, and AWS CloudFormation stacks as required by eksctl.
Combining Amazon EKS with AWS Fargate delivers a true serverless container orchestration experience, removing the operational burden of patching operating systems and scaling EC2 instances. However, developers must be mindful of architectural differences, such as the restriction where Fargate pods cannot directly access the EC2 Instance Metadata Service (IMDS), requiring explicit configuration workarounds.
Once prerequisites and permissions are verified, you can provision the cluster using the command eksctl create cluster --name demo-eks-cluster --region us-east-1 --fargate. Afterward, update the kubeconfig file so that kubectl can seamlessly communicate with the newly created cluster. It is worth noting that for Fargate deployments, running kubectl get nodes will not display any EC2 instances.
Stock photo for illustration only, not from the actual event
To ensure secure communication between Kubernetes service accounts and AWS IAM roles, OpenID Connect (OIDC) must be associated using IRSA (IAM Roles for Service Accounts), granting pods temporary AWS credentials safely. Furthermore, creating a namespace-specific Fargate profile is accomplished via eksctl create fargateprofile --cluster demo-eks-cluster --region us-east-1 --name alb-game-2048 --namespace game-2048 to isolate the application workloads.
During the installation of the AWS Load Balancer Controller—which manages ALB resources for Kubernetes Ingress—you might encounter a Helm repository communication error resulting in an EOF when running helm repo add eks https://aws.github.io/eks-charts, even if fetching the index file directly via curl works. The workaround involves downloading the tarball explicitly using wget, such as wget https://aws.github.io/eks-charts/aws-load-balancer-controller-3.4.3.tgz, and installing it locally via Helm.
Another common hurdle involves a CrashLoopBackOff error accompanied by the message failed to fetch VPC ID from instance metadata during controller log inspection. Because Fargate pods lack access to the EC2 IMDS, administrators must explicitly query the VPC ID using the AWS CLI command aws eks describe-cluster --name demo-eks-cluster --region us-east-1 --profile dev --query "cluster.resourcesVpcConfig.vpcId".
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment