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

Par défaut, le plan de contrôle (maître) d'un cluster et les nœuds s'exécutent dans une seule zone de calcul, que vous spécifiez lors de la création du cluster. Les clusters régionaux augmentent la disponibilité du plan de contrôle (maître) d'un 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 :

  • En cas de panne sur une ou plusieurs zones (mais pas toutes) de la région, le plan de contrôle du cluster reste accessible tant qu'une instance dupliquée du plan de contrôle est disponible.
  • 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.

Par défaut, le plan de contrôle et chaque pool de nœuds sont répliqués sur trois zones d'une région, mais vous pouvez personnaliser le nombre d'instances dupliquées.

Vous ne pouvez pas déterminer si un cluster est zonal, multizones ou régional une fois le cluster créé.

Utiliser les clusters régionaux

Les clusters régionaux répliquent les maîtres et les nœuds de cluster dans plusieurs zones d'une même région. Par exemple, 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 :

  • La résilience lors de la 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 Kubernetes et vos ressources ne sont pas affectés.
  • Aucun temps d'arrêt pour la mise à niveau ou le redimensionnement des maîtres, et temps d'arrêt réduit en cas de panne d'un maître. Un cluster régional fournit un plan de contrôle à haute disponibilité, qui vous permet d'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 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 Google 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 les clusters régionaux exécutant des GPU, vous devez choisir une région comportant des GPU dans trois zones ou spécifier des zones à l'aide de l'option --node-locations. Sinon, vous pourriez rencontrer une erreur semblable à celle-ci :

    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.

  • Vous ne pouvez pas créer de pool de nœuds dans des zones extérieures aux zones du cluster. Toutefois, 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 de stockage persistants sont des ressources zonales. Lorsque vous ajoutez un espace de stockage persistant à votre cluster, GKE affecte le disque à une seule zone, sauf si une zone est déjà spécifiée. GKE choisit la zone au hasard. Lors de l'utilisation d'un objet StatefulSet, les disques persistants provisionnés pour chaque instance dupliquée sont répartis sur plusieurs zones.

Une fois qu'un disque persistant est provisionné, tous les pods référençant le disque sont planifiés dans la même zone que le disque.

Un disque persistant en lecture/écriture ne peut pas être associé à plusieurs nœuds.

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 ci-dessus, 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.

Étapes suivantes