Résoudre les problèmes d'isolation réseau dans GKE

Cette page explique comment résoudre les problèmes liés à l'isolation réseau de Google Kubernetes Engine (GKE).

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.

Cluster GKE non en cours d'exécution

La suppression des règles de pare-feu autorisant le trafic entrant issu du plan de contrôle du cluster vers les nœuds sur le port 10250 ou la suppression de la route par défaut vers la passerelle Internet par défaut entraîne l'arrêt du fonctionnement d'un cluster. Si vous supprimez la route par défaut, vous devez vous assurer que le trafic vers les servicesGoogle Cloud nécessaires est bien routé. Pour en savoir plus, consultez la section Routage personnalisé.

Expiration du délai lors de la création d'un cluster

Symptômes
Les clusters créés avec la version 1.28 ou antérieure avec des nœuds privés nécessitent une route d'appairage entre les VPC. Toutefois, une seule opération de peering peut avoir lieu à la fois. Si vous tentez de créer plusieurs clusters avec les caractéristiques précédentes en même temps, le processus de création du cluster risque d'expirer.
Solution

Utilisez l'une des solutions suivantes :

  • Créez des clusters en version 1.28 ou antérieure en série afin que les routes d'appairage VPC existent déjà pour chaque cluster suivant sans point de terminaison externe. La tentative de création d'un seul cluster peut également expirer si des opérations sont en cours d'exécution sur votre VPC.

  • Créez des clusters en version 1.29 ou ultérieure.

La connexion d'appairage de réseaux VPC est accidentellement supprimée

Symptômes

Lorsque vous supprimez une connexion d'appairage de réseaux VPC par inadvertance, le cluster est en état de réparation et tous les nœuds affichent un état UNKNOWN. Vous ne pourrez effectuer aucune opération sur le cluster, car la joignabilité au plan de contrôle est déconnectée. Lorsque vous inspectez le plan de contrôle, les journaux affichent une erreur semblable à celle-ci :

error checking if node NODE_NAME is shutdown: unimplemented
Causes probables

Vous avez accidentellement supprimé la connexion d'appairage de réseaux VPC.

Solution

Procédez comme suit :

  1. Créez un cluster d'appairage de réseaux VPC temporaire. La création d'un cluster entraîne la recréation de l'appairage de réseaux VPC et le rétablissement de l'ancien cluster sur son fonctionnement normal.

  2. Une fois que l'ancien cluster est restauré, supprimez le cluster d'appairage de réseaux VPC créé temporairement.

Le point de terminaison Private Service Connect et la règle de transfert sont supprimés par accident

Symptômes

Lorsque vous supprimez par inadvertance un point de terminaison ou une règle de transfert Private Service Connect, le cluster passe à l'état de réparation et tous les nœuds affichent un état UNKNOWN. Vous ne pourrez effectuer aucune opération sur le cluster, car l'accès au plan de contrôle est déconnecté. Lorsque vous inspectez le plan de contrôle, les journaux affichent une erreur semblable à celle-ci :

error checking if node NODE_NAME is shutdown: unimplemented
Causes probables

Vous avez supprimé accidentellement le point de terminaison Private Service Connect ou la règle de transfert. Ces deux ressources sont nommées gke-[cluster-name]-[cluster-hash:8]-[uuid:8]-pe et permettent au plan de contrôle et aux nœuds de se connecter en mode privé.

Solution

Effectuez une rotation de l'adresse IP de votre plan de contrôle.

Le cluster chevauche l'homologue actif

Symptômes

Si vous essayez de créer un cluster sans point de terminaison externe, vous obtenez une erreur semblable à celle-ci:

Google Compute Engine: An IP range in the peer network overlaps with an IP
range in an active peer of the local network.
Causes probables

Vous avez choisi un CIDR de plan de contrôle chevauchant.

Solution

Utilisez l'une des solutions suivantes :

  • Supprimez et recréez le cluster avec un CIDR de plan de contrôle différent.
  • Recréez le cluster dans la version 1.29 et incluez l'indicateur --enable-private-nodes.

