Ku­ber­netes vs. Docker

Docker ist eine Plattform zur Con­tai­ne­ri­sie­rung von An­wen­dun­gen, während Ku­ber­netes ein Or­ches­trie­rungs­sys­tem ist, das mehrere Docker-Container verwaltet und skaliert. Somit er­mög­licht Docker das Erstellen, Verpacken und Ausführen von An­wen­dun­gen in Con­tai­nern, während Ku­ber­netes dafür sorgt, dass diese Container au­to­ma­ti­siert be­reit­ge­stellt und or­ga­ni­siert werden.

Ku­ber­netes vs. Docker: Wo liegen die Un­ter­schie­de?

Docker hat mit der Ent­wick­lung der Container-Tech­no­lo­gie eine kleine Re­vo­lu­ti­on geschafft. Für die Arbeit in der Soft­ware­ent­wick­lung ergeben sich durch die Vir­tua­li­sie­rung mit in sich ge­schlos­se­nen Paketen (den Con­tai­nern) ganz neue Mög­lich­kei­ten. So können Ent­wick­le­rin­nen und Ent­wick­ler An­wen­dun­gen und deren Ab­hän­gig­kei­ten einfach in Con­tai­nern bündeln und damit dafür sorgen, dass eine Vir­tua­li­sie­rung auf Pro­zess­ebe­ne statt­fin­den kann. Obwohl es eine Reihe von Docker-Al­ter­na­ti­ven gibt, ist die Open-Source-Lösung Docker nach wie vor die po­pu­lärs­te Plattform zum Erstellen von Con­tai­nern.

Ku­ber­netes hingegen ist eine Anwendung zur Or­ches­trie­rung (das heißt Ver­wal­tung) von Con­tai­nern; die Container selbst erstellt das Programm nicht. Die Or­ches­trie­rungs­soft­ware greift auf die be­stehen­den Container-Tools zu und in­te­griert diese in den eigenen Workflow. So bindet man Container, die man mit Docker oder einem anderen Werkzeug erstellt hat, einfach in Ku­ber­netes ein. An­schlie­ßend nutzt man die Or­ches­trie­rung, um die Container zu verwalten, zu skalieren und zu bewegen. Ku­ber­netes ge­währ­leis­tet also, dass alles wie gewünscht läuft, und sorgt auch für Ersatz, sollte ein Kno­ten­punkt zu­sam­men­bre­chen.

Ein­satz­ge­bie­te von Docker und Ku­ber­netes

Im Vergleich Docker vs. Ku­ber­netes fällt auf, dass die beiden Tools sich hin­sicht­lich ihrer Ein­satz­ge­bie­te un­ter­schei­den, aber dabei Hand in Hand arbeiten. Um die un­ter­schied­li­chen Funk­tio­nen von Docker und Ku­ber­netes zu verstehen, schauen wir uns ein Beispiel an.

Die meisten An­wen­dun­gen sind heute mit so­ge­nann­ten Mi­cro­ser­vice-Ar­chi­tek­tu­ren or­ga­ni­siert, da dieser Ar­chi­tek­tur­stil eine bessere Ska­lier­bar­keit, Fle­xi­bi­li­tät und Wart­bar­keit er­mög­licht, indem er komplexe Systeme in kleinere, un­ab­hän­gi­ge Dienste aufteilt.

Schritt 1: Mi­cro­ser­vices pro­gram­mie­ren und Container erstellen

In einem ersten Schritt muss die Anwendung pro­gram­miert werden; hierzu ent­wi­ckelt das Team die einzelnen Mi­cro­ser­vices, aus denen die App besteht. Jeder Mi­cro­ser­vice wird als ei­gen­stän­di­ge Einheit ge­schrie­ben und verfügt über eine de­fi­nier­te API zur Kom­mu­ni­ka­ti­on mit anderen Services. Sobald die Ent­wick­lung eines Mi­cro­ser­vices ab­ge­schlos­sen ist, wird er mit Docker con­tai­ne­ri­siert. Docker er­mög­licht es, die Mi­cro­ser­vices in kleine, isolierte Container zu verpacken, die alle be­nö­tig­ten Ab­hän­gig­kei­ten und Kon­fi­gu­ra­tio­nen enthalten. Diese Container können dann in jeder Umgebung aus­ge­führt werden, ohne dass es zu Kom­pli­ka­tio­nen durch un­ter­schied­li­che Sys­tem­kon­fi­gu­ra­tio­nen kommt.

Schritt 2: Or­ches­trie­rung mit Ku­ber­netes kon­fi­gu­rie­ren

Nachdem die Mi­cro­ser­vices er­folg­reich con­tai­ne­ri­siert wurden, kommt Ku­ber­netes ins Spiel. In einem nächsten Schritt erstellt das Team daher Ku­ber­netes-Kon­fi­gu­ra­ti­ons­da­tei­en, die festlegen, wie die Container (im Ku­ber­netes-Jargon werden diese auch Pods genannt) auf ver­schie­de­nen Servern be­reit­ge­stellt werden sollen. Die Dateien be­inhal­ten unter anderem, wie viele Instanzen eines be­stimm­ten Pods aus­ge­führt werden sollen, welche Netz­werk­ein­stel­lun­gen er­for­der­lich sind und wie die Kom­mu­ni­ka­ti­on zwischen den Mi­cro­ser­vices funk­tio­niert.

