Introducing Today's Project!
In this project, I will deploy a containerized backend application to an Amazon EKS cluster because it provides a highly scalable, managed orchestration environment. This involves building a Docker image, pushing it to Amazon ECR, and defining the infrastructure state using Kubernetes Deployment and Service manifests applied via kubectl.
Tools and concepts
Key tools utilized include eksctl for Amazon EKS cluster provisioning, Docker for containerization, Amazon ECR for secure image storage, and kubectl for resource management. Core concepts demonstrated are Kubernetes orchestration, declarative state management via YAML manifests (Deployments and Services), immutable container deployments, and internal cluster networking using NodePort configurations.
Project reflection
This project took me approximately 90 minutes to complete. My favourite part was executing the kubectl apply commands to orchestrate the immutable backend container and establish NodePort routing across the distributed EKS worker nodes.
Project Set Up
Kubernetes cluster
To set up today's project, I launched a Kubernetes cluster using the eksctl CLI on a provisioned EC2 instance. The cluster's role in this deployment is to serve as a managed orchestration control plane via Amazon EKS, automating the scheduling, scaling, and networking of the containerized backend across a 3-node t3.micro compute group.
Error above showing `eksctl` not installed.
To install it, I ran;
`curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv -v /tmp/eksctl /usr/local/bin
`
Backend code
I retrieved backend code by executing a git clone command on the provisioned EC2 instance to pull the remote nextwork-flask-backend repository. Pulling code is essential to this deployment because the repository contains the Python application source files and the Dockerfile required to compile the standardized, immutable container image that Kubernetes will orchestrate.
Container image
Once I cloned the backend code, I built a container image because it creates a standardized, immutable package containing the application source and all necessary dependencies. Without an image, it would be difficult for Kubernetes to reliably provision identical, scalable container replicas across the cluster nodes, as the orchestrator requires a centralized, consistent artifact for deployment.
I also pushed the container image to a container registry, which is Amazon Elastic Container Registry (ECR), a fully managed, secure AWS repository for container artifacts. ECR facilitates scaling for my deployment because its native IAM integration with Amazon EKS enables the Kubernetes control plane to rapidly authenticate and pull immutable image replicas across distributed worker nodes on demand.
Manifest files
Kubernetes manifests are declarative YAML configuration files that define the desired state of cluster resources, specifying parameters such as container images, replica counts, and resource allocations. Manifests are helpful because they automate application orchestration, enabling reproducible, consistent deployments while eliminating the operational overhead and error-prone nature of manual container configuration.
A Deployment manifest manages the desired state of application replicas by automating the creation, scaling, and rolling updates of container groups across the cluster. The container image URL in my Deployment manifest tells Kubernetes the exact Amazon ECR registry location to authenticate against and pull the immutable Docker artifact from when provisioning new pods.
A Service resource exposes deployed applications to network traffic by establishing stable routing rules across dynamic pod replicas. My Service manifest sets up a NodePort configuration, instructing the Kubernetes control plane to map external node port requests to internal target port 8080 on pods bearing the app:nextwork-flask-backend label.
Backend Deployment!
To deploy my backend application, I updated the local kubeconfig using the AWS CLI to authenticate with the Amazon EKS control plane. Next, I executed the kubectl apply command on the Deployment and Service YAML manifests to schedule the container replicas and establish NodePort routing rules across the cluster.
kubectl
kubectl is the primary command-line interface for interacting with the Kubernetes control plane. I need this tool to authenticate with the EKS cluster and apply the declarative YAML manifests that orchestrate the application deployment. I can't use eksctl for the job because it is specifically designed for provisioning and managing the underlying EKS infrastructure, not for scheduling workloads or managing internal Kubernetes resources.
Verifying Deployment
My extension for this project is to use the EKS console to verify the deployment status, inspect the provisioned node groups, and confirm that the backend pods are running successfully. I had to set up IAM access policies because AWS IAM permissions do not automatically grant authorization within the internal Kubernetes RBAC system. I set up access by executing the eksctl create iamidentitymapping command to map my IAM User ARN to the Kubernetes system:masters group.
Once I gained access into my cluster's nodes, I discovered pods running inside each node. Pods are the smallest deployable units in Kubernetes, designed to bundle one or more containers together to function as a cohesive workload. Containers in a pod share the same network address space and underlying storage resources, which enables efficient inter-process communication and localized data synchronization.
The EKS console shows you the events for each pod, where I could see the control plane's sequence of operations, including internal IP assignment, image retrieval from Amazon ECR, and container initialization. This validated that the backend application was successfully provisioned, actively running, and accessible within the internal cluster network.
Top comments (0)