Warum sollten Sie sich für eine Multi-Master-Einrichtung entscheiden?
Um ein wirklich zuverlässiges, hochverfügbares verteiltes System für Ihre Anwendungen zu haben. Master-Fehlertoleranz.
Warum sollten Sie sich für eine Mehrzonenanlage entscheiden?
Verbesserung der Verfügbarkeit im Falle eines Ausfalls/Wartung einer einzelnen Zone. Toleranz bei Zonenausfall.
Warum 3 Master?
Einige der Hauptkomponenten müssen als ein einziger Akteur ausgeführt werden, um eine Split-Brain-Situation zu vermeiden. Mehr über den Abschnitt "Gewählte Master-Komponenten" weiter unten
Warum 3 Arbeiter?
Falls eine der Zonen ausfällt, müssen die Anwendungen in der anderen Zone gestartet werden können. Wir können "Pod-Affinität" verwenden, um unsere Pods in einer Zone mit einer höheren Anzahl von Arbeitern auszuführen
Wie kann man skalieren?
Durch die Verwendung von Amazons Single auto-scaling group, die mehrere Zonen umfasst.
Wie wird die dauerhafte Speicherung eingestellt?
AWS S3 ist mit Kubernetes kompatibel. Amazon EBS bietet persistente Blockspeicher-Volumes für die Verwendung mit Amazon EC2-Instances in der AWS-Cloud.
Wie überwacht man in AWS?
Wir können Open-Source-Tools wie Icinga2, Prometheus usw. verwenden oder uns für Amazon CloudWatch Service entscheiden. Beide sind geeignete Lösungen.
DIE HERAUSFORDERUNG
Erstellen Sie einen hochverfügbaren Kubernetes-Cluster mit Funktionen wie Master-Fehlertoleranz und Zonenfehlertoleranz.
DIE LÖSUNG
Einrichtung von redundantem, zuverlässigem Speicher:
Das oberste Gebot der Hochverfügbarkeit ist der Schutz der Daten. Was auch immer sonst passiert, was auch immer in Brand gerät, wenn man die Daten hat, kann man sie wiederherstellen.
Clustering ETCD
Verwenden Sie den persistenten Speicher von Amazon S3, der für eine Haltbarkeit von 99,999999999 % ausgelegt ist
https://aws.amazon.com/s3/ ODER Jedes Amazon EBS-Volume ist für eine Verfügbarkeit von 99,999 % ausgelegt und wird automatisch innerhalb seiner Availability Zone repliziert, um Ihre Anwendungen vor Komponentenausfällen zu schützen. https://aws.amazon.com/ebs/
Replizierte API:
Installieren Sie den API-Server auf allen Master-Knoten mit der YAML-Definition.
Richten Sie den Lastausgleich zwischen den Master-Knoten mit der gewünschten Methode ein. Bei AWS verwenden Sie ELB.
Master hat Komponenten gewählt:
Bisher haben wir noch nichts getan, was den Zustand des Clusters tatsächlich verändert, wie z. B. der Controller-Manager und der Scheduler. Um Zuverlässigkeit zu erreichen, wollen wir nur einen Akteur, der den Zustand des Clusters ändert, aber wir wollen auch replizierte Instanzen dieser Akteure, falls der Rechner stirbt. Lease-lock wird in der API verwendet, um die 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, führen der Scheduler und der Controller-Manager den oben erwähnten Prozess der Leader-Wahl durch, wenn sie das Flag "leader-elect" verwenden.
Falls der Zugriff auf den API-Server ausfällt, kann der gewählte Leader den Lease nicht erneuern, so dass ein neuer Leader gewählt werden muss. Dies ist besonders relevant, wenn der Scheduler und der Controller Manager so konfiguriert sind, dass sie über 127.0.0.1 auf den API-Server zugreifen, während der API-Server auf demselben Knoten nicht verfügbar ist.
Hinzufügen von Arbeitskräften:
Für einen neuen Cluster: Wir müssen das Kubelet und den Kube-Proxy auf jedem Worker-Node installieren und das Flag -apiserver auf Ihren replizierten Endpunkt setzen.
Multi-Zonen-Einrichtung:
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).
Bei Clustern mit mehreren Zonen wird dieses Verteilungsverhalten auf alle Zonen ausgedehnt (um die Auswirkungen von Zonenausfällen zu verringern). (Dies wird über SelectorSpreadPriority erreicht).
Einschränkungen bei der Einrichtung mehrerer Zonen:
Wir müssen sicherstellen, dass sich die verschiedenen Zonen im Netzwerk nahe beieinander befinden, daher führen wir kein zonenabhängiges Routing durch. Insbesondere der Datenverkehr, der über Dienste läuft, kann zonenübergreifend sein (auch wenn die Pods in einigen Pods, die diesen Dienst unterstützen, in derselben Zone wie der Client liegen), was zusätzliche Latenzzeiten und Kosten verursachen kann.