Was ist Kubernetes? Eine kurze Antwort, dann zehn kreative Einsätze.

Kubernetes hat den Ruf, das zu sein, was man einführt, wenn ein Projekt ernst wird — und einen zweiten Ruf, das zu sein, was ein einfaches Projekt kompliziert gemacht hat. Beide sind verdient. Dieser Artikel beginnt mit der Frage, die Leute tatsächlich eintippen: Was ist Kubernetes? Kubernetes betreibt Container auf einer Gruppe von Maschinen und hält sie so am Laufen, wie du es beschrieben hast, ohne dass jemand danebensitzt. Der offensichtliche Einsatz — eine große Anwendung auf vielen Servern — steht in jedem Tutorial. Hier geht es um die anderen: die, die einen Cluster in eine Build-Farm, eine Feuerwehrübung, einen GPU-Pool oder einen Notausgang aus deiner Cloud verwandeln. Zuerst kurz, was Kubernetes ist und was es von Docker unterscheidet. Dann zehn kreative Einsatzmöglichkeiten, heruntergezählt von zehn, die du heute Abend auf dem Schreibtisch aufbauen kannst, bis eins, dem Einsatz, den wir behalten würden, wenn wir nur einen behalten dürften.

Was ist Kubernetes eigentlich?

Docker betreibt einen Container auf einer Maschine. Kubernetes betreibt viele Container auf vielen Maschinen und hält sie am Laufen. Du beschreibst, was du willst — drei Kopien dieser Web-App, so viel Arbeitsspeicher pro Kopie, erreichbar unter dieser Adresse — und Kubernetes arbeitet ununterbrochen daran, dass der Cluster genau so aussieht: Es startet die Container, verschiebt sie von einer ausgefallenen Maschine, startet hängende neu und ersetzt sie nacheinander, wenn du eine neue Version veröffentlichst. Diese Schleife, die vergleicht, was du verlangt hast, mit dem, was tatsächlich läuft, und die Lücke schließt, ist die ganze Idee.

Vier Begriffe erledigen den Großteil der Arbeit. Ein Cluster ist die Gruppe von Maschinen, Nodes genannt, plus eine Control Plane, die die Entscheidungen trifft. Ein Pod ist das Kleinste, was Kubernetes betreibt: ein oder mehrere Container, die sich eine Adresse teilen. Ein Deployment legt fest, wie viele identische Pods existieren sollen und wie eine neue Version ausgerollt wird. Ein Service ist eine feste Adresse vor Pods, die kommen und gehen. All das steht in kurzen Textdateien, Manifeste genannt — die gesamte Einrichtung kann also in einem Git-Repository liegen, die Idee hinter Platz eins.

Kubernetes stammt von Google, das seine eigenen Dienste schon ein Jahrzehnt lang auf einem internen System namens Borg betrieben hatte. Google hat Kubernetes im Juni 2014 als Open Source veröffentlicht, im Juli 2015 Version 1.0 herausgebracht und es an die neu gegründete Cloud Native Computing Foundation übergeben, wo es das erste Projekt mit Graduated-Status wurde. Der Name ist griechisch für Steuermann, und K8s ist einfach das K, die acht Buchstaben dazwischen und das s.

Heute ist es der Standard, mit dem größere Organisationen Container betreiben: In der Umfrage der Cloud Native Computing Foundation von 2025 setzten 82 % der Container-Nutzer Kubernetes in Produktion ein. Bei einzelnen Entwicklern sieht es anders aus. In der Stack-Overflow-Umfrage 2025 nutzten 71,1 % der Befragten Docker und 28,5 % Kubernetes — die meisten, die mit Containern arbeiten, fassen nie einen Cluster an. Und Kubernetes steht nicht still. Etwa dreimal im Jahr erscheint eine neue Version, 1.37 im August 2026, und jede wird rund vierzehn Monate unterstützt — das gehört zu den Kosten, wie der Abschnitt dazu erklärt.

Kubernetes vs. Docker: keine Rivalen

Docker baut und betreibt Container; Kubernetes entscheidet, wo und wie viele davon auf einer Gruppe von Maschinen laufen. Sie sind keine Alternativen. Dasselbe Image, mit Docker gebaut, läuft auf einem Laptop unter Docker und auf einem Cluster unter Kubernetes, unverändert. Der ehrliche Vergleich ist Kubernetes gegen Docker Compose, das mehrere Container zusammen auf einer einzigen Maschine betreibt.

