Docker and Kubernetes

A container is not a virtual machine: no kernel boots and no operating system is installed; a process is started and pointed at a different set of files, and walls put up by the kernel stop it seeing the host's processes or filesystem.[1] Running ps inside a fresh container shows the shell and the ps command and nothing else, while the host sees that shell among all its own processes; each container also gets its own network, reachable from the host only through the ports Docker forwards.[1] The user inside is root, but root only in the context of that container.[1]

The second distinction is between an image and a container. A kata-style book puts it in a sentence: an image is a blueprint and a container is a running instance of it, as an executable is to a running program, so many containers can run from one image at once.[5] Its first exercise shows what happens when hello-world is run: Docker looks for the image locally, pulls it from Docker Hub when it is not there, runs the image's start command, and the container exits when that command does, which is why the list of running containers is empty a moment later.[5]

Why this is worth the trouble is the subject of the developer-facing books. A PHP author compares Docker with Vagrant: both give repeatable environments, but containers start and stop in seconds, building an environment is faster than provisioning a box, and the image shipped to production is identical to the one on the laptop, which encourages playing with software without the fear of installing it locally.[2] A web-development course lists the pains Docker removes: the "works on my machine" failure when a new hire has a different Node or MongoDB version, the size and drift of virtual-machine images, and the impossibility of running MySQL 5 and 8 side by side on one PC; a single, admittedly complicated, command downloads, configures and runs any combination of services.[6] A Go author adds the operational angle: a container is a zero-install way of running software, and the image run locally can be copied to a production server and run unchanged.[7]

The books that go beneath the Docker command line describe the same kernel primitives. One short book builds a container by hand from them, starting from the OCI image and runtime specifications and working through namespaces, control groups, capabilities, pivot_root, user namespaces with UID mapping, and bridge networking with veth pairs and iptables, before relating what it has built to Docker volumes and to Kubernetes networking through CNI plugins.[43] The long Docker guides cover the same ground from above: the runtime stack of runC, containerd and shims, image layers and the union filesystem, and seccomp and rootless mode as security features,[28][52] and Docker Deep Dive opens with container history and the OCI before the engine, images and containers.[24]

Docker is no longer the only front end to those primitives. A short 2019 book introduces podman, buildah, skopeo and runc for people who already know Docker: podman runs containers without a daemon and, in rootless mode, without root, buildah builds images, and each is compared directly with its Docker equivalent.[46] A 2026 secrets-management workbook simply tells its readers that Docker, Podman or nerdctl will do, because the commands are the same.[8]

Every Docker book for developers has the same first chapter, and the PHP one is representative. A Dockerfile begins with FROM, which extends another image the way a class inherits, so the official PHP image does the work of installing Apache and compiling PHP; COPY places the application's files in the image; LABEL adds metadata that docker inspect can read. The build command tags the result, and the run command maps a host port to a container port, detaches, and names the container for the stop, start and rm commands that follow; docker ps lists what is running and, with a flag, what has stopped.[2] The same author uses docker exec to open a shell in a running container, which he says feels like SSH but is nothing like it, and uses it to find where the image expects its php.ini before copying one in and rebuilding.[2]

The shorter introductions take a developer from there to publishing. One of them, deliberately brief, covers running and inspecting containers, volumes, creating and tagging images, passing configuration through environment variables, pushing to a registry, multi-stage builds that keep build tools out of the final image, and a chapter each for .NET Core, Java, Node.js, PHP and Python, with an exercise and a printed solution in most sections;[30] its author's combined Docker-and-Kubernetes edition carries the same first half.[27] The 2025 and 2026 beginner books add what the tooling has gained since: Docker Desktop, multi-architecture images, the build cache, and deploying a finished image straight to a cloud container service.[36][52] A by-example guide written mostly in Python goes from a first Dockerfile through Flask, MySQL and Jenkins containers, resource limits, logs and troubleshooting, and spends a fifth of its length on the Docker SDK for Python.[39]

