Eine Einführung in Kubernetes

Eine der grundlegenden Komponenten, die Kubernetes benötigt, um zu funktionieren, ist ein global verfügbarer Konfigurationsspeicher. Dasetcd project, das vom CoreOS-Team entwickelt wurde, ist ein leichtgewichtiger, verteilter Schlüsselwertspeicher, der so konfiguriert werden kann, dass er sich über mehrere Knoten erstreckt.

Kubernetes verwendetetcd, um Konfigurationsdaten zu speichern, auf die jeder der Knoten im Cluster zugreifen kann. Dies kann für die Serviceerkennung verwendet werden und Komponenten dabei helfen, sich selbst anhand aktueller Informationen zu konfigurieren oder neu zu konfigurieren. Es hilft auch bei der Aufrechterhaltung des Cluster-Status mit Funktionen wie der Wahl von Führungskräften und dem verteilten Sperren. Durch die Bereitstellung einer einfachen HTTP / JSON-API ist die Schnittstelle zum Festlegen oder Abrufen von Werten sehr einfach.

Wie die meisten anderen Komponenten in der Steuerebene könnenetcd auf einem einzelnen Master-Server konfiguriert oder in Produktionsszenarien auf mehrere Maschinen verteilt werden. Die einzige Voraussetzung ist, dass jeder Kubernetes-Rechner auf das Netzwerk zugreifen kann.

Einer der wichtigsten Master-Services 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 dafür verantwortlich, sicherzustellen, dass deretcd-Speicher und die Servicedetails der bereitgestellten Container übereinstimmen. Es fungiert als Brücke zwischen verschiedenen Komponenten, um den Clusterzustand aufrechtzuerhalten und Informationen und Befehle zu verbreiten.

Der API-Server implementiert eine RESTful-Schnittstelle, sodass viele verschiedene Tools und Bibliotheken problemlos mit ihm kommunizieren können. Ein Client mit dem Namenkubectl ist als Standardmethode für die Interaktion mit dem Kubernetes-Cluster von einem lokalen Computer aus verfügbar.

Der Controller Manager ist ein allgemeiner Dienst, der viele Aufgaben hat. In erster Linie werden verschiedene Controller verwaltet, die den Status des Clusters regeln, den Workload-Lebenszyklus verwalten und Routineaufgaben ausführen. Ein Replikationscontroller stellt beispielsweise sicher, dass die Anzahl der Replikate (identische Kopien), die für einen Pod definiert sind, mit der Anzahl übereinstimmt, die derzeit im Cluster bereitgestellt ist. Die Details dieser Vorgänge werden inetcd geschrieben, wo der Controller-Manager über den API-Server nach Änderungen sucht.

Wenn eine Änderung festgestellt wird, liest die Steuerung die neuen Informationen und implementiert die Prozedur, die den gewünschten Zustand erfüllt. Dies kann das Vergrößern oder Verkleinern einer Anwendung, das Anpassen von Endpunkten usw. umfassen.

Der Prozess, der Workloads tatsächlich bestimmten Knoten im Cluster zuweist, ist der Scheduler. Dieser Service liest die Betriebsanforderungen eines Workloads ein, analysiert die aktuelle Infrastrukturumgebung und platziert die Arbeit auf einem akzeptablen Knoten oder akzeptablen Knoten.

Der Scheduler ist dafür verantwortlich, die verfügbare Kapazität auf jedem Host zu verfolgen, um sicherzustellen, dass die Workloads nicht über die verfügbaren Ressourcen hinaus geplant werden. Der Scheduler muss die Gesamtkapazität sowie die Ressourcen kennen, die bereits auf den einzelnen Servern vorhandenen Workloads zugewiesen sind.

Kubernetes können in vielen verschiedenen Umgebungen bereitgestellt werden und mit verschiedenen Infrastrukturanbietern interagieren, um den Status der Ressourcen im Cluster zu verstehen und zu verwalten. Während Kubernetes mit allgemeinen Darstellungen von Ressourcen wie z. B. anfügbarem Speicher und Lastenausgleich arbeitet, muss es eine Möglichkeit geben, diese den tatsächlichen Ressourcen zuzuordnen, die von inhomogenen Cloud-Anbietern bereitgestellt werden.

