Bonnes pratiques pour la haute disponibilité avec OpenShift

Ce document décrit les bonnes pratiques à adopter pour assurer la haute disponibilité (HA) des charges de travail Red Hat OpenShift Container Platform sur Compute Engine. Ce document se concentre sur les stratégies au niveau de l'application pour vous aider à garantir que vos charges de travail restent hautement disponibles en cas de défaillance. Ces stratégies vous aident à éliminer les points de défaillance uniques et à implémenter des mécanismes de basculement et de récupération automatiques.

Ce document s'adresse 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.

Répartir les déploiements dans plusieurs zones

Nous vous recommandons de déployer OpenShift dans plusieurs zones d'une régionGoogle Cloud . 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 zones Google Cloud de la même région dans votre fichier install-config.yaml.

Pour un contrôle précis des emplacements où les nœuds sont déployés, nous vous recommandons de définir des stratégies d'emplacement 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 de répartition aux nœuds de votre cluster permet de réduire le nombre de nœuds simultanément affectés par des perturbations spécifiques à un emplacement. Pour savoir comment créer une stratégie de répartition pour les clusters existants, consultez Créer et appliquer des stratégies d'emplacement par répartition aux VM.

De même, pour empêcher la planification de plusieurs pods 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 pods pour chaque service ou route. Cette approche garantit que le trafic est automatiquement acheminé vers les pods dans les zones disponibles.

Gérez la charge de manière proactive pour éviter le surdimensionnement des ressources.

Nous vous recommandons de gérer de manière proactive la charge de votre application pour éviter le surdimensionnement des ressources. Un engagement excessif peut entraîner de mauvaises performances du service sous charge. Pour éviter le surdimensionnement, vous pouvez définir des limites de demande de ressources. Pour en savoir plus, consultez Gérer les ressources de votre pod. De plus, vous pouvez automatiquement augmenter ou diminuer le nombre de répliques en fonction du processeur, de la mémoire ou de métriques personnalisées à l'aide de l'autoscaler de pods horizontal.

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

  • Opérateur d'entrée OpenShift. L'opérateur 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 mondial pour le contrôleur Ingress. Cela permet aux clients de n'importe quelle région du même réseau et de la même région VPC que l'équilibreur de charge d'accéder aux charges de travail exécutées sur votre cluster. Nous vous recommandons également d'implémenter des vérifications d'état du contrôleur d'entrée pour surveiller l'état de vos pods et redémarrer ceux qui échouent.
  • Google Cloud Équilibrage de charge. L'équilibrage de charge répartit le trafic entre les zonesGoogle Cloud . Choisissez un équilibreur de charge qui répond aux besoins de votre application.

Définir des budgets d'interruptions de pods

Nous vous recommandons de définir des budgets d'interruption pour spécifier le nombre minimal de pods dont votre application a besoin pour être disponible en cas d'interruption, comme des événements de maintenance ou des mises à jour. L'exemple suivant montre comment définir un budget de perturbation :

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 espace de stockage sur disque, utilisez l'une des options suivantes :

Après avoir 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 PersistentVolumeClaims (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 :

  • Base de données entièrement gérée : nous vous recommandons d'utiliser Cloud SQL ou AlloyDB pour PostgreSQL afin de gérer la haute disponibilité de la base de données à votre place. Si vous utilisez Cloud SQL, vous pouvez utiliser l'opérateur proxy Cloud SQL pour simplifier la gestion des connexions entre votre application et la base de données.
  • Base de données autogérée : nous vous recommandons d'utiliser une base de données compatible avec la haute disponibilité et de déployer son opérateur pour l'activer. Pour en savoir plus, consultez la documentation relative à votre opérateur de base de données, comme Redis Enterprise pour Kubernetes, MariaDB Operator ou CloudNative PostgreSQL Operator.

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é dans 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 renforcer la sécurité.
  • 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 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 HA.

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 dans plusieurs zones
  • Gérez la charge de manière proactive pour éviter le surdimensionnement des ressources.
  • Définir des budgets d'interruptions de pods
  • Utiliser les fonctionnalités de réplication des données à haute disponibilité
  • Externaliser l'état de l'application

Étapes suivantes