Compose is where most developers stop typing run commands. The PHP book introduces it as the tool for multi-container applications: a compose file that replaces a run command with a services block, a build path and a ports list, so that anyone who clones the project brings the stack up with one command, and takes it down, with its networks and named volumes, with another.[2] The web-development course builds its environments the same way, a MySQL database, a WordPress site with Compose and a Node.js application with a Dockerfile, with live editing and remote debugging through browser DevTools and VS Code, and keeps CLI, Dockerfile and Compose references as appendices.[6] A network engineer's guide shows what a single Compose host can carry: Nautobot, Vault, Telegraf, Prometheus, Grafana and NGINX as one monitoring stack on one machine.[32]

The problems that follow are the subject of a short, unfinished recipe book for Node.js. Because an image is immutable and a container's changes vanish when it stops, editing code means mounting a host folder over the application's folder, with a left-hand path that must be absolute or Docker treats it as a named volume; debugging means exposing the debugger's port, sending the Node process the signal that starts its debugger, and attaching VS Code with a launch configuration that maps the local and remote roots; and the sheer length of the commands means wrapping them as npm scripts so that the team runs one word.[9] A Go author solves the same length problem with a shell wrapper that runs the official golang image with the current directory mounted and every argument passed through, so that go run on the host executes inside a container with nothing installed, and he runs Redis and MySQL beside it on a user-defined bridge network so the containers find each other by name.[7] His twelve-factor book creates that network, named party, with one command and a subnet, and starts MySQL and a self-hosted Gogs git server on it with a restart policy, which he describes as using Docker as a process manager that brings a service back after a reboot.[10] A microservices book goes a step further and runs its whole build, protobuf code generation included, as Drone CI steps inside a build image derived from the golang image, so that one command reproduces CI on a laptop.[11] Even books about something else use Docker as plumbing: a Graylog guide provisions MongoDB, Elasticsearch and Graylog as three containers from a Vagrantfile and leaves Docker itself to an appendix.[12]

The twelve-factor methodology, written for Heroku-style platforms, maps so naturally onto containers that three of the Docker books use it as a skeleton. One devotes a chapter to each factor with Go microservices in Docker as the running example: one codebase per service, dependencies vendored, configuration from flags and the environment, backing services such as the database treated as attached resources on the shared network, builds separated from runs, stateless processes, port binding, scaling by running more containers, logs as streams, and admin tasks as one-off processes.[10] Another organises its containerising chapter under the same headings and adds an appendix on linting Dockerfiles,[26] and a third ends with a twelve-factor checklist and command cheat sheets.[1] The logging factor turns up again in a book about centralised logging, which argues that in a cloud-native application logs are streams rather than files, the disk is ephemeral, and tailing log files over SSH on thirty servers does not scale.[12]

Before Kubernetes settled the question, Docker's own answer to running containers across hosts was Swarm, and the Docker books of 2017 to 2020 teach it. The twelve-factor book scales a service to a thousand containers on Swarm with rolling updates and health checks,[10] the 2017 developer book deploys to Swarm,[1] and the long general guides still give it a full chapter, with Kubernetes appearing only in a comparison section.[28][24] The most elaborate use is a self-hosting cookbook that designs a highly available Swarm with shared storage on Ceph or GlusterFS, Keepalived, Traefik and forward authentication, and then gives a recipe per application, Plex, GitLab, Home Assistant, NextCloud and dozens more, for hobbyists who want their own services to stay up.[31] A 2021 web-development course gives Swarm and Kubernetes one overview chapter between them.[6]

The administration guide's explanation of why Kubernetes won is also an explanation of what it is. It inherited from Borg the idea that an orchestrator should be a general-purpose control system that expresses what you want rather than how to get it: a Deployment manifest does not say start three pods and restart them if they die, it says I want three replicas of this template running, and a control loop reconciles the cluster's current state with that desired state continuously.[4] The guide's takeaway is that Kubernetes is not a container runtime but a control system that uses containers as its unit of deployment.[4] The DC/OS author, writing before the outcome was known, described what any such system promised: servers provisioned through cloud APIs and registered automatically, workloads placed by resource need rather than by hand, scaling and self-healing without an administrator, and single-process containers that scale individually.[3]

