Ajouter des plages d'adresses IP de pods


Vous trouverez sur cette page la procédure à suivre pour activer le CIDR multipods non contigu dans les clusters Google Kubernetes Engine (GKE) natifs VPC.

Présentation

Avec le CIDR multipods non contigu, vous pouvez ajouter de nouvelles plages d'adresses IP secondaires aux pods, qu'elles soient nouvelles ou existantes, à des clusters GKE.

Lorsque vous créez un pool de nœuds, celui-ci utilise par défaut la plage d'adresses IP des pods par défaut du cluster, également appelée CIDR du cluster. Cette fonctionnalité vous permet de spécifier une plage d'adresses IP de pod lors de la création du pool de nœuds. Le pool de nœuds utilise cette plage plutôt que la plage d'adresses IP des pods par défaut du cluster.

Le schéma suivant montre un cluster géré par l'utilisateur avec un bloc CIDR /24 en tant que plage d'adresses IP de pod secondaire (256 adresses IP) et deux nœuds utilisant /25 Blocs CIDR pour les adresses IP des pods (128 adresses IP chacune) La plage d'adresses IP du pod secondaire est épuisée, et vous ne pouvez pas ajouter un autre nœud au cluster. Au lieu de supprimer et de recréer le cluster, vous pouvez utiliser un CIDR multipod distinct pour créer un pool de nœuds. Le cluster se développe pour inclure un troisième nœud qui utilise un bloc CIDR /28 pour les adresses IP des pods.

Ajouter un pool de nœuds à un cluster avec une plage d'adresses IP de pod secondaire épuisée à l'aide d'un masque CIDR multipod
Schéma : Utilisation d'un CIDR multipod non contigu

Avantages

  • Vous n'avez pas à planifier l'évolution future avant de créer des clusters, ce qui permet une attribution d'adresses IP plus efficace.
  • Vous pouvez intégrer des clusters dans des espaces d'adresses IP fragmentés.
  • Vous pouvez réattribuer des adresses IP en réponse aux besoins de votre entreprise.

Limites

  • Le CIDR multipods non contigu est uniquement disponible dans les clusters de VPC natif.
  • Tous les pools de nœuds du cluster doivent s'exécuter sur les versions 1.19.8-gke.1000 à 1.20 ou 1.20.4-gke.500 et ultérieures.
  • Le CIDR multipods non contigu doit s'exécuter sur la version 330 du SDK Cloud ou une version ultérieure.
  • Vous ne pouvez pas modifier la plage d'adresses IP de pod secondaire d'un pool de nœuds après sa création. Toutefois, vous pouvez créer un pool de nœuds avec une nouvelle plage et faire pivoter les charges de travail vers le nouveau pool de nœuds.
  • Le CIDR multipods non contigu ne peut pas être utilisé avec les services multiclusters.

Mises en garde

  • Si vous utilisez ip-masq-agent configuré avec le paramètre nonMasqueradeCIDRs, vous devez mettre à jour nonMasqueradeCIDRs pour inclure toutes les plages CIDR des pods.
  • Si vous utilisez NetworkPolicy configuré avec ipBlock pour spécifier le trafic, vous devez mettre à jour la valeur cidr pour inclure toutes les plages CIDR des pods.

Règle de pare-feu modifiée

Lorsque GKE crée un cluster, il crée une règle de pare-feu pour permettre la communication entre les pods, gke-[cluster-name]-[cluster-hash]-all.

Lorsque vous créez ou supprimez un pool de nœuds avec le CIDR multipods non contigu activé, GKE met à jour la valeur source de cette règle de pare-feu vers tous les CIDR utilisés par le cluster pour les adresses IP de pod.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

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

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

Utiliser gcloud init

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

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

    gcloud init

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

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

Utiliser gcloud config

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

Créer un pool de nœuds avec une nouvelle plage d'adresses IP de pod secondaire

Dans cette section, vous allez créer un pool de nœuds avec une plage d'adresses IP de pod secondaire.

