Mittwochnachmittag, Videokonferenz. Eine CTO aus München sitzt mit ihrem dreiköpfigen Entwicklerteam zusammen, HealthTech-Startup, Plattform für Arztpraxis-Verwaltung. Ihr System läuft auf einem einzelnen Hetzner-Server. Erste Kunden sind zufrieden, aber die Anforderung an Verfügbarkeit wächst. Arztpraxen brauchen ihr System zwischen sieben und 19 Uhr, ohne Ausnahme. Ein einzelner Server ist ein Ausfallrisiko.
Auf dem Tisch liegt die Frage: Kubernetes oder etwas Einfacheres? Ihr Senior-Entwickler schwärmt von Helm Charts und ArgoCD. Sie rechnet: Drei Monate Einarbeitungszeit für das Team, zusätzliche Infrastrukturkosten, ein Ops-Overhead, der das kleine Team überfordern könnte. Zwischen Docker Swarm, K3s und vollständigem Kubernetes zu wählen ist keine rein technische Frage. Sie hängt am Team, am Budget und an der Wachstumsperspektive.
Dieser dritte Teil der Serie vergleicht die drei Werkzeuge anhand konkreter Kriterien: Lernkurve, Betriebsaufwand, Kosten und Skalierungsfähigkeit. Am Ende steht eine Entscheidungsmatrix, die Teamgröße, Erfahrung und Infrastrukturbedarf zusammenführt.
Docker Swarm: Totgesagt, aber quicklebendig
Docker Swarm hat den Ruf, veraltet zu sein. Kubernetes hat den Markt gewonnen, Swarm ist Geschichte. So die gängige Erzählung. Sie stimmt nicht.
Mirantis, das Unternehmen, das 2019 die Docker-Enterprise-Sparte übernahm, hat sich bis 2030 zur Pflege und Weiterentwicklung von Docker Swarm verpflichtet, und Sicherheitsupdates erscheinen zuverlässig im Sechs-Wochen-Rhythmus. Swarm ist Teil der Docker Engine und damit auf jedem Server mit Docker vorinstalliert, ohne zusätzliche Software und ohne separaten Installationsprozess. Ein docker swarm init auf dem ersten Server, ein docker swarm join auf den weiteren Knoten. Nach zwei Minuten steht ein Cluster.
Swarm glänzt durch seine Nähe zu Docker Compose. Ein Compose-File, das lokal funktioniert, lässt sich mit minimalen Änderungen als Swarm-Stack deployen. Der Befehl docker stack deploy nimmt das gleiche YAML-Format entgegen. Zwischen den Nodes spannt Swarm automatisch ein verschlüsseltes Overlay-Netzwerk auf (per VXLAN), Service Discovery funktioniert über DNS, Rolling Updates sind eingebaut. Jeder Entwickler, der Docker Compose beherrscht, kommt mit Swarm in einem halben Tag zurecht.
Swarms versteckte Stärken
Swarm bringt einiges mit, das in der öffentlichen Wahrnehmung untergeht. Der integrierte Load Balancer verteilt eingehende Anfragen automatisch auf alle Replicas eines Services. Ein Dienst mit drei Replicas bekommt drei Container auf verschiedenen Nodes, und der Ingress-Load-Balancer leitet Traffic an den nächsten gesunden Container weiter.
Rolling Updates lassen sich granular steuern: Wie viele Container gleichzeitig aktualisiert werden, wie lange zwischen den Schritten gewartet wird und ob bei einem Fehler automatisch zurückgerollt wird, bestimmt das Team über einfache Parameter im Compose-File. Für Teams, die bisher manuell per SSH deployt haben, ist das ein enormer Sprung. Secrets Management ist ebenfalls eingebaut: Datenbank-Passwörter und API-Keys werden verschlüsselt im Raft-Konsensus der Manager-Nodes gespeichert und nur den Containern bereitgestellt, die sie tatsächlich benötigen.
Für Teams mit weniger als zehn Nodes und Diensten, die keine komplexe Autoskalierung brauchen, ist Swarm eine ernsthafte Option. Health Checks überwachen Container und starten sie bei Fehlern automatisch neu. Node-Ausfälle erkennt Swarm selbstständig und verschiebt Container auf gesunde Knoten. Besonders glänzt Swarm bei Anwendungen, die aus einer Handvoll langlebiger Dienste bestehen und selten ändern: ein Webserver, eine API, eine Datenbank, vielleicht ein Worker für Hintergrundjobs. Solche Stacks profitieren kaum von Kubernetes-Features wie HPA oder Service Mesh, würden aber unter dem zusätzlichen Konfigurationsaufwand leiden. Einfachheit ist kein Makel. Docker Swarm ist die richtige Wahl für mehr Teams, als die Kubernetes-Community zugeben will.
Wo stößt Swarm an seine Grenzen?
Bei komplexeren Anforderungen zeigen sich Grenzen, die sich auch mit Workarounds nicht beseitigen lassen. Swarm bietet keine native Autoskalierung, und es gibt keinen eingebauten Ingress Controller mit der Flexibilität eines Kubernetes-Ingress, der pfadbasiertes Routing und TLS-Termination ohne zusätzliche Software beherrscht. An Erweiterungen und Werkzeugen ist das Angebot klein im Vergleich zu Kubernetes. Monitoring muss komplett selbst aufgesetzt werden, während bei Kubernetes Prometheus und Grafana per Helm Chart in Minuten laufen.
Schwerer wiegt: Die Community schrumpft. Neue Blog-Artikel, Tutorials und Stack-Overflow-Antworten zu Swarm werden seltener, und bei obskuren Fehlern dauert die Problemlösung länger, weil weniger Leute die gleichen Probleme haben und dokumentieren. Das ist kein Todessignal, aber ein Faktor, den jedes Team in seine Entscheidung einbeziehen sollte.
Stirbt Docker Swarm wirklich?
Nein, aber es wird stiller. Mirantis pflegt Swarm als Teil von Mirantis Kubernetes Engine (MKE), die parallel Swarm- und Kubernetes-Workloads unterstützt, was Unternehmen einen schrittweisen Übergang ermöglicht, ohne bestehende Deployments sofort umstellen zu müssen. Sicherheitszertifizierungen wie FIPS 140-2 und DISA STIG zeigen, dass auch regulierte Branchen Swarm weiterhin einsetzen.
Realistisch betrachtet: Swarm bekommt keine spektakulären neuen Features mehr. Es bleibt stabil, sicher und funktional. Kein bestehendes Swarm-Setup hat Grund zur Panik. Es läuft. Es wird weiterlaufen. Aber für ein neues Projekt, das absehbar über zehn Nodes hinauswachsen wird, fährt K3s langfristig besser. K3s ist Kubernetes-kompatibel und macht eine spätere Migration überflüssig.
Kubernetes: Die Macht und ihr Preis
Kubernetes ist der Industriestandard für Container-Orchestrierung, und laut der CNCF-Umfrage von 2025 nutzen 82 Prozent der befragten Organisationen Kubernetes in der Produktion. An Werkzeugen mangelt es nicht: Helm für Paketmanagement, ArgoCD für GitOps, Prometheus für Monitoring, Istio und Cilium für Service Mesh, cert-manager für Zertifikate. Für fast jedes Problem existiert eine Kubernetes-native Lösung, die von einer aktiven Community gepflegt und dokumentiert wird.
Diese Mächtigkeit hat ihren Preis. Jeder Kubernetes-Cluster besteht aus Control-Plane-Knoten und Worker-Knoten. Über die Control Plane wird der Zustand des Clusters verwaltet: welche Pods laufen auf welchem Node, welche Services sind erreichbar, welche Konfigurationen gelten. Dafür braucht es etcd als verteilten Key-Value-Store, den API-Server, den Scheduler und den Controller Manager. Vier Komponenten, nur für die Verwaltung.
Wann braucht ein Team tatsächlich Kubernetes?
Für ein Team mit 50 Microservices, Auto-skalierung basierend auf CPU-Last, Blue-Green-Deployments und Multi-Region-Verteilung ist Kubernetes ohne Alternative. Genau für diese Szenarien wurde es entwickelt.
Aber die meisten Teams haben nicht 50 Microservices. Sie haben vier bis acht Container und wollen, dass ihr Stack auf drei Servern zuverlässig läuft. Für diese Teams ist vollständiges Kubernetes wie ein Sattelschlepper für den Wocheneinkauf: technisch möglich, praktisch absurd.
Ein dedizierter Kubernetes-Administrator kostet in der DACH-Region zwischen 60.000 und 85.000 Euro Jahresgehalt. Für ein Fünfpersonen-Team ist das ein signifikanter Anteil des Budgets für eine Aufgabe, die bei drei Servern mit K3s oder Swarm in einem Bruchteil der Zeit gelöst wäre. Hinzu kommt die Lernkurve: Drei bis sechs Monate dauert es, bis ein Entwickler Kubernetes bedienen und vor allem debuggen kann.
RBAC-Policies, NetworkPolicies, PodSecurityAdmission, ResourceQuotas: Die Liste der Konzepte, die verstanden werden müssen, ist lang. Jedes davon kann bei falscher Konfiguration den gesamten Cluster lahmlegen. Besonders Ops-Teams, die bisher klassische Linux-Administration betrieben haben, unterschätzen den Paradigmenwechsel: Statt einzelne Server zu pflegen, verwalten sie deklarative Zustände in YAML-Dateien, und bei Problemen führt der Debugging-Pfad durch mehrere Abstraktionsschichten (Pod, ReplicaSet, Deployment, Service, Ingress), die alle eigene Fehlerquellen mitbringen. Jede Schicht ein potenzielles Loch.
Resume-Driven Development treibt Teams zu Kubernetes, bevor sie es brauchen. Kubernetes im Lebenslauf sieht besser aus als Docker Swarm. Leidtragend sind am Ende Budgets und Liefergeschwindigkeit. Startups mit ihren ersten 1.000 Kunden profitieren mehr von einem stabilen, einfachen Setup als von einer Plattform, die für Millionen Nutzer ausgelegt ist. Realistisch betrachtet dürfte mindestens die Hälfte aller Kubernetes-Installationen in KMUs mit K3s oder Swarm besser bedient sein.
Die versteckte Komplexität
Kubernetes-Komplexität zeigt sich oft erst im laufenden Betrieb, wenn der Cluster seit Wochen produktiv arbeitet und die ersten Wartungsaufgaben anstehen. Das Aufsetzen ist mit den richtigen Werkzeugen (kubeadm, kOps, Rancher) an einem Tag erledigt. Probleme zeigen sich danach. Der Aufwand endet nicht mit dem Setup. Zertifikate für die interne Kommunikation laufen ab und müssen rotiert werden, etcd braucht regelmäßige Backups und Überwachung der Cluster-Gesundheit. Kubernetes-Versionen müssen alle vier Monate aktualisiert werden, weil ältere Versionen nach 14 Monaten aus dem Support fallen.
Noch ein Punkt, den Kubernetes-Enthusiasten gern verschweigen: Die YAML-Dateien. Jeder Microservice braucht ein Deployment, einen Service, einen Ingress, eine ConfigMap, ein Secret, optional ein HorizontalPodAutoscaler und PodDisruptionBudget. Sieben YAML-Dateien für einen einzigen Dienst. Bei 15 Diensten sind das über 100 Dateien, die gepflegt, versioniert und synchron gehalten werden müssen. Helm und Kustomize mildern das Problem, eliminieren es aber nicht.
Managed Kubernetes (EKS, GKE, AKS) nimmt einen Teil dieser Arbeit ab, verlagert sie aber auf die Cloud-Rechnung. AWS EKS allein kostet 73 Dollar pro Monat und Cluster, ohne einen einzigen Container gestartet zu haben. Hinzu kommen Worker-Nodes, Load Balancer, Persistent Volumes und Traffic-Kosten, die sich bei wachsendem Datenvolumen schnell zu einer überraschend hohen Monatsrechnung summieren können. Kubernetes bleibt aufwendig, egal ob managed oder self-hosted, und wer den Aufwand scheut, aber Kubernetes-Kompatibilität braucht, landet fast zwangsläufig bei K3s.
Es gibt berechtigte Gründe für Kubernetes. Teams, die von Anfang an wissen, dass ihr Projekt innerhalb eines Jahres auf 20 oder mehr Dienste wachsen wird, sparen sich die spätere Migration. Regulierte Branchen (Banken, Gesundheitswesen) finden bei Kubernetes das breitere Werkzeugangebot für Compliance. Und Teams mit vorhandener Kubernetes-Erfahrung verlieren den größten Nachteil: die Lernkurve.
K3s: Kubernetes ohne den Ballast
K3s ist die Antwort auf die Frage: Was bleibt übrig, wenn man Kubernetes auf das Wesentliche reduziert? Entwickelt von Rancher Labs (heute Teil von SUSE), verpackt K3s einen vollständigen Kubernetes-Cluster in eine einzige Binärdatei unter 70 MB. Installiert ist alles in unter einer Minute.
Wichtigster Unterschied: K3s verwendet SQLite statt etcd als Datenspeicher. etcd ist ein verteilter Key-Value-Store, der für Hochverfügbarkeits-Cluster mit Dutzenden Nodes konzipiert ist. Für drei bis fünf Nodes ist etcd überdimensioniert. SQLite ist leichtgewichtig, braucht wenig RAM und reicht für Cluster dieser Größe völlig aus. Später auf etcd oder eine externe PostgreSQL-Datenbank umzusteigen, ist ohne Neuinstallation möglich.
Wie sieht ein K3s-Setup in der Praxis aus?
Drei Hetzner-VPS (CX33 mit vier vCPUs und 8 GB RAM, je 5,49 Euro pro Monat) reichen für einen produktionsreifen K3s-Cluster. Auf dem ersten Server läuft das Installationsskript: Eine Zeile curl, fertig. Beide weiteren Server treten dem Cluster mit einem Token bei, den der erste Server generiert hat. Nach zehn Minuten steht ein hochverfügbarer Cluster mit drei Knoten.
K3s bringt Traefik als Ingress Controller standardmäßig mit. TLS-Zertifikate per Let’s Encrypt lassen sich mit cert-manager automatisieren. Helm Charts funktionieren genauso wie auf vollständigem Kubernetes. Prometheus, Grafana, Loki für Logging, ArgoCD für GitOps: Das gesamte Kubernetes-Umfeld steht zur Verfügung, ohne Einschränkung. Bei Swarm fehlt diese Vielfalt.
K3s auf drei bis fünf Hetzner VPS ist für Startups und kleine bis mittlere Unternehmen im DACH-Raum der pragmatischste Weg zu produktionsreifer Container-Orchestrierung. Konfiguriert ist alles an einem Nachmittag statt in einer Woche. Monatlich fallen unter 50 Euro an. Bei AWS mit EKS kostet das gleiche Setup das Fünf- bis Siebenfache.
Schlanker als Standard-Kubernetes
K3s streicht alles, was für Self-Hosted-Setups unnötig ist: Cloud-Controller für AWS, Azure und GCP, Legacy-APIs aus früheren Kubernetes-Versionen, Storage-Treiber, die nur bei großen Cloud-Providern relevant sind. RAM-Verbrauch und Angriffsfläche sinken dadurch erheblich.
Ein K3s-Server braucht mindestens 2 GB RAM, ein Agent kommt mit 512 MB aus. Zum Vergleich: Ein vollständiges Kubernetes verlangt mindestens 2 GB pro Knoten für die Control Plane allein. Auf einem Server mit 8 GB RAM lässt K3s deutlich mehr Platz für die eigentlichen Anwendungen.
Manche Teams fürchten, dass K3s bei größeren Installationen nicht mithält. Diese Sorge ist in den meisten Fällen unbegründet. K3s ist CNCF-zertifiziert und besteht die gleichen Konformitätstests wie vollständiges Kubernetes. Cluster mit 50 und mehr Nodes laufen produktiv auf K3s. Chick-fil-A betreibt in über 3.000 Filialen jeweils einen eigenen K3s-Cluster auf Intel-NUC-Hardware, der Fritteusen, Grills und Bestelltablets steuert und Milliarden von IoT-Nachrichten pro Monat verarbeitet. Die Grenze liegt weniger bei K3s selbst als beim verwendeten Datenspeicher: SQLite ist auf Einzelserver-Setups beschränkt, aber ab dieser Größe wechselt man ohnehin auf etcd oder PostgreSQL.
K3s, MicroK8s oder K0s?
Neben K3s existieren zwei weitere leichtgewichtige Kubernetes-Distributionen. MicroK8s von Canonical wird als Snap-Paket installiert und bietet automatische Updates, ein Add-on-System und Integration mit der Ubuntu-Infrastruktur. K0s von Mirantis bleibt besonders nah am Upstream-Kubernetes und eignet sich für Teams, die möglichst wenig Anpassungen am Standard wollen.
MicroK8s ist die bessere Wahl, wenn das gesamte Team Ubuntu nutzt und Snap-Pakete kein Problem darstellen, weil sich Updates dann automatisch im Hintergrund einspielen und das Add-on-System Dienste wie Istio oder GPU-Unterstützung mit einem einzigen Befehl aktiviert. In allen anderen Fällen gewinnt K3s durch seine Distributionsunabhängigkeit und den geringeren Ressourcenverbrauch. K0s spricht Teams an, die Upstream-Treue höher gewichten als ein vorkonfiguriertes Setup. In der Praxis greift die Mehrheit zu K3s, weil Traefik, CoreDNS und ein lokaler Storage Provider ab Werk mitlaufen.
Welches Werkzeug passt zu welchem Profil?
Bei der Wahl des Orchestrierungswerkzeugs spielen drei Faktoren zusammen: Teamgröße und Kubernetes-Erfahrung, Anzahl der Services und Nodes sowie Anforderungen an Autoskalierung und Hochverfügbarkeit. Folgende Matrix stellt Docker Swarm, K3s und vollständiges Kubernetes anhand konkreter Kriterien gegenüber.
Das Muster ist deutlich. Für die Mehrheit der Teams im DACH-Raum (fünf bis 15 Entwickler, ein bis drei Dutzend Container, Self-Hosted-Infrastruktur) ist K3s der Sweet Spot. Kleinere Teams mit zwei bis fünf Entwicklern fahren mit Docker Swarm oft besser, weil die Lernkurve flacher ausfällt und die Compose-Kenntnisse direkt übertragbar sind. Vollständiges Kubernetes rechtfertigt seinen Aufwand erst ab 15 Personen oder einem dedizierten Ops-Team, eine Größe, die die meisten KMUs nie erreichen.
Nomad und andere Alternativen
HashiCorp Nomad verdient eine Erwähnung. Nomad ist ein Orchestrierer, der ein eigenes Modell nutzt statt auf Kubernetes aufzubauen. Der Vorteil: Nomad verwaltet Container, aber auch herkömmliche Anwendungen, Java-JARs und Batch-Jobs unter einer Oberfläche. Für Teams mit gemischten Workloads (Container plus Legacy-Anwendungen) ist Nomad eine Überlegung wert.
In der Praxis scheitert Nomad im DACH-Raum an einem banalen Problem: Fachkräfte. Das klingt trivial, wiegt aber schwer. Allein auf LinkedIn sind aktuell über 1.000 Stellen in Deutschland ausgeschrieben, die Kubernetes-Erfahrung verlangen, während Nomad-Erfahrung eine Nische bleibt, die bei der Personalsuche zum Engpass werden kann. Für reine Container-Setups bietet Nomad keinen Vorteil gegenüber K3s, bringt aber das Risiko mit, auf ein kleineres Umfeld zu setzen. Seit der Lizenzänderung von HashiCorp auf BSL (Business Source License) im August 2023 ist die Verunsicherung in der Community zusätzlich gewachsen, und OpenTofu als Terraform-Fork zeigt, dass die Community nicht bereit ist, solche Entscheidungen hinzunehmen.
Mein Rat: Nomad nur dann in Betracht ziehen, wenn Legacy-Workloads (nicht containerisierte Anwendungen) neben Containern laufen müssen und eine Migration auf Container kurzfristig ausgeschlossen ist. In allen anderen Fällen ist K3s der sicherere Weg.
Von Swarm zu K3s: Lohnt sich die Migration?
Viele Teams stehen vor einer konkreten Frage: Ihr bestehendes Swarm-Setup läuft, aber die Zukunft ist unklar. Lohnt sich jetzt der Umstieg auf K3s?
Ehrliche Antwort: Nicht immer. Solange Swarm die Anforderungen erfüllt und das Team keine Kubernetes-spezifischen Features braucht (Autoskalierung, HPA, Service Mesh, fortgeschrittenes RBAC), gibt es keinen zwingenden Grund für eine Migration, die Entwicklungszeit kostet und Risiken in den laufenden Betrieb trägt. Mirantis pflegt Swarm bis 2030. Das sind noch vier Jahre. Genug Zeit, um eine Migration sorgfältig zu planen, statt sie zu überstürzen.
Anders sieht es aus, wenn das Projekt wächst. Sobald die Zahl der Dienste zweistellig wird oder Anforderungen wie automatische Skalierung, rollenbasierte Zugriffskontrolle und Zertifikatsmanagement per GitOps hinzukommen, strapaziert Swarm seine Grenzen. Dann lohnt sich der Umstieg, und K3s macht ihn vergleichsweise schmerzlos. Container-Images ändern sich nicht. Compose-Files müssen in Kubernetes-Manifeste übersetzt werden (Kompose hilft dabei als Ausgangspunkt), aber die Grundarchitektur bleibt bestehen.
Der typische Migrationspfad: Erst K3s parallel zum bestehenden Swarm aufsetzen. Einen einzelnen, unkritischen Dienst migrieren, Erfahrungen sammeln, Tooling aufbauen. Dann schrittweise weitere Dienste umziehen, bis Swarm leer ist. Dieser Ansatz dauert Wochen statt Monate und vermeidet den gefürchteten Big-Bang-Umstieg, bei dem am Wochenende alles gleichzeitig migriert wird und am Montag nichts funktioniert.
Drei Stolperfallen tauchen bei fast jeder Migration auf. Erstens: Swarm-Volumes lassen sich nicht direkt in Kubernetes PersistentVolumes überführen, weil beide Systeme unterschiedliche Speicherabstraktionen nutzen, sodass Datenbanken und andere zustandsbehaftete Dienste eine eigene Migrationsstrategie brauchen (Export, Neuanlage, Import). Zweitens: Swarm-Secrets werden anders verwaltet als Kubernetes-Secrets, und ein automatischer Transfer existiert nicht. Das Team muss alle Zugangsdaten manuell in die neue Umgebung einpflegen und dabei prüfen, ob die Berechtigungen noch stimmen. Drittens: Netzwerk-Konfigurationen. Swarm-Overlay-Netzwerke und Kubernetes-NetworkPolicies folgen grundlegend verschiedenen Modellen, und wer seine Firewall-Regeln nicht sauber übersetzt, öffnet im schlimmsten Fall Ports, die geschlossen bleiben sollten.
Fazit und Ausblick
Unabhängig vom gewählten Werkzeug gilt: Automatisierung des Deployments hat Vorrang vor fortgeschrittenen Cluster-Features. Ein Team, das seinen CI/CD-Prozess nicht im Griff hat, wird auch mit dem besten Orchestrierer Probleme bekommen. Erst die Pipeline stabilisieren, dann den Cluster erweitern. In dieser Reihenfolge.
Orchestrierung ist eine Frage der Ehrlichkeit gegenüber dem eigenen Team und dem eigenen Projekt. Wie groß ist das Team wirklich, und wie viele Services laufen tatsächlich? Wachstum über zehn Nodes hinaus in den nächsten zwei Jahren muss realistisch eingeschätzt werden, nicht optimistisch herbeigewünscht. Antworten auf diese Fragen bestimmen das Werkzeug, nicht der Hype. Ich habe zu viele Teams gesehen, die sich Kubernetes aufbürden und ein Jahr später feststellen, dass drei Viertel der Features ungenutzt bleiben.
Für das Münchner HealthTech-Startup aus der Einleitung wäre K3s auf drei Hetzner-Servern die richtige Wahl. Klein genug, um an einem Nachmittag eingerichtet zu werden. Mächtig genug, um Hochverfügbarkeit, automatische Zertifikatsverwaltung und Rolling Updates zu liefern. Und kompatibel mit dem Kubernetes-Werkzeugangebot, falls das Projekt wächst. Drei Server, unter 50 Euro im Monat, kein Vendor Lock-in. Als ersten Schritt vor jeder Werkzeugentscheidung lohnt ein Proof-of-Concept am Wochenende mit dem Favoriten.
Nach der Werkzeugfrage bleibt die Kostenfrage. Ein K3s-Cluster auf drei Hetzner-Servern kostet unter 50 Euro im Monat. Bei AWS mit EKS kostet das gleiche Setup das Fünf- bis Siebenfache. Teil 4 rechnet durch, was Self-Hosted-Infrastruktur bei deutschen Anbietern im Vergleich zu den Hyperscalern tatsächlich kostet, wo versteckte Kosten lauern und wann sich der Cloud-Aufpreis lohnt.
Quellenverzeichnis
- CNCF Annual Survey 2025: „Kubernetes Established as the De Facto Operating System for AI“, Cloud Native Computing Foundation, Januar 2026
- Mirantis: „Mirantis Commits to Long-Term Support for Swarm Through 2030“, mirantis.com/blog, Juli 2025
- Mirantis: „Docker Swarm Still Thriving Three Years After Mirantis Acquisition“, mirantis.com, 2022
- K3s: Lightweight Kubernetes, k3s.io (Stand: Februar 2026)
- Canonical: MicroK8s Documentation, microk8s.io (Stand: Februar 2026)
- Mirantis: K0s Documentation, k0sproject.io (Stand: Februar 2026)
- Wallarm: „K3s vs MicroK8s: Lightweight Kubernetes Distributions“, wallarm.com/blog, 2025
- Portainer: „Docker Swarm vs Kubernetes: Which Should You Use in 2026?“, portainer.io/blog, 2026
- HashiCorp: Nomad Documentation, nomadproject.io (Stand: Februar 2026)
- HashiCorp: „HashiCorp adopts Business Source License“, hashicorp.com/blog, August 2023
- Spacelift: „15 Most Useful Container Orchestration Tools in 2026“, spacelift.io/blog, 2026
- Hetzner Online GmbH: Cloud Server Preisliste, hetzner.com/cloud (Stand: Februar 2026)
- Brian Chambers: „Enterprise Restaurant Compute“, Chick-fil-A Tech Blog (Medium), 2021