Résoudre les problèmes liés aux clusters privés dans GKE

Cette page explique comment résoudre les problèmes liés aux clusters privés de Google Kubernetes Engine (GKE).

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

Le cluster privé ne s'exécute pas

La suppression de l'appairage VPC entre le plan de contrôle de cluster et les nœuds de cluster, la suppression des règles de pare-feu autorisant le trafic entrant issu du plan de contrôle de 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înent l'arrêt du fonctionnement d'un cluster privé. Si vous supprimez la route par défaut, vous devez vous assurer que le trafic vers les services Google Cloud nécessaires est bien routé. Pour plus d'informations, consultez la section Routage personnalisé.

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

Chaque cluster privé nécessite une route d'appairage entre les VPC, mais une seule opération d'appairage peut se produire à la fois. Si vous tentez de créer plusieurs clusters privés en même temps, le processus de création du cluster risque d'expirer. Pour éviter cela, créez des clusters privés en série afin que les routes d'appairage VPC existent déjà pour chaque cluster privé suivant. La tentative de création d'un seul cluster privé peut également expirer si des opérations sont en cours d'exécution sur votre VPC.

La connexion d'appairage de réseaux VPC sur le cluster privé 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 :

  • 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.

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

Le cluster chevauche l'homologue actif

Symptômes

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

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

Supprimez et recréez le cluster avec un CIDR de plan de contrôle différent.

Vous ne pouvez pas accéder au plan de contrôle d'un cluster privé

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 la création d'un cluster privé, une tentative d'exécution de commandes kubectl sur le cluster renvoie une erreur semblable à l'un des exemples suivants :

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

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. Cette configuration est immuable après la création du cluster. 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(masterAuthorizedNetworksConfig)"\
      --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éder au point de terminaison privé du plan de contrôle dans le monde entier.

  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 "privateClusterConfig.masterGlobalAccessConfig"

    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 mondial au plan de contrôle.

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 privé 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

Au choix :

  • 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 :

  • 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.
  • 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 le sous-réseau

Symptômes

Lorsque vous tentez de créer un cluster privé avec un sous-réseau automatique, ou de créer un sous-réseau personnalisé, vous pouvez rencontrer l'erreur suivante :

An IP range in the peer network overlaps
with an IP range in one of the active peers of the local network.
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. Cela peut également se produire si vous avez récemment supprimé un cluster privé et que vous essayez de créer un autre cluster privé avec le même CIDR de plan de contrôle.

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 d'un cluster privé ne possèdent pas d'adresses IP externes et ne répondent donc pas aux conditions d'accès à Internet. Toutefois, les nœuds peuvent accéder aux API et aux services de Google, 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 privé 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 port cible 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 privé se retrouve bloqué à l'étape de vérification de l'é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

Parmi les suivantes :

  • 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 la création d'un cluster privé, 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

Utilisez l'une des solutions suivantes :

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

Souvent, lorsque vous utilisez des dispositifs de routage personnalisé et de réseau tiers sur le VPC utilisé par votre cluster privé, la route par défaut (0.0.0.0/0) est redirigée vers le dispositif au lieu de la passerelle Internet par défaut. 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 privés ne parviennent pas à accéder à Internet

Les pods des clusters GKE privés 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.