Configurer la compatibilité multiréseau pour les pods

Cette page explique comment activer plusieurs interfaces sur des nœuds et des pods d'un cluster Google Kubernetes Engine (GKE) en utilisant la compatibilité multiréseau des pods.

Avant de lire cette page, assurez-vous de connaître les concepts de mise en réseau, la terminologie et les concepts spécifiques à cette fonctionnalité, ainsi que les conditions requises et les limites de la compatibilité multiréseau des pods.

Pour en savoir plus, consultez la page À propos de la compatibilité multiréseau des pods.

Conditions requises et limites

La compatibilité multiréseau des pods présente les exigences et limites suivantes :

Conditions requises

  • GKE Standard version 1.28 ou ultérieure.
  • GKE Autopilot version 1.29.5-gke.1091000 et versions ultérieures, ou version 1.30.1-gke.1280000 et versions ultérieures.
  • La compatibilité multiréseau des pods utilise les mêmes spécifications au niveau des VM que les cartes d'interface réseau pour Compute Engine.
  • La compatibilité multiréseau des pods nécessite GKE Dataplane V2.
  • La compatibilité multiréseau des pods n'est disponible que pour les nœuds Container-Optimized OS qui exécutent la version m101 ou ultérieure.

Limites générales

  • La compatibilité multiréseau des pods ne fonctionne pas pour les clusters activés pour la mise en réseau à double pile.
  • Le VPC partagé n'est compatible qu'avec GKE version 1.28 ou ultérieure.
  • Le CIDR multipod n'est compatible qu'avec GKE version 1.29 ou ultérieure, et uniquement pour le réseau de pods par défaut.
  • Les réseaux de pods d'un même cluster GKE ne peuvent pas chevaucher des plages CIDR.
  • Lorsque vous activez la compatibilité multiréseau des pods, vous ne pouvez pas ajouter ni supprimer d'interfaces de réseaux de nœuds ou de réseaux de pods après avoir créé un pool de nœuds. Pour modifier ces paramètres, vous devez recréer le pool de nœuds.
  • Par défaut, l'accès à Internet n'est pas disponible sur des interfaces supplémentaires des réseaux de pods au sein du pod. Cependant, vous pouvez l'activer manuellement à l'aide de Cloud NAT.
  • Vous ne pouvez pas modifier la passerelle par défaut dans un pod avec plusieurs interfaces via l'API. La passerelle par défaut doit être connectée au réseau de pods par défaut.
  • Le réseau de pods par défaut doit toujours être inclus dans les pods, même si vous créez des réseaux de pods ou des interfaces supplémentaires.
  • Vous ne pouvez pas configurer la fonctionnalité multiréseau une fois que la solution Hubble gérée a été configurée.
  • Pour utiliser le VPC partagé, assurez-vous que votre cluster GKE exécute la version 1.28.4 ou ultérieure.
  • Pour les déploiements de VPC partagés, toutes les interfaces réseau (NIC) associées à des nœuds doivent appartenir au même projet que le projet hôte.
  • Le nom des objets réseau de type appareil ne peut pas dépasser 41 caractères. Le chemin d'accès complet de chaque socket de domaine UNIX est composé, y compris le nom de réseau correspondant. Linux limite la longueur des chemins d'accès aux sockets à 107 octets. En tenant compte du répertoire, du préfixe du nom de fichier et de l'extension .sock, le nom du réseau est limité à 41 caractères maximum.

Limites des appareils et du kit de développement de plan de données (DPDK)

  • La carte d'interface réseau d'une VM transmise à un pod en tant que carte d'interface réseau de type Device n'est pas disponible pour les autres pods du même nœud.
  • Les pods qui utilisent le mode DPDK doivent être exécutés en mode privilégié pour accéder aux appareils VFIO.
  • Le mode Autopilot n'est pas compatible avec DPDK.
  • En mode DPDK, un appareil est traité comme une ressource de nœud et n'est associé qu'au premier conteneur (non-init) du pod. Si vous souhaitez répartir plusieurs appareils DPDK entre des conteneurs du même pod, vous devez exécuter ces conteneurs dans des pods distincts.

Limitations de scaling

GKE fournit une architecture réseau flexible qui vous permet d'effectuer le scaling de votre cluster. Vous pouvez ajouter d'autres réseaux de nœuds et de pods à votre cluster. Vous pouvez effectuer le scaling de votre cluster comme suit :

  • Vous pouvez ajouter jusqu'à sept réseaux de nœuds supplémentaires à chaque pool de nœuds GKE. La même limite de scaling s'applique aux VM Compute Engine.
  • Chaque pod doit comporter moins de sept réseaux supplémentaires associés.
  • Vous pouvez configurer jusqu'à 35 réseaux de pods sur les huit réseaux de nœuds au sein d'un même pool de nœuds. Vous pouvez les diviser en différentes combinaisons, telles que les suivantes :
    • 7 réseaux de nœuds avec 5 réseaux de pods chacun
    • 5 réseaux de nœuds avec 7 réseaux de pods chacun
    • Un réseau de nœuds avec 30 réseaux de pods. Le nombre maximal de plages secondaires par sous-réseau est de 30.
  • Vous pouvez configurer jusqu'à 50 réseaux de pods par cluster.
  • Vous pouvez configurer jusqu'à 32 pods multiréseaux par nœud.
  • Vous pouvez avoir jusqu'à 5 000 nœuds avec plusieurs interfaces.
  • Vous pouvez avoir jusqu'à 100 000 interfaces supplémentaires sur tous les pods.

Déployer des pods multiréseaux

