Résoudre les problèmes d'enregistrement des nœuds

Standard

Ce document explique comment résoudre les problèmes rencontrés lors de l'ajout de nœuds à votre cluster Google Kubernetes Engine (GKE) standard. Certains des scénarios où ces problèmes se produisent incluent la création de clusters et de pools de nœuds, ainsi que lors d'événements de scaling à la hausse.

Pour résoudre les problèmes liés aux clusters GKE Autopilot, consultez la page Résoudre les problèmes liés aux clusters Autopilot.

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

À propos de l'enregistrement des nœuds

Les nœuds sont des instances de VM Compute Engine que GKE crée en votre nom. Lorsqu'un nouveau nœud est ajouté à un cluster GKE, il doit être enregistré auprès du plan de contrôle du cluster. Ce processus, appelé enregistrement de nœud ou amorçage de nœud, se produit lors de la création d'un nœud.

Quand l'enregistrement des nœuds se produit-il ?

L'enregistrement des nœuds s'effectue chaque fois que des nœuds sont créés, y compris dans les scénarios suivants :

Vous créez un cluster.
Vous créez un pool de nœuds.
GKE crée un pool de nœuds avec provisionnement automatique des nœuds.
L'autoscaler de cluster effectue un scaling à la hausse du cluster.
Vous redimensionnez le cluster.
La réparation automatique de nœuds crée un nœud.

Le processus d'enregistrement des nœuds est le suivant :

Le nombre de nœuds défini pour le pool de nœuds est répliqué sur les groupes d'instances gérés (MIG).
Les MIG créent le nombre requis d'instances de VM.
Pour chaque instance de VM créée, les étapes suivantes se produisent :
1. L'instance de VM démarre.
2. L'instance de VM configure et installe les packages nécessaires pour s'exécuter en tant que nœud Kubernetes.
3. Le kubelet qui s'exécute à présent sur l'instance de VM communique avec le serveur d'API du plan de contrôle pour s'enregistrer en tant que nœud.

Message d'erreur d'enregistrement des nœuds

Lorsque GKE tente d'ajouter des nœuds à votre cluster, l'erreur suivante s'affiche dans la console Google Cloud si l'enregistrement des nœuds a échoué :

  All cluster resources were brought up, but: only 0 nodes out of * have
  registered; this is likely due to the Nodes failing to start correctly; try
  re-creating the cluster or contact support if that doesn't work.

Ce message d'erreur indique que les nœuds n'ont pas été enregistrés auprès du cluster. Les sections suivantes décrivent certaines des causes possibles de cette erreur.

Conditions préalables à l'enregistrement réussi des nœuds

L'enregistrement réussi des nœuds dans un cluster GKE dépend de facteurs tels que les suivants :

Connectivité réseau.
Disponibilité des ressources.
Autorisations de compte de service.

Conditions préalables à la création d'une instance

Lorsque GKE crée un nœud pour votre cluster, la première étape consiste à créer une instance de VM Compute Engine.

La création de l'instance peut échouer pour l'une des raisons suivantes :

L'échec de la création d'une instance signifie que dans la période au cours de laquelle GKE a tenté de créer l'instance pour s'enregistrer en tant que nœud GKE, il manque des journaux pour la création de l'instance, car les instances n'ont jamais été créées. Pour rechercher les journaux manquants, reportez-vous aux instructions pour rechercher une instance dont l'enregistrement des nœuds a échoué.

Autorisations de compte de service

Les nœuds GKE sont associés à un compte de service IAM. Par défaut, ce compte de service est le compte de service Compute Engine par défaut. Nous vous recommandons de renforcer votre cluster à l'aide d'un compte de service IAM personnalisé disposant des autorisations minimales requises.

Ce compte de service doit disposer des autorisations appropriées pour que les instances de VM soient initialisées en tant que nœuds GKE. Si vous supprimez le compte de service ou que vous le désactivez ou si vous ne lui accordez pas les autorisations appropriées, l'enregistrement des nœuds peut échouer.

