Créer et gérer des clusters IPv6 à pile unique

Ce document explique comment créer, configurer et gérer des clusters IPv6 à pile unique dans Google Kubernetes Engine (GKE).

Vous pouvez exécuter des charges de travail conteneurisées dans un environnement réseau IPv6 uniquement pour éviter d'épuiser l'espace d'adressage IPv4 privé (RFC 1918). Lorsque vous déployez un cluster IPv6 à pile unique, vous n'attribuez que des adresses IPv6 à vos pods, nœuds et services, tout en conservant la connectivité d'entrée et de sortie vers les ressources internes et externes.

Présentation

À mesure que vos charges de travail évoluent et que la densité des clusters augmente, l'espace d'adressage IPv4 privé peut rapidement s'épuiser. Dans les clusters IPv4 uniquement et à double pile, chaque pod nécessite une adresse IPv4, ce qui peut faire de l'allocation de blocs CIDR sur votre réseau VPC un goulot d'étranglement majeur pour le scaling.

Dans les clusters GKE IPv6 à pile unique, vous attribuez des adresses IPv6 exclusivement sur le plan de données du cluster, ce qui supprime complètement les contraintes liées aux adresses IPv4. Les nœuds de calcul s'exécutent sur des instances de VM Compute Engine IPv6 à pile unique, et les pods et les services communiquent via des connexions IPv6.

Attribution d'adresses IP (IPAM)

Les clusters IPv6 à pile unique allouent des adresses IPv6 sur votre sous-réseau, vos nœuds, vos pods et vos services à l'aide des tailles de préfixe suivantes :

Ressource Préfixe de bloc CIDR Description
Sous-réseau /64 Spécifié en tant que bloc CIDR de sous-réseau IPv6 uniquement.
Nœud /96 Attribuée automatiquement par GKE à partir du bloc CIDR du sous-réseau, fournissant environ 4,29 milliards d'adresses IPv6 uniques par nœud.
Pod /112 Attribuée à partir d'un sous-ensemble de la sous-plage /96 du nœud.
Service /64 Attribuée automatiquement par GKE pour les services ClusterIP à partir de la plage d'adresses IPv6 2600:2D00:0:4::0:0/64.

Types d'accès IPv6 externe et interne

Lorsque vous configurez le sous-réseau de votre cluster, vous pouvez choisir entre deux types d'accès IPv6 pour contrôler la routabilité Internet :

  • Interne (ULA) : les sous-réseaux avec le type d'accès INTERNAL utilisent des adresses unicast locales uniques (ULA) dans la plage fd20::/20. La communication est limitée à votre réseau VPC, aux réseaux d'appairage et aux connexions hybrides. Les nœuds et les pods ne peuvent pas accéder directement aux ressources Internet IPv6 publiques ni recevoir d'entrées Internet directes.
  • Externe (GUA) : les sous-réseaux avec le type d'accès EXTERNAL utilisent des adresses unicast globales (GUA). Les nœuds et les pods se voient attribuer des adresses IPv6 uniques au niveau mondial et peuvent communiquer avec les ressources Internet IPv6 publiques en entrée et en sortie, sous réserve des règles de pare-feu et des tables de routage du VPC.

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 la Google Cloud CLI pour cette tâche, installez puis initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

Conditions requises et limites

Pour utiliser des clusters IPv6 à pile unique, assurez-vous de respecter les exigences et les limites suivantes :

  • Votre cluster doit exécuter GKE version 1.37.1-gke.3020000 ou ultérieure.
  • Votre cluster doit être un cluster de VPC natif qui utilise GKE Dataplane V2. Les clusters IPv6 à pile unique ne sont pas compatibles avec les clusters basés sur le routage.
  • Les clusters IPv6 à pile unique n'acceptent que les instances de VM IPv6 à pile unique en tant que nœuds de calcul, et ne sont pas compatibles avec les pools de nœuds mixtes ou à double pile.
  • Vous devez utiliser Cloud DNS comme fournisseur DNS du cluster (--cluster-dns=clouddns). Les clusters IPv6 à pile unique ne sont pas compatibles avec kube-dns.
  • L'accès au plan de contrôle dans les clusters IPv6 à simple pile utilise deux chemins distincts :
    • Clients externes : les clients situés en dehors du cluster (par exemple, utilisant kubectl) accèdent au plan de contrôle via un point de terminaison basé sur un domaine via GKE Frontend (GKFE).
    • Charges de travail internes : les nœuds et les pods se connectent de manière sécurisée au plan de contrôle via Private Service Connect. Pour permettre cette communication, vous devez fournir ou créer un sous-réseau avec un type d'accès IPv6 INTERNAL (--private-endpoint-subnetwork).
  • Sur les sous-réseaux IPv6 internes (INTERNAL), les nœuds et les pods peuvent accéder aux API Google et à Artifact Registry via IPv6 sans passerelle Cloud NAT. Toutefois, tenez compte des points suivants :
    • Pour atteindre des points de terminaison IPv4 externes uniquement (tels que des registres de conteneurs IPv4 externes uniquement), vous devez configurer DNS64 et Cloud NAT (NAT64).
    • Les nœuds et les pods des sous-réseaux INTERNAL ne peuvent pas atteindre les points de terminaison IPv6 publics externes en dehors de Google, car les adresses locales uniques (ULA) ne sont pas routables sur l'Internet IPv6 public et Cloud NAT n'est pas compatible avec la traduction IPv6 vers IPv6 (NAT66).
  • Les clusters IPv6 à pile unique ne sont pas compatibles avec les options de cluster --private-ipv6-google-access-type et --enable-private-nodes. Configurez plutôt l'accès privé à Google et les types d'accès IPv6 (INTERNAL ou EXTERNAL) directement sur votre sous-réseau VPC.
  • Les clusters IPv6 à pile unique ne sont pas compatibles avec les configurations multi-sous-réseaux.
  • Les clusters IPv6 à pile unique ne sont pas compatibles avec GKE Ingress. Pour configurer des équilibreurs de charge d'application de couche 7, utilisez l'API Gateway.
  • L'API multiréseau GKE n'est pas compatible avec les réseaux de pods IPv6. Les réseaux de pods secondaires doivent être IPv4 uniquement. Pour en savoir plus, consultez Compatibilité multiréseau pour les pods.
  • Les clusters IPv6 uniquement ne sont pas compatibles avec Cloud Service Mesh.
  • Vous pouvez utiliser vos propres adresses IPv6 (BYOIPv6) avec des clusters IPv6 à pile unique. Pour en savoir plus sur les exigences applicables aux préfixes BYOIPv6, consultez Créer et utiliser des sous-préfixes IPv6.

Configuration du serveur de métadonnées de charge de travail

Étant donné que les charges de travail exécutées dans des pods IPv6 uniquement ne peuvent pas atteindre l'adresse du serveur de métadonnées IPv4 standard (169.254.169.254), appliquez les ajustements suivants :

  • Configurez vos applications et vos bibliothèques clientes pour qu'elles accèdent au serveur de métadonnées à l'aide du nom de domaine metadata.google.internal (recommandé) ou de l'adresse IPv6 ULA littérale [fd20:ce::254].

  • Si vous utilisez des bibliothèques clientes ou des applications avec des points de terminaison de serveur de métadonnées IPv4 codés en dur (par exemple, des versions antérieures des bibliothèques clientes des API Google), définissez la variable d'environnement GCE_METADATA_HOST dans vos images de conteneurs ou vos spécifications de pod :

    env:
- name: GCE_METADATA_HOST
  value: "metadata.google.internal"

Créer un cluster IPv6 à pile unique

Vous pouvez créer un cluster IPv6 à pile unique à l'aide de la Google Cloud CLI.

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

Si vous ne disposez pas de sous-réseaux personnalisés préexistants, vous pouvez créer un cluster IPv6 standard à pile unique et demander à GKE de provisionner automatiquement le sous-réseau de nœud requis et --private-endpoint-subnetwork en une seule commande.

Exécutez la commande suivante :

gcloud beta container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-dataplane-v2 \
    --cluster-dns=clouddns \
    --stack-type=ipv6 \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME \
    --ipv6-access-type=ACCESS_TYPE \
    --location=COMPUTE_LOCATION

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du nouveau cluster.
  • VERSION : GKE version 1.37.1-gke.3020000 ou ultérieure.
  • NETWORK_NAME : nom d'un réseau VPC en mode personnalisé existant.
  • SUBNET_NAME : nom du nouveau sous-réseau de nœuds à créer.
  • ACCESS_TYPE : routabilité Internet du sous-réseau. Spécifiez INTERNAL pour l'adressage ULA privé ou EXTERNAL pour l'adressage GUA public. La valeur par défaut est EXTERNAL.
  • COMPUTE_LOCATION : région ou zone de calcul de votre cluster.

Créer un cluster Standard sur des sous-réseaux personnalisés

Pour utiliser des sous-réseaux préexistants ou personnalisés, créez le réseau VPC, le sous-réseau du plan de contrôle PSC et le sous-réseau de nœuds avant de créer votre cluster.

  1. Créez un réseau VPC en mode personnalisé avec les adresses IPv6 internes ULA activées :

    gcloud compute networks create NETWORK_NAME \
    --subnet-mode=CUSTOM \
    --enable-ula-internal-ipv6

  2. Créez le sous-réseau dédié du plan de contrôle PSC interne :

    gcloud compute networks subnets create PSC_SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=INTERNAL \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

    Remplacez COMPUTE_REGION par la région dans laquelle vous déployez votre cluster (par exemple, us-central1). Vous pouvez également spécifier --stack-type=ipv4_ipv6 pour le sous-réseau du plan de contrôle PSC.

  3. Créez le sous-réseau de nœuds. Choisissez l'accès interne (INTERNAL) ou l'accès externe (EXTERNAL) :

    gcloud compute networks subnets create NODE_SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=ACCESS_TYPE \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

  4. Créez le cluster standard IPv6 à pile unique référençant les deux sous-réseaux :

    gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-dataplane-v2 \
    --cluster-dns=clouddns \
    --stack-type=ipv6 \
    --network=NETWORK_NAME \
    --subnetwork=NODE_SUBNET_NAME \
    --private-endpoint-subnetwork=PSC_SUBNET_NAME \
    --location=COMPUTE_LOCATION

Créer un cluster Autopilot sur des sous-réseaux personnalisés

Les clusters Autopilot héritent automatiquement de leur type de pile du sous-réseau de nœuds que vous spécifiez. Lorsque vous sélectionnez un sous-réseau IPv6 uniquement, GKE crée un cluster Autopilot IPv6 à pile unique.

  1. Assurez-vous d'avoir créé un réseau VPC personnalisé, un sous-réseau PSC interne et un sous-réseau de nœuds IPv6 uniquement, comme décrit dans la section précédente.

  2. Créez le cluster Autopilot :

    gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=VERSION \
    --network=NETWORK_NAME \
    --subnetwork=NODE_SUBNET_NAME \
    --private-endpoint-subnetwork=PSC_SUBNET_NAME \
    --location=COMPUTE_LOCATION

Créer un cluster Standard avec des nœuds gérés

Vous pouvez également créer un cluster Standard IPv6 à pile unique qui utilise des nœuds gérés configurés au niveau de la charge de travail. Pour en savoir plus sur la configuration des ComputeClasses gérées dans les clusters standards, consultez Classes Autopilot dans les clusters standards.

Utiliser des adresses BYOIPv6 pour les nœuds et les pods

Vous pouvez créer un cluster IPv6 à pile unique dont les nœuds et les pods utilisent l'option Utiliser vos propres adresses IPv6 (BYOIPv6) au lieu des adresses fournies par Google. Pour ce faire, créez le sous-réseau de nœuds avec une plage d'adresses IPv6 externes provenant d'un sous-préfixe IPv6 régional de votre préfixe délégué public (PDP). Les nœuds et les pods reçoivent ensuite des adresses IPv6 à partir de ce préfixe et communiquent avec Internet et entre eux à l'aide de ces adresses.

  1. Créez un sous-préfixe IPv6 régional de votre préfixe délégué public en mode EXTERNAL_IPV6_SUBNETWORK_CREATION. Pour en savoir plus, consultez Créer des sous-préfixes IPv6.

  2. Créez le sous-réseau de nœuds avec un type d'accès IPv6 EXTERNAL et référencez le sous-préfixe à l'aide de l'option --ip-collection. Compute Engine alloue la plage d'adresses IPv6 /64 du sous-réseau à partir du sous-préfixe :

    gcloud compute networks subnets create NODE_SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=EXTERNAL \
    --ip-collection=SUB_PREFIX_NAME \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

    Remplacez SUB_PREFIX_NAME par le nom du sous-préfixe que vous avez créé à l'étape précédente. Le sous-préfixe doit se trouver dans la même région que le sous-réseau. Pour choisir une plage /64 spécifique dans le sous-préfixe au lieu de laisser Compute Engine en allouer une, ajoutez l'option --external-ipv6-prefix.

  3. Créez le cluster sur ce sous-réseau de nœuds en suivant les étapes de la section Créer un cluster Standard sur des sous-réseaux personnalisés ou Créer un cluster Autopilot sur des sous-réseaux personnalisés. Le sous-réseau du plan de contrôle PSC n'a pas besoin d'une plage d'adresses BYOIPv6.

  4. Une fois que GKE a créé le cluster, vérifiez que les nœuds et les pods ont des adresses IPv6 de votre préfixe :

    kubectl get nodes -o wide
kubectl get pods --all-namespaces -o wide

Tenez bien compte des éléments suivants :

  • Cette procédure utilise un sous-réseau de nœuds avec le type d'accès IPv6 EXTERNAL. Les nœuds et les pods obtiennent ainsi des adresses routables de manière globale à partir de votre préfixe. Vous pouvez également utiliser un sous-réseau de nœud avec le type d'accès IPv6 INTERNAL en référençant un sous-préfixe en mode INTERNAL_IPV6_SUBNETWORK_CREATION. Dans ce cas, les nœuds et les pods obtiennent des adresses BYOIPv6 internes, et les limites de connectivité du type d'accès IPv6 interne s'appliquent. Pour en savoir plus, consultez Se connecter à des ressources externes et privées.
  • Pour exposer des charges de travail sur des adresses BYOIPv6 avec des services LoadBalancer, consultez Utiliser vos propres adresses IPv6 (BYOIPv6), qui ne nécessite pas de sous-réseau de nœuds BYOIPv6.
  • Pour connaître les exigences applicables aux préfixes BYOIPv6, consultez Créer et utiliser des sous-préfixes IPv6.

Vérifier le type de pile du cluster

Une fois la création du cluster terminée, listez vos clusters pour vérifier que votre cluster s'exécute en mode IPv6 à pile unique :

gcloud beta container clusters list

Le résultat confirme que la colonne STACK_TYPE est définie sur IPV6 :

NAME               LOCATION       MASTER_VERSION      MASTER_IP                                 MACHINE_TYPE  NODE_VERSION        NUM_NODES  STACK_TYPE  STATUS
v6-only-cluster-1  us-central1-c  1.37.0-gke.1000000  gke-3a3234-123456.us-central1-c.gke.goog  e2-medium     1.37.0-gke.1000000  1          IPV6        RUNNING

Équilibrage de charge dans les clusters IPv6 à pile unique

Vous pouvez exposer des applications exécutées dans des clusters IPv6 à pile unique à l'aide d'équilibreurs de charge de couche 7 et de couche 4 :

  • Équilibrage de charge d'application de couche 7 (API Gateway) : utilisez l'API Gateway Kubernetes pour déployer des équilibreurs de charge d'application de couche 7 (gke-l7-rilb, gke-l7-regional-external-managed ou gke-l7-global-external-managed). Ces passerelles peuvent diffuser des clients IPv4 et IPv6 internes et externes tout en acheminant le trafic de manière transparente vers des points de terminaison de pods IPv6 internes uniquement. Notez que GKE Ingress n'est pas compatible avec les clusters IPv6 à pile unique. Lorsque vous déployez des passerelles régionales (gke-l7-rilb et gke-l7-regional-external-managed) sur des clusters IPv6 à pile unique, tenez compte des exigences suivantes concernant les sous-réseaux :

    • Sous-réseau proxy réservé : sur les clusters IPv6 à pile unique, le sous-réseau proxy réservé régional (--purpose=REGIONAL_MANAGED_PROXY) doit être à double pile (--stack-type=IPV4_IPV6). Sur les clusters IPv4 uniquement et à double pile, le sous-réseau peut être IPv4 uniquement ou à double pile.
    • Sous-réseau d'adresse IP virtuelle de la passerelle : contrairement aux passerelles externes régionales IPv4 (qui n'allouent pas d'adresses IP virtuelles à partir d'un sous-réseau), les passerelles externes régionales IPv6 (gke-l7-regional-external-managed) nécessitent un sous-réseau avec un accès IPv6 EXTERNAL, et les passerelles internes régionales (gke-l7-rilb) nécessitent un sous-réseau avec un accès IPv6 INTERNAL (ou une plage IPv4 pour une adresse IP virtuelle IPv4 interne). Pour allouer une adresse IP virtuelle de passerelle régionale éphémère à partir d'un sous-réseau personnalisé au lieu du sous-réseau de nœud du cluster, spécifiez le nom du sous-réseau dans le champ spec.default.subnetwork d'un GCPGatewayPolicy associé à la passerelle.

    Pour obtenir des instructions de configuration, consultez Déployer des passerelles.

  • Équilibrage de charge de passthrough de couche 4 (API Service) : vous pouvez exposer des charges de travail aux clients IPv6 à l'aide de services Kubernetes configurés avec type: LoadBalancer. Selon que les nœuds de votre cluster s'exécutent sur un sous-réseau INTERNAL (ULA) ou EXTERNAL (GUA), vous devrez peut-être provisionner un sous-réseau d'équilibreur de charge dédié et le référencer à l'aide de l'annotation networking.gke.io/load-balancer-subnet :