A 2026 book that teaches Kubernetes by writing a Bash script states the same ideas as principles for its tool: infrastructure as code with the script as the single source of truth, immutable deployments in which a rollout restart replaces pods rather than patching them and state lives in the database and volumes, fast feedback, failing loudly, and observability.[13]

The administration guide's first chapter is the fullest account of the machinery in the samples. The control plane has four parts. The API server is the single front door: every kubectl command, controller decision and watch stream passes through it, and it is where authentication, RBAC authorisation, admission control and validation happen before anything is written; it scales horizontally behind a load balancer, serves long-lived watch connections rather than being polled, and since version 1.21 has a priority-and-fairness mechanism that stops noisy tenants starving system traffic.[4] etcd holds every object as a serialised entry and uses Raft consensus across three or five members, so write latency follows the network between them, and its database must be compacted and defragmented or it grows without bound; a snapshot is the primary backup.[4] The scheduler picks up unscheduled pods and places each in two phases, filtering out the nodes that fail hard constraints (resources, taints, affinity) and scoring the rest with weighted plugins, a framework that since 1.16 can be extended for gang scheduling or GPU affinity.[4] The controller manager runs the control loops as one binary, the node, ReplicaSet, Deployment, EndpointSlice and garbage-collection controllers among them, and a cloud controller manager carries the provider-specific logic for load balancers, routes and terminated nodes.[4]

On every node run the kubelet, which watches for pods assigned to it, pulls images and starts containers through the CRI, runs the probes and reports status; kube-proxy, which programs the packet filter so that traffic to a Service's virtual IP reaches its pods, in iptables mode by default, in IPVS mode for clusters with many services, or replaced entirely by eBPF when Cilium is the network plugin; and the container runtime.[4] The guide then traces a kubectl apply through all of it: authentication, authorisation, admission, persistence to etcd, the Deployment controller creating a ReplicaSet, the ReplicaSet controller creating pods, the scheduler binding them, the kubelet pulling and starting, kube-proxy programming the routes, and status flowing back, with a note on what each step looks like when it fails.[4]

What a user of Kubernetes actually writes is a small vocabulary of objects, each a YAML document with an API version, a kind, metadata and a spec describing the desired state, beside which the controllers maintain a status describing the observed one.[4] The syllabus is remarkably stable across the introductory books: Pods, Deployments and ReplicaSets, Services, Ingress, Namespaces, Volumes and persistent volumes, ConfigMaps and Secrets, StatefulSets, RBAC. The yearly-updated The Kubernetes Book pairs theory with hands-on work in nearly every chapter across exactly that list and adds the Gateway API, service discovery and two chapters on threat modelling and security;[23] its course edition adds WebAssembly workloads, native sidecar containers and node-failure troubleshooting.[45] A 2026 book works the same list on local Kind clusters with MetalLB for real load balancers, carries the work to DigitalOcean, EKS and GKE at the end, and finishes each object with recommendations;[29] another takes one resource type per chapter, from pods with init and sidecar containers through Jobs, probes and security context to a custom service account.[42] The hundred-page Quick Start Kubernetes carries one sample application from containerising it through deploying, self-healing, scaling and a rolling update.[25]

The one sampled lab book shows the objects in use. Its ingress chapter installs the nginx ingress controller with Helm and reads the chart's output line by line, deploys three "cheese" web applications as Deployments with resource requests and limits and exposes them as ClusterIP Services, then writes two Ingress objects: name-based routing, one hostname per service on a single address, and path-based routing, one hostname with a path prefix per service and a rewrite-target annotation.[14] Its RBAC chapter explains that permissions are purely additive, there are no deny rules, and shows the two kinds of object involved, a Role or ClusterRole listing resources and verbs and a RoleBinding attaching it to subjects; the lab creates two namespaces, mints two users with openssl certificates signed by the cluster's own CA, gives each a Role in one namespace, and shows each being forbidden in the other.[14] Its manifests use the extensions/v1beta1 and rbac v1beta1 API versions and the Helm 2 install syntax, which dates it to 2019.[14]