Die Schlagzeile „Kubernetes schmeißt Docker raus“ von 2022 hat viele verwirrt. Entfernt wurde in Kubernetes 1.24 der dockershim, ein Adapter, über den Kubernetes auf jedem Node mit der Docker-Engine gesprochen hat. Cluster sprechen jetzt direkt mit containerd oder CRI-O. Mit Docker gebaute Images folgen dem offenen OCI-Standard und laufen also genau wie vorher. Für Entwickler hat sich nichts geändert.

Die Faustregel ist kurz. Ein oder zwei Server und eine Handvoll Dienste: Docker Compose und die Ideen aus zehn kreative Wege, Docker zu nutzen. Viele Dienste, mehrere Maschinen, Traffic, der steigt und fällt, oder mehrere Teams, die unabhängig ausliefern: Das ist das Problem, für das Kubernetes gebaut wurde, und der Punkt, ab dem sich sein Gewicht bezahlt macht.

Wie wir sie sortiert haben

„Kreativ“ ist ein billiges Wort, also haben wir ihm einen Test gegeben. Jeder Eintrag musste etwas anderes sein als der Betrieb deiner Hauptanwendung, und er musste jemandem etwas Echtes von der Woche nehmen: eine Rechnung, einen wackligen Handgriff, einen Server, den nur eine Person versteht, ein Risiko, das niemand gemessen hat.

Kubernetes ist schwerer als Docker, also haben wir die Latte höher gelegt. Die meisten Einträge setzen voraus, dass schon ein Cluster existiert — ein verwalteter von einem Cloud-Anbieter oder ein kleiner mit k3s — und fragen, was er noch kann, wenn du ohnehin dafür bezahlst. Ein Einsatz, der allein den Aufbau eines Clusters rechtfertigt, ist selten, und wir sagen es, wo das zutrifft.

Die Reihenfolge geht von zehn bis eins danach, was es einer kleinen Firma oder einem kleinen Entwicklerteam wert ist, nicht danach, wie clever der Trick ist. Jeder Eintrag bekommt dieselben drei Schritte: was er ersetzt, wie er ungefähr umgesetzt wird, und die ehrliche Grenze.

10. Ein Raspberry-Pi-Cluster auf dem Schreibtisch

Was er ersetzt: über Kubernetes zu lesen, statt ihm bei der Arbeit zuzusehen. k3s ist eine zertifizierte Kubernetes-Distribution in einer einzigen kleinen Programmdatei, gebaut für kleine und ARM-Rechner. Drei oder vier Raspberry Pis oder ein paar alte Laptops ergeben an einem Abend einen echten Cluster.

Er verdient seinen Platz, weil Kubernetes erst Sinn ergibt, wenn du siehst, wie es sich erholt. Lass eine App in drei Kopien laufen, zieh einem Board das Stromkabel und sieh zu, wie der Cluster es bemerkt und die fehlende Kopie woanders startet. Veröffentliche eine neue Version und beobachte, wie die Pods einer nach dem anderen ersetzt werden, ohne dass die Seite ausfällt. Kein Diagramm bringt dir das so gut bei.

Die ehrliche Grenze: Das ist ein Klassenzimmer, kein Serverraum. SD-Karten verschleißen, Internet zu Hause ist kein Rechenzentrum, und ein Cluster auf dem Schreibtisch hat kein Backup, wenn du keins baust. Nutz ihn zum Lernen und betreib echte Arbeit dann auf einem verwalteten Cluster oder auf richtigen Maschinen.

9. Eine Feuerwehrübung: Dinge absichtlich kaputt machen

Was sie ersetzt: bei einem echten Ausfall herauszufinden, dass die Retry-Logik nie funktioniert hat. Chaos-Engineering-Werkzeuge, die im Cluster laufen — Chaos Mesh und LitmusChaos sind die Open-Source-Varianten — beenden Pods, bauen Netzwerkverzögerung zwischen Diensten ein, füllen eine Festplatte oder schneiden einen Node ab, nach einem Zeitplan, den du festlegst.

Es geht ums Proben. Beende auf Staging die Pods des Zahlungsdienstes und schau, ob der Checkout eine klare Meldung zeigt oder eine weiße Seite. Mach die Datenbank eine halbe Sekunde langsamer und sieh, welche Seite zuerst in ein Timeout läuft. Jeder Fund ist eine Reparatur an einem ruhigen Dienstag statt mitten in einer Rabattaktion.

