Alle paar Monate fragt uns ein Team von drei bis fünf Engineers, ob es auf Kubernetes umziehen sollte. Die Anwendung ist ein Web-Frontend, eine API, ein paar Worker und eine Datenbank. Sie läuft auf ein oder zwei Servern oder auf einer Platform-as-a-Service, die teuer wird. Jemand hat gelesen, dass Kubernetes das ist, was echte Unternehmen tun, und sie wären gern ein echtes Unternehmen.
Die Antwort, die wir geben, fast jedes Mal, ist nein. Nicht „noch nicht“. Nein. Und weil diese Antwort nach Faulheit oder Widerspruchsgeist klingt, ist dieser Artikel die Begründung dahinter, die Alternative, die wir stattdessen bauen würden, was sie kostet, und die konkreten Bedingungen, unter denen sich die Antwort ändert.
Wofür Kubernetes da ist
Kubernetes löst Scheduling: gegeben eine Flotte von Maschinen und ein Satz Workloads mit Ressourcenanforderungen, platziere die Workloads auf den Maschinen, halte sie am Laufen, ersetze sie, wenn sie sterben, und mache sie füreinander und für die Welt erreichbar. Es löst das außerordentlich gut, in jeder Größenordnung, für jede Art von Workload, mit einem Ökosystem für alles, was man sich wünschen könnte.
Beachten Sie, was die Problemstellung voraussetzt: eine Flotte von Maschinen. Wenn Sie keine Flotte haben, haben Sie das Scheduling-Problem nicht, und Kubernetes wird zu einer sehr ausgefeilten Antwort auf eine Frage, die Sie nicht gestellt haben. Ein Team mit drei Diensten braucht kein Bin-Packing. Es braucht Container, die laufen, neu starten, bei Traffic von zwei auf sechs skalieren und eine HTTPS-URL bekommen.
Was Sie mit einem verwalteten Cluster trotzdem bekommen
„Managed Kubernetes“ (EKS, GKE, AKS) verwaltet die Control Plane. Den Rest verwaltet es nicht, und in den Rest fließt die Zeit. Für einen Produktions-Cluster besitzen Sie:
- Node-Gruppen, ihre Instanztypen, ihre AMI-Updates, ihr Autoscaling.
- Netzwerk: ein CNI, ein Ingress-Controller, ein Load Balancer pro Ingress oder ein geteilter, cert-manager für TLS, external-dns für Einträge.
- Observability: metrics-server, ein Logging-Agent und alles, was Sie ohnehin gebraucht hätten.
- Sicherheit: Pod Security Standards, Network Policies, IRSA oder Workload Identity für AWS-Zugriff, Image-Scanning, ein Admission Controller, wenn Sie es ernst meinen.
- Upgrades: Kubernetes erscheint dreimal im Jahr, und verwaltete Anbieter stellen den Support für alte Versionen etwa ein Jahr nach Release ein. Jedes Upgrade berührt den API-Server, die Nodes und gelegentlich die Manifeste, weil etwas deprecated wurde.
- Deployment-Tooling: Helm oder Kustomize, eine Umgebungsstrategie und wahrscheinlich ArgoCD oder Flux, sobald „kubectl apply vom Laptop“ Sie einmal gebissen hat.
Nichts davon ist schwer für Leute, die es schon gemacht haben. Alles davon ist eine dauerhafte Steuer für ein Team, das es nicht gemacht hat, und in einem Dreierteam ist es eine Person. Wir haben es gesehen: der stärkste Engineer wird zum Cluster-Engineer, die Produktgeschwindigkeit halbiert sich, und achtzehn Monate später haben sie eine schöne Plattform unter einem Produkt, das aufgehört hat zu wachsen.
Was wir stattdessen bauen
Ein gutes Dockerfile und eine verwaltete Laufzeit, die ein Image nimmt und eine URL zurückgibt. Auf AWS ist das App Runner für den einfachen Fall und ECS Fargate, wenn Sie einen VPC-internen Dienst oder mehr Kontrolle brauchen; die Entsprechungen in den anderen Clouds sind Cloud Run und Container Apps, und das Argument ist identisch.
Das Dockerfile ist der Ort, an den die Engineering-Arbeit geht, und es ist Arbeit, die auch für Kubernetes angefallen wäre: Multi-Stage-Build, ein Nicht-Root-Benutzer, ein gepinntes Basis-Image, ein HEALTHCHECK, keine eingebackenen Secrets, ein Image unter 200 MB, damit Kaltstarts schnell sind. Wir haben über die Node-Version davon geschrieben. Einmal richtig gemacht, ist es dieselbe Datei auf jeder Laufzeit, Kubernetes eingeschlossen, falls Sie je umziehen.
Die Laufzeit tut, was der Cluster getan hätte: zieht das Image, betreibt N Kopien, prüft ihre Gesundheit, ersetzt die toten, skaliert zwischen min und max, terminiert TLS, routet Traffic. Sie tut das mit einer Service-Definition von etwa zwanzig Zeilen CDK, und ohne ein Node-OS, das Sie patchen müssten.
Der Rest des Stacks ändert sich nicht. Aurora oder DynamoDB für Daten, SQS für Queues, Lambda für die wirklich eventförmigen Dinge, der OpenTelemetry Collector für Observability. Nichts auf dieser Liste hat je einen Cluster gebraucht.
Die Kosten, ehrlich
Die übliche Verteidigung von Kubernetes bei den Kosten ist, dass Fargate und App Runner einen Aufschlag pro vCPU-Stunde gegenüber rohem EC2 verlangen. Stimmt. Hier ist, was dieser Aufschlag in der fraglichen Größenordnung kauft, für drei Dienste mit je zwei warmen Instanzen in Produktion:
| Managed Kubernetes (EKS) | Container auf App Runner / Fargate | |
|---|---|---|
| Control Plane | $73 / Monat | $0 |
| Nodes / Compute | 3 × m6i.large ≈ $210, größtenteils idle als Reserve | 6 × 1 vCPU / 2 GB ≈ $250 zu App-Runner-Preisen |
| Load Balancer | 1 ALB ≈ $25 + LCUs | inklusive (App Runner) oder derselbe ALB (Fargate) |
| Add-ons, die Node-Kapazität verbrauchen | Ingress, cert-manager, DNS, Metriken, Logging ≈ ein ganzer Node | keine |
| Upgrades und Patching | 3 Cluster-Upgrades / Jahr, monatliche AMI-Rotation | Basis-Image-Tag anheben |
| Engineering-Zeit | ≈ 0,5–1 FTE | ≈ 0,05 FTE |
| Monatlich, alles inklusive | ~$310 + $5.000–10.000 Engineer | ~$275 + ~$500 Engineer |
Die Infrastrukturposten liegen $50 auseinander. Der Engineering-Posten ist der ganze Vergleich. Bei drei Diensten ist Kubernetes nicht teurer im Betrieb; es ist um eine Größenordnung teurer im Besitz, und der Aufschlag pro vCPU-Stunde ist dagegen Rauschen.
Wann sich die Antwort ändert
Wir sind nicht gegen Kubernetes. Wir betreiben es, für Kunden, die es brauchen. Die Antwort kippt, wenn eine dieser Bedingungen zutrifft, und meist braucht es zwei:
- Viele Dienste, viele Teams. Ab grob fünfzehn bis zwanzig Diensten mit mehreren unabhängig deployenden Teams wird die Pro-Dienst-Konfiguration der verwalteten Laufzeiten zu ihrem eigenen Wildwuchs, und ein Cluster mit Namespaces, Quotas und einem GitOps-Controller ist wirklich einfacher.
- Workloads, die nicht in die Form der Laufzeit passen. Requests länger als das Timeout der Laufzeit, GPUs, StatefulSets, Daemons mit Host-Zugriff, eigenes Networking. App Runners 120-Sekunden-Limit ist real; wenn Ihr Workload 20 Minuten Websocket braucht, sind Sie darüber hinausgewachsen.
- Gleichmäßiger, großer Compute. Bei Hunderten vCPUs rund um die Uhr ist der Aufschlag pro vCPU kein Rauschen mehr, und reservierte Nodes in einem Cluster sind spürbar günstiger. Das ist der Kosten-Schnittpunkt, und er liegt viel höher, als Leute annehmen.
- Portabilität als Anforderung. Wenn ein Vertrag sagt „muss in den eigenen Cluster des Kunden deploybar sein“, ist die Laufzeit Kubernetes, weil die des Kunden es ist. Das ist die Situation bei unserer Agentenplattform, weshalb sie als Helm-Charts ausgeliefert wird und weshalb wir die Steuer aus erster Hand kennen.
- Sie haben die Person schon. Wenn jemand im Team Produktions-Cluster betrieben hat und das weiter tun will, sinken die Besitzkosten und die Rechnung ändert sich. Stellen Sie sicher, dass die Person es will, und was passiert, wenn sie geht.
Der Einwand: „aber dann müssen wir später migrieren“
Vielleicht. Hier ist, was eine spätere Migration von einer verwalteten Laufzeit auf Kubernetes tatsächlich bedeutet, für ein Team, das so gebaut hat wie beschrieben: die Dockerfiles bleiben unverändert; die Health-Routen bleiben unverändert; die Umgebungsvariablen und Secret-Referenzen werden zu einer ConfigMap und einem ExternalSecret; die zwanzig Zeilen CDK pro Dienst werden zu vierzig Zeilen Helm-Values. Der Observability-Agent wechselt vom Sidecar zum DaemonSet mit derselben Konfiguration. Das ist ein Zwei-Wochen-Projekt für jemanden, der es schon gemacht hat, und bis Sie es brauchen, haben Sie die Person, denn es zu brauchen ist das, was die Einstellung rechtfertigt.
Was nicht wiederzuholen ist, sind die achtzehn Monate Aufmerksamkeit eines kleinen Teams, die in einen Cluster geflossen sind, den es nicht brauchte. Das sind die Kosten, über die wir tatsächlich streiten.
Die Kurzfassung
Kubernetes ist ein Scheduler für Flotten. Wenn Sie keine Flotte haben, lassen Sie Ihre Container auf etwas laufen, das Ihnen eine URL gibt, stecken Sie Ihre Arbeit ins Dockerfile und in den Health-Check, und stellen Sie die Frage neu, wenn Sie fünfzehn Dienste, eine GPU oder einen Kunden haben, der darauf besteht. Bis dahin sollte der erfahrenste Engineer in Ihrem Team das Produkt bauen.
Wenn Sie das gerade entscheiden und eine zweite Meinung möchten, die keine der beiden Antworten verkauft, sprechen Sie mit uns.