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.
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.
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 et Google Cloud.
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 : régional et zonal (zone unique ou multizones).
Les clusters créés en mode Autopilot sont régionaux.
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 régional à zonal, ou de zonal à régional. À la place, vous devez créer un autre cluster, puis transférer le trafic vers celui-ci.
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.
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.
Pour les charges de travail de production, utilisez des clusters régionaux, car ils offrent 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 aux mêmes coûts.
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.
Canaux de publication et versions de cluster
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.
Avec les canaux de publication, GKE choisit des versions 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. Les nouveaux clusters sont enregistrés par défaut dans le canal de publication standard. Si nécessaire, vous pouvez également choisir une version spécifique.
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.
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 lorsqu'une mise à niveau est disponible 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.
Pour en savoir plus sur les prochaines mises à niveau automatiques, consultez les notes de version de GKE.
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.
Pour en savoir plus, consultez le tableau Mode de réseau du cluster par défaut.
Utilisez le mode réseau VPC natif pour vos clusters. Il s'agit de la valeur par défaut pour les clusters créés en mode Autopilot.
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é.
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.
Caractéristiques 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.
Les fonctionnalités alpha ne sont pas disponibles dans les clusters créés en mode Autopilot.
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.