Conditions préalables à la connexion réseau aux API et services Google

L'instance de VM télécharge des packages pour se préparer à s'exécuter en tant que nœud GKE. Un délai d'inactivité de connexion peut signifier que votre cluster ne répond pas aux exigences de mise en réseau nécessaires pour se connecter aux API et services Google, tels que storage.googleapis.com. Si une instance ne peut pas se connecter à ces services, elle ne peut pas télécharger la distribution Kubernetes ni terminer le processus d'enregistrement des nœuds.

Selon votre connexion réseau, autoriser cette connexion peut signifier que vous devez configurer l'accès privé à Google, ou avoir des règles de pare-feu et des routes dans le réseau cloud privé virtuel (VPC) de votre cluster qui autorisent la connexion.

Conditions préalables à la connexion réseau avec le plan de contrôle

La connectivité entre le plan de contrôle et les nœuds est essentielle pour l'enregistrement des nœuds et pour la fonction standard. Cette communication est autorisée par défaut. Assurez-vous que lors de la mise en place des règles de pare-feu VPC, la communication est toujours possible entre les nœuds et le plan de contrôle.

Pour en savoir plus, consultez la section Autoriser la connectivité du plan de contrôle.

Utiliser le vérificateur d'enregistrement des nœuds pour résoudre les problèmes d'enregistrement des nœuds

Pour les pools de nœuds créés sur GKE version 1.24.0-gke.100 ou ultérieure, un utilitaire appelé vérificateur d'enregistrement des nœuds s'exécute sur les nouvelles instances et vérifie si l'instance a réussi les étapes d'enregistrement des nœuds.

Lorsque l'enregistrement des nœuds échoue, l'utilitaire génère un rapport récapitulatif dans lequel vous pouvez voir quelles conditions préalables n'ont pas été remplies en fonction de l'étape du processus où l'instance a échoué.

Suivez les instructions de la section suivante pour rechercher une instance ayant échoué lors de l'enregistrement des nœuds et consultez le résumé du vérificateur d'enregistrement des nœuds pour en apprendre les raisons.

Si vous ne pouvez pas utiliser le vérificateur d'enregistrement des nœuds dans votre pool de nœuds, consultez la section Résoudre les problèmes d'enregistrement des nœuds sans le vérificateur d'enregistrement des nœuds.

Rechercher une instance dont l'enregistrement des nœuds a échoué

Lorsqu'une ou plusieurs instances ne parviennent pas à s'enregistrer en tant que nœuds auprès du plan de contrôle de votre cluster GKE, vous pouvez voir le nombre d'instances ayant échoué à partir du message d'erreur affiché dans la page Détails du cluster de la console Google Cloud Lorsque l'enregistrement de plusieurs instances échoue en même temps, cela peut être dû à la même raison sous-jacente. Pour cette raison, vous pouvez utiliser l'une des instances ayant échoué pour déterminer la raison de l'échec de toutes les instances.

Toutefois, étant donné que les instances n'ont pas été enregistrées en tant que nœuds GKE, vous devez suivre les instructions suivantes pour rechercher les noms des VM Compute Engine sous-jacentes qui n'ont pas pu être enregistrées.

Dans la console Google Cloud, accédez à la page Explorateur de journaux.

Accéder à l'explorateur de journaux

Utilisez le filtre de journal suivant pour rechercher les journaux de la création des instances de VM :

resource.type="gce_instance"
logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.requestMetadata.callerSuppliedUserAgent="GCE Managed Instance Group for GKE"
protoPayload.response.status="RUNNING"

Remplacez PROJECT_ID par l'ID du projet de votre cluster.

Utilisez l'histogramme situé sous le filtre de journal pour affiner la période afin qu'elle corresponde à celle où la création des nœuds aurait dû se produire.
Cliquez sur l'un des journaux qui s'affichent sous Résultats de la requête, puis sur Développer les champs imbriqués pour afficher plus de détails.
Recherchez le champ protoPayload.resourceName. La dernière partie du chemin répertorié est le nom de l'instance. Les noms d'instance suivent un format commençant par le nom du cluster et le nom du pool de nœuds, par exemple :

