Translate Docker mental models into Kubernetes — pods, workloads, services, and the day-one kubectl flow without drowning in platform jargon.
Docker taught you to package an app and its dependencies into an image and run it anywhere. Kubernetes (often written k8s) answers the next questions: how do you run many of those containers across machines, restart them when they fail, roll out new versions safely, and expose them on the network?
If that sounds like a different vocabulary for problems you already half-solve with compose files and shell scripts, you are in the right place.
What Kubernetes adds on top of Docker
A container image still describes what runs. Kubernetes adds:
- Scheduling — which node should run which workload, respecting CPU, memory, and affinity rules.
- Declarative desired state — you describe the end state; controllers work to match it.
- Service discovery and load balancing — stable DNS names and cluster IPs in front of ephemeral pods.
- Rolling updates and rollbacks — change versions without a manual failover playbook for every app.
You still build and push images to a registry; Kubernetes pulls those images according to your pod specs.
Core objects to learn first
You can defer most of the platform surface area. Start with four building blocks:
Pods
A pod is the smallest deployable unit. Usually one container per pod for application code, sometimes with sidecars (logging, mesh proxies). Pods are ephemeral — never treat a pod name or filesystem as durable.
Workload controllers
Something has to recreate pods when nodes disappear. Common controllers:
- Deployment — stateless apps with replica count and rolling updates.
- StatefulSet — ordered identity and stable storage for databases or clustered systems that need persistent disk per replica.
- Job and CronJob — run-to-completion and scheduled work.
For learning, Deployments are the right default.
Services
A Service gives a stable cluster IP and DNS name (for example my-app.default.svc.cluster.local) that targets matching pods via labels. This decouples consumers from pod IP churn.
Namespaces
Namespaces partition objects inside a cluster. Teams often separate production, staging, and per-team sandboxes. Resource quotas and RBAC attach at namespace boundaries.
The kubectl loop you will actually use
These commands cover most day-one debugging:
kubectl get pods— what is running, and are pods healthy?kubectl describe pod <name>— events often explain image pull failures, crash loops, or quota issues.kubectl logs <pod>— application stdout/stderr; add-fto stream.kubectl exec -it <pod> -- /bin/sh— shell into a running container when logs are not enough.
If something worked in Docker locally but fails in Kubernetes, compare environment variables, mounted files, port bindings, and memory limits — the container is similar; the platform is stricter about resources and restarts.
Configuration: ConfigMaps and Secrets
Move configuration out of images. ConfigMaps hold non-secret data (feature flags, URLs). Secrets store sensitive values base64-encoded at rest — they are not encryption by themselves, so integrate with your cluster’s secret store or external KMS for production.
Mount them as files or inject them as environment variables depending on what the application already expects.
Health checks matter more than on a single VM
Define liveness and readiness probes:
- Readiness — “should this pod receive traffic yet?” During startup or dependency outages, fail readiness so traffic routes elsewhere.
- Liveness — “is this pod stuck in a bad state?” Kubernetes may restart it.
Without probes, a half-started process might sit behind a Service and serve errors.
Networking in one paragraph
Each pod gets an IP on a cluster-wide overlay network. Services provide stable access. Ingress (often with an ingress controller) terminates HTTP/TLS and routes hostnames and paths to Services. For local learning, minikube or kind installs a minimal ingress setup you can experiment with.
FAQ
Do I need Helm?
Not to learn. Helm packages complex YAML; use it when you are repeating the same chart across environments.
How does this relate to Docker Compose?
Compose coordinates containers on one host with a single file. Kubernetes coordinates containers across many nodes with richer operations primitives.
What about serverless?
Managed platforms can hide Kubernetes entirely. Understanding pods and deployments still helps when you debug cold starts, VPC networking, and quotas — many platforms are Kubernetes under the hood.
Start with one Deployment, one Service, and probes. Once those feel boring, add Ingress, autoscaling, and resource requests — each solves a problem you will recognize from running Docker in production.
Comments
Loading comments…