Kubernetes

Kubernetes
Kubernetes logo without workmark.svg
Originalautor (en) Google
Entwickler (en) Cloud Native Computing Foundation
Erstveröffentlichung 7. Juni 2014; Vor 8 Jahren[1]
Stabile Version
1.24.2[2]Edit this on Wikidata / 15. Juni 2022; Vor 51 Tagen
Repository
Geschrieben in gehen
Typ Cluster -Management -Software
Lizenz Apache -Lizenz 2.0
Webseite Kubernetes.io

Kubernetes (/ˌk(j)uːbərˈnɛtɪs, -ˈneɪtɪs, -ˈneɪtichz, -ˈnɛtichz/, häufig stilisiert als K8S[3]) ist ein Open Source Container Orchestrierung System zur Automatisierung Software-Bereitstellung, Skalierung und Management.[4][5] Google ursprünglich Kubernetes entworfen, aber die Cloud Native Computing Foundation Unterhält nun das Projekt.

Kubernetes arbeitet mit Docker, Container, und Cri.[6] Ursprünglich hat es ausschließlich mit der Docker -Laufzeit verbunden[7] durch ein "Dockershim"; Von 2016 bis April 2022 hat Kubernetes jedoch das veraltet Shim Um direkt mit dem Container durch Container zu verknüpfen oder Docker durch eine Laufzeit zu ersetzen, die mit der Container -Laufzeit -Schnittstelle (CRI) entspricht.[8][9][10] Mit der Veröffentlichung von V1.24 im Mai 2022 wurde "Dockershim" vollständig entfernt.[11]

Amazonas, Google, IBM, Microsoft, Orakel, roter Hut, Suse, Plattform9 und VMware Bieten Sie Kubernetes-basierte Plattformen an oder Infrastruktur als ein Service (IaaS), die Kubernetes bereitstellen.[12][13]

Geschichte

Google Kubernetes Engine Talk auf dem Google Cloud Summit