Vous ne pouvez pas accéder au plan de contrôle d'un cluster sans point de terminaison externe

Augmentez la probabilité d'accès à votre plan de contrôle de cluster en mettant en œuvre l'une des configurations d'accès aux points de terminaison du cluster. Pour en savoir plus, consultez la section Accès aux points de terminaison du cluster.

Symptômes

Après avoir créé un cluster sans point de terminaison externe, une tentative d'exécution de commandes kubectl sur le cluster renvoie une erreur semblable à l'une des suivantes:

Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection
timed out.

Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.
Causes probables

kubectl ne parvient pas à communiquer avec le plan de contrôle du cluster.

Solution

Utilisez l'une des solutions suivantes :

  • Activez l'accès DNS pour accéder de manière simplifiée et sécurisée à votre cluster. Pour en savoir plus, consultez la section Point de terminaison basé sur le DNS.

  • Vérifiez que les identifiants du cluster ont été générés pour kubeconfig ou que le contexte approprié est activé. Pour en savoir plus sur la définition des identifiants du cluster, consultez la page Générer une entrée kubeconfig.

  • Vérifiez que l'accès au plan de contrôle à l'aide de son adresse IP externe est autorisé. La désactivation de l'accès externe au plan de contrôle du cluster isole le cluster d'Internet. Avec cette configuration, seules les plages CIDR de réseau interne autorisées ou le réseau réservé ont accès au plan de contrôle.

    1. Vérifiez que l'adresse IP d'origine est autorisée à atteindre le plan de contrôle :

        gcloud container clusters describe CLUSTER_NAME \
      --format="value(controlPlaneEndpointsConfig.ipEndpointsConfig.authorizedNetworksConfig)"\
      --location=COMPUTE_LOCATION

      Remplacez les éléments suivants :

      Si votre adresse IP d'origine n'est pas autorisée, la sortie peut renvoyer un résultat vide (uniquement entre accolades) ou des plages CIDR qui n'incluent pas votre adresse IP d'origine.

      cidrBlocks:
  cidrBlock: 10.XXX.X.XX/32
  displayName: jumphost
  cidrBlock: 35.XXX.XXX.XX/32
  displayName: cloud shell
enabled: true

    2. Ajoutez des réseaux autorisés au plan de contrôle des accès.

  • Si vous exécutez la commande kubectl à partir d'un environnement sur site ou d'une région différente de celle du cluster, assurez-vous que l'accès mondial au point de terminaison privé du plan de contrôle est activé. Pour en savoir plus, consultez la section Accès via l'adresse IP interne du plan de contrôle depuis n'importe quelle région.

    1. Décrivez le cluster pour afficher la réponse de configuration d'accès au plan de contrôle :

      gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --flatten "controlPlaneEndpointsConfig.ipEndpointsConfig.globalAccess"

      Remplacez les éléments suivants :

      Le résultat renvoyé en cas de succès ressemble à ce qui suit :

        enabled: true

    2. Si null est renvoyé, activez l'accès via l'adresse IP interne du plan de contrôle depuis n'importe quelle région.

Impossible de créer le cluster en raison du chevauchement du bloc CIDR IPv4

Symptômes

gcloud container clusters create renvoie une erreur semblable à ce qui suit :

The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network
10.128.0.0/20.
Causes probables

Vous avez spécifié un bloc CIDR de plan de contrôle qui chevauche un sous-réseau existant dans votre VPC.

Solution

Spécifiez un bloc CIDR pour --master-ipv4-cidr qui ne chevauche pas un sous-réseau existant.

Impossible de créer le cluster en raison de l'utilisation de la plage de services par un autre cluster

Symptômes

La tentative de création d'un cluster renvoie une erreur semblable à ce qui suit:

Services range [ALIAS_IP_RANGE] in network [VPC_NETWORK], subnetwork
[SUBNET_NAME] is already used by another cluster.
Causes probables

