Aumenta la disponibilità delle app stateful con l'operatore HA stateful

L'operatore ad alta disponibilità (HA) stateful ti consente di utilizzare l'integrazione integrata di GKE con i dischi permanenti regionali per automatizzare e controllare la velocità del failover dei pod StatefulSet. Durante il failover, l'operatore gestisce automaticamente il rilevamento del guasto del nodo, lo scollegamento di un volume da un nodo in cui si è verificato un guasto e l'attacco sicuro del volume al nodo di failover.

Perché utilizzare l'operatore HA stateful

Un'architettura stateful comune per ottenere un'alta disponibilità utilizza i dischi permanenti regionali come livello di archiviazione. Questi dischi forniscono la replica sincrona dei dati tra due zone in una regione. In caso di guasti della rete del nodo o della zona, questa architettura consente ai carichi di lavoro di eseguire il failover (mediante aggancio forzato) delle repliche allo spazio di archiviazione su un altro nodo in una zona diversa.

L'operatore HA stateful ti consente di eseguire le seguenti ottimizzazioni:

  • Migliora il tempo di recupero delle applicazioni con una sola replica: se utilizzi solo una replica, puoi utilizzare Operatore HA stateful e sostituire lo spazio di archiviazione zonale con quello regionale quando viene eseguito il provisioning dell'applicazione, per aumentare la durata e la disponibilità dei dati in caso di guasto di un nodo.
  • Riduci i costi di networking tra zone: la replica dei dati in più zone può essere costosa per le applicazioni con un elevato throughput. Puoi utilizzare Operatore HA stateful per eseguire l'applicazione in un'unica zona, mantenendo al contempo un percorso di failover a una zona alternativa adatta allo SLA della tua applicazione.

Limitazioni

Con un'architettura dell'operatore HA stateful a replica singola, GKE mantiene i dati in due zone tramite il Persistent Disk regionale, ma i dati sono accessibili solo quando la replica dell'applicazione è attiva. Durante un failover, la tua applicazione non sarà temporaneamente disponibile mentre la replica viene riprogrammata su un nuovo nodo integro. Se la tua applicazione ha un obiettivo di tempo di recupero molto basso, ti consigliamo di utilizzare un approccio con più repliche.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  • Attiva l'API Google Kubernetes Engine.
    • Attiva l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.

Requisiti

  • Il piano di controllo e i nodi del cluster devono eseguire GKE versione 1.28 o successive.
  • Quando utilizzi l'operatore HA stateful, questo configura automaticamente il StatefulSet collegato in modo che utilizzi i dischi permanenti a livello di regione. Tuttavia, è tua responsabilità garantire che i pod siano configurati per utilizzare questi dischi e siano in grado di funzionare in tutte le zone associate allo spazio di archiviazione sottostante.
  • Assicurati che l'applicazione venga eseguita su forme di macchine supportate da Persistent Disk regionale: E2, N1, N2, N2D.
  • Assicurati che il driver CSI per il disco permanente di Compute Engine sia abilitato. Il driver CSI per il disco permanente è abilitato per impostazione predefinita nei nuovi cluster Autopilot e standard e non può essere disabilitato o modificato quando si utilizza Autopilot. Se devi aggiungere manualmente il driver CSI disco permanente dal tuo cluster, consulta Attivare il driver CSI disco permanente su un cluster esistente.
  • Se utilizzi un oggetto StorageClass personalizzato, configura il driver CSI Persistent Disk con il provisioning pd.csi.storage.gke.io e questi parametri:
    • availability-class: regional-hard-failover
    • replication-type: regional-pd

Configurare e utilizzare l'operatore HA stateful

Per configurare Stateful HA Operator per i tuoi carichi di lavoro con stato:

  1. Attiva il componente aggiuntivo StatefulHA.
  2. Installa una risorsa HighAvailabilityApplication.
  3. Installa un StatefulSet.
  4. Esamina la risorsa HighAvailabilityApplication.

Attiva il componente aggiuntivo StatefulHA

Per utilizzare l'operatore HA stateful, il componente aggiuntivo StatefulHA deve essere attivato nel tuo cluster.

  • Cluster Autopilot: GKE attiva automaticamente il plug-in StatefulHA al momento della creazione del cluster. Se vuoi utilizzare Operatore HA stateful per un carico di lavoro esistente, esegui nuovamente il deployment del carico di lavoro su un nuovo cluster Autopilot.

  • Cluster standard:

    • Creazione di un nuovo cluster: segui le istruzioni dell'interfaccia a riga di comando gcloud per creare un cluster standard e aggiungi il seguente flag: --add-on=StatefulHA.
    • Cluster standard esistente: segui le istruzioni dell'interfaccia a riga della gcloud CLI per aggiornare le impostazioni di un cluster standard e utilizza il seguente flag per attivare il componente aggiuntivo: --update-addons=StatefulHA=ENABLED.

GKE installa automaticamente un StorageClass denominato standard-rwo-regional quando il componente aggiuntivo è attivato.

Installa una risorsa HighAvailabilityApplication

HighAvailabilityApplication è una risorsa Kubernetes che semplifica le impostazioni di StatefulSet e aumenta la disponibilità dei pod su GKE. L'operatore HA stateful riconcilia le risorse HighAvailabilityApplication su GKE.

Nella specifica HighAvailabilityApplication, devi impostare HighAvailabilityApplication.spec.resourceSelection.resourceKind su StatefulSet.

Per scoprire come configurare la risorsa HighAvailability, consulta la HighAvailabilityApplication documentazione di riferimento.

Guarda il seguente esempio per PostgreSQL:

  1. Salva il seguente manifest in un file denominato 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

    Sostituisci quanto segue:

    • APP_NAME: il nome di un'applicazione nel cluster che vuoi proteggere. Questo nome deve essere condiviso sia da HighAvailabilityApplication che da StatefulSet.
    • APP_NAMESPACE: lo spazio dei nomi dell'applicazione. Questo spazio dei nomi deve essere condiviso sia dall'HighAvailabilityApplication sia dal StatefulSet protetti.

    In questo esempio:

    • L'opzione HighAvailabilityApplication.spec.policy.storageSettings.requireRegionalSettings è impostata su true. In questo modo viene applicato lo spazio di archiviazione regionale.
    • L'opzione HighAvailabilityApplication.spec.policy.failoverSettings è impostata su AfterNodeUnreachable. Questo determina in che modo viene attivata l'eliminazione forzata in caso di guasto del nodo.
    • HighAvailabilityApplication.spec.policy.failoverSettings.afterNodeUnreachable è impostato su 20. Questo è il timeout per l'eliminazione forzata di un pod dopo che il nodo in cui è in esecuzione è stato contrassegnato come non raggiungibile.

  2. Crea la risorsa. La risorsa HighAvailabilityApplication identifica un StatefulSet con uno spazio dei nomi e un nome corrispondenti.

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

Installa un StatefulSet

Installa un StatefulSet. Ad esempio, puoi installare un StatefulSet PostgreSQL utilizzando Helm (Helm è preinstallato con Cloud Shell):

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

La risorsa HighAvailabilityApplication modifica automaticamente StorageClass del StatefulSet in standard-rwo-regional, che utilizza il Persistent Disk regionale.

Controlla la risorsa HighAvailabilityApplication

Esegui il comando seguente per verificare che per l'applicazione di esempio sia stato attivato il failover automatico:

kubectl describe highavailabilityapplication APP_NAME

L'output dovrebbe essere simile al seguente:

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