Kubernetes (κυβερνήτης, griechisch für "Steuermann, "Pilot" oder "Gouverneur" und die etymologische Wurzel von Kybernetik)[5] wurde Mitte 2014 von Google angekündigt.[14] Das Projekt wurde von Joe Beda, Brendan Burns und Craig McLuckie geschaffen.[15][16] Zu den bald anderen Google -Ingenieuren, darunter Brian Grant und Tim Hockin.[14]

Das Design und die Entwicklung von Kubernetes wurde von Google beeinflusst Borg Cluster -Manager. Viele seiner Top -Mitwirkenden hatten zuvor an Borg gearbeitet.[17][18] Sie haben Kubernetes mitgetauscht "Projekt 7" nach dem Star Trek ex-Borg Charakter Sieben von neun[19] und gab seinem Logo ein Sieben-Speichen-Rad. Im Gegensatz zu Borg, der in geschrieben wurde C ++,[17] Kubernetes -Quellcode ist in der gehen Sprache.

Kubernetes 1.0 wurde am 21. Juli 2015 veröffentlicht.[20] Google arbeitete mit dem Linux Foundation um die zu bilden Cloud Native Computing Foundation (CNCF)[21] und bieten Kubernetes als Samentechnologie. Im Februar 2016,[22] der Helm[23][24] Paketmanager für Kubernetes wurde veröffentlicht.

Im Jahr 2017 gewann Kubernetes den Container -Orchestrierungskrieg im heftigen Wettbewerb.[25] Google bot bereits verwaltete Kubernetes -Dienste an roter Hut unterstützte Kubernetes als Teil von OpenShift Seit Beginn des Kubernetes -Projekts im Jahr 2014.[26] Im Jahr 2017 ralierten die Hauptkonkurrenten jedoch in Kubernetes und kündigten an, native Unterstützung dafür hinzuzufügen:

Am 6. März 2018 erreichte das Kubernetes -Projekt den neunten Platz in der Liste von GitHub Projekte nach der Anzahl der sich verpflichtetund zweiter Platz in Autoren und Themen nach dem Linux Kernel.[32]

Bis Version 1.18 folgte Kubernetes einer N-2-Support-Richtlinie, was bedeutet, dass die drei neuesten kleineren Versionen Sicherheitsaktualisierungen und Fehlerbehebungen erhalten.[33] Ab Version 1.19 folgt Kubernetes einer N-3-Support-Richtlinie.[34]

Konzepte

Kubernetes Architekturdiagramm

Kubernetes definiert eine Reihe von Bausteinen ("Primitive"), die gemeinsam Mechanismen bereitstellen, die Anwendungen basierend auf CPU und Speicher bereitstellen, verwalten und skalieren[35] oder benutzerdefinierte Metriken.[36] Kubernetes ist locker verbunden und erweiterbar, um verschiedene Arbeitsbelastungen zu erfüllen. Die internen Komponenten sowie Erweiterungen und Container, die auf Kubernetes ausgeführt werden, basieren auf der Kubernetes -API.[37] Die Plattform übt ihre Kontrolle über Rechen- und Speicherressourcen aus, indem sie Ressourcen als Objekte definiert, die dann als solche verwaltet werden können.

Kubernetes folgt dem Primär-/Replika -Architektur. Die Komponenten von Kubernetes können in diejenigen unterteilt werden, die eine Person verwalten Knoten und diejenigen, die Teil der Kontrollebene sind.[37][38]

Kontrollebene

Der Kubernetes -Master ist die Hauptsteuerung des Clusters, die seine Arbeitsbelastung verwaltet und die Kommunikation über das System leitet. Die Kubernetes -Steuerebene besteht aus verschiedenen Komponenten, die jeweils ihren eigenen Prozess haben, die sowohl auf einem einzelnen Masterknoten als auch auf mehreren unterstützenden Meistern ausgeführt werden können Hochverfügbarkeitscluster.[38] Die verschiedenen Komponenten der Kubernetes -Steuerebene sind wie folgt:

  • etcd[39] ist ein anhaltend, leicht, verteilt, verteilt, Schlüsselwertdatenspeicher das Coreos hat sich entwickelt. Es speichert die Konfigurationsdaten des Clusters zuverlässig und repräsentiert den Gesamtzustand des Clusters zu einem bestimmten Zeitpunkt. ETCD bevorzugt die Konsistenz gegenüber der Verfügbarkeit im Falle einer Netzwerkpartition (siehe Cap -Theorem). Die Konsistenz ist entscheidend für die korrekte Planungs- und Betriebsdienste.
  • Das API -Server dient den Kubernetes API Verwendung JSON Über Http, die sowohl die interne als auch die externe Schnittstelle zu Kubernetes liefert.[37][40] Der API -Server verarbeitet und validiert SICH AUSRUHEN Anfragen und Aktualisierungen des Zustands der API Objekte in ETCD, sodass Clients Workloads und Container über Arbeiterknoten hinweg konfigurieren können.[41] Der API -Server verwendet die Watch -API von ETCD, um den Cluster zu überwachen, kritische Konfigurationsänderungen auszusetzen oder alle Abweichungen des Status des Clusters wieder auf das zurück zu sein, was der Deployer deklariert hat. Beispielsweise kann der Bergbeauftrager angeben, dass drei Instanzen eines bestimmten "Pod" (siehe unten) ausgeführt werden müssen. etcd speichert diese Tatsache. Wenn der Bereitstellungscontroller feststellt, dass nur zwei Instanzen ausgeführt werden (widersprüchlich mit der ETCD -Deklaration),[42] Es plant die Schaffung einer zusätzlichen Instanz dieses Pods.[38]
  • Das Planer ist die erweiterbare Komponente, die auswählt, auf der ein außerplanmäßiger Pod (die vom Scheduler verwaltete Basisentität) basierend auf der Verfügbarkeit von Ressourcen ausgeführt wird. Der Scheduler verfolgt die Ressourcenverwendung auf jedem Knoten, um sicherzustellen, dass die Arbeitsbelastung nicht mehr an den verfügbaren Ressourcen geplant ist. Zu diesem Zweck muss der Scheduler die Ressourcenanforderungen, die Verfügbarkeit von Ressourcen und andere von Benutzer bereitgestellte Einschränkungen oder Richtlinienrichtlinien wie die Qualitätsqualität, Affinität im Anti-Affinitätsanforderungen und Datenlokalität kennen. Die Aufgabe des Schedulers besteht darin, das "Angebot" des Ressourcenangebots "für die Arbeitsbelastungsnachfrage" anzupassen.[43]
  • A Regler ist eine Versöhnungsschleife, die den tatsächlichen Clusterzustand in Richtung des gewünschten Zustands antreibt und mit dem API -Server kommuniziert, um die von ihm verwalteten Ressourcen zu erstellen, zu aktualisieren und zu löschen (z. B. Pods oder Serviceendpunkte).[44][40] Eine Art von Controller ist ein Replikationscontroller, der die Replikation und Skalierung durch Ausführen einer bestimmten Anzahl von Kopien eines Pod über den Cluster übernimmt. Es werden auch erstellt, wenn der zugrunde liegende Knoten ausfällt.[44] Andere Controller, die Teil des Kernkubernetes -Systems sind, umfassen einen Daemonset -Controller, um genau einen Pod auf jeder Maschine (oder einer Teilmenge von Maschinen) auszuführen, und einen Jobcontroller zum Ausführen von Pods, die bis zur Fertigstellung ausgeführt werden, z. als Teil eines Batch -Jobs.[45] Labels -Selektoren, die Teil der Definition des Controllers sind, geben den Satz von Pods an, den ein Controller verwaltet.[46]
  • Das Controller Manager ist ein Prozess, der eine Reihe von Kernkubernetes -Controllern verwaltet.

Knoten

Ein Knoten, auch als Arbeiter oder Diener bezeichnet, ist eine Maschine, auf der Container (Workloads) bereitgestellt werden. Jeder Knoten im Cluster muss einen Container ausführen Laufzeit wie zum Beispiel Dockersowie die unten erwähnten Komponenten für die Kommunikation mit der primären für die Netzwerkkonfiguration dieser Container.

  • Kuberett ist für den laufenden Zustand jedes Knotens verantwortlich, um sicherzustellen, dass alle Behälter auf dem Knoten gesund sind. Es kümmert sich um das Starten, Stoppen und Wartung von Anwendungsbehältern, die in Pods organisiert sind, wie von der Kontrollebene angewiesen.[37][47] Kuberelet überwacht den Zustand eines Pods, und wenn nicht im gewünschten Zustand, wird der POD wieder auf denselben Knoten eingesetzt. Der Knotenstatus wird alle paar Sekunden über Heartbeat -Nachrichten an die Primärmeldungen weitergeleitet. Sobald der Primär einen Knotenfehler erkennt, beobachtet der Replikationscontroller diese Zustandsänderung und startet Pods an anderen gesunden Knoten.[48]
  • Kube-Proxy ist eine Implementierung von a Netzwerkproxy und ein Lastenausgleicherund es unterstützt die Dienstabstraktion zusammen mit anderen Netzwerkbetrieb.[37] Es ist dafür verantwortlich, den Verkehr an den entsprechenden Container basierend auf der IP- und Portnummer der eingehenden Anforderung zu leiten.
  • A Container wohnt in einer Schote. Der Container ist die niedrigste Ebene eines Mikrodieners, der die laufende Anwendung, die Bibliotheken und deren Abhängigkeiten enthält. Container können der Welt über eine externe IP -Adresse ausgesetzt werden. Kubernetes hat seit seiner ersten Version Docker -Container unterstützt. Im Juli 2016 die rkt Containermotor wurde hinzugefügt.[49]

Namespaces

Kubernetes bietet eine Partitionierung der Ressourcen, die sie verwaltet, in nicht überlappende Sets, die als Namespaces bezeichnet werden.[50] Sie sind für die Verwendung in Umgebungen gedacht, in denen viele Benutzer über mehrere Teams oder Projekte verfügen oder sogar Umgebungen wie Entwicklung, Test und Produktion trennen.

Pods

Die grundlegende Planungseinheit in Kubernetes ist ein Pod.[51] Dies besteht aus einem oder mehreren Containern, die garantiert auf demselben Knoten co-located werden.[37] Jedem Pod in Kubernetes wird innerhalb des Cluster eine eindeutige IP -Adresse zugewiesen, mit der Anwendungen Ports ohne Konfliktrisiko verwenden können.[52] Innerhalb des Pod können sich alle Behälter gegenseitig verweisen. Die Container können auch in unterschiedlichem IP -Segment ausgeführt werden. Damit ein Container innerhalb eines Pods auf einen anderen Container in einem anderen Pod zugreifen kann, muss er die Pod -IP -Adresse verwenden. Pod -IP -Adressen sind jedoch kurzlebig; Daher sollte ein Anwendungsentwickler niemals hartcodierte Pod -IP -Adressen verwenden, da der spezifische POD, auf den er sich bezieht, einer anderen Pod -IP -Adresse beim Neustart zugewiesen werden kann. Stattdessen sollten sie einen Verweis auf einen Dienst verwenden (siehe unten), der einen Verweis auf die Zielpod an der spezifischen Pod -IP -Adresse enthält.

Ein Pod kann ein Volumen wie ein lokales Festplattenverzeichnis oder eine Netzwerkscheibe definieren und den Containern in der POD aussetzen.[53] Pods können manuell über die Kubernetes -API verwaltet werden, oder ihr Management kann an einen Controller delegiert werden.[37] Solche Volumina sind auch die Grundlage für die Kubernetes -Funktionen von configMaps (um Zugriff auf Konfiguration über das Dateisystem zu gewährleisten, das im Container sichtbar ist) und Geheimnisse (um den Zugriff auf Anmeldeinformationen zu gewähren nur für autorisierte Behälter sichtbar).

Daemonsets

Normalerweise entscheidet der Kubernetes -Scheduler, wo Pods ausgeführt werden sollen. Für einige Anwendungsfälle könnte jedoch auf jedem einzelnen Knoten im Cluster einen Pod ausgeführt werden. Dies ist nützlich für Anwendungsfälle wie Protokollsammlung, Eindringlinge und Speicherdienste. Daemonsets implementieren diese Art von Pod -Planung.[54]

Repliken

Der Zweck eines Replikats ist es, einen stabilen Satz von Replik -Pods zu verwalten, die zu einem bestimmten Zeitpunkt ausgeführt werden. Daher wird häufig verwendet, um die Verfügbarkeit einer bestimmten Anzahl identischer Pods zu gewährleisten.[55]

Die Replikationen[56] kann auch als ein Gruppierungsmechanismus bezeichnet werden, mit dem Kubernetes die Anzahl der für eine bestimmten Pod deklarierten Fälle beibehalten. Die Definition eines Replikats verwendet einen Selektor, dessen Bewertung dazu führt, dass alle damit verbundenen Schoten identifiziert werden.

Dienstleistungen

Vereinfachte Ansicht zeigt, wie Dienste mit Pod -Netzwerken in einem Kubernetes -Cluster interagieren

Ein Kubernetes -Service ist eine Reihe von Pods, die zusammenarbeiten, wie z. B. eine Stufe von a Multi-Tier Anwendung. Die Menge von Pods, die einen Dienst bilden, werden von einem Etikett -Selektor definiert.[37] Kubernetes liefert zwei Modi von Service -EntdeckungVerwenden von Umgebungsvariablen oder mit Kubernetes -DNS.[57] Service Discovery weist eine stabile IP -Adresse und zu DNS -Name zum Service und laden Sie den Verkehr in a Round-Robin Art zu Netzwerkverbindungen dieser IP -Adresse unter den Pods, die dem Selektor entsprechen (auch wenn Fehler von den Pods von Maschine zu Maschine bewegen).[52] Standardmäßig wird ein Dienst in einem Cluster freigelegt (z. B.,, Back End Pods könnten in einen Dienst mit Anfragen der Front-End-Schoten eingeteilt werden.[58]

Bände

Dateisysteme im Kubernetes -Container bieten kurzlebiger Lagerung, standardmäßig. Dies bedeutet, dass ein Neustart des Pod alle Daten zu solchen Containern ausgelöscht wird, und daher ist diese Speicherform in alles andere als triviale Anwendungen einschränkend. Eine Kubernetes -Lautstärke[59] Bietet eine anhaltende Speicherung, die für die Lebensdauer des Pods selbst vorhanden ist. Dieser Speicher kann auch als gemeinsamer Speicherplatz für Container innerhalb der Pod verwendet werden. Die Volumina werden an bestimmten Mountspunkten innerhalb des Containers montiert, die durch die POD -Konfiguration definiert sind, und können nicht an anderen Volumina oder einer Verbindung zu anderen Volumina montiert werden. Das gleiche Volumen kann an verschiedenen Stellen im Dateisystembaum durch verschiedene Behälter montiert werden.

ConfigMaps und Geheimnisse

Eine gemeinsame Anwendungsherausforderung besteht darin, die Konfigurationsinformationen zu speichern und zu verwalten, von denen einige sensible Daten enthalten können. Konfigurationsdaten können alles so feinkörnig sein wie einzelne Eigenschaften oder grobe Informationen wie ganze Konfigurationsdateien oder JSON / XML-Dokumente. Kubernetes bietet zwei eng verwandte Mechanismen, um diesen Bedarf zu erfüllen: "ConfigMaps" und "Secrets", die beide Konfigurationsänderungen ermöglichen, ohne dass ein Anwendungsaufbau erforderlich ist. Die Daten von configMaps und Geheimnissen werden jeder einzelnen Instanz der Anwendung zur Verfügung gestellt, an die diese Objekte über die Bereitstellung gebunden wurden. Ein Geheimnis und/oder eine Konfiguration wird nur an einen Knoten gesendet, wenn ein Pod auf diesem Knoten dies erfordert. Kubernetes wird es auf diesem Knoten im Speicher halten. Sobald der Pod, der vom Geheimnis oder Konfiguration abhängt, gelöscht wurde, wird auch die In-Memory-Kopie aller gebundenen Geheimnisse und Konfigurationen gelöscht. Die Daten sind auf einen von zwei Arten für den POD zugänglich: a) als Umgebungsvariablen (die von Kubernetes erstellt werden, wenn der Pod gestartet wird) oder b) im Containerdateisystem verfügbar ist, das nur innerhalb des Pod sichtbar ist.