Vous pouvez utiliser l'outil de ligne de commande gcloud ou l'API GKE.

gcloud

gcloud beta container node-pools create POOL_NAME \
  --cluster CLUSTER_NAME \
  --create-pod-ipv4-range name=RANGE_NAME,range=RANGE

Remplacez l'élément suivant :

  • POOL_NAME : nom du nouveau pool de nœuds.
  • CLUSTER_NAME : nom du cluster.
  • RANGE_NAME : nom facultatif de la nouvelle plage d'adresses IP du pod secondaire.
  • RANGE : plage d'adresses IP de pod facultative fournie sous forme de masque de réseau (/20) ou de plage CIDR (10.12.4.0/20). Si vous fournissez un masque de réseau, GKE alloue une plage à partir des plages disponibles dans le réseau de cluster. Si vous ne fournissez pas de valeur pour range, GKE alloue automatiquement un masque de réseau /14, la taille par défaut pour la plage d'adresses IP secondaire des pods du sous-réseau.

API

"nodePool": {
  "name": "POOL_NAME",
  ...
  "networkConfig": {
    "createPodRange": true,
    "podRange": "RANGE_NAME",
    "podIpv4CidrBlock": "RANGE"
  }
}

Remplacez l'élément suivant :

  • POOL_NAME : nom du nouveau pool de nœuds.
  • RANGE_NAME : nom facultatif de la nouvelle plage d'adresses IP du pod secondaire.
  • RANGE : plage d'adresses IP facultative du pod fournie sous la forme d'un masque de réseau (/20) ou d'une plage CIDR (10.12.0.0/20). Si un masque de réseau est spécifié, la plage d'adresses IP est automatiquement attribuée à l'espace libre du réseau. Si aucune valeur n'est spécifiée, GKE alloue automatiquement un masque de réseau /14, la taille par défaut de la plage d'adresses IP secondaire du sous-réseau pour les pods.

Créer un pool de nœuds à l'aide d'une plage d'adresses IP de pod secondaire existante

Dans cette section, vous allez créer un pool de nœuds avec une plage d'adresses IP de pod secondaire existante.

Vous pouvez utiliser l'outil gcloud ou l'API GKE.

gcloud

gcloud beta container node-pools create POOL_NAME \
  --cluster CLUSTER_NAME \
  --pod-ipv4-range RANGE_NAME

Remplacez l'élément suivant :

  • POOL_NAME : nom du nouveau pool de nœuds.
  • CLUSTER_NAME : nom du cluster.
  • RANGE_NAME : nom d'une plage d'adresses IP de pod secondaire existante dans le sous-réseau du cluster.

API

"nodePool": {
  "name": "POOL_NAME",
  ...
  "networkConfig": {
    "podRange": "RANGE_NAME"
  }
}

Remplacez l'élément suivant :

  • POOL_NAME : nom du nouveau pool de nœuds.
  • RANGE_NAME : nom d'une plage d'adresses IP de pod secondaire existante dans le sous-réseau du cluster.

Vérifier le bloc CIDR du pod d'un pool de nœuds

Pour identifier le bloc CIDR du pod utilisé pour les pods d'un pool de nœuds donné, exécutez la commande suivante :

gcloud beta container node-pools describe POOL_NAME \
  --cluster CLUSTER_NAME

Le résultat ressemble à ce qui suit :

...
networkConfig:
  podIpv4CidrBlock: 192.168.0.0/18
  podRange: podrange
...

Si le pool de nœuds utilise le CIDR multipods non contigu, podRange et podIpv4CidrBlock affichent les valeurs configurées pour ce pool de nœuds.

Si le pool de nœuds n'utilise pas un CIDR multipods non contigu, podRange et podIpv4CidrBlock affichent les valeurs par défaut du cluster, clusterSecondaryRangeName et clusterIpv4CidrBlock à partir d'IPAllocationPolicy.

Dépannage

Vous pouvez activer les journaux de flux VPC pour déterminer si les paquets sont envoyés correctement aux nœuds.

Étape suivante