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 page de présentation des clusters de VPC natif.

Pour les clusters GKE Autopilot, les réseaux VPC natifs sont activés par défaut et ne peuvent pas être remplacés.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Activez l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.
Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

Limites

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 réseau passthrough interne.
Si vous utilisez toutes les adresses IP de pods dans un sous-réseau, vous ne pouvez pas remplacer la plage d'adresses IP secondaire du sous-réseau sans entraîner l'instabilité du cluster. Toutefois, vous pouvez créer des plages d'adresses IP de pods supplémentaires à l'aide du CIDR multipods non contigu.

Créer un cluster

Cette section explique comment effectuer les tâches suivantes au moment de créer le cluster :

Créer simultanément un cluster et un sous-réseau.
Créer un cluster dans un sous-réseau existant.
Créer un cluster et sélectionner la plage d'adresses IP du plan de contrôle.
Créer un cluster avec la mise en réseau à double pile dans un nouveau sous-réseau (disponible dans les clusters Autopilot version 1.25 ou ultérieure et les clusters Standard version 1.24 ou ultérieure).
Créer un cluster et un sous-réseau à double pile simultanément (disponible dans les clusters Autopilot version 1.25 et ultérieure, et les clusters Standard version 1.24 ou ultérieure).

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 \
    --location=COMPUTE_LOCATION \
    --enable-ip-alias \
    --create-subnetwork name=SUBNET_NAME,range=NODE_IP_RANGE \
    --cluster-ipv4-cidr=POD_IP_RANGE \
    --services-ipv4-cidr=SERVICES_IP_RANGE

Remplacez les éléments suivants :

CLUSTER_NAME : nom du cluster GKE.
COMPUTE_LOCATION : emplacement Compute Engine du cluster.
SUBNET_NAME : 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 : plage d'adresses IP au format CIDR (par exemple, 10.5.0.0/20) ou 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 : plage d'adresses IP au format CIDR (par exemple, 10.0.0.0/14) ou 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 utilise une plage /14 choisie de manière aléatoire contenant 2¹⁸ adresses. La plage choisie automatiquement est sélectionnée de manière aléatoire à partir de 10.0.0.0/8 (une plage de 2²⁴ adresses) et n'inclut pas les plages d'adresses IP allouées aux VM, les routes existantes ou les plages allouées à d'autres clusters. La plage choisie automatiquement peut entrer en conflit avec des adresses IP réservées, des routes dynamiques ou des routes au sein de VPC appairés à ce cluster. Si vous utilisez l'un de ces éléments, vous devez spécifier --cluster-ipv4-cidr pour éviter les conflits.
SERVICES_IP_RANGE : plage d'adresses IP au format CIDR (par exemple, 10.4.0.0/19) ou 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 la console Google Cloud. 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.

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 \
    --location=COMPUTE_LOCATION \
    --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 \
    --location=COMPUTE_LOCATION \
    --enable-ip-alias \
    --subnetwork=SUBNET_NAME \
    --cluster-secondary-range-name=SECONDARY_RANGE_PODS \
    --services-secondary-range-name=SECONDARY_RANGE_SERVICES

Remplacez les éléments suivants :

CLUSTER_NAME : nom du cluster GKE.
COMPUTE_LOCATION : emplacement Compute Engine du cluster.
SUBNET_NAME : 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 : plage d'adresses IP au format CIDR (par exemple, 10.0.0.0/14) ou 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 vous omettez l'option --cluster-ipv4-cidr, GKE choisit automatiquement une plage /14 (2¹⁸ adresses). La plage choisie automatiquement est sélectionnée de manière aléatoire à partir de 10.0.0.0/8 (une plage de 2²⁴ adresses) et n'inclut pas les plages d'adresses IP allouées aux VM, les routes existantes ou les plages allouées à d'autres clusters. La plage choisie automatiquement peut entrer en conflit avec des adresses IP réservées, des routes dynamiques ou des routes au sein de VPC appairés à ce cluster. Si vous utilisez l'un de ces éléments, vous devez spécifier --cluster-ipv4-cidr pour éviter les conflits.
- SERVICES_IP_RANGE : 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 : 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 : nom d'une plage d'adresses IP secondaire existante dans le paramètre spécifié.

Console

Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

