Deploying workloads on EKS in AWS - Deep Dive

Overview - Deploying workloads on EKS

What is it?

Deploying workloads on EKS means running your applications inside containers on a managed Kubernetes service provided by AWS. EKS handles the complex parts of Kubernetes setup and management, so you can focus on your app. Workloads are the actual programs or services you want to run, packaged as containers, which EKS schedules and runs on a cluster of servers.

Why it matters

Without EKS, managing Kubernetes clusters is hard and time-consuming, requiring deep knowledge and constant upkeep. EKS solves this by automating cluster management, making it easier and safer to run containerized apps at scale. This means faster development, reliable app delivery, and less worry about infrastructure problems.

Where it fits

Before learning this, you should understand basic container concepts and what Kubernetes is. After mastering deploying workloads on EKS, you can explore advanced topics like scaling, monitoring, and securing Kubernetes clusters on AWS.

Mental Model

Core Idea

Deploying workloads on EKS is like handing your packed suitcases (containers) to a trusted travel agent (EKS) who arranges the best flights and hotels (Kubernetes cluster) so your trip (application) runs smoothly without you managing every detail.

Think of it like...

Imagine you have many packages to deliver across a city. Instead of driving each yourself, you hire a delivery company that knows the best routes and handles all logistics. You just prepare the packages and trust them to deliver on time. EKS is that delivery company for your containerized apps.

┌─────────────────────────────┐
│       Your Application       │
│  (Containerized Workloads)   │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│       Amazon EKS Cluster     │
│  ┌───────────────┐          │
│  │ Kubernetes    │          │
│  │ Control Plane │          │
│  └──────┬────────┘          │
│         │                   │
│  ┌──────▼───────┐           │
│  │ Worker Nodes │           │
│  │ (EC2 or Fargate)│         │
│  └───────────────┘          │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Containers and Kubernetes Basics

Concept: Learn what containers are and the role of Kubernetes in managing them.

Containers package your app and its environment so it runs the same everywhere. Kubernetes is a system that organizes and runs many containers across multiple servers, handling tasks like starting, stopping, and scaling them.

Result

You understand that containers are portable app packages and Kubernetes is the tool that manages these packages at scale.

Knowing containers and Kubernetes basics is essential because EKS is a managed Kubernetes service that runs containers efficiently.

2

Foundation

Introducing Amazon EKS Service

Concept: Discover what Amazon EKS is and how it simplifies Kubernetes management.

Amazon EKS is a cloud service that runs Kubernetes control planes for you. It handles setup, upgrades, and availability, so you don't have to manage the complex parts of Kubernetes yourself.

Result

You see that EKS removes much of the manual work needed to run Kubernetes, making it easier to deploy containerized apps.

Understanding EKS's role helps you focus on deploying your workloads instead of managing infrastructure.

3

Intermediate

Preparing Your Workload for Deployment

🤔Before reading on: do you think you need to write special code to deploy on EKS or just package your app as a container? Commit to your answer.

Concept: Learn how to package your application as a container and prepare Kubernetes deployment files.

You create a Docker container image of your app, which includes your code and environment. Then, you write Kubernetes YAML files describing how to run your app, including replicas, ports, and resource needs.

Result

You have a container image and deployment configuration ready to be applied to EKS.

Knowing that deployment is about packaging and configuration, not rewriting code, makes the process approachable and repeatable.

4

Intermediate

Connecting to EKS and Applying Workloads

🤔Before reading on: do you think you connect to EKS using a web console only, or can you use command-line tools? Commit to your answer.

Concept: Learn how to access your EKS cluster and deploy workloads using command-line tools.

You use AWS CLI and kubectl (Kubernetes command-line tool) to connect to your EKS cluster. After configuring access, you run commands to create deployments and services from your YAML files, which starts your app on the cluster.

Result

Your application containers start running on the EKS cluster nodes.

Understanding command-line access empowers you to automate and control deployments efficiently.

5

Intermediate

Using Managed Node Groups and Fargate

🤔Before reading on: do you think EKS requires you to manage all servers yourself, or does it offer options to simplify this? Commit to your answer.

Concept: Explore how EKS offers managed node groups and serverless options to run workloads without managing servers directly.

Managed node groups let AWS handle the servers (EC2 instances) that run your containers, including updates and scaling. Fargate lets you run containers without any servers to manage, paying only for the resources your containers use.

Result

You can choose between managing servers or using serverless compute for your workloads.

Knowing these options helps you pick the best balance between control and simplicity for your apps.

6

Advanced

Scaling and Updating Workloads Safely

🤔Before reading on: do you think scaling and updating workloads on EKS happens instantly or requires careful steps? Commit to your answer.

Concept: Learn how to scale your app up or down and update it without downtime using Kubernetes features on EKS.

You use Kubernetes commands or autoscaling to increase or decrease the number of app instances. For updates, you apply new container images with rolling updates, which replace old instances gradually to avoid downtime.

Result

Your app can handle more users or new versions smoothly without stopping service.

Understanding safe scaling and updates is key to maintaining reliable applications in production.

7

Expert

Optimizing Workload Deployment with Advanced Features

🤔Before reading on: do you think deploying workloads on EKS is only about running containers, or can you optimize cost, security, and performance? Commit to your answer.

Concept: Discover advanced deployment techniques like using namespaces, resource quotas, and security policies to optimize your workloads.

Namespaces isolate workloads for teams or projects. Resource quotas prevent any workload from using too many resources. Security policies control what containers can do, improving safety. You also learn about spot instances and node taints to optimize cost and performance.

