À 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 , 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 décrites 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 d'un cluster. Si vous devez modifier ces options, vous devez créer un autre cluster, puis y migrer le trafic, ce qui peut être perturbant.

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 architectes cloud, 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 Enterprise.

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 d'aborder les 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, ainsi que les choix de configuration de cluster à 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 à l'aide du 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.

Pour obtenir une comparaison détaillée des deux modes, consultez Comparer GKE Standard et Autopilot.

Choix de configuration du cluster

Une fois que vous avez choisi un mode de fonctionnement, vous devez ensuite sélectionner la configuration dont vous avez besoin pour votre cluster. Étant donné que les clusters Autopilot sont plus entièrement gérés et configurés par Google Cloud que les clusters Standard, ils offrent moins de choix de configuration.

Les options de configuration de tous les clusters sont réparties 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 libellés au cluster, si vous le souhaitez.
  • Disponibilité et évolutivité : spécifiez où vous souhaitez exécuter le plan de contrôle et les nœuds de votre cluster, et si vous souhaitez plusieurs répliques de plan de contrôle. Tous les clusters Autopilot sont régionaux, ce qui signifie qu'ils comportent plusieurs plans de contrôle sur 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.
  • Versions et gestion des mises à niveau : utilisez les canaux de publication pour choisir l'équilibre souhaité entre les nouvelles fonctionnalités et la stabilité lors de la mise à niveau du logiciel de ce cluster. 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 la fédération d'identité de charge de travail pour 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 celles-ci, les clusters standards proposent également des options dans la catégorie suivante :

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

Les sections suivantes examinent certaines de ces catégories plus en détail, 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
Version disponible Rapid, Standard ou Stable Toutes les chaînes
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 qui comportent plusieurs répliques de 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.

Vous ne pouvez pas modifier ces paramètres une fois le cluster créé : un cluster zonal ne peut pas devenir un cluster régional, et inversement.

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 a les mêmes coûts qu'un cluster zonal. Pour en savoir plus sur les considérations spécifiques à la région, consultez Zones géographiques et régions.

Clusters régionaux

Un cluster régional comporte plusieurs instances dupliquées du plan de contrôle, qui s'exécutent dans plusieurs zones de la Google Cloud région que vous avez 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 régionaux standards 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 sur trois zones de la région du plan de contrôle. Lorsque vous créez un cluster Standard régional 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.

Une fois le cluster régional créé, vous ne pouvez plus modifier sa région.

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 lors d'une mise à niveau du cluster ou d'une panne de la zone dans laquelle s'exécute le plan de contrôle. 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 vos exigences de disponibilité des charges 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 répartition de vos nœuds dans les zones. Vous pouvez configurer les zones par défaut pour tous les futurs pools de nœuds, ainsi qu'attribuer ou modifier les zones spécifiques pour les 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 connaît 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 les transformer en clusters multizones.

Clusters multizones

Un cluster multizone (qui peut être un cluster régional ou zonal) améliore la disponibilité des charges de travail en distribuant 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 des 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 les transformer en clusters à zone unique.

Niveau de cluster

Comme vous le savez grâce aux éditions GKE, GKE propose deux niveaux de fonctionnalités : un niveau standard disponible pour tous les utilisateurs GKE et un niveau Enterprise qui ajoute des fonctionnalités puissantes pour travailler à l'échelle de l'entreprise, dont beaucoup s'appuient sur la gestion de parc GKE.

Pour les clusters GKE sur Google Cloud, vous pouvez choisir d'ajouter le niveau de fonctionnalités supplémentaires pour chaque cluster. Une fois qu'un cluster est inscrit au niveau GKE Enterprise, vous êtes autorisé à utiliser toutes les fonctionnalités Enterprise disponibles avec celui-ci. Si vous ne spécifiez pas de niveau de cluster, le cluster utilise le niveau standard par défaut, avec certaines exceptions.

Assurez-vous de comprendre les points suivants lorsque vous sélectionnez le niveau de votre cluster :

  • Pour que de nombreuses fonctionnalités de GKE Enterprise fonctionnent, vous devez être membre d'un parc. Vous pouvez enregistrer un cluster dans un parc lors de sa création ou après l'avoir créé. Si vous souhaitez utiliser des fonctionnalités GKE Enterprise compatibles avec les parcs avec un cluster, nous vous recommandons d'enregistrer le cluster dans un parc lors de sa création. Cela signifie que le cluster héritera des paramètres au niveau du parc pour les fonctionnalités Enterprise. Pour en savoir plus, consultez Appartenance à un parc.
  • Vous ne pouvez activer le niveau Enterprise pour un cluster que si l'API GKE Enterprise (Anthos) est activée dans le projet du cluster.

