Kubernetes – HA-verteiltes Setup über 3 Bürostandorte

Kubernetes – HA-verteiltes Setup über 3 Bürostandorte

Ich möchte mein internes, vor Ort gestapeltes HA Kubernetes mit 3 Kontrollebenen und 3 Worker-Nodes-Clustern an 3 Bürostandorten erweitern. Jede Kontrollebene und 1 Worker wären also in jedem der Büros. Jede Kontrollebene hätte ihre eigene statische IP.

Ich verstehe nicht, wie der Lastenausgleich (ich verwende Metallb) seine Aufgabe erfüllen soll, wenn beispielsweise in Büro 1 der Strom ausfällt. Wie wird der Verkehr zu Büro 2 und 3 umgeleitet?

Beispielsweise verwenden externe, öffentliche Benutzer, die auf Nextcloud zugreifen, das auf Office-1-Node läuft, möglicherweise einen FQDN cloud.company.com, der mit der statischen IP von Office-1-Node verknüpft ist. (Nextcloud läuft jedoch möglicherweise auf einem Worker oder Master in Office-2-Node oder Office-3-Node … was die Benutzer betrifft, stellt dies jedoch kein Problem dar.)

Wenn es bei Office-1-Knoten zu einem Stromausfall kommt, was würde cloud.company.com an die statische IP von Office-2-Knoten oder Office-3-Knoten weiterleiten?

Ich bin immer noch in der Lernphase, also berücksichtigen Sie das bitte bei Ihrer Antwort.

Antwort1

Ich konnte sehen, dass Metal LB eingesetzt wird (https://metallb.universe.tf/installation/) als Controller (der die IP-Zuweisung übernimmt) und Daemonset (Komponente - Lautsprecher -> Dies ist meiner Meinung nach die Handhabung externer Ankündigungen gemäßhttps://metallb.universe.tf/concepts/). Dieser LB wird also grundsätzlich als Kubernetes-Ressource bereitgestellt.

Kommen wir nun zu Ihrer Frage: Wenn es bei Office-1-Knoten zu einem Ausfall kommt, funktionieren die Pods im Daemonset von anderen Knoten wie erforderlich (machen externe Ankündigungen und machen die Dienste erreichbar) und der Controller von Ihren anderen Masterknoten übernimmt weiterhin die IP-Zuweisungen.

Ressourcen:

  1. Kubernetes Controllerhttps://kubernetes.io/docs/concepts/architecture/controller/
  2. Kubernetes Daemonsethttps://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
  3. Kubernetes Metallb-Manifest -https://github.com/metallb/metallb/blob/main/manifests/metallb.yaml

Bearbeiten: Beantwortung der Frage im zweiten Kommentar. Zuerst müssen Sie einen Domänennamen kaufen (von GoDaddy, BigRock, AWS Route53 usw.). Erstellen Sie dann einen CNAME, um diesen Domänennamen auf die IP Ihres Load Balancers zu verweisen (optional mit Port) (in Ihrem Fall können die IPs von Office-1,2,3 im Round-Robin-Verfahren verwendet werden, um die Verfügbarkeit sicherzustellen). Dieses Round-Robin-Verfahren wird genanntDNS-LastausgleichOder Sie können implementierenDNS-Failoverwie in AWS Route53, indem Sie Integritätsprüfungen in Ihrem Load Balancer implementieren. Sobald dies erledigt ist, hat der externe Benutzer weiterhin Zugriff auf Dienste in Kubernetes (von Office-2 und 3).

verwandte Informationen