gke-cluster-1-default-pool-b0ac62d3-9g1v est une instance du pool de nœuds default-pool dans gke-cluster-1.
Dans la console Google Cloud, accédez à la page instances de VM de Compute Engine :

Accéder à la page Instances de VM

Recherchez le nom de l'instance de VM à l'aide du filtre. Cliquez pour en savoir plus.

Résoudre les problèmes d'une instance avec le vérificateur d'enregistrement des nœuds

Une fois que vous avez trouvé le nom de l'instance qui n'a pas pu être enregistrée, vous pouvez déterminer pourquoi elle a échoué à l'aide du vérificateur d'enregistrement des nœuds.

Dans l'onglet Détails de l'instance de VM, dans la section Journaux, cliquez sur Port série 1 (console).

Pour les pools de nœuds créés sur GKE 1.24.0-gke.100 ou une version ultérieure, la sortie des nouvelles instances inclut les éléments suivants, indiquant que le vérificateur d'enregistrement des nœud a démarré :

** Starting Node Registration Checker **
** Loading variables from kube-env **
** Sleeping for 7m to allow registration to complete  **

Si l'enregistrement des nœuds réussit, la sortie inclut les messages suivants :

** Node ready and registered. **
** Completed running Node Registration Checker **

Si vous ne voyez pas ces messages, l'enregistrement du nœud a échoué et le vérificateur d'enregistrement du nœud a généré un rapport expliquant pourquoi l'enregistrement a échoué. Recherchez le message supplémentaire suivant pour consulter le résumé :

** Here is a summary of the checks performed: **

Sous ce message, vous trouverez une table semblable à celle-ci :

------------------------------
Service    DNS      Reachable
------------------------------
LOGGING    true     true
GCR        true     true
GCS        true     true
Master     N/A      false
------------------------------

Si LOGGING, GCR ou GCS sont répertoriés comme non accessibles, vérifiez les autorisations de compte de service pour l'enregistrement des nœuds et la connexion réseau aux API et services Google pour l'enregistrement des nœuds.

Si Master est répertorié comme non accessible, vérifiez les conditions préalables à la connexion réseau avec le plan de contrôle pour l'enregistrement des nœuds.

Après avoir résolu tous les problèmes empêchant l'enregistrement des nœuds, consultez la section Terminer l'enregistrement des nœuds après avoir corrigé la cause première.

Si les étapes précédentes ne vous indiquent pas pourquoi l'enregistrement des nœuds a échoué, consultez la section Collecter des informations pour effectuer une enquête plus approfondie.

Résoudre les problèmes d'enregistrement des nœuds sans le vérificateur d'enregistrement des nœuds

Si l'enregistrement des nœuds a échoué dans un pool de nœuds créé sur une version de GKE antérieure à la version 1.24.0-gke.100, vous ne pouvez résoudre les problèmes d'enregistrement des nœuds que manuellement. Si votre pool de nœuds a été créé sur GKE version 1.24.0-gke.100 ou une version ultérieure, suivez les instructions de la page Utiliser le vérificateur d'enregistrement des nœuds pour résoudre les problèmes d'enregistrement des nœuds.

Après avoir résolu tous les problèmes empêchant l'enregistrement des nœuds, suivez les instructions ci-dessous pour terminer l'enregistrement des nœuds après avoir corrigé la cause première.

Si aucune des étapes d'enquête de cette page ne vous explique pourquoi l'enregistrement des nœuds a échoué, consultez la section Collecter des informations pour effectuer une enquête plus approfondie.

Vérifier les autorisations du compte de service pour l'enregistrement des nœuds

Le compte de service utilisé par vos nœuds doit disposer des autorisations préalables requises pour l'enregistrement des nœuds. Suivez les instructions ci-dessous pour vérifier que vous remplissez ces conditions préalables :

