Types de clusters

Cette page décrit les principaux types de clusters que vous pouvez créer dans Google Kubernetes Engine (GKE). En règle générale, les choix présentés ici ne peuvent pas être modifiés après la création d'un cluster. Ces choix affectent la disponibilité et la stabilité de la version du cluster, ainsi que le réseau.

Niveau de gestion du cluster

Avant de pouvoir parler des types de clusters, il est important de comprendre le niveau de flexibilité, de responsabilité et de contrôle dont vous avez besoin pour votre cluster. Le niveau de contrôle dont vous avez besoin détermine le mode de fonctionnement à utiliser dans GKE, ainsi que les configurations de clusters à effectuer.

Modes de fonctionnement

Lorsque vous créez un cluster dans GKE, vous le faites en utilisant l'un des modes de fonctionnement suivants:

  • Autopilot: fournit une configuration de cluster entièrement gérée et provisionnée. Pour les clusters créés à l'aide du mode Autopilot, les options de configuration de cluster sont créées automatiquement. Les clusters Autopilot sont préconfigurés avec une configuration de cluster optimisée, prête pour les charges de travail de production.

  • Standard: offre une flexibilité de configuration avancée sur l'infrastructure sous-jacente du cluster. Pour les clusters créés à l'aide du mode standard, vous déterminez les configurations nécessaires pour vos charges de travail de production.

Pour plus d'informations sur ces modes et pour en savoir plus sur Autopilot, consultez la page Présentation d'Autopilot.

Choix de configuration du cluster

En fonction du mode d'opération choisi, vous devez ensuite sélectionner les configurations dont vous avez besoin pour votre cluster. En mode Autopilot, la plupart des choix sont réalisés automatiquement. En mode standard, vous devez sélectionner les configurations qui conviennent le mieux à vos charges de travail de production.

Choix des clusters Mode
Autopilot Standard
Type de disponibilité Regional (Régional) Régionalou zonal
Version Version disponible Version disponible, par défaut ou spécifique.
le routage réseau. VPC natif VPC natif ou basé sur le routage
Isolation du réseau Privé ou public ? Privé ou public ?
Fonctionnalités de Kubernetes Production Production ou Alpha

Type de disponibilité du cluster

GKE vous permet de créer un cluster adapté aux exigences de disponibilité de votre charge de travail et à votre budget. Les types de clusters disponibles sont les suivants : zonal (zone unique ou multizones) et régional.

Pour vous aider à choisir le cluster disponible à créer en mode Standard, consultez la page Choisir un plan de contrôle régional ou zonal.

Cluster zonal

Les clusters zonaux possèdent un seul plan de contrôle dans une seule zone. Selon vos exigences de disponibilité, vous pouvez choisir de répartir les nœuds de votre cluster zonal dans une seule zone ou dans plusieurs zones.

Pour créer un cluster zonal en mode standard, consultez la page Créer un cluster zonal.

Clusters à zone unique

Un cluster à zone unique possède un seul plan de contrôle s'exécutant dans une zone. Ce plan de contrôle gère les charges de travail sur les nœuds exécutés dans la même zone.

Clusters multizones

Un cluster multizones comporte une seule instance dupliquée du plan de contrôle s'exécutant dans une seule zone et plusieurs nœuds s'exécutant dans plusieurs zones. Une mise à niveau du cluster ou une panne de la zone dans laquelle s'exécute le plan de contrôle n'empêchent pas les charges de travail de s'exécuter normalement. Toutefois, le cluster, ses nœuds et ses charges de travail ne peuvent pas être configurés tant que le plan de contrôle n'est pas disponible. Les clusters à zones multiples équilibrent la disponibilité et les coûts afin d'assurer la cohérence des charges de travail. Si vous souhaitez maintenir la disponibilité, mais que le nombre de vos nœuds et pools de nœuds évolue fréquemment, pensez à utiliser un cluster régional.

Clusters régionaux

Un cluster régional comporte plusieurs instances dupliquées du plan de contrôle, qui s'exécutent dans plusieurs zones au sein d'une région donnée. Les nœuds s'exécutent également dans chaque zone dans laquelle s'exécute une instance dupliquée du plan de contrôle. Dans la mesure où un cluster régional réplique le plan de contrôle et les nœuds, il consomme davantage de ressources Compute Engine qu'un cluster analogue à zone unique ou multizones.

Pour créer un cluster régional en mode standard, consultez la section Créer un cluster régional.

Pour créer un cluster régional en mode Autopilot, consultez la page Créer un cluster Autopilot.

Version du cluster

Lorsque vous créez un cluster, vous pouvez choisir une version Kubernetes spécifique ou sélectionner des options concernant sa stabilité et ses fonctionnalités globales.

Quelle que soit votre gestion de la version du cluster, nous vous recommandons d'activer la mise à jour automatique pour le cluster et ses nœuds. GKE met automatiquement à niveau les nœuds pour les clusters Autopilot.

Canal de publication

Si vous connaissez le niveau de stabilité requis pour un cluster donné, vous pouvez enregistrer ce cluster dans une version disponible. Par défaut, les nouveaux clusters sont enregistrés dans la version disponible standard. Google met automatiquement à jour le cluster et ses nœuds lorsqu'une mise à jour est disponible pour cette version. Le canal rapide reçoit plusieurs mises à jour par mois, tandis que le canal stable ne reçoit que quelques mises à jour par an.

Version par défaut

Si vous n'utilisez pas une version disponible ou si ne vous choisissez pas de version de cluster, la version par défaut actuelle est utilisée. La version par défaut est sélectionnée en fonction de l'utilisation et des performances réelles. Elle est régulièrement modifiée. Bien que la version par défaut soit la plus aboutie, d'autres versions disponibles sont des versions en disponibilité générale qui ont passé avec succès les tests et la qualification internes. Les modifications apportées à la version par défaut sont annoncées dans une note de version.

Version spécifique

Si vous devez utiliser une version compatible de Kubernetes spécifique pour une charge de travail donnée, vous pouvez l'indiquer lors de la création du cluster.

Si vous n'avez pas besoin de contrôler la version de correctif spécifique utilisée, envisagez d'enregistrer votre cluster dans une version disponible au lieu de gérer directement sa version.

Mise en réseau des clusters

Lors de la création d'un cluster GKE, vous pouvez spécifier le mode de routage du réseau ainsi que la manière de l'isoler.

Clusters de VPC natif et clusters basés sur le routage

Google Kubernetes Engine comprend deux types de clusters, caractérisés par la manière dont ils acheminent le trafic d'un pod à un autre. Un cluster qui s'appuie sur des adresses IP d'alias est appelé un cluster de VPC natif. Un cluster qui utilise des routes Google Cloud est appelé cluster basé sur le routage.

Le VPC natif est le mode réseau recommandé pour les nouveaux clusters. Il s'agit de la valeur par défaut pour les clusters créés en mode Autopilot.

Le mode de réseau du cluster par défaut dépend de la façon dont le cluster est créé en mode standard. Pour en savoir plus, consultez le tableau Mode de réseau du cluster par défaut.

Choix concernant l'isolation du réseau

Par défaut, vous pouvez configurer l'accès des réseaux publics aux charges de travail de votre cluster. Les routes ne sont pas créées automatiquement. Les clusters privés attribuent des adresses IP internes aux pods et aux nœuds. Les charges de travail sont complètement isolées des réseaux publics.

Pour créer un cluster privé, consultez la section Créer un cluster privé.

Fonctionnalités de Kubernetes

Les nouvelles fonctionnalités de Kubernetes sont répertoriées sous les noms Alpha, Bêta ou Stable, en fonction de leur état de développement. Dans la plupart des cas, les fonctionnalités de Kubernetes répertoriées en tant que version Bêta ou version Stable sont incluses avec des clusters GKE. Les fonctionnalités Alpha de Kubernetes sont disponibles dans des clusters alpha GKE spéciaux.

Cluster alpha

Dans un cluster alpha, toutes les API Kubernetes alpha (aussi appelées portes de fonctionnalité) sont activées. Vous pouvez vous servir des clusters alpha pour réaliser des tests préliminaires des fonctionnalités de Kubernetes et les valider. Les clusters alpha ne sont pas compatibles avec les charges de travail de production. Ils ne peuvent pas être mis à jour et ont une durée de vie de 30 jours.

Pour créer un cluster alpha en mode standard, consultez la section Créer un cluster alpha.