Skip to main content

Chapter 4 checkpoint

You can now reason about running containers at scale. Recall the chapter, then prove it.

The throughline​

  • Orchestration automates scheduling, self-healing, scaling, networking, and updates across many containers and machines; Kubernetes is the open, portable standard (EKS/GKE/AKS run it identically). It's complex — use it only when you have the scale problem; otherwise it's overkill.
  • An image is a static blueprint; a container is a running instance of one. Build images from a Dockerfile (cached layers), push to a registry, pull to run. Immutable, versioned tags (not latest) make deploys reliable and rollbacks instant.
  • A pod ≈ one running app instance (disposable). A deployment declares image + replica count and reconciles to give self-healing, scaling, and rolling updates/rollbacks. A service is a stable name + load balancer over shifting pods. An ingress routes outside HTTP to services.
  • ConfigMaps (settings) and Secrets (sensitive) inject config so one immutable image runs everywhere. Kubernetes Secrets are base64-encoded, not encrypted — add encryption at rest, RBAC, or an external manager.
  • The control plane (API server, etcd, scheduler, controllers) + worker nodes (kubelet) run one reconciliation loop: desired vs actual, act to close the gap. Same loop as Terraform and GitOps.

Quiz​

Required checkpoint

Chapter 4 — Containers & Kubernetes

Pass to unlock the Next button below

That completes the foundation of this guide: you can explain the cloud, choose its primitives, provision them as code, and run containers at scale. From here, the guide moves into delivering and operating what you've built.

Next: Chapter 5: CI/CD & GitOps →