Die ehrliche Grenze: Das ist eine Disziplin, kein Produkt. Ohne Monitoring, das dir sagt, was passiert ist, ist ein Chaos-Experiment nur ein Ausfall, den du selbst verursacht hast. Fang auf Staging an, halte jedes Experiment klein und umkehrbar, und geh erst in die Nähe der Produktion, wenn das Team sowohl dem Werkzeug als auch den eigenen Dashboards vertraut. Ein kleines Team ohne Verfügbarkeitszusagen hat von einfacheren Checks oft erst einmal mehr.

8. Geplante Jobs, die ihren Server überleben

Was sie ersetzen: die Crontab auf einem Server, die still aufgehört hat, als der Server neu aufgesetzt wurde, und das nächtliche Backup, das seit März fehlschlägt, ohne dass es jemand weiß. Ein Kubernetes-CronJob startet einen Container nach Zeitplan, irgendwo im Cluster — der Job hängt also nicht mehr davon ab, dass eine einzelne Maschine am Leben bleibt.

Er regelt auch die Details, die eine normale Crontab dem Zufall überlässt. Eine Concurrency-Policy verhindert, dass ein langsames Backup eine zweite Kopie über sich selbst startet. Fehlgeschlagene Läufe werden eine festgelegte Anzahl von Malen wiederholt. Die letzten erfolgreichen und fehlgeschlagenen Läufe bleiben zur Kontrolle erhalten, und dem Zeitplan kannst du eine feste Zeitzone geben, damit ein Job um 02:00 Uhr bei der Zeitumstellung nicht wandert.

Die ehrliche Grenze: Kubernetes führt den Job aus, ob er etwas Sinnvolles getan hat, ist ihm egal. Ein Backup, das erfolgreich endet, nachdem es eine leere Datei geschrieben hat, ist trotzdem ein erfolgreicher Lauf. Lass dich bei Fehlern alarmieren, prüf das Ergebnis und teste die Wiederherstellung. Für zwei Jobs im Monat auf einem einzigen Server reicht eine Crontab mit einem Ping an einen Uptime-Monitor völlig aus.

7. Build-Maschinen, die nur existieren, solange ein Job läuft

Was sie ersetzen: minutenweise bezahlte gehostete CI-Runner oder einen Build-Server, der die ganze Nacht läuft und noch die Dateien von letzter Woche auf der Platte hat. Der Actions Runner Controller von GitHub betreibt selbst gehostete Runner als Pods: Startet ein Workflow, erscheint ein frischer Runner, erledigt den Job und wird gelöscht. Wenn nichts gebaut wird, kann die Zahl der Runner auf null fallen.

Jeder Build startet aus einem sauberen Image, nichts sickert von einem Job zum nächsten — keine übrig gebliebenen Tokens, kein alter Cache, der einen kaputten Build bestehen lässt. Große Testsuiten können sich auf so viele Runner verteilen, wie der Cluster Platz hat, und die Runner sitzen im selben Netz wie deine Staging-Dienste, was Integrationstests einfach macht.

Die ehrliche Grenze ist die Sicherheit. Ein Runner in deinem Cluster führt jeden Code aus, den der Workflow enthält, er darf also nie Jobs aus Pull Requests von Fremden übernehmen — GitHub selbst rät von selbst gehosteten Runnern bei öffentlichen Repositorys ab. Auch Container-Images in einem Pod zu bauen, braucht Sorgfalt: Der bequeme Weg ist ein privilegierter Container, der dem Build Root-Rechte auf dem Node gibt. Nimm einen Rootless-Builder und halte die Runner in einem eigenen Namespace ohne Zugriff auf die Produktion.

6. Worker, die bei null schlafen und für die Queue aufwachen

Was sie ersetzen: einen Worker-Server, der zweiundzwanzig Stunden am Tag untätig herumsteht, um für zwei bereit zu sein. KEDA, ein Projekt der Cloud Native Computing Foundation, beobachtet eine Queue, eine Datenbanktabelle, einen Zeitplan oder Dutzende anderer Ereignisquellen und skaliert ein Deployment von null Pods auf so viele, wie die Arbeit braucht — und zurück auf null, wenn sie erledigt ist.

