Beginner to Advanced

Kubernetes from Zero to Production on Amazon EKS

A path from never having used Kubernetes to running Amazon EKS in production. Start with the basics on a free local cluster, learn the core concepts, move to EKS and build the platform, then work through the real challenges of operating it.

Level: Beginner to Advanced Duration: 20 Modules · 217 min read Updated:
Overview

Learn the basics, then the concepts, then how to run it

Most EKS guides start with a cluster already running and jump straight to production tricks. This track starts at the very beginning, and assumes no Kubernetes experience at all. It explains why Kubernetes exists and gets you running it on your own laptop for free. Then it teaches the core concepts one at a time, moves to Amazon EKS to build a real platform, and finishes with the challenges that only show up once you're operating it. Each module builds on the ones before it, with diagrams wherever it helps to see how requests, permissions, and deploys move through the system.

Every module is built to be worked through, not just read. Each one opens with what you'll learn, includes hands-on Try it commands, recaps the key terms, and ends with a five-question pop quiz: three questions on the ideas and two real-world scenarios, shuffled into a new order every time. Score 4 out of 5 to pass.

Where to start.
  • New to Kubernetes, or to containers? Start at Module 01 and read in order. Parts 1 and 2 run on a free cluster on your laptop.
  • Know Kubernetes, new to Amazon EKS? Skim Part 2, then start at Module 10.
  • Already run EKS? Go straight to Part 4, Operating in production, or to whichever challenge you're facing.

Parts 1 and 2 need nothing but a laptop. Parts 3 and 4 draw on running Amazon EKS across four separate environments (Development, QA, Staging, Production) for a single platform, with every name and account removed. Where a module links to a case study, that's the real engagement the pattern came from.

Part 1

Basics

No experience needed. Get Kubernetes running on your own laptop for free, and learn to read and write the files that describe everything in a cluster.

Part 2

Core concepts

How Kubernetes works, on any cluster. Everything later relies on these, so read them in order.

Part 3

Kubernetes on Amazon EKS

Moving to EKS, then turning an empty cluster into a platform that's safe to deploy to. Read these in order if you're setting one up.

Part 4

Operating in production

The challenges that only show up once real users depend on the platform: delivery, capacity, monitoring, incidents, and upgrades. Read in order, or go straight to what you need.

Big picture

The whole platform, as three flows

This is the map, and it makes the most sense once you've finished Part 2. Here's the whole system end to end, as three flows. Press Play step by step on any of them to follow it hop by hop. Every box names the module that explains it, so if something breaks at one hop, that's the module to open.

Flow 1 · A user's request, from the browser to your code

Flow 1 · A request from the internet to a pod, and out to AWS
Internet
Useropens https://api.example.com/orders in a browser or app
Route 53 resolves the name; ExternalDNS keeps the record in sync (Module 12)
Your VPC
Application Load BalancerTLS ends here; shared across APIs by an ingress group (Module 14)
Ingress rule /orders matches; target type ip sends it straight to a pod IP (Modules 06, 10)
EKS cluster
Service orders-apilists only the ready pods; the ALB targets come from it (Module 06)
readiness probe passed, so this pod is in rotation (Module 05)
orders-api podyour container, with its own VPC IP from the VPC CNI (Modules 04, 10)
calls another service by its DNS name, orders to payments (Module 06)
payments-api podreached through its ClusterIP Service and kube-proxy rules
needs AWS: credentials come from EKS Pod Identity (Module 13)
Amazon S3, SQS, Secrets ManagerIAM allows only what this workload's role permits (Module 13)

Flow 2 · A code change, from a commit to running in Production

Flow 2 · Shipping a change safely through every environment
Developermerges a pull request to the application repo
CI builds and tests the image once (Module 15)
Amazon ECRimage stored once, identified by its digest (Module 15)
a pull request to the manifests repo changes the digest for one environment (Module 16)
Manifests reporeviewed and merged; for Production this is the approval step (Module 16)
Argo CD inside the cluster notices the change (Module 16)
EKS cluster (one per environment, Module 11)
Argo CDapplies the change, allowed by its RBAC permissions (Modules 08, 11)
API server stores the new Deployment; the scheduler places the new pods (Module 04)
Rolling updatenew pods start, pass readiness, then old ones are removed (Module 05)
if new pods need room, Karpenter adds a node (Module 17)
New version livesame image digest that was tested in QA
to roll back, revert the commit in Git; Argo CD syncs the cluster back (Module 16)

Flow 3 · Keeping it running, from a warning sign to a fix

Flow 3 · From an early warning to a resolved incident
EKS cluster
Pods and nodesemit logs, metrics, and events all the time
Fluent Bit and a metrics agent ship them out of the cluster (Modules 12, 18)
Logs and metricsCloudWatch or Managed Prometheus, with Grafana dashboards (Module 18)
an alert rule on a user-facing symptom fires: errors, latency, or missing pods (Module 18)
On-call engineerfollows the runbook linked from the alert
checks context, events, and pod status, one layer at a time (Module 19)
Capacity
Pods Pending or CPU-boundtune requests and autoscaling (Module 17)
Bad release
Rollout failingroll back through Git or kubectl (Modules 16, 19)
Platform
Old version or add-onupgrade one minor version at a time (Module 20)
fixed, and the cause written down
Service healthythe alert clears and the next on-call person has the notes

Questions about this learning path?

I'm happy to go into more detail on any of this: how the pieces fit together, ingress costs, RBAC design, or how I triage incidents.

anupojuprudhvi@gmail.com