Kubernetes on AWS (EKS)

Kubernetes Refresher

Kubernetes (K8s) orchestrates containerized applications — handling deployment, scaling, networking, and self-healing. This module is a refreshercovering cluster architecture, components, object properties, and hands-on demos on AWS EKS.

Anatomy of a Kubernetes Cluster

A K8s cluster has two layers: the Control Plane (the brain) and the Worker Nodes (the muscle). On managed services like EKS, AWS runs the control plane for you.

┌─────────────────────── CONTROL PLANE ───────────────────────┐
│                                                             │
│  ┌──────────────┐  ┌───────────┐  ┌──────────────────────┐  │
│  │  API Server   │  │   etcd    │  │  Controller Manager  │  │
│  │  (kube-api)   │  │ (key-val  │  │  (node, replicaset,  │  │
│  │               │  │  store)   │  │   endpoint, etc.)    │  │
│  └──────────────┘  └───────────┘  └──────────────────────┘  │
│                                                             │
│  ┌──────────────┐  ┌────────────────────────────────────┐   │
│  │  Scheduler    │  │  Cloud Controller Manager (EKS)   │   │
│  └──────────────┘  └────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

┌──────── WORKER NODE 1 ────────┐  ┌──────── WORKER NODE 2 ────────┐
│  ┌─────────┐  ┌────────────┐  │  │  ┌─────────┐  ┌────────────┐  │
│  │ kubelet  │  │ kube-proxy │  │  │  │ kubelet  │  │ kube-proxy │  │
│  └─────────┘  └────────────┘  │  │  └─────────┘  └────────────┘  │
│  ┌──────────────────────────┐ │  │  ┌──────────────────────────┐ │
│  │  Container Runtime       │ │  │  │  Container Runtime       │ │
│  │  (containerd / CRI-O)    │ │  │  │  (containerd / CRI-O)    │ │
│  └──────────────────────────┘ │  │  └──────────────────────────┘ │
│  ┌─────┐ ┌─────┐ ┌─────┐     │  │  ┌─────┐ ┌─────┐             │
│  │Pod A│ │Pod B│ │Pod C│     │  │  │Pod D│ │Pod E│             │
│  └─────┘ └─────┘ └─────┘     │  │  └─────┘ └─────┘             │
└───────────────────────────────┘  └───────────────────────────────┘

Control Plane Components

The control plane makes global decisions about the cluster and detects/responds to events.

Worker Node Components

Every worker node runs three essential components that keep pods alive and networked:

🤖 kubelet

The agent running on every node. It receives pod specs from the API server and ensures the described containers are running and healthy. It:

• Pulls container images from registries (ECR, Docker Hub)
• Starts/stops containers via the container runtime
• Reports node status and pod health back to the API server
• Executes liveness and readiness probes
• Mounts volumes (EBS, EFS, ConfigMaps, Secrets)

🌐 kube-proxy

Handles networking rules on each node. When you create a K8s Service, kube-proxy sets up iptables/IPVS rules so that traffic to the Service's ClusterIP gets forwarded to the correct pod(s). It:

• Maintains network rules for Service → Pod routing
• Load-balances across pod replicas using round-robin
• Handles NodePort and ClusterIP traffic forwarding
• Updates rules dynamically as pods are added/removed

📦 Container Runtime

The software that actually runs containers. K8s doesn't run containers directly — it delegates to a runtime via the Container Runtime Interface (CRI).

How They Work Together

You run: kubectl apply -f deployment.yaml

1. kubectl → API Server:    "Create 3 pods of my-app"
2. API Server → etcd:       Stores the desired state
3. Scheduler → API Server:  "Pod X should go on Node 2" (picks best node)
4. API Server → kubelet:    "Hey Node 2, run Pod X"
5. kubelet → containerd:    "Pull image, start container"
6. kubelet → API Server:    "Pod X is Running"
7. kube-proxy:              Updates iptables so Service routes to new pod
8. Controller Manager:      Continuously watches — if a pod dies, repeats 3-7

Properties of Kubernetes Objects

K8s objects have fundamental properties that shape how you design and operate applications. Understanding these is critical for building resilient systems.

⚛️ Atomicity of Pods

A pod is the atomic unit of scheduling. All containers in a pod are scheduled together, run on the same node, and share the same lifecycle:

• If any container in a pod fails its restart policy, the entire pod may be restarted
• All containers share the same network namespace (same IP, can communicate via localhost)
• All containers share the same storage volumes
• A pod cannot be split across multiple nodes — it's all-or-nothing

💨 Ephemerality

Pods are ephemeral by design — they can be killed, rescheduled, or replaced at any time. This is a feature, not a bug:

• No guarantees on lifespan — a pod may live for seconds or months
• New IP on restart — never hardcode pod IPs (use Services instead)
• Local storage is lost on pod deletion (use PersistentVolumes for data)
• Nodes can fail — pods on a failed node are rescheduled to healthy nodes

Pod dies or node fails:
  ┌──────────┐        ┌──────────┐
  │ Pod v1   │  ──X── │ Pod v1   │  ← pod is terminated
  │ IP: 10.1 │        │ IP: gone │
  └──────────┘        └──────────┘
                          │
                     Scheduler picks new node
                          │
                      ┌──────────┐
                      │ Pod v1   │  ← brand new pod
                      │ IP: 10.7 │  ← different IP!
                      └──────────┘

This is why you always use a Service (stable IP) to reach pods.

📜 Declarative Model

You declare the desired state (e.g., "I want 3 replicas running image v2") and K8s continuously reconciles the actual state to match. You never say "start a container" — you say "the desired state is 3 containers."

🏷️ Labels & Selectors

Labels are key-value pairs attached to objects. Selectors filter objects by labels. This is how K8s connects everything — a Service finds its pods, a Deployment manages its ReplicaSet, and HPA targets a Deployment, all through label matching.

# Pod with labels
metadata:
  labels:
    app: my-api
    env: production
    version: v2

# Service uses selector to find matching pods
spec:
  selector:
    app: my-api       # matches pods with app=my-api
  ports:
    - port: 80

📐 Resource Requests & Limits

Every container should declare how much CPU and memory it needs. This is critical for scheduling and stability:

resources:
  requests:
    cpu: 100m        # 100 millicores = 10% of 1 CPU core
    memory: 128Mi    # guaranteed 128MB RAM
  limits:
    cpu: 500m        # max 50% of 1 CPU core (throttled beyond this)
    memory: 256Mi    # killed (OOMKilled) if exceeds 256MB

Core Kubernetes Objects

📦 Pods

The smallest deployable unit. A pod wraps one or more containers that share the same network namespace (same IP, same ports) and storage volumes. You rarely create pods directly — you use Deployments.

🚀 Deployments

Manages ReplicaSets and handles rolling updates. Declares the desired state: image, replicas, update strategy. K8s continuously ensures that state is met. If a pod dies, the Deployment creates a replacement.

🌐 Services

A stable network abstraction over ephemeral pods. Because pods get new IPs when rescheduled, you need a fixed endpoint. Services provide this:

🚪 Ingress

HTTP routing rules that map domains/paths to services. On EKS, the AWS ALB Ingress Controller translates Ingress resources into real ALBs.

📁 Namespaces

Virtual clusters within a cluster. Isolate environments (dev/staging/prod) or teams. Resource quotas and network policies can be scoped per namespace.

📊 HPA (Horizontal Pod Autoscaler)

Autoscales pod replicas based on CPU, memory, or custom metrics. It's the K8s equivalent of EC2 Auto Scaling Groups.

Other Important Objects

EKS — Elastic Kubernetes Service

EKS is AWS's managed Kubernetes. AWS manages the control plane(API server, etcd, scheduler) and you manage the worker nodes.

Setting Up EKS

# Install eksctl (the EKS CLI — like 'az aks create')
brew install eksctl

# Create a cluster (takes ~15 minutes)
eksctl create cluster \
  --name sandbox-eks \
  --region us-east-1 \
  --version 1.29 \
  --nodegroup-name standard \
  --node-type t3.medium \
  --nodes 2 \
  --nodes-min 1 \
  --nodes-max 4

# Verify
kubectl get nodes

EKS Cleanup

# Delete the cluster (removes all resources)
eksctl delete cluster --name sandbox-eks --region us-east-1

Key Takeaways

• Control plane = API server + etcd + scheduler + controllers (managed by AWS on EKS)
• Worker nodes = kubelet (agent) + kube-proxy (networking) + container runtime (containerd)
• Pods are atomic — all containers co-scheduled, same node, same network, same lifecycle
• Pods are ephemeral — design for failure, never rely on pod IPs, use Services for stable endpoints
• Declarative model — declare desired state, K8s continuously reconciles
• Labels + selectors are how K8s connects everything (Services → Pods, Deployments → ReplicaSets)
• Always set resource requests/limits — scheduling and stability depend on them
• EKS = managed K8s on AWS. eksctl is the easiest way to create clusters
• HPA scales pods horizontally based on metrics (like ASG for containers)
• ALB Controller bridges K8s Ingress with AWS ALBs
• Always clean up EKS clusters — they're not cheap!