Nobody learns Kubernetes on a production cluster, and the books disagree only on which substitute to use. The Bash-first Kubernetes for All makes the case for Kind, which runs each cluster node as a Docker container sharing the host kernel: a multi-node cluster in about thirty seconds, native on Apple Silicon, a command that pushes an image straight into the nodes without a registry, and the same configuration in GitHub Actions and GitLab CI.[13] The 2025 and 2026 introductions also build on Kind,[29][42] the Helm introduction sets one up so that no existing cluster is needed,[41] and the controller interview guide runs its capstone in kind.[16] The textbook family uses the cluster built into Docker Desktop and a cloud cluster on Linode or Civo for the rest,[23][25] and a long cloud-native guide covers Minikube, Rancher and Terraform-built clusters.[34]

A service can pass every test and still fail in an ordinary rollout, and a 2026 pocketbook for Go teams starts from exactly that failure: Kubernetes sends SIGTERM to a pod during a deployment, the pod keeps reporting ready for a few seconds, traffic keeps arriving, in-flight requests are dropped, and the rollout is marked successful anyway.[15] Its baseline closes the gap: on SIGTERM the pod flips readiness to false so the Service stops routing to it, drains within the grace period, and only then exits.[15] The same book gives the probe semantics that most tutorials blur. A liveness probe should be process-local and never check a database or a network dependency, because a slow downstream then looks like a dead process and the pod is restarted when it should merely stop receiving traffic; readiness reflects whether the pod can serve now, with dependencies checked under bounded timeouts; a startup probe protects slow initialisation from false restarts.[15] It closes with a security baseline for the pod spec: run as non-root, a read-only root filesystem, every capability dropped, the default seccomp profile, a network policy, and secrets mounted rather than baked into the image.[15]

The language-specific guides take an application from laptop to cluster. The Java one gets a Spring Boot and a Quarkus application onto Kubernetes without writing YAML or a Dockerfile, through the Quarkus CLI, Dekorate and Cloud Native Buildpacks, then layers in security, autoscaling, Knative, an Istio mesh and delivery with Tekton and Argo CD.[38] The Python one pairs Dockerfiles, Compose and GPU containers with Deployments, horizontal pod autoscaling, secrets and Helm before serving language models with vLLM and TorchServe.[53] A deep-learning book places containerising with Docker and scaling with Kubernetes at the end of a lifecycle that begins with structuring and testing the model code.[22]

Helm packages an application's manifests as a chart with a values file, and a 68-page 2026 introduction takes a newcomer from what a chart is through installing, upgrading and rolling back releases to building and publishing custom charts, covering both Helm 3 and the server-side apply and WASM plugins of Helm 4.[41] The lab book shows Helm 2 installing the ingress controller and lists the resources the chart creates,[14] and the Bash book installs its releases through a library of Helm wrappers.[13]

GitOps makes a Git repository the source of truth and a controller inside the cluster the thing that applies it. The 2025 Master GitOps with Argo CD spends its first chapters on the problems GitOps solves, manual kubectl and script-driven pipelines, and on Argo CD's internals, before installation, a first application, sync policies and sync waves, ApplicationSets and the App of Apps pattern, blue-green deployments and secrets, and ends by comparing Argo CD with Flux, Tekton, Jenkins X and Spinnaker.[44] The long cloud-native guide ends in the same place, with Argo CD, Helm charts and Ansible-generated values for several environments,[34] the Bash book adds Argo CD in its third act so that the cluster pulls from Git rather than being pushed to by hand,[13] and the administration guide gives GitOps, Argo CD against Flux, and policy with OPA Gatekeeper and Kyverno a chapter.[4] The older pipeline model is in a 2018 book that builds a Jenkins pipeline for a Spring Boot application with Jenkins agents allocated as Kubernetes pods and a canary release at the end; its free sample is the Agile and Scrum chapters that precede the tooling.[18] A 2024 survey of the DevOps toolchain gives Docker and Kubernetes a chapter each among AWS, Linux, Terraform and GitHub Actions.[19]