Das passt zu jeder Arbeit, die schubweise kommt: Rechnungen, die am Monatsende als PDF erzeugt werden, Produktbilder, die nach einem Import verkleinert werden, tausend E-Mails nach dem Versand eines Newsletters, ein Video, das nach dem Hochladen konvertiert wird. Die Queue füllt sich, die Worker erscheinen, die Queue leert sich, die Worker verschwinden.

Die ehrliche Grenze ist der erste Job im Schub. Läuft gerade nichts, wartet die erste Nachricht, bis ein Pod gestartet ist — normalerweise Sekunden, länger, wenn der Cluster auch noch eine Maschine hinzufügen muss. Und Pods auf null zu skalieren spart nur Geld, wenn auch die Maschinen darunter herunterskalieren, was zusätzlich einen Node-Autoscaler braucht. Auf einem Cluster fester Größe kosten untätige Pods nichts extra, der Gewinn ist vor allem Ordnung.

5. Ein privates KI-Modell, das sich eine teure GPU teilt

Was es ersetzt: eine Grafikkarte, die für ein einziges internes KI-Werkzeug gekauft wurde und den Großteil des Tages untätig ist. NVIDIAs GPU Operator für Kubernetes kann eine GPU auf mehrere Pods aufteilen, entweder per Time-Slicing oder, auf Rechenzentrumskarten, die das unterstützen, durch Aufteilung in isolierte Teile. Mehrere kleine Modelle — eins fasst Dokumente zusammen, eins liest Rechnungen, eins sortiert eingehende Anfragen — können sich dann eine Karte teilen, statt jeweils eine eigene zu brauchen.

Die Daten verlassen nie deine Infrastruktur, und genau deshalb betreibst du Modelle selbst. Der Cluster plant sie wie jede andere Arbeitslast ein: neu gestartet, wenn sie abstürzen, verschoben, wenn ein Node ausfällt. Mit deinen eigenen Dokumenten verbunden, wird daraus die private Version von RAG für Unternehmen.

Die ehrliche Grenze: Time-Slicing teilt die Zeit der GPU, nicht ihren Speicher — ein Modell, das wächst, kann die anderen verdrängen, und ein Fehler in einem kann alle treffen. Echte Isolierung braucht die Hardware-Aufteilung, die nur teure Rechenzentrumskarten bieten. GPU-Maschinen sind außerdem die teuersten Nodes, die ein Cluster haben kann. Für ein Modell, das zehn Leute nutzen, ist ein einzelner GPU-Server, der es in Docker betreibt — Platz fünf in zehn kreative Wege, Docker zu nutzen — einfacher und günstiger.

4. Schwere Batch-Arbeit auf billiger Restkapazität

Was sie ersetzt: den vollen Preis für Rechenleistung, die nur irgendwann da sein muss. Cloud-Anbieter verkaufen ihre ungenutzte Kapazität als Spot-Maschinen mit bis zu 90 % Rabatt, mit einem Haken: Sie können eine Maschine kurzfristig zurückholen — mit zwei Minuten Vorwarnung bei AWS, dreißig Sekunden bei Azure und bei Google Cloud ganz ohne Vorwarnung, wenn du keine anforderst. Mit diesem Haken kommt Kubernetes sehr gut zurecht. Verschwindet ein Spot-Node, werden seine Pods auf andere Maschinen verlegt und fehlgeschlagene Jobs wiederholt.

Gute Kandidaten sind Jobs, die groß und geduldig sind und sich fortsetzen lassen: nächtliche Berichte über ein Jahr Bestellungen, das Neurendern eines Produktkatalogs, die Verarbeitung eines Archivs gescannter Dokumente, das Training oder Feintuning eines Modells, das Checkpoints speichert. Pack sie auf einen Spot-Node-Pool und lass alles andere auf normalen Maschinen.

Die ehrliche Grenze: Dorthin gehört nur Arbeit, die unterbrochen werden darf. Nie die Datenbank, nie der Checkout, nie etwas, worauf ein Kunde wartet. Der Job muss seinen Fortschritt speichern, sonst kostet dich eine zurückgeholte Maschine den ganzen Lauf. Und Spot-Kapazität kann für einen bestimmten Maschinentyp ausgehen — erlaube also mehrere Typen und rechne mit gelegentlichen Verzögerungen.

3. Ein Namespace pro Kunde