Pour déployer des pods multiréseaux, procédez comme suit :

  1. Préparez un VPC supplémentaire, un sous-réseau (réseau de nœuds) et des plages secondaires (réseau de pods).
  2. Créez un cluster GKE multiréseau à l'aide de la commande Google Cloud CLI.
  3. Créez un pool de nœuds GKE connecté au réseau de nœuds et au réseau de pods supplémentaires à l'aide de la commande Google Cloud CLI.
  4. Créez un réseau de pods et référencez le VPC, le sous-réseau et les plages secondaires appropriés dans les objets multiréseaux à l'aide de l'API Kubernetes.
  5. Dans la configuration de votre charge de travail, référencez l'objet Kubernetes Network préparé à l'aide de l'API Kubernetes.

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.

Préparer un VPC supplémentaire

Google Cloud crée un réseau de pods par défaut lors de la création du cluster associé au pool de nœuds GKE utilisé lors de la création initiale du cluster GKE. Le réseau de pods par défaut est disponible sur l'ensemble des nœuds et des pods du cluster. Pour faciliter les fonctionnalités multiréseaux au sein du pool de nœuds, vous devez préparer des VPC, nouveaux ou existants, compatibles avec les réseaux de type Layer 3 et Device.

Pour préparer un VPC supplémentaire, tenez compte des exigences suivantes :

  • Réseau de type Layer 3 et Netdevice :

    • Créez une plage secondaire si vous utilisez des réseaux de type Layer 3.
    • Assurez-vous que la taille du bloc CIDR de la plage secondaire est suffisamment importante pour répondre au nombre de nœuds du pool de nœuds et au nombre de pods par nœud dont vous souhaitez disposer.
    • À l'instar du réseau de pods par défaut, les autres réseaux de pods utilisent le surprovisionnement d'adresses IP. La plage d'adresses IP secondaire doit comporter deux fois plus d'adresses IP par nœud que de pods par nœud.

  • Exigences du réseau de type Device : créez un sous-réseau standard sur un VPC. Vous n'avez pas besoin d'un sous-réseau secondaire.

Pour activer les fonctionnalités multiréseaux dans le pool de nœuds, vous devez préparer les VPC vers lesquels vous souhaitez établir des connexions supplémentaires. Vous pouvez utiliser un VPC existant ou créer un VPC spécifiquement pour le pool de nœuds.

Créer un réseau VPC compatible avec un appareil de type Layer 3

Pour créer un réseau VPC compatible avec l'appareil de type Layer 3, procédez comme suit :

  • Assurez-vous que la taille du bloc CIDR de la plage secondaire est suffisamment importante pour répondre au nombre de nœuds du pool de nœuds et au nombre de pods par nœud dont vous souhaitez disposer.

  • À l'instar du réseau de pods par défaut, les autres réseaux de pods utilisent le surprovisionnement d'adresses IP. La plage d'adresses IP secondaire doit comporter deux fois plus d'adresses IP par nœud que de pods par nœud.

gcloud

gcloud compute networks subnets create SUBNET_NAME \
    --project=PROJECT_ID \
    --range=SUBNET_RANGE \
    --network=NETWORK_NAME \
    --region=REGION \
    --secondary-range=SECONDARY_RANGE_NAME=<SECONDARY_RANGE_RANGE>

Remplacez les éléments suivants :

  • SUBNET_NAME : nom du sous-réseau
  • PROJECT_ID : ID du projet qui contient le réseau VPC dans lequel le sous-réseau est créé.
  • SUBNET_RANGE : plage d'adresses IPv4 principale pour le nouveau sous-réseau, au format CIDR.
  • NETWORK_NAME : nom du réseau VPC contenant le nouveau sous-réseau.
  • REGION : région Google Cloud dans laquelle le nouveau sous-réseau est créé.
  • SECONDARY_RANGE_NAME : nom de la plage secondaire.
  • SECONDARY_IP_RANGE : plage d'adresses IPv4 secondaire au format CIDR.

Console

  1. Dans la console Google Cloud, accédez à la page Réseaux VPC.

  2. Cliquez sur Créer un réseau VPC.

  3. Dans le champ Nom, saisissez le nom du réseau. Exemple : l3-vpc.

  4. Dans le menu déroulant Unité de transmission maximale (MTU), choisissez la valeur de MTU appropriée.

  5. Dans la section Mode de création du sous-réseau, sélectionnez Personnalisé.

  6. Cliquez sur AJOUTER UN SOUS-RÉSEAU.

  7. Dans la section Nouveau sous-réseau, spécifiez les paramètres de configuration de sous-réseau suivants :

    1. Indiquez un Nom. Par exemple, l3-subnet.

    2. Sélectionnez une Région.

    3. Saisissez une plage d'adresses IP. Il s'agit de la plage d'adresses IPv4 principale du sous-réseau.

      Si vous sélectionnez une plage qui n'est pas une adresse RFC 1918, vérifiez qu'elle n'entre pas en conflit avec une configuration existante. Pour en savoir plus, consultez la section sur les plages de sous-réseaux IPv4.

    4. Pour définir une plage secondaire pour le sous-réseau, cliquez sur Créer une plage d'adresses IP secondaire.

      Si vous sélectionnez une plage qui n'est pas une adresse RFC 1918, vérifiez qu'elle n'entre pas en conflit avec une configuration existante. Pour en savoir plus, consultez la section sur les plages de sous-réseaux IPv4.

    5. Accès privé à Google : vous pouvez activer l'accès privé à Google, soit lorsque vous créez le sous-réseau, soit lorsque vous le modifiez ultérieurement.

    6. Journaux de flux : vous pouvez activer les journaux de flux VPC, soit lorsque vous créez le sous-réseau, soit lorsque vous le modifiez ultérieurement.

    7. Cliquez sur OK.

  8. Dans la section Règles de pare-feu, sous Règles de pare-feu IPv4, sélectionnez zéro ou plusieurs règles de pare-feu prédéfinies.

    Les règles traitent des cas d'utilisation courants de la connectivité à des instances. Vous pouvez créer vos propres règles de pare-feu après avoir créé le réseau. Chaque nom de règle prédéfini commence par le nom du réseau VPC que vous créez.

  9. Sous Règles de pare-feu IPv4, pour modifier la règle de pare-feu d'entrée prédéfinie nommée allow-custom, cliquez sur MODIFIER.

    Vous pouvez modifier les sous-réseaux, ajouter des plages IPv4 supplémentaires et spécifier des protocoles et des ports.

    La règle de pare-feu allow-custom n'est pas automatiquement mise à jour si vous ajoutez des sous-réseaux supplémentaires ultérieurement. Si vous avez besoin de règles de pare-feu pour les nouveaux sous-réseaux, vous devez mettre à jour la configuration du pare-feu pour ajouter les règles.

  10. Dans la section Mode de routage dynamique, pour le réseau VPC. Pour plus d'informations, consultez la documentation relative au Mode de routage dynamique. Vous pouvez modifier le mode de routage dynamique ultérieurement.

  11. Cliquez sur Créer.