Kubernetes can be extended with new object kinds and with controllers that reconcile them, and the two 2026 books on the subject are the most demanding in the sample. A Kubebuilder guide builds one operator end to end: custom resource definitions and the control loop, when an operator is the right tool rather than a Job, validation, status, finalizers, idempotent reconciliation, metrics, tests with envtest, Helm packaging, and a second API version with a conversion webhook.[48] An interview guide for platform engineers states the invariant every controller must respect: it converges current state toward desired state, events are only hints, and the reconcile loop must be idempotent and correct even when it runs twice or misses an intermediate event.[16] Its sampled panels list the traps: the controller-runtime client reads through a cache that the watch stream updates asynchronously, so a read immediately after a write may return the old object, and direct API reads are a cost rather than a fix; predicates that filter events can drop a change that correctness needed; leader election does not give exactly-once processing, so idempotency still protects correctness when the leader is killed mid-reconcile; and a name is not an identity, so a UID annotation distinguishes a recreated object from the one it replaced.[16] Its capstone, a syncer that copies ConfigMaps from a tenant namespace into a managed one, is broken on purpose eight ways, by editing the target, deleting its namespace, exceeding a limit, removing the controller's RBAC and so on, each with the recovery to expect.[16]

A service mesh puts a proxy beside every pod and moves routing, retries, encryption and telemetry out of the application. A 2020 sketchnote book covers Istio with a drawing and a how-to per concept: its components as they were then, its resources from Gateway and VirtualService to EnvoyFilter, traffic splitting, canary releases and mirroring, circuit breaking and fault injection, observability, security and debugging.[40] Istio appears again as a chapter of the Java guide and of the long cloud-native guide, where it drives blue-green and canary deployments,[38][34] and the administration guide sets it beside Linkerd.[4]

The Go pocketbook's observability panels are a compact statement of current practice: one Prometheus metrics endpoint with stable names and low-cardinality labels, never user IDs or raw URLs, and OpenTelemetry as the instrumentation standard, exported to a collector that fans out to Prometheus, Tempo or Jaeger and Loki.[15] The administration guide's chapter covers the same three pillars, plus kubectl debug, ephemeral containers and crictl, and its architecture chapter gives the diagnostic value of the data flow: an expired certificate blocks everything at authentication, an RBAC mistake shows as forbidden, a slow etcd write as an API timeout, a missing image as ImagePullBackOff.[4] A short 2026 troubleshooting guide is organised by symptom rather than by object: CrashLoopBackOff and ImagePullBackOff, DNS and CNI failures, CPU throttling, OOM kills and node pressure, persistent volume problems, and control plane failures such as etcd corruption.[50] A 2024 book approaches cluster observability through eBPF and Cilium with Grafana rather than through a Prometheus-first stack.[33] The GPU books add DCGM metrics for the accelerators.[51][49]

Container security has a Docker layer and a Kubernetes layer, and the samples cover both. A 2018 quick reference on hardening Docker pairs risks with countermeasures for each area: image provenance and doppelganger images in registries, the root user by default, hardening the host, the engine and the containers with namespaces, control groups, capabilities, Linux Security Modules, seccomp and read-only containers, and the scanners of that era.[37] The same material appears, inside a risk-and-countermeasure method applied to everything from SSH to firewalls, as one section of a very long security book for web developers.[35] The general Docker guides give security a chapter and cover rootless mode and Docker Scout.[28][24]

On the cluster side the administration guide records that Pod Security Admission has fully replaced PodSecurityPolicy and that admission policies written in CEL now come built in, and it covers authentication, RBAC design, image signing and scanning, and external secret stores.[4] The textbook and the course close with threat modelling (spoofing, tampering, repudiation and the rest) and a real-world security chapter on pipelines, isolation, identity and auditing.[23][45] Secrets are the recurring weak point. Vault in Practice opens with a database password sitting in a deployment manifest that is in Git, mirrored, cloned to nineteen laptops and pasted into a ticket by a contractor who has since left, and names what that sprawl costs: visibility, rotation, attribution and revocation.[8] The Go baseline's answer at the pod level is to mount secrets and never bake them into the image.[15]

