Créer un cluster de VPC natif

Cette page explique comment configurer des clusters de VPC natif dans Google Kubernetes Engine (GKE).

Pour en savoir plus sur les avantages et les exigences des clusters de VPC natif, consultez la section Clusters de VPC natif.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Configurez les paramètres gcloud par défaut à l'aide de l'une des méthodes suivantes :

  • Utilisez gcloud init pour suivre les instructions permettant de définir les paramètres par défaut.
  • Utilisez gcloud config pour définir individuellement l'ID, la zone et la région de votre projet.

Utiliser gcloud init

Si le message d'erreur One of [--zone, --region] must be supplied: Please specify location s'affiche, effectuez les tâches ci-dessous.

  1. Exécutez gcloud init et suivez les instructions :

    gcloud init

    Si vous utilisez SSH sur un serveur distant, utilisez l'option --console-only pour empêcher la commande d'ouvrir un navigateur :

    gcloud init --console-only
  2. Suivez les instructions pour autoriser gcloud à utiliser votre compte Google Cloud.
  3. Créez ou sélectionnez une configuration.
  4. Choisissez un projet Google Cloud.
  5. Choisissez une zone Compute Engine par défaut.

Utiliser gcloud config

  • Définissez votre ID de projet par défaut :
    gcloud config set project project-id
  • Si vous travaillez avec des clusters zonaux, définissez votre zone de calcul par défaut :
    gcloud config set compute/zone compute-zone
  • Si vous utilisez des clusters régionaux, définissez votre région de calcul par défaut :
    gcloud config set compute/region compute-region
  • Mettez à jour gcloud vers la dernière version :
    gcloud components update

Procédures

Procédez comme suit pour créer un cluster de VPC natif et vérifier la configuration des plages d'adresses IP réservées aux pods et aux services.

Créer un cluster dans un sous-réseau existant

Les instructions suivantes décrivent comment créer un cluster GKE de VPC natif dans un sous-réseau existant à l'aide de la méthode d'attribution de plages secondaires de votre choix.

gcloud

  • Pour utiliser une méthode d'attribution de plages secondaires gérée par GKE :

    gcloud container clusters create cluster-name \
      --region=region \
      --enable-ip-alias \
      --subnetwork=subnet-name \
      --cluster-ipv4-cidr=pod-ip-range \
      --services-ipv4-cidr=services-ip-range
    
  • Pour utiliser une méthode d'attribution de plages secondaires gérée par l'utilisateur :

    gcloud container clusters create cluster-name \
      --region=region \
      --enable-ip-alias \
      --subnetwork=subnet-name \
      --cluster-secondary-range-name=secondary-range-pods \
      --services-secondary-range-name=secondary-range-services
    

Remplacez les espaces réservés par des valeurs valides :

  • cluster-name correspond au nom du cluster GKE.
  • region correspond à la région dans laquelle le cluster est créé. Pour créer un cluster zonal, remplacez cette option par --zone=zone, où zone correspond à une zone Google Cloud.
  • subnet-name correspond au nom d'un sous-réseau existant. La plage d'adresses IP principale du sous-réseau est utilisée par les nœuds. Le sous-réseau doit exister dans la même région que celle utilisée par le cluster. S'il est omis, GKE tente d'utiliser un sous-réseau dans le réseau VPC default de la région du cluster.
  • Si la méthode d'attribution de plages secondaires est gérée par GKE :
    • pod-ip-range correspond à une plage d'adresses IP au format CIDR (par exemple, 10.0.0.0/14) ou à la taille du masque de sous-réseau d'un bloc CIDR (par exemple, /14). Cela permet de créer la plage d'adresses IP secondaire du sous-réseau utilisée par les pods.
    • services-ip-range correspond à une plage d'adresses IP au format CIDR (par exemple, 10.4.0.0/19) ou à la taille du masque de sous-réseau d'un bloc CIDR (par exemple, /19). Cela permet de créer la plage d'adresses IP secondaire du sous-réseau utilisée par les services.
  • Si la méthode d'attribution de plages secondaires est gérée par l'utilisateur :
    • secondary-range-pods correspond au nom d'une plage d'adresses IP secondaire existante dans le paramètre subnet-name spécifié. GKE utilise la totalité de la plage d'adresses IP secondaire du sous-réseau pour les pods du cluster.
    • secondary-range-services correspond au nom d'une plage d'adresses IP secondaire existante dans le paramètre subnet-name spécifié. GKE utilise la totalité de la plage d'adresses IP secondaire du sous-réseau pour les services du cluster.

