Docker from First PrinciplesPost 15 of 18 · 18 of 18 written
  1. How to use this guide
  2. 01The problem Docker solves
  3. 02What a container really is
  4. 03Images: layers, hashes and registries
  5. 04Docker's architecture
  6. 05Container lifecycle
  7. 06Dockerfiles in depth
  8. 07Storage: where data lives
  9. 08Networking
  10. 09Docker Compose for multi-service AI apps
  11. 10GPUs in containers
  12. 11Building good images for AI workloads
  13. 12Serving and production patterns
  14. 13Security
  15. 14Debugging and introspection
  16. 15Beyond Docker
  17. 16Hands-on learning path
  18. 17Question bank
  19. 18Glossary and cheat sheet

15. Beyond Docker

Docker · 15 of 182 min readOct 2026

Docker is the on-ramp. The OCI images you build flow unchanged into other runtimes and orchestrators, and university HPC clusters often don’t allow Docker at all, so knowing the neighbours is part of fluency.

Other runtimes

  • Podman. Daemonless and rootless by default, with a Docker-compatible CLI (alias docker=podman mostly works) and support for pods, groups of containers that share a network namespace like in Kubernetes. Standard on Fedora and RHEL.
  • containerd with nerdctl, and CRI-O. What Kubernetes nodes actually run. nerdctl gives containerd a Docker-like CLI.
  • Apptainer (formerly Singularity). The HPC standard. It runs containers as your own user with no root daemon, packs an image into a single .sif file that sits on the shared filesystem, mounts your home directory by default, and enables GPUs with --nv. Convert your Docker image directly: apptainer build trainer.sif docker://ghcr.io/ulvi/trainer:1.0, then apptainer exec --nv trainer.sif python -m src.train.
  • Enroot and Pyxis. NVIDIA’s tools for running containers under Slurm, used on many GPU clusters: srun --container-image=<image> ….

Kubernetes in Docker terms

Kubernetes schedules containers across many machines and keeps the declared state true. Most of it maps onto concepts you already know:

Docker concept Kubernetes equivalent
docker run (one container) Pod: one or more containers sharing a network namespace
--restart unless-stopped Deployment: keeps N replicas running, rolls out updates
A one-off docker run --rm job Job, or CronJob for schedules; how training runs are launched
-p and container DNS names Service: stable name and virtual IP in front of pods
Reverse proxy Ingress or Gateway
Named volume PersistentVolumeClaim
-e and --env-file ConfigMap and Secret
HEALTHCHECK Readiness, liveness and startup probes
--memory, --cpus resources.requests and resources.limits
--gpus 1 resources.limits: nvidia.com/gpu: 1, via the NVIDIA device plugin or GPU Operator
compose.yaml Manifests, packaged with Helm or Kustomize

The ML ecosystem on top: KServe for model serving, KubeRay for Ray clusters (distributed training, tuning, batch inference), Kubeflow and Argo Workflows for pipelines, Kueue for GPU job queueing. For local practice, kind, k3d or minikube run a small cluster inside Docker on your Mac.

Dev Containers

A .devcontainer/devcontainer.json file tells VS Code, Cursor, JetBrains IDEs or GitHub Codespaces to open a project inside a container built from your Dockerfile, with extensions and settings preconfigured. Every collaborator, and every machine you use, gets the same toolchain. It pairs naturally with the dev build target from Part 11.

Stronger isolation

gVisor, Kata Containers and Firecracker microVMs (Part 13) plug in as alternative runtimes when you run untrusted code, including agent-generated code, in a multi-tenant setting.