CaaS (Containers as a Service) is a cloud delivery model in which providers manage the underlying infrastructure so teams can build, run, and scale containerized workloads without owning servers. It sits between IaaS and PaaS: you supply container images, the platform handles scheduling, networking, scaling, and availability. The runtime layer — the component that actually executes containers — and the orchestrator above it together determine latency, isolation, cost, and operational complexity; choosing the right combination for each workload is the central decision in CaaS architecture.
What This Cheat Sheet Covers
This topic spans 24 focused tables and 154 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Container Runtimes
The container runtime is the lowest-level component that pulls images, creates namespaces and cgroups, and starts processes inside a container. Understanding the distinction between high-level runtimes (containerd, CRI-O) that implement the CRI and low-level runtimes (runc, Kata Containers) that implement the OCI runtime spec is essential when troubleshooting scheduling failures, security incidents, or performance issues.
| Runtime | Example | Description |
|---|---|---|
ctr run --rm docker.io/library/nginx:latest mynginx | • Industry-standard high-level CRI runtime • manages image pull, snapshots, and lifecycle • default runtime in Kubernetes, EKS, GKE, and AKS | |
crictl pull nginx:latest | • Lightweight CRI runtime built specifically for Kubernetes • no daemon restart needed for config changes • default in OpenShift | |
docker run -d -p 80:80 nginx | • Full container platform with CLI, build, and daemon • uses containerd internally since v23 • still dominant for local development and CI builds. | |
runc run mycontainer | • Reference OCI low-level runtime • spawns container processes directly via Linux namespaces and cgroups • used by containerd and CRI-O under the hood |