Docker & Kubernetes Foundations Course

A Docker image is a read-only template containing an application, its runtime, libraries, and configuration. Images are built from Dockerfiles using layers: every instruction such as FROM, COPY, RUN, or ENV creates a layer, and unchanged layers are cached to make rebuilds faster. Smaller, more secure images prefer minimal base images, combine related RUN commands, and copy only files the application needs.

The FROM instruction selects the base image. COPY moves files from the build context into the image, while RUN executes commands during the build. CMD provides the default command and arguments used when the container starts, and ENTRYPOINT defines the executable that always runs. When both are present, the entrypoint receives command-line arguments as its parameters. A health check or non-root user can be added with HEALTHCHECK and USER.

Use docker build -t myapp:latest . to build an image and docker image ls to list images. Tag images with meaningful version numbers and avoid using only latest in production. The goal is an image that is deterministic, small, and reproducible from the Dockerfile alone.

Image drill: use a small base image, combine RUN commands, copy only needed files, and run as a non-root user. Order layers so cacheable steps come first, and scan images for vulnerabilities.

A container is a running instance of an image. Docker creates, starts, stops, restarts, and removes containers with commands such as docker create, docker start, docker stop, and docker rm. The common shortcut docker run creates and starts a container in one step. Use docker ps for running containers, docker ps -a to include stopped containers, and docker logs to inspect application output.

Container filesystems are ephemeral: when a container is removed, changes written inside it disappear. Volumes and bind mounts solve this. A named volume is managed by Docker and survives container removal; a bind mount maps a host directory into the container. The -v and --mount flags attach storage, and containers can share the same volume. Read-only mounts prevent accidental modification.

For debugging, docker exec -it container bash opens a shell inside a running container, and docker inspect shows configuration and state details. Attach --restart policies only when the application should recover automatically, and keep logs and data outside the container when the container itself is replaceable.

Container drill: know create, start, stop, restart, rm, and run. For persistence, use volumes or bind mounts so data survives container removal; avoid storing state in the writable container layer.

Docker networks let containers communicate by name or IP. The default bridge network provides automatic DNS between containers on the same network, while the host network shares the host network stack and removes isolation. User-defined bridge networks are recommended because they support DNS resolution and can be attached or detached without recreating containers. Publish a container port to the host with -p 8080:80; the left side is the host port and the right side is the container port.

Docker Compose defines multi-container applications in a YAML file. Services declare images, build contexts, ports, volumes, environment variables, and networks. Running docker compose up -d creates the network and starts services together; docker compose down removes containers and the default network while preserving named volumes. Compose also supports dependencies, health checks, and scaling service replicas.

Debug connectivity with docker network ls, docker network inspect, and docker exec. A common failure is a web container that cannot reach a database because they are on different networks or because the application uses localhost instead of the service name. Use service names in Compose so the built-in DNS resolves to the correct container.

Network drill: use custom bridge networks for DNS-based communication, host mode only when isolation is acceptable, and Compose to define multi-container apps. Name services so containers resolve each other by name.

Kubernetes runs containerized applications on a cluster of nodes. The smallest deployable unit is a Pod, which wraps one or more containers with shared storage, network, and lifecycle. Pods are usually created by controllers. A Deployment manages stateless replicas with rolling updates and rollbacks; a StatefulSet gives stable network identities and ordered scaling for stateful applications; a DaemonSet runs exactly one Pod on every selected node; a Job runs a workload to completion; and a CronJob runs Jobs on a schedule.

Configuration is separated from code with ConfigMaps and Secrets. A ConfigMap holds non-sensitive data such as environment variables or config files, while a Secret stores sensitive values such as passwords and API tokens. Both can be mounted as volumes or injected as environment variables. Secrets are base64-encoded in the API but should still be protected with RBAC and encryption at rest.

Controllers reconcile desired state: you declare the desired number of replicas, and Kubernetes creates or removes Pods until reality matches. Labels and selectors connect controllers to Pods, so use meaningful labels such as app and tier. Apply manifests with kubectl apply -f and inspect workload status with kubectl get pods, kubectl describe deployment, and kubectl rollout status.

Workload drill: use Deployment for stateless replicas, StatefulSet for stable identity and storage, DaemonSet for per-node agents, and Job/CronJob for batch work. Define resource requests and limits for predictable scheduling.

A Service provides a stable network endpoint for a set of Pods. ClusterIP exposes the Service inside the cluster, NodePort opens a port on every node, and LoadBalancer integrates with the cloud provider for external traffic. An Ingress routes HTTP and HTTPS traffic to Services using hostnames and paths, typically through an ingress controller. Selectors in the Service must match Pod labels, and the Service targetPort must match the container port.

Persistent storage uses PersistentVolumeClaim (PVC) to request storage, PersistentVolume (PV) to provide it, and StorageClass to define provisioning behavior. A PVC bound to a PV can be mounted into a Pod; ReclaimPolicy controls whether the volume is retained or deleted when the PVC is released. Stateful workloads such as databases should use stable storage and understand how volume claims map to Pods.

Troubleshooting follows a structured order: kubectl get pods to see status, kubectl describe pod for events and conditions, kubectl logs for application output, and kubectl exec for interactive inspection. Check image pull errors, CrashLoopBackOff causes, readiness probes, Service selectors, and network policies. A review workflow of building images, testing locally, deploying small changes, and rolling back quickly turns Kubernetes practice into a repeatable skill.

Service drill: ClusterIP for internal, NodePort for node-level access, LoadBalancer for cloud external access, and Ingress for host/path routing. Use PersistentVolumeClaims for storage and kubectl logs/describe to debug.