Créer un réseau VPC compatible avec les appareils de type Netdevice ou DPDK

gcloud

gcloud compute networks subnets create SUBNET_NAME \
    --project=PROJECT_ID \
    --range=SUBNET_RANGE \
    --network=NETWORK_NAME \
    --region=REGION \
    --secondary-range=SECONDARY_RANGE_NAME=<SECONDARY_RANGE_RANGE>

Remplacez les éléments suivants :

  • SUBNET_NAME : nom du sous-réseau
  • PROJECT_ID : ID du projet qui contient le réseau VPC dans lequel le sous-réseau est créé.
  • SUBNET_RANGE : plage d'adresses IPv4 principale pour le nouveau sous-réseau, au format CIDR.
  • NETWORK_NAME : nom du réseau VPC contenant le nouveau sous-réseau.
  • REGION : région Google Cloud dans laquelle le nouveau sous-réseau est créé.
  • SECONDARY_RANGE_NAME : nom de la plage secondaire.
  • SECONDARY_IP_RANGE : plage d'adresses IPv4 secondaire au format CIDR.

Console

  1. Dans la console Google Cloud, accédez à la page Réseaux VPC.

  2. Cliquez sur Créer un réseau VPC.

  3. Dans le champ Nom, saisissez le nom du réseau. Par exemple, netdevice-vpc ou dpdk-vpc.

  4. Dans le menu déroulant Unité de transmission maximale (MTU), choisissez la valeur de MTU appropriée.

  5. Dans la section Mode de création du sous-réseau, sélectionnez Personnalisé.

  6. Dans la section Nouveau sous-réseau, spécifiez les paramètres de configuration de sous-réseau suivants :

    1. Indiquez un Nom. Par exemple, netdevice-subnet ou dpdk-vpc.

    2. Sélectionnez une Région.

    3. Saisissez une plage d'adresses IP. Il s'agit de la plage d'adresses IPv4 principale du sous-réseau.

      Si vous sélectionnez une plage qui n'est pas une adresse RFC 1918, vérifiez qu'elle n'entre pas en conflit avec une configuration existante. Pour en savoir plus, consultez la section sur les plages de sous-réseaux IPv4.

    4. Accès privé à Google : indiquez si vous souhaitez activer l'accès privé à Google, soit lorsque vous créez le sous-réseau, soit lorsque vous le modifiez ultérieurement.

    5. Journaux de flux : vous pouvez activer les journaux de flux VPC, soit lorsque vous créez le sous-réseau, soit lorsque vous le modifiez ultérieurement.

    6. Cliquez sur OK.

  7. Dans la section Règles de pare-feu, sous Règles de pare-feu IPv4, sélectionnez zéro ou plusieurs règles de pare-feu prédéfinies.

    Les règles traitent des cas d'utilisation courants de la connectivité à des instances. Vous pouvez créer vos propres règles de pare-feu après avoir créé le réseau. Chaque nom de règle prédéfini commence par le nom du réseau VPC que vous créez.

  8. Sous Règles de pare-feu IPv4, pour modifier la règle de pare-feu d'entrée prédéfinie nommée allow-custom, cliquez sur MODIFIER.

    Vous pouvez modifier les sous-réseaux, ajouter des plages IPv4 supplémentaires et spécifier des protocoles et des ports.

    La règle de pare-feu allow-custom n'est pas automatiquement mise à jour si vous ajoutez des sous-réseaux supplémentaires ultérieurement. Si vous avez besoin de règles de pare-feu pour les nouveaux sous-réseaux, vous devez mettre à jour la configuration du pare-feu pour ajouter les règles.

  9. Dans la section Mode de routage dynamique, pour le réseau VPC. Pour plus d'informations, consultez la documentation relative au Mode de routage dynamique. Vous pouvez modifier le mode de routage dynamique ultérieurement.

  10. Cliquez sur Créer.

Créer un cluster GKE avec des fonctionnalités multiréseaux

L'activation de la fonctionnalité multiréseau sur un cluster permet d'ajouter les définitions de ressources personnalisées nécessaires au serveur d'API pour ce cluster. Elle déploie également un gestionnaire de contrôleurs réseau, chargé du rapprochement et de la gestion des objets multiréseaux. Vous ne pouvez pas modifier la configuration du cluster après sa création.

Créer un cluster GKE Autopilot avec des fonctionnalités multiréseaux

Créez un cluster GKE Autopilot avec des fonctionnalités multiréseaux :

gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --enable-multi-networking

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster.
  • CLUSTER_VERSION : version du cluster.

L'option --enable-multi-networking active les définitions de ressources personnalisées (CRD) multiréseaux dans le serveur d'API pour ce cluster, et déploie un gestionnaire de contrôleurs réseau qui contient le rapprochement et la gestion du cycle de vie des objets multiréseaux.

Créer un cluster GKE Standard avec des fonctionnalités multiréseaux

gcloud

Créez un cluster GKE Standard avec des fonctionnalités multiréseaux :

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --enable-dataplane-v2 \
    --enable-ip-alias \
    --enable-multi-networking

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster.
  • CLUSTER_VERSION : version du cluster.