Recherchez une instance dont l'enregistrement des nœuds a échoué.
Dans l'onglet Détails de l'instance de VM, dans la section Gestion des API et des identités, localisez le nom du compte de service dans le champ Compte de service. Si le nœud a utilisé le compte de service Compute Engine par défaut, le nom suit le format PROJECT_NUMBER-compute@developer.gserviceaccount.com. Ce compte de service doit disposer des autorisations minimales requises.
Recherchez les indicateurs d'enregistrement réussi dans la sortie de la console série. Dans l'onglet Détails de l'instance de VM, dans la section Journaux, cliquez sur Port série 1 (console).

Si l'instance a utilisé un compte de service doté des autorisations appropriées, la sortie inclut les éléments suivants :
- Started Download and install k8s binaries and configurations
- Started Docker Application Container Engine.
- Started Configure kubernetes node.
- Reached target Kubernetes.
Ces messages se trouvent à différents endroits dans la sortie. Ils peuvent également présenter des codes temporels ou d'autres artefacts qui les interrompent, comme ceci : Starting [0;1;39mConfigure kubernetes node. Si tous ces messages sont présents, cela signifie que les conditions préalables du compte de service sont remplies.

Si ces messages ne s'affichent pas, il est possible que le compte de service attribué à l'instance de VM soit supprimé, désactivé ou qu'il ne dispose pas des autorisations appropriées.

Vérifier la connexion réseau aux API et services Google pour l'enregistrement des nœuds

Vérifier la connexion avec un accès SSH

Si vous disposez d'un accès SSH aux instances de VM dans votre projet, vous pouvez également vérifier que l'instance de VM dispose d'une connexion réseau aux API et services Google.

