Teil 1 - Die Geburt einer Schote
In dieser Serie werden wir tief in die komplizierten Mechanismen von Kubernetes eintauchen und jeden Schritt der Kubernetes-Lebenszyklus-Reise unter die Lupe nehmen und untersuchen. Beginnen wir mit der Magie, die einem Pod Leben einhaucht. Machen Sie sich gefasst auf eine Reise voller technischer Wunderwerke!
Ich werde es nicht beschönigen - es mag Momente der Langeweile geben, aber ich bin bestrebt, so umfassende Einblicke wie möglich zu geben. Also machen Sie es sich bequem und lassen Sie uns unsere Hardcore-Reise in Kubernetes beginnen!
Lassen Sie uns nun in den faszinierenden Prozess der Kubernetes-Pod-Erstellung eintauchen und die Geheimnisse aufdecken, die darin liegen.
Stufe 1: Pod-Spezifikationen
Es ist ein Junge (pod)!
Die Definition des begehrten Staates
Die Reise beginnt mit dem Entwurf einer Pod-Spezifikation, die in der Regel im YAML-Format erstellt wird. Diese Spezifikation enthält unter anderem Informationen zu Images, Ressourcenanforderungen, Umgebungsvariablen, Volume-Mounts und Netzwerkeinstellungen. Dies dient als Masterplan für den Lebenszyklus des Pods innerhalb des Kubernetes-Clusters.
Stufe 2: Kubectl entfesselt
"Herstellen der Verbindung: Kubectl-Befehle und -Anfragen an den Kubernetes-API-Server"
Lassen Sie uns den folgenden Befehl ausführen:
kubectl create -f apache-pod.yaml
In dieser Phase greifen wir auf den Kubernetes-API-Server zu, indem wir das Kubernetes-Befehlszeilen-Tool mit dem treffenden Namen "kubectl" verwenden,
Zu Beginn führt kubectl eine clientseitige Validierung durch, seine wichtigste Aktion. Diese Validierung stellt sicher, dass zum Scheitern verurteilte Anfragen, z. B. solche, die versuchen, eine nicht unterstützte Ressource zu erstellen oder einen falsch formatierten Bildnamen zu verwenden, sofort abgewiesen werden, bevor sie den kube-apiserver erreichen. Auf diese Weise filtert kubectl fehlerhafte Versuche heraus und schont die wertvolle Zeit(ressourcen) des bereits belegten kube-apiserver.
Als Nächstes verwendet es Generatoren, um Daten zu einer HTTP-Anfrage zu formen, die dann an den kube-api-Server gesendet werden kann. Darüber hinaus übernimmt kubectl die Aufgabe, die Versionskompatibilität zwischen Client- und Serverversionen zu vermitteln und sicherzustellen. Bei der Client-Authentifizierung sucht kubectl rigoros nach Anmeldeinformationen und gibt dabei den angegebenen Benutzernamen den Vorrang. Dazu gehört die Einbettung von Authentifizierungsdaten wie x509-Zertifikaten, Inhaber-Token oder Basis-Authentifizierungsdaten in die an den kube-api-Server gerichtete HTTP-Anfrage. Bei der OpenID-Authentifizierung obliegt es den Nutzern, das Token zu sichern und als Bearer-Token in die Anfrage einzubetten. Durch die Nutzung dieser Funktionen ermöglicht kubectl einen reibungslosen Dialog mit der Kubernetes-Infrastruktur.
Nachdem wir unsere API-Anfrage an die kube-api-Server gesendet haben, wollen wir uns nun ansehen, was als nächstes passiert.
Stufe 3: Innerhalb des API-Servers
Der API-Server fungiert als zentrale Steuerungsebene, die Anfragen von Clients entgegennimmt und bearbeitet. Er prüft die eingehenden Anfragen, sorgt für eine angemessene Authentifizierung und leitet das Orchestrierungsverfahren ein.
Authentifizierung: Die Feststellung unserer Identität
Jede Anfrage durchläuft die Authentifizierungskette, bis eine erfolgreich ist. Dies beinhaltet die Validierung von TLS-Schlüsseln, die Überprüfung von Inhaber-Tokens oder die Validierung grundlegender Authentifizierungsdaten; der Kube-Apiserver ist sehr sorgfältig bei der Authentifizierung der Identität des Anfragenden. Nach erfolgreicher Authentifizierung wird der Authorization-Header entfernt und die Benutzerdaten werden dem Anforderungskontext angehängt, was weitere Prozesse wie die Autorisierung und den Betrieb von Admission Controllern unter Nutzung der bestätigten Benutzeridentität erleichtert.
Autorisierung: Zugriffsrechte werden bestätigt
Während die Authentifizierung den Zugang gewährt, bestimmt die Autorisierung, ob wir die erforderlichen Berechtigungen besitzen, um die geforderte Aktion auszuführen. Der kube-apiserver verwaltet die Autorisierung durch die Anordnung einer Reihe von Autorisierern,
Formulierung einer Reihe von Autorisierern, durch die Anfragen laufen (Webhook, ABAC, RBAC, Node)
-> Bei einstimmiger Ablehnung wird die Anfrage mit "Verboten" beantwortet
-> Wenn ein Genehmigender zustimmt, geht der Prozess in die nächste Phase über...
Zulassungskontrolle: Durchsetzung von Clusterprotokollen
Ein Admission Controller ist ein Codesegment, das an den Kubernetes-API-Server gerichtete Anfragen vor der Objektpersistenz abfängt, allerdings nach der Authentifizierung und Autorisierung.
über die Kette der Zulassungssteuerungsstellen, die aus einer Reihe von Plugins besteht, - -> wenn eine von ihnen den Antrag ablehnt, wird der Prozess angehalten. (Hinweis: Die Erwartung weicht hier leicht von der Autorisierung ab; hier muss der Antrag über alle Zulassungssteuerungsketten hinweg genehmigt werden)
Ein kurzes Beispiel für Zulassungssteuerungs-Plugins:
LimitRanger - bestimmt die Standardanforderungen und -beschränkungen für Container.
ResourceQuota - wertet Anfragen aus und lehnt sie ab, wenn die Anzahl der Objekte im Namensraum die festgelegte Anfrage übersteigt (Pods, Service, rc, Load Balancer).
Der Admission Controller könnte ein Thema für einen zukünftigen Teil der Hardcore-Kubernetes-Serie sein. Bleiben Sie dran, wenn Ihnen die Serie bisher gefallen hat und Sie Interesse am Hardcore-Kubernetes-Weg haben. Das ist der Weg!
Der kube-apiserver entpackt die HTTP-Anfrage, erstellt daraus Laufzeitobjekte (eine Art umgekehrter Vorgang im Vergleich zu den Generatoren von kubectl) und speichert sie im Datenspeicher.
Zusammenfassend lässt sich sagen, dass die Ressource "Einsatz" nun einen Platz in der usw. hat.
Stufe 4: Zeitplanung
Ermittlung des Geburtsortes unseres Pods:
Überwachung des Baby-Fortschritts - "In diesem Moment befinden sich unsere Pods in einem Pending-Status, da sie noch keinem Node zugewiesen worden sind. Der letzte Controller, der sich mit diesem Problem befasst, ist der Scheduler.
Der Planer führt eine Reihe von Prozessen durch, um zu einer Entscheidung zu gelangen.
Schritt 1: Auswahl des Knotens
Der Scheduler beginnt mit der Ermittlung einer Gruppe geeigneter Knoten, in denen der Pod untergebracht werden kann. Dabei werden mehrere Aspekte berücksichtigt, u. a. Ressourcenanforderungen, Knotenkapazität, Affinitäts- und Anti-Affinitäts-Spezifikationen sowie Taints und Toleranzen. Dadurch wird gewährleistet, dass der Pod auf einem Knoten liegt, der seine Ressourcenanforderungen erfüllen kann und gleichzeitig alle spezifischen Platzierungsvoraussetzungen erfüllt.
Schritt 2: Filterung
Nach der Ermittlung einer Liste in Frage kommender Knoten setzt der Planer eine Reihe von Filtern ein, um Knoten auszusondern, die bestimmte Standards nicht erfüllen. Diese Filter können u. a. Elemente wie Knotenbereitschaft, Knotenselektoren, Knotenbedingungen und Ressourcenschwellenwerte umfassen. Knoten, die diese Filter nicht erfüllen, werden aus der Betrachtungsgruppe ausgeschlossen.
Schritt 3: Punktevergabe
Nach der Filterungsphase weist der Scheduler den verbleibenden Knoten Punkte zu, um ihre Eignung für die Aufnahme des Pods zu bewerten. Jeder Knoten wird anhand von Kriterien wie Ressourcenverfügbarkeit, Nähe zu anderen Pods, Affinitäts- oder Anti-Affinitätsregeln innerhalb des Pods, Anforderungen an die Dienstqualität sowie benutzerspezifischen Regeln oder Präferenzen des Nutzers bewertet. Ein Knoten mit einer höheren Punktzahl wird als wünschenswerter für die Planung angesehen.
Schritt 4: Endgültige Auswahl
Nach der Verteilung der Punktzahlen nimmt der Planer eine abschließende Bewertung vor und wählt den Knoten mit der höchsten Punktzahl als den für den Pod vorgesehenen Gastgeber aus. In Fällen, in denen sich mehrere Knoten die höchste Punktzahl teilen, kann der Planer zusätzliche Entscheidungsstrategien anwenden, wie z. B. eine Zufallsauswahl oder vom Benutzer festgelegte Regeln, um den endgültigen Empfänger auszuwählen.
Schritt 5: Bindung und Zuteilung
Nach der Auswahl des Knotens übermittelt der Scheduler sein Urteil an die Kubernetes-Kontrollebene. Die Bindungsinformationen des Pods werden mit dem Namen des ausgewählten Knotens dokumentiert, was die Zuteilung des Pods an diesen spezifischen Knoten angibt. Folglich ändert die Steuerebene den Status des Clusters, um diese Zuweisung widerzuspiegeln.
Schritt 6: Vorbereitung des Knotens - Einrichten des Hosts
Nach der Auswahl des Knotens leitet der designierte Kubernetes-Controller die Vorbereitungsphase ein. Er richtet den Knoten ein, indem er die erforderlichen Namespaces einrichtet, Netzwerkbrücken einrichtet und die für den Betrieb des Pods erforderlichen Ressourcen zuweist. Anschließend wird die Laufzeit des Containers, sei es Docker oder Container, aktiviert, um den Container im Pod einzurichten.
Stufe 5: Container
Hier findet der Prozess der Containererstellung statt. Wir wollen untersuchen, wie Kubelet, Container Runtime und CNI Plugins zusammenarbeiten:
Stufe 6: Container werden Teil des Festes
Hier findet der Prozess der Containererstellung statt:
Erforschung des Кubelet und seiner Funktion bei der Überwachung der Lebenszyklen von Schoten:
Das Кubelet fungiert als Agent, der sich auf jedem Knoten innerhalb eines Kubernetes-Clusters befindet und eine zentrale Rolle bei der Steuerung der Lebenszyklen von Pods einnimmt. Neben anderen Aufgaben entschlüsselt das Кubelet das Pod-Konzept in seine einzelnen Container und überwacht Aspekte wie die Verwaltung des Lebenszyklus von Containern, das Einhängen von Volumes, die Protokollierung von Containern und die Garbage Collection.
Pod-Synchronisierung: In regelmäßigen Abständen, in der Regel in 20-Sekunden-Intervallen, ruft das Кubelet den kube-apiserver auf, um die Liste der mit dem Knoten, auf dem es arbeitet, verbundenen Pods abzurufen. Dieser Dienstplan wird mit dem eigenen Cache abgeglichen, um Neuzugänge oder Unstimmigkeiten festzustellen. Bei der Erstellung eines Pods protokolliert das Кubelet die Startmetriken und erzeugt ein PodStatus-Objekt, das das aktuelle Stadium des Pods widerspiegelt. Diese Phase kapselt die Position des Pods in seinem Lebenszyklus und gibt Status wie "Ausstehend", "In Betrieb", "Erfolgreich", "Fehlgeschlagen" oder "Unbekannt" an.
Zulassungshandler: Im Anschluss an die Erstellung des PodStatus aktiviert das Кubelet Zulassungshandler, um die entsprechenden Sicherheitsberechtigungen für den Pod zu überprüfen. Diese Vermittler schreiben Sicherheitsprotokolle wie AppArmor-Profile und NO_NEW_PRIVS vor. Sollte ein Pod in dieser Phase abgelehnt werden, behält er den Status "Ausstehend", bis die Sicherheitskonflikte behoben sind.
CRI und Zwischencontainer: Das Кubelet nutzt das Container Runtime Interface (CRI) für die Interaktion mit der zugrundeliegenden Container-Laufzeitumgebung, z. B. Docker oder rkt, und erleichtert die Kommunikation mit verschiedenen Laufzeitanpassungen durch eine Abstraktionsschicht. Wenn ein Pod initiiert wird, ruft das Кubelet die Remote-Prozedur RunPodSandbox auf und erstellt eine "Sandbox", die als Elternteil für die Container des Pods fungiert. Im Szenario von Docker bedeutet dies die Erstellung eines "Interim-Containers", der gemeinsame Namensräume (IPC, Netzwerk, PID) für die Container des Pods bereithält.
CNI- und Pod-Netzwerk-Konfigurationen: Pod-Netzwerkoperationen werden durch das Кubelet an die Container Network Interface (CNI)-Plugins delegiert. Diese Schnittstelle ermöglicht es verschiedenen Netzwerkanbietern, unterschiedliche Netzwerkkonfigurationen für Container zu verwenden. Die Interaktion mit den CNI-Plugins beinhaltet die Übertragung von JSON-Daten, wodurch die Netzwerkpräferenzen strukturiert werden. Das Bridge-CNI-Plugin richtet beispielsweise eine native Linux-Bridge im Netzwerk-Namensraum des Hosts ein und verbindet sie über ein Veth-Paar mit dem Netzwerk-Namensraum des Interim-Containers. Dieses Plugin weist der Schnittstelle des Interims-Containers eine IP-Adresse zu und legt Routen fest, wodurch der Pod mit einer eindeutigen IP-Adresse ausgestattet wird.
Interknoten-Kommunikation: Zur Förderung der Konnektivität zwischen Pods, die auf verschiedenen Hosts untergebracht sind, verwendet Kubernetes hauptsächlich Overlay-Netzwerke wie Flannel, die die Routensynchronisierung über zahlreiche Knoten in einem Cluster koordinieren. Flannel erweitert ein Layer-3-IPv4-Netzwerk zwischen den Knoten und kapselt ausgehende Pakete in UDP-Datagramme ein, um ein ordnungsgemäßes Routing zu gewährleisten.
Container-Initiierung: Nach dem Aufbau der Vernetzung beginnt das Кubelet mit der Container-Initialisierung. Die erforderlichen Container-Images werden abgerufen, wobei die in der PodSpec für private Registries angegebenen Geheimnisse verwendet werden. Anschließend wird der Container über die CRI eingerichtet, wobei die relevanten Details aus der PodSpec in eine ContainerConfig-Struktur aufgenommen werden. Der CPU-Manager ordnet Container bestimmten CPU-Clustern zu und initialisiert den Container anschließend. Falls angegeben, werden nach der Initialisierung des Containers Lebenszyklus-Hooks wie Exec- oder HTTP-Aktionen ausgelöst.
Zum Abschluss
Und damit sind wir am Ende unserer ersten Reise ins Hardcore-Kubernetes angelangt. Wie ein Pod entsteht, hat zwar nichts mit Störchen oder Kreißsälen zu tun, ist aber nicht weniger magisch. Wenn Sie also das nächste Mal erleben, wie ein Pod in Ihrem Cluster seinen ersten Atemzug tut, seien Sie ein stolzer und verantwortungsvoller Elternteil! Schneiden Sie die Nabelschnur durch und genießen Sie, wie unser Neugeborenes seine aufregende Reise in die Welt der verteilten Systeme antritt.