Vous pourrez modifier ce paramètre après la création du cluster.

Pour en savoir plus sur les fonctionnalités incluses dans GKE Enterprise, y compris le sous-ensemble de fonctionnalités qui ne nécessitent pas d'appartenir à un parc, consultez les options de déploiement de GKE Enterprise.

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, si vous avez activé GKE Enterprise, nous vous recommandons vivement d'enregistrer les nouveaux clusters de niveau Enterprise dans un parc lors de leur création. En effet, ces clusters "créés dans le parc" sont créés avec les paramètres par défaut au niveau du parc que vous avez choisis pour un certain nombre de fonctionnalités Enterprise, et avec les journaux et métriques recommandés déjà activés. Pour en savoir plus, consultez les guides suivants :

Ce paramètre peut être mis à jour après la création du cluster pour enregistrer ou annuler l'enregistrement du cluster. Toutefois, nous vous déconseillons de déplacer des clusters avec des charges de travail en direct 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 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 du réseau et si vous souhaitez que les nœuds de votre cluster soient accessibles depuis les 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 la plupart de ces options ne peuvent pas être modifiées après la création du cluster. Si vous êtes administrateur réseau, vous trouverez de nombreuses informations sur la mise en réseau GKE dans À propos de la mise en réseau GKE, ainsi que des 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 réseau possibles.

Réseau et sous-réseau

Le réseau 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. Toutefois, vous pouvez choisir un autre réseau si vous ou votre administrateur en avez créé un. Si disponible, 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 services.

Vous ne pourrez plus modifier ces paramètres une fois le cluster créé.

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 un DNS est désactivé. Vous pouvez choisir les options suivantes :

    • Désactivez les points de terminaison externes et internes, 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 le mode Standard) ou de la charge de travail (pour le mode 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 qui s'appuie sur des adresses IP d'alias est appelé cluster de VPC natif. 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 VPC natif, qui est l'option que nous recommandons. 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 sur les exigences spécifiques, consultez 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 limite l'accès 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 lorsque 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 et des exclusions de maintenance pour contrôler le calendrier et le champ d'application des mises à niveau automatiques.

Fonctionnalités alpha (clusters standards 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 de Kubernetes répertoriées en tant que version bêta ou stable sont incluses avec les clusters GKE.

Si vous souhaitez tester des fonctionnalités très récentes qui ne sont pas encore prêtes pour la production, des fonctionnalités alpha sont disponibles dans des clusters alpha GKE spéciaux. 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 à niveau ni ajoutés aux canaux de publication, et ils 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 propose plusieurs paramètres de sécurité que vous pouvez spécifier lors de la création du cluster. Il s'agit, entre autres, des paramètres de chiffrement, des fonctionnalités de sécurité telles que Binary Authorization, du compte de service que vous souhaitez utiliser pour les nœuds du cluster (nous y reviendrons plus en détail dans la section suivante) et de la question de savoir si votre cluster utilise Workload Identity Federation for GKE.

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 nos pages Présentation de la sécurité et Renforcer la sécurité de votre 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 dans votre projet ou votre organisation, il est possible qu'il dispose de plus d'autorisations que nécessaire pour GKE, ce qui peut vous exposer à des risques de sécurité.

Vous ne pouvez pas modifier le compte de service pour les clusters en mode Autopilot ni pour les 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 grâce à la Présentation de l'administration des clusters et aux 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 les configure pour vous. Les nœuds des clusters Autopilot sont tous entièrement gérés par GKE et utilisent tous le même système d'exploitation des nœuds.

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 d'un 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 du nœud que vous souhaitez utiliser pour les nouveaux nœuds.
  • Indique si vous souhaitez utiliser des VM Spot éphémères pour les nœuds.
  • Le type de machine Compute Engine que vous souhaitez utiliser pour les nœuds.
  • Compte de service que vous souhaitez utiliser pour les nœuds, comme décrit dans Paramètres de sécurité.

Vous pouvez modifier certains paramètres de pool de nœuds d'un cluster après la création du cluster, mais tous les clusters Standard nécessitent au moins un pool de nœuds. Si vous ne spécifiez pas le nombre de nœuds ni le type de machine lorsque vous créez 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