Cette page explique comment attribuer des sous-réseaux supplémentaires à un cluster de VPC natif. Les sous-réseaux supplémentaires attribués à un cluster vous permettent de créer des pools de nœuds dans lesquels les adresses IPv4 des nœuds et des pods proviennent des plages de sous-réseaux supplémentaires.
Cette page s'adresse aux spécialistes de la mise en réseau qui conçoivent et implémentent le réseau pour leur organisation. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans Cloud de Confiance by S3NS le contenu, consultez Rôles utilisateur et tâches courantes de GKE.
Présentation
Lorsque vous créez un cluster GKE de VPC natif, vous sélectionnez un sous-réseau par défaut pour le cluster. Le sous-réseau par défaut du cluster fournit des adresses IPv4 pour les nœuds, les pods et les services, comme décrit dans la section Plages d'adresses IP pour les clusters de VPC natif.
Vous pouvez attribuer jusqu'à huit sous-réseaux supplémentaires à un cluster de VPC natif, ce qui permet une croissance significative du cluster. Chaque sous-réseau supplémentaire nouvellement attribué est appelé sous-réseau non par défaut.
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 et 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
Cette section décrit les conditions requises et les limites qui s'appliquent lorsque vous attribuez et utilisez des sous-réseaux supplémentaires à un cluster. Vous devez remplir toutes les conditions requises avant d'attribuer des sous-réseaux supplémentaires.
- Assurez-vous que votre cluster GKE est un cluster de VPC natif qui exécute la version 1.30.3-gke.1211000 ou une version ultérieure de GKE. Les clusters basés sur le routage et les clusters sur des réseaux hérités ne sont pas compatibles avec les sous-réseaux supplémentaires.
- Vous pouvez attribuer jusqu'à huit sous-réseaux supplémentaires par cluster.
- Les sous-réseaux supplémentaires ne fournissent que des adresses IPv4 pour les nœuds et les pods. Ils ne peuvent pas être utilisés pour fournir des adresses IPv6 pour les nœuds ou les pods.
- Seuls les nouveaux pools de nœuds peuvent utiliser les sous-réseaux supplémentaires, et non les pools de nœuds existants. Par défaut, GKE sélectionne automatiquement un sous-réseau approprié pour le pool de nœuds. Vous pouvez également spécifier manuellement un sous-réseau lors de la création d'un pool de nœuds.
- Les plages d'adresses IPv4 secondaires de sous-réseau dans un sous-réseau non par défaut ne peuvent être utilisées que par un seul cluster.
- Les sous-réseaux supplémentaires ne peuvent pas être utilisés avec les passerelles multiclusters.
- Si vous utilisez la prise en charge multiréseau pour les pods, les plages d'adresses IPv4 principales et de pods d'un sous-réseau supplémentaire ne doivent pas chevaucher les plages CIDR configurées dans votre configuration multiréseau setup. Les sous-réseaux supplémentaires que vous configurez ne s'appliquent qu'au réseau par défaut. Cette limite signifie que toutes les interfaces réseau supplémentaires de vos nœuds et pods ne peuvent pas utiliser les adresses IP fournies par ces sous-réseaux supplémentaires.
- Lorsque vous ajoutez un sous-réseau à des clusters pour lesquels Cloud Service Mesh est activé, le maillage ne peut pas acheminer le trafic vers les pods du sous-réseau non par défaut.
Exigences relatives à l'équilibreur de charge pour les clusters avec des sous-réseaux supplémentaires
Cette section décrit les exigences relatives à l'équilibreur de charge qui s'appliquent lorsque vous utilisez des sous-réseaux supplémentaires sur votre cluster. Ces exigences s'appliquent chaque fois que vous créez un objet Ingress externe, une passerelle externe ou un service LoadBalancer externe.
- Pour utiliser un objet Ingress, une passerelle ou un service LoadBalancer externe dans un cluster avec des sous-réseaux supplémentaires, votre cluster doit exécuter la version 1.33.2-gke.4780000 ou une version ultérieure de GKE.
- Les objets Ingress externes qui utilisent le contrôleur GKE Ingress doivent utiliser l'équilibrage de charge natif en conteneurs.
- Activez le sous-paramètre GKE pour les services LoadBalancer internes. Le sous-paramètre GKE n'affecte que les nouveaux services LoadBalancer internes. Par conséquent, vous devez supprimer et recréer tous les services existants dans votre cluster après avoir activé le sous-paramètre GKE.
Pour créer un équilibreur de charge réseau passthrough externe basé sur un service de backend , les nouveaux services LoadBalancer externes doivent inclure le champ
spec.loadBalancerClassdéfini surnetworking.gke.io/l4-regional-external. Ce champ n'affecte que les nouveaux services LoadBalancer externes et ne s'applique pas aux services LoadBalancer externes existants. Supprimez et recréez tous les services LoadBalancer externes créés sans le champspec.loadBalancerClass. Ce champ nécessite la version 1.33.1-gke.1779000 ou une version ultérieure de GKE.Le type de backend utilisé (backends NEG
GCE_VM_IPou backends de groupe d'instances) dépend de la version de GKE lorsque vous créez le service LoadBalancer externe. Pour en savoir plus, consultez la section Regroupement de nœuds.
Ajouter un sous-réseau avec une plage d'adresses IPv4 de pods
Créez un sous-réseau et ajoutez une plage d'adresses IPv4 secondaire de sous-réseau. Le sous-réseau doit se trouver dans la même région et le même réseau VPC que le cluster :
gcloud compute networks subnets create SUBNET_NAME \ --network=NETWORK \ --region=REGION \ --range=PRIMARY_RANGE \ --secondary-range=POD_RANGE_NAME=SECONDARY_RANGE \ --enable-private-ip-google-accessRemplacez les éléments suivants :
SUBNET_NAME: nom du nouveau sous-réseau.NETWORK: nom du réseau VPC contenant le nouveau sous-réseau.REGIONest la région dans laquelle se trouve le sous-réseau.PRIMARY_RANGE: plage d'adresses IPv4 principales pour le nouveau sous-réseau, au format CIDR. Pour en savoir plus, consultez la section sur les plages de sous-réseaux IPv4.POD_RANGE_NAME: nom de la plage secondaire.SECONDARY_RANGEcorrespond à la plage d'adresses IPv4 secondaire en notation CIDR. Pour connaître les plages valides, consultez la section sur les plages de sous-réseaux IPv4.
Pour plus d'informations, consultez la section Travailler avec des sous-réseaux.
Mettez à jour votre cluster pour utiliser le sous-réseau supplémentaire à l'aide de la gcloud CLI :
gcloud container clusters update CLUSTER_NAME \ --additional-ip-ranges=subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAMERemplacez les éléments suivants :
CLUSTER_NAME: nom de votre cluster existant.SUBNET_NAME: nom du nouveau sous-réseau que vous avez créé.POD_RANGE_NAME: nom de la plage d'adresses IPv4 secondaire du sous-réseau que vous souhaitez utiliser pour la plage d'adresses IPv4 de pods.
Ajouter un sous-réseau avec plusieurs plages d'adresses IPv4 de pods
Créez un nouveau sous-réseau dans la même région et le même réseau VPC que le cluster. Définissez la plage d'adresses IPv4 principale du sous-réseau sur une plage d'adresses IPv4 supplémentaire pour les nœuds.
Pour chaque plage d'adresses IPv4 de pods supplémentaire dont vous avez besoin, ajoutez une nouvelle plage d'adresses IPv4 secondaire de sous-réseau au sous-réseau que vous avez créé à l'étape précédente.
Mettez à jour votre cluster pour utiliser le sous-réseau supplémentaire à l'aide de la gcloud CLI. L'exemple suivant ajoute un sous-réseau comportant deux plages d'adresses IPv4 secondaires de sous-réseau pour les pods.
gcloud container clusters update CLUSTER_NAME \ --additional-ip-ranges=subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAME_1 \ --additional-ip-ranges=subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAME_2Remplacez les éléments suivants :
CLUSTER_NAME: nom de votre cluster existant.SUBNET_NAME: nom du nouveau sous-réseau que vous avez créé.POD_RANGE_NAME_1etPOD_RANGE_NAME_2: noms des plages d'adresses IPv4 secondaires de sous-réseau que vous souhaitez utiliser pour les plages d'adresses IPv4 de pods.
Vérifier les sous-réseaux
Par cluster : pour afficher les détails de tous les sous-réseaux associés à un cluster, exécutez la commande suivante :
gcloud container clusters describe CLUSTER_NAME
Remplacez CLUSTER_NAME par le nom de votre cluster.
Le résultat ressemble à ce qui suit :
ipAllocationPolicy:
additionalIPRangesConfig:
- podIpv4RangeNames:
- pod-range-1
subnetwork: projects/user-gke-dev-2/regions/us-central1/subnetworks/shared-msc-subnets
Par pool de nœuds : pour afficher les détails de tous les sous-réseaux associés à un pool de nœuds, exécutez la commande suivante :
gcloud container node-pools describe POOL_NAME \
--cluster=CLUSTER_NAME \
Remplacez les éléments suivants :
POOL_NAME: nom du pool de nœuds.CLUSTER_NAME: nom du cluster.
Le résultat ressemble à ce qui suit :
name: pool-1
networkConfig:
podRange: pod-range-1
subnetwork: projects/user-gke-dev-2/regions/us-central1/subnetworks/shared-msc-subnets
Comment les pools de nœuds sélectionnent-ils un sous-réseau ?
Par défaut, lorsque vous créez un pool de nœuds et que plusieurs sous-réseaux sont disponibles, GKE sélectionne automatiquement un sous-réseau approprié pour le pool de nœuds en fonction des exigences relatives aux adresses IP et de la disponibilité des adresses IP dans tous les sous-réseaux du cluster.
Spécifier manuellement un sous-réseau lors de la création d'un pool de nœuds
Pour spécifier un sous-réseau lorsque vous créez un pool de nœuds, utilisez l'option --subnetwork avec la commande gcloud container node-pools create. Le sous-réseau que vous spécifiez doit déjà être attribué au cluster (en tant que sous-réseau par défaut ou sous-réseau supplémentaire). Si vous ne spécifiez pas de plage IPv4 de pods, GKE sélectionne automatiquement une plage secondaire disponible dans le sous-réseau spécifié. Si le sous-réseau ou la plage de pods spécifié ne dispose pas de suffisamment d'adresses IP disponibles pour le pool de nœuds, GKE renvoie une erreur.
gcloud container node-pools create POOL_NAME \
--cluster=CLUSTER_NAME \
--location=LOCATION \
--subnetwork=SUBNET_NAME
Spécifier la plage d'adresses IPv4 de pods avec le sous-réseau
Si le sous-réseau spécifié comporte plusieurs plages d'adresses IPv4 secondaires, vous pouvez utiliser à la fois l'option --pod-ipv4-range et l'option --subnetwork pour spécifier la plage à utiliser pour les pods du pool de nœuds.
gcloud container node-pools create POOL_NAME \
--cluster=CLUSTER_NAME \
--location=LOCATION \
--subnetwork=SUBNET_NAME \
--pod-ipv4-range=POD_RANGE_NAME
Remplacez les éléments suivants :
POOL_NAME: nom du nouveau pool de nœuds.CLUSTER_NAME: nom du cluster.LOCATION: région ou zone du cluster.SUBNET_NAME: nom ou chemin d'accès complet de la ressource du sous-réseau que vous souhaitez utiliser.POD_RANGE_NAME: nom de la plage secondaire du sous-réseau à utiliser pour les pods de ce pool de nœuds.
Supprimer un sous-réseau non par défaut
La suppression d'un sous-réseau non par défaut d'un cluster indique au cluster de ne plus utiliser les plages du sous-réseau dans aucun des pools de nœuds du cluster. La suppression a les effets suivants :
- La plage d'adresses IPv4 principale du sous-réseau non par défaut ne peut pas être utilisée pour les plages d'adresses IPv4 de nœuds.
- Les plages IPv4 secondaires du sous-réseau non par défaut ne peuvent pas être utilisées pour les plages IPv4 de pods.
Avant de supprimer un sous-réseau non par défaut, vous devez supprimer tous les pools de nœuds qui utilisent ce sous-réseau. La première étape recommandée consiste à définir l'état du sous-réseau sur "vidange". Les sous-réseaux dont l'état est "vidange" ne seront pas pris en compte pour une utilisation par les pools de nœuds nouvellement créés. Cela empêche les opérations d'autoscaler de cluster (comme le scaling à la hausse du pool de nœuds) de sélectionner le sous-réseau que vous souhaitez supprimer, sans avoir à désactiver l'autoscaling pour l'ensemble du cluster.
Voici les étapes à suivre pour supprimer un sous-réseau :
- Définissez l'état du sous-réseau non par défaut sur "vidange". Cela empêche les nouveaux pools de nœuds de sélectionner ce sous-réseau, ce qui est utile lorsque vous activez l'autoscaling sur le cluster.
- Supprimez tous les pools de nœuds qui utilisent ce sous-réseau.
- Supprimez le sous-réseau du cluster.
Pour supprimer un sous-réseau non par défaut du cluster, exécutez la commande suivante :
gcloud container clusters update CLUSTER_NAME \
--remove-additional-ip-ranges=subnetwork=SUBNET_NAME
Remplacez les éléments suivants :
CLUSTER_NAME: nom de votre cluster.SUBNET_NAME: nom du sous-réseau que vous souhaitez supprimer du cluster.
Pour définir l'état d'un sous-réseau non par défaut sur "vidange", exécutez la commande suivante :
gcloud container clusters update CLUSTER_NAME \
--drain-additional-ip-ranges=subnetwork=SUBNET_NAME
Remplacez les éléments suivants :
CLUSTER_NAME: nom de votre cluster.SUBNET_NAME: nom du sous-réseau dont vous souhaitez définir l'état sur "vidange".
Pour annuler la vidange d'un sous-réseau non par défaut, exécutez la commande suivante :
gcloud container clusters update CLUSTER_NAME \
--undrain-additional-ip-ranges=subnetwork=SUBNET_NAME
Remplacez les éléments suivants :
CLUSTER_NAME: nom de votre cluster.SUBNET_NAME: nom du sous-réseau dont vous souhaitez annuler la vidange.
Après avoir supprimé un sous-réseau non par défaut du cluster, vous pouvez supprimer le sous-réseau non par défaut.
Supprimer une plage IPv4 secondaire de sous-réseau non par défaut
Lorsque vous supprimez une plage IPv4 secondaire de sous-réseau non par défaut d'un cluster, GKE indique au cluster de ne pas utiliser cette plage pour les plages IPv4 de pods dans aucun pool de nœuds. Si la plage IPv4 secondaire de sous-réseau non par défaut que vous supprimez est la seule plage du sous-réseau non par défaut utilisée par ce cluster, GKE indique également au cluster d'arrêter d'utiliser l'adresse IPv4 principale de ce sous-réseau pour les adresses IPv4 de nœuds.
Avant de supprimer une plage IPv4 secondaire de sous-réseau non par défaut, vous devez supprimer tous les pools de nœuds qui utilisent la plage pour les adresses IPv4 de pods.
Pour supprimer une plage IPv4 secondaire de sous-réseau non par défaut du cluster, exécutez la commande suivante :
gcloud container clusters update CLUSTER_NAME \
--remove-additional-ip-ranges=\
subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAME
Remplacez les éléments suivants :
CLUSTER_NAME: nom du cluster.SUBNET_NAME: nom du sous-réseau non par défaut.POD_RANGE_NAME: nom de la plage IPv4 secondaire de sous-réseau non par défaut que vous souhaitez supprimer du cluster.
Après avoir supprimé une plage IPv4 secondaire de sous-réseau non par défaut du cluster, vous pouvez supprimer la plage IPv4 secondaire de sous-réseau non par défaut range.
Utiliser des sous-réseaux supplémentaires dans un VPC partagé
Avant de continuer, assurez-vous de disposer des éléments suivants :
- Un environnement VPC partagé fonctionnel dans lequel les projets hôte et de service sont associés. Pour obtenir des instructions, consultez la section Configurer un cluster avec un VPC partagé.
- Un cluster GKE en cours d'exécution situé dans le projet de service.
- Toutes les API nécessaires sont activées dans les projets hôte et de service.
Créez un sous-réseau supplémentaire dans le projet hôte sous le même réseau que le cluster GKE :
gcloud compute networks subnets create ADDITIONAL_SUBNET_NAME \ --project HOST_PROJECT_ID \ --network shared-net \ --range 172.16.4.0/22 \ --region COMPUTE_REGION \ --secondary-range ADDITIONAL_SUBNET_NAME-services=172.16.16.0/20,ADDITIONAL_SUBNET_NAME-pods=172.20.0.0/14Obtenez la stratégie IAM. Pour permettre au cluster GKE du projet de service d'accéder à des sous-réseaux supplémentaires dans le VPC partagé du projet hôte, vous devez configurer les autorisations IAM nécessaires. Si les autorisations ne sont pas déjà configurées, procédez comme suit. Aucune action n'est nécessaire si les autorisations existent déjà.
gcloud compute networks subnets get-iam-policy ADDITIONAL_SUBNET_NAME \ --project HOST_PROJECT_ID \ --region COMPUTE_REGIONLe résultat contient un champ
etag. Notez la valeuretag.Créez un fichier nommé ADDITIONAL_SUBNET_NAME-policy.yaml avec le contenu suivant :
bindings: - members: - serviceAccount:SERVICE_PROJECT_NUM@cloudservices.s3ns-system.iam.gserviceaccount.com - serviceAccount:service-SERVICE_PROJECT_NUM@container-engine-robot.s3ns-system.iam.gserviceaccount.com role: roles/compute.networkUser etag: ETAG_STRINGRemplacez
ETAG_STRINGpar la valeuretagque vous avez notée précédemment.Définissez la stratégie IAM pour le sous-réseau ADDITIONAL_SUBNET_NAME :
gcloud compute networks subnets set-iam-policy ADDITIONAL_SUBNET_NAME \ ADDITIONAL_SUBNET_NAME-policy.yaml \ --project HOST_PROJECT_ID \ --region COMPUTE_REGIONVérifiez les sous-réseaux utilisables et les plages d'adresses IP secondaires, comme décrit dans la section Vérifier les sous-réseaux utilisables du VPC partagé.
Mettez à jour le cluster VPC partagé des sous-réseaux supplémentaires :
gcloud container clusters update CLUSTER_NAME \
--project=SERVICE_PROJECT_ID \
--location=CONTROL_PLANE_LOCATION \
--additional-ip-ranges=subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/ADDITIONAL_SUBNET_NAME,pod-ipv4-range=ADDITIONAL_SUBNET_NAME-pods
Remplacez les éléments suivants :
- CLUSTER_NAME : nom de votre cluster GKE dans le projet de service.
- ADDITIONAL_SUBNET_NAME : nom du sous-réseau supplémentaire que vous avez créé dans le projet hôte (par exemple, tier-2).
- HOST_PROJECT_ID : ID du projet hôte.
- SERVICE_PROJECT_NUM : nom du projet de service.
- COMPUTE_REGION : région dans laquelle se trouve le sous-réseau.
Vous pouvez ainsi utiliser les sous-réseaux supplémentaires dans un environnement VPC partagé.
Étape suivante
- Documentez-vous plus avant sur les clusters de VPC natif.
- Découvrez comment ajouter des plages d'adresses IPv4 de pods.
- Découvrez comment optimiser l'allocation d'adresses IP en configurant le nombre maximal de pods par nœud.