Se connecter à des ressources externes et privées

Les charges de travail de votre cluster IPv6 à pile unique doivent souvent communiquer avec des services externes sur Internet ou des services privés dans Google Cloud.

Se connecter à des ressources Internet IPv6 publiques

Si vos nœuds de cluster s'exécutent sur un sous-réseau configuré avec le type d'accès IPv6 EXTERNAL (--ipv6-access-type=EXTERNAL), la connectivité sortante et entrante vers les points de terminaison IPv6 Internet publics est activée par défaut. Vérifiez que vos règles de pare-feu VPC autorisent le trafic IPv6 requis. Pour en savoir plus, consultez Utiliser des règles de pare-feu VPC.

Se connecter à des ressources Internet IPv4 publiques (DNS64 et NAT64)

Étant donné que les pods d'un cluster IPv6 à pile unique ne disposent que d'adresses IPv6, la connexion à des points de terminaison Internet IPv4 publics nécessite une traduction réseau. Vous pouvez configurer Cloud DNS et Cloud NAT sur votre réseau VPC pour fournir une traduction DNS64 et NAT64 automatique :

  1. Créez une règle de serveur DNS64 :

    gcloud dns policies create POLICY_NAME \
    --description="DNS64 policy for single-stack IPv6 cluster" \
    --networks=NETWORK_NAME \
    --enable-dns64-all-queries

  2. Créez un routeur Cloud Router dans la région où votre cluster est déployé :

    gcloud compute routers create ROUTER_NAME \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

  3. Créez une passerelle Cloud NAT configurée pour la traduction NAT64 :

    gcloud compute routers nats create NAT_NAME \
    --router=ROUTER_NAME \
    --region=COMPUTE_REGION \
    --auto-allocate-nat-external-ips \
    --nat64-all-v6-subnet-ip-ranges

    Pour configurer NAT64 avec des sous-réseaux spécifiques ou des adresses IP externes manuelles, utilisez --nat64-custom-v6-subnet-ip-ranges et --nat-external-ip-pool.

Pour en savoir plus sur la traduction d'adresses, consultez Configurer DNS64 et NAT64 et DNS64 et NAT64 pour la connectivité 6to4.

Se connecter à des services privés à l'aide de Private Service Connect

Private Service Connect (PSC) est compatible avec la traduction d'adresses IPv6 vers IPv4 sur les points de terminaison et les règles de transfert. Vous pouvez connecter les charges de travail de votre cluster IPv6 à pile unique aux services gérés Google Cloud (tels que les instances Cloud SQL) ou aux services de producteurs tiers :

  1. Réservez une adresse IPv6 interne statique à partir du sous-réseau PSC de votre cluster :

    gcloud compute addresses create ADDRESS_NAME \
    --ip-version=IPV6 \
    --subnet=PSC_SUBNET_NAME \
    --region=COMPUTE_REGION

  2. Créez une règle de transfert de point de terminaison PSC ciblant le rattachement de service :

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --address=ADDRESS_NAME \
    --region=COMPUTE_REGION \
    --network=NETWORK_NAME \
    --target-service-attachment=SERVICE_ATTACHMENT_URL \
    --allow-psc-global-access

  3. Récupérez l'adresse IPv6 attribuée :

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME \
    --region=COMPUTE_REGION \
    --format='value(IPAddress)'

  4. Utilisez l'adresse IPv6 récupérée dans les chaînes de connexion de votre application. PSC traduit le trafic afin que vos pods IPv6 puissent atteindre de manière sécurisée les services de producteur IPv4 ou à double pile.

