Config Controller für Hochverfügbarkeit konfigurieren

Auf dieser Seite wird gezeigt, wie Sie Config Controller am besten verwenden, wenn Sie hochverfügbare Dienste ausführen oder Ressourcen in mehreren Google Cloud-Regionen verwalten.

Diese Seite richtet sich an Administratoren, Architekten und Operatoren, die den Lebenszyklus der zugrunde liegenden Technologieinfrastruktur verwalten und Kapazitäts- und Infrastrukturanforderungen planen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

Config Controller wird in einer einzelnen Region ausgeführt, sodass er den Ausfall einer Verfügbarkeitszone tolerieren kann. Wenn jedoch eine gesamte Region ausfällt, verliert Config Controller die Verfügbarkeit. Es gibt zwei verschiedene Strategien für den Umgang mit regionalen Ausfällen. Ihre Auswahl hängt davon ab, was Sie tun würden, wenn eine Region ausfällt:

Fehlerszenarien verstehen

Config Controller verwendet einen regionalen GKE-Cluster. Obwohl der regionale Cluster den Ausfall einer einzelnen Zone in einer Region tolerieren kann, ist der Cluster nicht mehr verfügbar, wenn mehrere Zonen in der Region ausfallen.

Wenn Ihre Config Controller-Instanz ausfällt, bleiben Ihre vorhandenen Google Cloud-Ressourcen in ihrem aktuellen Zustand. Selbst wenn Ihre Anwendungen jedoch noch ausgeführt werden, können Sie ihre Konfiguration nicht ändern, wenn Config Controller nicht verfügbar ist. Dies gilt für Ressourcen in derselben Region und für Ressourcen in anderen Regionen, die Sie über den Config Controller in der nicht verfügbaren Region verwalten.

Da Sie Ressourcen in derselben Region nicht neu konfigurieren können, können Sie diese Ressourcen nicht reparieren, wenn ein regionaler Ausfall Auswirkungen auf Google Cloud-Ressourcen in der Config Controller-Region hat.

Da Sie auch Ressourcen in anderen Regionen nicht neu konfigurieren können, betrifft ein Ausfall in einer Region jetzt Ihre Möglichkeit, Änderungen in einer anderen Region vorzunehmen.

Andere Fehlerszenarien sind auch möglich. Wenn Sie beispielsweise Config Sync für das Abrufen von einem externen Git-Anbieter konfigurieren, sollten Sie die Fehlermodi dieses Git-Anbieters berücksichtigen. Sie können möglicherweise keine Konfigurationsänderungen vornehmen, da Sie keine Änderungen an diesen Git-Anbieter übertragen können. Oder wenn Config Sync nicht aus Git lesen kann, werden Git-Änderungen nicht auf den Cluster angewendet. Daher werden sie von Config Connector nicht angewendet. Regionale Ausfälle sind jedoch häufig das wichtigste Fehlerszenario, da andere Fehlerszenarien in der Regel nicht mit dem Config Controller-Fehler zusammenhängen.

Einzelnen Cluster für regionale Verfügbarkeit verwenden

In vielen Szenarien müssen Sie keine Neukonfiguration vornehmen, wenn eine Region ausfällt. In diesem Fall müssen Sie wohl akzeptieren, dass ein regionaler Ausfall dazu führt, dass Ihre Konfigurationssteuerungsebene nicht mehr verfügbar ist.

Wenn Sie beispielsweise nur in einer einzelnen Region arbeiten, gibt es keine nützliche Neukonfiguration, wenn diese Region ausfällt. Wenn Sie eine Single-Point-of-Failure-Datenbank in einer einzelnen Region haben, können Sie diese erst dann wiederherstellen, wenn die Region wiederhergestellt ist. Bei Anwendungen, die nicht die absolut höchste Verfügbarkeit benötigen, kann dies ein angemessener Kompromiss in Bezug auf Kosten und Komplexität sein.

Wenn Sie die Config Controller-Instanz in derselben Region einrichten, haben Sie eine Art Schicksalsgemeinschaft: Config Controller ist verfügbar, solange die primäre Region verfügbar ist. Es kann auch eine gute Wahl sein, die Config Controller-Instanz in einer anderen Region einzurichten. Auch wenn Sie jetzt potenzielle Fehler in zwei Regionen berücksichtigen müssen, vermeiden Sie einen korrelierten Ausfall der primären Region und der Konfigurationssteuerungsebene.

Alternativ wäre eine multiregionale redundante Konfiguration, wodurch Ihr System automatisch von ausgefallenen Regionen ferngehalten würde. Hier müssen Sie auch keine Neukonfiguration vornehmen, wenn eine Region ausfällt. In diesem Fall können Sie eine einzelne Config Controller-Instanz auswählen.

Manueller Failover auf eine zweite Config Controller-Instanz

