À propos des choix de configuration des clusters

Cette page décrit les principaux choix de configuration de cluster que vous pouvez faire lors de la création d'un cluster dans Google Kubernetes Engine (GKE), que vous utilisiez la consoleGoogle Cloud , la Google Cloud CLI ou Terraform. Ces options vous permettent de personnaliser un large éventail d'attributs et de comportements de cluster pour répondre à vos besoins, qu'il s'agisse de l'accessibilité du cluster depuis les réseaux publics ou de la manière dont vous souhaitez qu'il reçoive les mises à niveau de version.

De nombreuses options présentées dans ce guide ne peuvent pas être modifiées après la création d'un cluster. Ces choix affectent la disponibilité et le réseau du cluster. Si vous devez modifier ces options, vous devez créer un autre cluster, puis transférer le trafic vers celui-ci, ce qui peut entraîner des perturbations.

Bonne pratique:

Étant donné que de nombreuses options de configuration de cluster ne peuvent pas être modifiées après la création du cluster, planifiez et concevez la configuration de votre cluster avec les administrateurs et les architectes de votre organisation, les Cloud Architects, les administrateurs réseau ou toute autre équipe chargée de définir, d'implémenter et de gérer l'architecture GKE etGoogle Cloud .

Cette page s'adresse aux administrateurs et aux architectes qui définissent les solutions informatiques et l'architecture du système conformément à la stratégie de l'entreprise. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Avant de lire cette page, vous devez connaître les concepts suivants, ainsi que les concepts de base de Kubernetes :

Niveau de gestion des clusters

Avant de discuter des options de cluster, 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 et les choix de configuration de cluster que vous devez effectuer.

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

  • Autopilot (recommandé) : fournit une configuration de cluster entièrement provisionnée et gérée. 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 en mode Standard, vous déterminez la configuration nécessaire pour vos charges de travail de production.

Pour en savoir plus sur ces modes et sur Autopilot, consultez Modes de fonctionnement de GKE et la présentation d'Autopilot.

Vous trouverez un comparatif détaillé des deux modes dans Comparer GKE Standard et Autopilot.

Choix de configuration du cluster

Après avoir choisi un mode de fonctionnement, vous sélectionnez la configuration dont vous avez besoin pour votre cluster. Comme les clusters Autopilot sont plus entièrement gérés et configurés par Google Cloud que les clusters standards, ils offrent moins de choix de configuration.

Les options de configuration de tous les clusters se répartissent dans les catégories suivantes :

  • Nom et autres métadonnées : chaque cluster doit avoir un nom d'identification unique dans son projet. Vous pouvez également ajouter une description et des étiquettes au cluster.
  • Disponibilité et évolutivité : spécifiez l'emplacement où vous souhaitez que le plan de contrôle et les nœuds de votre cluster s'exécutent, et si vous souhaitez plusieurs instances répliquées du plan de contrôle. Tous les clusters Autopilot sont régionaux, ce qui signifie qu'ils disposent de plusieurs plans de contrôle dans plusieurs zones de calcul d'une région Google Cloud.
  • Appartenance au parc : indiquez si vous souhaitez que votre cluster soit membre d'un parc.
  • Mise en réseau : options de mise en réseau, y compris le réseau et le sous-réseau de cloud privé virtuel (VPC) dans lesquels se trouve le cluster, et si vous souhaitez que votre cluster soit accessible depuis les réseaux publics.
  • Gestion des versions et des mises à niveau : utilisez les canaux de publication pour choisir l'équilibre que vous préférez entre nouvelles fonctionnalités et stabilité lors de la mise à niveau du logiciel de ce cluster, et définissez des intervalles et des exclusions de maintenance pour choisir quand les mises à niveau peuvent et ne peuvent pas avoir lieu.
  • Sécurité : indique si le cluster utilise Workload Identity Federation for GKE et le compte de service utilisé par les nœuds du cluster pour s'authentifier auprès deGoogle Cloud.
  • Fonctionnalités du cluster : activez et configurez des fonctionnalités GKE etGoogle Cloud supplémentaires pour ce cluster, y compris les sauvegardes et l'observabilité. Le mode Standard vous permet également de créer des clusters alpha de courte durée pour tester les fonctionnalités alpha de Kubernetes.