Cette commande inclut les options suivantes :

  • --enable-multi-networking: active les définitions de ressources personnalisées (CRD) multiréseaux dans le serveur d'API pour ce cluster, et déploie un gestionnaire de contrôleurs réseau qui contient le rapprochement et la gestion du cycle de vie des objets multiréseaux.
  • --enable-dataplane-v2: active GKE Dataplane V2. Cette option est requise pour activer le multiréseau.

Console

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

    Accéder à Google Kubernetes Engine

  2. Cliquez sur Créer.

  3. Configurez votre cluster Standard. Pour en savoir plus, consultez les sections Créer un cluster zonal ou Créer un cluster régional. Lors de la création du cluster, sélectionnez le réseau et le sous-réseau de nœud appropriés.

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

  5. Cochez la case Activer Dataplane V2.

  6. Sélectionnez Activer le multiréseau.

  7. Cliquez sur Créer.

Créer un pool de nœuds GKE Standard connecté à des VPC supplémentaires

Créez un pool de nœuds comprenant des nœuds connectés au réseau de nœuds (VPC et sous-réseau) et au réseau de pods (plage secondaire) créés dans la section Créer un réseau de pods.

Pour créer le pool de nœuds et l'associer aux réseaux supplémentaires du cluster GKE, procédez comme suit :

gcloud

gcloud container node-pools create POOL_NAME \
  --cluster=CLUSTER_NAME \
  --additional-node-network network=NETWORK_NAME,subnetwork=SUBNET_NAME \
  --additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=POD_IP_RANGE,max-pods-per-node=NUMBER_OF_PODS \
  --additional-node-network network=highperformance,subnetwork=subnet-highperf

Remplacez les éléments suivants :

  • POOL_NAME par le nom du nouveau pool de nœuds.
  • CLUSTER_NAME par le nom du cluster existant auquel vous ajoutez le pool de nœuds.
  • NETWORK_NAME par le nom du réseau auquel associer les nœuds du pool de nœuds.
  • SUBNET_NAME par le nom du sous-réseau au sein du réseau à utiliser pour les nœuds.
  • POD_IP_RANGE : plage d'adresses IP des pods dans le sous-réseau.
  • NUMBER_OF_PODS : nombre maximal de pods par nœud.

Cette commande contient les options suivantes :

  • --additional-node-network : définit les détails de l'interface réseau, du réseau et du sous-réseau supplémentaires. Cela permet de spécifier les réseaux de nœuds pour la connexion aux nœuds du pool de nœuds. Spécifiez ce paramètre si vous souhaitez vous connecter à un autre VPC. Si vous ne spécifiez pas ce paramètre, le VPC par défaut associé au cluster est utilisé. Pour les réseaux de type Layer 3, spécifiez l'option additional-pod-network qui définit le réseau de pods exposé dans le cluster GKE en tant qu'objet Network. Lorsque vous utilisez l'option --additional-node-network, vous devez indiquer un réseau et un sous-réseau en tant que paramètres obligatoires. Assurez-vous de séparer les valeurs du réseau et du sous-réseau par une virgule, et évitez d'utiliser des espaces.
  • --additional-pod-network : spécifie les détails de la plage secondaire à utiliser pour le réseau de pods. Ce paramètre n'est pas obligatoire si vous utilisez un réseau de type Device. Cet argument spécifie les valeurs de clé suivantes : subnetwork, pod-ipv4-range et max-pods-per-node. Lorsque vous utilisez --additional-pod-network, vous devez fournir les valeurs pod-ipv4-range et max-pods-per-node, séparées par une virgule et sans espaces.
    • subnetwork : associe le réseau de nœuds au réseau de pods. Le sous-réseau est facultatif. Si vous ne le spécifiez pas, le réseau de pods supplémentaire est associé au sous-réseau par défaut fourni lors de la création du cluster.
    • --max-pods-per-node : le paramètre max-pods-per-node doit être spécifié et doit être un multiple de 2. La valeur minimale est 4. La valeur max-pods-per-node ne doit pas être supérieure à la valeur max-pods-per-node du pool de nœuds.

Console

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

    Accéder à Google Kubernetes Engine

  2. Dans le volet de navigation, cliquez sur Clusters.

  3. Dans la section Clusters Kubernetes, cliquez sur le cluster que vous avez créé.

  4. En haut de la page, pour créer votre pool de nœuds, cliquez sur Ajouter un pool de nœuds.

  5. Dans la section Détails du pool de nœuds, procédez comme suit :

    1. Saisissez un nom pour le pool de nœuds.
    2. Saisissez le nombre de nœuds à créer dans le pool de nœuds.

  6. Dans le volet de navigation, cliquez sur Nœuds sous Pools de nœuds.

    1. Dans la liste déroulante Type d'image, sélectionnez l'image de nœud Container-Optimized OS avec containerd (cos_containerd).

  7. Lorsque vous créez une VM, vous sélectionnez un type de machine dans une famille de machines qui détermine les ressources disponibles pour cette VM. Par exemple, un type de machine tel que e2-standard-4 contient quatre processeurs virtuels et peut donc accepter jusqu'à quatre VPC au total. Vous pouvez faire votre choix parmi plusieurs familles de machines, organisées en séries qui regroupent chacune des types de machines prédéfinis ou personnalisés. Chaque type de machine est facturé différemment. Pour en savoir plus, consultez la grille tarifaire par type de machine.

  8. Dans le volet de navigation, sélectionnez Mise en réseau.

  9. Dans la section Mise en réseau de nœuds, spécifiez le nombre maximal de pods par nœud. La section "Réseaux de nœuds" affiche le réseau VPC utilisé pour créer le cluster. Il est nécessaire de désigner des réseaux de nœuds supplémentaires en corrélation avec les réseaux VPC et les types d'appareils précédemment établis.

  10. Créez une association de pool de nœuds :

    1. Pour l'appareil de type Layer 3 :
      1. Dans la section Réseaux de nœuds, cliquez sur AJOUTER UN RÉSEAU DE NŒUDS.
      2. Dans la liste déroulante "Réseau", sélectionnez le VPC compatible avec l'appareil de type couche 3.
      3. Sélectionnez le sous-réseau créé pour le VPC Layer 3.
      4. Dans la section Plages d'adresses IP d'alias pour les pods, cliquez sur Ajouter une plage d'adresses IP de pods.
      5. Sélectionnez le Sous-réseau secondaire et indiquez le Nombre maximal de pods par nœud.
      6. Sélectionnez OK.
    2. Pour les appareils de type Netdevice et DPDK :
      1. Dans la section Réseaux de nœuds, cliquez sur AJOUTER UN RÉSEAU DE NŒUDS.
      2. Dans la liste déroulante "Réseau", sélectionnez le VPC compatible avec les appareils de type Netdevice ou DPDK.
      3. Sélectionnez le sous-réseau créé pour le VPC Netdevice ou DPDK.
      4. Sélectionnez OK.

  11. Cliquez sur Créer.