Console

  1. Accédez au menu "Google Kubernetes Engine" dans Cloud Console.

    Accéder au menu "Google Kubernetes Engine"

  2. Cliquez sur le bouton Créer un cluster.

  3. Dans le volet de navigation, sous Cluster, cliquez sur Réseau.

  4. Dans la liste déroulante Réseau, sélectionnez un VPC.

  5. Dans la liste déroulante Sous-réseau de nœud, sélectionnez un sous-réseau pour le cluster.

  6. Assurez-vous que la case Activer le routage du trafic de VPC natif (utilisation d'une adresse IP d'alias) est cochée.

  7. Cochez la case Créer automatiquement des plages secondaires si vous souhaitez que la méthode d'attribution de plages secondaires soit gérée par GKE. Désactivez cette option si vous avez déjà créé des plages secondaires pour le sous-réseau sélectionné et que vous souhaitez que la méthode d'attribution de plages secondaires soit gérée par l'utilisateur.

  8. Dans le champ Plage d'adresses de pod, saisissez une plage pour le pod (exemple : 10.0.0.0/14).

  9. Dans le champ Plage d'adresses du service, saisissez une plage pour le service (exemple : 10.4.0.0/19).

  10. Configurez le cluster selon vos besoins.

  11. Cliquez sur Créer.

API

Lorsque vous créez un cluster de VPC natif, vous définissez un objet IPAllocationPolicy. Vous pouvez référencer des plages d'adresses IP secondaires de sous-réseaux existantes ou spécifier des blocs CIDR. Référencez des plages d'adresses IP secondaires de sous-réseau existantes pour créer un cluster dont la méthode d'attribution de plages secondaires est gérée par l'utilisateur. Spécifiez des blocs CIDR si vous souhaitez que la méthode d'attribution des plages soit gérée par GKE.

{
  "name": cluster-name,
  "description": description,
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "clusterIpv4CidrBlock"      : string,
    "servicesIpv4CidrBlock"     : string,
    "clusterSecondaryRangeName" : string,
    "servicesSecondaryRangeName": string,

  },
  ...
}

