1.Was ist Kubernetes?
Kubernetes ist eine neue führende Lösung für verteilte Architektur basierend auf Container-Technologie. Wenn das Systemdesign den Designideen von Kubernetes folgt, können die zugrunde liegenden Code- oder Funktionsmodule in der traditionellen Systemarchitektur, die wenig mit dem Geschäft zu tun haben, aus unserem Blickfeld verschwinden, und wir müssen uns nicht mehr um die Auswahl und Auswahl kümmern Load Balancer. Probleme bei der Bereitstellungsimplementierung. Kubernetes ist außerdem eine Entwicklungsplattform und nicht auf eine Sprache beschränkt, sodass bestehende Systeme problemlos geändert, aktualisiert und auf Kubernetes migriert werden können. Schließlich ist Kubernetes eine vollständige verteilte Systemunterstützungsplattform.
2. Warum Kubernetes verwenden?
Es gibt viele Gründe, Kubernetes zu nutzen. Der wichtigste Grund ist, dass die IT-Branche schon immer von neuen Technologien angetrieben wurde. Derzeit wird die Containerisierungstechnologie Docker von vielen Unternehmen übernommen. Der Übergang von einer einzelnen Maschine zu einem Cluster ist unumgänglich geworden. Die boomende Entwicklung der Datenverarbeitung beschleunigt diesen Prozess.
Welche Vorteile bietet die Verwendung von Kubernetes?
Erstens können komplexe Systeme „leicht“ entwickelt werden.
Zweitens kann die Microservice-Architektur vollständig genutzt werden.
Drittens kann das gesamte System jederzeit in die Public Cloud „verlagert“ werden.
Dann ermöglicht uns der inhärente elastische Erweiterungsmechanismus von Kubernetes, plötzlichen Datenverkehr problemlos zu bewältigen.
Schließlich kann die superhorizontale Erweiterungsfähigkeit der Kubernetes-Systemarchitektur unsere Wettbewerbsfähigkeit erheblich verbessern.
3.Grundlegende Konzepte und Terminologie von Kubernetes
Die meisten Konzepte in Kubernetes können als Ressourcenobjekt betrachtet werden. Fast alle Ressourcenobjekte können über das Kubectl-Tool von Kubernetes hinzugefügt, gelöscht, geändert, überprüft usw. und zur dauerhaften Speicherung in etcd gespeichert werden. Aus dieser Perspektive ist Kubernetes ein hochautomatisiertes Ressourcenkontrollsystem.
Im Folgenden werden die wichtigen Ressourcenobjekte in Kubernetes vorgestellt
3.1Meister
Der Master in Kubernets bezieht sich auf den Cluster-Kontrollknoten. Alle von uns ausgeführten Befehle werden grundsätzlich auf dem Master ausgeführt. Auf dem Master laufen folgende Schlüsselprozesse:
kube-apiserver: stellt den Schlüsseldienstprozess der HTTP-Rest-Schnittstelle bereit. Es ist der einzige Einstiegspunkt für Vorgänge wie das Hinzufügen, Löschen, Ändern und Überprüfen aller Ressourcen in Kubernets. Es ist auch der Einstiegsprozess für die Clustersteuerung.
kube-controller-manager: Das automatisierte Kontrollzentrum für alle Ressourcenobjekte.
kube-scheduler: Der Prozess, der für die Ressourcenplanung verantwortlich ist.
Darüber hinaus muss der etcd-Dienst auf dem Master bereitgestellt werden, da die Daten von Ressourcenobjekten in etcd gespeichert werden.
3.2Knoten
Arbeitslastknoten: Wenn ein Knoten ausfällt, wird die darauf befindliche Arbeitslast vom Master automatisch auf andere Knoten übertragen. Auf jedem Knoten finden die folgenden Prozesse statt:
Kubelet: Verantwortlich für Aufgaben wie das Erstellen, Starten und Stoppen von Containern, die Pods entsprechen, und enge Zusammenarbeit mit dem Master, um grundlegende Funktionen der Clusterverwaltung zu implementieren.
Kube-Proxy: Eine wichtige Komponente, die den Kommunikations- und Lastausgleichsmechanismus des Kubernet-Dienstes implementiert
Docker-Engine: Docker-Engine, verantwortlich für die lokale Containererstellung und -verwaltung
Häufig verwendete Befehle:
kubectl get nodes Überprüfen Sie, wie viele Knoten sich im Cluster befinden
kubectl beschreiben Knoten Knotenname Detaillierte Informationen zu einem Knoten anzeigen
3.3 Pod
Pod ist das wichtigste Grundkonzept. Jeder Pod verfügt über einen speziellen Pausencontainer, den sogenannten Root-Container, und enthält außerdem einen oder mehrere eng verbundene Benutzergeschäftscontainer.
Was ist der besondere Aufbau von Pod und warum gibt es ein neues Pod-Konzept?
Wenn eine Gruppe von Containern als Einheit erhalten wird, ist es für uns schwierig, einfach das „Ganze“ zu beurteilen und effektiv zu handeln. Durch die Einführung eines Pausencontainers, der nichts mit dem Geschäft zu tun hat und als Root-Container des Pods nicht leicht zu sterben ist und dessen Status den Status des gesamten Containers darstellt, wird dieses Problem einfach gelöst. Mehrere Geschäftscontainer in einem Pod teilen sich die IP des Pausencontainers und das vom Pausencontainer gemountete Volume, wodurch auch das Dateifreigabeproblem zwischen ihnen gelöst wird. Kubernetes weist jedem Pod eine eindeutige IP-Adresse zu. Mehrere Container in einem Pod teilen sich die Pod-IP-Adresse. In Kubernetes kann ein Container in einem Pod direkt mit einem Pod-Container auf einem anderen Host kommunizieren.
Jedes Ressourcenobjekt in Kubernetes kann mithilfe von Dateien im Yaml- oder JSON-Format definiert oder beschrieben werden.
Endpunkt: Pod-IP plus Containerport bilden dieses neue Konzept
Pod-Volume: Basierend auf der Erweiterung des Dcker-Volumes kann das verteilte Dateisystem als Back-End-Speicherfunktion verwendet werden, die auf dem Pod definiert und dann vom Container in das entsprechende Dateisystem eingebunden wird.
pod Event: Aufzeichnung von Ereignissen.
3.4Etikett
Label ist ein weiteres Kernkonzept in Kubernetes. Ein Label ist ein Schlüssel=Wert-Paar. Ein Label kann an verschiedene Ressourcenobjekte angehängt werden. Ein Ressourcenobjekt kann eine beliebige Anzahl von Labels definieren und das gleiche Label kann auch einer beliebigen Anzahl von Ressourcenobjekten hinzugefügt werden.
Label kann Ressourcenobjekte mit bestimmten Labels über den Label-Selektor abfragen und filtern. matchLabels wird verwendet, um eine Reihe von Beschriftungen zu definieren, und matchExpressions wird verwendet, um eine Reihe satzbasierter Filterbedingungen zu definieren.
Die wichtigen Verwendungsszenarien des Label-Selektors in Kubernetes sind wie folgt:
Der Kube-Controller-Prozess filtert die Anzahl der zu überwachenden Pod-Kopien über den im Ressourcenobjekt RC definierten Label-Selektor.
Kube-Proxy filtert die entsprechenden Pods über den Label-Selektor im Dienst und erstellt automatisch eine Routing-Anforderungstabelle von jedem Dienst zum entsprechenden Pod, wodurch ein intelligenter Lastausgleich erreicht wird.
Durch die Definition einer bestimmten Bezeichnung für einen Knoten und die Verwendung des Knotenselektors für die Bezeichnungsplanungsstrategie in der Pod-Definitionsdatei kann der Kube-Scheduler-Prozess die Pod-gesteuerte Planungsfunktion implementieren.
3.5 Replikationscontroller
RC definiert ein erwartetes Szenario, was bedeutet, dass die Anzahl der Kopien eines bestimmten Pods zu jedem Zeitpunkt einen bestimmten erwarteten Wert erreicht. Die Definition von RC umfasst also Folgendes:
Die Anzahl der Replikate, die der Pod erwartet.
Label-Selektor zum Filtern von Ziel-Pods
Die Pod-Vorlage wird zum Erstellen eines neuen Pods verwendet, wenn weniger Pod-Replikate als erwartet vorhanden sind.
Replikatsatz: Der einzige Unterschied zum aktuellen RC besteht darin, dass er eine satzbasierte Etikettenauswahl unterstützt
Eigenschaften und Funktionen von RC (Replica Set):
In den meisten Fällen realisieren wir die Erstellung von Pods und die automatische Steuerung der Anzahl der Kopien durch die Definition eines RC.
Fügen Sie die vollständige Pod-Definitionsvorlage in RC ein
RC realisiert die automatische Steuerung von Pod-Kopien über den Etikettenauswahlmechanismus.
Durch Ändern der Anzahl der Pod-Kopien in RC kann eine Pod-Erweiterung und -Kontraktion erreicht werden
Durch Ändern der Bildversion in der Pod-Vorlage in RC kann ein fortlaufendes Upgrade des Pods erreicht werden.