En plus de ces options, les clusters standards disposent également d'options dans la catégorie suivante :

  • Pools de nœuds : spécifiez des détails sur les nœuds de votre cluster, y compris les pools de nœuds, le système d'exploitation des nœuds et le dimensionnement des nœuds.

Les sections suivantes examinent plus en détail certaines de ces catégories, en particulier celles dont les options ne peuvent pas être modifiées après la création du cluster. Pour obtenir la liste complète des options de configuration, consultez la documentation de référence sur la configuration.

Le tableau suivant compare les options disponibles dans certains domaines clés pour les clusters Autopilot et Standard :

Choix des clusters Mode
Autopilot Standard
Type de disponibilité Regional (Régional) Régionalou zonal
Canal de publication Rapide, Standard ou Stable Tous les canaux
Versions de cluster Par défaut ou une autre version disponible Par défaut ou une autre version disponible
le routage réseau. VPC natif VPC natif ou basé sur le routage
Isolation du réseau Personnalisable Personnalisable
Fonctionnalités de Kubernetes Production Production ou Alpha

Disponibilité du cluster

GKE vous permet de créer un cluster adapté aux exigences de disponibilité de votre charge de travail et à votre budget. Vous pouvez choisir entre des clusters régionaux comportant plusieurs instances répliquées du plan de contrôle dans plusieurs zones de calcul d'une région Google Cloud , ou des clusters zonaux avec un seul plan de contrôle dans une seule zone. Les clusters Autopilot sont toujours régionaux.

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

Ces paramètres ne peuvent pas être modifiés après la création du cluster : un cluster zonal ne peut pas devenir un cluster régional, et un cluster régional ne peut pas devenir un cluster zonal.

Bonne pratique:

Pour les charges de travail de production, utilisez des clusters régionaux, car ils offrent généralement une disponibilité plus élevée que les clusters zonaux. Pour les environnements de développement, utilisez des clusters régionaux avec des pools de nœuds zonaux. Un cluster avec un plan de contrôle régional et des pools de nœuds zonaux entraîne les mêmes coûts qu'un cluster zonal. Pour en savoir plus sur les considérations spécifiques à la région, consultez la page Zones géographiques et régions.

Clusters régionaux

Un cluster régional comporte plusieurs instances répliquées du plan de contrôle, qui s'exécutent dans différentes zones de la région Google Cloud spécifiée. Vous devez toujours spécifier une région lorsque vous créez un cluster Autopilot ou un autre cluster régional.

Pour les clusters standards régionaux uniquement, vous pouvez également choisir les zones dans lesquelles les nœuds du cluster s'exécutent. 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 dans trois zones de la région du plan de contrôle. Lorsque vous créez un cluster Standard régional ou que 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 sont exécutés. 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.

Vous ne pouvez pas modifier la région d'un cluster régional après sa création.

Cluster zonal

Les clusters zonaux possèdent un seul plan de contrôle dans une seule zone. Les charges de travail continuent de s'exécuter pendant la mise à niveau d'un cluster ou en cas d'indisponibilité de la zone où le plan de contrôle s'exécute. 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. Selon les exigences de disponibilité de votre charge de travail, 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, consultez Créer un cluster zonal.

Emplacement et distribution des nœuds

Que vous utilisiez des clusters régionaux ou zonaux, vous pouvez déterminer précisément l'emplacement et la distribution de vos nœuds dans les zones. Vous pouvez configurer les zones par défaut pour tous les futurs pools de nœuds, et attribuer ou modifier les zones spécifiques des nœuds dans les pools de nœuds existants.

Clusters à zone unique

Un cluster à zone unique (qui peut être un cluster régional ou zonal) exécute des charges de travail sur des nœuds situés dans une seule zone. Si cette zone subit une panne, toutes les charges de travail deviennent indisponibles.

Les clusters zonaux sont créés par défaut en tant que clusters à zone unique, mais vous pouvez modifier cette configuration pour en faire des clusters multizonaux.

Clusters multizones

