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

L'operatore stateful ad alta disponibilità (HA) consente di utilizzare per l'integrazione integrata con Persistent Disk per automatizzare e controllare la velocità Failover del 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 garantisce il collegamento sicuro del volume al nodo di failover.

Perché utilizzare l'operatore stateful HA

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. Durante la rete a livello di nodo o di zona gli errori, questa architettura consente il failover dei carichi di lavoro (tramite collegamento di forza) nello spazio di archiviazione su un altro nodo in una zona diversa.

L'operatore stateful ad alta disponibilità consente di effettuare 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: replica dei dati su più zone possono essere costosi per le applicazioni a velocità effettiva elevata. 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 disco permanente 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 il recupero dell'applicazione è molto basso obiettivo temporale (RTO), consigliamo di utilizzare un approccio a più repliche.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Attiva l'API Google Kubernetes Engine.
    • Abilita 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à assicurarti 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 la tua applicazione venga eseguita su forme di macchine dei Persistent Disk supportati a livello di regione: E2, N1, N2, N2D.
  • Assicurati che il driver CSI per il disco permanente di Compute Engine sia abilitato. Il driver CSI del disco permanente è abilitato per impostazione predefinita sui nuovi Autopilot e Standard e non può essere disabilitato o quando si usa 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 del disco permanente 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

Segui questi passaggi per configurare l'operatore stateful ad alta disponibilità per i carichi di lavoro stateful:

  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 abilita automaticamente il componente aggiuntivo StatefulHA durante la creazione del cluster. Se vuoi utilizzare Operatore stateful ad alta disponibilità per un carico di lavoro esistente, esegui nuovamente il deployment del carico di lavoro su un nuovo 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 gcloud CLI istruzioni per aggiornare le impostazioni di un cluster Standard e usare il flag seguente per abilitare 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 Alta disponibilità, consulta la documentazione di riferimento HighAvailabilityApplication.

Vedi l'esempio seguente 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 sia da StatefulSet.
    • APP_NAMESPACE: lo spazio dei nomi dell'applicazione. Questo spazio dei nomi deve essere condiviso da entrambe le istanze e StatefulSet.

    In questo esempio:

    • L'opzione HighAvailabilityApplication.spec.policy.storageSettings.requireRegionalSettings è impostata su true. Viene applicato lo spazio di archiviazione regionale.
    • Il valore di HighAvailabilityApplication.spec.policy.failoverSettings è impostato su AfterNodeUnreachable. Questo determina in che modo viene attivata l'eliminazione forzata in caso di guasto del nodo.
    • Il valore 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 uno StatefulSet con uno spazio dei nomi e un nome corrispondenti.

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

Installa un StatefulSet

Installare uno 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 disco permanente 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