Augmenter la disponibilité des applications avec état avec l'opérateur HA avec état

L'opérateur haute disponibilité avec état vous permet d'utiliser l'intégration de GKE au disque persistant régional pour automatiser et contrôler la vitesse de basculement des pods StatefulSet. Lors du basculement, l'opérateur gère automatiquement la détection des défaillances des nœuds, dissocie un volume d'un nœud défaillant et garantit l'association de ce volume au nœud de basculement.

Pourquoi utiliser l'opérateur haute disponibilité avec état

Une architecture avec état commune permettant d'atteindre une haute disponibilité utilise des disques persistants régionaux en tant que couche de stockage. Ces disques fournissent une réplication synchrone des données entre deux zones d'une même région. Lors des défaillances de nœud ou de réseau zonal, cette architecture permet à vos charges de travail de basculer (en forçant l'association) des instances dupliquées vers le stockage sur un autre nœud dans un zone différente.

L'opérateur HA avec état vous permet d'effectuer les optimisations suivantes :

  • Améliorez le temps de récupération des applications à instance dupliquée unique : si vous n'utilisez qu'une seule instance dupliquée, vous pouvez utiliser l'opérateur HA avec état et remplacer le stockage zonal par un stockage régional lors du provisionnement de votre application, pour augmenter la durabilité et la disponibilité des données en cas de défaillance d'un nœud.
  • Réduire les coûts de mise en réseau interzone : la réplication de données sur plusieurs zones peut s'avérer coûteuse pour les applications à haut débit. Vous pouvez utiliser l'opérateur haute disponibilité avec état pour exécuter votre application dans une seule zone, tout en conservant un chemin de basculement vers une autre zone, conforme au contrat de niveau de service de votre application.

Limites

Avec une architecture d'opérateur haute disponibilité avec état à instance unique, GKE conserve vos données dans deux zones via un disque disque persistant régional, mais les données ne sont accessibles que lorsque l'instance répliquée de votre application est opérationnelle. Lors d'un basculement, votre application est temporairement indisponible pendant que votre instance dupliquée est reprogrammée vers un nouveau nœud opérationnel. Si votre application a un objectif de temps de récupération (RTO, Recovery Time Objective) très faible, nous vous recommandons d'utiliser une approche multi-instance répliquée.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

Conditions requises

  • Le plan de contrôle et les nœuds de votre cluster doivent exécuter GKE version 1.28 ou ultérieure.
  • Lorsque vous utilisez un opérateur HA avec état, il configure automatiquement votre StatefulSet associé pour utiliser des disques persistants régionaux. Cependant, vous devez vous assurer que les pods sont configurés pour utiliser ces disques et qu'ils sont capables de s'exécuter dans toutes les zones associées au stockage sous-jacent.
  • Assurez-vous que votre application s'exécute sur des formes de machines compatibles avec les disques persistants régionaux : E2, N1, N2, N2D.
  • Assurez-vous que le pilote CSI de disque persistant Compute Engine est activé. Le pilote CSI de disque persistant est activé par défaut sur les nouveaux clusters Autopilot et Standard et ne peut pas être désactivé ou modifié avec l'utilisation d'Autopilot. Si vous devez ajouter manuellement le pilote CSI de disque persistant à partir de votre cluster, consultez la section Activer le pilote CSI de disque persistant sur un cluster existant.
  • Si vous utilisez une ressource StorageClass personnalisée, configurez le pilote CSI de disque persistant avec l'approvisionneur pd.csi.storage.gke.io et les paramètres suivants :
    • availability-class: regional-hard-failover
    • replication-type: regional-pd

Configurer et utiliser l'opérateur HA avec état

Pour configurer l'opérateur HA avec état pour vos charges de travail avec état, procédez comme suit :

  1. Activez le module complémentaire StatefulHA.
  2. Installez une ressource HighAvailabilityApplication.
  3. Installez un StatefulSet
  4. Inspectez la ressource HighAvailabilityApplication.

Activez le module complémentaire StatefulHA.

Pour utiliser l'opérateur haute disponibilité avec état, le module complémentaire StatefulHA doit être activé sur votre cluster.

  • Clusters Autopilot : GKE active automatiquement le module complémentaire StatefulHA lors de la création du cluster. Si vous souhaitez utiliser l'opérateur haute disponibilité avec état pour une charge de travail existante, redéployez votre charge de travail sur un nouveau cluster Autopilot.

  • Clusters Standard :

GKE installe automatiquement une ressource StorageClass nommée standard-rwo-regional lorsque le module complémentaire est activé.

Installer une ressource HighAvailabilityApplication

HighAvailabilityApplication est une ressource Kubernetes qui simplifie les paramètres StatefulSet et augmente la disponibilité des pods sur GKE. L'opérateur haute disponibilité avec état rapproche les ressources HighAvailabilityApplication sur GKE.

Dans la spécification HighAvailabilityApplication, vous devez définir HighAvailabilityApplication.spec.resourceSelection.resourceKind sur StatefulSet.

Pour savoir comment configurer la ressource HighAvailability, consultez la documentation de référence sur HighAvailabilityApplication.

Consultez l'exemple suivant pour PostgreSQL :

  1. Enregistrez le fichier manifeste suivant dans un fichier nommé 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

    Remplacez les éléments suivants :

    • APP_NAME : nom d'une application de votre cluster que vous souhaitez protéger. Ce nom doit être partagé à la fois par l'application HighAvailabilityApplication et par l'objet StatefulSet.
    • APP_NAMESPACE : espace de noms de l'application. Cet espace de noms doit être partagé à la fois par l'application HighAvailabilityApplication et par l'objet StatefulSet protégé.

    Dans cet exemple :

    • La propriété HighAvailabilityApplication.spec.policy.storageSettings.requireRegionalSettings est définie sur true. Cela applique un stockage régional.
    • La propriété HighAvailabilityApplication.spec.policy.failoverSettings est définie sur AfterNodeUnreachable. Cela détermine le mode de déclenchement de la suppression forcée en cas de défaillance du nœud.
    • La propriété HighAvailabilityApplication.spec.policy.failoverSettings.afterNodeUnreachable est définie sur 20. Il s'agit du délai avant expiration permettant de forcer la suppression d'un pod une fois que le nœud dans lequel il s'exécute est marqué comme inaccessible.

  2. Créez la ressource. La ressource HighAvailabilityApplication identifie un objet StatefulSet avec un espace de noms et un nom correspondants.

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

Installer un StatefulSet

Installez un StatefulSet. Par exemple, vous pouvez installer un StatefulSet PostgreSQL à l'aide de Helm (Cloud Shell est préinstallé avec Helm) :

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

La ressource HighAvailabilityApplication modifie automatiquement la StorageClass de l'objet StatefulSet en standard-rwo-regional, qui utilise un disque persistant régional.

Inspecter la ressource HighAvailabilityApplication

Exécutez la commande suivante pour vérifier que le basculement automatique est activé dans l'exemple d'application :

kubectl describe highavailabilityapplication APP_NAME

Le résultat doit se présenter comme suit :

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