Types de clusters

Cette page décrit les principaux types de clusters que vous pouvez créer 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, qu'il s'agisse d'un cluster de VPC natif ou basé sur le routage. Ils affectent également l'l'isolation du réseau.

Pour en savoir plus et pour vous aider à choisir entre différents types de cluster, reportez-vous à la section Choisir un plan de contrôle régional ou zonal.

Choix concernant la 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.

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, 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.

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.

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 s'exécutent également dans chaque zone dans laquelle s'exécute une instance dupliquée du plan de contrôle. Dans la mesure où un cluster régional réplique le plan de contrôle et les nœuds, il consomme davantage de ressources Compute Engine qu'un cluster analogue à zone unique ou multizones.

Vous pouvez créer un cluster régional.

Choix concernant la 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.

Version disponible

Si vous connaissez le niveau de stabilité requis pour un cluster donné, vous pouvez enregistrer ce cluster dans une version disponible. Google met automatiquement à jour le cluster et ses nœuds lorsqu'une mise à jour est disponible pour cette version. La version précoce reçoit plusieurs mises à jour par mois, tandis que la version stable ne reçoit que quelques mises à jour par an.

Vous pouvez enregistrer un cluster dans une version disponible.

Version par défaut

Si vous n'utilisez pas une version disponible ou si ne vous choisissez pas de version de 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. 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.

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.

Vous pouvez créer un cluster avec une version spécifique.

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.

Vous pouvez créer un cluster alpha.

Options de 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.

Le mode réseau par défaut du cluster dépend de la façon dont le cluster est créé. 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.

Vous pouvez créer un cluster privé.

Sécurité sur la chaîne d'approvisionnement de la charge de travail

L'autorisation binaire est une fonctionnalité de la plate-forme Anthos. Elle assure la sécurité sur la chaîne d'approvisionnement logicielle de vos charges de travail GKE. L'autorisation binaire fonctionne avec les images que vous déployez dans GKE à partir de Container Registry ou d'un autre registre d'images de conteneurs. Avec l'autorisation binaire, vous pouvez vous assurer que les processus internes protégeant la qualité et l'intégrité de vos logiciels se sont bien terminés avant de déployer une application dans votre environnement de production.

Pour en savoir plus, consultez la section Créer un cluster avec l'autorisation binaire activée dans la documentation sur l'autorisation binaire.