Was ist Kubernetes?
Dies ist der erste Beitrag einer Miniserie, die sich dem Betrieb von Kubernetes auf AWS widmet. Eine Einführung in Kubernetes und Container-Orchestrierung finden Sie in unserem Leitfaden für Einsteiger. In diesem ersten Beitrag geht es um die Überlegungen, die wir angestellt haben, als wir unseren Kunden eine produktionsreife Kubernetes-Umgebung auf Enterprise-Niveau vorschlugen. Im nächsten Blogbeitrag werde ich auf die von uns verwendeten Tools und AWS-Services eingehen und versuchen, die von uns gelösten Probleme zu beschreiben.
Hohe Verfügbarkeit ist eine Eigenschaft, die unser System haben soll. Unser Ziel ist es, eine vereinbarte Betriebsleistung (Betriebszeit) über einen längeren Zeitraum als normal zu gewährleisten. Dies sind die Grundsätze, die wir bei der Systemkonzeption befolgen:
- Eliminierung einzelner Fehlerquellen. Dies bedeutet, dass dem System Redundanz hinzugefügt wird, so dass der Ausfall einer Komponente nicht zum Ausfall des gesamten Systems führt.
- Zuverlässige Kreuzung. In redundanten Systemen neigt der Kreuzungspunkt selbst dazu, zu einem Single Point of Failure zu werden. Zuverlässige Systeme müssen ein zuverlässiges Crossover gewährleisten.
- Erkennung von Fehlern, sobald sie auftreten. Wenn die beiden oben genannten Grundsätze beachtet werden, sieht ein Benutzer vielleicht nie einen Fehler. Aber die Wartungstätigkeit muss es.
Das folgende Diagramm zeigt die Kubernetes-Master-Komponenten, die zum Einrichten eines Clusters verwendet werden. Wir gehen sie nacheinander durch:
Sichern der ETCD-Verfügbarkeit
ETCD ist unser API-Objektspeicher, der von Kubernetes verwendet wird. Wenn wir die Daten hier verlieren, sind wir erledigt, wir verlieren unseren Cluster. Folgendes müssen wir beachten, wenn wir ETCD in einem hochverfügbaren Setup betreiben:
- Führen Sie ETCD als einen Cluster mit ungeraden Mitgliedern aus. Ein etc-Cluster benötigt eine Mehrheit von Knoten, ein Quorum, um sich auf Aktualisierungen des Cluster-Status zu einigen. Bei einem Cluster mit n Mitgliedern beträgt das Quorum (n/2)+1.
- ETCD ist ein führerbasiertes verteiltes System. Stellen Sie sicher, dass der Leader regelmäßig und rechtzeitig Heartbeats an alle Follower sendet, um den Cluster stabil zu halten.
- Stellen Sie sicher, dass kein Ressourcenmangel auftritt. Die Leistung und Stabilität des Clusters hängt von der Netzwerk- und Festplatten-IO ab. Jeder Ressourcenmangel kann zu einem Heartbeat-Timeout führen, was die Instabilität des Clusters verursacht. Ein instabiler ETCD zeigt an, dass kein Leader gewählt wurde. Unter solchen Umständen kann ein Cluster keine Änderungen an seinem aktuellen Zustand vornehmen, was bedeutet, dass keine neuen Pods geplant werden können.
- Die Stabilität von ETCD ist entscheidend für die Stabilität von Kubernetes-Clustern. Führen Sie ETCD daher auf dedizierten Maschinen oder in isolierten Umgebungen aus, um die Ressourcenanforderungen zu gewährleisten.
- Außerdem müssen wir sicherstellen, dass unsere Daten intakt bleiben, falls der laufende Host aus irgendeinem Grund ausfällt. Da wir unseren Cluster in Amazon betreiben, ist der Elastic Block Store (EBS) der bequemste und zuverlässigste Dienst, den wir nutzen können. Auf diese Weise können wir im Falle eines Stopps, einer Beendigung oder einer Migration den EBS einfach an eine andere Instanz anschließen. Jedes Amazon EBS-Volume wird automatisch innerhalb seiner Verfügbarkeitszone repliziert, um Sie vor Komponentenausfällen zu schützen, und bietet so hohe Verfügbarkeit und Haltbarkeit.
Aufbau eines zuverlässigen API-Servers
Wenn ETCD das Gehirn unseres Clusters ist, dann ist der Kubernetes-API-Server wie der Rest des Nervensystems. Der API-Server fungiert als Vermittler für alle Daten, die in ETCD ein- und ausgehen - von Ihnen und von den Worker Nodes, auf denen Ihre Anwendung bereitgestellt wird. Das Tolle am API-Server ist, dass die Überlegungen für ihn hauptsächlich von Ihren Überlegungen für ETCD bestimmt werden. Da jeder Master-Knoten in Ihrem Cluster eine ETCD-Mitgliedschaft hat und als API-Server fungiert, haben Sie eine hohe Verfügbarkeit sowohl für die Daten, die Ihr API-Server verbraucht, als auch für die Funktionalität des API-Servers.
Der API-Server in diesem manuellen Setup kommuniziert mit ETCD über localhost. Auf diese Weise müssen Sie nie befürchten, dass der API-Server von seinen Daten getrennt wird. Unsere Arbeit hier besteht darin, einen API-Server zu installieren und einen Load Balancer vor jedem Server einzurichten, damit die Last über unser gesamtes System verteilt wird. Der Load Balancer lässt sich leicht mit Amazon ELB einrichten. Nachdem wir unsere Load-Balancer-Adresse haben, benötigen wir sie beim Einrichten der restlichen Master-Komponenten.
Einrichten eines Controller-Managers und eines Schedulers
Wir haben bisher nichts getan, was den Cluster-Status tatsächlich verändert, wie zum Beispiel die Controller-Manager und Planer. Um Zuverlässigkeit zu erreichen, soll nur ein Akteur den Zustand des Clusters ändern. Außerdem wollen wir replizierte Instanzen dieser Akteure, für den Fall, dass die Maschine ausfällt. Leasing-Schloss wird in der API verwendet, um eine Master-Wahl durchzuführen (Flag "leader-elect"). Der Scheduler und der Controller-Manager können so konfiguriert werden, dass sie über die IP-Adresse der API-Server mit Lastausgleich kommunizieren. Unabhängig davon, wie sie konfiguriert sind, muss der Planer und controller-manager wird den oben erwähnten Prozess der Wahl des Anführers mit Hilfe der -Leiter-gewählt Flagge.
Kubernetes Worker-Komponenten im Detail
Wenn ETCD das Gehirn ist und der API-Server der Rest des Nervensystems - dann sind die Worker ihre Arme und Beine. Ihre Worker sind der Ort, an dem sich Ihre Anwendungen befinden, mit denen alle anderen interagieren, und sie sind in gewisser Weise der unwichtigste Teil, was das Leben Ihres Clusters betrifft. Worker können sterben und ersetzt werden, ohne dass dies irgendwelche Auswirkungen auf Ihren Cluster hat. Wenn Sie mehrere Worker haben, kann Ihre Anwendung in den meisten Situationen ihre Funktionalität beibehalten. Sie wollen immer mehrere Untergebene, aber bedenken Sie, dass die Skalierung Ihrer Untergebenen extrem schnell und einfach ist. Es ist im Allgemeinen sicher, mit einer kleinen Anzahl zu beginnen - und in der Zukunft mehr hinzuzufügen, wenn der Platz, der Speicher und die CPU knapp werden.
kubelet holt sich die Konfiguration eines Pods vom API-Server und stellt sicher, dass die beschriebenen Container einsatzbereit sind. Dies ist der Arbeitsdienst, der für die Kommunikation mit dem Master-Knoten verantwortlich ist. Er kommuniziert auch mit etcd, um Informationen über Dienste zu erhalten und die Details über neu erstellte Dienste zu schreiben.
kube-proxy fungiert als Netzwerkproxy und Lastausgleich für einen Dienst auf einem einzelnen Arbeiterknoten. Er kümmert sich um das Netzwerk-Routing für TCP- und UDP-Pakete.
Einrichtung mehrerer Zonen
Die Unterstützung für mehrere Zonen ist absichtlich begrenzt: Ein einzelner Kubernetes-Cluster kann in mehreren Zonen ausgeführt werden, aber nur innerhalb derselben Region (und desselben Cloud-Anbieters). Eine der Einschränkungen eines Multizonen-Setups besteht darin, dass wir sicherstellen müssen, dass sich die verschiedenen Zonen im Netzwerk nahe beieinander befinden, weshalb wir kein zonenbasiertes Routing durchführen. Insbesondere der Datenverkehr, der über Dienste läuft, kann zonenübergreifend sein (selbst wenn Pods in einigen Pods, die diesen Dienst unterstützen, in derselben Zone wie der Client existieren), was zusätzliche Latenzzeiten und Kosten verursachen kann.
Apropos Skalierbarkeit...
Ich habe kaum über die Methoden gesprochen, mit denen Sie Ihre Anwendungen skalieren können. Wir wollen, dass dies so flexibel wie möglich ist. Wir haben zwei Instanzkomponenten, die skaliert werden müssen.
Skalierender Kubernetes-Master - Egal, ob Sie ein kleines Startup oder ein großes Unternehmen sind, wenn Sie sich für Hochverfügbarkeit in Amazon entscheiden, möchten Sie, dass Ihre Master in der gesamten Region funktionieren. In diesem Beispiel verwende ich eu-west-1 (Irland). In jeder Verfügbarkeitszone (eu-west-1a, eu-west-1b, eu-west-1c) werden wir 1 Kubernetes-Master festlegen, der seiner eigenen Auto-Scaling-Gruppe zugewiesen wird .
Warum ist jeder Master in seiner eigenen Auto-Scaling-Gruppe? - Der Hauptgrund dafür ist, dass wir uns vor der Replikation einer ungesunden Instanz schützen wollen.
Skalierung von Kubernetes Worker
Wie ein paar Zeilen weiter oben beschrieben, ist unser Kubernetes-Arbeitsknoten unser Arbeitspferd. Es reicht aus, ihn einmal einzurichten und zu konfigurieren. Danach ist es einfach, ihn einer Auto-Scaling-Gruppe zuzuweisen. Wenn Sie dies tun und die "gewünschte" Anzahl von Worker-Instanzen erhöhen, werden Sie genau dieselben Hosts mit genau denselben Worker-Komponenten verwenden. Ihre Cubelets werden alle gleich konfiguriert und können sich beim Kubernetes-Master anmelden. Gehen einer der Worker-Instanzen die Ressourcen aus, wird eine neue in die andere Availability Zone gebracht. Dieser Mechanismus ist einer der stärksten in Bezug auf die Skalierung bei Amazon.
Nach all diesen Gesprächen sind wir zu der unten stehenden Architektur gelangt:
So einfach ist es, einen Kubernetes-Cluster in einem hochverfügbaren Modus mit persistentem Speicher in Amazon einzurichten 🙂
Im nächsten Blogbeitrag wird es technischer. Wir werden einen Kubernetes-Cluster in Amazon von Grund auf einrichten, mit einem neuen Amazon IAM-Konto. Dann werde ich zeigen, wie einfach dieser Prozess mit Hilfe von kops und seiner Magie ist.