Recherchez une instance dont l'enregistrement des nœuds a échoué.
Dans l'onglet Détails de l'instance de VM, cliquez sur SSH.
Une fois connecté à la ligne de commande de votre instance de VM, exécutez la commande suivante pour vérifier la connexion aux API et services Google :
```
curl -m 5 -v https://storage.googleapis.com/generate_204
```
Si la connexion réussit, la sortie ressemble à ce qui suit :
```
*   Trying 142.250.148.128:443...
* Connected to storage.googleapis.com (142.250.148.128) port 443 (#0)

...

< HTTP/1.1 204 No Content
< Content-Length: 0
< Cross-Origin-Resource-Policy: cross-origin
< Date: Wed, 04 Jan 2023 00:58:41 GMT
< 
* Connection #0 to host storage.googleapis.com left intact
```
Si la connexion échoue, la sortie ressemble à ce qui suit :
```
*   Trying 142.250.148.128:443...
* Connection timed out after 5000 milliseconds
* Closing connection 0
curl: (28) Connection timed out after 5000 milliseconds```
```
Si la connexion expire et que l'adresse IP renvoyée est comprise dans la plage d'adresses IP 199.36.153.0/24, vérifiez que votre cluster remplit les conditions préalables à la mise en réseau pour la connexion aux API et services Google. Si la connexion expire et que l'adresse IP renvoyée ne se trouve pas dans la plage d'adresses IP mentionnée, vérifiez s'il existe des règles de pare-feu bloquant le trafic sortant ou des routes mal configurées dans le réseau VPC de votre cluster.

Gardez la connexion SSH à l'instance de VM ouverte et passez à la section suivante.

Vérifier la connexion sans accès SSH à l'aide des tests de connectivité

Si vous ne disposez pas d'un accès SSH aux instances de VM, utilisez les tests de connectivité pour vérifier que l'instance de VM dispose d'une connexion aux API et services Google.

Recherchez une instance dont l'enregistrement des nœuds a échoué.
Créez et exécutez des tests de connectivité avec l'instance de VM en tant que source et storage.googleapis.com TCP/443 en tant que destination.

Utilisez les résultats du test pour vérifier la configuration réseau de votre cluster.

Vérifier la connexion réseau avec le plan de contrôle pour l'enregistrement des nœuds

Si vous disposez d'un accès SSH aux instances de VM dans votre projet, vous pouvez vérifier si l'instance de VM dispose d'une connexion réseau au plan de contrôle du cluster.

Recherchez une instance dont l'enregistrement des nœuds a échoué.
Dans l'onglet Détails de l'instance de VM, cliquez sur SSH.
Une fois que vous êtes connecté à la ligne de commande de votre instance de VM, enregistrez le point de terminaison du plan de contrôle du cluster en tant que variable d'environnement :
```
source <(sudo grep KUBERNETES_MASTER_NAME /home/kubernetes/kube-env)
```

Envoyez une requête GET au point de terminaison du plan de contrôle :

curl -k -m 5  https://${KUBERNETES_MASTER_NAME}/version

Si la sortie ressemble à ce qui suit, l'instance de VM peut établir une connexion avec le plan de contrôle :

{
"major": "1",
"minor": "24",
"gitVersion": "v1.24.7-gke.900",
"gitCommit": "e35c4457f66187eff006dda6d2c0fe12144ef2ec",
"gitTreeState": "clean",
"buildDate": "2022-10-26T09:25:34Z",
"goVersion": "go1.18.7b7",
"compiler": "gc",
"platform": "linux/amd64"
}

Si la sortie ressemble à ce qui suit, l'instance de VM ne peut pas établir de connexion avec le plan de contrôle :

curl: (28) Connection timed out after 5000 milliseconds

Si l'instance de VM ne peut pas établir de connexion avec le plan de contrôle, consultez la section sur l'autorisation de la connectivité du plan de contrôle dans les bonnes pratiques de mise en réseau GKE.

Terminer l'enregistrement des nœuds après avoir corrigé la cause première

Une fois résolu le problème qui bloque l'enregistrement des nœuds, la procédure à suivre dépend du contexte de l'échec :

Si l'enregistrement du nœud a échoué lors de la création du cluster, supprimez le cluster et réessayez.
Si l'enregistrement des nœuds a échoué lors du scaling à la hausse avec l'autoscaler de cluster, attendez que les instances de VM tentent à nouveau de s'enregistrer.
Si l'enregistrement des nœuds a échoué lors de la création du pool de nœuds, procédez comme suit :
- Si les instances de VM ont été créées, attendez qu'elles essayent à nouveau de s'enregistrer.
- Si les instances de VM n'ont pas été créées, supprimez le pool de nœuds, puis réessayez.
Si l'enregistrement des nœuds a échoué lors du redimensionnement du cluster, exécutez à nouveau la commande pour augmenter la taille de votre cluster.
Si l'enregistrement des nœuds a échoué en dehors du champ d'application d'une opération, par exemple lors d'une opération de réparation, attendez que les instances de VM tentent à nouveau de s'enregistrer.

Collecter des informations pour effectuer une enquête plus approfondie

Si vous ne parvenez pas à résoudre le problème d'enregistrement des nœuds, vous pouvez collecter des informations supplémentaires pour faciliter l'enquête de Cloud Customer Care en suivant les instructions ci-dessous. Ces étapes nécessitent un accès SSH aux instances de VM dans votre projet et utilisent l'utilitaire sosreport, qui est inclus dans les images COS.

Recherchez une instance dont l'enregistrement des nœuds a échoué.

Collectez des informations de débogage à l'aide de sosreport.

Si vos nœuds n'ont pas l'utilitaire sosreport téléchargé et qu'il ne peut pas être installé, vous pouvez également collecter les informations de débogage manuellement en exécutant les commandes suivantes:

sudo journalctl -u cloud-init-local
sudo journalctl -u cloud-init
sudo journalctl -u cloud-final
sudo journalctl -u cloud-config
systemctl status kubelet
journalctl -u kubelet
systemctl status kube-node-installation.service
systemctl status kube-node-configuration.service
journalctl -u kube-node-installation.service --no-pager
journalctl -u kube-node-configuration.service --no-pager
journalctl -u kubelet.service --no-pager

Placez ces informations dans un fichier ZIP et incluez-les lors de l'envoi d'une demande d'assistance à Cloud Customer Care.

Étapes suivantes

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