où :

  • "clusterIpv4CidrBlock" est la taille/l'emplacement de la plage CIDR des pods. Cette valeur détermine la taille de la plage secondaire destinée aux pods et peut être spécifiée selon le format adresse IP/taille en notation CIDR (par exemple, 10.0.0.0/14) ou le format /taille (par exemple, /14). Un espace vide de la taille donnée est choisi parmi l'espace disponible dans votre VPC. Si aucune valeur n'est spécifiée, une plage valide est trouvée et créée avec une taille par défaut.
  • "servicesIpv4CidrBlock" est la taille/l'emplacement de la plage CIDR des services. Lisez la description de "clusterIpv4CidrBlock".
  • "clusterSecondaryRangeName" est le nom de la plage secondaire destinée aux pods. Cette plage doit déjà exister, et elle doit appartenir au sous-réseau associé au cluster (comme le sous-réseau spécifié avec l'indicateur --subnetwork).
  • "serviceSecondaryRangeName" est le nom de la plage secondaire destinée aux services. Cette plage secondaire doit déjà exister, et elle doit appartenir au sous-réseau associé au cluster (comme le sous-réseau spécifié avec l'indicateur --subnetwork).

Terraform

Vous pouvez facilement créer un cluster VPC natif via Terraform à l'aide d'un module Terraform.

Par exemple, vous pouvez ajouter ce bloc à votre configuration Terraform :

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google"
  version = "~> 9.1"

  project_id        = "project-id"
  name              = "cluster-name"
  region            = "region"
  network           = "network-name"
  subnetwork        = "subnet-name"
  ip_range_pods     = "secondary-range-pods"
  ip_range_services = "secondary-range-services"
}

Remplacez les éléments suivants :

  • project-id correspond à l'ID du projet dans lequel le cluster est créé.
  • cluster-name correspond au nom du cluster GKE.
  • region correspond à la région dans laquelle le cluster est créé.
  • network-name correspond au nom d'un réseau existant.
  • subnet-name correspond au nom d'un sous-réseau existant. La plage d'adresses IP principale du sous-réseau est utilisée par les nœuds. Le sous-réseau doit exister dans la même région que celle utilisée par le cluster.
  • secondary-range-pods correspond au nom d'une plage d'adresses IP secondaire existante dans le paramètre subnet-name spécifié. GKE utilise la totalité de la plage d'adresses IP secondaire du sous-réseau pour les pods du cluster.
  • secondary-range-services correspond au nom d'une plage d'adresses IP secondaire existante dans le paramètre subnet-name spécifié. GKE utilise la totalité de la plage d'adresses IP secondaire du sous-réseau pour les services du cluster.

Créer simultanément un cluster et un sous-réseau

Les instructions suivantes décrivent comment créer dans le même temps un cluster et un sous-réseau GKE sur un VPC natif. La méthode d'attribution de plages secondaires est gérée par GKE lorsque vous effectuez ces deux étapes à l'aide d'une seule commande.

gcloud

Pour créer simultanément un cluster et un sous-réseau VPC natif :

gcloud container clusters create cluster-name \
    --region=region \
    --enable-ip-alias \
    --create-subnetwork name=subnet-name,range=node-ip-range \
    --cluster-ipv4-cidr=pod-ip-range \
    --services-ipv4-cidr=services-ip-range

où :

  • cluster-name correspond au nom du cluster GKE.
  • region correspond à la région dans laquelle le cluster est créé. Pour créer un cluster zonal, remplacez cette option par --zone=zone, où zone correspond à une zone GKE.
  • subnet-name correspond au nom du sous-réseau à créer. La région du sous-réseau est la même que celle du cluster (ou que la région dans laquelle réside le cluster zonal). Utilisez une chaîne vide (name="") si vous souhaitez que GKE génère un nom automatiquement.
  • node-ip-range correspond à une plage d'adresses IP au format CIDR (par exemple, 10.5.0.0/20) ou à la taille du masque de sous-réseau d'un bloc CIDR (par exemple, /20). Cela permet de créer la plage d'adresses IP principale du sous-réseau utilisée par les nœuds. Si cette valeur est omise, GKE choisit une plage d'adresses IP disponible dans le VPC, d'une taille de /20.
  • pod-ip-range correspond à une plage d'adresses IP au format CIDR (par exemple, 10.0.0.0/14) ou à la taille du masque de sous-réseau d'un bloc CIDR (par exemple, /14). Cela permet de créer la plage d'adresses IP secondaire du sous-réseau utilisée par les pods. Si cette valeur est omise, GKE applique la valeur /14, soit la taille par défaut de la plage d'adresses IP du pod.
  • services-ip-range correspond à une plage d'adresses IP au format CIDR (par exemple, 10.4.0.0/19) ou à la taille du masque de sous-réseau d'un bloc CIDR (par exemple, /19). Cela permet de créer la plage d'adresses IP secondaire du sous-réseau utilisée par les services. Si cette valeur est omise, GKE applique la valeur /20, soit la taille par défaut de la plage d'adresses IP des services.

Console

Vous ne pouvez pas créer simultanément un cluster et un sous-réseau à l'aide de Cloud Console. Vous devez donc commencer par créer un sous-réseau, puis créer le cluster dans un sous-réseau existant.

API

Pour créer un cluster de VPC natif, définissez un objet [IPAllocationPolicy] dans votre ressource de cluster :

{
  "name": cluster-name,
  "description": description,
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "createSubnetwork": true,
    "subnetworkName": subnet-name
  },
  ...
}

Le champ createSubnetwork crée et provisionne automatiquement un sous-réseau pour le cluster. Le champ subnetworkName est facultatif. Si aucune valeur n'est spécifiée, un nom est automatiquement choisi pour le sous-réseau.

Utiliser des plages d'adresses IP privées non-RFC 1918

Les clusters GKE utilisant 1.14.2-gke.1 et versions ultérieures peuvent utiliser des plages d'adresses IP privées en dehors des plages RFC 1918 pour les nœuds, les pods et les services. Consultez la section Plages valides dans la documentation du réseau VPC pour obtenir la liste des plages privées non-RFC 1918 pouvant être utilisées comme adresses IP internes pour les plages de sous-réseaux.

Les plages d'adresses IP privées non-RFC 1918 sont compatibles avec les clusters privés et les clusters non privés.

