Einführung in die Cloud-native-Technologie Kubernetes (K8S)

Heute werden wir uns die Einführung in die Kubernetes-Technologie ansehen. Vor kurzem habe ich mir die ausführliche Präsentation von Lehrer Zhang Lei zur Kubernetes-Technologie auf Geek Time angesehen. Sie war sehr gut präsentiert. Interessierte Schüler können sie sich anhören. Sie ist sehr hilfreich, um die Kubernetes-Technologie zu verstehen. Hier werde ich meine Lernnotizen entsprechend meinem eigenen Fortschritt teilen.

Heute stehen wir auf einer höheren Ebene und es wird mehr konzeptionelle Dinge geben.

01 Was ist Kubernetes?

Früher dachte ich, diese Frage sei leicht zu beantworten, aber als ich mein Verständnis für Kubernetes weiter vertiefte und immer tiefer in die Materie eindrang, stellte ich fest, dass es schwierig ist, diese Frage umfassend zu beantworten.

Um dieses Problem zu verstehen, müssen Sie zunächst wissen, was ein Container ist. Im vorherigen Artikel haben wir gesagt, dass ein Container ein spezieller Prozess ist, der eigentlich eine spezielle Prozessisolationsumgebung ist, die mit drei Technologien erstellt wurde: Namespace, Cgroup und Rootfs. Der Hauptzweck dieser isolierten Umgebung besteht darin, unsere eigenen Anwendungen auszuführen.

Für Cloud-Anbieter gilt: Wenn sie die von Benutzern übermittelten Docker-Images in der Containerumgebung ihrer eigenen Plattform ausführen und gut verwalten können, hat diese Cloud-Plattform einen kommerziellen Wert. Tatsächlich wird dies erreicht.

Wenn Sie jedoch die Anerkennung der Benutzer gewinnen möchten, reicht es nicht aus, einen Container oder das Docker-Image eines Benutzers zu unterstützen. Vielmehr geht es darum, unzählige Entwickler und einen großen Container-Cluster zu unterstützen, damit Ihre Plattform vom gesamten Cloud-native-Ökosystem erkannt wird. Aufgrund dieser Tatsache ist es nicht schwer festzustellen, dass im Containerbereich derjenige bevorzugt wird, der die Verwaltung von Container-Clustern besser organisieren, planen, orchestrieren und standardisieren kann.

Hier habe ich zwei Wörter rot markiert, nämlich Planung und Choreographie. Diese beiden Wörter müssen erklärt werden:

Planung: Platzieren eines Containers auf dem besten Knoten, damit er gemäß bestimmten Regeln ausgeführt werden kann

Orchestrierung: Verarbeitet die Beziehungen zwischen Containern vollautomatisch nach den Wünschen des Benutzers und den Regeln des Gesamtsystems

In diesem Zusammenhang entstanden die native Compose+Swarm-Kombination von Docker und das Kubernetes-Projekt von Google. Warum hat Kubernetes am Ende gewonnen? Schauen wir es uns langsam an.

Die theoretische Grundlage des Kubernetes-Projekts ist fortschrittlicher als seine technische Praxis. Das Kubernetes-Projekt entstand aus Borg, einem Kernsystem der Infrastruktur von Google. Im Vergleich zu anderen Container-Orchestrierungsprojekten verkörpert es eine Reihe von „Fortschrittlichkeit“ und „Vollständigkeit“, und diese Merkmale sind zum Kernwert geworden, auf den sich das Kubernetes-Projekt stützt.

Mit der Einführung von Kubernetes wurden die Engpässe bei der Container-Orchestrierung, -Planung und Cluster-Verwaltung behoben. Außerdem wurde ein Problem für Benutzer gelöst: Ich habe ein Container-Image einer Anwendung. Bitte helfen Sie mir, diese Anwendung auf einem Cluster auszuführen. Dies reicht jedoch nicht aus, um die Compose + Swarm-Architektur zu ersetzen, da die native Compose + Swarm-Architektur von Docker auch den Betrieb von Containern sowie grundlegende Betriebs- und Wartungsverwaltungsfunktionen lösen kann.

Was Kubernetes noch wertvoller macht, ist, dass es nicht von Anfang an um den spezifischen Container Docker herum entwickelt wurde. Es betrachtet Docker nur als zugrunde liegende Containerimplementierung. Das Problem, auf dessen Lösung es sich konzentriert, besteht darin, dass es tatsächlich verschiedene Beziehungen zwischen Aufgaben gibt, die in großem Maßstab ausgeführt werden. Die Handhabung dieser Beziehungen ist der schwierigste Teil der Aufgabenorchestrierung und des Systemmanagements.

Es gibt viele Arten von Beziehungen zwischen diesen Aufgaben, beispielsweise die Beziehung zwischen einer Webanwendung und einer MySQL-Datenbank, die Beziehung zwischen einem Ladeproxy und Backend-Diensten usw.

Herkömmliche virtuelle Maschinen bewältigen diese Art von Aufgaben, indem sie sie normalerweise gemeinsam bereitstellen, da zwischen den Aufgaben TCP- oder HTTP-Anfragen auftreten. Mit dem Aufkommen der Containertechnologie können jedoch alle Aufgaben durch Spiegelung in unterschiedliche Container gekapselt werden, sodass sie sich nicht gegenseitig stören, über eine eigene Ressourcenkonfiguration verfügen und vom Cluster auch auf unterschiedlichen Maschinen geplant werden können. wie folgt:

02 Der Unterschied zwischen Kubernetes und Compost+Swarm

Diese Art der Beziehungsverarbeitung zwischen Aufgaben ist auch der offensichtlichste Unterschied zwischen dem Kubernetes-Projekt und der Compost+Swarm-Architektur.

Am Beispiel der Webanwendung und der MySQL-Dienste wird in der Compost+Swarm-Architektur eine „Verbindung“ zwischen den beiden Diensten definiert und das Docker-Projekt ist für die Aufrechterhaltung dieser „Verbindung“ verantwortlich. Docker fügt die IP und den Port des DB-Containers als Umgebungsvariablen in den Container dieser Webanwendung ein, damit sie vom Anwendungsprozess verwendet werden können. Wenn sich die Verbindungsinformationen des DB-Containers ändern, werden die Umgebungsvariablen aktualisiert.

Das Compost+Swarm-Entwurfsmuster kann die Verbindung zwischen Webanwendungen und MySQL-Diensten besser unterstützen, in Zukunft kann es jedoch Verbindungen zwischen mehr Aufgabentypen geben, und diese einfache Fähigkeit zur Handhabung von Abhängigkeiten wird definitiv auf Engpässe stoßen.

Die zentrale Entwurfsidee des Kubernetes-Projekts besteht darin, die verschiedenen Beziehungen zwischen Aufgaben aus einer eher makroökonomischen Perspektive einheitlich zu definieren und Raum für die zukünftige Unterstützung weiterer Beziehungstypen zu lassen.

Beispielsweise klassifiziert Kubernetes die gegenseitigen Aufrufe zwischen Containern, um zu unterscheiden, bei welchen Interaktionen es sich um häufige TCP-Interaktionen handelt, bei welchen es sich lediglich um Festplattendateiinteraktionen handelt usw. Für diese Aufgaben, die Interaktion erfordern, besteht die herkömmliche Vorgehensweise darin, verschiedene Aufgaben auf derselben Maschine bereitzustellen und über Localhost zu kommunizieren. Kubernetes führt das Service-Konzept ein, mit dem zwei ursprünglich voneinander abhängige Dienste auf verschiedenen Maschinen bereitgestellt werden können. Hinter jedem Service stehen mehrere Pods. Die Funktion des Services besteht darin, einen festen Proxy-Eintrag für den Pod bereitzustellen, und die Verteilung des Pods erfolgt völlig zufällig.

Auf diese Weise muss sich der Web-Anwendungs-Pod lediglich um die Serviceinformationen des Datenbank-Pods kümmern. Es ist nicht schwer, sich vorzustellen, dass die automatische Aktualisierung und Pflege der IP-Adresse, des Ports und anderer Informationen des Pods, die das Service-Backend tatsächlich weiterleitet, in der Verantwortung des Kubernetes-Projekts liegt.

03 Zusammenfassung

Heute haben wir mit dem grundlegendsten Konzept des Containers begonnen und den Hintergrund von k8s vorgestellt. Durch die „enge Zusammenarbeit“ zwischen Webanwendung und MySQL-Dienst haben wir es auch auf Pod erweitert. Mit Pod hoffen wir, mehrere Anwendungsinstanzen gleichzeitig starten zu können, daher benötigen wir Deployment, einen Multi-Instanz-Manager von Pod (der später erläutert wird); und mit einer solchen Gruppe identischer Pods müssen wir über eine feste IP-Adresse und einen festen Port lastausgeglichen darauf zugreifen, sodass wir Service haben. Wenn die Webanwendung ein Konto und ein Kennwort benötigt, um auf MySQL zuzugreifen, führen wir Secret ein … Schließlich sehen Sie das folgende Bild:

Wir werden den spezifischen Inhalt später analysieren. . .

Ich habe so viel vor allem gesagt, um zum Ausdruck zu bringen, dass das Kubernetes-Projekt nicht wie andere Projekte ist, die für jede Verwaltungsfunktion eine Anweisung erstellen und die Logik dann im Projekt implementieren.
Im Gegensatz dazu empfehlen wir im Kubernetes-Projekt folgenden Ansatz:
1. Beschreiben Sie zunächst die Anwendung, die Sie über ein „Orchestrierungsobjekt“ wie Pod, Job, CronJob usw. verwalten möchten.
2. Definieren Sie dann einige „Serviceobjekte“ dafür, wie etwa Service, Secret, Horizontal Pod Autoscaler usw. Diese Objekte sind für bestimmte Funktionen auf Plattformebene verantwortlich.
Diese Verwendungsmethode ist die sogenannte „deklarative API“. Die dieser API entsprechenden „Orchestrierungsobjekte“ und „Serviceobjekte“ sind beide API-Objekte im Kubernetes-Projekt.
Dies ist das zentrale Designkonzept von Kubernetes.

Das ist alles für heute.

Oben finden Sie eine ausführliche Einführung in die Cloud-native Technologie Kubernetes (K8S). Weitere Informationen zur Cloud-nativen Technologie Kubernetes (K8S) finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!