Un cluster multizone (qui peut être un cluster régional ou zonal) améliore la disponibilité des charges de travail en répartissant les nœuds sur plusieurs zones d'une même région. Cela vous permet d'exécuter des charges de travail dans plusieurs zones d'une région. 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.

La distribution de nœuds GKE sur plusieurs zones peut entraîner des frais de sortie réseau interzone lorsque les nœuds doivent communiquer avec des pairs situés dans une autre zone de la région.

Les clusters régionaux sont créés par défaut en tant que clusters multizones, mais vous pouvez modifier cette configuration pour en faire des clusters à zone unique.

Zones d'IA

Les zones d'IA sont des zones spécialisées utilisées pour les charges de travail d'entraînement et d'inférence d'IA/de ML. Ces zones offrent une capacité d'accélérateur de ML importante. Pour en savoir plus, consultez la documentation sur les zones d'IA.

Dans ce document et dans la documentation GKE, les termes "zones standards" ou "zones" font référence aux zones non-IA d'une région Google Cloud .

Avant d'utiliser une zone d'IA dans GKE, tenez compte des caractéristiques suivantes :

  • Pour utiliser une zone d'IA avec des clusters GKE existants, votre plan de contrôle doit exécuter la version 1.36.4-gke.1495002 ou ultérieure, ou la version 1.37.1-gke.1552000 ou ultérieure. Ces versions permettent au plan de contrôle de reconnaître la zone et d'enregistrer les nœuds. Si votre plan de contrôle exécute la version 1.35 ou une version antérieure, ou une version antérieure à ces versions minimales, mettez à niveau le plan de contrôle avant de créer des pools de nœuds dans la zone IA. Si la mise à niveau n'est pas possible, contactez Cloud Customer Care.
  • Les zones d'IA sont physiquement séparées des zones standards pour fournir un espace de stockage et une puissance supplémentaires. Cette séparation peut entraîner une latence plus élevée, ce qui est généralement tolérable pour les charges de travail d'IA/de ML.
  • Les zones d'IA ont un suffixe avec la notation ai. Par exemple, une zone d'IA située dans la région us-central1 est nommée us-central1-ai1a.
  • Actuellement, seules les VM TPU sont compatibles.
  • Le plan de contrôle du cluster s'exécute dans une ou plusieurs zones standards de la même région que la zone IA.

  • Vous ne pouvez exécuter des VM sans TPU associé dans une zone d'IA que si vous remplissez les conditions suivantes :

    • Vous exécutez déjà d'autres charges de travail qui utilisent des VM TPU dans la même zone.
    • Les VM non-TPU sont soit des VM Spot, liées à une réservation, soit des VM faisant partie d'un pool de nœuds avec un ratio spécifique de VM à usage général par rapport aux VM optimisées pour les accélérateurs.

  • Les zones d'IA partagent des composants, tels que les connexions réseau et les déploiements logiciels, avec les zones standards qui ont le même suffixe dans la même région. Pour les charges de travail à haute disponibilité, nous vous recommandons d'utiliser différentes zones. Par exemple, évitez d'utiliser à la fois us-central1-ai1a et us-central1-a pour la haute disponibilité.

Par défaut, GKE ne déploie pas vos charges de travail dans les zones d'IA. Pour utiliser une zone d'IA, vous devez configurer l'une des options suivantes :

  • (Recommandé) ComputeClasses : définissez votre priorité la plus élevée pour demander des TPU à la demande dans une zone d'IA. Les ComputeClasses vous aident à définir une liste prioritaire de configurations matérielles pour vos charges de travail. Pour obtenir un exemple, consultez À propos des ComputeClasses.
  • Provisionnement automatique des nœuds : utilisez un nodeSelector ou un nodeAffinity dans la spécification de votre pod pour indiquer au provisionnement automatique des nœuds de créer un pool de nœuds dans la zone d'IA. Si votre charge de travail ne cible pas explicitement une zone d'IA, le provisionnement automatique des nœuds ne prend en compte que les zones standards ou les zones de --autoprovisioning-locations lors de la création de pools de nœuds. Cette configuration permet de s'assurer que les charges de travail qui n'exécutent pas de modèles d'IA/ML restent dans des zones standards, sauf si vous configurez explicitement le contraire. Pour obtenir un exemple de fichier manifeste utilisant un nodeSelector, consultez Définir les zones par défaut pour les nœuds créés automatiquement.
  • GKE Standard : si vous gérez directement vos pools de nœuds, utilisez une zone d'IA dans l'option --node-locations lorsque vous créez un pool de nœuds. Pour obtenir un exemple, consultez Déployer des charges de travail TPU dans GKE Standard.