Les plages privées non-RFC 1918 sont des plages de sous-réseaux. Vous pouvez les utiliser exclusivement ou conjointement avec des plages de sous-réseaux RFC 1918. Les nœuds, les pods et les services continuent à utiliser les plages de sous-réseaux, comme décrit dans la section Plages d'adresses IP pour les clusters de VPC natif. Si vous utilisez des plages non-RFC 1918, tenez bien compte des éléments suivants :

  • Les plages de sous-réseaux, y compris celles utilisant des plages non-RFC 1918, doivent être attribuées manuellement ou par GKE avant la création des nœuds du cluster. Vous ne pouvez pas basculer vers ou cesser d'utiliser des plages de sous-réseaux non-RFC 1918, sauf si vous remplacez le cluster.

  • Les équilibreurs de charge TCP/UDP internes n'utilisent que des adresses IP de la plage d'adresses IP principale du sous-réseau. Pour créer un équilibreur de charge TCP/UDP interne avec une adresse non-RFC 1918, la plage d'adresses IP principale de votre sous-réseau doit être autre que RFC 1918.

Les destinations situées en dehors de votre cluster peuvent rencontrer des difficultés pour recevoir du trafic provenant de plages privées non-RFC 1918. Par exemple, les plages privées RFC 1112 (classe E) sont généralement utilisées en tant qu'adresses de multidiffusion. Si une destination extérieure à votre cluster ne peut pas traiter les paquets dont les sources sont des adresses IP privées en dehors de la plage RFC 1918, vous pouvez effectuer les deux opérations suivantes :

  • Utilisez une plage RFC 1918 pour la plage d'adresses IP principale du sous-réseau. De cette manière, les nœuds du cluster utilisent des adresses RFC 1918.

  • Vérifiez que votre cluster exécute l'agent de masquage d'adresses IP et que les destinations ne sont pas dans la liste nonMasqueradeCIDRs. De cette manière, les sources (SNAT) des paquets envoyés à partir de pods sont remplacées par des adresses de nœuds, qui sont RFC 1918.

Activer les plages d'adresses IP publiques réutilisées en mode privé

Les clusters GKE utilisant 1.14.2-gke.1 et versions ultérieures peuvent réutiliser en mode privé certaines plages d'adresses IP publiques en tant que plages d'adresses IP de sous-réseau internes. Vous pouvez réutiliser en mode privé toute adresse IP publique, à l'exception de certaines plages restreintes, comme décrit dans la documentation du réseau VPC.

Votre cluster doit être un cluster privé pour que vous puissiez utiliser des plages d'adresses IP publiques réutilisées en mode privé. Les clusters de VPC natifs non privés et les clusters basés sur le routage ne sont pas compatibles.

Les plages publiques réutilisées en mode privé sont des plages de sous-réseaux. Vous pouvez les utiliser exclusivement ou conjointement avec d'autres plages de sous-réseaux qui utilisent des adresses privées. Les nœuds, les pods et les services continuent à utiliser les plages de sous-réseaux, comme décrit dans la section Plages d'adresses IP pour les clusters de VPC natif. Tenez bien compte des éléments suivants lorsque vous réutilisez des adresses IP publiques en mode privé :

  • Lorsque vous réutilisez une plage d'adresses IP publique en tant que plage de sous-réseau, votre cluster ne peut plus communiquer avec les systèmes sur Internet qui utilisent cette plage publique. La plage devient une plage d'adresses IP interne dans le réseau VPC du cluster.

  • Les plages de sous-réseaux, y compris celles qui réutilisent des plages d'adresses IP publiques en mode privé, doivent être attribuées manuellement ou par GKE avant la création des nœuds du cluster. Vous ne pouvez pas basculer vers ou cesser d'utiliser des adresses IP publiques réutilisées en mode privé, sauf si vous remplacez le cluster.

  • Les sources (SNAT) des paquets envoyés à partir de pods qui utilisent une plage d'adresses IP publiques réutilisée en mode privé ne peuvent pas être remplacées par des adresses de nœud. Par conséquent, vous devez créer votre cluster avec l'indicateur --disable-default-snat. Pour en savoir plus sur cette option, reportez-vous à la section Masquage d'adresse IP dans GKE.

  • Étant donné qu'un cluster dont les pods réutilisent en mode privé les plages d'adresses IP publiques doit être un cluster privé, votre cluster doit utiliser une solution NAT telle que Cloud NAT si les pods doivent envoyer du trafic à des destinations sur Internet. Lorsque vous utilisez Cloud NAT, vous devez au moins configurer la passerelle NAT de sorte qu'elle s'applique à la plage d'adresses IP secondaire du sous-réseau du cluster utilisée par les pods. Ainsi, Cloud NAT exécute la SNAT à partir des paquets envoyés par les adresses IP des pods, car le comportement SNAT par défaut doit être désactivé dans la configuration du masquage d'adresses IP du cluster.

