Kubernetes: Was Sie über den K8s-Trend wissen müssen

Kubernetes: Was Sie über den K8s-Trend wissen müssen

Manche IT-Trends kommen und gehen recht schnell, andere bleiben länger und wieder andere prägen eine ganze Ära. Cloud, Container und deren automatische Steuerung über Kubernetes haben das Zeug dazu, einen langfristigen Fußabdruck zu hinterlassen. Wir zeigen, was Sie über Kubernetes, die dahinter stehende Architektur und Funktionsweise wissen sollten und wie K8s zu Docker und OpenShift im Verhältnis steht.

Die IT-Welt wird für Anwender immer einfacher. Leistungsfähige Web-Dienste stehen rund um die Uhr bereit, geben sich auch bei hoher Last keine Blöße und sind selbst bei Hardware-Ausfällen immer am Start. Doch damit das alles so reibungslos funktioniert, ist im Hintergrund eine ausgefeilte Strategie für den Betrieb der Apps nötig, die heute in der Regel auf Container aufbaut. Anwendungscode wird dabei zusammen mit Bibliotheken zu einem Paket geschnürt und kann damit ohne Anpassungen praktisch überall laufen, etwa auf klassischen Desktops, auf traditionellen Servern oder in der Cloud.

Klingt einfach und das ist es in der Praxis auch, einzelne Container lassen sich schnell an den Start bringen, verschieben und skalieren. Doch die Einfachheit artet schnell in viel Arbeit aus, wenn die Anzahl der Container zunimmt, also mehr Software Deployment gemacht wird. Admins wären dann mit vielen manuellen Aufgaben rund um das Management der praktischen Pakete beschäftigt. Hier kommt Kubernetes ins Spiel, das viele dieser händischen Prozesse automatisieren kann, die mit der Bereitstellung, Verwaltung und Skalierung von containerisierten Anwendungen einhergehen.

Was ist Kubernetes?

Der Begriff Kubernetes, oft auch einfach als K8s oder Kube abgekürzt, leitet sich vom griechischen Wort für Steuermann ab und das ist ziemlich treffend. K8s ist eine Opensource-Plattform zur sogenannten Container-Orchestrierung. Die „Orchestrierung“ bezieht sich im weitesten Sinne auf die automatische Bereitstellung, Skalierung und Verwaltung von Containern. Beispiel: Ein Webdienst soll möglichst ausfallsicher und schnell bereitgestellt werden. Deshalb wird in Kubernetes eine Regel erstellt, die besagt, dass immer drei Instanzen der Webservice-App laufen sollen. Fällt eine aus, etwa weil ein Server defekt ist, merkt das Kubernetes und startet zu den beiden anderen Instanzen den dritten Webservice automatisch auf anderer Hardware neu.

Entstanden ist Kubernetes bei Google, die für die Steuerung ihrer Serverlandschaft ein eigenes System namens Borg entwickelt hatten. Borg war bei Google dafür zuständig, für hochverfügbare Dienste wie die Suche, Gmail oder Maps immer genügend Rechenleistung bereitzustellen. Im Jahr 2014 hat man das Projekt unter dem Namen Kubernetes aber an die eigens dafür gegründete Cloud Native Computing Foundation (CNCF) gespendet, die sich seither um die Standardisierung und Weiterentwicklung von K8s kümmert. Stand heute sind in der CNCF über 500 Unternehmen zusammengeschlossen, darunter Amazon Web Services, Alibaba Cloud, Apple, Google, Twitter, Microsoft, Red Hat, OVH und VMware.

Wofür kann Kubernetes eingesetzt werden?

Kubernetes ist ein mächtiges Hilfsmittel für das Deployment von Anwendungen. Hat man früher Apps noch auf dedizierter Hardware installiert, zeigten sich virtuelle Maschinen schon wesentlich flexibler, weil man Anwendungen besser trennen und virtuelle Maschinen einfacher verwalten konnte als bei Bare-Metal-Installationen. Aber auch virtuelle Maschinen haben Nachteile, denn sie müssen immer mit einem eigenen Betriebssystem ausgestattet werden. Erst Container lösen dieses Problem, denn sie bringen zwar die Anwendung selbst sowie die nötigen Bibliotheken mit, zapfen aber nur Betriebssystemressourcen vom darunter liegenden Host an, die sie wirklich brauchen.

