Backend Deep-Dive · Beginner Friendly
If the words Kubernetes and EKS have always felt like a wall of jargon, this is the guide that finally makes them click. We start from absolute zero — what a container even is — and build up, one idea at a time, until you can follow a single user request all the way through a real Amazon EKS cluster and back. Plain English, simple analogies, and a clear mental model instead of a pile of commands.
Prefer to read? Everything in the video is written out below. Skim the table of contents and jump to whatever you need.
- Containers pack your app and its environment together so it runs the same everywhere.
- Kubernetes is a manager that runs, heals, scales, and connects hundreds of containers for you.
- Every cluster has a Control Plane (the brain) and Worker Nodes (the muscle).
- You describe the desired state; Kubernetes works nonstop to match it.
- Amazon EKS runs the Control Plane for you — real, managed Kubernetes on AWS.
- You still own the nodes and apps; AWS owns the hard, boring, high-stakes brain.
- Part 1: Kubernetes foundations
- The "works on my machine" problem
- What is a container?
- Why you need an orchestrator
- What is Kubernetes?
- Control plane vs worker nodes
- Pods, Deployments & Services
- The reconciliation loop
- Part 2: Amazon EKS
- What is EKS?
- AWS vs You
- Node Groups, Fargate, Auto Mode
- Networking, load balancing & security
- A request, end-to-end
- Pricing & when to use EKS
- FAQ & glossary
Part 1 — Kubernetes, from the ground up
The problem: "but it works on my machine!"
Every developer has lived this. On your laptop the app runs perfectly — right language version, right database, right settings. You ship it to a production server and it crashes: older runtime, a different database version, missing dependencies, different config.
The root cause is simple. Your app and everything it depends on live in different places on every machine. Move the app, and its environment doesn't come with it. You're shipping a fish without the water.
The fix: containers
A software container is the same idea: a standardized box holding your app plus its exact environment — code, runtime, libraries, and config, all sealed together. Because the app and its world travel as one unit, it runs identically on your laptop, in test, and in production. "Works on my machine" becomes "works on every machine."
The new problem: hundreds of containers
Containers solve packaging — and immediately create a new problem. Real systems run dozens or hundreds of containers across many servers. Now, by hand, someone has to answer:
- A container crashed at 3 AM — who restarts it?
- Traffic spiked 10× — who adds more copies, fast?
- A server died — who moves its containers somewhere healthy?
- A new version ships — who updates everything with zero downtime?
- How do all these containers even find and talk to each other?
Doing this manually is impossible. You need something to manage the containers for you.
What is Kubernetes?
Kubernetes (often shortened to k8s) is that conductor for your containers. You tell it what you want, and it makes it happen — and keeps it that way. Automatically, it will:
The design: brain + muscle
Every cluster splits into two halves.
The brain sends instructions to the muscle: run this here, restart that, add two more copies there. Keep this split in your head — it's the key to understanding EKS later.
Inside the Control Plane
- API Server — the front door. Everything talks to the cluster only through here.
- etcd — the cluster's memory. A database storing the desired and current state of everything.
- Scheduler — the matchmaker. Decides which node each new pod runs on.
- Controllers — the watchdogs. Constantly compare "what you asked for" vs "what exists," and fix gaps.
Inside a Worker Node
- kubelet — the on-site foreman that runs the pods the brain assigns.
- kube-proxy — the switchboard that routes traffic to the right pod.
- container runtime — the engine (e.g. containerd) that starts and stops containers.
The building blocks you'll use every day
Pod. The smallest unit Kubernetes runs. It wraps your container (Kubernetes never runs a bare container). Usually one pod = one container = one running copy of your app. Pods are disposable by design — cattle, not pets — created and destroyed constantly.
Deployment. You don't create pods by hand. You declare a wish — "I want 3 copies running" — and the Deployment keeps exactly that many alive. If one dies, a replacement appears within seconds. That's self-healing, on by default, no human paged.
Service. Because pods die and each new pod gets a new IP, you can't rely on a pod's address. A Service is a single, stable front door with a fixed name; it load-balances traffic across whichever pods are currently alive.
A few more words you'll hear constantly:
| Object | What it's for |
|---|---|
| Namespace | Folders for your cluster — keep dev, staging, and prod separate. |
| ConfigMap | Non-secret settings kept outside your image (URLs, flags, tuning). |
| Secret | Same idea, for sensitive values (passwords, API keys, tokens). |
| Ingress | The smart doorway letting outside internet traffic reach the right Service. |
The one idea that explains all of Kubernetes
Part 2 — Amazon EKS (the main event)
The catch: who runs the Control Plane?
That "brain" doesn't run itself. If you run plain Kubernetes yourself, you must set up and secure etcd, make the control plane highly available across data centres, patch and upgrade it constantly, back it up, test restores, and monitor it 24/7 — for every environment. It's heavy, boring, high-stakes work, and none of it is your actual product.
What is Amazon EKS?
Amazon EKS (Elastic Kubernetes Service) is managed Kubernetes. AWS runs the entire Control Plane for you — set up, highly available, patched, monitored, backed up. You just get a healthy, ready-to-use Kubernetes. Crucially:
- It's real, unmodified Kubernetes — your skills and YAML transfer anywhere.
- No control-plane babysitting — no etcd, no brain upgrades, no 3 AM pages for it.
- It's AWS-native — plugs straight into AWS networking, security, storage, and scaling.
The most important idea: AWS vs You
The number-one source of EKS confusion is who's responsible for what. Here's the clean split:
| AWS manages (the brain) | You manage (the muscle + apps) |
|---|---|
| API Server & etcd | Worker nodes (or let AWS run them) |
| High availability across 3 AZs | Your pods, images & deployments |
| Version patching & upgrades | How much to scale |
| Backups & recovery | App-level networking rules |
| 24/7 health monitoring | Access & permissions |
What an EKS cluster looks like
Up top: an AWS-managed Control Plane, replicated across three Availability Zones so no single data-centre failure can take it down — and you never touch it. Below: your VPC, your own private network, holding your worker nodes and pods. The managed control plane drives your nodes; AWS quietly runs the entire top half for you.
Where your containers run: three compute options
| Managed Node Groups | Fargate | EKS Auto Mode | |
|---|---|---|---|
| You manage nodes? | Some — pick type & size | None | None |
| Who scales them? | You configure it | AWS, per pod | AWS, automatically |
| Control level | Highest | Lowest | Low, but flexible |
| Best for | Steady, custom fleets | Spiky / simple apps | "Just run it for me" |
Networking, load balancing & security
Networking (VPC CNI). On EKS, a plugin called the VPC CNI gives every pod a real IP from your VPC. Each pod becomes a first-class citizen on your AWS network and can talk to RDS, S3, and other services naturally.
Load balancing. The AWS Load Balancer Controller watches your cluster and automatically creates a real AWS load balancer (ALB/NLB) the moment you expose an app. You declare intent; the infrastructure appears — you never wire up load balancers by hand.
Security. Pods often need to reach AWS services. The wrong way is pasting AWS keys into the app — if it leaks, attackers get everything. The EKS way stores no keys at all: each pod is mapped to an IAM Role and handed temporary, least-privilege, auto-rotated credentials. The features that do this are IRSA and EKS Pod Identity.
Storage & scaling. CSI drivers let a pod claim real AWS storage — EBS (fast personal disk) or EFS (shared files) — so data survives a pod restart. And scaling happens on two layers: the HPA adds pod copies when traffic rises, while Karpenter adds servers so those pods have somewhere to run (and both scale back down to save money).
Putting it together: one user request, end-to-end
- A user opens your app.
- Route 53 (DNS) resolves the address of your system.
- The request hits your ALB (load balancer).
- The ALB hands it to your Service, which picks a healthy pod.
- Your code runs inside a Pod. If it needs data, it uses its Pod Identity to reach RDS or S3 over the VPC.
The response travels the same path back to the user. Every layer we covered — nodes, pods, services, load balancers, networking, identity — working together to answer one click.
What EKS costs (and one gotcha)
Pricing is two parts:
- Control-plane fee: a flat $0.10 per hour, per cluster (≈ $73/month) — the same whether you run 1 pod or 1,000.
- Compute you use: the nodes (EC2 / Fargate / Auto Mode) running your pods, plus storage and data transfer. This is usually the bigger part of the bill.
Should you even use EKS?
- Your team already knows Kubernetes
- You want to stay portable / multi-cloud
- You run many services or many teams
- You rely on the K8s tooling ecosystem
- You're operating at real scale
- You have one small, simple app
- Nobody on the team knows Kubernetes
- You want the least ops overhead possible
- You don't need K8s-specific tooling
- A simpler AWS option (like ECS) would do
EKS is a powerful default for Kubernetes teams — not an automatic yes for every app. Choosing the right tool is the senior move.
Frequently asked questions
Is Amazon EKS the same as Kubernetes?
EKS is Kubernetes — the standard, unmodified project — with AWS running and managing the control plane for you. Your Kubernetes knowledge and YAML manifests work the same on EKS as anywhere else.
Do I need to learn Docker before Kubernetes?
A basic grasp of containers helps a lot, since Kubernetes runs containers. You don't need to be a Docker expert, but understanding what a container is — an app packaged with its environment — makes everything here click faster.
What's the difference between EKS and ECS?
Both run containers on AWS. ECS is AWS's own simpler orchestrator — less to learn, AWS-only. EKS is full Kubernetes — more power and portability, more concepts. If your team knows Kubernetes or values portability, EKS; if you want the simplest path on AWS, ECS is often enough.
What does EKS cost?
A flat $0.10 per hour per cluster for the managed control plane (about $73/month), plus the compute, storage, and data transfer your workloads use. Watch out for the 6× fee increase if your cluster falls into extended support on an old Kubernetes version.
Fargate vs Managed Node Groups vs Auto Mode — which should I pick?
For simplicity, start with EKS Auto Mode or Fargate and let AWS manage the servers. Move to Managed Node Groups when you need precise control over instance types, sizing, or scaling behaviour.
Is Kubernetes hard to learn?
The vocabulary is intimidating at first, but the core is one idea: you declare a desired state and Kubernetes continuously reconciles reality to match it. Once that clicks, Pods, Deployments, Services, and the rest fall into place.
How does a pod talk to AWS services securely on EKS?
Through IAM roles, not stored keys. Using IRSA or EKS Pod Identity, each pod is granted temporary, least-privilege, auto-rotated credentials scoped to exactly what it needs — so there's no long-lived secret to leak.
Quick glossary
Enjoyed the breakdown?
The next video goes hands-on and spins up a real EKS cluster, step by step. Subscribe so you don't miss it — and tell me in the comments which part to go deeper on: networking, security, or scaling.
▶ Subscribe on YouTubeKubernetesEKSAWSDevOpsContainersCloud NativeK8s
Written by Prashant Sharma · Backend & cloud tutorials at prashantsharmaofficial.com · Course: Udemy · 1:1: Topmate
.png)
.png)
Comments
Post a Comment