Cloud-Controller-Manager fungieren als Bindeglied, mit dem Kubernetes Anbieter mit unterschiedlichen Funktionen, Features und APIs interagieren kann, während relativ allgemeine Konstrukte intern beibehalten werden. Auf diese Weise kann Kubernetes seine Statusinformationen anhand der vom Cloud-Anbieter gesammelten Informationen aktualisieren, Cloud-Ressourcen anpassen, wenn Änderungen im System erforderlich sind, und zusätzliche Cloud-Dienste erstellen und verwenden, um die dem Cluster übermittelten Arbeitsanforderungen zu erfüllen.

Die erste Komponente, die jeder Knoten haben muss, ist eine Container-Laufzeit. In der Regel wird diese Anforderung durch die Installation und Ausführung vonDocker erfüllt. Es stehen jedoch auch Alternativen wierkt undrunc zur Verfügung.

Die Container-Laufzeit ist für das Starten und Verwalten von Containern verantwortlich. Dabei handelt es sich um Anwendungen, die in einer relativ isolierten, aber leichten Betriebsumgebung zusammengefasst sind. Jede Arbeitseinheit im Cluster wird auf der Basisebene als ein oder mehrere Container implementiert, die bereitgestellt werden müssen. Die Containerlaufzeit auf jedem Knoten ist die Komponente, die schließlich die Container ausführt, die in den an den Cluster gesendeten Workloads definiert sind.

Der Hauptkontaktpunkt für jeden Knoten mit der Clustergruppe ist ein kleiner Dienst namenskubelet. Dieser Dienst ist für die Weiterleitung von Informationen an und von den Steuerebenendiensten sowie für die Interaktion mit demetcd-Speicher verantwortlich, um Konfigurationsdetails zu lesen oder neue Werte zu schreiben.

Der Dienstkubeletkommuniziert mit den Hauptkomponenten, um sich beim Cluster zu authentifizieren, Befehle zu empfangen und zu arbeiten. Die Arbeit wird in Form vonmanifest empfangen, die die Arbeitslast und die Betriebsparameter definieren. Derkubelet-Prozess übernimmt dann die Verantwortung für die Aufrechterhaltung des Arbeitsstatus auf dem Knotenserver. Es steuert die Container-Laufzeit, um Container nach Bedarf zu starten oder zu zerstören.

Um einzelne Host-Subnetze zu verwalten und Dienste für andere Komponenten verfügbar zu machen, wird auf jedem Knotenserver ein kleiner Proxy-Dienst namenskube-proxy ausgeführt. Dieser Prozess leitet Anforderungen an die richtigen Container weiter, kann den primitiven Lastenausgleich durchführen und ist im Allgemeinen dafür verantwortlich, sicherzustellen, dass die Netzwerkumgebung vorhersehbar und zugänglich ist, gegebenenfalls jedoch isoliert.

Apod ist die grundlegendste Einheit, mit der sich Kubernetes befasst. Container selbst sind keinen Hosts zugeordnet. Stattdessen sind ein oder mehrere eng gekoppelte Container in einem Objekt eingekapselt, das als Pod bezeichnet wird.

Ein Pod repräsentiert im Allgemeinen einen oder mehrere Container, die als einzelne Anwendung gesteuert werden sollen. Pods bestehen aus Containern, die eng zusammenarbeiten, einen gemeinsamen Lebenszyklus haben und immer auf demselben Knoten geplant werden sollten. Sie werden vollständig als Einheit verwaltet und teilen sich Umgebung, Volumes und IP-Speicherplatz. Trotz der containerisierten Implementierung sollten Sie sich Pods im Allgemeinen als eine einzige, monolithische Anwendung vorstellen, um die bestmögliche Konzeption für die Verwaltung der Ressourcen und die Planung des Pods durch den Cluster zu erhalten.

