Container-runtime

"Container-runtime" dækker over to lag, som er lette at forveksle. En lavniveau-runtime (OCI-runtime) implementerer OCI Runtime Specification: givet et bundle - et rodfilsystem plus config.json - udfører den operationerne create, start, kill og delete ved at kalde clone/unshare for namespaces, skrive cgroup-grænser, skifte ind i rodfilsystemet med pivot_root, fjerne capabilities, installere seccomp-filteret og anvende AppArmor- eller SELinux-profilen, før entrypoint startes med exec. runc (skrevet i Go, oprindeligt Dockers libcontainer, som blev doneret til OCI i 2015) er referenceimplementeringen; crun (C) og youki (Rust) er hurtigere eller mindre alternativer. En højniveau-runtime som containerd eller CRI-O håndterer alt omkring det: at hente og pakke images ud i snapshots, forberede bundlet, koble netværk på via CNI-plugins, streame logs og exec-sessioner og overvåge hver container gennem en lille shim-proces, så containeren overlever en genstart af dæmonen.

Kubernetes taler med højniveau-runtimen via Container Runtime Interface (CRI), et gRPC-API med en RuntimeService (pod-sandkasser og containere) og en ImageService, som kom til i Kubernetes 1.5. Docker Engine har aldrig selv implementeret CRI; kubelets indbyggede adapter, dockershim, blev fjernet i Kubernetes 1.24, og siden bruger klynger containerd eller CRI-O direkte (images bygget med Docker kører stadig uændret, fordi de er OCI-images). Kaldkæden på en node er derfor kubelet → CRI → containerd eller CRI-O → shim → runc → kerne.

Sandkasse-runtimes sættes ind i samme grænseflade, men ændrer isolationsmodellen. gVisors runsc opfanger systemkald i en kerne i brugerrummet (Sentry), så arbejdsbyrden kun rører en smal del af værtens kerne; Kata Containers starter hver pod i en letvægts-VM med sin egen gæstekerne under en hypervisor som QEMU eller Cloud Hypervisor. Kubernetes vælger handler per pod med et RuntimeClass-objekt, så én klynge kan køre betroede workloads på runc og ikke-betroede på gVisor eller Kata på bekostning af noget ydeevne og kompatibilitet.

Runtimen er en del af den betroede computerbase: den kører som root på værten og fortolker input, som en angriber kan påvirke (image-lag, config, exec-forespørgsler). runc-sårbarhederne CVE-2019-5736 og CVE-2024-21626 blev begge til udbrud på værtsniveau, og derfor hører opdatering af runtimen med i den løbende sårbarhedshåndtering på linje med kerneopdateringer. Hærdningsmuligheder er bl.a. rootless mode, user namespaces for pods, begrænset adgang til runtimens socket (/run/containerd/containerd.sock) og standard-seccomp-profiler. I modsætning til orkestreringen har runtimen intet begreb om ønsket tilstand på tværs af klyngen; den gør kun det, dens lokale agent beder om.