Pour en savoir plus sur l'utilisation des services publiés, consultez Créer un point de terminaison Private Service Connect et Se connecter à Cloud SQL avec Private Service Connect. Pour publier un service LoadBalancer interne s'exécutant dans votre cluster auprès de clients d'autres réseaux VPC à l'aide d'une ressource ServiceAttachment, consultez Créer un équilibreur de charge interne avec Private Service Connect.

Mise en réseau avancée et accélérateurs

Vous pouvez configurer des clusters IPv6 à pile unique avec des interfaces réseau secondaires pour les pools de nœuds d'accélérateur et les pods multiréseaux.

Mise en réseau d'accélérateurs avec plusieurs cartes d'interface réseau

Dans les clusters IPv6 à pile unique standards, vous pouvez associer des réseaux de données secondaires (RDMA ou DIORITE) à des pools de nœuds d'accélérateur (GPU et TPU) à l'aide de la mise en réseau automatisée (--accelerator-network-profile=auto) ou de la configuration multiréseau manuelle (--additional-node-network). Les interfaces secondaires peuvent s'exécuter sur des sous-réseaux IPv4, des sous-réseaux à double pile ou des sous-réseaux IPv6 uniquement.

Pour obtenir des instructions détaillées, consultez Configurer des réseaux de nœuds multi-NIC sur des clusters IPv6 à pile unique.

Compatibilité multiréseau des pods

Les clusters IPv6 à pile unique sont compatibles avec le multiréseau pour les pods présentant les caractéristiques suivantes :

  • L'interface réseau du pod principal (eth0) utilise une mise en réseau IPv6 à pile unique.
  • Les interfaces réseau de pod supplémentaires doivent être de type IPv4 uniquement (réseaux VPC de couche 3). Les clusters IPv6 à pile unique ne sont pas compatibles avec les réseaux de pods IPv6 sur des interfaces réseau supplémentaires.
  • L'annotation de pod networking.gke.io/default-interface configure l'interface par défaut pour le trafic IPv4 uniquement. Aucune interface par défaut n'est configurée pour le trafic IPv6.

Pour savoir comment configurer des réseaux de pods IPv4 secondaires basés sur des sous-réseaux VPC, consultez Configurer la compatibilité multiréseau pour les pods sur des clusters IPv6 à pile unique.

Migrer vers des clusters IPv6 à pile unique

Vous ne pouvez pas convertir directement ni mettre à jour sur place des clusters IPv4 ou à double pile existants en clusters IPv6 à pile unique. Pour effectuer la transition des charges de travail, utilisez une migration bleu-vert :

  1. Auditer les dépendances : vérifiez que les configurations d'application, les bibliothèques clientes et les agents utilisent des noms DNS (tels que metadata.google.internal) plutôt que des adresses IPv4 codées en dur. Configurez GCE_METADATA_HOST si nécessaire.
  2. Provisionner un cluster vert : déployez un nouveau cluster IPv6 à pile unique en parallèle de votre cluster existant, au sein du même réseau VPC ou d'un réseau VPC appairé. Vérifiez que Cloud DNS, DNS64, Cloud NAT (NAT64) et les règles de transfert PSC sont configurés.
  3. Déployer des charges de travail : appliquez vos fichiers manifestes Kubernetes au cluster vert et vérifiez que les pods démarrent et communiquent correctement.
  4. Déplacer le trafic : à l'aide de vos équilibreurs de charge (API Gateway ou règles de routage Cloud DNS), déplacez progressivement le trafic de l'ancien cluster vers le nouveau cluster IPv6 tout en surveillant les métriques et les taux d'erreur.
  5. Mettre hors service l'ancien cluster : une fois que tout le trafic a été transféré et que le cluster vert est stable, drainez et supprimez l'ancien cluster.

Étapes suivantes