Dieser Artikel wurde wegen inhaltlicher Mängel auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen, und beteilige dich an der Diskussion! () Begründung: Deutlich Luft nach oben bei der Allgemeinverständlichkeit. Weite Teile des Artikels basieren offenkundig auf einer kaum bearbeiteten maschinellen Übersetzung. Dafür sprechen Satzbau und Wortwahl. --KS80 (Diskussion) 12:36, 10. Dez. 2020 (CET)

Dieser Artikel oder Abschnitt bedarf einer Überarbeitung. Näheres sollte auf der Diskussionsseite angegeben sein. Bitte hilf mit, ihn zu verbessern, und entferne anschließend diese Markierung.

Dieser Artikel oder Abschnitt ist nicht allgemeinverständlich formuliert. Die Mängel sind unter Diskussion:Kubernetes beschrieben. Wenn du diesen Baustein entfernst, begründe dies bitte auf der Artikeldiskussionsseite und ergänze den automatisch erstellten Projektseitenabschnitt Wikipedia:Unverständliche Artikel #Kubernetes um {{Erledigt|1=~~~~}}.

Folgendes sollte noch verbessert werden: Deutlich Luft nach oben bei der Allgemeinverständlichkeit. Weite Teile des Artikels basieren offenkundig auf einer kaum bearbeiteten maschinellen Übersetzung. Dafür sprechen Satzbau und Wortwahl.

Kubernetes (auch als K8s bezeichnet, deutsche Aussprache: [ˌkuːbɐˈneːtəs]) ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von Container-Anwendungen, das ursprünglich von Google entworfen und an die Cloud Native Computing Foundation (CNCF) gespendet wurde. Es zielt darauf ab, eine „Plattform für das automatisierte Bespielen, Skalieren und Warten von Anwendungscontainern auf verteilten Hosts“ zu liefern. Es unterstützt eine Reihe von Container-Tools, einschließlich Docker.^[4]

Die Orchestrierung mittels Kubernetes wird von führenden Cloud-Plattformen wie Microsofts Azure,^[5] IBM Cloud,^[6] Red Hats OpenShift,^[7] Amazons EKS,^[8] Googles Kubernetes Engine,^[9] und Oracles OCI^[10][11] unterstützt.

Geschichte

Kubernetes (von griechisch κυβερνήτης ‚Steuermann‘) wurde ursprünglich von Joe Beda, Brendan Burns und Craig McLuckie entwickelt.^[12] Kurze Zeit später stießen weitere Google-Entwickler wie Brian Grant und Tim Hockin hinzu. 2014 stellte Google Kubernetes als Open-Source-Projekt der Öffentlichkeit vor.^[13]

Version 1.0 wurde am 21. Juli 2015 veröffentlicht.^[14] Dabei wurde auch die Gründung der Cloud Native Computing Foundation unter dem Dach der Linux Foundation angekündigt und Kubernetes wurde von Google an diese gespendet.^[15]

Einführung

Vergleich traditioneller Ansatz vs. virtuelle Maschinen vs. Containerisierung von Anwendungen

Früher führten Unternehmen Anwendungen auf physischen Servern aus. Es gab keine Möglichkeit, Ressourcengrenzen für Anwendungen auf einem physischen Server zu definieren. Dies führte zu Problemen bei der Ressourcenzuweisung. Wenn z. B. mehrere Anwendungen auf einem physischen Server ausgeführt werden, kann es vorkommen, dass eine Anwendung die meisten Ressourcen beansprucht. Dies hat zur Folge, dass die anderen Anwendungen nicht mehr mit der notwendigen Leistung arbeiten können. Eine Lösung hierfür wäre, jede Anwendung auf einem anderen physischen Server laufen zu lassen. Dies war jedoch nicht skalierbar, da die Ressourcen nicht ausgelastet waren und es für Unternehmen teuer war, viele physische Server zu unterhalten. Zudem war die zu betreibende Software stark an das Betriebssystem gebunden. Aktualisierungen von Bibliotheken konnten Auswirkungen auf die bereits installierte Software haben. Die Aktualisierung der Software war ein kritischer Prozess, der zu Ausfallzeiten führte. Ein Zurückrollen der Installation war praktisch kaum möglich. Die Anwendungen selbst basierten auf einer monolithischen Architektur, die in der Regel nicht in Teilsysteme gegliedert oder auf Basis einzelner, zusammenwirkender Komponenten erstellt wurden. Dadurch waren diese Systeme weder wartbar noch erweiterbar, da die Teile dieses Systems nur mit erheblichem Aufwand modifiziert und an neue Bedingungen angepasst werden können.

