Clusters régionaux

Cette page explique le fonctionnement des clusters régionaux dans Google Kubernetes Engine (GKE).

Les clusters régionaux augmentent la disponibilité d'un cluster en répliquant le plan de contrôle et les nœuds sur plusieurs zones d'une région.

Les clusters régionaux présentent tous les avantages des clusters multizones, en plus des suivants :

  • Résilience en cas de défaillance d'une zone unique: les clusters régionaux sont disponibles dans une région plutôt que dans une seule zone au sein d'une région. En cas d'indisponibilité d'une seule zone, votre plan de contrôle et vos ressources ne sont pas affectés.
  • Mises à niveau continues du plan de contrôle, redimensionnement du plan de contrôle et temps d'arrêt réduit en cas de défaillance d'un plan de contrôle. Avec des instances dupliquées redondantes du plan de contrôle, les clusters régionaux assurent une plus grande disponibilité de l'API Kubernetes. Vous pouvez ainsi accéder à votre plan de contrôle même pendant les mises à niveau.

Les clusters Autopilot GKE sont toujours régionaux. Si vous utilisez GKE Standard, vous pouvez choisir de créer des clusters régionaux, zonaux ou multizones. Pour en savoir plus sur les différents types de disponibilité de cluster, consultez la page À propos des choix de configuration des clusters.

Dans les clusters régionaux (clusters Autopilot inclus), le plan de contrôle est répliqué sur trois zones d'une région. GKE réplique automatiquement les nœuds dans les zones d'une même région. Dans les clusters et les pools de nœuds standards, vous pouvez éventuellement spécifier manuellement la ou les zones dans lesquelles les nœuds sont exécutés. Toutes les zones doivent se trouver dans la même région que le plan de contrôle.

Une fois que vous avez créé un cluster régional, vous ne pouvez pas le modifier en un cluster zonal.

Utiliser les clusters régionaux

Les clusters régionaux répliquent le plan de contrôle et les nœuds du cluster dans plusieurs zones d'une même région. Par exemple, en utilisant la configuration par défaut, un cluster régional dans la région us-east1 crée des instances dupliquées du plan de contrôle et des nœuds dans trois zones de la région us-east1 : us-east1-b, us-east1-c, et us-east1-d. En cas de panne d'infrastructure, les charges de travail Autopilot continuent de s'exécuter et GKE rééquilibre automatiquement les nœuds. Si vous utilisez des clusters standards, vous devez rééquilibrer les nœuds manuellement ou à l'aide de l'autoscaler de cluster.

Limites

  • Le pool de nœuds par défaut créé pour les clusters régionaux standards comprend neuf nœuds (trois par zone) répartis uniformément sur trois zones d'une région. Pour les clusters publics, cela implique la consommation de neuf adresses IP. Si vous le souhaitez, vous pouvez limiter le nombre de nœuds à un par zone. Les comptes de facturation Cloud qui viennent d'être créés ne se voient attribuer que huit adresses IP par région. Vous devrez donc peut-être demander une augmentation de vos quotas pour les adresses IP régionales utilisées, selon la taille de votre cluster régional. En cas de faible disponibilité des adresses IP en cours d'utilisation, la création du cluster échoue.

  • Pour exécuter des GPU dans votre cluster régional, choisissez une région qui comporte au moins une zone dans laquelle les GPU demandés sont disponibles. Vous devez utiliser l'option --node-locations lors de la création du pool de nœuds pour spécifier la ou les zones contenant les GPU demandés.

    Si la région que vous choisissez ne dispose pas d'au moins une zone où les GPU demandés sont disponibles, une erreur semblable à celle-ci peut s'afficher:

    ERROR: (gcloud.container.clusters.create) ResponseError: code=400, message=
    (1) accelerator type "nvidia-tesla-k80" does not exist in zone us-west1-c.
    (2) accelerator type "nvidia-tesla-k80" does not exist in zone us-west1-a.

    Pour obtenir la liste complète des régions et des zones où des GPU sont disponibles, consultez la page GPU sur Compute Engine.

  • Les zones des pools de nœuds en mode Standard doivent se trouver dans la même région que le plan de contrôle du cluster. Si nécessaire, vous pouvez modifier les zones d'un cluster, de sorte que tous les nœuds nouveaux et existants couvrent ces zones.

Tarifs

Tous les clusters Autopilot sont régionaux et sont soumis au modèle de tarification Autopilot.

En mode standard, les clusters régionaux nécessitent davantage de quotas régionaux de votre projet que les clusters zonaux ou multizones similaires. Assurez-vous de bien comprendre vos quotas et la tarification de GKE avant d'utiliser les clusters régionaux. Si une erreur Insufficient regional quota to satisfy request for resource s'affiche, cela signifie que votre requête dépasse votre quota disponible dans la région actuelle.

De plus, des frais sont facturés pour le trafic nœud à nœud entre les zones. Par exemple, si une charge de travail exécutée dans une zone doit communiquer avec une charge de travail située dans une autre zone, le trafic interzone entraîne des coûts. Pour en savoir plus, consultez la section Sortie entre zones d'une même région (par Go) de la page des tarifs de Compute Engine.

Espace de stockage persistant dans les clusters régionaux

Les disques persistants zonaux sont des ressources zonales et les disques persistants régionaux sont des ressources multi-zonales. Lors de l'ajout d'un espace de stockage persistant, GKE attribue le disque à une seule zone aléatoire, sauf si une zone est déjà spécifiée. Pour savoir comment contrôler les zones, consultez la section Zones dans les disques persistants.

Procéder à l'autoscaling des clusters régionaux

Tenez compte des considérations suivantes lorsque vous effectuez le scaling automatique des pools de nœuds avec l'autoscaler de cluster dans des clusters régionaux en mode Standard.

Vous pouvez également obtenir plus d'informations sur les limites de l'autoscaling pour les clusters régionaux ou sur l'équilibrage au niveau des zones de l'autoscaler de cluster.

Ces considérations ne s'appliquent qu'aux clusters en mode standard avec autoscaler de cluster.

Surprovisionner les limites de scaling

Pour maintenir la capacité dans le cas improbable d'une défaillance de zone, vous pouvez autoriser GKE à surprovisionner les limites de scaling, afin de garantir un niveau de disponibilité minimal même lorsque certaines zones ne sont pas disponibles.

Par exemple, si vous surprovisionnez un cluster à trois zones à 150 % (50 % de capacité supplémentaire), cela vous garantit que 100 % du trafic est acheminé vers les zones disponibles en cas de perte d'un tiers de la capacité du cluster. Dans l'exemple précédent, vous pouvez atteindre cet objectif en spécifiant un maximum de six nœuds par zone au lieu de quatre. Si une zone échoue, le cluster peut évoluer pour intégrer jusqu'à 12 nœuds dans les zones restantes.

De même, si vous surprovisionnez un cluster à deux zones à 200 %, cela vous garantit que 100 % du trafic est redirigé en cas de perte de la moitié de la capacité du cluster.

Vous pouvez en apprendre plus sur l'autoscaler de cluster ou lire la section Questions fréquentes sur l'autoscaling de la documentation Kubernetes.

Étape suivante