Ku­ber­netes übernimmt die au­to­ma­ti­sche Ver­wal­tung dieser Container. Wenn ein Mi­cro­ser­vice ausfällt oder ein Container abstürzt, sorgt Ku­ber­netes dafür, dass der Container au­to­ma­tisch neu gestartet wird, sodass die Anwendung weiterhin ohne Sys­tem­aus­fäl­le funk­tio­niert. Zudem kann Ku­ber­netes die Funktion eines Load Balancers über­neh­men und Container auf mehreren Servern verteilen, um eine bessere Aus­las­tung und Ska­lier­bar­keit zu ge­währ­leis­ten. Sollte der Traffic für die Anwendung steigen, kann Ku­ber­netes au­to­ma­tisch neue Pods starten.

Schritt 3: Updates

Mit Ku­ber­netes wird nicht nur die Be­reit­stel­lung von Con­tai­nern ver­ein­facht, sondern auch die Ver­wal­tung von Updates. Möchten die Pro­gram­mie­re­rin­nen und Pro­gram­mie­rer neuen Code in Pro­duk­ti­on bringen, kann Ku­ber­netes die Container schritt­wei­se mit der neuen Version ersetzen, ohne dass es zu Aus­fall­zei­ten kommt. So bleibt die Anwendung stets verfügbar, während gleich­zei­tig neue Features oder Bugfixes ein­ge­spielt werden.

Direkte Ge­gen­über­stel­lung: Ku­ber­netes vs. Docker

Docker Swarm: Die Ku­ber­netes-Al­ter­na­ti­ve

Auch wenn Ku­ber­netes und Docker wunderbar mit­ein­an­der har­mo­nie­ren, gibt es doch eine Kon­kur­renz für das Or­ches­trie­rungs­tool: Docker Swarm in Kom­bi­na­ti­on mit Docker Compose. Zwar geht Docker mit beiden Lösungen um und kann sogar zwischen beiden hin und her wechseln, Docker Swarm und Ku­ber­netes al­ler­dings lassen sich nicht kom­bi­nie­ren. Deshalb stehen Nut­ze­rin­nen und Nutzer oft vor der Frage, ob sie auf das sehr populäre Ku­ber­netes setzen oder doch das zu Docker gehörende Swarm verwenden sollen.

Der Aufbau der beiden Tools ähnelt sich prin­zi­pi­ell sehr stark – nur die Namen der einzelnen Aspekte ändern sich. Auch der An­wen­dungs­zweck ist identisch: Container effizient verwalten und durch in­tel­li­gen­te Ska­lie­rung den möglichst sparsamen Res­sour­cen­ein­satz si­cher­stel­len.

Vorteile offenbart Swarm bei der In­stal­la­ti­on: Da das Werkzeug ein in­te­gra­ler Be­stand­teil von Docker ist, fällt der Übergang sehr leicht. Während man bei Ku­ber­netes die Or­ches­trie­rung erst aufsetzen muss, was zu­ge­ge­be­ner­ma­ßen aber nicht son­der­lich komplex ist, ist bei Swarm alles bereits vorhanden. Da man in der Praxis höchst­wahr­schein­lich ohnehin schon mit Docker arbeitet, braucht man sich auch nicht in die Ei­gen­hei­ten eines neuen Programms ein­ar­bei­ten.

Dafür glänzt Ku­ber­netes mit eigenem GUI: Über das zur Anwendung gehörende Dashboard hat man nicht nur eine sehr gute Übersicht über alle Aspekte des Projekts, sondern kann auch zahl­rei­che Aufgaben erledigen. Docker Swarm auf der anderen Seite bietet solch einen Komfort erst durch zu­sätz­li­che Programme. Punkten kann Ku­ber­netes zudem im Funk­ti­ons­um­fang: Während Swarm für das Mo­ni­to­ring und das Führen eines Logs zu­sätz­li­che Mittel benötigt, sind diese Aufgaben in Ku­ber­netes bereits vor­ge­se­hen und ent­spre­chen­de Funk­tio­nen gehören zum Re­per­toire dazu.

Der Haupt­nut­zen der beiden Programme besteht al­ler­dings in der Ska­lie­rung und der Si­cher­stel­lung der Ver­füg­bar­keit. Es heißt, dass Docker Swarm in puncto Ska­lier­bar­keit generell besser ist. Grund dafür ist die Kom­ple­xi­tät von Ku­ber­netes, die zu einer gewissen Schwer­fäl­lig­keit führt. Das komplexe System sorgt auf der anderen Seite aber wiederum dafür, dass au­to­ma­ti­sche Ska­lie­run­gen bei Ku­ber­netes besser sind. Außerdem ist ein großer Vorteil von Ku­ber­netes, dass es den Zustand der Container jederzeit überwacht und einen Ausfall direkt aus­gleicht.

Dafür schneidet Swarm beim Load Balancing besser ab: Die gleich­mä­ßi­ge Ver­tei­lung der Last ist bei Swarm eine Selbst­ver­ständ­lich­keit. Bei Ku­ber­netes muss man für das Load Balancing einen kleinen Umweg in Kauf nehmen. Dort müssen De­ploy­ments erst zu Services gemacht werden, um von der Last­ver­tei­lung pro­fi­tie­ren zu können.