Les configurations suivantes peuvent provoquer cette erreur:

  • Vous avez choisi une plage de services qui est toujours utilisée par un autre cluster, ou le cluster n'a pas été supprimé.
  • Un cluster utilisant cette plage de services a été supprimé, mais les métadonnées des plages secondaires n'ont pas été correctement supprimées. Les plages secondaires d'un cluster GKE sont enregistrées dans les métadonnées Compute Engine et doivent être supprimées une fois le cluster supprimé. Même lorsqu'un cluster est correctement supprimé, il est possible que les métadonnées ne le soient pas.
Solution

Procédez comme suit :

  1. Vérifiez si la plage de services est utilisée par un cluster existant. Vous pouvez utiliser la commande gcloud container clusters list avec l'option filter pour rechercher le cluster. Si un cluster existant utilise les plages de services, vous devez le supprimer ou en créer une nouvelle.
  2. Si la plage de services n'est pas utilisée par un cluster existant, supprimez manuellement l'entrée de métadonnées correspondant à la plage de services que vous souhaitez utiliser.

Impossible de créer un sous-réseau

Symptômes

Lorsque vous tentez de créer un cluster avec un sous-réseau automatique ou de créer un sous-réseau personnalisé, vous pouvez rencontrer l'une des erreurs suivantes:

An IP range in the peer network overlaps
with an IP range in one of the active peers of the local network.

Error: Error waiting for creating GKE cluster: Invalid value for field
PrivateClusterConfig.MasterIpv4CidrBlock: x.x.x.x/28 conflicts with an
existing subnet in one of the peered VPCs.
Causes probables

La plage CIDR du plan de contrôle que vous avez spécifiée chevauche une autre plage d'adresses IP du cluster. Cette erreur de création de sous-réseau peut également se produire si vous essayez de réutiliser les blocs CIDR master-ipv4-cidr utilisés dans un cluster récemment supprimé.

Solution

Essayez d’utiliser une autre plage CIDR.

Impossible d'extraire l'image du registre Docker Hub public

Symptômes

Un pod exécuté dans votre cluster affiche un avertissement dans kubectl describe :

Failed to pull image: rpc error: code = Unknown desc = Error response
from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled
while waiting for connection (Client.Timeout exceeded while awaiting
headers)
Causes probables

Les nœuds disposant d'adresses IP privées ne nécessitent qu'une configuration supplémentaire pour répondre aux conditions d'accès à Internet. Toutefois, les nœuds peuvent accéder aux API et services de Google Cloud , y compris à Artifact Registry, si vous avez activé l'accès privé à Google et que vous remplissez les conditions requises pour le réseau.

Solution

Utilisez l'une des solutions suivantes :

  • Copiez les images de votre cluster de Docker Hub vers Artifact Registry. Pour en savoir plus, consultez la page Migrer des conteneurs à partir d'un registre tiers.

  • GKE vérifie automatiquement mirror.gcr.io pour les copies mises en cache des images Docker Hub fréquemment utilisées.

  • Si vous devez extraire des images de Docker Hub ou d'un autre dépôt public, utilisez Cloud NAT ou un proxy basé sur une instance correspondant à la cible d'une route 0.0.0.0/0 statique.

Dépassement du délai d'une requête API déclenchant un webhook d'admission

Symptômes

Une requête API qui déclenche un webhook d'admission configuré pour utiliser un service avec un targetPort autre que 443 dépasse le délai, ce qui entraîne l'échec de la requête:

Error from server (Timeout): request did not complete within requested timeout 30s
Causes probables

Par défaut, le pare-feu n'autorise pas les connexions TCP aux nœuds, sauf sur les ports 443 (HTTPS) et 10250 (kubelet). Un webhook d'admission qui tente de communiquer avec un pod sur un port autre que 443 échoue si aucune règle de pare-feu personnalisée n'autorise le trafic.

Solution

Ajoutez une règle de pare-feu pour votre cas d'utilisation spécifique.

Impossible de créer le cluster en raison de l'échec de la vérification de l'état

Symptômes

Une fois créé, un cluster standard avec des pools de nœuds privés se retrouve bloqué à l'étape de vérification de l'état'état et génère un message d'erreur semblable à l'un des messages suivants:

All cluster resources were brought up, but only 0 of 2 have registered.

All cluster resources were brought up, but: 3 nodes out of 4 are unhealthy
Causes probables

Les configurations suivantes peuvent provoquer cette erreur:

  • Les nœuds de cluster ne peuvent pas télécharger les binaires requis depuis l'API Cloud Storage (storage.googleapis.com).
  • Des règles de pare-feu limitent le trafic de sortie.
  • Les autorisations IAM du VPC partagé sont incorrectes.
  • L'accès privé à Google nécessite la configuration du DNS pour *.gcr.io.
Solution

Utilisez l'une des solutions suivantes :

kubelet n'a pas réussi à créer le bac à sable de pod

Symptômes

Après avoir créé un cluster avec des nœuds privés, il génère une erreur semblable à l'une des suivantes:

Warning  FailedCreatePodSandBox  12s (x9 over 4m)      kubelet  Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Get https://registry.k8s.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Causes probables

Le pod calico-node ou netd ne peut pas atteindre *.gcr.io.

Solution

Assurez-vous d'avoir effectué la configuration requise pour Container Registry ou Artifact Registry.

Nœuds privés créés, mais non associés au cluster

Pour les clusters qui utilisent uniquement des nœuds avec des adresses IP privées, la route par défaut (0.0.0.0/0) est souvent redirigée vers l'appareil au lieu de la passerelle Internet par défaut lorsque vous utilisez un routage personnalisé et des dispositifs réseau tiers sur le VPC. Outre la connectivité du plan de contrôle, vous devez vous assurer que les destinations suivantes sont accessibles :

  • *.googleapis.com
  • *.gcr.io
  • gcr.io

Configurez l'accès privé à Google pour les trois domaines. Cette bonne pratique permet de démarrer les nouveaux nœuds et de les associer au cluster, tout en continuant à limiter le trafic Internet.

Les charges de travail sur des clusters GKE ne parviennent pas à accéder à Internet

Les pods exécutés dans des nœuds avec des adresses IP privées ne peuvent pas accéder à Internet. Par exemple, après avoir exécuté la commande apt update à partir du pod exec shell, elle signale une erreur semblable à celle-ci:

0% [Connecting to deb.debian.org (199.232.98.132)] [Connecting to security.debian.org (151.101.130.132)]

Si la plage d'adresses IP secondaire du sous-réseau utilisée pour les pods du cluster n'est pas configurée sur la passerelle Cloud NAT, les pods ne peuvent pas se connecter à Internet, car ils n'ont pas d'adresse IP externe configurée pour la passerelle Cloud NAT.

Assurez-vous de configurer la passerelle Cloud NAT pour appliquer au moins les plages d'adresses IP de sous-réseau suivantes au sous-réseau utilisé par votre cluster :

  • Plage d'adresses IP principale du sous-réseau (utilisée par les nœuds)
  • Plage d'adresses IP secondaire du sous-réseau pour les pods du cluster
  • Plage d'adresses IP secondaire du sous-réseau pour les services du cluster

Pour en savoir plus, consultez la section Ajouter une plage d'adresses IP secondaire de sous-réseau pour les pods.

L'accès direct par adresse IP ne peut pas être désactivé pour les clusters publics

Symptômes

Après avoir désactivé le point de terminaison de l'adresse IP, un message d'erreur semblable au suivant s'affiche:

Direct IP access can't be disabled for public clusters
Causes probables

Votre cluster utilise un ancien réseau.

Solution

Migrez vos clusters vers Private Service Connect. Pour en savoir plus sur l'état de la migration, contactez l'assistance .

L'accès direct par adresse IP ne peut pas être désactivé pour les clusters en cours de migration PSC.

Symptômes

Après avoir désactivé le point de terminaison de l'adresse IP, un message d'erreur semblable au suivant s'affiche:

Direct IP access can't be disabled for public clusters
Causes probables

Votre cluster utilise un ancien réseau.

Solution

