Verfügbarkeit zustandsorientierter Anwendungen mit zustandsorientiertem HA-Operator erhöhen

Mit dem zustandsorientierten Operator für Hochverfügbarkeit (Stateful High Availability, HA) können Sie das in GKE integrierte regionale Persistent Disk verwenden, um die Geschwindigkeit von StatefulSet Pod-Failover zu automatisieren und zu steuern. Während des Failovers übernimmt der Operator automatisch die Erkennung von Knotenausfällen, das Trennen eines Volumes von einem ausgefallenen Knoten und das sichere Anhängen von Volumes an den Failover-Knoten.

Vorteile des zustandsorientierten Operators für Hochverfügbarkeit

Eine gängige zustandsorientierte Architektur zum Erreichen von Hochverfügbarkeit verwendet regionales Persistent Disk als Speicherebene. Diese Laufwerke ermöglichen die synchrone Replikation von Daten zwischen zwei Zonen in einer Region. Bei Knoten- oder zonalen Netzwerkausfällen ermöglicht diese Architektur für Ihre Arbeitslasten ein Failover (durch erzwungenes Anhängen) in den Speicher auf einem anderen Knoten in einer anderen Zone.

Mit dem zustandsorientierten Operator für Hochverfügbarkeit können Sie folgende Optimierungen vornehmen:

  • Wiederherstellungszeit von Anwendungen mit einem einzelnen Replikat verbessern: Wenn Sie nur ein Replikat verwenden, können Sie den zustandsorientierten Operator für Hochverfügbarkeit verwenden und zonalen Speicher gegen regionalen Speicher austauschen, wenn Ihre Anwendung bereitgestellt wird, um Erhöhen der Langlebigkeit und Verfügbarkeit von Daten im Falle eines Knotenausfalls.
  • Zonenübergreifende Netzwerkkosten reduzieren: Die Replikation von Daten über mehrere Zonen kann bei Anwendungen mit hohem Durchsatz kostspielig sein. Mit dem zustandsorientierten Operator für Hochverfügbarkeit können Sie Ihre Anwendung in einer einzelnen Zone ausführen. Gleichzeitig muss ein Failover-Pfad zu einer anderen Zone beibehalten werden, die dem SLA Ihrer Anwendung entspricht.

Beschränkungen

Mit einer Architektur für zustandsorientierte Operatoren für Hochverfügbarkeit speichert GKE Ihre Daten mit einem einzelnen Replikat über regionales Persistent Disk in zwei Zonen. Die Daten sind jedoch nur zugänglich, wenn Ihr Anwendungsreplikat fehlerfrei ist. Während eines Failovers ist Ihre Anwendung vorübergehend nicht verfügbar, während das Replikat auf einen neuen fehlerfreien Knoten neu geplant wird. Wenn Ihre Anwendung ein sehr niedriges Recovery Time Objective (RTO) hat, empfehlen wir die Verwendung eines Ansatzes mit mehreren Replikaten.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

Voraussetzungen

  • Auf der Steuerungsebene und den Knoten Ihres Clusters muss die GKE-Version 1.28 oder höher ausgeführt werden.
  • Wenn Sie einen zustandsorientierten Operator für Hochverfügbarkeit verwenden, wird das verknüpfte StatefulSet automatisch für die Verwendung regionaler nichtflüchtiger Persistent Disks konfiguriert. Sie müssen jedoch dafür sorgen, dass die Pods für die Verwendung dieser Laufwerke konfiguriert sind und in allen Zonen ausgeführt werden können, die dem zugrunde liegenden Speicher zugeordnet sind.
  • Achten Sie darauf, dass Ihre Anwendung auf Maschinenformen ausgeführt wird, die von regionalem Persistent Disk unterstützt werden: E2, N1, N2, N2D.
  • Achten Sie darauf, dass der CSI-Treiber für Persistent Disk von Compute Engine aktiviert ist. Der CSI-Treiber für Persistent Disk ist in neuen Autopilot- und Standardclustern standardmäßig aktiviert und kann bei Verwendung von Autopilot nicht deaktiviert oder bearbeitet werden. Wenn Sie den CSI-Treiber für Persistent Disk aus Ihrem Cluster manuell hinzufügen müssen, finden Sie weitere Informationen unter CSI-Treiber für Persistent Disk auf einem vorhandenen Cluster aktivieren.
  • Wenn Sie eine benutzerdefinierte StorageClass verwenden, konfigurieren Sie den CSI-Treiber für Persistent Disk mit dem Bereitsteller pd.csi.storage.gke.io und diesen Parametern:
    • availability-class: regional-hard-failover
    • replication-type: regional-pd

Zustandsorientierte Operator für Hochverfügbarkeit einrichten und verwenden

