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, 160 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
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 | ||
podman run -d --name web nginx | • Daemonless, rootless OCI runtime • drop-in Docker CLI replacement • supports pods natively • preferred for rootless and socket-less environments | ||
runsc run --bundle /bundle mycontainer | • Google's user-space kernel sandbox (runsc) • intercepts syscalls inside a sandbox process • strong isolation with moderate performance overhead • supported in GKE Sandbox | ||
RuntimeClass: kata-qemu (in Pod spec) | • Runs each container inside a lightweight VM (QEMU/Firecracker/Cloud Hypervisor) • OCI-compliant • integrates via RuntimeClass • ~150–400 ms startup • used for multi-tenant isolation and regulated workloads | ||
kubectl apply -f spinapp.yaml | • WASM runtime shim for Kubernetes ( containerd-shim-spin)• runs WebAssembly modules as pods via SpinApp CRD • modules are 10–100× smaller than OCI images with sub-millisecond cold starts |