Was er ersetzt: einen eigenen Server für jeden Kunden oder jeden Abnehmer eines Softwareprodukts, jeder von Hand eingerichtet und jeder mit der Zeit anders als die übrigen. Ein Kubernetes-Namespace ist ein benannter Bereich eines Clusters. Gib jedem Kunden seinen eigenen, mit einer Ressourcenquote, damit niemand mehr als seinen Anteil verbraucht, mit Network Policies, damit seine Dienste nicht mit denen anderer reden können, und mit eigenen Secrets.

Ein neuer Kunde heißt dann: eine Vorlage anwenden; ein Kunde, der geht: den Namespace löschen, und alles darin ist weg. Das passt zu einer Agentur, die viele Kundenanwendungen hostet, und zu einem Softwareprodukt, das größeren Kunden eine eigene Instanz anbietet. Jeder Kunde läuft auf derselben getesteten Einrichtung, und eine Verbesserung, die einmal gemacht wird, erreicht alle.

Die ehrliche Grenze: Ein Namespace ist eine weiche Wand. Alle Mandanten teilen sich die Control Plane des Clusters und den Kernel der Nodes — was die Kubernetes-Dokumentation Soft Multi-Tenancy nennt, gedacht für Mandanten, die einander vertrauen. Das passt für vertrauenswürdige Kunden, die Code ausführen, den du geschrieben hast; es reicht nicht für Mandanten, die sich gegenseitig angreifen könnten, oder für streng regulierte Daten, die eigene Nodes oder eigene Cluster brauchen. Denk auch daran, dass Kubernetes Secrets standardmäßig unverschlüsselt speichert, solange du keine Verschlüsselung ruhender Daten aktivierst — ein Namespace ändert daran nichts.

2. Ein Notausgang aus deiner Cloud

Was er ersetzt: den Satz „wir kommen da nicht raus“ über einen Cloud-Anbieter, dessen Preise gestiegen sind. Jede zertifizierte Kubernetes-Plattform — die verwalteten Dienste von Amazon, Google und Microsoft, DigitalOcean, europäische Anbieter, ein Cluster auf eigener Hardware — führt dieselben Manifeste auf dieselbe Weise aus. Genau das zertifiziert das Konformitätsprogramm der Cloud Native Computing Foundation, für mehr als 90 Kubernetes-Angebote. Eine Anwendung, die für einen Cluster beschrieben ist, lässt sich in einem Projekt von Wochen auf einen anderen umziehen, nicht durch eine Neuentwicklung.

Der Wert eines Notausgangs liegt darin, dass du ihn selten benutzen musst. Ein glaubwürdiger verändert das Gespräch über den Preis, und er beantwortet die Frage, wo die Daten liegen: Wenn ein Kunde oder eine Vorschrift einen EU-Anbieter verlangt, ist der Umzug eine bekannte Größe statt einer Schätzung.

Die ehrliche Grenze: Die Portabilität gilt für die Container, nicht für die Dienste um sie herum. Eine verwaltete Datenbank, eine Queue, ein Dateispeicher oder das Login-System, die du beim Cloud-Anbieter gekauft hast, sind eine Bindung, die Kubernetes nicht aufhebt, und Load Balancer, Speicher und Berechtigungen werden auf jeder Plattform anders eingerichtet. Halte auch die Datenschicht portabel, sonst geht die Tür nur halb auf. Gleichzeitig auf zwei Clouds zu laufen, ist eine andere und viel teurere Idee — siehe die Liste der Einsätze, die wir weggelassen haben.

1. Die ganze Plattform als Git-Repository

Was sie ersetzt: Änderungen, die von Hand auf einem Live-Server gemacht wurden, von einer Person im Kopf behalten und nirgends aufgeschrieben. Bei GitOps beobachtet ein Werkzeug im Cluster — Argo CD oder Flux, beides Graduated-Projekte der Cloud Native Computing Foundation — ein Git-Repository und hält den Cluster mit ihm identisch. Eine Änderung an der Produktion ist ein Pull Request. Jemand prüft ihn, er wird gemergt, und der Cluster aktualisiert sich selbst.

