Cette page décrit l’exécution de Kubernetes sur plusieurs zones.
Kubernetes est conçu pour qu’un seul cluster Kubernetes puisse fonctionner sur plusieurs zones de défaillance, généralement regroupées au sein d’une entité logique appelée région. Les principaux fournisseurs cloud définissent une région comme un ensemble de zones de défaillance (également appelées zones de disponibilité) qui fournissent un ensemble cohérent de fonctionnalités : dans une région, chaque zone expose les mêmes API et services.
Les architectures cloud typiques visent à réduire au maximum le risque qu’une panne dans une zone affecte également les services d’une autre zone.
Tous les composants du plan de contrôle peuvent fonctionner comme un ensemble de ressources interchangeables, répliquées par composant.
Lors du déploiement d’un plan de contrôle Kubernetes, placez les réplicas des composants du plan de contrôle sur plusieurs zones de défaillance. Si la disponibilité est un critère important, sélectionnez au moins trois zones de défaillance et répliquez chaque composant du plan de contrôle (API server, scheduler, etcd, controller manager) sur au moins trois zones de défaillance. Si vous utilisez un cloud controller manager, vous devez également le répliquer dans toutes les zones sélectionnées.
Kubernetes répartit automatiquement les Pods des ressources de charge de travail (telles que Deployment ou StatefulSet) sur différents nœuds du cluster. Cette répartition permet de réduire l’impact des défaillances.
Lors de leur démarrage, les kubelets sur chaque nœud ajoutent automatiquement des labels à l’objet Node représentant ce kubelet dans l’API Kubernetes. Ces labels peuvent inclure des informations de zone (zone information).
Si votre cluster s’étend sur plusieurs zones ou régions, vous pouvez utiliser ces labels avec des contraintes de répartition topologique des Pods pour contrôler la distribution des Pods entre les domaines de défaillance : régions, zones et même nœuds spécifiques. Ces indications permettent au scheduler de placer les Pods de manière à améliorer la disponibilité et réduire le risque qu’une panne corrélée affecte l’ensemble de votre charge de travail.
Par exemple, vous pouvez définir une contrainte pour vous assurer que les 3 réplicas d’un StatefulSet sont répartis sur des zones différentes lorsque cela est possible. Cela peut être défini de manière déclarative sans avoir à spécifier explicitement les zones utilisées pour chaque workload.
Le cœur de Kubernetes ne crée pas de nœuds pour vous ; vous devez le faire vous-même, ou utiliser un outil comme le Cluster API pour gérer les nœuds à votre place.
Avec des outils comme Cluster API, vous pouvez définir des ensembles de machines exécutées comme nœuds de travail répartis sur plusieurs domaines de défaillance, ainsi que des règles permettant de réparer automatiquement le cluster en cas de panne complète d’une zone.
Vous pouvez appliquer des sélecteurs de nœuds aux Pods que vous créez, ainsi qu’aux templates de Pods dans les ressources de type Deployment, StatefulSet ou Job.
Lors de la création de volumes persistants, Kubernetes ajoute automatiquement des labels
de zone aux PersistentVolumes liés à une zone spécifique.
Le scheduler s’assure ensuite,
via le prédicat NoVolumeZoneConflict, que les pods utilisant un PersistentVolume donné
sont planifiés uniquement dans la même zone que ce volume.
Notez que la manière d’ajouter ces labels dépend du fournisseur cloud et du provisionneur de stockage utilisé. Consultez toujours la documentation de votre environnement pour garantir une configuration correcte.
Vous pouvez spécifier une StorageClass qui définit les domaines de défaillance (zones) dans lesquels le stockage peut être créé. Pour en savoir plus, consultez les topologies autorisées.
Kubernetes n’intègre pas nativement de prise en charge du réseau par zone.
Vous pouvez utiliser un
plugin réseau
pour configurer la connectivité du cluster, et cette solution peut inclure des
éléments dépendant des zones. Par exemple, si votre fournisseur cloud prend en charge
les Services de type LoadBalancer, le load balancer peut diriger le trafic uniquement
vers les Pods situés dans la même zone que l’instance traitant la connexion.
Consultez la documentation de votre fournisseur cloud pour plus de détails.
Pour les déploiements sur site ou personnalisés, des considérations similaires s’appliquent. Le comportement des Service et Ingress, notamment en matière de zones, dépend de la configuration de votre cluster.
Lors de la configuration du cluster, vous devez également envisager la manière dont votre système peut restaurer le service si toutes les zones d’une région deviennent indisponibles simultanément. Par exemple, votre système dépend-il de la présence d’au moins un nœud actif dans une zone ?
Assurez-vous que les opérations de réparation critiques ne dépendent pas de la disponibilité d’un nœud sain dans le cluster. Par exemple, si tous les nœuds sont défaillants, vous devrez peut-être exécuter une tâche de réparation avec une tolérance spéciale afin de permettre la remise en service d’au moins un nœud.
Kubernetes ne fournit pas de solution complète à ce problème, mais il s’agit d’un point important à prendre en compte.
Pour comprendre comment le scheduler place les Pods dans un cluster en respectant les contraintes configurées, consultez la section Planification et éviction.