Développement et test d'applications pour garantir leur résilience

Découvrez comment l' Red Hat OpenShift on IBM Cloud gère la maintenance du plan de contrôle, comment les mises à jour de maintenance affectent les charges de travail en cours d'exécution, et comment tester et concevoir vos applications pour une résilience élevée.

Présentation générale de l'architecture des clusters et de leurs responsabilités

Red Hat OpenShift on IBM Cloud est un service Kubernetes géré. Dans chaque cluster, l'architecture est divisée en deux plans avec [des responsabilités distinctes en matière de gestion](/docs/openshift?topic=openshift-responsibilities_Kubernetes Service):

Plan de contrôle
Géré par IBM. Comprend le serveur API Kubernetes, etcd, le gestionnaire de contrôleurs et le planificateur.
Plan de données
Géré par vous. Comprend les nœuds de travail, les pods d'application, les configurations de stockage et les modules complémentaires de mise en réseau.
Responsabilités liées à la gestion du plan de contrôle et du plan de données du cluster
Plane Géré par Composants
Plan de contrôle IBM Serveur API, etcd, gestionnaire de contrôleurs, planificateur
Plan de données Vous Nœuds de travail, pods d’applications, stockage, modules complémentaires de mise en réseau

IBM applique régulièrement des mises à jour de version (patches) au plan de contrôle. Ces correctifs corrigent des failles de sécurité, appliquent des corrections de bogues critiques et garantissent que les clusters restent conformes aux exigences de sécurité d' IBM. Comprendre comment ces correctifs sont appliqués vous aide à prendre des décisions éclairées concernant l'architecture de votre application.

Les applications exécutées dans des environnements cloud sont exposées à des conditions dynamiques, notamment des perturbations réseau passagères, la maintenance de l'infrastructure d'hébergement et la latence des services tiers. Concevoir et tester la résilience dans toutes les conditions garantit la fiabilité des charges de travail en production.

Comment IBM applique les correctifs au plan de contrôle

Les composants du plan de contrôle de chaque cluster d' Red Hat OpenShift on IBM Cloud s fonctionnent dans une configuration à haute disponibilité (HA). Plusieurs répliques de chaque composant sont réparties dans des zones de disponibilité indépendantes, de sorte qu'il n'existe aucun point de défaillance unique au sein du plan de contrôle.

Lorsqu'une mise à jour de correctif est appliquée, IBM utilise une stratégie de recréation progressive. Les répliques sont mises à jour de manière séquentielle :

  • Le serveur API Kubernetes reste accessible tout au long de la mise à niveau.
  • Les opérations du cluster, telles que la planification, la mise à l'échelle automatique et les contrôles d'intégrité, se poursuivent sans interruption.
  • IBM fournit un délai d'arrêt progressif afin de permettre aux connexions en cours de se terminer avant la suppression d'un pod.

Les mises à jour des correctifs du plan de contrôle sont conçues de manière à n'avoir aucun impact sur les applications utilisateur s'exécutant dans le plan de données. Vos pods, services et charges de travail continuent de fonctionner normalement sur les nœuds de travail tout au long du processus.

Impact sur les charges de travail lors des mises à jour du plan de contrôle

Le plan de données étant géré par l'utilisateur, les correctifs du plan de contrôle d' IBM ne redémarrent pas, ne replanifient pas et ne modifient pas vos nœuds de travail ni vos pods d'applications en cours d'exécution.

Toutefois, les applications ou outils qui effectuent fréquemment des appels directs à l’API Kubernetes (tels que les contrôleurs personnalisés, les opérateurs, les pipelines CI/CD ou les agents de surveillance qui surveillent l’état du cluster) doivent gérer les erreurs API transitoires de manière appropriée. Respectez les bonnes pratiques générales en matière d' Kubernetes:

  • Mettez en œuvre une logique de réessai avec délai d'attente exponentiel pour tous les appels d'API.
  • Évitez de vous appuyer sur des connexions ouvertes persistantes au serveur API sans logique de reconnexion.

Simulation de scénarios pour tester la résilience des applications

Pour renforcer la confiance dans la résilience des applications, simulez des conditions de défaillance en production dans un environnement hors production avant qu'une maintenance programmée ou des perturbations imprévues ne surviennent.

Au cours de toute simulation, surveillez vos applications afin de détecter tout signe de perturbation : redémarrages inattendus de pods, pics dans les journaux d'erreurs, temps de réponse dégradés ou requêtes client perdues. Utilisez ces observations pour affiner la logique de nouvelle tentative, optimiser les sondes de santé ou ajuster la topologie des répliques.

L'exécution de commandes de gestion de cluster (telles que master refresh ou worker pool resize) nécessite un accès à la plateforme en tant qu'administrateur ou opérateur, ainsi que des autorisations pour le service de gestion de cluster. Si vous êtes développeur d'applications et que vous n'avez pas accès à l'infrastructure de cluster, coordonnez-vous avec votre administrateur de cluster pour exécuter ces simulations.

Simulation d'un correctif du plan de contrôle à l'aide d'une actualisation du plan de contrôle

Le déclenchement d'un rafraîchissement du plan de contrôle lance le processus de mise à jour progressive utilisé par IBM lors des mises à niveau de correctifs. Ce test permet de vérifier que votre application et vos outils gèrent correctement les transitions entre les répliques du plan de contrôle.

  1. Déclenchez un rafraîchissement du plan de contrôle sur votre cluster.

    ibmcloud oc cluster master refresh --cluster CLUSTER_NAME_OR_ID

  2. Vérifiez que vos applications continuent de traiter le trafic sans interruption et que les points de terminaison accessibles aux clients restent réactifs.

