Bonnes pratiques pour la haute disponibilité

Ce document décrit les bonnes pratiques à suivre pour obtenir une haute disponibilité (HA) avec les charges de travail Red Hat OpenShift Container Platform sur Compute Engine. Il se concentre sur les stratégies au niveau de l'application pour vous aider à garantir que vos charges de travail restent disponibilité élevée en cas de défaillance. Ces stratégies vous aident à éliminer les points de défaillance uniques et à mettre en œuvre des mécanismes de basculement et de récupération automatiques.

Ce document est destiné aux architectes de plate-forme et d'application, et suppose que vous avez une certaine expérience du déploiement d'OpenShift. Pour en savoir plus sur le déploiement d'OpenShift, consultez la documentation Red Hat.

Ce document fait partie d'une série axée sur les stratégies au niveau de l'application qui garantissent que vos charges de travail restent disponibilité élevée et rapidement récupérables en cas de défaillance. Les documents de cette série sont les suivants :

Répartir les déploiements sur plusieurs zones

Nous vous recommandons de déployer OpenShift sur plusieurs zones d'une même Google Cloud région. Cette approche permet de s'assurer qu'en cas de panne dans une zone, les nœuds du plan de contrôle du cluster continuent de fonctionner dans les autres zones où le déploiement est réparti. Pour déployer OpenShift sur plusieurs zones, spécifiez une liste de Google Cloud zones de la même région dans votre install-config.yaml fichier.

Pour un contrôle précis des emplacements où les nœuds sont déployés, nous vous recommandons de définir des règles de placement de VM qui garantissent que les VM sont réparties sur différents domaines de défaillance dans la même zone. L'application d'une stratégie d'emplacement par répartition aux nœuds de votre cluster permet de réduire le nombre de nœuds qui sont simultanément affectés par des interruptions spécifiques à un emplacement. Pour en savoir plus sur la création d'une règle de répartition pour les clusters existants, consultez Créer et appliquer des règles de placement réparti aux VM.

De même, pour éviter que plusieurs pods ne soient planifiés sur le même nœud, nous vous recommandons d'utiliser des règles d'anti-affinité de pod. Ces règles répartissent les répliques d'application sur plusieurs zones. L'exemple suivant montre comment implémenter des règles d'anti-affinité de pod :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-app-namespace
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      # Pod Anti-Affinity: Prefer to schedule new pods on nodes in different zones.
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: my-app
            topologyKey: topology.kubernetes.io/zone
      containers:
      - name: my-app-container
        image: quay.io/myorg/my-app:latest
        ports:
        - containerPort: 8080

Pour les services sans état tels que les interfaces Web ou les API REST, nous vous recommandons d' exécuter plusieurs répliques de pod pour chaque service ou route. Cette approche garantit que le trafic est automatiquement acheminé vers les pods des zones disponibles.

Gérer la charge de manière proactive pour éviter le surprovisionnement des ressources

Nous vous recommandons de gérer de manière proactive la charge de votre application pour éviter le surprovisionnement des ressources. Le surprovisionnement peut entraîner de mauvaises performances du service sous charge. Vous pouvez éviter le surprovisionnement en définissant des limites de requêtes de ressources. Pour une explication plus détaillée, consultez Gérer les ressources de votre pod. De plus, vous pouvez automatiquement augmenter ou réduire le nombre de répliques en fonction du processeur, de la mémoire ou de métriques personnalisées à l'aide de l'autoscaler horizontal de pods.

Nous vous recommandons également d'utiliser les services d'équilibrage de charge suivants :

  • Opérateur d'entrée OpenShift. L'opérateur d'Ingress déploie des contrôleurs d'entrée basés sur HAProxy pour gérer le routage vers vos pods. Plus précisément, nous vous recommandons de configurer l'accès global pour le Ingressentrée, ce qui permet aux clients de n'importe quelle région du même réseau VPC et de la même région que l'équilibreur de charge d'atteindre les charges de travail exécutées sur votre cluster. De plus, nous vous recommandons d'implémenter des vérifications d'état du contrôleur d'entrée pour surveiller l'état de vos pods et redémarrer les pods défaillants.
  • Google Cloud Équilibrage de charge. L'équilibrage de charge répartit le trafic entre les Google Cloud zones. Choisissez un équilibreur de charge qui répond aux besoins de votre application.

