Was ist Kubernetes?

Was ist Kubernetes? Und was ist seine Architektur?

Die Containerisierung hat das Kabel zwischen Softwareentwicklern und Produktionsumgebung gesenkt. Nicht in dem Sinne, dass Sie überhaupt kein Produktionssystem benötigen, aber Sie müssen sich keine Sorgen über die Spezifität der Produktionsumgebung machen.

Die Apps sind jetzt mit den Abhängigkeiten gebündelt, die sie benötigen, in einem leichten Behälter anstelle eines VM. Das ist großartig! Es bietet jedoch keine Immunität gegen Systemausfälle, Netzwerkausfälle oder Festplattenfehler. Wenn beispielsweise das Rechenzentrum, in dem Ihre Server ausgeführt werden, in Wartung steht, wird Ihre Anwendung offline gehen.

Kubernetes kommt ins Bild, um diese Probleme zu lösen. Es nimmt die Idee von Containern und erweitert es, über mehrere Rechenknoten hinweg zu funktionieren (bei der Cloud -Hosted Virtual Machine oder Bare Metal -Server sein könnten). Die Idee ist, ein verteiltes System für Containeranwendungen zu haben, auf denen sie ausgeführt werden müssen.

Warum Kubernetes?

Warum müssten Sie nun überhaupt eine verteilte Umgebung benötigen??

Aus mehreren Gründen ist in erster Linie eine hohe Verfügbarkeit von hoher Verfügbarkeit. Sie möchten, dass Ihre E-Commerce-Website rund um die Uhr online bleibt, oder Sie werden Geschäfte verlieren, Kubernetes dafür verwenden. Zweitens ist die Skalierbarkeit, wo Sie "aus Skalieren" möchten. Durch Skalieren hier werden weitere Rechenknoten hinzugefügt, um Ihrer wachsenden Anwendung mehr Beinraum zum Betrieb zu geben.

Design und Architektur

Wie jedes verteilte System hat ein Kubernetes -Cluster einen Masterknoten und dann viele Arbeiterknoten, an denen Ihre Anwendungen tatsächlich ausgeführt werden. Der Master ist verantwortlich für die Planung von Aufgaben, die Verwaltung von Workloads und das sichere Hinzufügen neuer Knoten zum Cluster.

Natürlich kann der Masterknoten selbst scheitern und den gesamten Cluster mitnehmen.

Eine Vogelperspektive einer typischen Kubernetes -Bereitstellung

Kubernetes Master

Der Kubernetes -Master ist das, mit dem das DevOps -Team interagiert und zur Bereitstellung neuer Knoten, der Bereitstellung neuer Apps und Ressourcenüberwachung und -verwaltung interagiert und diese verwendet. Die grundlegendste Aufgabe des Masterknotens ist es Zeitplan Die Arbeitsbelastung effizient unter allen Arbeiterknoten, um die Ressourcennutzung zu maximieren, die Leistung zu verbessern und verschiedene Richtlinien zu befolgen, die vom DevOps -Team für ihre bestimmte Arbeitsbelastung ausgewählt wurden.

Eine andere wichtige Komponente ist die etcd Das ist ein Daemon, der die Arbeiterknoten im Auge behält und eine Datenbank speichert, die den Status des gesamten Clusters speichert. Es handelt sich um einen Schlüsselwertdatenspeicher, der auch in einer verteilten Umgebung über mehrere Master-Knoten ausgeführt wird. Der Inhalt von ETCD liefert alle relevanten Daten über den gesamten Cluster. Ein Arbeiterknoten würde den Inhalt von ETCD von Zeit zu Zeit betrachten, um festzustellen, wie er sich verhalten sollte.

Regler ist die Entität, die Anweisungen vom API -Server (die wir später behandeln werden) und die erforderlichen Aktionen wie Erstellung, Löschung und Aktualisierung von Anwendungen und Paketen ausführen würden.

Der API -Server Enthält die Kubernetes -API, die JSON Payloads über HTTPS verwendet. Sowohl die Web -Benutzeroberfläche als auch die CLI konsumieren diese API, um mit dem Kubernetes -Cluster zu interagieren.

Der API -Server ist auch für die Kommunikation zwischen den Arbeiterknoten und verschiedenen Masterknotenkomponenten wie etcd verantwortlich.

Der Masterknoten ist dem Endbenutzer niemals ausgesetzt, da er die Sicherheit des gesamten Clusters riskieren würde.

Kubernetes Knoten

Eine Maschine (physisch oder virtuell) würde einige wichtige Komponenten benötigen, die nach dem ordnungsgemäßen und ordnungsgemäßen Einrichten diesen Server in ein Mitglied Ihres Kubernetes -Clusters verwandeln können.

Das erste, was Sie benötigen. Es wird offensichtlich dafür verantwortlich sein, Container zu spinnen und zu verwalten.

Zusammen mit der Docker -Laufzeit brauchen wir auch die Kuberett Dämon. Es kommuniziert über den API -Server mit den Masterknoten und fragt die ETCD ab und gibt wieder Gesundheit und Nutzungsinformationen über die Pods, die auf diesem Knoten ausgeführt werden.

Die Behälter sind jedoch für sich selbst ziemlich begrenzt, sodass Kubernetes eine höhere Abstraktion auf einer Sammlung von Containern aufbaut, die als bekannt als bekannt sind Schoten.

Warum sich Schoten einfallen lassen??

Docker hat die Richtlinie, einen Antrag pro Container auszuführen. Oft beschrieben als die "Ein Prozess pro Container" Politik. Wenn Sie eine WordPress -Site benötigen, werden Sie aufgefordert, zwei Container zu haben, auf die die Datenbank ausgeführt werden kann, und einen anderen, auf dem der Webserver ausgeführt werden kann. Bündeln Sie solche verwandten Komponenten einer Anwendung in einen POD, stellt sicher, dass die beiden voneinander abhängigen Container, wenn Sie skalieren, immer auf demselben Knoten existieren und so schnell und einfach miteinander sprechen.

Pods sind die grundlegende Einsatzeinheit in Kubernetes. Wenn Sie skalieren, fügen Sie dem Cluster weitere Schoten hinzu. Jeder Pod erhält eine eindeutige IP -Adresse im internen Netzwerk des Clusters.

Zurück zum Kubernetes -Knoten

Jetzt kann ein Knoten mehrere Pods ausführen und es kann viele solcher Knoten geben. Das ist alles in Ordnung, bis Sie darüber nachdenken, mit der externen Welt zu kommunizieren. Wenn Sie einen einfachen webbasierten Service haben, wie würden Sie Ihren Domain-Namen auf diese Sammlung von Pods mit vielen IP-Adressen richten?

Du kannst nicht, und du musst nicht! Kube-Proxy ist das letzte Stück des Puzzles, mit dem die Betreiber bestimmte Schoten dem Internet aussetzen können. Zum Beispiel kann Ihr Front-End öffentlich zugänglich gemacht werden, und der Kube-Proxy würde den Verkehr auf alle verschiedenen Schoten verteilen, die für die Hosting des Frontend verantwortlich sind. Ihre Datenbank muss jedoch nicht öffentlich gemacht werden, und Kube-Proxy würde nur eine interne Kommunikation für solche Back-End-Arbeitsbelastungen ermöglichen.

Benötigen Sie das alles??

Wenn Sie gerade erst als Hobbyist oder Student anfangen, wäre die Verwendung von Kubernetes für eine einfache Anwendung tatsächlich ineffizient. Das gesamte Rigmarole würde mehr Ressourcen als Ihre tatsächliche Anwendung konsumieren und eine einzelne Person mehr Verwirrung verleihen.

Wenn Sie jedoch mit einem großen Team zusammenarbeiten und Ihre Apps für den ernsthaften kommerziellen Gebrauch einsetzen, ist Kubernetes den Zusatzaufwand wert. Sie können verhindern, dass die Dinge chaotisch werden. Machen Sie Platz für die Wartung ohne Ausfallzeiten. Setup Nifty A/B-Testbedingungen einrichten und allmählich ausgrößen, ohne zu viel für die Infrastruktur im Voraus auszugeben.