Begriff
CaaS (Container as a Service)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Du hast Docker-Container. Aber wo lässt du sie laufen? Auf deinem Laptop? (Nicht skalierbar). Auf einer VM (EC2)? (Du musst das OS patchen -> Nervig). Auf CaaS (wie Google GKE, AWS EKS). Du sagst: "Hier ist mein Image. Lass es 10x laufen." Der Cloud Provider gibt dir Kubernetes als Service. Er kümmert sich um die Master Nodes, das Netzwerk, die Updates. Du kümmerst dich nur um deine Container. Es ist der Sweet Spot zwischen IaaS (zu viel Arbeit) und PaaS (zu wenig Kontrolle).
Merksatz: Ein Cloud-Service-Modell, das Nutzern ermöglicht, containerisierte Anwendungen (Docker, Kubernetes) hochzuladen, zu organisieren, zu starten, zu stoppen und zu skalieren, ohne die darunterliegende Infrastruktur zu verwalten.
Du nutzt kubectl.
kubectl apply -f deployment.yaml.
Dein CaaS-Provider (GKE) sieht das, spinnt neue VMs hoch (Node Auto-Provisioning), zieht das Image und startet es.
Wenn eine Node stirbt, startet GKE sie neu.
1. The Control Plane Tax
Bei Kubernetes hast du Master Nodes (Control Plane) und Worker Nodes. Bei CaaS managed der Provider die Control Plane. Oft zahlst du dafür eine Pauschale (z. B. 70$/Monat bei EKS), oder es ist inkludiert (GKE Zonal). Das nimmt dir die schwerste Arbeit ab (Etcd Backups, Zertifikats-Rotation).
2. Serverless Containers (Fargate / Cloud Run)
Die Evolution von CaaS. Du siehst nicht mal mehr die Worker Nodes. Du zahlst pro Sekunde, die dein Container läuft. Keine "Cluster-Upgrades" mehr.
1. Scheduling & Bin-Packing
In einem CaaS-System ist die Effizienz des Schedulers entscheidend. Der Provider nutzt Algorithmen wie Bin-Packing, um so viele Container wie möglich auf so wenige virtuelle Maschinen wie möglich zu quetschen, ohne dass diese sich gegenseitig die Ressourcen (CPU/RAM) wegstehlen. In der Produktion führt das oft zum "Noisy Neighbor" Problem: Ein Container auf der gleichen Node verbraucht den gesamten L3-Cache der CPU, wodurch dein Container langsamer wird, obwohl er laut Dashboard noch CPU-Limit frei hat. CaaS-Provider nutzen daher Techniken wie Resource Isolation (cgroups v2), um dies zu minimieren.
2. Multi-Tenancy & Security Hardening
Da CaaS oft "Shared Infrastructure" ist (deine Container laufen auf dem gleichen physischen Server wie die der Konkurrenz), ist Sicherheit das A und O. Modernes CaaS nutzt oft Sandboxed Runtimes anstelle von Standard-Docker:
- gVisor (Google): Emuliert den Linux-Kernel im User-Space. Ein Container kann den echten Kernel nicht direkt angreifen.
- Kata Containers (AWS Fargate): Startet für jeden Container eine extrem kleine, optimierte Micro-VM. Dies erhöht die Sicherheit massiv, kostet aber ca. 3-5% Performance durch den Abstraktions-Overhead.
3. Vertical vs. Horizontal Scaling
CaaS glänzt beim Scaling.
- HPA (Horizontal Pod Autoscaler): Erstellt mehr Kopien deiner App, wenn die Last steigt.
- VPA (Vertical Pod Autoscaler): Erhöht die CPU/RAM-Zuweisung für einen bestehenden Container.
Ein häufiger Fehler im CaaS-Betrieb: Man setzt keine CPU-Limits (
limits). Kubernetes killt den Container dann nicht bei hohem Verbrauch, was zum "OOM-Kill" (Out of Memory) der gesamten Node führen kann und so auch andere, unbeteiligte Container mit in den Abgrund reißt.
Quick-Check
Warum nicht einfach PaaS (Heroku)?
PaaS zwingt dich oft in ein Korsett ("Nur Java 8", "Keine C++ Libraries"). CaaS gibt dir volle Freiheit (jedes Docker Image läuft), aber nimmt dir trotzdem die Infrastruktur ab.Lock-in?
Gering. Kubernetes ist Standard. Du kannst von GKE (Google) zu EKS (AWS) wechseln. Die YAML-Dateien bleiben (fast) gleich.Ist Docker CaaS?
Nein. Docker ist das Werkzeug. Docker Hub ist eine Registry. CaaS ist die Laufzeitumgebung in der Cloud.