Ein Teil der beschriebenen Probleme konnte durch die Virtualisierung der Hardware gelöst werden. Sie ermöglicht es, mehrere virtuelle Maschinen (VMs) auf der CPU eines einzigen physischen Servers auszuführen. Die Virtualisierung ermöglicht die Isolierung von Anwendungen zwischen VMs und bietet ein gewisses Maß an Sicherheit, da die Informationen einer Anwendung nicht frei von einer anderen Anwendung abgerufen werden können. Die Virtualisierung ermöglicht eine bessere Ausnutzung der Ressourcen eines physischen Servers und bietet eine bessere Skalierbarkeit. Eine Anwendung kann einfach hinzugefügt oder aktualisiert werden. Dies reduziert u. a. die Hardwarekosten. Jede virtuelle Maschine ist eine vollständige Maschine, auf der alle Komponenten, einschließlich eines eigenen Betriebssystems, auf der virtualisierten Hardware laufen. Die Abstraktion zwischen der tatsächlich vorhandenen Hardware übernimmt der Hypervisor. Da in einer VM jeweils ein Betriebssystem installiert ist, sind diese nicht leichtgewichtig.

Dies führte zu der Idee der Containervirtualisierung: Für eine Anwendung werden jeweils nur Ressourcen des Betriebssystems zur Verfügung gestellt, welche sie wirklich benötigt. Ein Programm, das innerhalb eines Containers läuft, kann nur den Inhalt des Containers und die dem Container zugewiesenen Geräte sehen. Solche Container sind ähnlich wie VMs, haben aber gelockerte Isolationseigenschaften, um das Betriebssystem mit den Anwendungen zu teilen. Daher werden Container als leichtgewichtig angesehen. Ähnlich wie eine VM hat ein Container sein eigenes Dateisystem, Anteil an CPU, Speicher, Prozessraum und mehr. Da sie von der zugrunde liegenden Infrastruktur entkoppelt sind, sind sie über unterschiedliche Cloud-Lösungen und Betriebssysteme hinweg portabel. Da Container klein und schnell sind, kann in jedes Containerimage eine Anwendung gepackt werden. Container sind in der Regel unveränderlich, d. h. ab dem Zeitpunkt der Erstellung des Containers wird eine konsistente Umgebung von der Entwicklung bis zur Produktion gewährleistet. Anstatt die Software innerhalb eines Containers zu aktualisieren, wird der alte Container mit einem anderen Container mit neuerer Software ausgetauscht.

Anstatt eine Anwendung monolithisch aufzubauen, werden diese in kleinere Einheiten aufgeteilt (Microservices), die jeweils einen Teilaspekt der Anwendung bereitstellen. Ein Microservice kann relativ leicht ausgetauscht werden, um zum Beispiel Fehler zu beheben. Wenn ein Service in einer Cloud-Umgebung läuft, ist es wichtig, dass das Aktualisieren dieser Komponente ohne Probleme und mit möglichst wenig Ausfallzeit durchgeführt werden kann (Continuous Deployment). Dies lässt sich erreichen, indem man jeweils einen Service in einem Container bereitstellt.

Mit der Containervirtualisierung gibt es eine gute Möglichkeit, Anwendungen zusammenzustellen und auszuführen. Wird die Anwendung produktiv eingesetzt, so müssen die Container, in denen die Anwendungen laufen, verwaltet werden. Es muss sichergestellt werden, dass es keine Ausfallzeiten gibt. Fällt zum Beispiel ein Container aus, so muss ein anderer Container gestartet werden.

Kubernetes bietet nun ein Framework an, mit dem solche verteilten, auf Container basierenden Systeme ausfallsicher betrieben werden können. Das System kümmert sich um Skalierung und Failover für die laufenden Container. Kubernetes übernimmt das Bereitstellen (Deployment) der Container und überwacht deren Status.

Kubernetes bietet folgendes an:^[16]

