Topic overview
Docker: the image-vs-container distinction, Dockerfile layers and build caching, multi-stage builds, volumes vs. bind mounts, and container networking.
Kubernetes: pods, deployments (replica sets, rolling updates), services for stable networking, horizontal pod autoscaling, and config maps/secrets.
Core concepts
An image is a read-only, layered filesystem snapshot; a container is a running instance of it with its own writable layer. Dockerfile instructions cache in order, so ordering least-to-most-frequently-changed keeps rebuilds fast, and multi-stage builds discard build-time dependencies from the final image.
A pod wraps one or more tightly-coupled containers with a shared network namespace. A deployment declares a desired state — replica count, image version — and Kubernetes reconciles toward it, handling rolling updates and rollbacks. A service gives pods a stable DNS name/IP even as individual pods are replaced.
Why it matters
Containers make an app behave the same in development, CI, and production — that consistency is the prerequisite for orchestration. Pods die and get rescheduled constantly; Kubernetes' job is to make that churn invisible to everything depending on the service, while scaling under load and rolling out new versions without downtime.
Interview relevance
Expect Docker questions on why layer order affects build speed, volumes vs. bind mounts, and why multi-stage builds shrink images. Expect Kubernetes questions on why you'd use a Deployment instead of creating pods directly, how a Service routes to healthy pods, and how a rolling update avoids downtime versus a recreate strategy.