Week 11: Elastic Kubernetes Service (EKS) on AWS Lab Guide

• Let's create an EC2 instance which contains AWS CLI (to control AWS services), eksctl (to create EKS clusters) and kubectl (to control the cluster):

In this experiment, we only need one single EC2 instance:

• Here are the settings of the EC2:

  • Name: eksctl_kubectl_server

  • OS: Amazon Linux 2023 AMI (Latest one)

  • Instance Type: t3.micro (Free-tier)

  • Key pair: create a new key or reuse the old key.

  • Storage: Default 8 GB is plenty enough!

  • Security Group:

    • Optional Name: eksctl_kubectl_server_security_group

    • Source Type: Anywhere

    • Open only one port:

      • 22 for SSH

• Let’s wait for the EC2 instance state to be “Running” first. After that, let's attach the IAM role “LabRole" to this EC2 instance so this EC2 can execute commands as “LabRole”:

  • Why attach a role?

    • By attaching the LabRole (or in this case, a similar LabInstanceProfile) to the EC2 instance, you grant the AWS CLI running on that instance the permissions of that role.

    • This means you don't need to configure static AWS access keys (aws configure). The instance automatically retrieves temporary credentials, which is a much more secure practice.

    • Now, any aws or eksctl command you run from this instance will be authenticated as the LabRole, which has the necessary permissions to interact with your EKS cluster.

• After the EC2 instance is running, please SSH to that EC2 instance “eksctl_kubectl_server” you just created:

• Also, please change the hostname of this instance to “eksctl-kubectl-server” to keep it organized like so:

sudo nano /etc/hostname

• Reboot the EC2 instance so the new hostname is updated:

sudo reboot

• To keep things simple without dealing with permission, let’s login as a root user and change our current directory to /root:

sudo su -

• We can check the current version of AWS CLI:

aws --version

So the default version of AWS CLI is 2.17.18 which is good enough to meet the requirement to use eksctl which requires AWS CLI version >= 2.2.37. Nice!!!

• Let’s install kubectl which is the standard, open-source command-line tool for any Kubernetes cluster. It's used for deploying applications, inspecting resources, and managing the cluster's state.

• Next, let's install kubectl so please refer to this documentation:

• At this point of writing, the latest version of kubectl is 1.31 so let's install it!

• Download the kubectl binary for your cluster's Kubernetes version from Amazon S3:

curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/1.31.2/2024-11-15/bin/linux/amd64/kubectl

• Apply execute permissions to the binary:

chmod +x ./kubectl

• Copy the binary to a folder in your PATH.

mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin

• Add the $HOME/bin path to your shell initialization file so that it is configured when you open a shell.

echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc

• After you install kubectl, you can verify its version with the following command:

kubectl version --client

• Let’s install eksctl which is a popular open-source tool sponsored by AWS that simplifies many EKS-specific tasks. While you created the cluster through the console, eksctl is excellent for creating clusters, node groups, and other resources from the command line.

• Next, let's install eksctl so please refer to this documentation:

• Download and extract the latest release of eksctl with the following command.

curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

• Move the extracted binary to /usr/local/bin.

sudo mv /tmp/eksctl /usr/local/bin

• Test that your installation was successful with the following command.

eksctl version

• Let's display info of nodes in our cluster:

  • The kubectl get nodes command is the "hello world" of cluster management. Seeing your two nodes with a Ready status is the final confirmation that your cluster is fully operational.

kubectl get nodes

We can see these two of our EC2 worker nodes are ready to listen to our command!

• Using the kubectl get all command we can list down all the pods, services:

kubectl get all

Initially, there is no other service yet!

• Install git and clone the Github voting application repo:

yum install git -y
git clone https://github.com/TomHuynhSG/Simple-Voting-Application-Docker

• Change the current directory to be inside k8s-specifications folder where all of our k8s yaml files are located:

cd Simple-Voting-Application-Docker/aws-eks-example/k8s-specifications/

• Run these K8s yaml files to create deployments and services to launch the voting application:

  • The series of kubectl create -f <filename>.yaml commands is the core of deploying an application. Each command reads a YAML file and tells the Kubernetes API to create the resources defined within it (Deployments, Services, etc.). The explanation correctly breaks down the purpose of each component: a frontend (voting-app), a backend database (postgres), a cache (redis), a processor (worker-app), and a results viewer (result-app).

