Clusters régionaux


Cette page explique le fonctionnement des clusters régionaux dans Google Kubernetes Engine (GKE). Vous pouvez créer un cluster régional ou en apprendre davantage sur les différents types de clusters.

Présentation

Contrairement aux clusters zonaux ayant un seul plan de contrôle dans une seule zone, les clusters régionaux augmentent la disponibilité du plan de contrôle du cluster et de ses nœuds en les répliquant sur plusieurs zones d'une même région. Cela permet d'obtenir les avantages liés aux clusters multizones, en plus des bénéfices suivants :

  • Si une zone d'une région subit une panne, le plan de contrôle du cluster reste accessible tant que deux répliques du plan de contrôle sont disponibles.
  • Lors des opérations de maintenance du cluster, telle qu'une mise à jour, une seule instance dupliquée du plan de contrôle à la fois n'est pas disponible et le cluster reste opérationnel.

Le plan de contrôle est répliqué sur trois zones d'une région. Pour les pools de nœuds, vous pouvez spécifier manuellement la ou les zones dans lesquelles exécuter les pools de nœuds, ou utiliser la configuration par défaut, qui réplique chaque pool de nœuds sur trois zones de la région du plan de contrôle. Toutes les zones doivent se trouver dans la même région que le plan de contrôle du cluster.

Utilisez des clusters régionaux pour exécuter vos charges de travail de production, car elles offrent une disponibilité plus élevée que les clusters zonaux.

Après avoir créé un cluster régional, vous ne pouvez pas le remplacer par 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 sur 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 us-east1 : us-east1-b, us-east1-c, et us-east1-d. En cas de panne d'infrastructure, vos charges de travail continuent de s'exécuter, et les nœuds peuvent être rééquilibrés manuellement ou à l'aide de l'autoscaler de cluster.

Voici les avantages qu'offre l'utilisation de clusters régionaux:

  • 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 réduction des temps d'arrêt liés aux défaillances du plan de contrôle. Avec des instances dupliquées redondantes du plan de contrôle, les clusters régionaux offrent une plus grande disponibilité de l'API Kubernetes. Vous pouvez ainsi accéder à votre plan de contrôle même pendant les mises à niveau.

Limites

  • Par défaut, les clusters régionaux sont composés de neuf nœuds (trois par zone) répartis uniformément sur trois zones d'une région. Cette configuration consomme 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, en fonction de 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 avec trois zones où les GPU sont disponibles. Vous pouvez également spécifier des zones à l'aide de l'option --node-locations lors de la création du cluster.

    Si la région que vous choisissez ne dispose pas de trois zones où les GPU 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 dans lesquelles les GPU sont disponibles, consultez la page GPU sur Compute Engine.

  • Les zones des pools de nœuds 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

L'utilisation de clusters régionaux nécessite davantage de quotas régionaux de votre projet que l'utilisation d'un cluster zonal ou multizones semblable. 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 dans des clusters régionaux à l'aide de l'autoscaler de cluster.

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.

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