Partager via

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

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 .

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

  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 :

    Définissez vos variables d’environnement et exécutez les commandes pour afficher l’état du cluster et déboguer les informations.

    export RG_NAME="my-aks-rg"
export CLUSTER_NAME="myakscluster"
clusterResourceId=$(az aks show \
    --resource-group $RG_NAME --name $CLUSTER_NAME --output tsv --query id)
az resource update --debug --verbose --ids $clusterResourceId

    Résultats :

    {
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-aks-rg-xxx/providers/Microsoft.ContainerService/managedClusters/myaksclusterxxx",
  "name": "myaksclusterxxx",
  "type": "Microsoft.ContainerService/managedClusters",
  "location": "eastus2",
  "tags": null,
  "properties": {
    ...
  }
}

  2. 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 :

      Important: Vous devez spécifier l’ensemble de mise à l'échelle de VM. Ici, nous démontrons comment interroger un identifiant d'instance valide (par exemple, 0) et un groupe de machines virtuelles à échelle variable (VMSS) probable dans un groupe de ressources de nœud AKS. Mettez à jour les valeurs de manière appropriée pour qu’elles correspondent à votre environnement.

      export NODE_RESOURCE_GROUP=$(az aks show --resource-group $RG_NAME --name $CLUSTER_NAME --query nodeResourceGroup -o tsv)
export VMSS_NAME=$(az vmss list --resource-group $NODE_RESOURCE_GROUP --query "[0].name" -o tsv)
export DNS_IP_ADDRESS="10.0.0.10"
export INSTANCE_ID=$(az vmss list-instances --resource-group $NODE_RESOURCE_GROUP --name $VMSS_NAME --query "[0].instanceId" -o tsv)
export API_FQDN=$(az aks show --resource-group $RG_NAME --name $CLUSTER_NAME --query fqdn -o tsv)

az vmss run-command invoke \
    --resource-group $NODE_RESOURCE_GROUP \
    --name $VMSS_NAME \
    --instance-id $INSTANCE_ID \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet $DNS_IP_ADDRESS 53"
az vmss run-command invoke \
    --resource-group $NODE_RESOURCE_GROUP \
    --name $VMSS_NAME \
    --instance-id $INSTANCE_ID \
    --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 :

      Important: Vous devez spécifier la --name machine virtuelle valide dans un groupe à haute disponibilité dans votre groupe de ressources. Voici un modèle permettant d’exécuter des vérifications réseau.

      az vm run-command invoke \
    --resource-group $RG_NAME \
    --name $AVAILABILITY_SET_VM \
    --command-id RunShellScript \
    --output tsv \
    --query "value[0].message" \
    --scripts "telnet $DNS_IP_ADDRESS 53"
az vm run-command invoke \
    --resource-group $RG_NAME \
    --name $AVAILABILITY_SET_VM \
    --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

  • Last updated on