So richten Sie den zustandsorientierten Operator für Hochverfügbarkeit für Ihre zustandsorientierten Arbeitslasten ein:

  1. Aktivieren Sie das Add-on StatefulHA.
  2. Installieren Sie eine HighAvailabilityApplication-Ressource.
  3. Installieren Sie StatefulSet.
  4. Prüfen Sie die HighAvailabilityApplication-Ressource.

StatefulHA-Add-on aktivieren

Damit Sie den zustandsorientierten Operator für Hochverfügbarkeit verwenden können, muss das Add-on StatefulHA in Ihrem Cluster aktiviert sein.

  • Autopilot-Cluster: GKE aktiviert das Add-on StatefulHA beim Erstellen des Clusters automatisch. Wenn Sie den zustandsorientierten Operator für Hochverfügbarkeit für eine vorhandene Arbeitslast verwenden möchten, stellen Sie Ihre Arbeitslast in einem neuen Autopilot-Cluster noch einmal bereit.

  • Standardcluster:

GKE installiert automatisch eine StorageClass mit dem Namen standard-rwo-regional, wenn das Add-on aktiviert ist.

HighAvailabilityApplication-Ressource installieren

HighAvailabilityApplication ist eine Kubernetes-Ressource, die die StatefulSet-Einstellungen vereinfacht und die Pod-Verfügbarkeit in GKE erhöht. Zustandsorientierter Operator für Hochverfügbarkeit gleicht HighAvailabilityApplication-Ressourcen in GKE ab.

In der Spezifikation HighAvailabilityApplication müssen Sie für HighAvailabilityApplication.spec.resourceSelection.resourceKind den Wert StatefulSet festlegen.

Informationen zum Konfigurieren der HighAvailability-Ressource finden Sie in der Referenzdokumentation zu HighAvailabilityApplication.

Sehen Sie sich das folgende Beispiel für PostgreSQL an:

  1. Speichern Sie folgendes Manifest in einer Datei mit dem Namen stateful-ha-example-resource.yaml:

    kind: HighAvailabilityApplication
apiVersion: ha.gke.io/v1
metadata:
  name: APP_NAME
  namespace: APP_NAMESPACE
spec:
  resourceSelection:
    resourceKind: StatefulSet
  policy:
    storageSettings:
      requireRegionalStorage: true
    failoverSettings:
      forceDeleteStrategy: AfterNodeUnreachable
      afterNodeUnreachable:
        afterNodeUnreachableSeconds: 20

    Ersetzen Sie Folgendes:

    • APP_NAME ist der Name einer Anwendung in Ihrem Cluster, die Sie schützen möchten. Dieser Name muss sowohl von HighAvailabilityApplication als auch von StatefulSet freigegeben werden.
    • APP_NAMESPACE ist der Namespace der Anwendung. Dieser Namespace muss sowohl von der HighAvailabilityApplication als auch vom StatefulSet freigegeben werden, das geschützt wird.

    In diesem Fall gilt Folgendes:

    • HighAvailabilityApplication.spec.policy.storageSettings.requireRegionalSettings ist auf true gesetzt. Dadurch wird Regional Storage erzwungen.
    • HighAvailabilityApplication.spec.policy.failoverSettings ist auf AfterNodeUnreachable gesetzt. Dies bestimmt, wie ein erzwungenes Löschen bei einem Knotenfehler ausgelöst wird.
    • HighAvailabilityApplication.spec.policy.failoverSettings.afterNodeUnreachable ist auf 20 gesetzt. Dies ist das Zeitlimit, mit dem das Löschen eines Pods erzwungen wird, nachdem der Knoten, auf dem er ausgeführt wird, als nicht erreichbar markiert wird.

  2. Erstellen Sie die Ressource. Die HighAvailabilityApplication-Ressource identifiziert ein StatefulSet mit einem übereinstimmenden Namespace und Namen.

    kubectl apply -f stateful-ha-example-resource.yaml

StatefulSet installieren

Installieren Sie StatefulSet. Sie können beispielsweise ein PostgreSQL-StatefulSet mit Helm installieren (Helm ist in Cloud Shell vorinstalliert):

helm install postgresql oci://registry-1.docker.io/bitnamicharts/postgresql \
  --namespace=APP_NAMESPACE \
  --set fullnameOverride=APP_NAME

Die Ressource HighAvailabilityApplication ändert die StorageClass des StatefulSets automatisch in standard-rwo-regional, die regionales Persistent Disk verwendet.

HighAvailabilityApplication-Ressource überprüfen

Führen Sie den folgenden Befehl aus, um zu prüfen, ob für die Beispielanwendung das automatische Failover aktiviert ist:

kubectl describe highavailabilityapplication APP_NAME

Die Ausgabe sollte in etwa so aussehen:

Status:
Conditions:
  Last Transition Time:  2023-08-09T23:59:52Z
  Message:               Application is protected
  Observed Generation:   1
  Reason:                ApplicationProtected
  Status:                True
  Type:                  Protected