Définir des budgets d'interruption de pods

Nous vous recommandons de définir des budgets d'interruption pour spécifier le nombre minimal de pods que votre application doit rendre disponibles lors d'interruptions telles que des événements de maintenance ou des mises à jour. L'exemple suivant montre comment définir un budget d'interruption :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
  namespace: my-app-namespace
spec:
  # Define how many pods need to remain available during a disruption.
  # At least one of "minAvailable" or "maxUnavailable" must be specified.
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

Pour en savoir plus, consultez la section Spécifier un budget d'interruption pour votre application.

Utiliser un stockage compatible avec la haute disponibilité et la réplication des données

Pour les charges de travail avec état qui nécessitent un stockage de données persistant en dehors des conteneurs, nous vous recommandons de suivre les bonnes pratiques ci-dessous.

Bonnes pratiques concernant les disques

Si vous avez besoin d'un stockage sur disque, utilisez l'une des options suivantes :

Une fois que vous avez sélectionné une option de stockage, installez son pilote dans votre cluster :

L'opérateur CSI Persistent Disk fournit une classe de stockage que vous pouvez utiliser pour créer des revendications de volume persistant (PVC). Pour Filestore, vous devez créer la classe de stockage Filestore.

Bonnes pratiques concernant les bases de données

Si vous avez besoin d'une base de données, utilisez l'une des options suivantes :

Après avoir installé votre opérateur de base de données, configurez un cluster avec plusieurs instances. L'exemple suivant montre la configuration d'un cluster avec les attributs suivants :

  • Un cluster PostgreSQL nommé my-postgres-cluster est créé avec trois instances pour la haute disponibilité.
  • Le cluster utilise la classe de stockage regionalpd-balanced pour un stockage durable et répliqué entre les zones.
  • Une base de données nommée mydatabase est initialisée avec un utilisateur myuser, dont les identifiants sont stockés dans un secret Kubernetes appelé my-database-secret.
  • L'accès superutilisateur est désactivé pour une sécurité renforcée.
  • La surveillance est activée pour le cluster.
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: my-postgres-cluster
  namespace: postgres-namespace
spec:
  instances: 3
  storage:
    size: 10Gi
    storageClass: regionalpd-balanced
  bootstrap:
    initdb:
      database: mydatabase
      owner: myuser
      secret:
        name: my-database-secret
  enableSuperuserAccess: false
  monitoring:
    enabled: true
---
apiVersion: 1
kind: Secret
metadata:
  name: my-database-secret
  namespace: postgres-namespace
type: Opaque
data:
  username: bXl1c2Vy # Base64-encoded value of "myuser"
  password: c2VjdXJlcGFzc3dvcmQ= # Base64-encoded value of "securepassword"

Externaliser l'état de l'application

Nous vous recommandons de déplacer l'état de la session ou la mise en cache vers des magasins en mémoire partagés (par exemple, Redis) ou des magasins de données persistants (par exemple, Postgres, MySQL) configurés pour s'exécuter en mode haute disponibilité.

Récapitulatif des bonnes pratiques

En résumé, implémentez les bonnes pratiques suivantes pour obtenir une haute disponibilité avec OpenShift :

  • Répartir les déploiements sur plusieurs zones
  • Gérer la charge de manière proactive pour éviter le surprovisionnement des ressources
  • Définir des budgets d'interruption de pods
  • Utiliser des fonctionnalités de réplication de données à haute disponibilité
  • Externaliser l'état de l'application

Étape suivante