Utilisez l'une des solutions suivantes :

  • Recréez manuellement tous les pools de nœuds dans une autre version.
  • Attendez que GKE mette automatiquement à niveau les pools de nœuds lors d'un événement de maintenance.

Le point de terminaison interne du plan de contrôle ne peut pas être activé

Symptômes

Lorsque vous essayez d'activer le point de terminaison interne du plan de contrôle de votre cluster, des messages d'erreur semblables à ceux-ci s'affichent:

private_endpoint_enforcement_enabled can't be enabled when envoy is disabled

private_endpoint_enforcement_enabled is unsupported. Please upgrade to the minimum support version
Causes probables

Votre cluster doit effectuer une rotation d'adresses IP ou une mise à jour de version.

Solution

Utilisez l'une des solutions suivantes :

La création de cluster échoue lorsque des règles d'administration sont définies

Symptômes

Lorsque vous essayez de créer un cluster, un message d'erreur semblable au suivant s'affiche:

compute.disablePrivateServiceConnectCreationForConsumers violated for projects
Causes probables

Le point de terminaison ou le backend du cluster est bloqué par une règle d'administration client.

Solution

Autorisez les instances à créer des points de terminaison avec la contrainte compute.restrictPrivateServiceConnectProducer en suivant la procédure décrite dans la section Règles d'administration côté client.

Le point de terminaison Private Service Connect peut être endommagé lors de la suppression du cluster

Symptômes

Après avoir créé un cluster, vous pouvez rencontrer l'un des symptômes suivants:

  • Vous ne pouvez pas voir de point de terminaison connecté sous Private Service Connect dans votre cluster basé sur Private Service Connect.

  • Vous ne pouvez pas supprimer le sous-réseau ou le réseau VPC alloué au point de terminaison interne dans un cluster qui utilise Private Service Connect. Un message d'erreur semblable à celui-ci s'affiche :

    projects/<PROJECT_ID>/regions/<REGION>/subnetworks/<SUBNET_NAME> is already being used by projects/<PROJECT_ID>/regions/<REGION>/addresses/gk3-<ID>
Causes probables

Sur les clusters GKE qui utilisent Private Service Connect, GKE déploie un point de terminaison Private Service Connect à l'aide d'une règle de transfert qui alloue une adresse IP interne pour accéder au plan de contrôle du cluster dans le réseau d'un plan de contrôle. Pour protéger la communication entre le plan de contrôle et les nœuds à l'aide de Private Service Connect, GKE maintient le point de terminaison invisible. Vous ne pouvez pas le voir dans la consoleGoogle Cloud ni dans la gcloud CLI.

Solution

Pour éviter que le point de terminaison Private Service Connect ne soit divulgué avant la suppression du cluster, procédez comme suit:

  1. Attribuez le rôle Kubernetes Engine Service Agent role au compte de service GKE.
  2. Assurez-vous que les autorisations compute.forwardingRules.* et compute.addresses.* ne sont pas explicitement refusées par le compte de service GKE.

Si vous constatez une fuite du point de terminaison Private Service Connect, contactez l'assistance .

Impossible d'analyser le réseau autorisé du cluster

Symptômes

Vous ne pouvez pas créer de cluster dans la version 1.29 ou ultérieure. Un message d'erreur semblable à celui-ci s'affiche :

Unable to parse cluster.master_ipv4_cidr "" into a valid IP address and mask
Causes probables

Votre projet Google Cloud utilise des webhooks basés sur des adresses IP privées. Vous ne pouvez donc pas créer de cluster avec Private Service Connect. À la place, votre cluster utilise l'appairage de réseaux VPC, qui analyse l'indicateur master-ipv4-cidr.

Solution

Utilisez l'une des solutions suivantes :

  • Poursuivez la création de votre cluster d'appairage de réseaux VPC et incluez master-ipv4-cidr pour définir des CIDR valides. Cette solution présente les limites suivantes:

    • L'indicateur master-ipv4-cidr a été abandonné dans la console Google Cloud . Pour mettre à jour cet indicateur, vous ne pouvez utiliser que Google Cloud CLI ou Terraform.
    • L'appairage de réseaux VPC est obsolète dans GKE version 1.29 ou ultérieure.

  • Migrez vos webhooks basés sur des adresses IP privées en suivant les étapes décrites dans la section Limites de Private Service Connect. Ensuite, contactez l'assistance pour activer l'utilisation de clusters avec Private Service Connect.