Die Daten selbst werden auf dem Master gespeichert, einem hochgesichtigen Maschine, auf den niemand einen Anmeldangriff haben sollte. Der größte Unterschied zwischen einem Geheimnis und einem ConfigMap besteht darin, dass der Inhalt der Daten in einem Geheimnis Base64 codiert ist. Jüngste Versionen von Kubernetes haben auch die Unterstützung für die Verwendung der Verschlüsselung eingeführt. Geheimnisse werden häufig verwendet, um Daten wie Zertifikate, Passwörter, Abzahlen von Geheimnissen (Anmeldeinformationen für die Arbeit mit Bildregistern) und SSH -Tasten zu speichern.

Staatliche Sets

Die skalierenden staatenlosen Anwendungen sind nur eine Frage des Hinzufügens von mehr laufenden Pods. Zustandsfägige Arbeitsbelastungen sind schwieriger, da der Staat erhalten bleiben muss, wenn ein Pod neu gestartet wird. Wenn die Anwendung nach oben oder unten skaliert wird, muss der Staat möglicherweise umverteilt werden. Datenbanken sind ein Beispiel für staatliche Workloads. Wenn Sie im Hochverfügbarkeitsmodus ausgeführt werden, sind viele Datenbanken mit dem Begriff einer primären Instanz- und Sekundärinstanzen ausgestattet. In diesem Fall ist der Begriff der Bestellung von Instanzen wichtig. Andere Anwendungen wie Apache Kafka Die Daten auf ihre Makler verteilen; Daher ist ein Broker nicht dasselbe wie ein anderer. In diesem Fall ist der Begriff der Einzigartigkeit der Instanz wichtig.

