Kubernetes
 | |
| Ursprüngliche(r) Autor(en) | |
|---|---|
| Entwickler(n) | Stiftung für Cloud Native Computing |
| Erste Veröffentlichung | 7. Juni 2014; vor 8 Jahren |
| Geschrieben in. | Go |
| Typ | Cluster-Management-Software |
| Lizenz | Apache-Lizenz 2.0 |
| Website | kubernetes.io |
Kubernetes (/ˌk(j)uːbərˈnɛtɪs, -ˈneɪtɪs, -ˈneɪtiːz, -ˈnɛtiːz/, umgangssprachlich K8s) ist ein Open-Source-Container-Orchestrierungssystem zur Automatisierung der Softwarebereitstellung, -skalierung und -verwaltung. Ursprünglich wurde Kubernetes von Google entwickelt, doch inzwischen wird das Projekt von der Cloud Native Computing Foundation verwaltet. ⓘ
Kubernetes arbeitet mit Docker, Containerd und CRI-O zusammen. Ursprünglich arbeitete es ausschließlich mit der Docker-Laufzeitumgebung über einen "Dockershim" zusammen; von 2016 bis April 2022 hat Kubernetes jedoch den Shim zugunsten einer direkten Schnittstelle mit dem Container über Containerd veraltet oder Docker durch eine Laufzeitumgebung ersetzt, die mit dem Container Runtime Interface (CRI) konform ist. Mit der Veröffentlichung von v1.24 im Mai 2022 wurde der "Dockershim" vollständig entfernt. ⓘ
Amazon, Google, IBM, Microsoft, Oracle, Red Hat, SUSE, Platform9 und VMware bieten Kubernetes-basierte Plattformen oder Infrastructure as a Service (IaaS) an, die Kubernetes einsetzen. ⓘ
Geschichte
Kubernetes (κυβερνήτης, griechisch für "Steuermann", "Pilot" oder "Gouverneur" und die etymologische Wurzel der Kybernetik) wurde Mitte 2014 von Google angekündigt. Das Projekt wurde von Joe Beda, Brendan Burns und Craig McLuckie entwickelt, denen sich bald weitere Google-Ingenieure anschlossen, darunter Brian Grant und Tim Hockin. ⓘ
Das Design und die Entwicklung von Kubernetes wurden von Googles Borg-Cluster-Manager beeinflusst. Sie nannten Kubernetes "Project 7" nach der Star Trek-Ex-Borg-Figur Seven of Nine und gaben dem Logo ein Rad mit sieben Speichen. Im Gegensatz zu Borg, das in C++ geschrieben wurde, ist der Quellcode von Kubernetes in der Sprache Go verfasst. ⓘ
Kubernetes 1.0 wurde am 21. Juli 2015 veröffentlicht. Google arbeitete mit der Linux Foundation zusammen, um die Cloud Native Computing Foundation (CNCF) zu gründen und Kubernetes als Seed-Technologie anzubieten. Im Februar 2016 wurde der Paketmanager Helm für Kubernetes veröffentlicht. Am 6. März 2018 erreichte das Kubernetes-Projekt den neunten Platz in der Liste der GitHub-Projekte nach der Anzahl der Commits und den zweiten Platz nach Autoren und Issues, nach dem Linux-Kernel. ⓘ
Bis Version 1.18 verfolgte Kubernetes eine N-2-Support-Politik, was bedeutet, dass die drei neuesten Unterversionen Sicherheitsupdates und Fehlerbehebungen erhalten. Ab Version 1.19 folgt Kubernetes einer N-3-Support-Politik. ⓘ
Konzepte
Kubernetes definiert eine Reihe von Bausteinen ("Primitives"), die gemeinsam Mechanismen für die Bereitstellung, Wartung und Skalierung von Anwendungen auf der Grundlage von CPU-, Speicher- oder benutzerdefinierten Metriken bereitstellen. Kubernetes ist lose gekoppelt und erweiterbar, um verschiedenen Arbeitslasten gerecht zu werden. Sowohl die internen Komponenten als auch Erweiterungen und Container, die auf Kubernetes laufen, basieren auf der Kubernetes-API. Die Plattform übt ihre Kontrolle über Rechen- und Speicherressourcen aus, indem sie Ressourcen als Objekte definiert, die dann auch als solche verwaltet werden können. ⓘ
Kubernetes folgt der primären/replizierenden Architektur. Die Komponenten von Kubernetes lassen sich in solche, die einen einzelnen Knoten verwalten, und solche, die Teil der Steuerungsebene sind, unterteilen. ⓘ
Steuerebene
Der Kubernetes-Master ist die Hauptsteuerungseinheit des Clusters, die dessen Arbeitslast verwaltet und die Kommunikation im gesamten System steuert. Die Kubernetes-Kontrollebene besteht aus verschiedenen Komponenten, die jeweils einen eigenen Prozess darstellen und sowohl auf einem einzelnen Master-Knoten als auch auf mehreren Mastern laufen können, die hochverfügbare Cluster unterstützen. Die verschiedenen Komponenten der Kubernetes-Kontrollebene sind wie folgt:
- etcd ist ein persistenter, leichtgewichtiger, verteilter Key-Value-Datenspeicher, den CoreOS entwickelt hat. Er speichert zuverlässig die Konfigurationsdaten des Clusters, die den Gesamtzustand des Clusters zu jedem beliebigen Zeitpunkt darstellen. etcd bevorzugt im Falle einer Netzwerkpartition die Konsistenz gegenüber der Verfügbarkeit (siehe CAP-Theorem). Die Konsistenz ist entscheidend für die korrekte Planung und den Betrieb von Diensten.
- Der API-Server stellt die Kubernetes-API mithilfe von JSON über HTTP bereit, die sowohl die interne als auch die externe Schnittstelle zu Kubernetes bildet. Der API-Server verarbeitet und validiert REST-Anfragen und aktualisiert den Status der API-Objekte in etcd, so dass Clients Workloads und Container über Worker Nodes hinweg konfigurieren können. Der API-Server verwendet die Watch-API von etcd, um den Cluster zu überwachen, kritische Konfigurationsänderungen vorzunehmen oder den Zustand des Clusters wiederherzustellen, den der Deployer angegeben hat, falls er davon abweicht. Der Deployer kann zum Beispiel angeben, dass drei Instanzen eines bestimmten "Pods" (siehe unten) laufen müssen. etcd speichert diese Tatsache. Wenn der Deployment Controller feststellt, dass nur zwei Instanzen laufen (was im Widerspruch zur etcd-Deklaration steht), plant er die Erstellung einer zusätzlichen Instanz dieses Pods.
- Der Scheduler ist die erweiterbare Komponente, die auf der Grundlage der Ressourcenverfügbarkeit auswählt, auf welchem Knoten ein ungeplanter Pod (die vom Scheduler verwaltete Basiseinheit) läuft. Der Scheduler verfolgt die Ressourcennutzung auf jedem Knoten, um sicherzustellen, dass die Arbeitslast nicht über die verfügbaren Ressourcen hinaus geplant wird. Zu diesem Zweck muss der Scheduler die Ressourcenanforderungen, die Ressourcenverfügbarkeit und andere benutzerdefinierte Einschränkungen oder Richtlinien wie Quality-of-Service, Affinitäts- bzw. Anti-Affinitätsanforderungen und Datenlokalität kennen. Die Aufgabe des Schedulers besteht darin, das "Angebot" an Ressourcen mit dem "Bedarf" an Arbeitslasten abzugleichen.
- Ein Controller ist eine Abgleichsschleife, die den tatsächlichen Clusterzustand in Richtung des gewünschten Zustands steuert und mit dem API-Server kommuniziert, um die von ihm verwalteten Ressourcen (z. B. Pods oder Dienstendpunkte) zu erstellen, zu aktualisieren und zu löschen. Eine Art von Controller ist ein Replikations-Controller, der die Replikation und Skalierung übernimmt, indem er eine bestimmte Anzahl von Kopien eines Pods im gesamten Cluster ausführt. Er kümmert sich auch um die Erstellung von Ersatz-Pods, wenn der zugrunde liegende Knoten ausfällt. Weitere Controller, die zum Kubernetes-Kernsystem gehören, sind ein DaemonSet-Controller, der genau einen Pod auf jeder Maschine (oder einer Teilmenge von Maschinen) ausführt, und ein Job-Controller, der Pods ausführt, die bis zum Ende laufen, z. B. als Teil eines Batch-Jobs. Label-Selektoren, die Teil der Controller-Definition sind, geben die Menge der Pods an, die ein Controller verwaltet.
- Der Controller-Manager ist ein Prozess, der eine Reihe von Kubernetes-Kern-Controllern verwaltet. ⓘ
Knoten
Ein Knoten, auch Worker oder Minion genannt, ist ein Rechner, auf dem Container (Workloads) bereitgestellt werden. Jeder Knoten im Cluster muss eine Container-Laufzeitumgebung wie Docker sowie die unten genannten Komponenten für die Kommunikation mit dem primären Netzwerk für die Konfiguration dieser Container ausführen.
- Kubelet ist für den Betriebszustand eines jeden Knotens verantwortlich und stellt sicher, dass alle Container auf dem Knoten in Ordnung sind. Es kümmert sich um das Starten, Stoppen und Warten von Anwendungscontainern, die in Pods organisiert sind, wie von der Steuerungsebene angewiesen. Kubelet überwacht den Zustand eines Pods, und wenn dieser nicht dem gewünschten Zustand entspricht, wird der Pod erneut auf denselben Knoten deployed. Der Status des Knotens wird alle paar Sekunden über Heartbeat-Nachrichten an den primären Knoten weitergegeben. Sobald der primäre Knoten einen Ausfall feststellt, beobachtet der Replication Controller diese Zustandsänderung und startet Pods auf anderen gesunden Knoten.
- Kube-proxy ist eine Implementierung eines Netzwerk-Proxys und eines Load Balancers und unterstützt die Dienstabstraktion zusammen mit anderen Netzwerkoperationen. Er ist für die Weiterleitung des Datenverkehrs an den entsprechenden Container auf der Grundlage der IP- und Port-Nummer der eingehenden Anfrage verantwortlich.
- Ein Container befindet sich innerhalb eines Pods. Der Container ist die unterste Ebene eines Mikrodienstes, der die laufende Anwendung, Bibliotheken und deren Abhängigkeiten enthält. Container können der Welt über eine externe IP-Adresse zugänglich gemacht werden. Kubernetes unterstützt Docker-Container seit seiner ersten Version. Im Juli 2016 wurde die Container-Engine rkt hinzugefügt. ⓘ
Namespaces
Kubernetes bietet eine Partitionierung der von ihm verwalteten Ressourcen in nicht überlappende Gruppen, die Namespaces genannt werden. Sie sind für den Einsatz in Umgebungen mit vielen Benutzern gedacht, die über mehrere Teams oder Projekte verteilt sind, oder sogar für die Trennung von Umgebungen wie Entwicklung, Test und Produktion. ⓘ
Pods
Die grundlegende Planungseinheit in Kubernetes ist ein Pod, der aus einem oder mehreren Containern besteht, die sich garantiert auf demselben Knoten befinden. Jedem Pod in Kubernetes wird eine eindeutige IP-Adresse innerhalb des Clusters zugewiesen, so dass Anwendungen Ports ohne das Risiko von Konflikten nutzen können. Innerhalb des Pods können sich alle Container gegenseitig referenzieren. Die Container können auch in verschiedenen IP-Segmenten ausgeführt werden. Damit jedoch ein Container innerhalb eines Pods auf einen anderen Container innerhalb eines anderen Pods zugreifen kann, muss er die IP-Adresse des Pods verwenden. Pod-IP-Adressen sind jedoch flüchtig; daher sollte ein Anwendungsentwickler niemals fest kodierte Pod-IP-Adressen verwenden, da der spezifische Pod, auf den er verweist, beim Neustart einer anderen Pod-IP-Adresse zugewiesen werden könnte. Stattdessen sollten sie einen Verweis auf einen Dienst (siehe unten) verwenden, der einen Verweis auf den Ziel-Pod unter der spezifischen Pod-IP-Adresse enthält. ⓘ
Ein Pod kann ein Volume definieren, z. B. ein lokales Festplattenverzeichnis oder eine Netzwerkfestplatte, und es den Containern im Pod zur Verfügung stellen. Pods können manuell über die Kubernetes-API verwaltet werden, oder ihre Verwaltung kann an einen Controller delegiert werden. Solche Volumes sind auch die Grundlage für die Kubernetes-Funktionen ConfigMaps (für den Zugriff auf die Konfiguration über das für den Container sichtbare Dateisystem) und Secrets (für den Zugriff auf Anmeldedaten, die für den sicheren Zugriff auf entfernte Ressourcen erforderlich sind, indem diese Anmeldedaten im Dateisystem bereitgestellt werden, das nur für autorisierte Container sichtbar ist). ⓘ
DaemonSets
Normalerweise entscheidet der Kubernetes Scheduler, wo die Pods ausgeführt werden. In einigen Anwendungsfällen kann es jedoch erforderlich sein, einen Pod auf jedem einzelnen Knoten im Cluster auszuführen. Dies ist nützlich für Anwendungsfälle wie Protokollsammlung, Ingress-Controller und Speicherdienste. DaemonSets implementieren diese Art der Pod-Planung. ⓘ
ReplicaSets
Ein ReplicaSet hat die Aufgabe, einen stabilen Satz von Replica-Pods aufrechtzuerhalten, die zu einem bestimmten Zeitpunkt laufen. Daher wird es häufig verwendet, um die Verfügbarkeit einer bestimmten Anzahl identischer Pods zu gewährleisten. ⓘ
ReplicaSets können auch als Gruppierungsmechanismus bezeichnet werden, der es Kubernetes ermöglicht, die Anzahl der Instanzen zu verwalten, die für einen bestimmten Pod deklariert wurden. Die Definition eines ReplicaSets verwendet einen Selektor, dessen Auswertung zur Identifizierung aller damit verbundenen Pods führt. ⓘ
Dienste
Ein Kubernetes-Dienst ist eine Gruppe von Pods, die zusammenarbeiten, wie z. B. eine Schicht einer mehrschichtigen Anwendung. Die Pods, aus denen ein Dienst besteht, werden durch einen Label-Selektor definiert. Kubernetes bietet zwei Arten der Service-Erkennung: über Umgebungsvariablen oder über Kubernetes DNS. Bei der Diensterkennung werden dem Dienst eine stabile IP-Adresse und ein DNS-Name zugewiesen, und der Datenverkehr wird nach dem Round-Robin-Prinzip auf die Netzwerkverbindungen dieser IP-Adresse unter den Pods verteilt, die dem Selektor entsprechen (selbst wenn die Pods aufgrund von Ausfällen von Maschine zu Maschine wandern). Standardmäßig wird ein Dienst innerhalb eines Clusters bereitgestellt (z. B. können Backend-Pods in einem Dienst gruppiert werden, wobei die Anfragen von den Front-End-Pods auf sie verteilt werden), aber ein Dienst kann auch außerhalb eines Clusters bereitgestellt werden (z. B. für Clients, um Front-End-Pods zu erreichen). ⓘ
Volumes
Die Dateisysteme im Kubernetes-Container bieten standardmäßig ephemeren Speicher. Das bedeutet, dass bei einem Neustart des Pods alle Daten in solchen Containern gelöscht werden, weshalb diese Form der Speicherung nur für triviale Anwendungen geeignet ist. Ein Kubernetes-Volume bietet persistenten Speicher, der für die Lebensdauer des Pods selbst existiert. Dieser Speicher kann auch als gemeinsam genutzter Festplattenspeicher für Container innerhalb des Pods verwendet werden. Volumes werden an bestimmten Einhängepunkten innerhalb des Containers eingehängt, die durch die Pod-Konfiguration definiert sind, und können nicht auf andere Volumes eingehängt oder mit anderen Volumes verbunden werden. Ein und dasselbe Volume kann von verschiedenen Containern an unterschiedlichen Stellen im Dateisystembaum eingehängt werden. ⓘ
ConfigMaps und Geheimnisse
Eine häufige Anwendungsherausforderung ist die Entscheidung darüber, wo Konfigurationsinformationen gespeichert und verwaltet werden sollen, von denen einige sensible Daten enthalten können. Bei den Konfigurationsdaten kann es sich sowohl um einzelne Eigenschaften als auch um grobkörnige Informationen wie ganze Konfigurationsdateien oder JSON/XML-Dokumente handeln. Kubernetes bietet zwei eng verwandte Mechanismen, um diesem Bedarf gerecht zu werden: "Configmaps" und "Secrets", die es ermöglichen, Konfigurationsänderungen vorzunehmen, ohne dass ein Build der Anwendung erforderlich ist. Die Daten von Configmaps und Secrets werden jeder einzelnen Instanz der Anwendung, an die diese Objekte über das Deployment gebunden wurden, zur Verfügung gestellt. Ein Geheimnis und/oder eine Configmap wird nur dann an einen Knoten gesendet, wenn ein Pod auf diesem Knoten sie benötigt. Kubernetes behält es im Speicher dieses Knotens. Sobald der Pod, der von dem Secret oder der Configmap abhängt, gelöscht wird, wird auch die In-Memory-Kopie aller gebundenen Secrets und Configmaps gelöscht. Die Daten sind für den Pod auf zwei Arten zugänglich: a) als Umgebungsvariablen (die von Kubernetes beim Start des Pods erstellt werden) oder b) im Container-Dateisystem, das nur vom Pod aus sichtbar ist. ⓘ
Die Daten selbst werden auf dem Master gespeichert, einem hochsicheren Rechner, auf den niemand Zugriff haben sollte. Der größte Unterschied zwischen einem Secret und einer Configmap ist, dass der Inhalt der Daten in einem Secret base64-kodiert ist. Neuere Versionen von Kubernetes unterstützen auch die Verwendung von Verschlüsselung. Secrets werden häufig zum Speichern von Daten wie Zertifikaten, Passwörtern, Pull-Secrets (Anmeldeinformationen für die Arbeit mit Image-Registries) und SSH-Schlüsseln verwendet. ⓘ
StatefulSets
Die Skalierung zustandsloser Anwendungen ist nur eine Frage des Hinzufügens weiterer laufender Pods. Stateful-Workloads sind schwieriger, da der Status erhalten bleiben muss, wenn ein Pod neu gestartet wird. Wenn die Anwendung nach oben oder unten skaliert wird, muss der Status möglicherweise neu verteilt werden. Datenbanken sind ein Beispiel für zustandsabhängige Workloads. Wenn sie im Hochverfügbarkeitsmodus ausgeführt werden, verfügen viele Datenbanken über eine primäre und eine sekundäre Instanz. In diesem Fall ist der Begriff der Reihenfolge der Instanzen wichtig. Andere Anwendungen, wie z. B. Apache Kafka, verteilen die Daten auf ihre Broker; daher ist ein Broker nicht mit einem anderen identisch. In diesem Fall ist der Begriff der Einzigartigkeit der Instanz wichtig. ⓘ
StatefulSets sind Controller (siehe oben), die die Eigenschaften der Eindeutigkeit und Ordnung zwischen den Instanzen eines Pods erzwingen und zur Ausführung zustandsabhängiger Anwendungen verwendet werden können. ⓘ
Replikationscontroller und Bereitstellungen
Ein ReplicaSet deklariert die Anzahl der Instanzen eines Pods, die benötigt werden, und ein Replication Controller verwaltet das System so, dass die Anzahl gesunder Pods, die ausgeführt werden, mit der Anzahl der Pods übereinstimmt, die im ReplicaSet deklariert sind (ermittelt durch Auswertung des Selektors). ⓘ
Deployments sind ein übergeordneter Verwaltungsmechanismus für ReplicaSets. Während der Replication Controller die Skalierung des ReplicaSets verwaltet, verwalten Deployments, was mit dem ReplicaSet geschieht - ob eine Aktualisierung ausgerollt oder zurückgerollt werden muss, usw. Wenn Deployments nach oben oder unten skaliert werden, führt dies dazu, dass sich die Deklaration des ReplicaSets ändert - und diese Änderung des deklarierten Zustands wird vom Replication Controller verwaltet. ⓘ
Bezeichnungen und Selektoren
Kubernetes ermöglicht es Clients (Benutzern oder internen Komponenten), jedem API-Objekt im System, z. B. Pods und Nodes, Schlüssel, so genannte "Labels", zuzuweisen. Dementsprechend sind "Label-Selektoren" Abfragen gegen Labels, die zu passenden Objekten führen. Bei der Definition eines Dienstes können die Label-Selektoren definiert werden, die vom Dienst-Router/Load-Balancer verwendet werden, um die Pod-Instanzen auszuwählen, an die der Datenverkehr weitergeleitet wird. So kann durch einfaches Ändern der Labels der Pods oder der Label-Selektoren des Dienstes gesteuert werden, welche Pods Verkehr erhalten und welche nicht, wodurch verschiedene Bereitstellungsmuster wie Blue-Green-Bereitstellungen oder A-B-Tests unterstützt werden können. Diese Fähigkeit zur dynamischen Steuerung der Nutzung von Implementierungsressourcen durch Dienste ermöglicht eine lose Kopplung innerhalb der Infrastruktur. ⓘ
Wenn die Pods einer Anwendung beispielsweise Labels für eine Systemebene (mit Werten wie Frontend, Backend usw.) und einen release_track (mit Werten wie Canary, Production usw.) haben, kann eine Operation auf allen Backend- und Canary-Knoten einen Label-Selektor verwenden, z. B:
tier=backend AND release_track=canary ⓘ
Genau wie Labels ermöglichen auch Feldselektoren die Auswahl von Kubernetes-Ressourcen. Im Gegensatz zu Labels basiert die Auswahl auf den Attributwerten der ausgewählten Ressource und nicht auf einer benutzerdefinierten Kategorisierung. metadata.name und metadata.namespace sind Feldselektoren, die bei allen Kubernetes-Objekten vorhanden sind. Andere Selektoren, die verwendet werden können, hängen vom Objekt-/Ressourcentyp ab. ⓘ
Add-ons
Add-ons funktionieren wie jede andere Anwendung, die innerhalb des Clusters läuft: Sie werden über Pods und Dienste implementiert und unterscheiden sich nur dadurch, dass sie Funktionen des Kubernetes-Clusters implementieren. Die Pods können von Deployments, ReplicationControllers usw. verwaltet werden. Es gibt viele Add-ons, und die Liste wird immer länger. Einige der wichtigeren sind:
- DNS: Alle Kubernetes-Cluster sollten über Cluster-DNS verfügen; es ist eine obligatorische Funktion. Cluster-DNS ist ein DNS-Server, der zusätzlich zu den anderen DNS-Servern in Ihrer Umgebung DNS-Einträge für Kubernetes-Dienste bereitstellt. Container, die von Kubernetes gestartet werden, beziehen diesen DNS-Server automatisch in ihre DNS-Suche ein.
- Web-Benutzeroberfläche: Dies ist eine allgemeine, webbasierte Benutzeroberfläche für Kubernetes-Cluster. Sie ermöglicht Benutzern die Verwaltung und Fehlerbehebung von Anwendungen, die im Cluster laufen, sowie des Clusters selbst.
- Container-Ressourcen-Überwachung: Die Bereitstellung einer zuverlässigen Anwendungslaufzeit und die Möglichkeit, diese als Reaktion auf die Arbeitslast nach oben oder unten zu skalieren, setzt voraus, dass die Leistung der Arbeitslast kontinuierlich und effektiv überwacht werden kann. Container Resource Monitoring bietet diese Möglichkeit, indem es Metriken über Container in einer zentralen Datenbank aufzeichnet und eine Benutzeroberfläche zum Durchsuchen dieser Daten bereitstellt. Der cAdvisor ist eine Komponente auf einem Slave-Knoten, die eine begrenzte Fähigkeit zur Überwachung von Metriken bietet. Es gibt auch vollständige Metrik-Pipelines, wie z. B. Prometheus, die die meisten Überwachungsanforderungen erfüllen können.
- Protokollierung auf Clusterebene: Protokolle sollten unabhängig von Knoten, Pods oder Containern gespeichert werden und einen eigenen Lebenszyklus haben. Andernfalls können Ausfälle von Knoten oder Pods zum Verlust von Ereignisdaten führen. Die Fähigkeit, dies zu tun, wird als Protokollierung auf Clusterebene bezeichnet, und solche Mechanismen sind für die Speicherung von Containerprotokollen in einem zentralen Protokollspeicher mit Such-/Browsing-Schnittstelle verantwortlich. Kubernetes bietet keinen nativen Speicher für Protokolldaten, aber man kann viele bestehende Protokollierungslösungen in den Kubernetes-Cluster integrieren. ⓘ
Speicherung
Container wurden entwickelt, um Software portabel zu machen. Der Container enthält alle Pakete, die für die Ausführung eines Dienstes erforderlich sind. Das mitgelieferte Dateisystem macht Container extrem portabel und einfach in der Entwicklung zu verwenden. Ein Container kann ohne oder mit relativ wenigen Konfigurationsänderungen von der Entwicklung in den Test- oder Produktionsbetrieb verschoben werden. ⓘ
In der Vergangenheit war Kubernetes nur für zustandslose Dienste geeignet. Viele Anwendungen verfügen jedoch über eine Datenbank, die Persistenz erfordert, was zur Schaffung von persistentem Speicher für Kubernetes führt. Die Implementierung von persistentem Speicher für Container ist eine der größten Herausforderungen für Kubernetes-Administratoren, DevOps- und Cloud-Ingenieure. Container mögen zwar kurzlebig sein, aber immer mehr ihrer Daten sind es nicht. Daher muss sichergestellt werden, dass die Daten im Falle einer Beendigung des Containers oder eines Hardwareausfalls erhalten bleiben. Bei der Bereitstellung von Containern mit Kubernetes oder containerisierten Anwendungen stellen Unternehmen oft fest, dass sie persistenten Speicher benötigen. Sie müssen schnellen und zuverlässigen Speicher für Datenbanken, Root-Images und andere von den Containern verwendete Daten bereitstellen. ⓘ
Zusätzlich zur Landschaft hat die Cloud Native Computing Foundation (CNCF) weitere Informationen über Kubernetes Persistent Storage veröffentlicht, darunter einen Blog, der hilft, das Container Attached Storage Pattern zu definieren. Bei diesem Muster wird Kubernetes selbst als eine Komponente des Speichersystems oder -dienstes verwendet. ⓘ
Weitere Informationen über die relative Popularität dieser und anderer Ansätze finden sich auch in der Landschaftsumfrage der CNCF, die ergab, dass OpenEBS von MayaData und Rook - ein Speicherorchestrierungsprojekt - die beiden Projekte sind, die sich im Herbst 2019 am ehesten in der Evaluierung befinden. ⓘ
Container Attached Storage ist eine Art der Datenspeicherung, die mit der zunehmenden Verbreitung von Kubernetes entstanden ist. Der Container Attached Storage-Ansatz bzw. das Container Attached Storage-Muster stützt sich bei bestimmten Funktionen auf Kubernetes selbst, während es in erster Linie Block-, Datei- und Objektspeicher sowie Schnittstellen für Workloads bereitstellt, die auf Kubernetes laufen. ⓘ
Zu den gemeinsamen Merkmalen von Container Attached Storage gehören die Verwendung von Erweiterungen für Kubernetes, wie z. B. benutzerdefinierte Ressourcendefinitionen, und die Verwendung von Kubernetes selbst für Funktionen, die andernfalls separat für die Speicherung oder das Datenmanagement entwickelt und bereitgestellt werden müssten. Beispiele für Funktionen, die von benutzerdefinierten Ressourcendefinitionen oder von Kubernetes selbst bereitgestellt werden, sind die Wiederholungslogik, die von Kubernetes selbst bereitgestellt wird, und die Erstellung und Pflege eines Inventars verfügbarer Speichermedien und Volumes, die in der Regel über eine benutzerdefinierte Ressourcendefinition bereitgestellt wird. ⓘ
API
Eine Schlüsselkomponente der Kubernetes-Kontrollebene ist der API-Server, der eine HTTP-API bereitstellt, die sowohl von anderen Teilen des Clusters als auch von Endbenutzern und externen Komponenten aufgerufen werden kann. Bei dieser API handelt es sich um eine REST-API, die deklarativen Charakter hat. Es gibt zwei Arten von API-Ressourcen. Die meisten API-Ressourcen in der Kubernetes-API sind Objekte. Diese stellen eine konkrete Instanz eines Konzepts auf dem Cluster dar, z. B. einen Pod oder Namespace. Eine kleine Anzahl von API-Ressourcentypen sind "virtuell". Diese stellen eher Operationen als Objekte dar, wie z. B. eine Berechtigungsprüfung unter Verwendung der Ressource "subjectaccessreviews". API-Ressourcen, die Objekten entsprechen, werden im Cluster mit eindeutigen Bezeichnern für die Objekte dargestellt. Virtuelle Ressourcen haben keine eindeutigen Bezeichner. ⓘ
Operatoren
Kubernetes kann mit benutzerdefinierten Ressourcen erweitert werden. Diese API-Ressourcen stellen Objekte dar, die nicht Teil des Kubernetes-Standardprodukts sind. Diese Ressourcen können in einem laufenden Cluster durch dynamische Registrierung erscheinen und verschwinden. Cluster-Administratoren können benutzerdefinierte Ressourcen unabhängig vom Cluster aktualisieren. ⓘ
Custom Controllers sind ein weiterer Erweiterungsmechanismus. Diese interagieren mit benutzerdefinierten Ressourcen und ermöglichen eine echte deklarative API, die die Verwaltung des Lebenszyklus von benutzerdefinierten Ressourcen ermöglicht, die mit der Art und Weise, wie Kubernetes selbst konzipiert ist, übereinstimmt. Die Kombination aus benutzerdefinierten Ressourcen und benutzerdefinierten Controllern wird oft als (Kubernetes-)Operator bezeichnet. Der Hauptanwendungsfall für Operatoren besteht darin, das Ziel eines menschlichen Operators zu erfassen, der einen Dienst oder eine Reihe von Diensten verwaltet, und diese mithilfe von Automatisierung zu implementieren, wobei eine deklarative API diese Automatisierung unterstützt. Menschliche Operatoren, die sich um bestimmte Anwendungen und Dienste kümmern, verfügen über fundierte Kenntnisse darüber, wie sich das System verhalten sollte, wie es einzusetzen ist und wie bei Problemen zu reagieren ist. Beispiele für Probleme, die von Operatoren gelöst werden, sind das Erstellen und Wiederherstellen von Backups des Anwendungsstatus und die Durchführung von Upgrades des Anwendungscodes zusammen mit damit verbundenen Änderungen wie Datenbankschemata oder zusätzlichen Konfigurationseinstellungen. ⓘ
Cluster-API
Die gleichen API-Entwurfsprinzipien wurden verwendet, um eine API zur programmatischen Erstellung, Konfiguration und Verwaltung von Kubernetes-Clustern zu definieren. Diese wird als Cluster-API bezeichnet. Ein Schlüsselkonzept der API ist die Verwendung von Infrastructure as Software, d. h. die Vorstellung, dass die Kubernetes-Cluster-Infrastruktur selbst eine Ressource/ein Objekt ist, das wie alle anderen Kubernetes-Ressourcen verwaltet werden kann. Ebenso werden die Maschinen, aus denen der Cluster besteht, als Kubernetes-Ressource behandelt. Die API besteht aus zwei Teilen - der Kern-API und einer Provider-Implementierung. Die Provider-Implementierung besteht aus Cloud-Provider-spezifischen Funktionen, die es Kubernetes ermöglichen, die Cluster-API in einer Weise bereitzustellen, die gut in die Dienste und Ressourcen des Cloud-Providers integriert ist. ⓘ
Verwendet
Kubernetes wird häufig zum Hosten von Microservice-basierten Implementierungen verwendet, da es und das zugehörige Ökosystem von Tools alle Funktionen bieten, die zur Bewältigung der Hauptprobleme jeder Microservice-Architektur erforderlich sind. Es ist in drei Formen erhältlich: Open Source, kommerziell und verwaltet. Zu den Open-Source-Distributionen gehören das ursprüngliche Kubernetes, Amazon EKS-D, Red Hat OpenShift, VMware Tanzu, Mirantis Kubernetes Engine und D2iQ Kubernetes Platform. Zu den verwalteten Angeboten gehören GKE, Oracle Container Engine für Kubernetes, Amazon Elastic Kubernetes Service, IBM Kubernetes Service und Platform9 Managed Kubernetes. ⓘ
Zeitplan für die Veröffentlichung
Unterstützungszeiträume
Das folgende Diagramm veranschaulicht den Zeitraum, in dem jede Version unterstützt wird/wurde ⓘ
$wgTimelinePerlCommand korrekt festgelegt ist.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: ⓘ
Kubernetes Node
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. ⓘ