Résoudre les échecs de nœud non prêt causés par des erreurs CSE
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 qu’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).
Prerequisites
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 la plus courante des erreurs. Pour vérifier que le déploiement de l’extension de nœud échoue lorsque vous approvisionnez le kubelet, procédez comme suit :
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
Vérifiez la sortie de débogage et les messages d’erreur que vous avez reçus de la commande par rapport à la
az resource update
liste d’erreurs dans le fichier exécutable de l’assistance CSE sur GitHub.
Si l’une des erreurs implique le déploiement CSE du 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 qui provoque l’échec. Par exemple, vous voyez 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’expiration du réseau d’API ou d’une erreur de nœud qui a besoin d’un remplacement.
Solution 1 : Vérifiez que votre serveur DNS personnalisé est configuré correctement
Configurez votre serveur DNS (Domain Name System) personnalisé afin qu’il puisse effectuer la résolution de noms correctement. Vous devez configurer le serveur pour qu’il respecte les 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 à l’adresse IP Azure DNS (ou du 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 du DNS Azure avec les adresses IP de votre serveur DNS personnalisé. Ceci n'est pas recommandé.
Évitez d’utiliser des adresses IP au lieu du serveur DNS dans les paramètres DNS. Vous pouvez utiliser des commandes Azure CLI pour vérifier cette situation sur un groupe de machines virtuelles identiques ou un groupe à haute disponibilité.
Pour les nœuds du 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 du 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 réseau de l’API
Assurez-vous que le serveur d’API peut être atteint et n’est pas soumis à des retards. Pour ce faire, procédez comme suit :
Vérifiez le sous-réseau AKS pour déterminer si le groupe de sécurité réseau affecté bloque le port de trafic de sortie 443 vers le serveur d’API.
Vérifiez le nœud lui-même pour déterminer si le nœud a un autre groupe de sécurité réseau qui bloque le trafic.
Vérifiez le sous-réseau AKS pour toute table de routage affectée. Si une table de routage a une appliance virtuelle 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 le CSE de nœud a échoué en raison d’un délai d’attente d’API, effectuez l’action appropriée, comme indiqué dans le tableau suivant.
Définir le type Action Groupe à haute disponibilité de machines virtuelles Supprimez le nœud du Portail Azure et l’API AKS à l’aide de la commande kubectl delete node, puis effectuez un scale-up du cluster à nouveau. Groupe de machines virtuelles identiques Réimagez le nœud à partir du Portail Azure, ou supprimez le nœud, puis effectuez un scale-up du cluster à nouveau. Pour supprimer le nœud spécifique, utilisez la commande az aks nodepool delete-machines . Il cordon &draine d’abord, puis supprime le nœud. Si les requêtes 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 les niveaux tarifaires pour AKS.
Plus d’informations
- Pour connaître les étapes de dépannage générales, consultez La résolution des problèmes de base des échecs Node Not Ready.