Staatliche Sets[60] sind Controller (siehe oben), die die Eigenschaften der Einzigartigkeit und Ordnung zwischen den Fällen eines Pods durchsetzen und zum Ausführen staatlicher Anwendungen verwendet werden können.

Replikationscontroller und Bereitstellungen

A Replikat deklariert die Anzahl der Fälle eines Pods, der benötigt wird, und ein Replikationscontroller verwaltet das System so, dass die Anzahl der gesunden Pods, die ausgeführt werden, mit der Anzahl der im Replicaset deklarierten Schoten übereinstimmt (bestimmt durch Bewertung des Selektors).

Die Bereitstellungen sind ein Mechanismus des Managements auf höherem Niveau für Repliken. Während der Replikationscontroller die Skala des Replicaset verwaltet, verwaltet die Bereitstellungen, was mit dem ReplikaSet passiert - ob ein Update eingeführt oder zurückgerollt werden muss usw. Wenn die Bereitstellungen nach oben oder unten skaliert werden, führt dies zu der Erklärung der Erklärung des Replicaset -Änderung - und diese Änderung des deklarierten Zustands wird vom Replikationscontroller verwaltet.

Etiketten und Selektoren

Mit Kubernetes ermöglicht Clients (Benutzer oder interne Komponenten) Tasten, die als "Bezeichnungen" an ein API -Objekt im System wie Pods und Pods und angehängt werden Knoten. Entsprechend sind "Label -Selektoren" Abfragen gegen Beschriftungen, die sich auf passende Objekte lösen.[37] Wenn ein Dienst definiert ist, kann man die Etikettenauswahl definieren, die vom Service -Router/Last -Balancer verwendet werden, um die POD -Instanzen auszuwählen, an die der Datenverkehr geleitet wird. So kann das einfache Ändern der Beschriftungen der Schoten oder das Ändern der Etikettenauswahlern im Dienst verwendet werden, um zu steuern, welche Pods Datenverkehr erhalten und welche nicht, um verschiedene Bereitstellungsmuster wie zu unterstützen Blue-Green-Bereitstellungen oder A-B-Test. Diese Fähigkeit, dynamisch zu steuern, wie Dienste die Implementierung von Ressourcen nutzen, bietet eine lockere Kopplung innerhalb der Infrastruktur.

Zum Beispiel, wenn die Pods einer Anwendung Etiketten für ein System haben Ebene (mit Werten wie z. Frontend, Backendzum Beispiel) und a Release_track (mit Werten wie z. Kanarienvogel, Produktionzum Beispiel), dann eine Operation auf allen von Backend und Kanarienvogel Knoten können einen Etikettenwähler verwenden, z. B.:[46]

Tier = Backend und Release_track = Canary

Genau wie die Beschriftungen können auch Feldauswahlern eine Kubernetes -Ressourcen auswählen. Im Gegensatz zu Beschriftungen basiert die Auswahl auf den Attributwerten, die der ausgewählten Ressource und nicht der benutzerdefinierten Kategorisierung innewohnt. metadata.name und metadata.namespace sind Feldauswahlern, die in allen Kubernetes -Objekten vorhanden sind. Andere Selektoren, die verwendet werden können, hängen vom Objekt-/Ressourcentyp ab.

Add-Ons

Add-Ons arbeiten wie jede andere Anwendung, die im Cluster ausgeführt wird: Sie werden über Pods und Dienste implementiert und unterscheiden sich nur dann, wenn sie Funktionen des Kubernetes-Cluster implementieren. Die Pods können von Bereitstellungen, ReplicationControllern usw. verwaltet werden. Es gibt viele Add-Ons und die Liste wächst. Einige der wichtigsten sind:

  • DNS: Alle Kubernetes -Cluster sollten Cluster -DNS haben. Es ist ein obligatorisches Merkmal. Cluster DNS ist zusätzlich zu den anderen DNS -Server in Ihrer Umgebung ein DNS -Server, der DNS -Datensätze für Kubernetes -Dienste bedient. Container, die von Kubernetes gestartet wurden, enthalten automatisch diesen DNS -Server in die DNS -Suche.
  • Web-UI: Dies ist eine allgemeine webbasierte UI für Kubernetes-Cluster. Es ermöglicht Benutzern, Anwendungen zu verwalten und zu beheben, die im Cluster ausgeführt werden, sowie im Cluster selbst.
  • Überwachung der Containerressourcen: Bereitstellung einer zuverlässigen Laufzeit für Anwendungen und in der Lage, sie als Reaktion auf Workloads zu skalieren oder zu reagieren, bedeutet, die Leistung der Arbeitsbelastung kontinuierlich und effektiv zu überwachen. Die Überwachung der Containerressourcen bietet diese Fähigkeit, indem Metriken über Container in einer zentralen Datenbank aufgezeichnet werden, und bietet eine Benutzeroberfläche zum Durchsuchen dieser Daten. Der Cadvisor ist eine Komponente eines Slaveknotens, die eine begrenzte Metriküberwachungsfähigkeit bietet. Es gibt auch vollständige Metrik -Pipelines wie Prometheus, die die meisten Überwachungsbedürfnisse erfüllen können.
  • Protokollierung auf Clusterebene: Protokolle sollten unabhängig von Knoten, Schoten oder Behältern einen separaten Speicher- und Lebenszyklus haben. Andernfalls können Knoten- oder POD -Fehler zu Verlust von Ereignisdaten führen. Die Fähigkeit, dies zu tun, wird als Protokollierung auf Clusterebene bezeichnet, und solche Mechanismen sind dafür verantwortlich, Containerprotokolle in einem zentralen Protokollspeicher mit Such-/Browser-Schnittstelle zu sparen. Kubernetes bietet keinen nativen Speicher für Protokolldaten, aber man kann viele vorhandene Protokollierungslösungen in den Kubernetes -Cluster integrieren.