The administration guide's hard numbers are the ones administrators quote: three etcd members tolerate one failure and five tolerate two; kube-proxy in iptables mode evaluates its rules sequentially and becomes a bottleneck above about a thousand Services, where IPVS or eBPF is recommended; the kubelet's default of 110 pods per node and its eviction thresholds are what stand between resource pressure and a cascading failure.[4] A 2026 field manual on rate limiting treats the application side of overload: the window and bucket algorithms, local against distributed quota state, and what happens to a limiter when pod counts change under autoscaling.[21] A distributed-systems book supplies the arithmetic behind every microservice diagram: a function call costs about five nanoseconds and an HTTP call on the same host about two hundred microseconds, so five sequential service calls add ten milliseconds before any business logic runs, and it lists the dozen ways a call can fail, from connection refused to a 429, that a single process never sees.[20]

OpenShift is Kubernetes with the pieces an enterprise adds around it, and two 2025 books describe it from opposite ends. One builds a private cloud on a single KVM host: an OpenShift cluster installed with the installer-provisioned method, OpenStack services run as containers on top of it for the virtual machines that remain necessary, and a three-node Ceph cluster serving both; its first chapter argues the case for on-premise cloud on control, cost predictability, hardware specialisation and hybrid placement, and explains what OpenShift adds to Kubernetes, integrated registries and build pipelines, OVN-Kubernetes networking, operators for day-two operations and enterprise authentication.[17] The other is a handbook for platform engineers building a GPU-capable AI platform on OpenShift that is often air-gapped or behind a proxy: agent-based installation from a local Quay registry mirror, cluster-wide proxies, a disconnected OperatorHub, the NVIDIA GPU Operator, RDMA networking and GitOps with Argo CD, all framed by the CNCF platform engineering whitepaper's idea of a platform as a product with golden paths.[49] The administration guide compares the managed services, EKS, GKE and AKS, with Rancher, OpenShift and bare metal, and gives FinOps for Kubernetes a chapter.[4] For a single container the cloud route is simpler: the 2026 Docker course deploys to DigitalOcean App Platform, AWS ECS and Google Cloud Run,[52] and the twelve-factor book scripts DigitalOcean droplets with the doctl tool so that a Docker host exists only while it is needed.[10]

The newest books in the sample are about putting GPUs and language models on Kubernetes. One 2026 guide follows a single running example, Mistral-7B, from the NVIDIA GPU Operator and GPU scheduling and sharing, including dynamic resource allocation, through serving with vLLM and the alternatives to it, multi-node inference, training with Kueue and the Kubeflow operator, storage, RDMA networking, DCGM observability, policy and cost control, to a GPU troubleshooting field guide.[51] The OpenShift handbook covers the same operators, DCGM monitoring and a model registry, and runs LLM benchmarks as code with Inference-Benchmarker.[49] The Python series volume serves models with vLLM and TorchServe on a cluster and builds a private chat platform as its capstone,[53] and on the laptop the 2025 Docker introductions run local models with Docker Model Runner.[36][24]

A large share of the books filed under Docker are about something else and use containers as plumbing, which is itself a fact about the field. A DevOps katas book teaches Docker, Git and Jenkins as short repeatable exercises in a learning VM and ends with a pipeline that builds an image, pushes it to a private registry and promotes it through environments; six of its twenty-one katas are Docker.[5] The network-management guide stands up its whole stack with Compose,[32] the logging guide provisions its containers through Vagrant,[12] and the deep-learning book containerises a model server behind Nginx.[22]

The exams follow the same syllabus as the books. The textbook is written partly for CKA candidates,[23] the troubleshooting guide names the CKA and CKAD,[50] a study guide follows the eleven modules of the LPI DevOps Tools Engineer exam, three of them on container usage, infrastructure and orchestration,[47] and the interview guide prepares senior and staff platform engineers with a study plan, a drill bank and a capstone to defend in a design review.[16]