Remarques :

  • Si plusieurs réseaux de pods supplémentaires sont spécifiés dans le même réseau de nœuds, ils doivent se trouver dans le même sous-réseau.
  • Vous ne pouvez pas référencer plusieurs fois la même plage secondaire d'un sous-réseau.

Exemple : L'exemple suivant crée un pool de nœuds nommé pool-multi-net qui associe deux réseaux supplémentaires aux nœuds, à savoir datapalane (réseau de type Layer 3) et highperformance (réseau de type netdevice). Dans cet exemple, nous partons du principe que vous avez déjà créé un cluster GKE nommé cluster-1 :

gcloud container node-pools create pool-multi-net \
  --project my-project \
  --cluster cluster-1 \
  --zone us-central1-c \
  --additional-node-network network=dataplane,subnetwork=subnet-dp \
  --additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-blue,max-pods-per-node=8 \
  --additional-node-network network=highperformance,subnetwork=subnet-highperf

Pour spécifier des interfaces de réseau de nœuds et de réseau de pods supplémentaires, définissez les paramètres --additional-node-network et --additional-pod-network plusieurs fois, comme indiqué dans l'exemple suivant :

--additional-node-network network=dataplane,subnetwork=subnet-dp \
--additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-blue,max-pods-per-node=8 \
--additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-green,max-pods-per-node=8 \
--additional-node-network network=managementdataplane,subnetwork=subnet-mp \
--additional-pod-network subnetwork=subnet-mp,pod-ipv4-range=sec-range-red,max-pods-per-node=4

Spécifiez des réseaux de pods supplémentaires directement dans l'interface du VPC principal du pool de nœuds, comme illustré dans l'exemple suivant :

--additional-pod-network subnetwork=subnet-def,pod-ipv4-range=sec-range-multinet,max-pods-per-node=8

Créer un réseau de pod

Définissez les réseaux de pods auxquels les pods accéderont en définissant des objets Kubernetes et en les associant aux ressources Compute Engine correspondantes, telles que les VPC, les sous-réseaux et les plages secondaires.

Pour créer un réseau de pod, vous devez définir les objets CRD réseau dans le cluster.

Configurer un réseau VPC Layer 3

YAML

Pour le VPC Layer 3, créez les objets Network et GKENetworkParamSet :

  1. Enregistrez l'exemple de fichier manifeste suivant sous le nom blue-network.yaml :

    apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: blue-network
spec:
  type: "L3"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: "l3-vpc"

    Le fichier manifeste définit une ressource Network nommée blue-network de type Layer 3. L'objet Network référence l'objet GKENetworkParamSet appelé l3-vpc, qui associe un réseau aux ressources Compute Engine.

  2. Appliquez le fichier manifeste au cluster :

    kubectl apply -f blue-network.yaml

  3. Enregistrez le fichier manifeste suivant sous le nom dataplane.yaml :

    apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: "l3-vpc"
spec:
  vpc: "l3-vpc"
  vpcSubnet: "subnet-dp"
  podIPv4Ranges:
    rangeNames:
    - "sec-range-blue"

    Ce fichier manifeste définit l'objet GKENetworkParamSet nommé dataplane, le nom du VPC sur dataplane, le nom du sous-réseau sur subnet-dp et la plage d'adresses IPv4 secondaire sec-range-blue des pods.

  4. Appliquez le fichier manifeste au cluster :

    kubectl apply -f dataplane.yaml

Console

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

    Accéder à Google Kubernetes Engine

  2. Dans le volet de navigation, cliquez sur Optimiseur de fonction réseau.

  3. En haut de la page, cliquez sur Créer pour créer votre réseau de pods.

  4. Dans la section Avant de commencer, vérifiez les détails.

  5. Cliquez sur SUIVANT : EMPLACEMENT DU RÉSEAU DE PODS.

  6. Dans la section Emplacement du réseau de pods, dans le menu déroulant Cluster, sélectionnez le cluster GKE sur lequel le multiréseau et GKE Dataplane V2 sont activés.

  7. Cliquez sur SUIVANT : RÉFÉRENCE DE RÉSEAU VPC.

  8. Dans la section Référence de réseau VPC, dans le menu déroulant Référence de réseau VPC, sélectionnez le réseau VPC utilisé pour les pods à plusieurs cartes d'interface réseau Layer 3.

  9. Cliquez sur SUIVANT : TYPE DE RÉSEAU DE PODS.

  10. Dans la section Type de réseau de pods, sélectionnez L3 et saisissez le nom du réseau de pods.

  11. Cliquez sur SUIVANT : PLAGE SECONDAIRE DU RÉSEAU DE PODS.

  12. Dans la section Plage secondaire du réseau de pods, saisissez la Plage secondaire.

  13. Cliquez sur SUIVANT : ROUTES DU RÉSEAU DE PODS.

  14. Dans la section Routes du réseau de pods, sélectionnez AJOUTER UNE ROUTE pour définir des Routes personnalisées.

  15. Cliquez sur CRÉER UN RÉSEAU DE PODS.