Der Clou dabei ist, Software-Container nutzen zwar eine Form der Betriebssystemvirtualisierung, mit der Anwendungen ein Betriebssystem gemeinsam verwenden können, indem Prozesse isoliert und der Zugriff auf CPU, Speicher und Prozesse geteilt werden. Sie brauchen aber kein eigenes OS und sind damit wesentlich schlanker als virtuelle Maschinen. Denkt man das weiter, lassen sich große Anwendungen in viele kleine Teile zerlegen, die alle in eigenen Containern stecken. Für die Steuerung dieser Einheiten ist Kubernetes zuständig.

Man kann also mit Kubernetes die Bereitstellung, Skalierung und Verwaltung von Anwendungen automatisieren. Das können Datenbanken sein, Mail- oder Web-Server, Content Management-, CRM- oder ERP-Systeme und mehr.

Funktionsweise & grundlegende Begriffe

Die Idee hinter Kubernetes lässt sich auch ohne viele Fachbegriffe verstehen. Doch wer etwas tiefer in die Funktionsweise einsteigen und den Kubernetes Aufbau verstehen will, muss sich mit den grundlegenden Begriffen rund um Kubernetes vertraut machen. Mit Kubernetes lassen sich Einrichtung, Bereitstellung, Betrieb, Skalierung und Wartung vieler einzelner Container stark vereinfachen und automatisieren. Manchmal trifft man in dem Zusammenhang auch noch auf den Begriff „Master-Slave-Architektur“, wobei das langsam aus dem Sprachgebrauch verschwindet. Gemeint ist, es gibt eine Cluster-Struktur bestehend aus Control Plane, Nodes, Pods und Containern.

Cluster: Einen Kubernetes-Cluster kann man sich als klassischen vernetzten Rechnerverbund vorstellen. Die grundsätzliche Idee, durch solche Vernetzungen Rechenkapazität und Ausfallsicherheit zu erhöhen, stammt aus den 60er Jahren. Heute ist die Struktur aber deutlich flexibler. Ein Kubernetes-Cluster besteht grob gesagt aus zwei Teilen: einer Kontrolleinheit, der sogenannten Control Plane (Master) und den Recheneinheiten, auch als Knoten oder Nodes bezeichnet. Letztere sind nicht mehr zwingend in eigenständiger Hardware realisiert, sondern können auch virtuelle Maschinen sein.

Master / Control Plane: Neben den Knoten ist die Control Plane der zweite essenzielle Bestandteil eines Kubernetes-Clusters. Sind die Nodes die eigentlichen Arbeiter, ist die Control Plane die Steuereinheit des Kubernetes-Clusters, im veralteten Sprachgebrauch der „Master“. Sie enthält die zentrale Datenbank aller Kubernetes-Objekte und umfasst drei Prozesse: kube-apiserver, kube-controller-manager und kube-scheduler. Was die genau machen, erklären wir weiter unten. Grundsätzlich verwaltet die Control Plane alle Kubernetes-Objekte und prüft über Controller-Prozesse ständig den Status dieser Objekte. Zentral in ihr eingebettet ist deswegen die Datenbank etcd. Werden Abweichungen vom definierten Wunschzustand festgestellt, etwa wenn eine Anwendung ausgefallen ist, dann veranlasst die Control Plane deren Neustart.

