Kubernetes vs Docker
Docker und Kubernetes schliessen sich nicht aus. Auf die Frage «welches von beiden?» lautet die Antwort deshalb meistens «beides» oder «nur Docker». Docker baut Container-Images und startet Container auf einem Host. Kubernetes verteilt Container über viele Hosts und hält sie am Laufen, wenn einer davon ausfällt. Die eigentliche Frage ist also, ob du überhaupt eine Orchestrierung brauchst, und falls ja, wer sie betreibt.
Zwei Werkzeuge auf zwei Ebenen
| Docker | Kubernetes | |
|---|---|---|
| Aufgabe | Baut Images und startet Container auf der Maschine, auf der es läuft | Verteilt Container auf einen Cluster und hält den gewünschten Zustand |
| Reichweite | Ein Host | Viele Hosts |
| Wenn ein Host ausfällt | Seine Container stehen, bis der Host zurück ist | Die Workloads starten auf den übrigen Nodes neu |
| Updates | Container stoppen und neu starten, von Hand oder per Skript | Rolling Updates und Rollbacks sind eingebaut |
| Typische Datei | Dockerfile, compose.yaml |
Deployments, Services, Gateway-API-Routen |
| Was du betreibst | Einen Server und seine Docker Engine | Control Plane, Nodes, Netzwerk, Ingress, Storage |
Die Images sind auf beiden Seiten dieselben. Was du mit docker build baust, läuft mit jeder Container-Laufzeit, die Kubernetes unterstützt, und Kubernetes führt es unverändert aus. Mit Version 1.24 ist der Dockershim weggefallen, der eingebaute Adapter, über den Kubernetes mit der Docker Engine sprach. Cluster nutzen heute eine Laufzeit wie containerd oder CRI-O. Wer die Docker Engine weiterhin braucht, bindet sie über cri-dockerd an, einen Adapter, den Mirantis und Docker pflegen. An den Images, die du mit Docker baust, ändert das nichts.
Wer Docker mit Kubernetes vergleichen will, meint oft Dockers eigene Orchestrierung, Docker Swarm. Das ist eine andere Frage als diese hier.
Wann du Kubernetes vielleicht nicht brauchst
Besteht deine Anwendung aus einem Container oder ein paar wenigen in einer compose.yaml, läuft sie auf einem Server, und sind ein paar Minuten Unterbruch beim Neustart dieses Servers verkraftbar, dann brauchst du Kubernetes vielleicht nicht. Docker mit Restart-Policy, ein Backup der Volumes und ein erprobter Weg, den Host neu aufzusetzen, decken diesen Fall ab, mit viel weniger Betriebsaufwand.
Bei VSHN gilt seit 2021: Kubernetes first, nicht Kubernetes only. Kubernetes ist der Standard, wo ein Workload braucht, was es kann. Wo nicht, bleibt ein einzelner Host die richtige Antwort.
Kubernetes lohnt sich, sobald einer dieser Punkte zutrifft:
- Ein einzelner Host ist ein Ausfallrisiko, das du nicht tragen willst. Workloads auf andere Nodes zu verschieben, kann Kubernetes, Docker auf einer Maschine nicht.
- Du deployst oft und kannst den Dienst dafür nicht abschalten. Rolling Updates und Rollbacks gehören zur API.
- Mehrere Teams oder viele Dienste teilen sich die Infrastruktur. Namespaces, RBAC und Resource Quotas geben jedem einen eigenen Bereich auf demselben Cluster.
- Du willst den Anbieter wechseln können. Dieselben Manifeste laufen in einer Schweizer Cloud, bei einem Hyperscaler und auf eigener Hardware.
Der Entscheid, der wirklich ansteht: Kubernetes selbst betreiben oder für dich betrieben
Brauchst du Kubernetes, stellt sich die nächste Frage: Wer betreibt es? Das Kubernetes-Projekt pflegt nur die drei neusten Minor-Versionen und liefert für jede rund ein Jahr lang Patches. Ein Cluster braucht also mindestens einmal im Jahr ein Versions-Upgrade, nur um unterstützt zu bleiben. Jedes Upgrade muss zum Betriebssystem der Nodes passen, zum Netzwerk-Plugin, zum Ingress-Controller und zum Storage, die alle ihre eigenen Release-Zyklen haben. Dazu kommen OS-Patches, Zertifikatsrotation, etcd-Backups und jemand, der reagiert, wenn ein Node ausfällt. Das ist die Arbeit eines Plattform-Teams, keine Nebenaufgabe.
Selbst betreiben ist sinnvoll, wenn es dieses Team gibt und Kubernetes-Betrieb zu seinem Auftrag gehört.
Mit VSHN Managed Kubernetes wird die Plattform für dich betrieben, auf einem standardisierten Stack: Talos Linux als unveränderliches Betriebssystem, Cilium fürs Netzwerk, die Gateway API für Ingress und Rook / Ceph für Storage, verwaltet über Cluster API bei Cloudscale in der Schweiz. VSHN übernimmt die Kubernetes-Upgrades nach festem Wartungsplan, die Talos-Updates und die Kernkomponenten. Wie bei jeder Plattform, die du nicht selbst betreibst, bleiben deine Anwendungen bei dir: ihre Kompatibilität mit jedem Kubernetes- und OS-Update, ihre Skalierung und ihre Konfiguration. Soll auch das abgedeckt sein, kommt Application Operations dazu. Der Service läuft zu Bürozeiten mit reaktivem Support.
Wie sich die Varianten im Detail unterscheiden, von Do-it-yourself über die Control Plane eines Cloud-Anbieters bis zu Enterprise-OpenShift, steht auf der Vergleichsseite.
Nächster Schritt
Managed Kubernetes ist in Entwicklung. Wenn du zwischen einem einzelnen Host und einem Cluster abwägst, oder zwischen eigenem Betrieb und betreiben lassen, melde dein Interesse an und erzähl uns, was du heute betreibst. Wir sagen dir, auf welcher Seite dieser Linie deine Workloads stehen.