Accéder à Google Kubernetes Engine
Cliquez sur Créer, puis sur Configurer dans la section Standard ou Autopilot.
Dans le volet de navigation, cliquez sur Réseau sous Cluster.
Dans la liste déroulante Réseau, sélectionnez un VPC.
Dans la liste déroulante Sous-réseau de nœud, sélectionnez un sous-réseau pour le cluster.
Assurez-vous que la case Activer le routage du trafic de VPC natif (utilisation d'une adresse IP d'alias) est cochée.
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.
Dans le champ Plage d'adresses de pod, saisissez une plage pour le pod, par exemple 10.0.0.0/14.
Dans le champ Plage d'adresses du service, saisissez une plage pour le service, par exemple 10.4.0.0/19.
Configurez votre cluster.
Cliquez sur Créer.

Terraform

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

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

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

  project_id        = "PROJECT_ID"
  name              = "CLUSTER_NAME"
  region            = "COMPUTE_LOCATION"
  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 : ID de votre projet.
CLUSTER_NAME : nom du cluster GKE.
COMPUTE_LOCATION : emplacement Compute Engine du cluster. Pour Terraform, la région Compute Engine.
NETWORK_NAME : nom d'un réseau existant.
SUBNET_NAME : 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 : nom d'une plage d'adresses IP secondaire existante dans le paramètre spécifié.
SECONDARY_RANGE_SERVICES : nom d'une plage d'adresses IP secondaire existante dans le paramètre spécifié.

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,

  },
  ...
}

Cette commande inclut les valeurs suivantes :

"clusterIpv4CidrBlock" : 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 CIDR, par exemple 10.0.0.0/14. Un espace vide de la taille donnée est sélectionné au sein de 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" : plage CIDR des services. Lisez la description de "clusterIpv4CidrBlock".
"clusterSecondaryRangeName" : 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.
"serviceSecondaryRangeName" : nom de la plage secondaire destinée aux services. Cette plage doit déjà exister et elle doit appartenir au sous-réseau associé au cluster.

Créer un cluster et sélectionner la plage d'adresses IP du plan de contrôle

Par défaut, les clusters dotés de Private Service Connect utilisent la plage de sous-réseau principale pour provisionner l'adresse IP interne attribuée au point de terminaison du plan de contrôle. Vous pouvez remplacer ce paramètre par défaut seulement au moment de la création du cluster en sélectionnant une autre plage de sous-réseaux. Les sections suivantes expliquent comment créer un cluster avec Private Service Connect et remplacer la plage de sous-réseaux.

gcloud

Créer un cluster avec Private Service Connect défini comme public

gcloud container clusters create CLUSTER_NAME \
    --private-endpoint-subnetwork=SUBNET_NAME \
    --location=COMPUTE_LOCATION

Ajoutez l'option --enable-private-nodes pour créer le cluster Private Service Connect comme privé.

Remplacez les éléments suivants :

CLUSTER_NAME : nom du cluster GKE.
SUBNET_NAME : nom d'un sous-réseau existant.
COMPUTE_LOCATION : emplacement Compute Engine du cluster.

GKE crée un cluster avec Private Service Connect.

Créez un cluster défini comme privé :

Dans GKE version 1.29 ou ultérieure, vous pouvez créer un cluster avec Private Service Connect. Lorsque vous créez un sous-réseau dans un cluster privé à l'aide de Private Service Connect, le paramètre --master-ipv4-cidr est facultatif. Pour créer un cluster privé :

gcloud container clusters create CLUSTER_NAME --enable-ip-alias \
    --enable-private-nodes  \
    --private-endpoint-subnetwork=SUBNET_NAME \
    --region=COMPUTE_REGION

Remplacez les éléments suivants :

CLUSTER_NAME : nom du cluster GKE.
SUBNET_NAME : nom d'un sous-réseau existant. Si vous n'indiquez pas de valeur pour l'option private-endpoint-subnetwork, mais que vous utilisez l'option master-ipv4-cidr, GKE crée un sous-réseau qui utilise les valeurs que vous avez définies dans master-ipv4-cidr. GKE utilise le nouveau sous-réseau pour provisionner l'adresse IP interne du plan de contrôle.
COMPUTE_LOCATION : emplacement Compute Engine du cluster.

Console

Créez un cluster défini comme public :

Pour attribuer un sous-réseau au plan de contrôle d'un nouveau cluster, vous devez d'abord ajouter un sous-réseau. Procédez comme suit :

Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

