A 38-minute working session on going from one container on your laptop to a fleet that schedules, scales, and repairs itself — Pods, Deployments, Services, config & storage, autoscaling, and the tooling that ties it together.
You can docker run a single container by hand. But real systems need dozens of copies spread across many servers, restarted when they crash, replaced when a machine dies, and updated without downtime. Doing that by hand is a full-time job. Kubernetes is the robot that does it for you — all day, every day.
Desired vs actual, forever. The gap is what Kubernetes spends its life closing.
Self-healing. A crashed container or dead machine? Replaced automatically.
Scaling. Run 3 copies at night, 30 at peak — by hand or automatically.
Zero-downtime updates. Roll out a new version gradually; roll back if it misbehaves.
Service discovery. Apps find each other by name, even as copies come and go.
Almost everything you run is described by a small set of objects that stack on each other. You'll spend 90% of your time with three: the Pod (what runs), the ReplicaSet (how many), and the Deployment (how it changes over time).
Containers in a pod share one IP and can talk over localhost. The pod is the unit of scheduling.
You write the Deployment; it creates a ReplicaSet; the ReplicaSet keeps the pods at the count you asked for.
replicas: 3 is the wish; template is the pod stamped out three times. Apply this and the loop does the rest.
app=api", and a Service later sends traffic to that same label. Nothing is wired by hardcoded IDs — everything is matched by labels.Every pod gets its own IP, but pods are replaced constantly — so that IP is a moving target. You can't hardcode it. A Service gives a stable name and address that always points at the healthy pods behind it, no matter how often they churn.
http://api (the service name) and never worry about which pod or which node answers. The Service spreads requests across whichever pods are currently healthy.The Service selects pods by label and balances across the healthy ones — pods can be replaced without callers noticing.
Same app: api label as the Deployment — that is the only wiring needed.
The default. A virtual IP reachable only within the cluster. Perfect for one app calling another (frontend → api → db).
Opens the same high port on every node's IP. Simple, but raw and rarely used directly in production — mostly a building block.
Asks your cloud for an external load balancer with a public IP. The usual way to expose a single TCP service to the internet.
shop.acme.com → web, shop.acme.com/api → api. It also terminates TLS (HTTPS) in one place.One entry point, many backends. Path and host rules decide which Service each request reaches.
A container image should be the same in every environment — only its settings change. Kubernetes splits that out: ConfigMaps and Secrets hold settings; Volumes and PVCs hold data that must outlive any one pod.
Key/value config — log level, feature flags, a service URL — injected into a pod as environment variables or mounted as files. Change config without rebuilding the image.
The same idea for passwords, tokens, and TLS keys. Stored base64-encoded and kept separate so access can be restricted and they can be encrypted at rest. Base64 is notencryption — treat the cluster's secret store with care.
The same image reads its settings from env vars or files — supplied fresh per environment.
Config is pulled in by reference — never baked into the image or committed in plaintext.
The pod claims storage by size/type; the cluster binds the claim to a real disk and re-attaches it if the pod moves.
StatefulSet + PVCs.This is where the control loop earns its keep. Probes tell Kubernetes whether a pod is healthy, the autoscaler adjusts the replica count to match load, and rolling updates swap versions a few pods at a time.
A periodic check (HTTP, TCP, or command). If it fails repeatedly, Kubernetes restarts the container — the cure for a hung or deadlocked process.
Checks if a pod can serve right now. While it fails, the pod is pulled out of the Service — no requests sent — but not restarted. Great for warm-up and temporary overload.
Guards slow-starting apps: holds off the liveness check until the app has finished starting, so a slow boot isn't mistaken for a crash.
requests tell the scheduler how much room to reserve; limits cap how much a pod may use. Both are also what the autoscaler measures against.
New pods come up and pass readiness before old ones are retired — so capacity never drops and a bad version can be rolled back.
kubectl rollout undo snaps back to the previous ReplicaSet if the new version misbehaves.You rarely click buttons. You apply YAML with a CLI, template it so it isn't copy-pasted everywhere, and increasingly let Git be the source of truth. And the cluster itself usually comes from a managed provider. Here are the leading tools, with the trade-off for each.
The official command-line tool — apply manifests, inspect and debug everything.
Pro: universal, scriptable, works on any cluster.
Con:raw YAML doesn't scale across many environments on its own.
Bundles manifests into reusable, parameterized charts — install Postgres or your app with one command and a values file.
Pro: huge ecosystem of ready-made charts; easy per-env values.
Con: Go-template logic in YAML gets hard to read and debug.
Built into kubectl. Keep a plain base, then patch it per environment with overlays — no templating language.
Pro: pure YAML, no new syntax; clean dev/stage/prod diffs.
Con: no packaging/sharing story like Helm charts.
How to choose: start with kubectl + Kustomize — zero new languages and it covers most teams. Reach for Helm when you need to package and share an app, or to install third-party software. Many teams use both: Helm for vendored dependencies, Kustomize for their own apps.
Running the control plane (the brains) yourself is hard and rarely worth it. Managed services run it for you; you just bring your workloads.
Pro: deepest AWS integration and reach.
Con: the most assembly required to set up.
Pro: widely seen as the most polished; strong autopilot mode.
Con: ties you to Google Cloud.
Pro: natural fit for Azure / enterprise shops.
Con: tightest in the Azure ecosystem.
Pro: full control; runs on-prem or anywhere.
Con: you own upgrades, security, and 3am pages.
How to choose:use the managed service of whatever cloud you're already on — that's the right answer for the vast majority. Self-manage only for on-prem, strict compliance, or special hardware needs. For learning, a local cluster (kind, k3d, or minikube) is free and instant.
kubectl apply by hand; instead you merge a pull request and the agent syncs it.A controller with a rich dashboard that shows sync status and diffs between Git and the live cluster.
Pro: excellent visibility; easy to adopt.
Con: another sizeable system to run and secure.
A set of small controllers, Git-native and CLI-first, that compose well with Helm and Kustomize.
Pro: minimal, modular, integrates cleanly.
Con: less of a built-in UI than Argo CD.
How to choose: want a dashboard and a gentle on-ramp? Argo CD. Want a minimal, composable, CLI-first setup? Flux. Either way the win is the same: Git becomes your audit log and your rollback button.
apply to live, in five commands.Everything so far comes together in one short workflow: declare it, apply it, expose it, scale it, watch it heal.
Notice every step describes what you want. The control loop from section 1 makes it real and keeps it real.
Five quick questions on the control loop, the core objects, networking, config, and scaling — instant feedback, no sign-in.
Navigate with ← → or scroll · Part 2: Advanced Kubernetes → · back to library