Einführung
Kubernetes ist ein leistungsstarkes Open-Source-System, das ursprünglich von Google entwickelt und von der Cloud Native Computing Foundation (CNCF) unterstützt wurde, um containerisierte Anwendungen in einer geclusterten Umgebung zu verwalten. Es zielt darauf ab, bessere Möglichkeiten zur Verwaltung verwandter, verteilter Komponenten und Dienste über unterschiedliche Infrastrukturen hinweg bereitzustellen. Um mehr über Kubernetes zu erfahren, erkunden Sie den untenstehenden Leitfaden. Wenn Sie nach einem verwalteten Kubernetes-Hosting-Service suchen, schauen Sie sich unseren einfachen, verwalteten Kubernetes-Service an, der für Wachstum konzipiert ist.
In diesem Leitfaden werden wir besprechen, was Kubernetes ist, einige grundlegende Konzepte von Kubernetes. Wir werden über die Architektur des Systems, die Probleme, die es löst, und das Modell, das es zur Behandlung von containerisierten Bereitstellungen und Skalierung verwendet, sprechen.
Was ist Kubernetes?
Kubernetes ist auf grundlegender Ebene ein System zum Ausführen und Koordinieren von containerisierten Anwendungen über einen Cluster von Maschinen hinweg. Es ist eine Plattform, die darauf ausgelegt ist, den gesamten Lebenszyklus von containerisierten Anwendungen und Diensten vollständig zu verwalten, indem Methoden verwendet werden, die Vorhersehbarkeit, Skalierbarkeit und hohe Verfügbarkeit bieten.
Als Kubernetes-Benutzer können Sie definieren, wie Ihre Anwendungen ausgeführt werden sollen und auf welche Weise sie mit anderen Anwendungen oder der Außenwelt interagieren können. Sie können Ihre Dienste skalieren, Updates sanft durchführen und den Datenverkehr zwischen verschiedenen Versionen Ihrer Anwendungen umschalten, um Funktionen zu testen oder problematische Bereitstellungen zurückzusetzen. Kubernetes bietet Schnittstellen und zusammensetzbare Plattform-Primitiven, mit denen Sie Ihre Anwendungen mit hohem Maß an Flexibilität, Leistung und Zuverlässigkeit definieren und verwalten können.
Kubernetes-Architektur
Um zu verstehen, wie Kubernetes diese Fähigkeiten bereitstellen kann, ist es hilfreich, ein Gefühl dafür zu bekommen, wie es auf hoher Ebene entworfen und organisiert ist. Kubernetes kann als System in Schichten visualisiert werden, wobei jede höhere Ebene die Komplexität in den unteren Ebenen abstrahiert.
An seiner Basis vereint Kubernetes einzelne physische oder virtuelle Maschinen zu einem Cluster, der über ein gemeinsames Netzwerk kommuniziert, um zwischen jedem Server zu kommunizieren, ob physische oder virtuelle Maschinen. Dieser Kubernetes-Cluster ist die physische Plattform, auf der alle Kubernetes-Komponenten, -Fähigkeiten und -Workloads konfiguriert sind.
Die Maschinen im Kubernetes-Cluster erhalten jeweils eine Rolle innerhalb des Kubernetes-Ökosystems. Ein Server (oder eine kleine Gruppe in hochverfügbaren Bereitstellungen) fungiert als Master-Server. Dieser Server dient als Gateway und Gehirn für den Cluster, indem er eine Kubernetes-API für Benutzer und Clients freigibt, die Gesundheit anderer Server überprüft, entscheidet, wie Arbeit am besten aufgeteilt und zugewiesen wird (bekannt als „Scheduling“) und die Kommunikation zwischen anderen Komponenten orchestriert (manchmal als Containerorchestrierung bezeichnet). Der Master-Server fungiert als primärer Kontaktpunkt mit dem Cluster und ist für den größten Teil der zentralisierten Logik verantwortlich, die Kubernetes bereitstellt.
Die anderen Maschinen im Cluster sind als Knoten bezeichnet: Server, die dafür verantwortlich sind, Workloads unter Verwendung lokaler und externer Ressourcen anzunehmen und auszuführen. Um bei Isolation, Verwaltung und Flexibilität zu helfen, führt Kubernetes Anwendungen und Dienste in Containern aus. Daher muss jeder Knoten mit einer Container-Runtime (wie Docker oder rkt) ausgestattet sein. Der Knoten empfängt Arbeitsanweisungen vom Master-Server und erstellt oder zerstört Container entsprechend, wobei Netzwerkregeln angepasst werden, um den Datenverkehr ordnungsgemäß zu leiten und weiterzuleiten.
Wie oben erwähnt, werden die Anwendungen und Dienste selbst innerhalb von Containern im Cluster ausgeführt. Die zugrunde liegenden Komponenten stellen sicher, dass der gewünschte Zustand der Anwendungen mit dem tatsächlichen Zustand des Clusters übereinstimmt. Benutzer interagieren mit dem Cluster, indem sie direkt mit dem Haupt-Kubernetes-API-Server oder mit Clients und Bibliotheken kommunizieren. Um eine Anwendung oder einen Dienst zu starten, wird ein deklarativer Plan in JSON oder YAML eingereicht, der definiert, was erstellt werden soll und wie es verwaltet werden soll. Der Master-Server nimmt dann den Plan entgegen und ermittelt, wie er ihn auf der Infrastruktur ausführen kann, indem er die Anforderungen und den aktuellen Zustand des Systems untersucht. Diese Gruppe von benutzerdefinierten Anwendungen, die gemäß einem festgelegten Plan ausgeführt werden, stellt die letzte Ebene von Kubernetes dar.
Master-Server-Komponenten
Wie oben beschrieben, fungiert der Master-Server als primäres Steuerungselement für Kubernetes-Cluster. Er dient als Hauptkontaktpunkt für Administratoren und Benutzer und stellt auch viele clusterweite Systeme für die relativ unkomplizierten Worker-Knoten bereit. Insgesamt arbeiten die Komponenten auf dem Master-Server zusammen, um Benutzeranfragen entgegenzunehmen, die besten Möglichkeiten zur Planung von Arbeitslastcontainern zu ermitteln, Clients und Knoten zu authentifizieren, clusterweite Netzwerke anzupassen sowie Skalierungs- und Gesundheitsüberprüfungsverantwortlichkeiten zu verwalten.
Diese Komponenten können auf einer einzigen Maschine oder auf mehreren Servern verteilt installiert werden. In diesem Abschnitt werden wir uns jede der einzelnen Komponenten ansehen, die mit den Master-Servern für Kubernetes-Cluster verbunden sind.
etcd
Eine der grundlegenden Komponenten, die Kubernetes zum Funktionieren benötigt, ist ein global verfügbarer Konfigurationsspeicher. Das von dem Team bei CoreOS (Betriebssystem) entwickelte Projekt etcd ist ein leichtgewichtiger, verteilter Schlüssel-Wert-Speicher, der so konfiguriert werden kann, dass er über mehrere Knoten hinweg verteilt ist.
Kubernetes verwendet etcd, um Konfigurationsdaten zu speichern, auf die von jedem Knoten im Cluster zugegriffen werden kann. Dies kann für die Diensterkennung verwendet werden und kann Komponenten dabei helfen, sich gemäß aktueller Informationen zu konfigurieren oder neu zu konfigurieren. Es hilft auch dabei, den Zustand des Clusters mit Funktionen wie der Leader-Wahl und der verteilten Sperrung aufrechtzuerhalten. Durch Bereitstellung einer einfachen HTTP/JSON-API ist die Schnittstelle zum Setzen oder Abrufen von Werten sehr einfach.
Wie die meisten anderen Komponenten in der Kontrollebene kann etcd auf einem einzelnen Master-Server oder in Produktionsumgebungen auf mehreren Maschinen konfiguriert werden. Die einzige Anforderung ist, dass es für jede der Kubernetes-Maschinen im Netzwerk erreichbar ist.
kube-apiserver
Einer der wichtigsten Master-Services ist ein API-Server. Dies ist der Hauptverwaltungspunkt des gesamten Clusters, da er einem Benutzer ermöglicht, Kubernetes-Arbeitslasten und Organisationseinheiten zu konfigurieren. Er ist auch dafür verantwortlich, sicherzustellen, dass der etcd-Speicher und die Service-Details der bereitgestellten Container übereinstimmen. Er fungiert als Brücke zwischen verschiedenen Komponenten, um die Cluster-Gesundheit aufrechtzuerhalten und Informationen und Befehle zu verbreiten.
Der API-Server implementiert eine RESTful-Schnittstelle, was bedeutet, dass viele verschiedene Tools und Bibliotheken problemlos mit ihm kommunizieren können. Ein Client namens kubectl steht als Standardmethode zur Interaktion mit dem Kubernetes-Cluster von einem lokalen Computer aus zur Verfügung.
kube-controller-manager
Der Controller-Manager ist ein allgemeiner Dienst, der viele Verantwortlichkeiten hat. Hauptsächlich verwaltet er verschiedene Controller, die den Zustand des Clusters regulieren, Arbeitslast-Lebenszyklen verwalten und Routineaufgaben ausführen. Zum Beispiel stellt ein Replikations-Controller sicher, dass die Anzahl der Replikate (identische Kopien), die für ein Pod definiert sind, mit der Anzahl übereinstimmt, die derzeit auf dem Cluster bereitgestellt sind. Die Details dieser Operationen werden in etcd geschrieben, wo der Controller-Manager über den API-Server Änderungen beobachtet.
Wenn eine Änderung erkannt wird, liest der Controller die neuen Informationen und implementiert das Verfahren, das den gewünschten Zustand erfüllt. Dies kann das Skalieren einer Anwendung nach oben oder unten, das Anpassen von Endpunkten usw. umfassen.
kube-scheduler
Der Prozess, der tatsächlich Arbeitslasten bestimmten Knoten im Cluster zuweist, ist der Scheduler. Dieser Dienst liest die Betriebsanforderungen einer Arbeitslast ein, analysiert die aktuelle Infrastrukturlandschaft und platziert die Arbeit auf einem akzeptablen Knoten oder Knoten.
Der Scheduler ist dafür verantwortlich, die verfügbare Kapazität auf jedem Host zu verfolgen, um sicherzustellen, dass Arbeitslasten nicht über die verfügbaren Ressourcen hinaus geplant werden. Der Scheduler muss sowohl die Gesamtkapazität als auch die Ressourcen kennen, die bereits an vorhandene Arbeitslasten auf jedem Server zugewiesen sind.
cloud-controller-manager
Kubernetes kann in vielen verschiedenen Umgebungen bereitgestellt werden und mit verschiedenen Infrastrukturanbietern interagieren, um den Zustand der Ressourcen im Cluster zu verstehen und zu verwalten. Während Kubernetes mit generischen Darstellungen von Ressourcen wie anhängbarem Speicher und Lastenausgleichern arbeitet, benötigt es eine Möglichkeit, diese auf die tatsächlichen Ressourcen abzubilden, die von nicht homogenen Cloud-Anbietern bereitgestellt werden.
Die Cloud-Controller-Manager fungieren als das Bindeglied, das es Kubernetes ermöglicht, mit Anbietern mit unterschiedlichen Fähigkeiten, Funktionen und APIs zu interagieren, während sie intern relativ generische Konstrukte aufrechterhalten. Dies ermöglicht es Kubernetes, seinen Zustandsinformationen gemäß den Informationen, die vom Cloud-Anbieter gesammelt wurden, zu aktualisieren, Cloud-Ressourcen anzupassen, wenn Änderungen im System erforderlich sind, und zusätzliche Cloud-Services zu erstellen und zu nutzen, um die Arbeitsanforderungen zu erfüllen, die an den Cluster übermittelt werden.
Komponenten des Knotenservers
In Kubernetes werden Server, die Arbeit durch Ausführen von Containern ausführen, als Knoten bezeichnet. Knotenserver haben einige Anforderungen, die erforderlich sind, um mit Masterkomponenten zu kommunizieren, das Container-Netzwerk zu konfigurieren und die tatsächlichen Arbeitslasten auszuführen, die ihnen zugewiesen sind.
A Container Runtime
Die erste Komponente, die jeder Knoten haben muss, ist eine Containerlaufzeit. In der Regel wird diese Anforderung durch Installation und Ausführung von Docker erfüllt, aber auch Alternativen wie rkt und runc sind verfügbar.
Der Container-Runtime ist dafür verantwortlich, Container zu starten und zu verwalten, Anwendungen, die in einer relativ isolierten, aber leichtgewichtigen Betriebsumgebung eingekapselt sind. Jede Arbeitseinheit im Cluster wird auf grundlegender Ebene als ein oder mehrere Container implementiert, die bereitgestellt werden müssen. Die Container-Runtime auf jedem Knoten ist die Komponente, die letztendlich die in den Workloads definierten Container ausführt, die an den Cluster übermittelt wurden.
kubelet
Der Hauptkontaktpunkt für jeden Knoten mit der Clustergruppe ist ein kleiner Dienst namens kubelet. Dieser Dienst ist dafür verantwortlich, Informationen zwischen den Steuerebene-Diensten zu übermitteln, sowie mit dem etcd-Speicher zu interagieren, um Konfigurationsdetails zu lesen oder neue Werte zu schreiben.
Der kubelet-Dienst kommuniziert mit den Masterkomponenten, um sich beim Cluster anzumelden und Befehle und Arbeiten zu empfangen. Die Arbeit wird in Form eines Manifests empfangen, das die Workload und die Betriebsparameter definiert. Der kubelet-Prozess übernimmt dann die Verantwortung für die Aufrechterhaltung des Zustands der Arbeit auf dem Knotenserver. Er steuert die Container-Runtime, um Container bei Bedarf zu starten oder zu zerstören.
kube-proxy
Um die individuelle Host-Subnetzverwaltung zu ermöglichen und Dienste für andere Komponenten verfügbar zu machen, wird auf jedem Knotenserver ein kleiner Proxydienst namens kube-proxy ausgeführt. Dieser Prozess leitet Anfragen an die richtigen Container weiter, kann primitive Lastverteilung durchführen und ist im Allgemeinen dafür verantwortlich, sicherzustellen, dass die Netzwerkumgebung vorhersehbar und zugänglich ist, aber isoliert, wo es angemessen ist.
Kubernetes-Objekte und Workloads
Während Container der zugrunde liegende Mechanismus sind, der zur Bereitstellung containerisierter Anwendungen verwendet wird, verwendet Kubernetes zusätzliche Abstraktionsebenen über der Container-Schnittstelle, um Skalierbarkeit, Widerstandsfähigkeit und Lebenszyklus-Managementfunktionen bereitzustellen. Anstatt Container direkt zu verwalten, definieren und interagieren Benutzer mit Instanzen, die aus verschiedenen Grundelementen bestehen, die vom Kubernetes-Objektmodell bereitgestellt werden. Im Folgenden werden wir die verschiedenen Arten von Objekten erläutern, die verwendet werden können, um diese Workloads zu definieren.
Pods
A pod is the most basic unit that Kubernetes deals with. Containers themselves are not assigned to hosts. Instead, one or more tightly coupled containers are encapsulated in an object called a pod.
A pod generally represents containers that should be controlled as a single application. Pods consist of containers that operate closely together, share a life cycle, and should always be scheduled on the same node. They are managed entirely as a unit and share their environment, volumes, and IP space. In spite of their containerized implementation, you should generally think of pods as a single, monolithic application to best conceptualize how the cluster will manage the pod’s resources and scheduling.
In der Regel bestehen Pods aus einem Hauptcontainer, der den allgemeinen Zweck der Workload erfüllt, und optional aus einigen Hilfscontainern, die eng verwandte Aufgaben erleichtern. Dies sind Programme, die davon profitieren, in ihren eigenen Containern ausgeführt und verwaltet zu werden, aber eng mit der Hauptanwendung verbunden sind. Zum Beispiel kann ein Pod einen Container haben, der den primären Anwendungsserver ausführt, und einen Hilfscontainer, der Dateien auf das gemeinsame Dateisystem herunterlädt, wenn Änderungen in einem externen Repository erkannt werden. Die horizontale Skalierung wird im Allgemeinen auf Pod-Ebene nicht empfohlen, da es andere höherstufige Objekte gibt, die besser für die Aufgabe geeignet sind.
Im Allgemeinen sollten Benutzer Pods nicht selbst verwalten, da sie nicht alle Funktionen bereitstellen, die in Anwendungen typischerweise benötigt werden (wie eine anspruchsvolle Lebenszyklusverwaltung und Skalierung). Stattdessen werden Benutzer ermutigt, mit höherstufigen Objekten zu arbeiten, die Pods oder Pod-Templates als Grundkomponenten verwenden, aber zusätzliche Funktionalitäten implementieren.
Replikationscontroller und Replikationssätze
Häufig werden bei der Arbeit mit Kubernetes anstelle von einzelnen Pods Gruppen identischer, replizierter Pods verwaltet. Diese werden aus Pod-Templates erstellt und können horizontal skaliert werden durch Controller, die als Replikationscontroller und Replikationssätze bekannt sind.
A replication controller is an object that defines a pod template and control parameters to scale identical replicas of a pod horizontally by increasing or decreasing the number of running copies. This is an easy way to distribute load and increase availability natively within Kubernetes. The replication controller knows how to create new pods as needed because a template that closely resembles a pod definition is embedded within the replication controller configuration.
Der Replikations-Controller ist dafür verantwortlich, sicherzustellen, dass die Anzahl der in den Cluster bereitgestellten Pods mit der Anzahl der Pods in seiner Konfiguration übereinstimmt. Wenn ein Pod oder der zugrunde liegende Host ausfällt, startet der Controller neue Pods, um dies auszugleichen. Wenn sich die Anzahl der Repliken in der Konfiguration eines Controllers ändert, startet der Controller entweder Container neu oder beendet sie, um die gewünschte Anzahl anzupassen. Replikations-Controller können auch rollende Updates durchführen, um eine Reihe von Pods schrittweise auf eine neue Version zu aktualisieren, wodurch die Auswirkungen auf die Anwendungsverfügbarkeit minimiert werden.
Replikationssätze sind eine Weiterentwicklung des Designs des Replikations-Controllers mit größerer Flexibilität bei der Identifizierung der Pods, die der Controller verwalten soll. Replikationssätze beginnen, Replikations-Controller aufgrund ihrer größeren Auswahl an Repliken zu ersetzen, können jedoch keine rollenden Updates durchführen, um Back-Ends auf eine neue Version zurückzusetzen, wie es Replikations-Controller können. Stattdessen sollen Replikationssätze innerhalb zusätzlicher, höherstufiger Einheiten verwendet werden, die diese Funktionalität bereitstellen.
Wie Pods sind sowohl Replikations-Controller als auch Replikationssätze selten die Einheiten, mit denen Sie direkt arbeiten werden. Obwohl sie das Pod-Design nutzen, um horizontales Skalieren und Zuverlässigkeitsgarantien hinzuzufügen, fehlen ihnen einige der feinkörnigen Lebenszyklusverwaltungsfähigkeiten, die in komplexeren Objekten zu finden sind.
Bereitstellungen
Bereitstellungen sind eine der häufigsten Arbeitslasten, die direkt erstellt und verwaltet werden. Bereitstellungen verwenden Replikationssets als Bausteine und fügen flexible Funktionalitäten für das Lebenszyklusmanagement hinzu.
Obwohl Bereitstellungen, die mit Replikationssets erstellt wurden, die Funktionalität von Replikationscontrollern zu duplizieren scheinen, lösen Bereitstellungen viele der Probleme, die bei der Implementierung von Rolling Updates bestanden haben. Bei der Aktualisierung von Anwendungen mit Replikationscontrollern müssen Benutzer einen Plan für einen neuen Replikationscontroller einreichen, der den aktuellen Controller ersetzen würde. Bei der Verwendung von Replikationscontrollern sind Aufgaben wie das Nachverfolgen von Historien, das Wiederherstellen von Netzwerkfehlern während des Updates und das Rückgängigmachen von schlechten Änderungen entweder schwierig oder bleiben in der Verantwortung des Benutzers.
Bereitstellungen sind ein Objekt auf hoher Ebene, das dazu entwickelt wurde, das Lebenszyklusmanagement von replizierten Pods zu erleichtern. Bereitstellungen können leicht geändert werden, indem die Konfiguration geändert wird, und Kubernetes passt die Replikationssets an, verwaltet Übergänge zwischen verschiedenen Anwendungsversionen und behält optional automatisch Ereignishistorien und Rückgängigmachungsfähigkeiten bei. Aufgrund dieser Funktionen werden Bereitstellungen wahrscheinlich der Typ von Kubernetes-Objekt sein, mit dem Sie am häufigsten arbeiten.
Zustandssets
Stateful Sets sind spezialisierte Pod-Controller, die Ordnungs- und Eindeutigkeitsgarantien bieten. In erster Linie werden diese verwendet, um eine feinere Kontrolle zu haben, wenn spezielle Anforderungen in Bezug auf Bereitstellungsreihenfolge, persistente Daten oder stabiles Networking bestehen. Beispielsweise werden Stateful Sets oft mit datenorientierten Anwendungen wie Datenbanken in Verbindung gebracht, die auch bei Neuzuweisung zu einem neuen Knoten Zugriff auf dieselben Volumes benötigen.
Stateful Sets bieten einen stabilen Netzwerkidentifikator, indem für jeden Pod ein eindeutiger, nummernbasierter Name erstellt wird, der auch dann bestehen bleibt, wenn der Pod zu einem anderen Knoten verschoben werden muss. Ebenso können persistente Speichervolumes mit einem Pod übertragen werden, wenn eine Neuordnung erforderlich ist. Die Volumes bleiben auch nach dem Löschen des Pods erhalten, um versehentlichen Datenverlust zu verhindern.
Beim Bereitstellen oder Anpassen der Skalierung führen Stateful Sets Operationen gemäß der Nummer im Namen aus. Dies ermöglicht eine größere Vorhersehbarkeit und Kontrolle über die Ausführungsreihenfolge, was in einigen Fällen nützlich sein kann.
Daemon Sets
Daemon Sets sind eine weitere spezialisierte Form von Pod-Controllern, die eine Kopie eines Pods auf jedem Knoten im Cluster ausführen (oder eine Teilmenge, wenn angegeben). Dies ist am nützlichsten beim Bereitstellen von Pods, die bei der Wartung helfen und Dienste für die Kubernetes-Knoten selbst bereitstellen.
Zum Beispiel sind das Sammeln und Weiterleiten von Protokollen, das Aggregieren von Metriken und das Ausführen von Diensten, die die Fähigkeiten des Knotens selbst erhöhen, beliebte Kandidaten für Daemon Sets. Da Daemon Sets oft grundlegende Dienste bereitstellen und im gesamten Verbund benötigt werden, können sie Pod-Zuordnungsbeschränkungen umgehen, die andere Controller daran hindern, Pods bestimmten Hosts zuzuweisen. Als Beispiel ist aufgrund seiner einzigartigen Verantwortlichkeiten der Master-Server häufig so konfiguriert, dass er für die normale Pod-Zuordnung nicht verfügbar ist, aber Daemon Sets haben die Möglichkeit, die Beschränkung podweise zu überschreiben, um sicherzustellen, dass wesentliche Dienste ausgeführt werden.
Aufgaben und Cron-Jobs
Die bisher beschriebenen Arbeitslasten haben alle einen lang laufenden, dienstähnlichen Lebenszyklus angenommen. Kubernetes verwendet eine Arbeitslast namens Jobs, um einen mehr auf Aufgaben basierenden Arbeitsablauf bereitzustellen, bei dem erwartet wird, dass die laufenden Container erfolgreich beendet werden, nachdem sie ihre Arbeit erledigt haben. Jobs sind nützlich, wenn Sie einmalige oder Stapelverarbeitungen durchführen müssen, anstatt einen kontinuierlichen Dienst auszuführen.
Das Erstellen von Jobs sind Cron-Jobs. Wie die herkömmlichen cron-Daemonen auf Linux- und Unix-ähnlichen Systemen, die Skripte nach einem Zeitplan ausführen, bieten Cron-Jobs in Kubernetes eine Schnittstelle zum Ausführen von Jobs mit einem Zeitplanungskomponenten. Cron-Jobs können verwendet werden, um einen Job in Zukunft oder regelmäßig und wiederkehrend auszuführen. Kubernetes Cron-Jobs sind im Wesentlichen eine Neuentwicklung des klassischen Cron-Verhaltens, wobei der Cluster als Plattform anstelle eines einzelnen Betriebssystems verwendet wird.
Weitere Kubernetes-Komponenten
Jenseits der Workloads, die Sie in einem Cluster ausführen können, bietet Kubernetes eine Reihe weiterer Abstraktionen, die Ihnen helfen, Ihre Anwendungen zu verwalten, das Netzwerk zu steuern und Persistenz zu ermöglichen. Hier werden wir einige der häufigeren Beispiele besprechen.
Kubernetes-Dienste
Bisher haben wir den Begriff „Dienst“ im herkömmlichen, Unix-ähnlichen Sinne verwendet: um lang laufende Prozesse zu bezeichnen, die oft netzwerkverbunden sind und in der Lage sind, auf Anfragen zu reagieren. In Kubernetes ist ein Dienst jedoch eine Komponente, die als grundlegender interner Lastenausgleicher und Botschafter für Pods fungiert. Ein Dienst gruppiert logische Sammlungen von Pods zusammen, die die gleiche Funktion ausführen, um sie als eine einzelne Entität darzustellen.
Dies ermöglicht es Ihnen, einen Dienst bereitzustellen, der alle Backend-Container eines bestimmten Typs verfolgen und routen kann. Interne Verbraucher müssen nur über den stabilen Endpunkt des Dienstes informiert sein. Gleichzeitig ermöglicht Ihnen die Abstraktion des Dienstes, die Backend-Arbeitseinheiten bei Bedarf zu skalieren oder zu ersetzen. Die IP-Adresse eines Dienstes bleibt stabil, unabhängig von Änderungen an den Pods, zu denen er routet. Durch Bereitstellen eines Dienstes gewinnen Sie leicht an Entdeckbarkeit und können Ihre Container-Designs vereinfachen.
Jedes Mal, wenn Sie einem anderen Anwendungsprogramm oder externen Verbrauchern den Zugriff auf einen oder mehrere Pods ermöglichen müssen, sollten Sie einen Dienst konfigurieren. Wenn Sie beispielsweise eine Gruppe von Pods mit Webservern haben, die aus dem Internet erreichbar sein sollen, bietet ein Dienst die erforderliche Abstraktion. Ebenso, wenn Ihre Webserver Daten speichern und abrufen müssen, möchten Sie einen internen Dienst konfigurieren, um ihnen den Zugriff auf Ihre Datenbank-Pods zu ermöglichen.
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 NodePort funktioniert, indem auf jedem externen Netzwerkinterface eines Knotens ein statischer Port geöffnet wird. Datenverkehr zum externen Port wird automatisch zu den entsprechenden Pods unter Verwendung eines internen Cluster-IP-Dienstes geroutet.
Alternativ erstellt der Diensttyp LoadBalancer einen externen Lastenausgleicher, um zum Dienst über die Kubernetes-Lastenausgleicherintegration des Cloud-Anbieters zu routen. Der Cloud-Controller-Manager erstellt die entsprechende Ressource und konfiguriert sie unter Verwendung der internen Dienstadressen.
Volumes und Persistente Volumes
Zuverlässiges Teilen von Daten und Sicherstellen ihrer Verfügbarkeit zwischen Neustarts von Containern ist eine Herausforderung in vielen containerisierten Umgebungen. Container Laufzeiten bieten oft einen Mechanismus, um Speicher an einen Container anzuhängen, der über die Lebensdauer des Containers hinaus bestehen bleibt, aber die Implementierungen fehlen in der Regel an Flexibilität.
Um dies anzugehen, verwendet Kubernetes seine eigene Volumes Abstraktion, die es ermöglicht, Daten von allen Containern innerhalb eines Pods gemeinsam zu nutzen und bis zur Beendigung des Pods verfügbar zu halten. Dies bedeutet, dass eng gekoppelte Pods Dateien ohne komplexe externe Mechanismen einfach teilen können. Container-Ausfälle innerhalb des Pods beeinträchtigen nicht den Zugriff auf die gemeinsam genutzten Dateien. Sobald der Pod beendet ist, wird das gemeinsame Volume zerstört, daher ist es keine gute Lösung für wirklich persistente Daten.
Persistente Volumes sind ein Mechanismus zur Abstraktion von robusterem Speicher, der nicht an den Lebenszyklus des Pods gebunden ist. Stattdessen ermöglichen sie es Administratoren, Speicherressourcen für das Cluster zu konfigurieren, die Benutzer für die von ihnen ausgeführten Pods anfordern und beanspruchen können. Sobald ein Pod mit einem persistenten Volume fertig ist, bestimmt die Rückgewinnungsrichtlinie des Volumes, ob das Volume so lange aufbewahrt wird, bis es manuell gelöscht oder zusammen mit den Daten sofort entfernt wird. Persistente Daten können verwendet werden, um gegen Knotenausfälle abzusichern und um größere Speichermengen zuzuweisen, als lokal verfügbar sind.
Etiketten und Annotationen
A Kubernetes organizational abstraction related to, but outside of the other concepts, is labeling. A label in Kubernetes is a semantic tag that can be attached to Kubernetes objects to mark them as a part of a group. These can then be selected for when targeting different instances for management or routing. For instance, each of the controller-based objects use labels to identify the pods that they should operate on. Services use labels to understand the backend pods they should route requests to.
Etiketten werden als einfache Schlüssel-Wert-Paare angegeben. Jede Einheit kann mehr als ein Etikett haben, aber jede Einheit kann nur einen Eintrag für jeden Schlüssel haben. Normalerweise wird ein „Name“-Schlüssel als allgemeiner Identifikator verwendet, aber Sie können Objekte zusätzlich nach anderen Kriterien wie Entwicklungsstadium, öffentliche Zugänglichkeit, Anwendungsversion usw. klassifizieren.
Annotationen sind ein ähnlicher Mechanismus, der es Ihnen ermöglicht, beliebige Schlüssel-Wert-Informationen an ein Objekt anzuhängen. Während Etiketten für semantische Informationen verwendet werden sollten, die nützlich sind, um eine Pod mit Auswahlkriterien abzugleichen, sind Annotationen eher frei formatiert und können weniger strukturierte Daten enthalten. Im Allgemeinen sind Annotationen eine Möglichkeit, einem Objekt reichhaltige Metadaten hinzuzufügen, die nicht hilfreich für Auswahlzwecke sind.
Abschluss
Source:
https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes