Cette page décrit les deux modes de fonctionnement et les principaux choix de configuration de cluster que vous pouvez faire lors de la création d'un cluster 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 des clusters
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.
Une fois que vous avez créé un cluster, vous ne pouvez pas le faire passer de zonal à régional, ou de régional à zonal. À la place, vous devez créer un autre cluster, puis transférer le trafic vers celui-ci.
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. Si vous exécutez une charge de travail dans une seule zone, cette charge de travail ne sera pas disponible en cas d'indisponibilité de 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. Si vous exécutez une charge de travail dans plusieurs zones et qu'une indisponibilité de zone se produit, la charge de travail est interrompue dans cette zone, mais reste disponible dans les autres.
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 d'un cluster régional peuvent s'exécuter dans une ou plusieurs zones, en fonction des emplacements de nœuds configurés. Par défaut, GKE réplique chaque pool de nœuds sur trois zones de la région du plan de contrôle. Lorsque vous créez un cluster ou lorsque vous ajoutez un pool de nœuds, vous pouvez modifier la configuration par défaut en spécifiant la ou les zones dans lesquelles les nœuds du cluster s'exécutent. Toutes les zones doivent se trouver dans la même région que le plan de contrôle.
Utilisez des clusters régionaux pour exécuter vos charges de travail de production, car ils offrent une disponibilité plus élevée que les clusters zonaux.
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 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.
Version par défaut
Si vous choisissez d'utiliser une version statique au lieu d'enregistrer le cluster dans une version disponible (c'est-à-dire sans canal) et que vous ne définissez pas de version spécifique pour le 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. La version statique par défaut est généralement alignée sur la version disponible standard. 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.
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.
Pour les clusters créés en mode standard, le mode de réseau par défaut dépend de la version de GKE et de la méthode utilisée pour créer le cluster.
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.