Sie steht auf Platz eins, weil sie den Betrieb von etwas, das Leute im Kopf haben, in etwas Aufgeschriebenes verwandelt. Jede Änderung hat einen Autor, einen Grund und eine Prüfung — genau den Änderungsnachweis, den ein Auditor sehen will. Zurückrollen heißt, einen Commit rückgängig zu machen. Ein schneller Fix, der direkt im Cluster eingetippt wurde, wird bemerkt und zurückgedreht, das Repository bleibt also die Wahrheit. Und wenn ein Cluster verloren geht, baut ein neuer, der auf dasselbe Repository zeigt, die Anwendungen von selbst wieder auf.

Hier kommen auch mehrere der Einträge oben zusammen. Die Namespaces aus Platz drei, die geplanten Jobs aus Platz acht und die Queue-Worker aus Platz sechs sind alles nur Dateien im Repository, geprüft und versioniert wie Code.

Die ehrlichen Grenzen: Secrets dürfen nicht als Klartext in Git landen, sie brauchen vom ersten Tag an ein verschlüsseltes Format oder einen externen Secret-Speicher. Das Repository wird zum Empfindlichsten, was du besitzt, denn wer darin mergen darf, kontrolliert die Produktion. Und Git beschreibt die Anwendungen, nicht die Daten: Datenbanken und hochgeladene Dateien brauchen weiterhin echte Backups und eine getestete Wiederherstellung.

Fünf, die wir weggelassen haben, und warum

Kubernetes für eine Visitenkarten-Website. Eine Seite mit fünf Unterseiten oder eine WordPress-Seite mit Kontaktformular braucht gutes Hosting, keinen Cluster. Kubernetes fügt bewegliche Teile hinzu, die eine solche Seite nie nutzen wird, und jemand bezahlt für jedes davon.

Kubernetes für drei Container auf einem Server. Docker Compose betreibt eine Handvoll Dienste auf einer Maschine mit einem Bruchteil der Komplexität. Steig um, wenn du wirklich mehrere Maschinen, automatische Skalierung oder unabhängige Teams brauchst — nicht, wenn ein Konferenzvortrag sagt, dass du sie brauchen wirst.

Eine von Hand gebaute Control Plane für die Produktion. Einen Cluster von Grund auf zusammenzusetzen, ist eine hervorragende Art zu lernen und eine schlechte Art, ein Geschäft zu führen. Nimm einen verwalteten Dienst oder k3s für kleine Installationen und steck die Zeit in die Anwendungen.

Die Produktionsdatenbank im Cluster, ohne jemanden, der sie dort betreiben kann. Datenbanken können auf Kubernetes gut laufen, mit einem Operator, der Replikate, Backups und Updates übernimmt. Ohne jemanden, der diesen Operator versteht, ist eine verwaltete Datenbank meist günstiger, sobald du die Stunden mitrechnest.

Multi-Cloud als Selbstzweck. Dieselbe Anwendung gleichzeitig auf zwei Clouds zu betreiben, verdoppelt den Betriebsaufwand für ein Maß an Ausfallsicherheit, das die meisten Firmen nie brauchen. Platz zwei handelt davon, die Option zum Gehen zu behalten, nicht dauerhaft an zwei Orten zu wohnen.

Was das alles kostet

Kubernetes selbst ist Open Source und kostenlos. Die Kosten sind die Maschinen, die Control Plane und vor allem die Menschen.

Bei der Control Plane unterscheiden sich die verwalteten Dienste. Amazon EKS berechnet 0,10 Dollar pro Stunde und Cluster, rund 73 Dollar im Monat. Google GKE verlangt dieselbe Gebühr, gibt jedem Abrechnungskonto aber ein monatliches Guthaben, das einen zonalen oder Autopilot-Cluster abdeckt. Azure AKS hat eine kostenlose Stufe ohne Verfügbarkeitsgarantie und eine Standard-Stufe für 0,10 Dollar pro Stunde, und DigitalOcean berechnet für die Control Plane gar nichts. Dazu kommen die Nodes — meist mindestens drei, damit der Verlust von einem kein Ausfall ist — sowie die Load Balancer und der Speicher, den sie nutzen.

Der größte Posten ist Aufmerksamkeit. Ein Cluster muss etwa dreimal im Jahr aktualisiert werden, um auf einer unterstützten Version zu bleiben, und ein Cluster, den niemand aktualisiert, fällt nach gut einem Jahr aus dem Support; auf EKS kostet das Verbleiben auf einer alten Version dann 0,60 Dollar pro Stunde statt 0,10. Jemand muss für Updates, Monitoring, Sicherheitspatches und Backups zuständig sein. An dieser Stelle, nicht bei der Hosting-Rechnung, fällt die Entscheidung für Kubernetes wirklich — also triff sie bewusst.