Normalerweise bestehen Pods aus einem Hauptcontainer, der den allgemeinen Zweck der Arbeitslast erfüllt, und optional einigen Hilfscontainern, die eng miteinander verbundene Aufgaben erleichtern. Hierbei handelt es sich um Programme, die von der Ausführung und Verwaltung in eigenen Containern profitieren, jedoch eng an die Hauptanwendung gebunden sind. Beispielsweise kann ein Pod einen Container haben, in dem der primäre Anwendungsserver ausgeführt wird, und einen Hilfscontainer, der Dateien auf das gemeinsam genutzte Dateisystem herunterlädt, wenn Änderungen in einem externen Repository festgestellt werden. Die horizontale Skalierung wird auf der Pod-Ebene im Allgemeinen nicht empfohlen, da es andere Objekte höherer Ebenen gibt, die für die Aufgabe besser geeignet sind.

Im Allgemeinen sollten Benutzer Pods nicht selbst verwalten, da sie nicht die Funktionen bereitstellen, die normalerweise in Anwendungen benötigt werden (z. B. ausgeklügeltes Lebenszyklusmanagement und Skalierung). Stattdessen wird den Benutzern empfohlen, mit Objekten höherer Ebene zu arbeiten, die Pods oder Pod-Vorlagen als Basiskomponenten verwenden, jedoch zusätzliche Funktionen implementieren.

Wenn Sie mit Kubernetes anstatt mit einzelnen Pods arbeiten, verwalten Sie häufig Gruppen identischer, replizierter Pods. Diese werden aus Pod-Vorlagen erstellt und können von Controllern, den sogenannten Replikationscontrollern und Replikationssätzen, horizontal skaliert werden.

Areplication controller ist ein Objekt, das eine Pod-Vorlage und Steuerparameter definiert, um identische Replikate eines Pod horizontal zu skalieren, indem die Anzahl der ausgeführten Kopien erhöht oder verringert wird. Dies ist eine einfache Möglichkeit, die Last zu verteilen und die Verfügbarkeit innerhalb von Kubernetes zu erhöhen. Der Replikationscontroller kann bei Bedarf neue Pods erstellen, da eine Vorlage, die einer Pod-Definition sehr ähnlich ist, in die Replikationscontrollerkonfiguration eingebettet ist.

Der Replikationscontroller muss sicherstellen, dass die Anzahl der im Cluster bereitgestellten Pods mit der Anzahl der Pods in seiner Konfiguration übereinstimmt. Wenn ein Pod oder ein zugrunde liegender Host ausfällt, startet der Controller neue Pods, um dies zu kompensieren. Wenn sich die Anzahl der Replikate in der Konfiguration eines Controllers ändert, wird der Controller entweder gestartet oder er beendet Container entsprechend der gewünschten Anzahl. Replikationscontroller können auch fortlaufende Aktualisierungen durchführen, um eine Reihe von Pods nacheinander auf eine neue Version zu übertragen, wodurch die Auswirkungen auf die Anwendungsverfügbarkeit minimiert werden.

Replication sets sind eine Iteration des Replikationscontroller-Designs mit größerer Flexibilität bei der Identifizierung der Pods, die der Controller verwalten soll. Replikationssätze beginnen, Replikationscontroller zu ersetzen, da sie über umfangreichere Replikatauswahlfunktionen verfügen. Sie können jedoch keine fortlaufenden Aktualisierungen durchführen, um die Back-Ends auf eine neue Version umzuschalten, wie dies Replikationscontroller können. Stattdessen sollen Replikationssätze in zusätzlichen übergeordneten Einheiten verwendet werden, die diese Funktionalität bereitstellen.

Wie bei Pods sind sowohl Replikationscontroller als auch Replikationssätze selten die Einheiten, mit denen Sie direkt arbeiten werden. Während sie auf dem Pod-Design aufbauen, um horizontale Skalierung und Zuverlässigkeitsgarantien hinzuzufügen, fehlen ihnen einige der fein abgestimmten Funktionen für das Lebenszyklusmanagement, die in komplexeren Objekten zu finden sind.

