Bonnes pratiques pour la haute disponibilité avec OpenShift

Ce document décrit les bonnes pratiques à suivre pour assurer la haute disponibilité (HA) avec les 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 à vous assurer 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'applications. Il 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 sur plusieurs zones

Nous vous recommandons de déployer OpenShift sur plusieurs zones d'une même 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 sur lesquelles le déploiement est réparti. Pour déployer OpenShift dans 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. Appliquer une stratégie de répartition de l'emplacement à vos nœuds de cluster permet de réduire le nombre de nœuds simultanément affectés par des perturbations spécifiques à une zone géographique. Pour en savoir plus sur la création d'une stratégie de répartition pour des clusters existants, consultez la section Créer et appliquer des stratégies d'emplacement par répartition 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éplicas 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 utilisateur 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 de manière proactive la charge pour éviter le surengagement de ressources

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

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 global pour le contrôleur d'entré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'accéder aux charges de travail exécutées sur votre cluster. En outre, nous vous recommandons d'implémenter des vérifications de l'é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 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 lors d'interruptions telles que 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 de 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 suivantes.

Bonnes pratiques concernant les disques

Si vous avez besoin 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:

Enfin, définissez un StorageClass pour votre disque:

L'exemple suivant montre comment définir une StorageClass:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: regionalpd-balanced
provisioner: PROVISIONER
parameters:
  type: DISK-TYPE
  replication-type: REPLICATION-TYPE
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
allowVolumeExpansion: true
allowedTopologies:
  - matchLabelExpressions:
      - key: topology.kubernetes.io/zone
        values:
          - europe-west1-b
          - europe-west1-a

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 pour gérer la haute disponibilité de la base de données en votre nom. 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 activer la haute disponibilité. Pour en savoir plus, consultez la documentation associée à votre opérateur de base de données, comme Redis Enterprise pour Kubernetes, Operator MariaDB ou Operator PostgreSQL CloudNative.

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

Étape suivante