Cette page explique comment configurer des plages d'adresses IPv4 de pods supplémentaires pour un cluster de VPC natif et comment spécifier des plages d'adresses IPv4 de pods personnalisées pour les pools de nœuds d'un cluster de VPC natif.
Les plages d'adresses IPv4 des pods dans les clusters de VPC natif proviennent toujours des plages d'adresses IPv4 secondaires du sous-réseau. Lorsque vous créez un cluster, vous lui attribuez une plage d'adresses IPv4 de pod par défaut.
- Pour les clusters Autopilot et Standard, vous pouvez configurer un cluster pour utiliser des plages d'adresses IPv4 de pods supplémentaires. GKE utilise ces plages d'adresses IPv4 de pods supplémentaires pour les adresses IPv4 de pod sur les nœuds créés dans les futurs pools de nœuds.
- Pour les clusters standards, vous pouvez créer des pools de nœuds qui utilisent chacun une plage d'adresses IPv4 secondaire de sous-réseau personnalisé pour leurs adresses IPv4 de pod.
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
.
- Assurez-vous de disposer du rôle IAM (Identity and Access Management) Administrateur de réseaux Compute pour le projet contenant le sous-réseau du cluster. Cette opération est nécessaire pour créer des plages d'adresses IPv4 secondaires de sous-réseau. Lorsque vous utilisez un VPC partagé, vous devez contacter l'administrateur réseau du projet hôte de VPC partagé.
- Assurez-vous que votre cluster GKE est un cluster de VPC natif. Les clusters basés sur le routage ne sont pas compatibles avec les plages d'adresses IPv4 de pods supplémentaires ou les plages d'adresses IPv4 de pods personnalisées pour les pools de nœuds.
- Consultez la section Procédure à suivre.
Créer une plage d'adresses IPv4 secondaire de sous-réseau
Pour créer une plage d'adresses IPv4 secondaire de sous-réseau, utilisez la console Google Cloud ou Google Cloud CLI. Chaque sous-réseau accepte jusqu'à 30 plages d'adresses IPv4 secondaires. Pour en savoir plus, consultez la page Modifier les plages IPv4 secondaires dans la documentation sur les VPC.
Console
Accédez à la page Réseaux VPC de Google Cloud Console.
Dans la liste Réseaux VPC, sélectionnez le réseau que vous souhaitez étendre.
Dans la liste Sous-réseaux, sélectionnez le sous-réseau souhaité.
Cliquez sur Modifier.
Cliquez sur Ajouter une plage d'adresses IP.
Dans Nom de la plage de sous-réseau, saisissez le nom de la nouvelle plage d'adresses IPv4 secondaire du sous-réseau. Exemple :
pod-range-2
Dans Plage d'adresses IP secondaire, saisissez la plage d'adresses IPv4 au format CIDR. Exemple :
10.2.204.0/22
Cliquez sur Enregistrer.
gcloud
gcloud compute networks subnets update SUBNET_NAME \
--region=REGION \
--add-secondary-ranges=SECONDARY_RANGE_NAME=SECONDARY_RANGE_CIDR
Remplacez les éléments suivants :
SUBNET_NAME
: nom du sous-réseau du cluster (même sous-réseau attribué au cluster lors de sa création).REGION
: région du sous-réseau de sous-réseau du cluster. La région du sous-réseau du cluster est celle qui contient le cluster GKE.SECONDARY_RANGE_NAME
: nom de la nouvelle plage d'adresses IPv4 secondaire du sous-réseau à utiliser comme plage d'adresses IPv4 de pod supplémentaire pour le cluster. Exemple :pod-range-2
SECONDARY_RANGE_CIDR
: CIDR à utiliser par la nouvelle plage d'adresses IPv4 secondaire du sous-réseau. Exemple :10.2.204.0/22
Vous pouvez ajouter au moins deux nouvelles plages d'adresses IPv4 secondaires de sous-réseau en spécifiant des paires SECONDARY_RANGE_NAME
=SECONDARY_RANGE_CIDR
supplémentaires, séparées par une virgule, après l'option --add-secondary-ranges
.
Attribuer des plages IPv4 de pods supplémentaires à un cluster
Vous pouvez attribuer des plages d'adresses IPv4 de pod supplémentaires au niveau du cluster, applicables aux nœuds créés dans les pools de nœuds que vous créez dans le cluster. Pour attribuer des plages d'adresses IPv4 de pods supplémentaires à un cluster, vous devez d'abord créer une plage d'adresses IPv4 secondaire de sous-réseau.
L'attribution de plages d'adresses IPv4 de pods supplémentaires à un cluster est prise en charge sur :
- Les clusters Autopilot exécutant la version 1.26 de GKE ou une version ultérieure
- Les clusters standards
Console
Accédez à la page Google Kubernetes Engine dans Google Cloud Console.
À côté du cluster que vous souhaitez modifier, cliquez sur more_vertActions, puis sur edit Modifier.
Dans la section Mise en réseau, à côté de Plages IPv4 de pod du cluster (supplémentaires), cliquez sur edit Modifier.
Dans la boîte de dialogue Modifier les plages IPv4 de pod de cluster supplémentaires, cliquez sur Plages CIDR secondaires des pods et sélectionnez le ou les noms d'une ou de plusieurs plages d'adresses IPv4 secondaires de sous-réseau existants dans le sous-réseau du cluster. Si aucune plage d'adresses IPv4 secondaire de sous-réseau supplémentaire n'est disponible, commencez par créer une plage d'adresses IPv4 secondaire de sous-réseau, puis répétez ces étapes.
Cliquez sur Save Changes (Enregistrer les modifications).
gcloud
Mettez à jour votre cluster à l'aide de l'option
--additional-pod-ipv4-ranges
:gcloud container clusters update CLUSTER_NAME \ --additional-pod-ipv4-ranges=SECONDARY_RANGE_NAME \ --location=COMPUTE_LOCATION
Remplacez les éléments suivants :
CLUSTER_NAME
: nom du cluster.SECONDARY_RANGE_NAME
: nom d'une ou de plusieurs plages d'adresses IPv4 secondaires de sous-réseau existantes dans le sous-réseau du cluster, séparées par une virgule. Si aucune plage d'adresses IPv4 secondaire de sous-réseau n'est disponible, commencez par créer une plage d'adresses IPv4 secondaire de sous-réseau.COMPUTE_LOCATION
: emplacement Compute Engine du cluster.
Rechercher des plages IPv4 de pods de cluster
Pour rechercher la plage d'adresses IPv4 de pod par défaut d'un cluster et toutes les plages d'adresses IPv4 de pod supplémentaires qui ont été attribuées au cluster, utilisez la commande suivante :
gcloud container clusters describe CLUSTER_NAME \
--location=COMPUTE_LOCATION
Remplacez les éléments suivants :
CLUSTER_NAME
: nom du cluster.COMPUTE_LOCATION
: emplacement Compute Engine du cluster.
Le résultat ressemble à celui ci-dessous, qui inclut la règle IPAllocationPolicy du cluster :
ipAllocationPolicy:
clusterSecondaryRangeName: cluster-pods
clusterIpv4CidrBlock: 10.10.0.0/23
additionalPodRangesConfig:
podRangeNames:
- pod-range-1
- pod-range-2
où :
clusterSecondaryRangeName
: nom de la plage d'adresses IPv4 secondaire du sous-réseau utilisée comme plage d'adresses IPv4 de pod par défaut du cluster, définie lors de la création du cluster.clusterIpv4CidrBlock
: CIDR de la plage d'adresses IPv4 secondaire du sous-réseau pour les adresses IPv4 de pod, définie lors de la création du cluster.additionalPodRangesConfig.podRangeNames
: liste de toute plage d'adresses IPv4 secondaire de sous-réseau supplémentaire attribuée pour les adresses IPv4 de pods.
Plages d'adresses IPv4 de pods personnalisées pour un pool de nœuds
Pour les clusters standards exécutant GKE 1.20.4-gke.500 ou une version ultérieure, vous pouvez attribuer une plage IPv4 de pods personnalisée à un nouveau pool de nœuds à l'aide de l'une des méthodes suivantes :
Plage d'adresses IPv4 de pods personnalisée de pool de nœuds, gérée par GKE : avec cette option, vous créez un pool de nœuds et fournissez à GKE les informations nécessaires pour créer une plage d'adresses IPv4 secondaire de sous-réseau dans le sous-réseau du cluster. Chaque nouveau nœud créé dans le nouveau pool de nœuds se voit attribuer une plage d'adresses IP d'alias pour ses adresses IPv4 de pod, et chaque plage d'adresses IP d'alias provient de la nouvelle plage d'adresses IPv4 secondaire de sous-réseau créée par GKE. Cette option ne peut être utilisée que si le cluster et le réseau VPC contenant le sous-réseau du cluster se trouvent dans le même projet.
Plage d'adresses IPv4 de pods personnalisée de pool de nœuds, gérée par l'utilisateur : avec cette option, vous créez un pool de nœuds dans lequel GKE utilise une plage d'adresses IPv4 secondaire de sous-réseau existante. Chaque nouveau nœud créé dans le nouveau pool de nœuds se voit attribuer une plage d'adresses IP d'alias pour ses adresses IPv4 de pod, et chaque plage d'adresses IP d'alias provient de la plage d'adresses IPv4 secondaire de sous-réseau que vous indiquez à GKE d'utiliser. Si votre cluster est situé dans un projet de service de VPC partagé et que le sous-réseau de votre cluster se trouve sur le réseau VPC partagé du projet hôte, vous devez utiliser cette option.
La plage d'adresses IPv4 de pods personnalisée d'un pool de nœuds remplace toutes les plages d'adresses IPv4 de pods définies au niveau du cluster, y compris les plages d'adresses IPv4 de pods supplémentaires attribuées au cluster. Les plages d'adresses IPv4 de pods personnalisées attribuées aux pools de nœuds sont également appelées CIDR multipods non contigue.
Exemple de plage d'adresses IPv4 de pods personnalisée de pool de nœuds
Le schéma suivant représente un cluster de VPC natif avec des plages d'adresses IPv4 de pods gérées par l'utilisateur :
Dans le schéma précédent :
- Le nombre maximal de pods par nœud pour chaque pool de nœuds du cluster a été défini sur
64
. Pour gérer un maximum de 64 pods par nœud, GKE crée chaque nœud avec une plage d'adresses IP d'alias/25
, en fournissant128
adresses IPv4 de pod par nœud. - La plage d'adresses IPv4 de pods par défaut du cluster est une plage
/24
. Étant donné que chaque nœud nécessite une plage/25
pour les adresses IPv4 de pod, la plage d'adresses IPv4 de pods par défaut du cluster n'accepte que deux nœuds. - Pour pouvoir prendre en charge des nœuds supplémentaires, un administrateur de cluster a créé un pool de nœuds supplémentaire, en maintenant le nombre maximal de
64
pods par nœud. Le pool de nœuds supplémentaire utilise une plage d'adresses IPv4 de pods personnalisée/20
, qui accepte 32 nœuds supplémentaires.
Plage d'adresses IPv4 de pods personnalisée de pool de nœuds, gérée par GKE
Pour créer un pool de nœuds avec une plage d'adresses IPv4 de pods personnalisée gérée par GKE, utilisez gcloud CLI ou l'API GKE comme suit :
gcloud
gcloud container node-pools create POOL_NAME \
--cluster=CLUSTER_NAME \
--location=COMPUTE_LOCATION \
--create-pod-ipv4-range=name=SECONDARY_RANGE_NAME,range=CIDR_OR_NETMASK
Remplacez les éléments suivants :
POOL_NAME
: nom du nouveau pool de nœuds.CLUSTER_NAME
: nom du cluster.COMPUTE_LOCATION
: emplacement Compute Engine du cluster.SECONDARY_RANGE_NAME
: nom de la plage d'adresses IPv4 secondaire de sous-réseau créée par GKE. Si vous omettezname=SECONDARY_RANGE_NAME
, GKE génère automatiquement le nom de la nouvelle plage d'adresses IPv4 secondaire du sous-réseau.CIDR_OR_NETMASK
: plage d'adresses IPv4 de pods exprimée au format CIDR (par exemple,10.12.4.0/20
) ou sous forme de masque de sous-réseau (par exemple,/20
).- Si vous ne fournissez qu'un masque de sous-réseau, GKE tente de créer une plage d'adresses IPv4 secondaire de sous-réseau qui n'entre pas en conflit avec les plages d'adresses IPv4 de sous-réseau existantes dans le réseau VPC contenant le sous-réseau du cluster.
- Si vous omettez
range=CIDR_OR_NETMASK
, GKE tente de créer une plage d'adresses IPv4 secondaire de sous-réseau/14
qui n'entre pas en conflit avec les plages d'adresses IPv4 de sous-réseau existantes dans le réseau VPC contenant le sous-réseau du cluster.
API
"nodePool": {
"name": "POOL_NAME",
...
"networkConfig": {
"createPodRange": true,
"podRange": "SECONDARY_RANGE_NAME",
"podIpv4CidrBlock": "CIDR_OR_NETMASK"
}
}
Remplacez les éléments suivants :
POOL_NAME
: nom du nouveau pool de nœuds.SECONDARY_RANGE_NAME
(facultatif) : nom de la plage d'adresses IPv4 secondaire de sous-réseau créée par GKE. Si vous utilisez""
comme valeur pournetworkConfig.podRange
ou si vous omettez le paramètrepodRange
dans la requête, GKE génère automatiquement le nom de la nouvelle plage d'adresses IPv4 secondaire de sous-réseau.CIDR_OR_NETMASK
: plage d'adresses IPv4 de pods exprimée au format CIDR (par exemple,10.12.4.0/20
) ou sous forme de masque de sous-réseau (par exemple,/20
).- Si vous ne fournissez qu'un masque de sous-réseau, GKE tente de créer une plage d'adresses IPv4 secondaire de sous-réseau qui n'entre pas en conflit avec les plages d'adresses IPv4 de sous-réseau existantes dans le réseau VPC contenant le sous-réseau du cluster.
- Si vous utilisez
""
comme valeur pournetworkConfig.podIpv4CidrBlock
, GKE tente de créer une plage d'adresses IPv4 secondaire de sous-réseau/14
qui n'entre pas en conflit avec les plages d'adresses IPv4 de sous-réseau existantes au sein du réseau VPC contenant le sous-réseau du cluster.
Plage d'adresses IPv4 de pods personnalisée de pool de nœuds, gérée par l'utilisateur
Pour créer un pool de nœuds avec une plage d'adresses IPv4 de pods personnalisée gérée par l'utilisateur, utilisez gcloud CLI ou l'API GKE comme suit :
gcloud
gcloud container node-pools create POOL_NAME \
--cluster=CLUSTER_NAME \
--location=COMPUTE_LOCATION \
--pod-ipv4-range SECONDARY_RANGE_NAME
Remplacez les éléments suivants :
POOL_NAME
: nom du nouveau pool de nœuds.CLUSTER_NAME
: nom du cluster.COMPUTE_LOCATION
: emplacement Compute Engine du cluster.SECONDARY_RANGE_NAME
: nom d'une plage d'adresses IPv4 secondaire de sous-réseau existante dans le sous-réseau du cluster. Si nécessaire, créez d'abord une plage d'adresses IPv4 secondaire de sous-réseau.
API
"nodePool": {
"name": "POOL_NAME",
...
"networkConfig": {
"createPodRange": false,
"podRange": "SECONDARY_RANGE_NAME"
}
}
Remplacez les éléments suivants :
POOL_NAME
: nom du nouveau pool de nœuds.SECONDARY_RANGE_NAME
: nom d'une plage d'adresses IPv4 secondaire de sous-réseau existante dans le sous-réseau du cluster. Si nécessaire, créez d'abord une plage d'adresses IPv4 secondaire de sous-réseau.
Rechercher des plages IPv4 de pods de pool de nœuds
Pour rechercher la plage d'adresses IPv4 de pods d'un pool de nœuds, utilisez la commande suivante :
gcloud container node-pools describe POOL_NAME \
--cluster=CLUSTER_NAME \
--location=COMPUTE_LOCATION
Remplacez les éléments suivants :
POOL_NAME
: nom du pool de nœuds.CLUSTER_NAME
: nom du cluster.COMPUTE_LOCATION
: emplacement Compute Engine du cluster.
Le résultat ressemble à celui ci-dessous, qui inclut l'élément NodeNetworkConfig du pool de nœuds :
networkConfig:
podRange: podrange
podIpv4CidrBlock: 192.168.0.0/18
où :
podRange
: nom de la plage d'adresses IPv4 secondaire du sous-réseau pour les adresses IPv4 de pods du pool de nœuds.podIpv4CidrBlock
: CIDR de la plage d'adresses IPv4 secondaire du sous-réseau pour les adresses IPv4 de pods du pool de nœuds.
Si le pool de nœuds utilise une plage d'adresses IPv4 de pods personnalisée, les valeurs podRange
et podIpv4CidrBlock
sont différentes de la plage d'adresses IPv4 de pods par défaut du cluster.
Procédure à suivre
Une fois que vous avez attribué des plages d'adresses IPv4 de pods supplémentaires à un cluster ou configuré des plages d'adresses IPv4 de pods personnalisées pour le pool de nœuds, GKE met à jour la règle de pare-feu VPC gke-[cluster-name]-[cluster-hash]-all
créée automatiquement afin que sa plage source inclut toutes les adresses IPv4 des pods.
Vous devrez peut-être également :
Mettez à jour la configuration de l'agent de masquage d'adresses IP de votre cluster. L'ensemble effectif de CIDR non masqués doit inclure toutes les plages d'adresses IPv4 de pods utilisées par votre cluster (et ses pools de nœuds). Pour en savoir plus, consultez les pages Vérifier l'état de
ip-masq-agent
et Configurer et déployer la ressourceip-masq-agent
.Vérifiez la configuration
NetworkPolicy
de votre cluster. Vous devrez peut-être mettre à jour les attributsipBlock
qui font référence aux plages d'adresses IPv4 des pods.Résolvez les problèmes de connectivité à l'aide des journaux de flux VPC et de la journalisation des règles de pare-feu.
Étapes suivantes
- Apprenez-en plus sur les clusters de VPC natif.
- Lisez la présentation du réseau GKE.
- Apprenez-en plus sur l'optimisation de l'attribution des adresses IP.