Result

Your deployments are efficient, secure, and cost-effective in a shared environment.

Knowing these advanced features lets you run professional-grade Kubernetes workloads on EKS.

Under the Hood

EKS runs a Kubernetes control plane managed by AWS, which schedules container workloads onto worker nodes. These nodes can be EC2 instances or serverless Fargate pods. The control plane monitors cluster state, manages API requests, and ensures workloads run as specified. Communication happens via Kubernetes APIs, and AWS integrates with IAM for secure access control.

Why designed this way?

EKS was designed to remove the complexity of managing Kubernetes control planes, which require high availability and security expertise. AWS chose a managed control plane to let users focus on workloads, while still allowing flexibility with worker nodes. Alternatives like self-managed Kubernetes clusters require more effort and risk.

┌───────────────────────────────┐
│       Amazon EKS Control      │
│           Plane               │
│  ┌───────────────┐            │
│  │ API Server    │◄───────────┤
│  ├───────────────┤            │
│  │ Scheduler     │            │
│  └──────┬────────┘            │
│         │                    │
│         ▼                    │
│  ┌───────────────┐           │
│  │ Worker Nodes  │           │
│  │ (EC2/Fargate) │           │
│  └───────────────┘           │
└───────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think EKS automatically scales your application containers without any setup? Commit to yes or no.

Common Belief: EKS automatically scales my app containers whenever needed without extra configuration.

Reality: EKS manages the Kubernetes control plane but does not automatically scale your app containers unless you configure Kubernetes autoscaling features.

Why it matters: Assuming automatic scaling leads to unexpected downtime or resource waste because your app won't scale without proper setup.

Quick: Do you think you must manage all Kubernetes servers yourself when using EKS? Commit to yes or no.

Common Belief: Using EKS means I have to manage all the servers running my containers.

Reality: EKS manages the control plane servers, and you can use managed node groups or Fargate to avoid managing worker servers.

Why it matters: Believing you must manage all servers can discourage using EKS or lead to unnecessary operational work.

Quick: Do you think deploying on EKS requires rewriting your app code? Commit to yes or no.

Common Belief: To deploy on EKS, I need to change my application code to fit Kubernetes.

Reality: You only need to package your app as a container and write deployment configs; the app code itself usually stays the same.

Why it matters: Thinking code changes are needed can slow adoption and cause unnecessary rewrites.

Quick: Do you think EKS is only for large companies with big teams? Commit to yes or no.

Common Belief: EKS is too complex and expensive for small projects or teams.

Reality: EKS can be used for small to large projects, and features like Fargate reduce complexity and cost for smaller workloads.

Why it matters: This misconception limits who benefits from EKS and can prevent efficient use of cloud resources.

Expert Zone

1

EKS control plane is multi-AZ by default, providing high availability without user setup, but worker nodes need careful placement for resilience.

2

Using Kubernetes namespaces in EKS is crucial for multi-team environments to avoid resource conflicts and improve security.

3

Fargate on EKS abstracts away nodes but has limitations on supported Kubernetes features and resource types, requiring tradeoffs.

When NOT to use

EKS may not be ideal if you need full control over Kubernetes versions or custom control plane configurations; in such cases, self-managed Kubernetes or other managed services like AWS ECS might be better.

Production Patterns

In production, teams use Infrastructure as Code tools like Terraform or AWS CloudFormation to automate EKS cluster and workload deployment, combined with CI/CD pipelines for continuous updates and monitoring tools like Prometheus and Grafana for health tracking.

Connections

Infrastructure as Code (IaC)

Builds-on

Understanding IaC helps automate and reliably reproduce EKS cluster and workload deployments, reducing manual errors.

Serverless Computing

Alternative approach

Knowing serverless concepts clarifies when to use EKS Fargate for container workloads without managing servers, blending container orchestration with serverless ease.

Supply Chain Logistics

Analogous system

The way EKS schedules and routes containers to nodes is similar to how logistics companies route packages efficiently, highlighting optimization and resource management principles.

Common Pitfalls

#1 Trying to deploy workloads without configuring kubectl access to EKS cluster.

Wrong approach:

kubectl apply -f deployment.yaml
# Error: Unable to connect to the server: dial tcp ...

Correct approach:

aws eks update-kubeconfig --name your-cluster-name
kubectl apply -f deployment.yaml

Root cause:

Not setting up local Kubernetes config to authenticate and connect to the EKS cluster.

#2 Using latest tag for container images in production deployments.

Wrong approach:

image: myapp:latest

Correct approach:

image: myapp:v1.2.3

Root cause:

Using 'latest' causes unpredictable deployments because the image can change without notice, breaking reproducibility.

#3 Deploying workloads without resource requests and limits defined.

Wrong approach:

containers:
- name: app
image: myapp:v1
# no resources specified

Correct approach:

containers:
- name: app
image: myapp:v1
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "512Mi"

Root cause:

Omitting resource specs can cause unstable cluster performance due to resource contention.

Key Takeaways

Deploying workloads on EKS means running containerized apps on a managed Kubernetes service that handles complex infrastructure tasks for you.

You prepare your app by packaging it as a container and writing Kubernetes deployment files, then use command-line tools to deploy on EKS.

EKS offers options like managed node groups and Fargate to simplify or customize how your containers run on servers.

Scaling and updating workloads on EKS use Kubernetes features to keep apps running smoothly without downtime.

Advanced features like namespaces, resource quotas, and security policies help optimize and secure production workloads on EKS.