An dieser Stelle möchten wir gern noch einige Hinweise an alle weitergeben, die sich gerade erst in die Thematik einfinden. Basierend auf einigen Missverständnissen taucht immer wieder die Frage auf, ob man lieber Docker oder Kubernetes nutzen sollte. Um überhaupt zu einer Antwort zu gelangen, müssen der Anwendungsfall und Docker als solches zunächst präzisiert werden.
Docker Container als Basis
Ohne zu technisch zu werden, lässt sich knapp sagen, dass beispielsweise alle einzelnen Teil-Awendungen, die später in der HERO Software zu einem großen Ganzen werden, in sogenannten Docker Containern unabhängig voneinander arbeiten. Diese Aufteilung ist ein gängiger Standard und bietet viele Vorteile (Geschwindigkeit, einfache Verwaltung etc.), durch die Docker so bekannt geworden ist. Erst wenn der Umgang mit diesen Containern im Alltag zu komplex wird, schalten Unternehmen ein Orchestrierungs-Tool wie Kubernetes hinzu.
Die Docker Container sind in der Regel allerdings genau das, womit Docker an sich identifiziert wird, obgleich hinter dem Namen ein ganzes Unternehmen, eine Open Source Community, und nicht zuletzt mit weiteren Tools wie Docker Swarm auch eine Alternative zu Kubernetes stecken.
Kubernetes steuert das Zusammenspiel der Container
Werden also Docker und Kubernetes direkt gegenübergestellt, dann wurde entweder das Verhältnis zwischen Docker Containern und dem Orchestrierungs-Tool Kubernetes falsch verstanden oder unterschlagen, dass es eigentlich um Docker Swarm vs. Kubernetes gehen soll.
Wir nutzen Kubernetes anstatt Docker Swarm
Kubernetes ist nicht das einzige Werkzeug seiner Art und lange Zeit war Docker Swarm eine valide Alternative. Es zeichnet sich jedoch ab, dass letzteres nicht mehr zukunftsfähig weiterentwickelt wird, weshalb wir bei HERO Software rechtzeitig von Docker Swarm auf Kubernetes umgestiegen sind. Im Bereich der Software-Infrastruktur muss man trotz rasanter Technologie-Fortschritte immer langfristig planen, weshalb eine fortdauernde Nutzung von Docker Swarm irgendwann einen teuren Umstieg auf andere Lösungen nach sich ziehen würde.
Der Wechsel muss jedoch nicht in allen Unternehmen von heute auf morgen passieren und es muss auch nicht unbedingt Kubernetes sein. Je nach Anwendungsfall könnten auch folgende Tools besser geeignet sein:
Alternativen zu Kubernetes | Vorteile | Nachteile |
---|
Managed Kubernetes | Alle Vorteile von Kubernetes, aber Verwaltung durch Dienstleister | Kann sehr teuer und wenig effizient sein |
Docker Swarm | Einfacher zu handhaben als Kubernetes | Weniger Detail-Features als Kubernetes |
Docker Compose | Gute Lösung für einfache Container Lösungen | Kein echtes Tool zu Orchestrierung |
Nomad | Bei hoher Skalierungs-Rate ist Nomad einfacher zu handhaben als Kubernetes | In Summe weniger Features als Kubernetes |
OpenStack | Nützliche Features zur Verwaltung von Clouds | Keine Nachteile, wenn OpenStack zusammen mit Kubernetes eingesetzt wird |
Apache Mesos | Vorteilhaft für einen Mix aus Container und Non-Container | Kubernetes ist besser für Container-Lösungen geeignet |
Mesos DC/OS | Einfacher zu bedienen als Kubernetes | Nicht alle Features sind kostenlos und die Community ist vergleichsweise klein |
Heroku | Einfacher zu bedienen als Kubernetes | Kein echtes Tool zu Orchestrierung, nicht auf eigenen Servern einsetzbar |
Amazon Elastic Beanstalk | Sehr gut mit Amazon Clouds (AWS) nutzbar | Immer wieder Berichte über fehlerhafte Deployments |
Cloud Foundry | Vereinfachter Aufbau gegenüber Kubernetes | Nicht alle Details sind einsehbar / lassen sich managen |
OpenShift | Ganzes Ökosystem inklusive Kubernetes | Mit Kosten verbunden, nicht so detailliert anpassbar wie Kubernetes |