Containers

Packaging an application with its dependencies, and orchestrating the result across machines.

Containers package an application together with its runtime and libraries so it runs the same way on a laptop, a CI runner and a production cluster. Docker builds and runs individual containers; Kubernetes schedules and manages many of them across a fleet of machines.

‹ Tools

1. Overview

A container image is a stack of read-only filesystem layers plus metadata (entrypoint, environment, exposed ports). A container is a running instance of that image, isolated with Linux namespaces and limited with cgroups. It shares the host kernel, which is why containers start in well under a second and use far less memory than virtual machines.

Docker is enough when you run one or a few containers on a single host, for local development, CI jobs, or a small service managed with Docker Compose. Once you need scheduling across many machines, self-healing, rolling updates, service discovery, autoscaling and declarative configuration, you move to an orchestrator; Kubernetes is the standard choice, available as managed services such as EKS, GKE and AKS.

2. Docker vs Kubernetes

Start with Key Points about Docker for images, layers and the build/run workflow, then Kubernetes Overview for the control plane, worker nodes and pods. Container images are the usual output of a CI/CD pipeline.

3. Common Pitfalls

• Large images built on full OS bases; use slim or distroless bases and multi-stage builds.
• Tagging everything latest, which makes deployments non-reproducible; tag with a version or commit SHA.
• Running as root inside the container, and missing resource requests and limits in Kubernetes.