• Service-Discovery und Lastausgleich: Stellt Kubernetes fest, dass das Datenaufkommen zu einem Container hoch ist, dann ist das System in der Lage, einen Lastausgleich durchzuführen und den Netzwerkverkehr so zu verteilen, dass die Bereitstellung stabil ist.
• Speicherorchestrierung: Kubernetes kann unterschiedliche Speichersysteme einbinden, z. B. lokale Speicher, öffentliche Cloud-Anbieter und mehr. Die Anwendung, die in einem Container läuft, muss nicht angepasst werden und verwendet die Schnittstelle, die Kubernetes anbietet.
• Automatisierte Rollouts und Rollbacks: Anstatt eine Schritt für Schritt Installationsanweisung zu schreiben, um eine Software zu installieren, wird bei Kubernetes nur der gewünschte Ziel-Zustand für die bereitgestellten Container beschrieben. Kubernetes ändert dann den tatsächlichen Zustand zu dem gewünschten Zustand mit einer kontrollierten Rate.
• Automatisches Bin Packing: Der Administrator stellt Kubernetes einen Cluster von Knoten zur Verfügung, den es zur Ausführung von containerisierten Aufgaben verwenden kann. Zudem wird Kubernetes mitgeteilt, wie viel CPU und Speicher (RAM) jeder Container benötigt. Kubernetes wird dann die Container so auf die Knoten verteilen, dass die Ressourcen optimal genutzt werden.
• Selbstheilung: Kubernetes startet Container bei Ausfall neu und ersetzt und stoppt Container, wenn diese nicht auf eine benutzerdefinierte Prüfung reagieren. Container werden von Kubernetes erst dann den Clients verfügbar gemacht, wenn diese arbeitsfähig sind.

Cloud-Provider bieten jeweils eine Kubernetes-Umgebung an, in der der Kunde seine Container laufen lassen kann. Durch das Kubernetes-Framework wird sichergestellt, dass die Anwendung im Produktivbetrieb in der Weise läuft, wie während der Entwicklung getestet.

Aufbau

Schematischer Aufbau

Kubernetes orchestriert sogenannte „Pods“ als kleinste einsetzbare Einheit. Pods beinhalten einen oder auch mehrere Container, die sich dann eine Container-Runtime und die zugeteilten Ressourcen teilen. Pods werden auf „Nodes“ (physische oder virtuelle Maschinen in einem Cluster) deployed und ausgeführt.

Der Cluster mit seinen Nodes wird über eine dedizierte Maschine, den „Kubernetes Control Plane“, gesteuert, der mit den einzelnen Nodes über die, in diesen laufenden, „Kubelets“ kommuniziert. Auf dem Kubernetes Control Plane laufen eine Instanz des etcd, der zentralen Schlüssel-Wert-Datenbank für sämtliche für das Management des Clusters wichtigen Informationen, sowie die automatisierten Controllerprozesse und ein „Scheduler“, der neu erzeugte Pods einem Node zuteilt.

Die Controller überwachen und steuern den Cluster und seine Bestandteile. Sie können z. B. ausgefallene Nodes durch identische Nodes ersetzen.^[17]

Architektur

Kubernetes ist nach der sogenannten Master-Slave-Architektur aufgebaut. Der Control Plane (Master) steuert mit seinen Komponenten die Nodes (Minions), auf welchen die Container laufen.

Kubernetes Control Plane

Der Kubernetes Control Plane (ehem. Master) ist die Steuereinheit des Clusters, welcher die Pods und die darin enthaltenen Container auf die Nodes verteilt und verwaltet. Zur Verwaltung dieser Aufgaben existieren mehrere Prozesse. Diese können auf einem einzelnen Control Plane oder – zwecks Hochverfügbarkeit – auf mehreren verteilt sein. Die Prozesse teilen sich auf in:

etcd

Der etcd ist eine von CoreOS entwickelte persistente, leichtgewichtige, verteilte Key-Value-Datenbank zur Speicherung der Konfiguration des Kubernetes Clusters. Diese enthält den Gesamtstatus des Clusters und wird vom API-Server unterhalten.

API Server

Der API Server ist eine der wichtigsten Komponenten der Architektur. Er versorgt alle anderen Komponenten bzw. Dienste, interne wie externe, mit JSON-formatierten Informationen über eine REST-Schnittstelle. Der API Server speichert alle Informationen persistent im etcd. Die Autorisierung kann über verschiedene Mechanismen erfolgen.

Scheduler

Der Scheduler entscheidet als eigenständige Komponente, auf welchem Node ein Pod gestartet wird. Dies ist abhängig von den zur Verfügung stehenden Ressourcen. Er verwaltet die Auslastung der Nodes und überwacht deren Last. Dafür muss der Scheduler die Anforderungen an die Ressourcen eines jeden Pods kennen. Berücksichtigt werden dabei Richtlinien wie QoS, Node-Zugehörigkeiten und z. B. Orte der Nodes im Cluster (Rechenzentren).

Controller Manager

Der Controller Manager ist jener Prozess, welcher alle Kontrollmechanismen enthält, in dem z. B. ein DaemonSet oder ein Replication Controller laufen. Er kommuniziert mit dem API Server, um alle Status zu lesen und zu schreiben.