Wenn du nur einen ausprobierst

Probier Platz zehn aus, auch wenn du Kubernetes nie in Produktion bringst. Ein Abend mit k3s auf zwei alten Rechnern zeigt dir die Idee hinter allen anderen Einträgen: Du beschreibst, was laufen soll, und der Cluster hält es so, wenn etwas kaputtgeht.

Danach kommt es darauf an, wo du stehst. Läuft dein Geschäft auf einem oder zwei Servern, brauchst du Kubernetes wahrscheinlich noch nicht — die Self-Hosting-Ideen aus zehn kreative Wege, Docker zu nutzen bringen dir mehr. Betreibst du schon einen Cluster, nimm dir Platz eins vor. Das ist der Eintrag, dessen Nutzen mit jedem Monat wächst, den er im Einsatz ist.

Und wenn du es lieber einrichten lässt: Unsere Arbeit mit Docker reicht von Compose auf einem einzelnen Server bis zu Kubernetes, wenn eine Anwendung darüber hinausgewachsen ist, und Node.js-Hosting und Monitoring hält es danach am Laufen. Erzähl uns, was heute wo läuft, und wir sagen dir ehrlich, ob Kubernetes helfen würde — auch dann, wenn die Antwort lautet, dass du es nicht brauchst.

Quellen

Jede Aussage zu Produkten, Preisen und Support oben stammt von den öffentlichen Seiten des jeweiligen Projekts oder Anbieters, geprüft im Oktober 2026. Preise und Supportbedingungen ändern sich, prüf sie also, bevor du dich festlegst.

• Kubernetes-Dokumentation — Overview ↗

  Definiert Kubernetes als portable, erweiterbare Open-Source-Plattform für die Verwaltung containerisierter Arbeitslasten und Dienste. Der Name ist griechisch für Steuermann oder Pilot, K8s zählt die acht Buchstaben zwischen K und s, und Google hat das Projekt 2014 als Open Source veröffentlicht.

• Kubernetes-Blog — 10 years of Kubernetes ↗

  Der erste Commit kam am 6. Juni 2014, Version 1.0 am 21. Juli 2015, als Google ankündigte, Kubernetes an die neu gegründete Cloud Native Computing Foundation zu spenden. Im März 2018 wurde es deren erstes Graduated-Projekt.

• Kubernetes — Patch releases ↗

  Minor-Versionen erscheinen etwa dreimal im Jahr und erhalten rund vierzehn Monate Support: zwölf Monate Standard-Support, danach zwei Monate im Wartungsmodus. Version 1.37 erschien am 26. August 2026.

• Kubernetes-Blog — Dockershim removal FAQ ↗

  Kubernetes 1.24 hat den dockershim entfernt; mit docker build erzeugte Images funktionieren mit allen CRI-Implementierungen wie containerd und CRI-O.

• CNCF — Annual Cloud Native Survey 2025 ↗

  Veröffentlicht im Januar 2026: 82 % der Container-Nutzer betreiben Kubernetes in Produktion, gegenüber 66 % im Jahr 2023.

• Stack Overflow — 2025 Developer Survey, Technology ↗

  Unter allen Befragten nutzten 2025 71,1 % Docker und 28,5 % Kubernetes.

• Kubernetes-Dokumentation — Multi-tenancy ↗

  Beschreibt Namespaces, Ressourcenquoten und Network Policies als Bausteine für die gemeinsame Nutzung eines Clusters und unterscheidet Soft Multi-Tenancy zwischen vertrauenswürdigen Mandanten von Hard Multi-Tenancy zwischen Mandanten, die einander nicht vertrauen.

• Kubernetes-Dokumentation — Secrets ↗

  Secrets werden standardmäßig unverschlüsselt im Datenspeicher des API-Servers (etcd) abgelegt; die Verschlüsselung ruhender Daten muss separat aktiviert werden.

• Kubernetes-Dokumentation — CronJob ↗

  Behandelt die Concurrency-Policy (Allow, Forbid, Replace), die Grenzen für den Job-Verlauf und das Feld für die Zeitzone.

