What if you could deploy your app everywhere with just one command, no sweat?
Why Deploying workloads on EKS in AWS? - Purpose & Use Cases
Imagine you have a website or app that needs to run on many computers at once to handle lots of visitors. You try to set up each computer by hand, installing software and copying files one by one.
This manual way is slow and tiring. If you make a small mistake on one computer, your app might break. Also, when you want to add more computers or fix problems, it takes a lot of time and effort.
Using EKS (Elastic Kubernetes Service) lets you tell the system what your app needs, and it automatically runs your app on many computers. It handles starting, stopping, and fixing your app without you doing it all manually.
ssh server1 install app ssh server2 install app ...
kubectl apply -f app-deployment.yaml
You can easily run and manage your app at large scale without worrying about each computer individually.
A company launches a new online store and uses EKS to quickly deploy their app so it can handle thousands of shoppers at once without downtime.
Manual setup is slow and error-prone.
EKS automates running apps on many computers.
This makes scaling and managing apps simple and reliable.
Practice
Solution
Step 1: Understand EKS functionality
Amazon EKS is a managed Kubernetes service that lets you run containers without managing the underlying servers.Step 2: Compare options
Storing data relates to services like S3, creating VMs to EC2, and managing permissions to IAM--none of which is EKS's core purpose.Final Answer:
To run containerized applications using Kubernetes without managing servers -> Option AQuick Check:
EKS = Managed Kubernetes for containers [OK]
- Confusing EKS with storage services like S3
- Thinking EKS manages virtual machines directly
- Mixing EKS with IAM user management
app-deployment.yaml on EKS?Solution
Step 1: Identify the kubectl command for applying YAML
The correct command to deploy resources defined in a YAML file iskubectl apply -f filename.Step 2: Evaluate other options
kubectl run app-deployment.yamlis for running individual pods, not applying YAML manifests.eksctl create app app-deployment.yamlmisuses eksctl, which is primarily for EKS cluster creation.aws eks deploy app-deployment.yamlis not a valid AWS CLI command.Final Answer:
kubectl apply -f app-deployment.yaml -> Option DQuick Check:
Deploy YAML with kubectl apply -f [OK]
- Using eksctl for direct YAML deployment
- Confusing kubectl run with apply
- Trying AWS CLI commands that don't exist
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: nginx:latest
What will be the number of running pods after applying this deployment?
Solution
Step 1: Read the replicas field in the Deployment spec
The YAML specifiesreplicas: 3, which means Kubernetes will create 3 pods for this deployment.Step 2: Understand pod creation behavior
Unless there is a scheduling issue, Kubernetes will run 3 pods as requested.Final Answer:
3 -> Option BQuick Check:
replicas = number of pods running [OK]
- Assuming only 1 pod runs by default
- Thinking pods depend on node capacity without error
- Confusing selector labels with pod count
kubectl apply -f deployment.yaml, but got an error: error: unable to recognize "deployment.yaml": no matches for kind "Deploy". What is the likely cause?Solution
Step 1: Analyze the error message
The error says no matches for kind "Deploy", which means Kubernetes does not recognize this resource kind.Step 2: Check the YAML kind field
The correct kind for workload deployment is "Deployment", not "Deploy". This typo causes the error.Final Answer:
The YAML file has a typo in the kind field; it should be 'Deployment' not 'Deploy' -> Option CQuick Check:
Kind field must be exact Kubernetes resource name [OK]
- Ignoring error details about resource kind
- Assuming cluster or kubectl issues without checking YAML
- Blaming image name for syntax errors
Solution
Step 1: Identify resource for managing pod replicas with scaling
A Deployment manages stateless pods and can be combined with a Horizontal Pod Autoscaler (HPA) to scale pods based on CPU.Step 2: Understand autoscaling setup
Set Deployment replicas to minimum 2, and HPA to scale up to max 5 pods based on CPU usage.Step 3: Evaluate other options
StatefulSet is for stateful apps, DaemonSet runs pods on all nodes (not scaling pods), fixed replicas do not autoscale.Final Answer:
A Deployment with replicas set to 2 and a Horizontal Pod Autoscaler targeting CPU usage with max replicas 5 -> Option AQuick Check:
Deployment + HPA = autoscaling pods [OK]
- Using StatefulSet for stateless apps
- Confusing DaemonSet with autoscaling pods
- Setting fixed replicas without autoscaler
Ready to prove it?
Pass the test and this pattern moves unknown