Configurer le réseau DPDK

YAML

Pour le VPC DPDK, créez les objets Network et GKENetworkParamSet.

  1. Enregistrez l'exemple de fichier manifeste suivant sous le nom dpdk-network.yaml :

    apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: dpdk-network
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: "dpdk"

    Ce fichier manifeste définit une ressource Network nommée dpdk-network de type Device. La ressource Network référence un objet GKENetworkParamSet appelé dpdk pour sa configuration.

  2. Appliquez le fichier manifeste au cluster :

    kubectl apply -f dpdk-network.yaml

  3. Pour l'objet GKENetworkParamSet, enregistrez le fichier manifeste suivant sous le nom dpdk.yaml :

    apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: "dpdk"
spec:
  vpc: "dpdk"
  vpcSubnet: "subnet-dpdk"
  deviceMode: "DPDK-VFIO"

    Ce fichier manifeste définit l'objet GKENetworkParamSet nommé dpdk, le nom du VPC sur dpdk, le nom du sous-réseau sur subnet-dpdk et le nom deviceMode sur DPDK-VFIO.

  4. Appliquez le fichier manifeste au cluster :

    kubectl apply -f dpdk-network.yaml

Console

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

    Accéder à Google Kubernetes Engine

  2. Dans le volet de navigation, cliquez sur Optimiseur de fonction réseau.

  3. En haut de la page, cliquez sur Créer pour créer votre réseau de pods.

  4. Dans la section Avant de commencer, vérifiez les détails.

  5. Cliquez sur SUIVANT : EMPLACEMENT DU RÉSEAU DE PODS.

  6. Dans la section Emplacement du réseau de pods, dans le menu déroulant Cluster, sélectionnez le cluster GKE sur lequel le multiréseau et GKE Dataplane V2 sont activés.

  7. Cliquez sur SUIVANT : RÉFÉRENCE DE RÉSEAU VPC.

  8. Dans la section Référence de réseau VPC, dans le menu déroulant Référence de réseau VPC, sélectionnez le réseau VPC utilisé pour les pods à plusieurs cartes d'interface réseau dpdk.

  9. Cliquez sur SUIVANT : TYPE DE RÉSEAU DE PODS.

  10. Dans la section Type de réseau de pods, sélectionnez DPDK-VFIO (Appareil) et saisissez le Nom du réseau de pods.

  11. Cliquez sur SUIVANT : PLAGE SECONDAIRE DU RÉSEAU DE PODS. La section "Plage secondaire du réseau de pods" ne sera pas disponible.

  12. Cliquez sur SUIVANT : ROUTES DU RÉSEAU DE PODS. Dans la section "Routes du réseau de pods", sélectionnez "AJOUTER UNE ROUTE" pour définir des routes personnalisées.

  13. Cliquez sur CRÉER UN RÉSEAU DE PODS.

Configurer le réseau netdevice

Pour le VPC netdevice, créez les objets Network et GKENetworkParamSet.

YAML

  1. Enregistrez l'exemple de fichier manifeste suivant sous le nom netdevice-network.yaml :

    apiVersion: networking.gke.io/v1
kind: Network
metadata:
    name: netdevice-network
spec:
    type: "Device"
    parametersRef:
      group: networking.gke.io
      kind: GKENetworkParamSet
      name: "netdevice"

    Ce fichier manifeste définit une ressource Network nommée netdevice-network de type Device. Il référence l'objet GKENetworkParamSet nommé netdevice.

  2. Appliquez le fichier manifeste au cluster :

    kubectl apply -f netdevice-network.yaml

  3. Enregistrez le fichier manifeste suivant sous le nom netdevice.yaml :

    apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: netdevice
spec:
  vpc: netdevice
  vpcSubnet: subnet-netdevice
  deviceMode: NetDevice

    Ce fichier manifeste définit une ressource GKENetworkParamSet nommée netdevice, le nom du VPC sur netdevice, le nom du sous-réseau sur subnet-netdevice et le mode de l'appareil sur NetDevice.

  4. Appliquez le fichier manifeste au cluster :

    kubectl apply -f netdevice.yaml

Console

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

    Accéder à Google Kubernetes Engine

  2. Dans le volet de navigation, cliquez sur Optimiseur de fonction réseau.

  3. En haut de la page, cliquez sur Créer pour créer votre réseau de pods.

  4. Dans la section Avant de commencer, vérifiez les détails.

  5. Cliquez sur SUIVANT : EMPLACEMENT DU RÉSEAU DE PODS.

  6. Dans la section Emplacement du réseau de pods, dans le menu déroulant Cluster, sélectionnez le cluster GKE sur lequel le multiréseau et GKE Dataplane V2 sont activés.

  7. Cliquez sur SUIVANT : RÉFÉRENCE DE RÉSEAU VPC.

  8. Dans la section Référence de réseau VPC, dans le menu déroulant Référence de réseau VPC, sélectionnez le réseau VPC utilisé pour les pods à plusieurs cartes d'interface réseau netdevice.

  9. Cliquez sur SUIVANT : TYPE DE RÉSEAU DE PODS.

  10. Dans la section Type de réseau de pods, sélectionnez NetDevice (Appareil) et saisissez le Nom du réseau de pods.

  11. Cliquez sur SUIVANT : PLAGE SECONDAIRE DU RÉSEAU DE PODS. La section "Plage secondaire du réseau de pods" ne sera pas disponible.

  12. Cliquez sur SUIVANT : ROUTES DU RÉSEAU DE PODS. Dans la section "Routes du réseau de pods", sélectionnez AJOUTER UNE ROUTE pour définir des routes personnalisées.

  13. Cliquez sur CRÉER UN RÉSEAU DE PODS.