Lagerung

Container wurden als eine Möglichkeit, Software tragbar zu machen. Der Container enthält alle Pakete, die Sie zum Ausführen eines Dienstes benötigen. Das bereitgestellte Dateisystem macht Container extrem tragbar und einfach in der Entwicklung zu bedienen. Ein Container kann von der Entwicklung auf Test oder Produktion ohne oder relativ wenige Konfigurationsänderungen verschoben werden.

Historisch gesehen war Kubernetes nur für staatenlose Dienste geeignet. Viele Anwendungen verfügen jedoch über eine Datenbank, die eine Persistenz erfordert, was zur Erstellung eines anhaltenden Speichers für Kubernetes führt. Die Implementierung anhaltender Speicher für Container ist eine der größten Herausforderungen von Kubernetes -Administratoren, DevOps und Cloud -Ingenieuren. Container können kurzlebig sein, aber immer mehr Daten sind nicht. Daher muss das Überleben der Daten im Falle eines Containerabschlusses oder des Hardwarefehlers sichergestellt werden. Bei der Bereitstellung von Containern mit Kubernetes oder Containeranwendungen erkennen Unternehmen häufig, dass sie einen anhaltenden Speicher benötigen. Sie müssen einen schnellen und zuverlässigen Speicher für Datenbanken, Stammbilder und andere von den Containern verwendete Daten bereitstellen.

Zusätzlich zur Landschaft hat die Cloud Native Computing Foundation (CNCF) andere Informationen über Kubernetes persistierende Speicher veröffentlicht, einschließlich eines Blogs, das zur Definition des beigefügten Speichermusters des Containers hilft. Dieses Muster kann als eine angesehen werden, die Kubernetes selbst als Komponente des Speichersystems oder Dienstes verwendet.[61]

Weitere Informationen über die relative Popularität dieser und anderer Ansätze finden Sie auch in der Landschaftsumfrage des CNCF, die zeigten, dass OpenEBs von Mayadata und Rook - einem Lager für das Lagerorchestrierung - die beiden Projekte am wahrscheinlichsten im Herbst in Bewertung waren von 2019.[62]

Container beigefügte Speicher ist eine Art von Datenspeicher, die sich als Kubernetes herausstellte. Der angehängte Speicheransatz oder Muster des Containers basiert auf Kubernetes selbst für bestimmte Funktionen, während er hauptsächlich Block, Datei, Objekt und Schnittstellen an Workloads auf Kubernetes liefert.[63]

Zu den allgemeinen Attributen des beigefügten Speichers von Container gehören die Verwendung von Erweiterungen an Kubernetes, wie z. B. benutzerdefinierte Ressourcendefinitionen, und die Verwendung von Kubernetes selbst für Funktionen, die ansonsten separat entwickelt und für die Speicherung oder zum Datenmanagement bereitgestellt werden. Beispiele für Funktionen, die durch benutzerdefinierte Ressourcendefinitionen oder von Kubernetes selbst geliefert werden, umfassen die Wiederholungslogik, die von Kubernetes selbst geliefert wird, sowie die Erstellung und Wartung eines Inventars verfügbarer Speichermedien und -volumina, die normalerweise über eine benutzerdefinierte Ressourcendefinition bereitgestellt werden.[64][65]

API

Eine Schlüsselkomponente der Kubernetes -Steuerebene ist der API -Server, der eine HTTP -API enthüllt, die von anderen Teilen des Clusters sowie Endbenutzern und externen Komponenten aufgerufen werden kann. Diese API ist a SICH AUSRUHEN API und ist in der Natur deklarativ. Es gibt zwei Arten von API -Ressourcen. Die meisten API -Ressourcen in der Kubernetes -API sind Objekte. Diese repräsentieren eine konkrete Instanz eines Konzepts auf dem Cluster wie ein Pod oder einen Namespace. Eine kleine Anzahl von API -Ressourcentypen ist "virtuell". Diese stellen eher Operationen als Objekte dar, wie z. B. eine Berechtigungsprüfung unter Verwendung der Ressource "SubjektAccessreviews". API -Ressourcen, die Objekten entsprechen, werden im Cluster mit eindeutigen Kennungen für die Objekte dargestellt. Virtuelle Ressourcen haben keine eindeutigen Kennungen.

Betreiber

Kubernetes kann mit benutzerdefinierten Ressourcen erweitert werden. Diese API -Ressourcen stellen Objekte dar, die nicht Teil des Standard -Kubernetes -Produkts sind. Diese Ressourcen können durch dynamische Registrierung in einem laufenden Cluster erscheinen und verschwinden. Clusteradministratoren können benutzerdefinierte Ressourcen unabhängig vom Cluster aktualisieren.

Benutzerdefinierte Controller sind ein weiterer Erweiterungsmechanismus. Diese interagieren mit benutzerdefinierten Ressourcen und ermöglichen eine echte deklarative API, die die Lebenszyklusverwaltung von benutzerdefinierten Ressourcen ermöglicht, die auf die Art und Weise ausgerichtet ist, wie Kubernetes selbst entworfen wurde. Die Kombination aus benutzerdefinierten Ressourcen und benutzerdefinierten Controllern wird häufig als Kubernetes -Operator bezeichnet. Der wichtigste Anwendungsfall für Betreiber besteht darin, das Ziel eines menschlichen Betreibers zu erfassen, der einen Dienst oder eine Reihe von Diensten verwaltet und diese mit der Automatisierung implementiert, sowie mit einer deklarativen API, die diese Automatisierung unterstützt. Menschliche Betreiber, die sich um bestimmte Anwendungen und Dienste kümmern, haben tiefgreifende Kenntnisse darüber, wie sich das System verhalten sollte, wie man es bereitstellt und wie man bei Problemen reagiert. Beispiele für Probleme, die von den Betreibern gelöst wurden, umfassen die Aufnahme und Wiederherstellung von Backups des Status dieser Anwendung sowie die Behandlung von Upgrades des Anwendungscodes sowie verwandte Änderungen wie Datenbankschemata oder zusätzliche Konfigurationseinstellungen.