Accéder à Google Kubernetes Engine
Cliquez sur Créer.
Dans la section Standard ou Autopilot, cliquez sur Configurer.
Dans le champ Nom, saisissez le nom de votre cluster.
Pour les clusters standards, dans le volet de navigation, sous Cluster, cliquez sur Mise en réseau.
Dans la section Accès au réseau IPv4, procédez comme suit :
1. Pour créer un cluster GKE en tant que public, sélectionnez Cluster public.
2. Pour créer un cluster GKE en tant que cluster privé, sélectionnez Cluster privé.
Dans les deux cas, vous pouvez ensuite modifier le mode d'isolation du cluster lors de la modification de sa configuration.
Dans la section Options de mise en réseau avancées, cochez la case Remplacer le sous-réseau du point de terminaison privé par défaut du plan de contrôle.
Dans la liste Sous-réseau du point de terminaison privé, sélectionnez le sous-réseau que vous avez créé.
Cliquez sur OK. Ajoutez d'autres réseaux autorisés selon les besoins.

Créer un cluster avec une mise en réseau à double pile

Vous pouvez créer un cluster avec une mise en réseau à double pile IPv4/IPv6 sur un sous-réseau à double pile nouveau ou existant. Le sous-réseau à double pile est disponible dans les clusters Autopilot version 1.25 ou ultérieure et les clusters standards version 1.24 ou ultérieure. Le sous-réseau à double pile n'est pas compatible avec les pools de nœuds Windows Server.

Avant de configurer des clusters à double pile, nous vous recommandons d'effectuer les actions suivantes :

En savoir plus sur les avantages et les exigences des clusters GKE avec une mise en réseau à double pile.
Consultez les restrictions et limites de la mise en réseau à double pile.

Dans cette section, vous allez d'abord créer un sous-réseau à double pile, puis utiliser ce sous-réseau pour créer un cluster.

Pour créer un sous-réseau à double pile, exécutez la commande suivante :
```
gcloud compute networks subnets create SUBNET_NAME \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --network=NETWORK_NAME \
    --range=PRIMARY_RANGE \
    --region=COMPUTE_REGION
```
Remplacez les éléments suivants :
- SUBNET_NAME : nom du sous-réseau que vous choisissez.
- ACCESS_TYPE : type de routage vers l'Internet public. Utilisez INTERNAL pour les clusters privés et EXTERNAL pour les clusters publics. Si --ipv6-access-type n'est pas spécifié, le type d'accès par défaut est EXTERNAL.
- NETWORK_NAME : nom du réseau qui contiendra le nouveau sous-réseau. Ce réseau doit répondre aux conditions suivantes :
  - Il doit s'agir d'un réseau VPC en mode personnalisé. Pour en savoir plus, découvrez comment basculer un réseau VPC en mode automatique vers le mode personnalisé.
  - Si vous remplacez ACCESS_TYPE par INTERNAL, le réseau doit utiliser des adresses Unicast IPv6 uniques locales (ULA).
- PRIMARY_RANGE : plage d'adresses IP principale IPv4 pour le nouveau sous-réseau, au format CIDR. Pour en savoir plus, consultez la section sur les plages de sous-réseaux.
- COMPUTE_REGION : région de calcul du cluster.
Pour créer un cluster avec un sous-réseau à double pile, utilisez gcloud CLI ou la console Google Cloud :

gcloud

Pour les clusters Autopilot, exécutez la commande suivante :
```
  gcloud container clusters create-auto CLUSTER_NAME \
      --location=COMPUTE_LOCATION \
      --network=NETWORK_NAME \
      --subnetwork=SUBNET_NAME
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom de votre nouveau cluster Autopilot.
- COMPUTE_LOCATION : emplacement Compute Engine du cluster.
- NETWORK_NAME : nom du réseau VPC contenant le sous-réseau. Ce réseau VPC doit être un réseau VPC en mode personnalisé. Pour en savoir plus, découvrez comment basculer un réseau VPC en mode automatique vers le mode personnalisé.
- SUBNET_NAME : nom du sous-réseau à double pile.
  
  Par défaut, les clusters GKE Autopilot utilisent un cluster à double pile lorsque vous utilisez un sous-réseau à double pile. Après la création du cluster, vous pouvez le mettre à jour pour qu'il utilise uniquement IPv4.

Pour les clusters Standard, exécutez la commande suivante :
```
gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --enable-dataplane-v2 \
    --stack-type=ipv4-ipv6 \
    --network=NETWORK_NAME \
    --subnetwork=SUBNET_NAME \
    --location=COMPUTE_LOCATION
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du nouveau cluster
- NETWORK_NAME : nom du réseau VPC contenant le sous-réseau. Ce réseau VPC doit être un réseau VPC en mode personnalisé qui utilise des adresses Unicast IPv6 uniques locales (ULA). Pour en savoir plus, découvrez comment basculer un réseau VPC en mode automatique vers le mode personnalisé.
- SUBNET_NAME : nom du sous-réseau
- COMPUTE_LOCATION : emplacement Compute Engine du cluster.