kubectl create -f voting-app-deploy.yaml
kubectl create -f voting-app-service.yaml
kubectl create -f redis-deploy.yaml
kubectl create -f redis-service.yaml
kubectl create -f postgres-deploy.yaml
kubectl create -f postgres-service.yaml
kubectl create -f worker-app-deploy.yaml
kubectl create -f result-app-deploy.yaml
kubectl create -f result-app-service.yaml

[Alternative] Instead of running each yaml file, you can also keep it simple by running “kubectl create -f .”

[Explanation] Each command uses a .yaml file to create different resources within the Kubernetes cluster:

• kubectl create -f voting-app-service.yaml & kubectl create -f voting-app-deploy.yaml : These commands launch the front-end part of the voting application. The voting-app-service.yaml defines the service that exposes the voting app to the users through a web interface. The voting-app-deploy.yaml defines a deployment, which manages the creation and scaling of the voting app pods.

• kubectl create -f redis-deploy.yaml & kubectl create -f redis-service.yaml : These commands are for deploying Redis, an in-memory data store used as a database, cache, and message broker. The redis-deploy.yaml creates the deployment for the Redis containers, while redis-service.yaml exposes Redis to the other components of the application that require it.

• kubectl create -f postgres-deploy.yaml & kubectl create -f postgres-service.yaml : These commands deploy a PostgreSQL database, which is a relational database used to persist data. The postgres-deploy.yaml handles the deployment of the PostgreSQL containers, and postgres-service.yaml makes the database accessible to other parts of the application that need to store or retrieve data.

• kubectl create -f worker-app-deploy.yaml : This command launches a background worker that processes tasks in the voting application, such as compiling and updating vote counts. The worker-app-deploy.yaml defines how this worker operates and scales within the Kubernetes environment.

• kubectl create -f result-app-deploy.yaml & kubectl create -f result-app-service.yaml : These commands are for the component that displays the results of the voting. The result-app-deploy.yaml sets up the deployment for the results application, and result-app-service.yaml defines the service to expose the results to users or other applications.

Each .yaml file contains the configuration for a specific part of the application and its related Kubernetes resources. Together, they work to create a distributed, scalable voting application.

• List out the deployment and services (svc) resources in the Kubernetes cluster:

  • The kubectl get deployments,svc command is used to check the status of the deployment. The key thing to look for is the EXTERNAL-IP for the services of type: LoadBalancer . This is the public DNS name of the AWS Elastic Load Balancer that EKS automatically created for you. This is the URL you will use to access the application.

kubectl get deployments,svc

These above screenshots are the payoff! They show the voting and result websites being accessed via the Load Balancer URLs. The bottom image connects the abstract DNS name to a concrete "Load Balancer" resource in the EC2 dashboard, reinforcing the link between Kubernetes and the underlying AWS services.

[Explanation]

• The first table of deployment shows the list of deployment resources in the Kubernetes cluster. Deployments are responsible for creating and updating instances of your application. We can see four deployments with names such as postgres-deploy, redis-deploy, etc.

• The second table of deployment shows the services in the Kubernetes cluster. Services in Kubernetes are an abstraction that defines a logical set of pods and a policy by which to access them, often via a network. The TYPE column indicates the kind of service, for example, ClusterIP which is a default type providing a service inside a cluster that other apps inside your cluster can access, and LoadBalancer which exposes the service externally to the cluster by using a cloud provider's load balancer. The EXTERNAL-IP for result-service and voting-service shows that these services are exposed outside of the cluster, likely allowing web traffic to reach the application. The red boxes highlight that the applications are accessible via the load balancers with external IP addresses and ports specified, suggesting that these services are reachable from outside the Kubernetes cluster. This is a common setup for web applications that need to be accessible to users or external systems.

• You can copy and paste the URL of these load balancers to access the voting website and the result website like below here:

  • Note: make sure your url has the http protocol like http:// … Otherwise the websites won’t be loaded without the correct URLs.

• Also, you can investigate further in the load balancer by going to the load balancer dashboard to look for the right balancer with the same DNS name like so:

• This screenshot below shows the details of the AWS Load Balancer. The key takeaway is the "Listeners" section. It shows that the load balancer is listening for traffic on port 80 (standard HTTP) and forwarding it to a TCP port on the worker nodes (in this case, 30790). Kubernetes manages this port mapping automatically.

• Let’s retrieve and list all resources (like pods, services, and deployments) in a Kubernetes cluster for further investigate:

  • The kubectl get all c ommand provides a comprehensive view of all the resources created. The explanation correctly identifies the four main types of objects:

  • Pods: The actual running instances of your application containers.

  • Services: The networking layer that exposes your pods.

  • Deployments: The controller that manages the Pods and ensures the desired number of replicas are running.

  • ReplicaSets : A lower-level controller managed by the Deployment, responsible for maintaining a stable set of replica Pods.

kubectl get all

[Explanation]

• Pods : The first section lists the pods, which are the smallest deployable units that can be created and managed in Kubernetes. Each pod represents a running process on your cluster. In this case, there are pods for PostgreSQL, Redis, a result app, and a worker app, each of which is running (1/1 READY) and has not been restarted since they were deployed (0 RESTARTS).

• Services : The second section lists the services, which provide stable endpoints for connecting to the pods. The services shown are for the database (db), Kubernetes itself (kubernetes), Redis, and two services related to the voting application (result-service and voting-service). The result-service and voting-service are exposed externally (LoadBalancer), which means they can be accessed from outside the Kubernetes cluster. External IP addresses are provided for these services, indicating where the services can be accessed.

• Deployments : The third section shows the deployments, which provide declarative updates to applications. A deployment allows you to describe an application’s life cycle, such as which images to use for the app, the number of pods, and the way to update them, among other aspects. There are deployments for PostgreSQL, Redis, the result app, and the worker app, all up-to-date and available.

• ReplicaSets : The last section lists the replica sets, which ensure that a specified number of pod replicas are running at any given time. This is useful for scaling and self-healing of the application. Each of the replica sets corresponds to one of the deployments and shows the desired count of replicas, which is 1 in this case, and the current count, which matches the desired count.

• The nice thing about EKS is to allow you to use EKS cluster dashboard with the “Resources” tab to monitor and check the components inside your cluster:

  • These below screenshots show the graphical equivalent of the kubectl commands. The AWS EKS console provides a user-friendly way to view the status of your Pods , Deployments , Services , and other Kubernetes resources. This can be very helpful for quick visual checks and for users who are less comfortable with the command line.

• Let’s clean up everything by deleting all resources in this kubernetes!

• Before deleting, you might want to list all the resources in the default namespace to review what will be deleted.

kubectl get all --namespace=default

• You can delete all resources in the default namespace using the following command. This command deletes pods, services, deployments, replicasets, etc.

kubectl delete all --all --namespace=default

• [Optional] If you want to delete specific types of resources only (like pods or services), you can specify the resource type.

kubectl delete pods,services --all --namespace=default

• Let's create a pod in our cluster using the httpd image from DockerHub:

  • kubectl run is a simple, imperative way to create a single pod. It's great for quick tests.

kubectl run webapp --image=httpd

• Let's check out if our pod is running:

kubectl get pods

As you can see, the pod name “webapp" is running!

Awesome! Let's move on to the next section so we need to clean up this pod by deleting it!

kubectl delete pod webapp

• Let's check out if our pod is deleted:

kubectl get pods

• Deploying two pods contains Nginx container and expose these two pods at port 80:

  • This is a more robust imperative command that creates a Deployment, which in turn creates a ReplicaSet and the desired number of Pods (in this case, 2). This is the preferred imperative method for creating workloads.

kubectl create deployment demo-nginx --image=nginx --replicas=2 --port=80

• List all deployments of the cluster:

kubectl get deployment

• List all replicasets of the cluster:

kubectl get replicaset

• List all pods of the cluster:

kubectl get pods

• List all resources in one go:

kubectl get all

• So far, these two pods are only accessible within the internal IP addresses so we need to expose them.

• Expose the deployment as a service. This will create an ELB in front of those 2 containers and allow us to publicly access them.

  • This is a key command. It creates a Service that "exposes" the pods managed by the deployment. By specifying --type=LoadBalancer, you are telling Kubernetes to provision an external AWS Load Balancer and configure it to send traffic to the Nginx pods. The diagram perfectly illustrates this relationship.