Cluster -API

Die gleichen API -Designprinzipien wurden verwendet, um eine API zu definieren, um kubernetes -Cluster programmatisch zu erstellen, zu konfigurieren und zu verwalten. Dies wird als Cluster -API bezeichnet.[66] Ein in der API enthaltener Schlüsselkonzept verwendet Infrastruktur als Software, oder die Vorstellung, dass die Kubernetes -Cluster -Infrastruktur selbst ein Ressource / ein Objekt ist, das wie alle anderen Kubernetes -Ressourcen verwaltet werden kann. In ähnlicher Weise werden Maschinen, aus denen sich der Cluster zusammensetzt, auch als Kubernetes -Ressource behandelt. Die API hat zwei Teile - die Kern -API und eine Anbieterimplementierung. Die Anbieterimplementierung besteht aus Cloud-Anbieter-spezifischen Funktionen, mit denen Kubernetes die Cluster-API in einer Weise bereitstellen kann, die in den Diensten und Ressourcen des Cloud-Anbieters gut integriert ist.

Verwendet

Kubernetes wird üblich Microservice -Architektur. Es ist in drei Formen erhältlich: Open Source, Commercial und Management. Open Source-Verteilungen umfassen die ursprünglichen Kubernetes, Amazon EKS-D, Red Hat OpenShift, VMware Tanzu, Mirantis Kubernetes Engine und D2IQ Kubernetes -Plattform. Zu den verwalteten Angeboten gehören GKE, Oracle Container Engine für Kubernetes, Amazon elastisch Kubernetes Service, IBM Kubernetes Service und Platform9 Managed Kubernetes.[67]

Timeline freigeben

Timeline freigeben
Ausführung Veröffentlichungsdatum Lebensende[68] Anmerkungen
Alte Version, nicht mehr gepflegt: 1.0 10. Juli 2015 Originalveröffentlichung
Alte Version, nicht mehr gepflegt: 1.1 9. November 2015 https://kubernetes.io/blog/2015/11/Kubernetes-1-1-performance-upgrades-impeved-tooling-and-growing-community
Alte Version, nicht mehr gepflegt: 1.2 16. März 2016 23. Oktober 2016 https://kubernetes.io/blog/2016/03/Kubernetes-2-2-even-more-performance-upgrades-plus-esier-application-ployment-and-management
Alte Version, nicht mehr gepflegt: 1.3 1. Juli 2016 1. November 2016 https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-nerprise-workloads
Alte Version, nicht mehr gepflegt: 1.4 26. September 2016 21. April 2017 https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-nerentes-anwhere
Alte Version, nicht mehr gepflegt: 1.5 12. Dezember 2016 1. Oktober 2017 https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads
Alte Version, nicht mehr gepflegt: 1.6 28. März 2017 23. November 2017 https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-ner-multi-workload-at-scale
Alte Version, nicht mehr gepflegt: 1.7 30. Juni 2017 4. April 2018 https://kubernetes.io/blog/2017/06/Kubernetes-1-7-security-hardening-stateful-application-eutsibility-Updates
Alte Version, nicht mehr gepflegt: 1.8 28. August 2017 12. Juli 2018 https://kubernetes.io/blog/2017/09/Kubernetes-18-security-workloads-and
Alte Version, nicht mehr gepflegt: 1.9 15. Dezember 2017 29. September 2018 https://kubernetes.io/blog/2017/12/Kubernetes-19-workload-expanded-ecosystem
Alte Version, nicht mehr gepflegt: 1.10 28. März 2018 13. Februar 2019 https://kubernetes.io/blog/2018/03/26/kubernetes-1.10-stabilisation-storage-security-networking
Alte Version, nicht mehr gepflegt: 1.11 3. Juli 2018 1. Mai 2019 https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-anouncent
Alte Version, nicht mehr gepflegt: 1.12 27. September 2018 8. Juli 2019 https://kubernetes.io/blog/2018/09/27/Kubernetes-12-KuBelet-tls-bootstrap-and-azure-virtual-machine-scale-sets-vmss-move-move-t-general-AVailability
Alte Version, nicht mehr gepflegt: 1.13 3. Dezember 2018 15. Oktober 2019 https://kubernetes.io/blog/2018/12/03/kubernetes-13-release-anounement
Alte Version, nicht mehr gepflegt: 1.14 25. März 2019 11. Dezember 2019 https://kubernetes.io/blog/2019/03/25/kubernetes-14-release-anounement
Alte Version, nicht mehr gepflegt: 1.15 20. Juni 2019 6. Mai 2020 https://kubernetes.io/blog/2019/06/19/kubernetes-15-release-anounement
Alte Version, nicht mehr gepflegt: 1.16 22. Oktober 2019 2. September 2020 https://kubernetes.io/blog/2019/09/18/Kubernetes-16-release-anounement
Alte Version, nicht mehr gepflegt: 1.17 9. Dezember 2019 13. Januar 2021 https://kubernetes.io/blog/2019/12/09/kubernetes-17-release-anounement
Alte Version, nicht mehr gepflegt: 1.18 25. März 2020 18. Juni 2021 https://kubernetes.io/blog/2020/03/25/Kubernetes-18-release-anounement
Alte Version, nicht mehr gepflegt: 1.19 26. August 2020[69] 28. Oktober 2021 Ab der Kubernetes Version 1.19 wurde das Support -Fenster auf ein Jahr voller Support plus zwei Monate des Wartungsmodus erweitert.[34]
https://kubernetes.io/blog/2020/08/26/Kubernetes-release-19-accentuate-the-paw-sitive
Alte Version, nicht mehr gepflegt: 1.20 8. Dezember 2020 28. Februar 2022 https://kubernetes.io/blog/2020/12/08/Kubernetes-1-20-release-announement/
Alte Version, nicht mehr gepflegt: 1.21 8. April 2021 28. Juni 2022 https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announement/
Ältere Version, dennoch gepflegt: 1.22 4. August 2021 28. Oktober 2022 https://kubernetes.io/blog/2021/08/04/kubernetes-22-release-anounement/
Ältere Version, dennoch gepflegt: 1.23 7. Dezember 2021 28. Februar 2023 https://kubernetes.io/blog/2021/12/07/kubernetes-23-release-anounement/
Aktuelle stabile Version: 1.24 3. Mai 2022 29. September 2023 https://kubernetes.io/blog/2022/05/03/Kubernetes-24-release-anounement/
Legende:
Alte Version
Ältere Version, noch gepflegt
Letzte Version
Neueste Vorschau -Version
Zukünftige Veröffentlichung