Configurer des routes réseau

La configuration d'une route réseau vous permet de définir des routes personnalisées pour un réseau spécifique, qui sont configurées sur les pods pour acheminer le trafic vers l'interface correspondante au sein du pod.

YAML

  1. Enregistrez le manifeste suivant sous le nom red-network.yaml :

    apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: red-network
spec:
  type: "L3"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: "management"
  routes:
  -   to: "10.0.2.0/28"

    Ce fichier manifeste définit une ressource Network nommée red-network de type Layer 3 et une route personnalisée "10.0.2.0/28" via cette interface réseau.

  2. Appliquez le fichier manifeste au cluster :

    kubectl apply -f red-network.yaml

Console

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

    Accéder à Google Kubernetes Engine

  2. Cliquez sur Créer.

  3. Dans le volet de navigation, cliquez sur Optimiseur de fonction réseau.

  4. Dans la section Clusters Kubernetes, cliquez sur le cluster que vous avez créé.

  5. En haut de la page, cliquez sur Créer pour créer votre réseau de pods.

  6. Dans la section Routes du réseau de pods, définissez des Routes personnalisées.

  7. Cliquez sur CRÉER UN RÉSEAU DE PODS.

Référencer l'objet Network préparé

Dans la configuration de votre charge de travail, référencez l'objet Kubernetes Network préparé à l'aide de l'API Kubernetes.

Connecter un pod à des réseaux spécifiques

Pour connecter des pods aux réseaux spécifiés, vous devez inclure les noms des objets Network en tant qu'annotations dans la configuration du pod. Veillez à inclure à la fois default Network et les réseaux supplémentaires sélectionnés dans les annotations pour établir les connexions.

  1. Enregistrez l'exemple de fichier manifeste suivant sous le nom sample-l3-pod.yaml :

    apiVersion: v1
kind: Pod
metadata:
  name: sample-l3-pod
  annotations:
    networking.gke.io/default-interface: 'eth0'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth1","network":"blue-network"}
      ]
spec:
  containers:
  - name: sample-l3-pod
    image: busybox
    command: ["sleep", "10m"]
    ports:
    - containerPort: 80
  restartPolicy: Always

    Ce fichier manifeste crée un pod nommé sample-l3-pod avec deux interfaces réseau, eth0 et eth1, associées respectivement aux réseaux default et blue-network.

  2. Appliquez le fichier manifeste au cluster :

    kubectl apply -f sample-l3-pod.yaml

Connecter un pod à plusieurs réseaux

  1. Enregistrez l'exemple de fichier manifeste suivant sous le nom sample-l3-netdevice-pod.yaml :

    apiVersion: v1
kind: Pod
metadata:
  name: sample-l3-netdevice-pod
  annotations:
    networking.gke.io/default-interface: 'eth0'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth1","network":"blue-network"},
        {"interfaceName":"eth2","network":"netdevice-network"}
      ]
spec:
  containers:
  - name: sample-l3-netdevice-pod
    image: busybox
    command: ["sleep", "10m"]
    ports:
    - containerPort: 80
  restartPolicy: Always

    Ce fichier manifeste crée un pod nommé sample-l3-netdevice-pod avec trois interfaces réseau, eth0, eth1 et eth2, associées respectivement aux réseaux default, blue-network et netdevice.

  2. Appliquez le fichier manifeste au cluster :

    kubectl apply -f sample-l3-netdevice-pod.yaml

Vous pouvez utiliser la même annotation dans n'importe quel ReplicaSet (Deployment ou DaemonSet) de la section sur les annotations du modèle.

Exemple de configuration d'un pod avec plusieurs interfaces :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default
    link/ether 2a:92:4a:e5:da:35 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.60.45.4/24 brd 10.60.45.255 scope global eth0
      valid_lft forever preferred_lft forever
10: eth1@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default qlen 1000
    link/ether ba:f0:4d:eb:e8:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.16.1.2/32 scope global eth1
      valid_lft forever preferred_lft forever

Validation

  • Veillez à ne créer des clusters avec --enable-multi-networking que si --enable-dataplane-v2 est activé.
  • Vérifiez que tous les pools de nœuds du cluster exécutent des images Container-Optimized OS au moment de la création du cluster et du pool de nœuds.
  • Vérifiez que les pools de nœuds sont créés avec --additional-node-network ou --additional-pod-network uniquement si le multiréseau est activé sur le cluster.
  • Assurez-vous que le même sous-réseau n'est pas spécifié deux fois comme argument --additional-node-network pour un pool de nœuds.
  • Vérifiez que la même plage secondaire n'est pas spécifiée en tant qu'argument --additional-pod-network pour un pool de nœuds.
  • Suivez les limites de scaling spécifiées pour les objets réseau, en tenant compte du nombre maximal de nœuds, de pods et d'adresses IP autorisés.
  • Vérifiez qu'il n'y a qu'un seul objet GKENetworkParamSet faisant référence à un sous-réseau et à une plage secondaire spécifiques.
  • Vérifiez que chaque objet réseau fait référence à un objet GKENetworkParamSet différent.
  • Vérifiez que l'objet réseau (s'il est créé avec un sous-réseau spécifique avec le réseau Device) n'est pas utilisé sur le même nœud avec un autre réseau avec une plage secondaire. Vous ne pouvez le vérifier que lors de l'exécution.
  • Vérifiez que les différentes plages secondaires attribuées aux pools de nœuds ne comportent pas d'adresses IP qui se chevauchent.

Résoudre les problèmes de paramètres multiréseaux dans GKE

Lorsque vous créez un cluster et un pool de nœuds, Google Cloud met en œuvre certaines vérifications pour s'assurer que seuls les paramètres multiréseaux valides sont autorisés. Cela garantit que le réseau est correctement configuré pour le cluster.