Exemple de cluster avec des plages publiques réutilisées en mode privé

L'exemple suivant utilise gcloud pour créer un cluster qui utilise des plages d'adresses IP publiques réutilisées en mode privé. Vous devez utiliser les indicateurs suivants :

  • --enable-ip-alias : cette opération crée un cluster de VPC natif requis pour réutiliser des plages d'adresses IP publiques en mode privé.
  • --enable-private-nodes : cette commande crée un cluster privé, requis pour réutiliser des plages d'adresses IP publiques en mode privé.
  • --disable-default-snat : cette option est obligatoire si vous réutilisez en mode privé des adresses IP publiques pour vos pods ou nœuds. La désactivation de la configuration SNAT est requise pour que les réponses puissent être acheminées vers le pod à l'origine du trafic.

Cette commande crée un cluster privé de VPC natif dont :

  • les nœuds utilisent la plage d'adresses IP principale 10.0.0.0/24 du sous-réseau ;
  • les pods réutilisent en mode privé la plage d'adresses IP publique 5.0.0.0/16 en tant que plage d'adresses IP secondaire du sous-réseau réservée aux pods ;
  • les services réutilisent en mode privé la plage d'adresses IP publiques 5.1.0.0/16 en tant que plage d'adresses IP secondaire du sous-réseau réservée aux services.
gcloud container clusters create cluster-name \
  --enable-ip-alias \
  --enable-private-nodes \
  --disable-default-snat \
  --zone=zone \
  --create-subnetwork name=cluster-subnet,range=10.0.0.0/24 \
  --cluster-ipv4-cidr=5.0.0.0/16 \
  --services-ipv4-cidr=5.1.0.0/16 \
  --master-ipv4-cidr=master-CIDR

Valider les plages de pod et de service

Après avoir créé un cluster de VPC-natif, vous pouvez valider les plages de pod et de service spécifiées.

gcloud

Afin de vérifier le cluster, exécutez la commande suivante :

gcloud container clusters describe cluster-name

Dans le résultat de la commande, regardez sous le champ ipAllocationPolicy :

  • clusterIpv4Cidr est la plage secondaire destinée aux pods.
  • servicesIpv4Cidr est la plage secondaire destinée aux services.

Console

Pour vérifier le cluster, procédez comme suit :

  1. Accédez au menu Google Kubernetes Engine dans Cloud Console.

    Accéder au menu Google Kubernetes Engine

  2. Sélectionnez le cluster souhaité.

Les plages secondaires sont affichées dans l'onglet Détails de la section Cluster :

  • La plage d'adresses du conteneur est la plage secondaire des pods.
  • La plage d'adresses de service est la plage secondaire des services.

Dépannage

Cette section fournit des conseils pour résoudre les problèmes liés aux clusters de VPC natif.

La ressource "projects/[PROJECT_NAME]/regions/XXX/subnetworks/default" n'est pas prête.

Causes probables
Des opérations sont effectuées en parallèle sur le même sous-réseau. Par exemple, un autre cluster de VPC natif est en cours de création, ou une plage secondaire est en cours d'ajout ou de suppression sur le sous-réseau.
Solution
Relancez la commande.

Valeur non valide pour le champ "resource.secondaryIpRanges[1].ipCidrRange": "XXX". IPCidrRange non valide : XXX est en conflit avec le sous-réseau existant "default" dans la région "XXX".

Causes probables

Un autre cluster de VPC natif est en cours de création simultanément et tente d'allouer les mêmes plages au sein du même réseau VPC.

La même plage secondaire est en cours d'ajout dans le sous-réseau du même réseau VPC.

Solution

Si cette erreur est renvoyée lors de la création du cluster alors qu'aucune plage secondaire n'a été spécifiée, relancez la commande de création du cluster.