Deployments sind eine der häufigsten Workloads, die direkt erstellt und verwaltet werden müssen. Bereitstellungen verwenden Replikationssätze als Baustein und erweitern den Mix um flexible Funktionen zur Lebenszyklusverwaltung.

Während Bereitstellungen, die mit Replikationssätzen erstellt wurden, die von Replikationscontrollern angebotenen Funktionen zu duplizieren scheinen, lösen Bereitstellungen viele der Probleme, die bei der Implementierung von fortlaufenden Updates auftraten. Beim Aktualisieren von Anwendungen mit Replikationscontrollern müssen Benutzer einen Plan für einen neuen Replikationscontroller einreichen, der den aktuellen Controller ersetzen würde. Bei Verwendung von Replikationscontrollern sind Aufgaben wie das Nachverfolgen des Verlaufs, das Wiederherstellen von Netzwerkfehlern während des Updates und das Zurücksetzen fehlerhafter Änderungen entweder schwierig oder liegen in der Verantwortung des Benutzers.

Bereitstellungen sind ein übergeordnetes Objekt, mit dem das Lebenszyklusmanagement von replizierten Pods vereinfacht werden soll. Bereitstellungen können einfach durch Ändern der Konfiguration geändert werden. Kubernetes passt die Replikatsätze an, verwaltet Übergänge zwischen verschiedenen Anwendungsversionen und verwaltet optional den Ereignisverlauf und macht die Funktionen zum Rückgängigmachen automatisch. Aufgrund dieser Funktionen sind Bereitstellungen wahrscheinlich der Typ des Kubernetes-Objekts, mit dem Sie am häufigsten arbeiten.

Stateful sets sind spezialisierte Pod-Controller, die Bestell- und Eindeutigkeitsgarantien bieten. In erster Linie dienen diese Funktionen einer genaueren Steuerung, wenn Sie spezielle Anforderungen in Bezug auf die Bereitstellungsreihenfolge, persistente Daten oder ein stabiles Netzwerk haben. Beispielsweise werden Stateful Sets häufig datenorientierten Anwendungen wie Datenbanken zugeordnet, die auch dann Zugriff auf dieselben Volumes benötigen, wenn sie auf einen neuen Knoten verschoben werden.

Stateful-Sets bieten eine stabile Netzwerkkennung, indem für jeden Pod ein eindeutiger, nummerbasierter Name erstellt wird, der auch dann bestehen bleibt, wenn der Pod auf einen anderen Knoten verschoben werden muss. Ebenso können persistente Speichervolumes mit einem Pod übertragen werden, wenn eine Neuplanung erforderlich ist. Die Volumes bleiben auch nach dem Löschen des Pods erhalten, um versehentlichen Datenverlust zu vermeiden.

Beim Bereitstellen oder Anpassen von Maßstäben führen Stateful-Sets Vorgänge entsprechend der im Namen enthaltenen nummerierten Kennung aus. Dies bietet eine bessere Vorhersehbarkeit und Kontrolle über die Ausführungsreihenfolge, was in einigen Fällen hilfreich sein kann.

Daemon sets sind eine weitere spezielle Form des Pod-Controllers, die auf jedem Knoten im Cluster eine Kopie eines Pods ausführt (oder eine Teilmenge, falls angegeben). Dies ist am häufigsten hilfreich, wenn Sie Pods bereitstellen, die die Wartung unterstützen und Dienste für die Knoten selbst bereitstellen.

