Partager via

Résoudre les défaillances de nœud non prêtes provoquées par des erreurs CSE

  • Article

Cet article vous aide à résoudre les scénarios dans lesquels un cluster Microsoft Azure Kubernetes Service (AKS) n’est pas dans l’état Succeeded et un nœud AKS n’est pas prêt dans un pool de nœuds en raison d’erreurs d’extension de script personnalisé (CSE).

Conditions préalables

Symptômes

En raison d’erreurs CSE, un nœud de cluster AKS n’est pas prêt dans un pool de nœuds et le cluster AKS n’est pas dans l’état Succeeded .

Cause

Le déploiement de l’extension de nœud échoue et retourne plusieurs codes d’erreur lorsque vous approvisionnez kubelet et d’autres composants. Il s’agit de la cause d’erreurs la plus courante. Pour vérifier que le déploiement de l’extension de nœud échoue lorsque vous approvisionnez kubelet, procédez comme suit :

  1. Pour mieux comprendre l’échec actuel sur le cluster, exécutez les commandes az aks show et az resource update pour configurer le débogage :

    clusterResourceId=$(az aks show \
    --resource-group <resource-group-name> --name <cluster-name> --output tsv --query id)
az resource update --debug --verbose --ids $clusterResourceId

  2. Vérifiez la sortie du débogage et les messages d’erreur que vous avez reçus de la az resource update commande par rapport à la liste d’erreurs dans le fichier exécutable de l’assistance CSE sur GitHub.

Si l’une des erreurs implique le déploiement CSE de kubelet, vous avez vérifié que le scénario décrit ici est la cause de l’échec du nœud non prêt.

En général, les codes de sortie identifient le problème spécifique à l’origine de l’échec. Par exemple, vous verrez des messages tels que « Impossible de communiquer avec le serveur d’API » ou « Impossible de se connecter à Internet ». Ou les codes de sortie peuvent vous avertir des délais d’attente du réseau d’API ou d’une erreur de nœud qui nécessite un remplacement.

Solution 1 : Vérifiez que votre serveur DNS personnalisé est correctement configuré

Configurez votre serveur DNS (Domain Name System) personnalisé afin qu’il puisse effectuer la résolution de noms correctement. Configurez le serveur pour répondre aux exigences suivantes :

  • Si vous utilisez des serveurs DNS personnalisés, assurez-vous que les serveurs sont sains et accessibles sur le réseau.

  • Assurez-vous que les serveurs DNS personnalisés disposent des redirecteurs conditionnels requis vers l’adresse IP Azure DNS (ou le redirecteur vers cette adresse).

  • Assurez-vous que votre zone DNS AKS privée est liée à vos réseaux virtuels DNS personnalisés s’ils sont hébergés sur Azure.

  • N’utilisez pas l’adresse IP Azure DNS avec les adresses IP de votre serveur DNS personnalisé. Cette opération n’est pas recommandée.

  • Évitez d’utiliser des adresses IP au lieu du serveur DNS dans les paramètres DNS. Vous pouvez utiliser les commandes Azure CLI pour case activée pour cette situation sur un groupe de machines virtuelles identiques ou un groupe à haute disponibilité.

    • Pour les nœuds de groupe de machines virtuelles identiques, utilisez la commande az vmss run-command invoke :

      az vmss run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-scale-set-name> \
    --command-id RunShellScript \
    --instance-id 0 \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet <dns-ip-address> 53"
az vmss run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-scale-set-name> \
    --instance-id 0 \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "nslookup <api-fqdn> <dns-ip-address>"

    • Pour les nœuds de groupe à haute disponibilité de machine virtuelle, utilisez la commande az vm run-command invoke :

      az vm run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-availability-set-name> \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet <dns-ip-address> 53"
az vm run-command invoke \
    --resource-group <resource-group-name> \
    --name <vm-availability-set-name> \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "nslookup <api-fqdn> <dns-ip-address>"

Pour plus d’informations, consultez Résolution de noms pour les ressources dans les réseaux virtuels Azure et Hub-and-spoke avec dns personnalisé.

Solution 2 : Corriger les délais d’attente du réseau d’API

Assurez-vous que le serveur d’API est accessible et qu’il n’est pas soumis à des retards. Pour cela, procédez comme suit :

  • Vérifiez le sous-réseau AKS pour voir si le groupe de sécurité réseau (NSG) affecté bloque le port de trafic de sortie 443 vers le serveur d’API.

  • Vérifiez le nœud lui-même pour voir si le nœud a un autre groupe de sécurité réseau qui bloque le trafic.

  • Vérifiez dans le sous-réseau AKS toute table de routage affectée. Si une table de routage a un Appliance virtuel réseau (NVA) ou un pare-feu, assurez-vous que le port 443 est disponible pour le trafic de sortie. Pour plus d’informations, consultez Contrôler le trafic de sortie pour les nœuds de cluster dans AKS.

  • Si le DNS résout correctement les noms et que l’API est accessible, mais que l’authentification CSE du nœud a échoué en raison d’un délai d’attente de l’API, effectuez l’action appropriée comme indiqué dans le tableau suivant.

    Type de définition Action
    Groupe à haute disponibilité de machine virtuelle Supprimez le nœud de la Portail Azure et de l’API AKS à l’aide de la commande kubectl delete node, puis effectuez un nouveau scale-up du cluster.
    Groupe de machines virtuelles identiques Réimagez le nœud ou supprimez-le, puis effectuez un scale-up du cluster.

  • Si les demandes sont limitées par le serveur d’API AKS, effectuez une mise à niveau vers un niveau de service supérieur. Pour plus d’informations, consultez CONTRAT SLA de durée de fonctionnement AKS.

Informations supplémentaires