kubectl expose deployment demo-nginx --port=80 --type=LoadBalancer

Here is the explanation:

• When you deploy, you set the replicas to be 2 so the replica set will create two pods.

  • When you run the “expose" command, then you will attach a load balancer (SVC) to access these two pods and allow the browser to open the content inside those pods via the public DNS of your load balancer.

• This is how you can verify the result of the expose command. You find the EXTERNAL-IP from kubectl get service, see the corresponding Load Balancer in the AWS console, and then access the Nginx welcome page using its DNS name. The kubectl describe service command provides detailed information, including the Events section which shows the progress of the load balancer creation.

kubectl get service

• That created a load balancer in AWS to expose these two pods for us! Let’s check out the information in the AWS Load Balancer dashboard!

The DNS name of the load balancer matches the External IP of our service in the cluster!

• You can list out all events happening in the K8s cluster to see if the load balancer is ready:

kubectl get events --sort-by=.metadata.creationTimestamp

• Or you can list out only events happening in a specific service to see if the load balancer is ready:

kubectl describe service demo-nginx

These events show that our load balancer is ready!

• Let’s open the browser and enter that DNS name / IP address:

You should see the welcome page of nginx which is served by our load balancer!

• You can check out about the port forwarding of the load balancer:

• Let’s list out all the resources of our cluster again!

kubectl get all

• Let's clean up everything to move on to the next section!

kubectl delete deployment demo-nginx

kubectl delete service/demo-nginx

This takes some time to delete service as it will clean up resources and delete the load balancer also!

• Let’s list out all the resources of our cluster again!

kubectl get all

All is gone! Nice!

• Let’s create a “pod.yml” manifest file to create a pod

nano pod.yml

apiVersion: v1
kind: Pod
metadata:
 name: nginx-pod
 labels:
  app: demo-app
spec:
 containers:
 - name: nginx-container
  image: nginx
  ports:
  - name: nginx
  containerPort: 80

• Create a pod by running that manifest yaml file:

kubectl apply -f pod.yml

• Let’s list out all the resources of our cluster!

kubectl get all

• Next, let’s create a manifest yaml file “service.yml” to create a service:

nano service.yml

apiVersion: v1
kind: Service
metadata:
 name: demo-service
spec:
 ports:
 - name: demo-service
  port: 80
  targetPort: 80
 selector:
  app: demo-app
 type: LoadBalancer

• Create a service by running that manifest yaml file:

kubectl apply -f service.yml

• Let’s list out all the resources of our cluster!

kubectl get all

• We can get more information of that service:

kubectl describe service/demo-service

Note: Did you realize we need to match the name “demo-app” for the selector of our balancer and the labels of our pod so that every traffic coming to the balancer will be redirected to the pods.

• You can check out the details of our load balancer in the AWS dashboard:

• Let’s open the browser and enter that DNS name / IP address:

• Display more information of the pod:

kubectl get pod -o wide

You can even see the private ip address and the name of the EC2 instance running that pod!

• Nice, now, let’s clean up everything!

kubectl delete service/demo-service
kubectl delete pod/nginx-pod

After cleaning up, only the default kubernetes service is running!

• To totally clean up everything, you should delete the worker node group and the EKS cluster as well like below!

  • Deleting the managed node group from the EKS console will trigger the termination of the associated EC2 worker nodes.

• Once the node group is gone, you can delete the cluster itself. This de-provisions the entire EKS control plane.

It will take some time to clean up everything in the cluster! So wait for it!

That's it! Great job! What a great success to wrap things up!

Congrats for finishing the final lab for learning AWS EKS! This is an amazing journey of conquering DevOps together! Thank you for your hard work and patience to reach the finish line of this journey!

Note : keep in mind that EKS is very expensive to run because Amazon EKS requires running multiple underlying resources like EC2 worker nodes, load balancers, and networking components, even for small clusters, so you end up paying for all those supporting services in addition to the EKS control plane fee, which makes even short learning experiments costly. So try to wisely manage your resources with AWS EKS. Otherwise it will burn all of your AWS Learner Lab credits.