Appartenance à un parc

Si votre organisation utilise plusieurs clusters, vous pouvez simplifier la gestion multicluster en ajoutant les clusters à un parc, qui est un regroupement logique de clusters Kubernetes. La création d'un parc facilite la gestion de votre entreprise avec des groupes de clusters plutôt que des clusters individuels, et vous permet d'utiliser des fonctionnalités spécifiques aux parcs comme Multi Cluster Ingress, Config Sync et Policy Controller.

Bien que vous puissiez ajouter des clusters à un parc à tout moment, nous vous recommandons vivement d'enregistrer les nouveaux clusters dans un parc lors de leur création. En effet, ces clusters "nés dans le parc" sont créés avec les paramètres par défaut que vous avez choisis au niveau du parc pour un certain nombre de fonctionnalités d'entreprise, et avec les journaux et les métriques recommandés déjà activés. Pour en savoir plus à ce sujet, consultez les guides suivants :

Ce paramètre peut être mis à jour après la création du cluster pour l'enregistrer ou annuler son enregistrement, bien que nous ne recommandions pas de déplacer des clusters avec des charges de travail actives d'un parc à un autre.

Pour en savoir plus sur l'ajout de clusters à des parcs, consultez Créer des parcs pour simplifier la gestion multicluster.

Paramètres de mise en réseau

Lorsque vous créez un cluster GKE, vous pouvez spécifier un certain nombre de paramètres réseau, y compris le réseau dans lequel se trouve le cluster, le mode de routage réseau et si vous souhaitez que les nœuds de votre cluster soient accessibles depuis des réseaux publics.

Si vous n'êtes pas administrateur réseau, vous devez consulter les spécialistes Mise en réseau de votre organisation avant de créer un cluster prêt pour la production, car bon nombre de ces options ne peuvent pas être modifiées après la création du cluster. Si vous êtes administrateur réseau, vous pouvez en savoir plus sur la mise en réseau GKE dans À propos de la mise en réseau GKE, avec les bonnes pratiques pour les options de mise en réseau dans Bonnes pratiques pour la mise en réseau GKE. Cette section ne décrit qu'un sous-ensemble de nos options de mise en réseau possibles.

Réseau et sous-réseau

Le réseau de cloud privé virtuel (VPC) dans lequel se trouve un cluster détermine avec quelles autres ressources Compute Engine il peut communiquer. Par défaut, les clusters GKE sont créés dans le réseau par défaut de votre projet, mais vous pouvez choisir un autre réseau si vous ou votre administrateur en avez créé un. Si possible, vous pouvez spécifier que vous souhaitez que votre cluster appartienne à un sous-réseau VPC spécifique. Sinon, le sous-réseau par défaut est utilisé. Vous pouvez également spécifier que vous souhaitez utiliser une plage d'adresses IP particulière dans ce sous-réseau pour vos pods et vos services.

Ces paramètres ne peuvent pas être modifiés après la création du cluster.

Choix concernant l'isolation du réseau

Vous pouvez personnaliser l'isolation du réseau dans votre cluster en tenant compte des deux aspects suivants :

  • Accès au plan de contrôle : par défaut, les points de terminaison interne et externe du plan de contrôle sont activés, et le point de terminaison basé sur le DNS est désactivé. Vous pouvez choisir les options suivantes :

    • Désactivez les points de terminaison externe et interne, et n'utilisez que le point de terminaison DNS.
    • Désactivez le point de terminaison externe uniquement pour empêcher l'accès aux clients externes.
    • Activez les réseaux autorisés pour contrôler les adresses IP qui atteignent les points de terminaison du plan de contrôle.

  • Configuration de la mise en réseau du cluster : vous pouvez choisir d'activer les nœuds privés dans votre cluster pour isoler complètement les charges de travail des réseaux publics. Vous pouvez activer les nœuds privés pour des clusters entiers, ou au niveau du pool de nœuds (pour Standard) ou de la charge de travail (pour Autopilot). L'activation des nœuds privés au niveau du pool de nœuds ou de la charge de travail remplace toute configuration de nœud au niveau du cluster.