Fenster unterstützen

Die folgende Tabelle visualisiert den Zeitraum, für den jede Version unterstützt wurde/wurde unterstützt[68]

Siehe auch

Verweise

  1. ^ "Erster Github Commit für Kubernetes". github.com. 2014-06-07. Archiviert vom Original am 2017-03-01.
  2. ^ "Kubernetes v1.24.2 veröffentlicht".
  3. ^ "Kubernetes Github Repository". GitHub. 22. Januar 2021.
  4. ^ "Kubernetes/Kubernetes". GitHub. Archiviert vom Original am 2017-04-21. Abgerufen 2017-03-28.
  5. ^ a b "Was ist Kubernetes?". Kubernetes. Abgerufen 2017-03-31.
  6. ^ "Container Laufzeit". Kubernetes. Abgerufen 2021-11-14.
  7. ^ "Kubernetes v1.12: Einführung von RunTimeClass". Kubernetes.io. 10. Oktober 2018.
  8. ^ "Nicht Panik: Kubernetes und Docker". Kubernetes Blog. 2. Dezember 2020. Abgerufen 2020-12-22.
  9. ^ "Einführung der Container -Laufzeit -Schnittstelle (CRI) in Kubernetes". Kubernetes.2016-12-19. Abgerufen 2021-05-16.
  10. ^ "Kubernetes/Community". GitHub. Abgerufen 2021-05-16.
  11. ^ Aktualisiert: Dockershim entfernt FAQ Kubernetes Blog
  12. ^ "Die 7 beliebtesten Kubernetes -Verteilungen". Abgerufen 2021-12-28.
  13. ^ MSV, Janakiram. "Warum Kubernetes -Entwickler -Ökosystem eine PaaS braucht". Forbes. Abgerufen 2021-05-16.
  14. ^ a b Metz, Cade. "Google Open Quarces seine Geheimwaffe im Cloud Computing". Verdrahtet. Archiviert Aus dem Original am 10. September 2015. Abgerufen 24. September 2015.
  15. ^ Metz, Cade. "Google hat seine geheime Blaupause öffentlich gemacht, um seine Cloud zu steigern". Verdrahtet. Archiviert vom Original am 2016-07-01. Abgerufen 2016-06-27.
  16. ^ Burns, Brendan (20. Juli 2018), Die Geschichte von Kubernetes und die Community dahinter, archiviert von das Original am 2022-02-27
  17. ^ a b Abhishek Verma; Luis Pedrosa; Madhukar R. Korupolu; David Oppenheimer; Eric Melodie; John Wilkes (21. bis 24. April 2015). "Großes Cluster-Management bei Google with Borg". Verfahren der Europäischen Konferenz über Computersysteme (Eurosys). Archiviert vom Original am 2017-07-27.
  18. ^ "Borg, Omega und Kubernetes - ACM -Warteschlange". queue.acm.org. Archiviert vom Original am 2016-07-09. Abgerufen 2016-06-27.
  19. ^ "Frühes Start -up -Heptio zielt darauf ab, Kubernetes freundlich zu machen". Abgerufen 2016-12-06.
  20. ^ "Wenn Kubernetes 1.0 trifft, spendet Google Technologie für die neu gebildete Cloud Native Computing Foundation". Techcrunch. Archiviert Aus dem Original am 23. September 2015. Abgerufen 24. September 2015.
  21. ^ "Cloud Native Computing Foundation". Archiviert vom Original am 2017-07-03.
  22. ^ "Release v1.0: Merge Pull Anfrage #277 von Jackgr/Master · Helm/Helm". GitHub. Abgerufen 2021-05-16.
  23. ^ "Helm (Paketmanager) - Wikieduonline". www.wikieduonline.com. Abgerufen 2021-05-16.
  24. ^ "Helm". Helm.sh. Abgerufen 2021-05-16.
  25. ^ Dawson, Ryan (2020-07-28). "Wie hat Kubernetes den Container -Orchestrierungskrieg gewonnen?". Abgerufen 2022-08-06.
  26. ^ "Red Hat und Google arbeiten mit Kubernetes zusammen, um Docker -Container in Maßstab zu verwalten.". 2014-07-10. Abgerufen 2022-08-06.
  27. ^ "VMware und Pivotal Starten Sie Pivotal Container Service (PKS) und arbeiten mit Google Cloud zusammen, um Kubernetes an Enterprise -Kunden zu bringen.". 2017-08-29. Abgerufen 2022-08-06.
  28. ^ Lardinois, Frederic (2017-09-06). "Mesosphäre fügt Kubernetes -Unterstützung für das Betriebssystem des Rechenzentrums hinzu". Abgerufen 2022-08-06.
  29. ^ "Docker kündigt Verbesserungen der Docker -Plattform an, um die Verwaltung von Kubernetes für Unternehmen zu vereinfachen und voranzutreiben.". 2017-10-17. Archiviert von das Original am 2020-09-26.
  30. ^ Monroy, Gabe (2017-10-24). "Einführung von AKs (Managed Kubernetes) und Azure Container Registry Verbesserungen". Abgerufen 2022-08-06.
  31. ^ "Einführung von Amazon Elastic Container Service für Kubernetes (Vorschau)". 2017-11-29. Abgerufen 2022-08-06.
  32. ^ Conway, Sarah (6. März 2018). "Kubernetes ist das erste CNCF -Projekt zum Abschluss" (HTML). Cloud Native Computing Foundation. Archiviert vom Original am 29. Oktober 2018. Abgerufen 3. Dezember 2018. Im Vergleich zu den 1,5 Millionen Projekten auf Github ist Kubernetes die Nummer 9 für Commits und Nr. 2 für Autoren/Probleme, nur als Linux an zweiter Stelle.
  33. ^ "Kubernetes -Version und Version Verseuchsunterstützungsrichtlinie". Kubernetes. Abgerufen 2020-03-03.
  34. ^ a b "Kubernetes 1.19 Release -Ankündigung> Kubernetes Support -Fenster auf ein Jahr erhöhen". Kubernetes. 26. August 2020. Abgerufen 2020-08-28.
  35. ^ Sharma, Priyanka (13. April 2017). "Autoscaling basierend auf CPU/Speicher in Kubernetes - Teil II". PowerupCloud Tech Blog. Mittel. Abgerufen 27. Dezember 2018.
  36. ^ "Konfigurieren Sie Kubernetes Autoscaling mit benutzerdefinierten Metriken". Bitnami. Bitrock. 15. November 2018. Abgerufen 27. Dezember 2018.
  37. ^ a b c d e f g h i "Eine Einführung in Kubernetes". Digitalocean. Archiviert Aus dem Original am 1. Oktober 2015. Abgerufen 24. September 2015.
  38. ^ a b c "Kubernetes -Infrastruktur". OpenShift Community -Dokumentation. OpenShift. Archiviert Aus dem Original am 6. Juli 2015. Abgerufen 24. September 2015.
  39. ^ Container Linux von CoreOS: Cluster -Infrastruktur
  40. ^ a b Marhubi, Kamal (2015-09-26). "Kubernetes von Grund auf: API -Server". Kamalmarhubi.com. Archiviert vom Original am 2015-10-29. Abgerufen 2015-11-02.
  41. ^ Ellingwood, Justin (2. Mai 2018). "Eine Einführung in Kubernetes". Digitalocean. Archiviert von das Original am 5. Juli 2018. Abgerufen 20. Juli 2018. Einer der wichtigsten primären Dienste ist ein API -Server. Dies ist der Hauptverwaltungspunkt des gesamten Clusters, da ein Benutzer die Workloads und Organisationseinheiten von Kubernetes konfigurieren kann. Es ist auch verantwortlich dafür, dass der ETCD -Store und die Servicedetails der bereitgestellten Container zustimmen. Es fungiert als Brücke zwischen verschiedenen Komponenten, um die Gesundheit der Cluster aufrechtzuerhalten und Informationen und Befehle zu verbreiten.
  42. ^ "Bereitstellungen". Kubernetes. Abgerufen 2022-02-27.
  43. ^ "Die drei Säulen von Kubernetes Container Orchestration - Rancher Labs". Rancher.com. 18. Mai 2017. Archiviert Aus dem Original am 24. Juni 2017. Abgerufen 22. Mai 2017.
  44. ^ a b "Überblick über einen Replikationscontroller". Dokumentation. Coreos. Archiviert vom Original am 2015-09-22. Abgerufen 2015-11-02.
  45. ^ Sanders, Jake (2015-10-02). "Kubernetes: Aufregende experimentelle Funktionen". Livewyer. Archiviert vom Original am 2015-10-20. Abgerufen 2015-11-02.
  46. ^ a b "Intro: Docker und Kubernetes Training - Tag 2". roter Hut. 2015-10-20. Archiviert von das Original Am 2015-10-29. Abgerufen 2015-11-02.
  47. ^ Marhubi, Kamal (2015-08-27). "Was [..] ist ein KuBelet?". Kamalmarhubi.com. Archiviert vom Original am 2015-11-13. Abgerufen 2015-11-02.
  48. ^ "Kubernetes Sicherheit | Probleme und Best Practices | Snyk". snyk.io. 26. Juli 2020. Abgerufen 2021-05-16.
  49. ^ "Rktnetes bringt Rkt Container -Engine zu Kubernetes". Kubernetes.io. 11. Juli 2016.
  50. ^ "Namespaces". Kubernetes.io.
  51. ^ "Pods". Kubernetes.io.
  52. ^ a b Langemak, Jon (2015-02-11). "Kubernetes 101 - Netzwerk". Das Blinken Lichten. Archiviert vom Original am 2015-10-25. Abgerufen 2015-11-02.
  53. ^ Strachan, James (2015-05-21). "Kubernetes für Entwickler". Medium (Verlagsplattform). Archiviert vom Original am 2015-09-07. Abgerufen 2015-11-02.
  54. ^ "Daemonset". Kubernetes.io.
  55. ^ "Replicaset". Kubernetes.io. Abgerufen 2020-03-03.
  56. ^ "Bereitstellungen, Repliken und Schoten". IBM.
  57. ^ "Service". Kubernetes.io.
  58. ^ Langemak, Jon (2015-02-15). "Kubernetes 101 - externer Zugriff auf den Cluster". Das Blinken Lichten. Archiviert vom Original am 2015-10-26. Abgerufen 2015-11-02.
  59. ^ "Volumes". Kubernetes.io.
  60. ^ "Staatsfulsets". Kubernetes.io.
  61. ^ "Container beigefügte Speicher: Ein Primer". Cloud Native Computing Foundation. 2018-04-19. Abgerufen 2021-05-16.
  62. ^ "CNCF Survey 2019" (PDF). cncf.io.{{}}: CS1 Wartung: URL-Status (Link)
  63. ^ "Container beigefügte Speicher: Ein Primer". Cloud Native Computing Foundation. 2018-04-19. Abgerufen 2020-10-09.
  64. ^ "Container angeschlossener Speicher | Snia". www.snia.org. Abgerufen 2020-10-09.
  65. ^ "Checkliste für native Anwendungen: Cloud Native Speicher". www.replex.io. Abgerufen 2020-10-09.
  66. ^ "Einführung - Das Cluster -API -Buch".
  67. ^ "5 Cloud Native Trends, auf die Sie im Jahr 2022 achten sollten". Der neue Stapel. 2022-01-03. Abgerufen 2022-02-03.
  68. ^ a b "Kubernetes Patch veröffentlicht". GitHub. 4. Mai 2022. Abgerufen 2022-05-09.
  69. ^ "Kubernetes 1.19 Release -Ankündigung". Kubernetes. 26. August 2020. Abgerufen 2020-08-28.

Externe Links