Si vous ne parvenez pas à créer des charges de travail multiréseaux, vous pouvez vérifier l'état et les événements du pod pour plus d'informations :

kubectl describe pods samplepod

Le résultat ressemble à ce qui suit :

Name:         samplepod
Namespace:    default
Status:       Running
IP:           192.168.6.130
IPs:
  IP:  192.168.6.130
...
Events:
  Type     Reason                  Age   From               Message
  ----     ------                  ----  ----               -------
  Normal   NotTriggerScaleUp  9s               cluster-autoscaler  pod didn't trigger scale-up:
  Warning  FailedScheduling   8s (x2 over 9s)  default-scheduler   0/1 nodes are available: 1 Insufficient networking.gke.io.networks/my-net.IP. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod

Voici les raisons générales de l'échec de la création d'un pod :

  • Échec de la planification du pod en raison du non-respect des exigences des ressources multiréseaux
  • Échec de l'identification des réseaux spécifiés

Résoudre les problèmes de création de réseaux Kubernetes

Une fois que vous avez créé un réseau, les nœuds qui doivent avoir accès au réseau configuré sont annotés avec l'état du réseau.

Pour observer les annotations, exécutez la commande suivante :

kubectl describe node NODE_NAME

Remplacez NODE_NAME par le nom du nœud.

Le résultat ressemble à ce qui suit :

networking.gke.io/network-status: [{"name":"default"},{"name":"dp-network"}]

Le résultat répertorie les réseaux disponibles sur le nœud. Si l'état du réseau attendu n'est pas visible sur le nœud, procédez comme suit :

Vérifier si le nœud peut accéder au réseau

Si le réseau ne s'affiche pas dans l'annotation de l'état du réseau du nœud :

  1. Vérifiez que le nœud fait partie d'un pool configuré pour le multiréseau.
  2. Vérifiez les interfaces du nœud pour voir s'il possède une interface pour le réseau que vous configurez.
  3. Si un nœud n'a pas d'état réseau et ne dispose que d'une seule interface réseau, vous devez toujours créer un pool de nœuds sur lequel le multiréseau est activé.
  4. Si votre nœud contient l'interface du réseau que vous configurez, mais qu'elle ne s'affiche pas dans l'annotation d'état du réseau, vérifiez les ressources Network et GKENetworkParamSet (GNP).

Vérifier les ressources Network et GKENetworkParamSet

L'état des ressources Network et GKENetworkParamSet (GNP) inclut un champ de conditions pour signaler les erreurs de configuration. Nous vous recommandons de commencer par vérifier le GNP, car il ne repose pas sur une autre ressource pour être valide.

Pour inspecter le champ des conditions, exécutez la commande suivante :

kubectl get gkenetworkparamsets GNP_NAME -o yaml

Remplacez GNP_NAME par le nom de la ressource GKENetworkParamSet.

Lorsque la condition Ready est égale à "true", la configuration est valide et le résultat ressemble à ce qui suit :

apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
...
spec:
  podIPv4Ranges:
    rangeNames:
    -   sec-range-blue
  vpc: dataplane
  vpcSubnet: subnet-dp
status:
  conditions:
  -   lastTransitionTime: "2023-06-26T17:38:04Z"
    message: ""
    reason: GNPReady
    status: "True"
    type: Ready
  networkName: dp-network
  podCIDRs:
    cidrBlocks:
    -   172.16.1.0/24

Lorsque la condition Ready est égale à "false", le résultat affiche un motif et ressemble à ce qui suit :

apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
...
spec:
  podIPv4Ranges:
    rangeNames:
    -   sec-range-blue
  vpc: dataplane
  vpcSubnet: subnet-nonexist
status:
  conditions:
  -   lastTransitionTime: "2023-06-26T17:37:57Z"
    message: 'subnet: subnet-nonexist not found in VPC: dataplane'
    reason: SubnetNotFound
    status: "False"
    type: Ready
  networkName: ""

Si vous rencontrez un message similaire, assurez-vous que votre GNP a été correctement configuré. Si c'est le cas, vérifiez que la configuration de votre réseau Google Cloud est correcte. Après avoir mis à jour la configuration du réseau Google Cloud, vous devrez peut-être recréer la ressource GNP pour déclencher manuellement une resynchronisation. Cela permet d'éviter l'interrogation infinie de l'API Google Cloud.

Une fois que le GNP est prêt, vérifiez la ressource Network.

kubectl get networks NETWORK_NAME -o yaml

Remplacez NETWORK_NAME par le nom de la ressource Network.

Le résultat d'une configuration valide ressemble à ce qui suit :

apiVersion: networking.gke.io/v1
kind: Network
...
spec:
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: dp-gnp
  type: L3
status:
  conditions:
  -   lastTransitionTime: "2023-06-07T19:31:42Z"
    message: ""
    reason: GNPParamsReady
    status: "True"
    type: ParamsReady
  -   lastTransitionTime: "2023-06-07T19:31:51Z"
    message: ""
    reason: NetworkReady
    status: "True"
    type: Ready
  • reason: NetworkReady indique que la ressource Network est correctement configurée. reason: NetworkReady ne signifie pas que la ressource Network est nécessairement disponible sur un nœud spécifique ou utilisée activement.
  • En cas de configuration incorrecte ou d'erreur, le champ reason de la condition spécifie le motif exact du problème. Dans ce cas, ajustez la configuration en conséquence.
  • GKE renseigne le champ ParamsReady si le champ parametersRef est défini sur une ressource GKENetworkParamSet qui existe dans le cluster. Si vous avez spécifié un parametersRef de type GKENetworkParamSet et que la condition n'apparaît pas, assurez-vous que le nom, le genre et le groupe correspondent à la ressource GNP qui existe dans votre cluster.

Étapes suivantes