Pas assez d'espace d'adresses IP libre pour les pods

Symptômes

Le cluster est bloqué dans un état de provisionnement pendant une période prolongée

La création de cluster renvoie une erreur de groupe d'instances géré (MIG, Managed Instance Group).

Les nouveaux nœuds ne peuvent pas être ajoutés à un cluster existant.

Causes probables

L'espace non attribué dans la plage d'adresses IP des pods n'est pas suffisant pour ajouter les nœuds demandés dans le cluster. Par exemple, si la plage d'adresses IP de pods d'un cluster comporte un masque de réseau d'une taille de /23 (512 adresses) et un nombre de pods par nœud de 110, vous ne pouvez pas créer plus de deux nœuds. (Une plage d'adresses IP avec un masque de réseau d'une taille de /24 est attribuée à chaque nœud.)

Solutions

Créez un cluster de remplacement après avoir examiné et planifié les plages d'adresses IP principale et secondaire d'une taille appropriée. Reportez-vous aux pages Plages d'adresses IP pour les clusters de VPC natif et Planifier des plages d'adresses IP.

Si vous ne pouvez pas remplacer le cluster, vous pouvez peut-être contourner le problème en recréant un pool de nœuds doté d'un nombre maximal de pods par nœud inférieur. Si possible, transférez les charges de travail vers ce pool de nœuds, puis supprimez le pool de nœuds précédent. La réduction du nombre maximal de pods par nœud vous permet d'accepter un plus grand nombre de nœuds sur une plage d'adresses IP secondaire fixe utilisée par les pods. Consultez les pages Plage d'adresses IP secondaire du sous-réseau utilisée par les pods et Plage de limites de nœuds pour plus d'informations sur les calculs à effectuer.

Vérifier si la configuration SNAT par défaut est désactivée

Exécutez la commande suivante pour vérifier l'état de la configuration SNAT par défaut :

gcloud container clusters describe cluster-name

Remplacez cluster-name par le nom de votre cluster.

Le résultat inclut un champ disableDefaultSnat comme suit :

networkConfig:
  disableDefaultSnat: true
  network: ...

Impossible d'utiliser --disable-default-snat sans --enable-ip-alias

Ce message d'erreur, ainsi que le message must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster, signifient que vous devez définir explicitement l'option --disable-default-snat lors de la création du cluster, car vous utilisez des adresses IP publiques dans votre cluster privé.

Si des messages d'erreur tels que cannot disable default sNAT ... s'affichent, cela signifie que la configuration SNAT par défaut ne peut pas être désactivée dans votre cluster. Veuillez vérifier la configuration de votre cluster.

Déboguer Cloud NAT avec la configuration SNAT par défaut désactivée

Si un cluster privé a été créé avec l'option --disable-default-snat et que vous avez configuré Cloud NAT pour l'accès à Internet, mais que vous ne voyez pas de trafic Internet en provenance de vos pods, assurez-vous que la plage dédiée aux pods est comprise dans la configuration Cloud NAT.

En cas de problème de communication entre pods, examinez les règles iptables sur les nœuds afin de vous assurer que les plages dédiées aux pods ne sont pas masquées par celles-ci. Reportez-vous à l'exemple de sortie iptables pour savoir comment répertorier les règles iptables et connaître les règles par défaut. Si vous n'avez pas configuré d'agent de masquage d'adresses IP pour le cluster, GKE s'assure automatiquement que la communication entre pods n'est pas masquée. Toutefois, si un agent de masquage d'adresses IP est configuré, il remplacera les règles de masquage d'adresses IP par défaut. Assurez-vous que des règles supplémentaires sont configurées dans l'agent de masquage d'adresses IP pour ignorer le masquage des plages dédiées aux pods.

Restrictions

  • Vous ne pouvez pas convertir un cluster de VPC natif en cluster basé sur le routage, ni convertir un cluster basé sur le routage en cluster de VPC natif.
  • Les clusters de VPC natif nécessitent des réseaux VPC. Les anciens réseaux ne sont pas compatibles.

  • Comme pour tout cluster GKE, les adresses de services (ClusterIP) ne sont disponibles qu'au sein du cluster. Si vous devez accéder à un service Kubernetes à partir d'instances de VM en dehors du cluster, mais dans le réseau VPC et la région du cluster, créez un équilibreur de charge TCP/UDP interne.

Étape suivante