What is the difference between a Docker image and a Docker container?

A Docker image is a read-only template — a snapshot of a filesystem and runtime configuration built from a Dockerfile. It exists on disk as a set of immutable layers. A container is a running instance of an image — it is the image plus a writable layer on top and a running process. You can run multiple containers from the same image simultaneously, each isolated. Images are built with docker build and pushed to a registry. Containers are started with docker run and are ephemeral — when a container is removed, any changes written to its writable layer are lost unless you used a volume.

Why should I use a non-root user in my Dockerfile?

By default, processes inside containers run as root (UID 0). If your application has a vulnerability that allows code execution, an attacker running as root inside the container has far more capabilities — reading any file, installing software, and potentially escaping the container if the kernel has a vulnerability. A non-root user limits what the attacker can do. Best practice: create a system user in the Dockerfile (RUN adduser --system appuser), set ownership of app files to that user (COPY --chown=appuser:appgroup), and switch to it (USER appuser) before the CMD. Most container security scanners will flag images running as root.

What is the difference between Kubernetes Deployment, ReplicaSet, and Pod?

A Pod is the smallest unit — one or more containers sharing network and storage. A ReplicaSet ensures a specified number of identical Pods are running at all times. A Deployment manages ReplicaSets and provides declarative updates — when you change the image or config, the Deployment creates a new ReplicaSet with the new configuration and gradually scales it up while scaling down the old one (rolling update). In practice, you almost always manage Deployments directly and let them manage ReplicaSets automatically. You would only create a standalone ReplicaSet if you need fine-grained control over rolling updates, which is uncommon.

When should I use ClusterIP vs NodePort vs LoadBalancer for a Kubernetes Service?

ClusterIP (the default) creates a Service only accessible within the cluster. Use it for internal service-to-service communication — your app connecting to its database, or your API service connecting to a cache. NodePort opens a port on every node in the cluster and routes traffic to the Service — accessible externally but with an awkward high-numbered port (30000-32767). Rarely used in production. LoadBalancer provisions a cloud load balancer (AWS ALB, GCP Load Balancer, etc.) with a public IP. Use it when you need to expose a single Service directly to the internet. In most production Kubernetes setups, internal Services use ClusterIP and a single Ingress controller (like nginx-ingress) handles all external HTTP/HTTPS routing to multiple services.

How do liveness and readiness probes differ in Kubernetes?

A readiness probe determines if a Pod is ready to receive traffic. Until the readiness probe passes, Kubernetes removes the Pod from the Service load balancer endpoints — traffic is not sent to it. This prevents requests from hitting a Pod that is still starting up, running migrations, or in a degraded state. A liveness probe determines if the Pod is still alive and functioning. If a liveness probe fails, Kubernetes kills and restarts the Pod. Use readiness probes to control traffic admission (slow startup, dependency checks). Use liveness probes to auto-recover from deadlocks or hung processes. A Pod can be alive (liveness passes) but not ready (readiness fails) during graceful startup or temporary overload.

Engineering·10 min read·June 21, 2026

🐳 Docker & Kubernetes Fundamentals for Software Engineers

A complete guide to Docker and Kubernetes for software engineers: Dockerfile best practices, multi-stage builds, docker-compose for local development, and Kubernetes concepts including pods, deployments, services, and ingress — with real kubectl commands.

📖Full-Stack SaaS with Next.js, Supabase & Groq AI (Full Access)

View →

Why Every Software Engineer Needs to Understand Containers

Containers have become the standard unit of deployment across cloud platforms. Whether you are pushing to Kubernetes on AWS, GCP, or Azure, deploying a Vercel/Fly.io/Railway app, or working on a microservices architecture, understanding Docker and Kubernetes is no longer optional infrastructure knowledge — it is core engineering knowledge. This guide covers the practical fundamentals that get you to productive quickly.

Topics covered

Docker tutorial developersKubernetes fundamentalsDockerfile best practicesDocker multi-stage builddocker-compose local developmentKubernetes pods deploymentskubectl commands guideKubernetes service typesKubernetes ingress nginxDocker non-root user securityDocker layer cachingKubernetes resource limitsKubernetes ConfigMap secretsDocker .dockerignoreKubernetes rolling updateDocker container securityKubernetes namespacecontainer orchestration guide