Console

Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

Accéder à Google Kubernetes Engine
Cliquez sur Créer.
Dans la section Standard ou Autopilot, cliquez sur Configurer.
Configurez le cluster selon vos besoins.
Dans le volet de navigation, cliquez sur Réseau sous Cluster.
Dans la liste Réseau, sélectionnez le nom de votre réseau.
Dans la liste Sous-réseau de nœud, sélectionnez le nom de votre sous-réseau à double pile.
Pour les clusters Standard, cochez la case d'option IPv4 et IPv6 (double pile). Cette option n'est disponible que si vous avez sélectionné un sous-réseau à double pile.

Par défaut, les clusters Autopilot utilisent un cluster à double pile lorsque vous utilisez un sous-réseau à double pile.
Cliquez sur Créer.

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

Vous pouvez créer simultanément un sous-réseau et un cluster à double pile. GKE crée un sous-réseau IPv6 et attribue une plage principale IPv6 externe au sous-réseau.

Si vous utilisez un VPC partagé, vous ne pouvez pas créer le cluster et le sous-réseau simultanément. En effet, un administrateur réseau du projet hôte de VPC partagé doit d'abord créer le sous-réseau à double pile.

Pour les clusters Autopilot, exécutez la commande suivante :
```
gcloud container clusters create-auto CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom de votre nouveau cluster Autopilot.
- COMPUTE_LOCATION : emplacement Compute Engine du cluster.
- NETWORK_NAME : nom du réseau VPC contenant le sous-réseau. Ce réseau VPC doit être un réseau VPC en mode personnalisé qui utilise des adresses Unicast IPv6 uniques locales (ULA). Pour en savoir plus, découvrez comment basculer un réseau VPC en mode automatique vers le mode personnalisé.
- SUBNET_NAME : nom du nouveau sous-réseau. GKE peut créer le sous-réseau en fonction de vos règles d'administration :
  - Si vos règles d'administration autorisent la double pile et que le réseau est en mode personnalisé, GKE crée un sous-réseau à double pile et attribue une plage principale IPv6 externe au sous-réseau.
  - Si les règles de votre organisation n'autorisent pas la double pile ou si le réseau est en mode automatique, GKE crée un sous-réseau à pile unique (IPv4).

Pour les clusters Standard, exécutez la commande suivante :
```
gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME,range=PRIMARY_RANGE \
    --location=COMPUTE_LOCATION
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du nouveau cluster choisi.
- ACCESS_TYPE : type de routage vers l'Internet public. Utilisez INTERNAL pour les clusters privés et EXTERNAL pour les clusters publics. Si --ipv6-access-type n'est pas spécifié, le type d'accès par défaut est EXTERNAL.
- NETWORK_NAME : nom du réseau qui contiendra le nouveau sous-réseau. Ce réseau doit répondre aux conditions suivantes :
  - Il doit s'agir d'un réseau VPC en mode personnalisé. Pour en savoir plus, découvrez comment basculer un réseau VPC en mode automatique vers le mode personnalisé.
  - Si vous remplacez ACCESS_TYPE par INTERNAL, le réseau doit utiliser des adresses Unicast IPv6 uniques locales (ULA).
- SUBNET_NAME : nom du nouveau sous-réseau que vous choisissez.
- PRIMARY_RANGE : plage d'adresses IPv4 principale pour le nouveau sous-réseau, au format CIDR. Pour en savoir plus, consultez la section sur les plages de sous-réseaux.
- COMPUTE_LOCATION : emplacement Compute Engine du cluster.

Mettre à jour le type de pile

Vous pouvez modifier le type de pile d'un cluster existant ou convertir un sous-réseau existant en sous-réseau à double pile.

