À 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 console Google 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, que le cluster soit accessible depuis des réseaux publics ou la manière dont vous souhaitez qu'il reçoive les mises à niveau de version.

De nombreuses options abordées dans ce guide ne peuvent pas être modifiées après la création d'un cluster. Il s'agit notamment des choix qui affectent la disponibilité et le réseau d'un cluster. Si vous devez modifier ces options, vous devez créer un cluster, puis y migrer le trafic, 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 architectes cloud, les administrateurs réseau ou toute autre équipe chargée de définir, implémenter et 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 la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

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

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, ainsi que les choix de configuration du 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 gérée et provisionné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 pour en savoir plus sur Autopilot, consultez les pages Modes de fonctionnement de GKE et Présentation d'Autopilot.

Vous trouverez une comparaison détaillée des deux modes dans Comparer GKE Standard et Autopilot.

Choix de configuration du cluster

Après avoir 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 gérés et configurés plus complètement par Google Cloud que les clusters standards, ils disposent de 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 libellés au cluster.
  • 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éplicas 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 dans une région Google Cloud.
  • Appartenance à un 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 VPC (cloud privé virtuel) dans lesquels se trouve le cluster, et si vous souhaitez que votre cluster soit accessible depuis des réseaux publics.
  • Gestion des versions et 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, 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 proposent également les options suivantes:

  • 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 la taille des nœuds.

Les sections suivantes examinent certaines de ces catégories plus en détail, en particulier celles pour lesquelles vous ne pouvez pas modifier le paramètre après avoir créé votre 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 Rapide, Standard ou Stable Toute chaîne
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

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. Vous pouvez choisir entre des clusters régionaux comportant plusieurs réplicas du plan de contrôle dans plusieurs zones de calcul d'une même Google Cloud région 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 la section Choisir un plan de contrôle régional ou zonal.

Ces paramètres ne peuvent pas être mis à jour une fois le cluster créé: 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 a les mêmes coûts qu'un cluster zonal. Pour en savoir plus sur les considérations spécifiques à chaque région, consultez la section 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 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 sur trois zones de la région du plan de contrôle. Lorsque vous créez un cluster standard 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 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 créé, vous ne pouvez plus modifier sa région.

Clusters zonaux (clusters standards uniquement)

Les clusters zonaux possèdent un seul plan de contrôle dans une seule zone. Selon vos 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 la section 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.

Niveau de cluster

Comme vous le savez, GKE propose deux niveaux de fonctionnalités: un niveau standard disponible pour tous les utilisateurs de GKE et un niveau entreprise qui ajoute des fonctionnalités puissantes pour travailler à grande échelle, dont beaucoup reposent sur la gestion de parc GKE.

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

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

  • De nombreuses fonctionnalités de GKE Enterprise nécessitent d'être membre d'un parc pour fonctionner. Vous pouvez enregistrer un cluster dans un parc lors de sa création ou après l'avoir créé. Si vous souhaitez utiliser les fonctionnalités de GKE Enterprise activées au niveau du parc avec un cluster, nous vous recommandons d'enregistrer le cluster dans un parc lors de sa création, car il héritera des paramètres au niveau du parc pour les fonctionnalités d'entreprise. Pour en savoir plus, consultez la section 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.

Ce paramètre peut être modifié 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'appartenance à 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 de nouveaux clusters de niveau entreprise 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, consultez les guides suivants:

Ce paramètre peut être mis à jour après la création du cluster pour l'enregistrer ou l'annuler, 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 la section 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 sur 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 des réseaux publics.

Si vous n'êtes pas administrateur réseau, consultez les spécialistes de la 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, et découvrir 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 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 sur 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. Le cas échéant, vous pouvez spécifier que votre cluster doit appartenir à 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 après la création du cluster.

Choix concernant l'isolation du réseau

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

  • Accès au plan de contrôle: par défaut, le point de terminaison interne et le point de terminaison 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 le point de terminaison externe et le point de terminaison 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 des 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 de 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 réseau, consultez les pages À propos de la personnalisation de l'isolation réseau et Personnaliser l'isolation 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 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 mis à jour après la création du cluster.

Pour en savoir plus sur les clusters de VPC natif et leurs avantages, y compris les exigences spéciales qu'ils présentent, 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 canal de publication de votre choix. Par défaut, les nouveaux clusters (Autopilot et Standard) sont enregistrés 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 canal de publication (bien que nous ne vous recommandions pas de le faire, 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 canal de publication. GKE met automatiquement à niveau le plan de contrôle du cluster et ses nœuds lorsque de nouvelles versions sont disponibles dans ce canal de publication. 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 canal de publication 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 version Stable sont incluses avec des clusters GKE.

Si vous souhaitez tester de toutes nouvelles fonctionnalités qui ne sont pas encore prêtes pour la production, les 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 à des 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 la section 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 d'un 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 (décrit plus en détail dans la section suivante) et de l'utilisation de la fédération d'identité de charge de travail pour 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 à la production. Pour en savoir plus sur la sécurité de GKE, consultez notre 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. Ces comptes de service de nœud doivent au minimum 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, comme compte de service de nœud.

Si votre organisation applique la contrainte de règle d'administration iam.automaticIamGrantsForDefaultServiceAccounts, le compte de service Compute Engine par défaut de votre projet risque de ne pas recevoir automatiquement les autorisations requises pour GKE.

Si vous utilisez le compte de service par défaut de Compute Engine pour d'autres fonctions de votre projet ou de votre organisation, il est possible que le compte de service dispose d'autorisations supérieures aux besoins de 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 ni des pools de nœuds en mode Standard après leur création.

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

Comme indiqué dans la présentation de l'administration de clusters et dans la section 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 à votre place. 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œuds, y compris les suivantes:

  • Nom, nombre, taille et emplacement des pools de nœuds que vous souhaitez utiliser. Il s'agit de groupes de nœuds au sein de votre cluster qui partagent une configuration commune.
  • L'OS de 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.
  • 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 la section Paramètres de sécurité.

Certains paramètres de 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 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 les pages À 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:

Étape suivante