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

Découvrez comment l' IBM Cloud Kubernetes Service 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 garantir une résilience élevée.

Présentation générale de l'architecture des clusters et de leurs rôles

IBM Cloud Kubernetes Service est un service Kubernetes géré. Dans chaque cluster, l'architecture est divisée en deux plans dont [les responsabilités en matière de gestion sont distinctes](/docs/containers?topic=containers-responsibilities_Kubernetes Service):

Plan de contrôle
Géré par IBM. Comprend le serveur API Kubernetes, l’interface etcd, le gestionnaire de contrôleurs et le planificateur.
Plan de données
Gérés par vos soins. 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'application, stockage, modules complémentaires de mise en réseau

IBM applique régulièrement des mises à jour de version de correctif au plan de contrôle. Ces correctifs corrigent des failles de sécurité, appliquent des corrections de bogues critiques et garantissent la conformité des clusters 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’ IBM Cloud Kubernetes Service 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 d' 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 qu'un pod ne soit supprimé.

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'application 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:

  • Mettre en œuvre une logique de réessai avec un délai d'attente exponentiel pour tous les appels d'API.
  • Évitez de recourir à 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 panne en production dans un environnement hors production avant qu'une maintenance planifié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 réessai, 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 par correctifs. Ce test vérifie que votre application et vos outils gèrent sans heurts les transitions entre les répliques du plan de contrôle.

  1. Déclenchez une actualisation du plan de contrôle sur votre cluster.

    ibmcloud ks 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 travailleurs pour ajouter un nœud de travail temporaire.

    ibmcloud ks 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.
       kubectl cordon NODE_NAME
   kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data
    1. Supprimez le nœud de travail du cluster.
       ibmcloud ks worker rm --cluster CLUSTER_NAME_OR_ID --worker WORKER_ID
    1. Rétablissez la capacité initiale du pool de travailleurs en utilisant la commande ibmcloud ks worker-pool resize avec votre valeur --size-per-zone d'origine.

    Comme alternative, avec une approche moins ciblée, vous pouvez simplement ramener le pool de workers à sa taille d'origine en utilisant la commande ibmcloud ks 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 interruption 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 des nœuds ou les mises à jour du 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 supporter.

Définir les sondes de disponibilité et de fonctionnement

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

  • Tests de disponibilité : assurez-vous que Kubernetes achemine le trafic uniquement vers les pods initialisés et prêts à traiter les requêtes.
  • Contrôles d'activité : activez la fonctionnalité Kubernetes pour redémarrer automatiquement les conteneurs qui se retrouvent 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 d' Kubernetes s 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 du système

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 vous appuyer sur des connexions de longue durée au serveur API

Kubernetes Les demandes de surveillance et les connexions de streaming (telles que les kubectl 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 recul 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