Beispielsweise sind das Sammeln und Weiterleiten von Protokollen, das Aggregieren von Metriken und das Ausführen von Diensten, die die Funktionen des Knotens selbst verbessern, beliebte Kandidaten für Daemon-Sets. Da Da Daemon-Sets häufig grundlegende Dienste bereitstellen und in der gesamten Flotte benötigt werden, können sie die Einschränkungen der Pod-Planung umgehen, die andere Controller daran hindern, bestimmten Hosts Pods zuzuweisen. Zum Beispiel wird der Master-Server aufgrund seiner einzigartigen Zuständigkeiten häufig so konfiguriert, dass er für die normale Pod-Planung nicht verfügbar ist. Daemon-Sets können jedoch die Einschränkung podweise außer Kraft setzen, um sicherzustellen, dass wichtige Dienste ausgeführt werden.

Die bisher beschriebenen Workloads haben alle einen langen, serviceähnlichen Lebenszyklus angenommen. Kubernetes verwendet eine Workload namensjobs, um einen aufgabenbasierten Workflow bereitzustellen, bei dem erwartet wird, dass die ausgeführten Container nach einiger Zeit nach Abschluss ihrer Arbeit erfolgreich beendet werden. Jobs sind nützlich, wenn Sie eine einmalige oder Stapelverarbeitung ausführen müssen, anstatt einen kontinuierlichen Dienst auszuführen.

Aufbauend auf Jobs sindcron jobs. Wie die herkömmlichen Daemons voncronauf Linux- und Unix-ähnlichen Systemen, die Skripts nach einem Zeitplan ausführen, bieten Cron-Jobs in Kubernetes eine Schnittstelle zum Ausführen von Jobs mit einer Planungskomponente. Mit Cron-Jobs können Sie einen Job planen, der in Zukunft oder regelmäßig ausgeführt wird. Kubernetes Cron-Jobs sind im Grunde genommen eine Neuimplementierung des klassischen Cron-Verhaltens und verwenden den Cluster als Plattform anstelle eines einzelnen Betriebssystems.

Bisher haben wir den Begriff „Service“ im herkömmlichen, Unix-ähnlichen Sinne verwendet: um lang laufende Prozesse zu bezeichnen, die häufig über ein Netzwerk verbunden sind und auf Anforderungen reagieren können. In Kubernetes ist aservice jedoch eine Komponente, die als grundlegender interner Load Balancer und Botschafter für Pods fungiert. Ein Service fasst logische Sammlungen von Pods zusammen, die dieselbe Funktion ausführen, um sie als eine einzige Entität darzustellen.

Auf diese Weise können Sie einen Service bereitstellen, der alle Back-End-Container eines bestimmten Typs verfolgt und an diese weiterleitet. Interne Verbraucher müssen nur den vom Dienst bereitgestellten stabilen Endpunkt kennen. Die Service-Abstraktion ermöglicht es Ihnen, die Back-End-Arbeitseinheiten nach Bedarf zu skalieren oder zu ersetzen. Die IP-Adresse eines Dienstes bleibt unabhängig von Änderungen an den Pods, an die er weitergeleitet wird, stabil. Durch die Bereitstellung eines Dienstes erhalten Sie leicht Erkennbarkeit und können Ihre Containerentwürfe vereinfachen.

Jedes Mal, wenn Sie einer anderen Anwendung oder externen Verbrauchern Zugriff auf einen oder mehrere Pods gewähren müssen, sollten Sie einen Dienst konfigurieren. Wenn Sie beispielsweise über eine Reihe von Pods verfügen, auf denen Webserver ausgeführt werden, auf die über das Internet zugegriffen werden soll, stellt ein Dienst die erforderliche Abstraktion bereit. Wenn Ihre Webserver Daten speichern und abrufen müssen, sollten Sie einen internen Dienst konfigurieren, um ihnen Zugriff auf Ihre Datenbank-Pods zu gewähren.

Obwohl Dienste standardmäßig nur über eine intern routbare IP-Adresse verfügbar sind, können sie durch Auswahl einer von mehreren Strategien außerhalb des Clusters verfügbar gemacht werden. Die Konfiguration vonNodePortfunktioniert durch Öffnen eines statischen Ports auf der externen Netzwerkschnittstelle jedes Knotens. Der Datenverkehr zum externen Port wird automatisch über einen internen Cluster-IP-Dienst an die entsprechenden Pods weitergeleitet.