Kubernetes Node

Der Kubernetes Node, auch Minion genannt, ist ein einzelner Server für Container. Dazu ist auf jedem dieser Nodes eine Container-Laufzeitumgebung installiert (z. B. Docker oder rkt (Rocket)) sowie die unten beschriebenen Komponenten:

Kubelet

Der Kubelet ist für den Status jedes Nodes verantwortlich. Er wird vom Controller Manager gesteuert und übernimmt das Starten und Stoppen von Containern. Wenn ein Container nicht mehr läuft, sorgt das Kubelet auch für den Neustart auf dem gleichen Node. Alle paar Sekunden rapportiert er an den Kubernetes Control Plane über seinen Status. Bei einem Fehler oder der Nichterreichbarkeit des Nodes erkennt der Control Plane dies aufgrund des nicht gemeldeten Status'. Der Controller Manager startet dann die Pods auf anderen „gesunden“ Nodes erneut.

Kube-Proxy

Der Kube-Proxy ist ein Proxy mit integrierter Lastausgleichsfunktion. Er öffnet die Ports zu den Container-Services und verwaltet die Verbindungen.

cAdvisor

Der cAdvisor ist im Kubelet integriert und zeichnet die Ressourcen eines Containers auf (CPU, Memory). Andere Monitoring-Lösungen können diesen Dienst konsultieren, um Langzeitaufzeichnungen anzubieten.

Microservices

Kubernetes wird häufig als eine Möglichkeit verwendet, eine auf Microservices basierende Implementierung zu hosten. Zusammen mit einer Palette an Werkzeugen bietet es alle Fähigkeiten, die erforderlich sind, um zentrale Probleme einer Microservice-Architektur zu lösen.

Literatur

• Kelsey Hightower: Kubernetes : eine kompakte Einführung. dpunkt.verlag, Heidelberg 2018, ISBN 978-3-86490-542-1. 
• Sébastien Goasguen: Kubernetes Cookbook : Building Cloud Native Applications. O'Reilly, 2018, ISBN 978-1-4919-7968-6. 
• Bilgin Ibryam, Roland Huß: Kubernetes Patterns : Reusable Elements for Designing Cloud-Native Applications. O'Reilly, 2019, ISBN 978-1-4920-5028-5. 

Weblinks

• Offizielle Website
• Kubernetes-Quellcode auf Github
• Kubernetes: Architektur und Einsatz – Eine Einführung mit Beispielen
• Why cloud-native open source Kubernetes matters (Engl.)

Einzelnachweise

1. ↑ First GitHub commit for Kubernetes. In: github.com. 7. Juni 2014.
2. ↑ Kubernetes 1.23: The Next Frontier. 7. Dezember 2021 (englisch, abgerufen am 7. Dezember 2021).
3. ↑ github.com. 7. Dezember 2021 (abgerufen am 7. Dezember 2021).
4. ↑ What is Kubernetes? – Kubernetes
5. ↑ Kubernetes on Microsoft’s Azure Container Service is now generally available auf techcrunch.com vom 21. Februar 2017.
6. ↑ Kubernetes now available on IBM Bluemix Container Service auf ibm.com vom 19. März 2017.
7. ↑ Why Red Hat Chose Kubernetes for OpenShift auf blog.openshift.com vom 7. November 2016.
8. ↑ Highly available and scalable Kubernetes service
9. ↑ Googles Kubernetes Engine
10. ↑ Überblick über Container Engine for Kubernetes, auf docs.cloud.oracle.com
11. ↑ Avi Miller: Announcing Oracle Container Services 1.1.9 for use with Kubernetes. (oracle.com [abgerufen am 23. April 2018]). 
12. ↑ Google Made Its Secret Blueprint Public to Boost Its Cloud (en-US) Abgerufen am 7. Juli 2017.
13. ↑ Cade Metz: Google Open Sources Its Secret Weapon in Cloud Computing. In: Wired. 10. Juni 2014, ISSN 1059-1028 (wired.com [abgerufen am 29. Juli 2019]). 
14. ↑ Google veröffentlicht Vollversion Kubernetes 1.0. In: ZDNet.de. 22. Juli 2015.
15. ↑ Cloud Native Computing Foundation soll Container-Technologien zusammenbringen. In: pro-linux.de. 22. Juni 2015. Abgerufen am 7. Juli 2017.
16. ↑ What is Kubernetes? Abgerufen am 5. April 2021 (englisch). 
17. ↑ Kubernetes Components. Webseite kubernetes.io, abgerufen am 8. Juli 2017 (amerikanisches Englisch).