Ces paramètres peuvent être modifiés après la création du cluster.

Pour en savoir plus sur l'isolation du réseau, consultez À propos de la personnalisation de l'isolation du réseau et Personnaliser l'isolation de votre réseau.

Bonne pratique:

Utilisez Cloud NAT pour fournir aux pods GKE un accès aux ressources avec des adresses IP publiques. Cloud NAT améliore la stratégie de sécurité globale du cluster, car les pods ne sont pas directement exposés à Internet, mais peuvent toujours accéder aux ressources Web.

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

GKE comprend deux types de clusters, caractérisés par la manière dont ils acheminent le trafic d'un pod à un autre. Un cluster dans lequel les adresses IP des pods sont nativement routables au sein du réseau VPC sans utiliser de routes statiques personnalisées est appelé cluster de VPC natif. Dans les clusters IPv4 et à double pile, GKE utilise des adresses IP d'alias. Dans les clusters IPv6 à pile unique, GKE alloue des adresses directement à partir du sous-réseau sans plages d'adresses IP d'alias. En revanche, un cluster qui utilise des routesGoogle Cloud est appelé cluster basé sur le routage.

Par défaut, tous les nouveaux clusters GKE utilisent le routage de VPC natif, qui est l'option recommandée. Vous pouvez modifier ce paramètre lors de la création du cluster pour créer un cluster basé sur le routage en mode Standard uniquement. Ce paramètre ne peut pas être modifié après la création du cluster.

Pour en savoir plus sur les clusters de VPC natif et leurs avantages, y compris les exigences particulières qui s'appliquent, consultez la page Clusters de VPC natif.

Bonne pratique:

Utilisez le mode réseau VPC natif pour vos clusters. Il s'agit de la valeur par défaut pour les clusters Autopilot.

Versions et mises à jour

Avec les canaux de publication, GKE choisit des versions logicielles pour un cluster, en vous offrant un équilibre entre disponibilité des fonctionnalités et stabilité. Lorsque vous créez un cluster, vous pouvez choisir le version disponible de votre choix. Les nouveaux clusters (Autopilot et Standard) sont enregistrés par défaut dans le canal de publication standard. Toutefois, vous pouvez choisir une version spécifique lors de la création du cluster si nécessaire.

Les clusters Autopilot utilisent toujours les canaux de publication. Les clusters Standard utilisent les canaux de publication par défaut, mais vous pouvez choisir de ne pas enregistrer votre cluster dans un version disponible (bien que nous ne le recommandions pas, car ce paramètre vous donne un accès plus limité aux fonctionnalités du cluster).

GKE met automatiquement à niveau tous les clusters au fil du temps, quel que soit l'enregistrement du version disponible. GKE met automatiquement à niveau le plan de contrôle du cluster et ses nœuds à mesure que de nouvelles versions sont disponibles dans ce version disponible. Vous pouvez contrôler le calendrier et le champ d'application des mises à niveau à l'aide des intervalles et exclusions de maintenance.

Vous pouvez modifier le version disponible d'un cluster à tout moment.

Pour en savoir plus sur les prochaines mises à niveau automatiques, consultez les notes de version de GKE.

Bonne pratique:

Choisissez un canal de publication pour GKE afin de sélectionner des versions pour votre cluster, en trouvant un équilibre approprié entre disponibilité des fonctionnalités et stabilité. Utilisez des intervalles de maintenance et des exclusions pour contrôler le calendrier et le champ d'application des mises à niveau automatiques.

Fonctionnalités alpha (clusters Standard uniquement)

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 Kubernetes listées comme bêta ou stables sont incluses dans les clusters GKE.

Si vous souhaitez tester de nouvelles fonctionnalités qui ne sont pas prêtes pour la production, les fonctionnalités alpha sont disponibles dans des clusters alpha GKE spéciaux. Toutes les API alpha de Kubernetes (parfois appelées "feature gates") sont activées sur un cluster alpha. 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, ne peuvent pas être mis à niveau ni ajoutés aux canaux de publication, et expirent au bout de 30 jours.