Container: Sie sind eine sehr elegante Möglichkeit, um lauffähige Software-Einheiten zu packen. Neben dem Source-Code einer Anwendung wandern auch Bibliotheken und Frameworks, die zur Ausführung wichtig sind, mit in den Container. Den kann man sich wie ein Zip-Archiv eines portablen Programms vorstellen. Alles was zur Ausführung nötig ist, steckt im Container, das macht ihn unabhängig von den darunter liegenden Schichten. Der Container wird nur auf ein Betriebssystem gesetzt und läuft. In der Praxis kann ein Entwickler zum Beispiel erst mit einem Container auf seinem Notebook experimentieren, ihn danach auf einen dedizierten Server packen oder in verschiedenen Cloud-Umgebungen testen. Mit dieser Technik lassen sich große Cloud-Anwendungen aus vielen kleinen Bestandteilen zusammenbauen. Das sind dann sogenannte Microservices, die untereinander kommunizieren.

Node (Knoten): Jeder Node (Knoten) ist eine eigene Recheneinheit im Cluster, die von der Control Plane gesteuert wird. Knoten können in der Praxis physische Computer sein oder auch virtuelle Maschinen. Wichtig ist nur, dass jeder Node eine eigene Betriebssystemumgebung enthält und auf ihm Container laufen können. Auch auf jeden Knoten laufen bestimmte Komponenten, die mit der Control Plane kommunizieren und Pods am Laufen halten.

Pod: Wichtig ist im Kubernetes-Jargon auch der Begriff Pod. Er fasst eine Gruppe von Containern zusammen, die auf einem Knoten laufen. Der kleinste mögliche Pod besteht aus nur einem Container. Damit ist ein Pod die kleinste Einheit in der Kubernetes Architektur. Nicht jeder Pod läuft exklusiv auf einem Knoten, gängig ist, dass mehrere Pods als Prozesse auf den Knoten laufen, um Ressourcen optimal zu nutzen. Oftmals werden Pods auch mehrfach gestartet, um Ausfallsicherheit zu erzeugen.

Aber anhand welcher Kriterien automatisiert Kubernetes die Container-Steuerung? Ganz von selbst geht das natürlich nicht, Admins müssen Input liefern, zum Beispiel welche Container in welcher Anzahl benötigt werden. In Kubernetes beschreibt man also einen Wunschzustand, der über deklarative YAML-Dateien formuliert wird. Controller prüfen automatisch den Ist-Zustand und sollte der vom Wunschzustand abweichen, dann greift Kubernetes automatisch ein.

Über verschiedene Prozesse kommuniziert die Control Plane mit den Nodes und weist den Pods die passenden Konfigurationen zu. Das umfasst viele Aufgaben, etwa für die Verteilung der Pods auf die bereitstehenden Nodes, das Starten und Stoppen von Containern oder im Fall der Fälle das Ersetzen von ausgefallenen Nodes.

Kubernetes Architektur & Komponenten

Bisher ist das Bild von Kubernetes noch stark vereinfacht. Ein Blick ins Innere von Control Plane und Nodes zeigt deren Komponenten mit ihren wichtigsten Aufgaben und den grundlegenden Kubernetes Aufbau:

Master / Control Plane Komponenten

kube-apiserver: Kubernetes ist ein mächtiges Hilfsmittel, aber ohne entsprechende Konfiguration ist es erstmal wertlos. Für die Interaktion mit dem Kubernetes-Cluster gibt es den kube-apiserver. Diese Komponente ist das Frontend der Control Plane und macht die Kubernetes-Schnittstellen verfügbar, indem es interne und externe Anforderungen verarbeitet. Der kube-apiserver stellt fest, ob eine Anforderungen gültig ist oder nicht und verarbeitet sie. Der Zugriff auf die API ist in der Praxis recht flexibel möglich, etwa über die Kommandozeile, über Befehlszeilen-Tools oder REST-Aufrufe. Die API regelt den Zugriff auf die Datenbank etcd und ist nicht nur Schnittstelle für die Konfiguration durch den Admin, sondern auch für Scheduler und Controller-Manager.

etcd: Sämtliche hinterlegten Konfigurationsdaten und auch immer frische Informationen zum Zustand des Kubernetes Clusters werden in der Datenbank etcd gespeichert. Versteht sich von selbst, dass der konsistente und hochverfügbare Key-Value Speicher immer gut gesichert werden sollte. Die Anwendungen des Clusters können Daten in etcd lesen und schreiben.

