Die Container Runtime ist die Software, die auf meinen Kubernetes-Worker-Nodes meine Container tatsächlich ausführt. Über das Container Runtime Interface (CRI) spricht Kubernetes – genauer gesagt kubelet – mit der Runtime und setzt meine Pod-Vorgaben technisch um.
Wo ich die Container Runtime betreibe
Ich betreibe die Container Runtime lokal auf jeder Worker Node meines Kubernetes-Clusters. In selbst installierten Umgebungen installiere ich containerd oder CRI-O direkt auf dem Betriebssystem meiner Nodes. In Cloud-Clustern wie AKS, EKS oder GKE läuft die Runtime ebenfalls auf meinen Worker-Maschinen, wird dort aber für mich vom Provider vorkonfiguriert und gewartet.
- Jeder Node benötigt genau eine aktive Runtime.
- kubelet spricht für mich direkt mit der Runtime.
- Der API-Server startet keine Container selbst.
Was das CRI konkret ist
Ich verstehe CRI als standardisierte Schnittstelle, die Kubernetes unabhängig von der konkreten Container-Technologie macht. Für mich kann ich dadurch verschiedene Runtimes nutzen, ohne meine Kubernetes-Objekte anpassen zu müssen.
Übliche Implementierungen, die ich verwende:
- containerd – verbreitet, schlank und stabil
- CRI-O – speziell für Kubernetes entwickelt
- weitere OCI-kompatible Runtimes
Wie die Container Runtime für mich funktioniert
Wenn ich einen Pod beschreibe, liest kubelet meine Definition aus der Kubernetes API und sendet CRI-Befehle an die Runtime. Für mich passiert dann:
- Die Runtime lädt „mein“ Container Image.
- Sie erstellt für mich Container laut Pod-Spec.
- Netzwerk wird über mein CNI-Plugin angebunden.
- Volumes werden für mich gemountet.
- Container werden dauerhaft überwacht.
Der Status meiner Container wird vom kubelet wieder an kube-apiserver gemeldet, so dass ich ihn später mit kubectl get pods abfragen kann.
Beispiele meiner Nutzung
Beispiel 1 – Ich frage laufende Container
kubectl get pods Für mich liefert dieser Befehl den Zustand meiner Pods, den kubelet über CRI von containerd erhält.
Beispiel 2 – Ich lese Logs
kubectl logs blog kubelet holt für mich Logs aus der Runtime, ohne dass ich direkt auf meinen Node zugreifen muss.
Beispiel 3 – Neustart nach Health Check
Wenn für mich eine Liveness-Probe fehlschlägt, weist kubelet die Container Runtime an, „meinen“ Container neu zu starten.
Was die Container Runtime nicht macht
- Ich plane Nodes mit kube-scheduler, nicht mit CRI
- Ich verwalte Replicas mit controller-manager
- Die Runtime führt nur meine Container aus
Fazit
Die Container Runtime (CRI) ist für mich die Komponente, die ich auf jeder Kubernetes-Worker-Node betreibe und die über containerd oder CRI-O meine Container tatsächlich startet. Sie arbeitet ausschließlich auf Node-Ebene und ist die technische Basis meines Pod-Lifecycles.