Simulation des mises à jour de routage réseau par l'ajout et la suppression de nœuds de travail

L'ajout et la suppression de nœuds de travail entraînent la mise à jour par l' Kubernetes de la logique de routage réseau interne à l'échelle du cluster, simulant ainsi les conditions qui se produisent lorsque les nœuds sont redémarrés lors de la maintenance de l'infrastructure.

  1. Redimensionnez votre pool de nœuds pour ajouter un nœud de travail temporaire.

    ibmcloud oc worker-pool resize --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME --size-per-zone NEW_SIZE

  2. Surveillez les journaux de votre application et la latence de réponse pendant que le nouveau nœud de travail s'initialise et rejoint le réseau du cluster.

  3. Une fois le test terminé, supprimez le nœud de travail de test.

    Pour supprimer de manière ciblée le nœud de travail spécifique créé à l'étape 1 :

    1. Isolez et vidangez le nœud de travail avant de le supprimer afin de garantir que les charges de travail soient replanifiées en douceur.
       oc cordon NODE_NAME
   oc drain NODE_NAME --ignore-daemonsets --delete-emptydir-data
    1. Supprimez le nœud de travail du cluster.
       ibmcloud oc worker rm --cluster CLUSTER_NAME_OR_ID --worker WORKER_ID
    1. Rétablissez la capacité d'origine du pool de travailleurs en utilisant la commande ibmcloud oc worker-pool resize avec votre valeur --size-per-zone d'origine.

    Comme alternative, avec une approche moins ciblée, vous pouvez simplement redimensionner le pool de travailleurs pour lui redonner sa taille d'origine en utilisant la commande ibmcloud oc worker-pool resize de l'étape 1 sans supprimer explicitement un nœud spécifique.

Pratiques recommandées pour la résilience des charges de travail

La résilience de votre application lors d'événements liés au cluster dépend de la manière dont vos charges de travail sont conçues et configurées. Appliquez les bonnes pratiques suivantes aux spécifications de vos charges de travail Kubernetes:

Exécutez plusieurs répliques pour chaque charge de travail

Un déploiement à réplique unique ne tolère aucune interruption. Définissez cette valeur à spec.replicas au moins ( 2 de préférence ou 3 plus pour les charges de travail de production) afin que la perte ou la replanification d'un seul pod n'entraîne pas d'interruption de service.

Répartir les répliques entre les zones et les nœuds de travail

Configurez les règles d'anti-affinité des topologySpreadConstraints pods dans votre configuration de déploiement. La répartition des pods sur plusieurs zones de disponibilité et nœuds de travail empêche qu’une perturbation dans une seule zone ou une opération de maintenance sur un nœud ne provoque la mise hors service simultanée de toutes les répliques.

Configurer les budgets de perturbation des pods (PDB)

Une ressource PodDisruptionBudget spécifie le nombre ou le pourcentage minimum de pods qui doivent rester disponibles lors d'interruptions volontaires, telles que le vidage de nœuds ou les mises à jour de cluster. Définissez un PDB pour chaque charge de travail critique afin d'éviter que les opérations d'administration n'évincent plus de pods que votre application ne peut en tolérer.

Définir les sondes de disponibilité et d'activité

Configurez les sondes de disponibilité et de fonctionnement dans les spécifications de vos conteneurs :

  • Tests de disponibilité : assurez-vous que l' Kubernetes e le trafic uniquement vers les pods initialisés et prêts à traiter les requêtes.
  • Contrôles de disponibilité : activez la fonctionnalité Kubernetes pour redémarrer automatiquement les conteneurs qui se trouvent dans un état de blocage ou de dysfonctionnement.

Définir des demandes et des limites de ressources appropriées

Spécifiez des demandes et des limites réalistes en matière de CPU et de mémoire pour chaque conteneur. Ces requêtes garantissent que le planificateur Kubernetes place les pods sur des nœuds disposant d'une capacité suffisante. Les limites empêchent un conteneur isolé de consommer des ressources excessives et de nuire aux charges de travail colocalisées sur le même nœud de travail.

Mise en œuvre d'une gestion en douceur de l'arrêt

Lorsqu'un pod est arrêté, Kubernetes envoie un signal SIGTERM avant d'envoyer SIGKILL. Concevez votre application de manière à détecter les problèmes SIGTERM, à cesser d'accepter de nouvelles connexions, à mener à bien les transactions en cours et à se fermer correctement. Définissez une valeur appropriée dans terminationGracePeriodSeconds la spécification de votre pod afin de laisser à votre application suffisamment de temps pour évacuer le trafic.

Évitez de recourir à des connexions de longue durée au serveur API

Kubernetes Les demandes de surveillance et les connexions de streaming (telles que les oc exec redirection de ports ou les surveillances de clients API personnalisées) se connectent directement à une réplique spécifique du plan de contrôle. Lorsque cette réplique effectue un cycle lors d'une mise à jour de correctif, la connexion est interrompue. Les charges de travail et les outils doivent mettre en œuvre une logique de reconnexion automatique avec un délai d'attente exponentiel.

Utiliser la logique de réessai et les disjoncteurs de circuit

Lorsque votre application interagit avec l'API Kubernetes, des bases de données externes ou des microservices en aval, mettez en œuvre une logique de réessai avec un délai d'attente exponentiel et une variation de délai. Utilisez des modèles de disjoncteurs pour éviter les défaillances en cascade lorsqu'une dépendance en amont ou en aval est temporairement indisponible.

Etapes suivantes