Wenn eine Region ausfällt, können Sie eine Neukonfiguration vornehmen, um den Fehler zu beheben. Möglicherweise möchten Sie auch die Konfiguration der Ressourcen in anderen Regionen fortsetzen, auch wenn sich die Config Controller-Instanz in einer fehlerhaften Region befindet. In diesem Fall empfehlen wir die Verwendung einer zweiten Config Controller-Instanz in einer zweiten Region.

Obwohl es nicht empfohlen wird, können zwei Config Controller-Instanzen mit identischen Konfigurationen ausgeführt werden. Beide Instanzen werden mit Schreibzugriff auf dasselbe Git-Repository ausgeführt und wenden dieselben Änderungen auf Google Cloud an. Aufgrund vieler Grenzfälle ist diese Konfiguration jedoch unzuverlässig. Die beiden Config Controller-Instanzen beobachten das Git-Repository zu leicht unterschiedlichen Zeiten und versuchen möglicherweise, etwas unterschiedliche Versionen Ihrer Google Cloud-Konfiguration anzuwenden. Mehrere aktive Autoren in Google Cloud erhöhen die Wahrscheinlichkeit, dass Kontingent- oder Ratenbegrenzungen erreicht werden. Eine geringe Anzahl von Config Connector-Ressourcen ist ebenfalls nicht idempotent und erfordert zusätzliche Sorgfalt, wie im weiteren Verlauf dieses Abschnitts erläutert. Daher wird davon abgeraten zwei Config Controller-Cluster zu verwenden, die sich aktiv abgleichen.

Stattdessen empfehlen wir, einen anderen Config Controller in einer zweiten Region auszuführen, wenn die Region ausfällt, in dem der Config Controller ausgeführt wird. Die neue Config Controller-Instanz sollte identisch mit der ersten konfiguriert sein und aus demselben Git-Repository lesen. In diesem Szenario kann nützlich sein, ein Skript zum Einrichten und Konfigurieren der Config Controller-Instanz vorzubereiten. Wenn Sie die neue Config Controller-Instanz erstellen, liest Config Sync den gewünschten Status von Git und wendet ihn auf Kubernetes an. Config Connector synchronisiert den gewünschten Status mit Google Cloud.

In dieser Situation sind zwei Dinge zu beachten:

  • Wenn der erste Config Controller-Cluster noch ausgeführt wird oder beim Wiederherstellen der ersten Region ausgeführt wird, kann es sein, dass er versucht, wieder den alten Status auf Google Cloud anzuwenden. Wenn Sie den Config Controller-Cluster in der ersten Region beenden können, bevor Sie einen zweiten Config Controller-Cluster starten, können Sie diesen potenziellen Konflikt vermeiden.

  • Nicht alle Config Connector-Ressourcen können nahtlos von Git noch einmal angewendet werden. Eine Liste der Ressourcen, die besondere Aufmerksamkeit erfordern, finden Sie unter Ressourcen mit Einschränkungen in Bezug auf die Übernahme. Insbesondere sollten Sie bei Folder-Ressourcen vorsichtig sein und IAMServiceAccountKey-Ressourcen vermeiden (z. B. mit GKE Workload Identity Federation for GKE).

Eine Config Controller-Instanz pro Region

Wenn Sie vermeiden möchten, dass eine Config Controller-Instanz in einer Region Auswirkungen auf eine andere Region hat, können Sie eine Config Controller-Instanz pro Region ausführen, wobei jede Config Controller-Instanz Ressourcen in dieser Region verwaltet.

Diese Konfiguration ist zwar möglich, wird aber aus folgenden Gründen nicht empfohlen:

  • Einige Ressourcen erstrecken sich über mehrere Regionen, z. B. Cloud DNS, wodurch diese Strategie eingeschränkt wird.

  • Im Allgemeinen verursacht ein Config Controller-Cluster in derselben Region das Problem eines korrelierten Ausfalls: Sie möchten Ressourcen neu konfigurieren, wenn sich ein regionaler Ausfall auf den Config Controller in dieser Region auswirkt.

  • Sie müssen Ihre Config Connector-Ressourcen nach Regionen aufteilen.

  • Config Controller ist derzeit nicht in allen Regionen verfügbar.

Google Cloud-Ressourcen direkt konfigurieren

Unter außergewöhnlichen Umständen können Sie Änderungen direkt an den zugrunde liegenden Google Cloud-Ressourcen vornehmen, ohne Git oder Config Connector zu nutzen. Config Connector versucht, Abweichungen zu beheben. Wenn Ihre Config Controller-Instanz noch ausgeführt wird, betrachtet Config Connector alle Änderungen, die Sie manuell vornehmen, als Abweichung und versucht, sie rückgängig zu machen.

Wenn Sie jedoch Ihre Config Controller-Instanz anhalten oder die Region offline ist, kann dies dennoch eine sinnvolle Behelfsmaßnahme sein.

Wenn die Config Controller-Instanz wiederhergestellt ist, versucht Config Connector wahrscheinlich, Ihre manuellen Änderungen rückgängig zu machen. Um diese Situation zu vermeiden, nehmen Sie alle manuell vorgenommenen Änderungen auch in Git vor.