Impossible de définir une plage d'adresses IP internes dans des clusters avec des nœuds publics

Symptômes

Vous ne pouvez pas définir de plage d'adresses IP internes à l'aide de l'option --master-ipv4-cidr. Un message d'erreur semblable à celui-ci s'affiche:

ERROR: (gcloud.container.clusters.create) Cannot specify --master-ipv4-cidr
  without --enable-private-nodes
Causes probables

Vous définissez une plage d'adresses IP internes pour le plan de contrôle avec l'indicateur master-ipv4-cidr dans un cluster sans que l'indicateur enable-private-nodes ne soit activé. Pour créer un cluster avec master-ipv4-cidr défini, vous devez configurer votre cluster pour provisionner des nœuds avec des adresses IP internes (nœuds privés) à l'aide de l'option enable-private-nodes.

Solution

Utilisez l'une des solutions suivantes :

  • Créez un cluster avec la commande suivante:

    gcloud container clusters create-auto CLUSTER_NAME \
    --enable-private-nodes \
    --master-ipv4-cidr CP_IP_RANGE

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • CLUSTER_NAME: plage d'adresses IP interne pour le plan de contrôle.

  • Mettez à jour votre cluster pour provisionner des nœuds avec des adresses IP uniquement. Pour en savoir plus, consultez Configurer votre cluster.

Impossible de planifier des charges de travail publiques sur des clusters Autopilot

Symptômes
Dans les clusters Autopilot, si votre cluster n'utilise que des nœuds privés, vous ne pouvez pas planifier de charges de travail dans des pods publics à l'aide du nodeSelector cloud.google.com/private-node=false.
Causes probables
La configuration de l'indicateur private-node défini sur false dans le nodeSelector du pod n'est disponible que dans les clusters de la version 1.30.3 ou ultérieure.
Solution
Mettez à niveau votre cluster vers la version 1.30 ou ultérieure.

L'accès au point de terminaison basé sur un DNS est désactivé

Symptômes

Si vous essayez d'exécuter des commandes kubectl sur le cluster, une erreur semblable à celle-ci s'affiche:

couldn't get current server API group list:
control_plane_endpoints_config.dns_endpoint_config.allow_external_traffic is
disabled
Causes probables

L'accès basé sur un DNS a été désactivé sur votre cluster.

Solution

Activez l'accès au plan de contrôle à l'aide du point de terminaison basé sur DNS du plan de contrôle. Pour en savoir plus, consultez la section Modifier l'accès au plan de contrôle.

Échec de l'allocation d'adresses IP aux nœuds lors du scaling

Symptômes

Si vous essayez d'étendre la plage d'adresses IP principale du sous-réseau à la liste des réseaux autorisés, une erreur semblable à celle-ci s'affiche:

 authorized networks fields cannot be mutated if direct IP access is disabled
Causes probables

Vous avez désactivé le point de terminaison basé sur l'adresse IP du cluster.

Solution

Désactivez et activez le point de terminaison basé sur l'adresse IP du cluster à l'aide de l'option enable-ip-access.

Trop de blocs CIDR

gcloud renvoie l'erreur suivante lorsqu'un utilisateur essaie de créer ou de mettre à jour un cluster avec plus de 50 blocs CIDR :

ERROR: (gcloud.container.clusters.update) argument --master-authorized-networks: too many args

Pour résoudre ce problème, procédez comme suit :

Impossible de se connecter au serveur

Les commandes kubectl dépassent le délai en raison de blocs CIDR mal configurés :

Unable to connect to the server: dial tcp MASTER_IP: getsockopt: connection timed out

Lorsque vous créez ou mettez à jour un cluster, veillez à spécifier les bons blocs CIDR.