kube-controller-manager: Controller machen ihrem Namen alle Ehre und sind die Prüfeinheiten, die überall im Cluster nach dem Rechten sehen. Der Manager fasst verschiedene Controller zusammen. Der Node Controller beispielsweise registriert, wenn Nodes ausfallen und leitet eine entsprechende Reaktion ein. Der Replication Controller sorgt dafür, dass die korrekte Anzahl an Pods im System läuft. Weitere Controller verbinden zum Beispiel Services und Pods oder interagieren mit den Schnittstellen der Cloud-Anbieter.

kube-scheduler: Der kube-scheduler ist eine wichtige Komponente auf der Control Plane, die immer die Ressourcenauslastung der Nodes im Blick hat. Er registriert neu erstellte Pods in etcd, denen noch kein Node zugewiesen ist. Dann wählt er den passenden Node aus, auf dem neue Pods ausgeführt werden sollen. Dabei berücksichtigt der Scheduler den Ressourcenbedarf des Pods, etwa CPU- und Speicherbedarf sowie den Zustand des Clusters.

Node Komponenten

 

kubelet: Ein kubelet ist eine winzige Anwendung, oft auch Agent genannt, der auf jedem Node im Cluster läuft. Ihre Hauptaufgabe ist die Kommunikation mit der Control Plane. Wenn die Control Plane einen Vorgang in einem Knoten lostreten will, führt das kubelet diesen aus. Kubelets stellen außerdem sicher, dass Container in einem Pod ausgeführt werden. Schiebt der Scheduler also einen neuen Pod auf einen Knoten, erfolgt dessen Start über das kubelet.

kube-proxy: Das Grundkonzept von Kubernetes sieht vor, dass Pods eine eigene IP-Adresse haben und sich so untereinander vernetzen lassen. Jeder Node enthält deshalb einen kube-proxy. Dieser Netzwerk-Proxy steuert die Netzwerkkommunikation. Er setzt die Netzwerkregeln auf dem Host durch und ist für eingerichtete Weiterleitungen zuständig.

Container Runtime: Ein wichtiger Punkt bei Kubernetes, der oft falsch verstanden wird. Gemeint ist mit der Runtime die Software, die für das Ausführen von Containern verantwortlich ist. Docker ist die wohl bekannteste Runtime in diesem Zusammenhang. Kubernetes unterstützt aber noch andere Runtimes, etwa containerd, cri-o oder rktlet.

Addons

Auch bei Kubernetes gibt es Addons, die das Funktionsspektrum erweitert, etwa rund um Sicherheit, Monitoring oder Vernetzung. Technisch gesehen sind das Pods und Dienste, die Cluster-Funktionen implementieren. Zum Beispiel gibt es zahlreiche Addons, die die Netzwerkfunktionalität von Kubernetes erweitert, etwa um Richtlinien. Auch ein Dashboard gibt es als Addon, mit dem sich Kubernetes mit einem Web-Interface ausstatten lässt.

Welche Vorteile bietet Kubernetes?

Die Vorteile von Kubernetes sind zahlreich. Über allen schwebt das Konzept einer Cloud-nativen Architektur, also einer Struktur, die explizit für den Einsatz in der Cloud entwickelt wurde. Container sind der bekannteste Baustein so einer Architektur, denn sie sorgen dafür, dass Apps unabhängig vom Betriebssystem laufen. Kubernetes ist die Steuereinheit im Hintergrund, die über zahlreiche Automatiken den Laden am Laufen hält.

Entwicklung: Einen großen Vorteil hat man bei der Anwendungsentwicklung mit Kubernetes und Containern, wenn man klassische, monolithische Anwendungen zum Vergleich heranzieht. Früher versuchte man die komplette Funktionalität in eine Anwendung zu pressen. Die Folge waren unübersichtlicher und fehlernfälliger Code. Programmierer können sich mit Containern auf ihren Code konzentrieren, die Operations-Teams auf die Bereitstellung. Statt einer Riesenanwendung wird die Struktur aufgebrochen in viele kleine Microservice-Apps. Die lassen sich schneller entwickeln, bereitstellen, austauschen oder updaten.