Alternativ erstellt der DiensttypLoadBalancereinen externen Load Balancer, der mithilfe der Kubernetes Load Balancer-Integration eines Cloud-Anbieters an den Service weitergeleitet wird. Der Cloud-Controller-Manager erstellt die entsprechende Ressource und konfiguriert sie mithilfe der internen Service-Service-Adressen.

In vielen containerisierten Umgebungen ist es eine Herausforderung, Daten zuverlässig auszutauschen und ihre Verfügbarkeit zwischen Containerneustarts zu gewährleisten. Containerlaufzeiten stellen häufig einen Mechanismus zum Anhängen von Speicher an einen Container bereit, der über die Lebensdauer des Containers hinaus bestehen bleibt, bei Implementierungen fehlt jedoch in der Regel die Flexibilität.

Um dies zu beheben, verwendet Kubernetes seine eigenevolumes-Abstraktion, mit der Daten von allen Containern innerhalb eines Pods gemeinsam genutzt werden können und verfügbar bleiben, bis der Pod beendet wird. Dies bedeutet, dass eng gekoppelte Pods Dateien ohne komplexe externe Mechanismen problemlos gemeinsam nutzen können. Containerfehler innerhalb des Pods wirken sich nicht auf den Zugriff auf die freigegebenen Dateien aus. Sobald der Pod beendet ist, wird das freigegebene Volume zerstört. Dies ist keine gute Lösung für wirklich beständige Daten.

Persistent volumes sind ein Mechanismus zum Abstrahieren von robusterem Speicher, der nicht an den Pod-Lebenszyklus gebunden ist. Stattdessen können Administratoren Speicherressourcen für den Cluster konfigurieren, die Benutzer für die von ihnen ausgeführten Pods anfordern und anfordern können. Sobald ein Pod mit einem dauerhaften Volume fertig ist, bestimmt die Wiederherstellungsrichtlinie des Volumes, ob das Volume so lange beibehalten wird, bis es manuell gelöscht oder zusammen mit den Daten sofort entfernt wird. Persistente Daten können verwendet werden, um sich vor knotenbasierten Ausfällen zu schützen und mehr Speicher zuzuweisen, als lokal verfügbar ist.

Eine Kubernetes-Organisationsabstraktion, die mit den anderen Konzepten zusammenhängt, aber nicht mit ihnen zusammenhängt, ist die Kennzeichnung. Alabel in Kubernetes ist ein semantisches Tag, das an Kubernetes-Objekte angehängt werden kann, um sie als Teil einer Gruppe zu markieren. Diese können dann ausgewählt werden, wenn verschiedene Instanzen für die Verwaltung oder das Routing ausgewählt werden. Beispielsweise verwenden alle Controller-basierten Objekte Beschriftungen, um die Pods zu identifizieren, mit denen sie arbeiten sollen. Services verwenden Labels, um die Back-End-Pods zu verstehen, an die Anforderungen weitergeleitet werden sollen.

Beschriftungen werden als einfache Schlüssel-Wert-Paare angegeben. Jede Einheit kann mehr als eine Beschriftung haben, aber jede Einheit kann nur einen Eintrag für jede Taste haben. Normalerweise wird ein Namensschlüssel als allgemeine Kennung verwendet. Sie können Objekte jedoch auch nach anderen Kriterien wie Entwicklungsstadium, öffentliche Zugänglichkeit, Anwendungsversion usw. klassifizieren.

Annotations sind ein ähnlicher Mechanismus, mit dem Sie einem Objekt beliebige Schlüsselwertinformationen hinzufügen können. Während Labels für semantische Informationen verwendet werden sollten, die nützlich sind, um einen Pod mit Auswahlkriterien abzugleichen, sind Anmerkungen freier und können weniger strukturierte Daten enthalten. Im Allgemeinen sind Anmerkungen eine Möglichkeit, einem Objekt umfangreiche Metadaten hinzuzufügen, die für Auswahlzwecke nicht hilfreich sind.