Mettre à jour le type de pile d'un cluster existant

Avant de modifier le type de pile sur un cluster existant, tenez compte des limites suivantes :

La modification du type de pile est compatible avec les nouveaux clusters GKE exécutant la version 1.25 ou ultérieure. Les clusters GKE qui ont été mis à niveau des versions 1.24 vers les versions 1.25 ou 1.26 peuvent recevoir des erreurs de validation lors de l'activation du réseau à double pile. En cas d'erreurs, contactez l'équipe d'assistance Google Cloud.
La modification du type de pile est une opération perturbatrice, car GKE redémarre les composants du plan de contrôle et des nœuds.
GKE respecte les intervalles de maintenance configurés lors de la recréation de nœuds. Cela signifie que le type de pile du cluster ne sera pas opérationnel sur le cluster avant le prochain intervalle de maintenance. Pour éviter d'attendre, vous pouvez mettre à niveau manuellement le pool de nœuds en définissant l'option --cluster-version sur la même version de GKE que celle que le plan de contrôle exécute. Pour cette solution, vous devez utiliser la gcloud CLI. Pour en savoir plus, consultez la section Mise en garde à propos des intervalles de maintenance.
La modification du type de pile ne modifie pas automatiquement la famille d'IP des services existants. Les conditions suivantes s'appliquent :
- Si vous remplacez une pile unique par une double pile, les services existants restent à pile unique.
- Si vous remplacez une pile double par une pile unique, les services existants avec des adresses IPv6 passent à l'état "erreur". Supprimez le service et créez-en un avec le paramètre ipFamilies approprié. Pour en savoir plus, consultez un exemple de configuration de déploiement.

Pour mettre à jour un cluster de VPC natif existant, vous pouvez utiliser la gcloud CLI ou la console Google Cloud :

gcloud

Exécutez la commande ci-dessous.

  gcloud container clusters update CLUSTER_NAME \
      --stack-type=STACK_TYPE \
      --location=COMPUTE_LOCATION

Remplacez les éléments suivants :

CLUSTER_NAME : nom du cluster que vous souhaitez mettre à jour.
STACK_TYPE : type de pile. Remplacez par l'une des valeurs suivantes :
- ipv4 : pour mettre à jour un cluster à double pile vers un cluster IPv4 uniquement. GKE utilise la plage d'adresses IPv4 principale du sous-réseau du cluster.
- ipv4-ipv6 : pour mettre à jour un cluster IPv4 existant vers une double pile. Vous ne pouvez passer d'un cluster à un cluster à double pile que si le sous-réseau sous-jacent est compatible avec la double pile. Pour en savoir plus, consultez la section Mettre à jour un sous-réseau existant vers un sous-réseau à double pile.
COMPUTE_LOCATION : emplacement Compute Engine du cluster.

Console

Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

Accéder à Google Kubernetes Engine
À côté du cluster que vous souhaitez modifier, cliquez sur Actions, puis sur Modifier.
Dans la section Mise en réseau, à côté de Type de pile, cliquez sur Modifier.
Dans la boîte de dialogue Modifier le type de pile, cochez la case correspondant au type de pile de cluster dont vous avez besoin.
Cliquez sur Save Changes (Enregistrer les modifications).

Mettre à jour un sous-réseau existant vers un sous-réseau à double pile (disponible dans les clusters Autopilot version 1.25 ou ultérieure et les clusters Standard version 1.24 ou ultérieure).

Mettre à jour un sous-réseau existant vers un sous-réseau à double pile

Pour mettre à jour un sous-réseau existant vers un sous-réseau à double pile, exécutez la commande suivante. La mise à jour d'un sous-réseau n'a pas d'incidence sur les clusters IPv4 existants du sous-réseau.

gcloud compute networks subnets update SUBNET_NAME \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --region=COMPUTE_REGION

Remplacez les éléments suivants :

SUBNET_NAME : nom du sous-réseau
ACCESS_TYPE : type de routage vers l'Internet public. Utilisez INTERNAL pour les clusters privés et EXTERNAL pour les clusters publics. Si --ipv6-access-type n'est pas spécifié, le type d'accès par défaut est EXTERNAL.
COMPUTE_REGION : région de calcul du cluster.

Vérifier les plages d'adresses IP des pods, des services et des types de pile

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