Les fonctionnalités alpha ne sont pas disponibles pour les clusters Autopilot.

Pour créer un cluster alpha, consultez Créer un cluster alpha.

Paramètres de sécurité

GKE dispose d'un certain nombre de paramètres de sécurité que vous pouvez spécifier lors de la création du cluster. Il s'agit notamment des paramètres de chiffrement, des fonctionnalités de sécurité telles que l'autorisation binaire, du compte de service que vous souhaitez utiliser pour les nœuds du cluster (abordé plus en détail dans la section suivante) et de l'utilisation ou non de Workload Identity Federation for GKE par votre cluster.

Comme pour les autres paramètres, vous devez consulter des collègues experts (dans ce cas, les spécialistes de la sécurité de votre organisation) avant de créer un cluster prêt pour la production. Pour en savoir plus sur la sécurité de GKE, consultez notre Présentation de la sécurité et la page Renforcer la sécurité d'un cluster.

Compte de service pour les nœuds

GKE utilise des comptes de service IAM associés à vos nœuds pour exécuter des tâches système telles que la journalisation et la surveillance. Au minimum, ces comptes de service de nœud doivent disposer du rôle Compte de service de nœud par défaut Kubernetes Engine (roles/container.defaultNodeServiceAccount) sur votre projet. Par défaut, GKE utilise le compte de service Compute Engine par défaut, qui est créé automatiquement dans votre projet, en tant que compte de service de nœud.

Si votre organisation applique la contrainte de règle d'administration iam.automaticIamGrantsForDefaultServiceAccounts, il est possible que le compte de service Compute Engine par défaut de votre projet n'obtienne pas automatiquement les autorisations requises pour GKE.

Si vous utilisez le compte de service Compute Engine par défaut pour d'autres fonctions de votre projet ou de votre organisation, il se peut que ce compte de service dispose de plus d'autorisations que nécessaire pour GKE, ce qui pourrait vous exposer à des risques de sécurité.

Vous ne pouvez pas modifier le compte de service des clusters en mode Autopilot ou des pools de nœuds en mode Standard après leur création.

Paramètres du pool de nœuds (clusters standards uniquement)

Comme vous le savez d'après la présentation de l'administration des clusters et les modes de fonctionnement de GKE, si vous utilisez Autopilot pour vos clusters, vous n'avez pas à vous soucier de la configuration des nœuds, car GKE configure vos nœuds pour vous. Les nœuds de cluster Autopilot sont tous entièrement gérés par GKE et utilisent tous le même système d'exploitation (OS) de nœud.

Si vous choisissez de créer un cluster Standard, vous pouvez spécifier un certain nombre d'options de nœud lors de la création du cluster, y compris :

  • Le nom, le nombre, la taille et l'emplacement des pools de nœuds que vous souhaitez utiliser. Les pools de nœuds sont des groupes de nœuds au sein de votre cluster qui partagent une configuration commune.
  • OS de nœud que vous souhaitez utiliser pour les nouveaux nœuds.
  • Si vous souhaitez utiliser des VM Spot éphémères pour les nœuds.
  • Type de machine Compute Engine que vous souhaitez utiliser pour les nœuds.
  • Le compte de service que vous souhaitez utiliser pour les nœuds, comme décrit dans Paramètres de sécurité.

Certains paramètres du pool de nœuds d'un cluster peuvent être modifiés après la création du cluster, bien que tous les clusters standards nécessitent au moins un pool de nœuds. Si vous ne spécifiez pas de nombre de nœuds ni de type de machine lors de la création d'un cluster Standard, son pool de nœuds par défaut se compose de trois nœuds dans chacune des zones du cluster, avec l'image de nœud par défaut cos_containerd et un type de machine à usage général.

Pour en savoir plus sur la configuration des pools de nœuds, consultez À propos des pools de nœuds et Ajouter et gérer des pools de nœuds.

Documentation de référence sur la configuration

Vous trouverez la liste complète des options de configuration possibles dans les guides de référence suivants :

Étapes suivantes