Automatik: Container kann man auch ohne Kubernetes einsetzen. Doch dann fallen schnell viele manuelle Prozesse für das Betreiben und Skalieren der paketierten Anwendung an. Kubernetes bietet hier viele Automatisierungsmöglichkeiten, die Admins entlasten.

Verfügbarkeit: Kubernetes liefert durch seine Cluster-Architektur und die Kombination mit Containern alles Nötige mit, um Anwendungen stabil und mit hoher Verfügbarkeit zu betreiben. Durch das Konzept mit Pods, Nodes und Clustern lassen sich nahezu beliebige Redundanzen abbilden. Benötigt ein Microservice mehr Ressourcen, stellt sie Kubernetes automatisch und ohne Service-Unterbrechung bereit.

Updates: Keine Anwendung kommt ohne Updates aus, doch das Problem sind nicht die Patches, sondern die Downtimes. Klassischerweise gibt es bei Updates zumindest kurze Unterbrechungen im Betrieb. Mit Kubernetes muss das nicht sein, denn Anwendungen können ohne Downtime aktualisiert werden. Betreiber würden einfach mehrere Pods bereitstellen und diese nach und nach Updates. So gibt es auch bei Updates keine Ausfallzeiten.

Flexibel: Flexibilität ist natürlich ein großes Wort und bei Kubernetes kann man diesen Vorteil an verschiedenen Stellen nennen. Gemeint ist hier aber die Plattformunabhängigkeit, Anwendungen sind außerdem einfach migrierbar oder reproduzierbar. K8s ist mit On-Premise-Plattformen und verschiedenen Cloud-Modellen wie Private Cloud, Public Cloud, Hybrid Cloud oder Multicloud kompatibel.

Partner: Kubernetes hat schon eine illustre Ansammlung an Partnern am Start. Rund 150 Firmen entwickeln Zusatzprodukte, das Ökosystem blüht also.

Verhältnis zu anderen Technologien

Kubernetes hat eine sehr aktive Community, ist in Unternehmen beliebt und auch weit verbreitet. Es ist aber einerseits nicht die einzige Plattform zur Container-Orchestrierung und kann andererseits auch nicht nur mit Docker zusammenarbeiten.

Kubernetes vs. Openshift

Dass eine Plattform zur Container-Orchestrierung für Unternehmen sehr wichtig ist, ist unstrittig. Kubernetes gilt hier zwar als Quasi-Standard, aber die Anforderungen von Unternehmen übersteigen an vielen Stellen die Ziele und Möglichkeiten der Opensource-Lösung. Die Kubernetes-Plattform Red Hat OpenShift hat im Vergleich wesentlich mehr zu bieten. Einen sehr detaillierten Vergleich gibt es in einem eigenen Blog-Beitrag zum Nachlesen. Die Kurzfassung: OpenShift ist das Kubernetes für Unternehmen, integriert zusätzliche Opensource Module in den Kubernetes-Stack, testet deren Zusammenspiel und konfiguriert sämtliche Komponenten für den schnellen Einsatz in Unternehmen vor. Das nimmt im Unternehmensalltag viel Arbeit ab und bringt Container-Vorhaben noch schneller ans Ziel.

Kubernetes vs. Docker

K8s und Docker werden oft in einen Topf geworfen und grundlegend falsch ist das nicht. Die beiden Techniken sind aber auch nicht austauschbar. Kubernetes ist eine Plattform zur Container-Orchestrierung, Docker ist dagegen eine Engine, um Container bereitzustellen und auszuführen, übernimmt also die Aufgabe einer Laufzeitumgebung. Kubernetes kann aber mit verschiedenen Laufzeitumgebungen für Container zusammenarbeiten und Docker wird dafür gern eingesetzt. Es ist aber auch der Einsatz von containerid, cri-o oder anderer Engines möglich. Wer Kubernetes sagt, kann also auch Docker sagen, muss das aber nicht tun.

Haben Sie noch Fragen?

Jetzt Experten kontaktieren