La sortie comporte un bloc ipAllocationPolicy. Le champ stackType décrit le type de définition de réseau. Pour chaque type, vous pouvez afficher les informations réseau suivantes :

Informations sur le réseau IPv4 :
- clusterIpv4Cidr est la plage secondaire destinée aux pods.
- servicesIpv4Cidr est la plage secondaire destinée aux services.
Informations réseau IPv6 (si un cluster dispose d'une mise en réseau à double pile) :
- ipv6AccessType : type de routage vers l'Internet public. INTERNAL pour les adresses IPv6 privées et EXTERNAL pour les adresses IPv6 publiques.
- subnetIpv6CidrBlock : plage d'adresses IPv6 secondaires du nouveau sous-réseau.
- servicesIpv6CidrBlock : plage d'adresses attribuée aux services IPv6 sur le cluster à double pile.

Console

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

Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

Accéder à Google Kubernetes Engine
Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez inspecter.

Les plages secondaires sont affichées dans la section Mise en réseau :

La plage d'adresses de pod est la plage secondaire des pods.
La plage d'adresses de service est la plage secondaire des services.

Configuration avancée pour les adresses IP internes

Les sections suivantes expliquent comment utiliser des plages d'adresses IP privées non-RFC 1918 et comment activer des plages d'adresses IP publiques utilisées en mode privé.

Utiliser des plages d'adresses IP non-RFC 1918

Les clusters GKE peuvent utiliser des plages d'adresses IP 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.

Cette fonctionnalité n'est pas compatible avec les pools de nœuds Windows Server.

Les plages d'adresses IP 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 réseau passthrough 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 réseau passthrough 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 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 externes utilisées en mode privé

Les clusters GKE peuvent utiliser en mode privé certaines plages d'adresses IP externes en tant que plages d'adresses IP de sous-réseau internes. Vous pouvez utiliser en mode privé toute adresse IP externe, à l'exception de certaines plages restreintes, comme décrit dans la documentation du réseau VPC. Cette fonctionnalité n'est pas compatible avec les pools de nœuds Windows Server.

Votre cluster doit être un cluster de VPC natif pour pouvoir utiliser des plages d'adresses IP externes utilisées en mode privé. Les clusters basés sur le routage ne sont pas compatibles.

Les plages externes 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 externes en mode privé :

Lorsque vous utilisez une plage d'adresses IP externes comme plage de sous-réseaux, votre cluster ne peut plus communiquer avec les systèmes sur Internet qui utilisent cette plage externe. 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 utilisant des plages d'adresses IP externes 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 externes utilisées en mode privé, sauf si vous remplacez le cluster.

Par défaut, GKE met en œuvre la SNAT sur les nœuds vers des adresses IP externes. Si vous avez configuré le CIDR du pod pour qu'il utilise des adresses IP externes, les règles SNAT s'appliquent au trafic entre les pods. Pour éviter cela, deux options s'offrent à vous :

Créer votre cluster avec l'option --disable-default-snat. Pour en savoir plus sur cette option, reportez-vous à la section IP masquerading dans GKE.
Configurer le configMap ip-masq-agent, en incluant dans la liste nonMasqueradeCIDRs au moins le CIDR du pod, le CIDR du service et le sous-réseau des nœuds.

Pour les clusters standards, si la version du cluster est 1.14 ou ultérieure, les deux options fonctionnent. Si votre cluster est antérieur à la version 1.14, vous ne pouvez utiliser que la deuxième option (configuration de ip-masq-agent).

Créer un cluster de VPC natif

Avant de commencer

Limites

Créer un cluster

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

gcloud

Console

API

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

gcloud

Console

Terraform

API

Créer un cluster et sélectionner la plage d'adresses IP du plan de contrôle

gcloud

Créer un cluster avec Private Service Connect défini comme public

Créez un cluster défini comme privé :

Console

Créez un cluster défini comme public :

Créer un cluster avec une mise en réseau à double pile

gcloud

Console

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

Mettre à jour le type de pile

Mettre à jour le type de pile d'un cluster existant

gcloud

Console

Mettre à jour un sous-réseau existant vers un sous-réseau à double pile

Vérifier les plages d'adresses IP des pods, des services et des types de pile

gcloud

Console

Configuration avancée pour les adresses IP internes

Utiliser des plages d'adresses IP non-RFC 1918

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

Étape suivante