• K3s — Requirements ↗

  Eine zertifizierte Kubernetes-Distribution und ein Sandbox-Projekt der Cloud Native Computing Foundation, die auf x86 und ARM läuft, auch auf dem Raspberry Pi. Minimum: 2 CPU-Kerne und 2 GB Arbeitsspeicher für einen Server-Node, 1 Kern und 512 MB für einen Agent; auf dem Raspberry Pi wird eine SSD empfohlen.

• Chaos Mesh ↗

  Eine Chaos-Engineering-Plattform für Kubernetes, die Fehler an Pods, Netzwerk, Festplatten und Nodes auslöst; wie LitmusChaos ein Incubating-Projekt der Cloud Native Computing Foundation.

• GitHub Docs — Actions Runner Controller ↗

  Ein Kubernetes-Operator, der selbst gehostete Runner für GitHub Actions orchestriert und skaliert; Runner Scale Sets können auf null Runner herunterskalieren.

• GitHub Docs — Sicherheit selbst gehosteter Runner ↗

  Empfiehlt selbst gehostete Runner nur für private Repositorys, weil Forks eines öffentlichen Repositorys über Pull Requests Code auf ihnen ausführen können.

• KEDA ↗

  Ereignisgesteuertes Autoscaling für Kubernetes: skaliert Arbeitslasten von und auf null anhand von Queues, Datenbanken, Zeitplänen und über 70 weiteren eingebauten Ereignisquellen; seit 2020 ein Projekt der Cloud Native Computing Foundation, seit August 2023 Graduated.

• NVIDIA — GPU Operator, Time-Slicing ↗

  Time-Slicing lässt mehrere Pods eine GPU teilen, bietet aber keine Speicher- oder Fehlerisolierung zwischen ihnen; Multi-Instance GPU (MIG) teilt unterstützte Rechenzentrums-GPUs in isolierte Instanzen.

• AWS — EC2 Spot Instances ↗

  Freie EC2-Kapazität mit bis zu 90 % Rabatt auf On-Demand-Preise, zurückholbar mit zwei Minuten Vorwarnung.

• Google Cloud — Spot VMs ↗

  Spot-VMs kosten bis zu 91 % weniger als Standard-VMs. Eine Vorwarnung vor dem Entzug ist optional — standardmäßig keine, oder 120 Sekunden, wenn konfiguriert — und das anschließende Herunterfahren dauert bis zu 30 Sekunden.

• Microsoft Learn — Azure Spot Virtual Machines ↗

  Spot-VMs nutzen freie Azure-Kapazität mit bis zu 90 % Rabatt und können mit 30 Sekunden Vorwarnung entzogen werden.

• Argo CD ↗

  Ein deklaratives GitOps-Werkzeug für Continuous Delivery auf Kubernetes, das den Clusterzustand mit einem Git-Repository synchron hält; Teil des Argo-Projekts, seit Dezember 2022 Graduated in der Cloud Native Computing Foundation.

• Flux ↗

  Ein GitOps-Toolkit, das Cluster mit Git-Repositorys und anderen Quellen abgleicht; seit November 2022 Graduated in der Cloud Native Computing Foundation.

• CNCF — Certified Kubernetes Software Conformance ↗

  Listet über 90 zertifizierte Kubernetes-Angebote; Konformität heißt, dass sich dieselben APIs gleich verhalten, sodass Arbeitslasten von einer zertifizierten Installation zur nächsten umziehen können.

• Amazon EKS — Pricing ↗

  0,10 Dollar pro Cluster und Stunde, solange die Kubernetes-Version im Standard-Support ist, und 0,60 Dollar pro Cluster und Stunde im Extended Support.

• Google Kubernetes Engine — Pricing ↗

  Eine Verwaltungsgebühr von 0,10 Dollar pro Cluster und Stunde, mit einem kostenlosen Guthaben von 74,40 Dollar im Monat pro Abrechnungskonto, nutzbar für zonale und Autopilot-Cluster.

• Azure Kubernetes Service — Pricing ↗

  Die Free-Stufe berechnet keine Control Plane und hat kein Verfügbarkeits-SLA; die Standard-Stufe kostet 0,10 Dollar pro Cluster und Stunde (Azure-Preisliste, East US).

• DigitalOcean Kubernetes — Pricing ↗

  Keine Gebühr für die Control Plane; die hochverfügbare Control Plane kostet 40 Dollar im Monat.