Solución de problemas de errores de nodo no listos causados por errores de CSE

  • Artículo

Este artículo le ayuda a solucionar escenarios en los que un clúster de Microsoft Azure Kubernetes Service (AKS) no está en el Succeeded estado y un nodo de AKS no está listo dentro de un grupo de nodos debido a errores de extensión de script personalizado (CSE).

Requisitos previos

Síntomas

Debido a errores de CSE, un nodo de clúster de AKS no está listo dentro de un grupo de nodos y el clúster de AKS no está en el Succeeded estado .

Causa

Se produce un error en la implementación de la extensión de nodo y devuelve más de un código de error al aprovisionar kubelet y otros componentes. Esta es la causa más común de errores. Para comprobar que se produce un error en la implementación de la extensión de nodo al aprovisionar kubelet, siga estos pasos:

  1. Para comprender mejor el error actual en el clúster, ejecute los comandos az aks show y az resource update para configurar la depuración:

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

  2. Compruebe la salida de depuración y los mensajes de error que recibió del az resource update comando en la lista de errores del archivo ejecutable del asistente de CSE en GitHub.

Si alguno de los errores implica la implementación de CSE de kubelet, ha comprobado que el escenario que se describe aquí es la causa del error Node Not Ready.

En general, los códigos de salida identifican el problema específico que provoca el error. Por ejemplo, verá mensajes como "No se puede comunicar con el servidor de API" o "No se puede conectar a Internet". O bien, los códigos de salida pueden alertarle sobre los tiempos de espera de red de la API o un error de nodo que necesita un reemplazo.

Solución 1: Asegúrese de que el servidor DNS personalizado está configurado correctamente

Configure el servidor del sistema de nombres de dominio (DNS) personalizado para que pueda resolver los nombres correctamente. Configure el servidor para que cumpla los siguientes requisitos:

  • Si usa servidores DNS personalizados, asegúrese de que los servidores estén en buen estado y sean accesibles a través de la red.

  • Asegúrese de que los servidores DNS personalizados tengan los reenviadores condicionales necesarios a la dirección IP de Azure DNS (o al reenviador a esa dirección).

  • Asegúrese de que la zona DNS de AKS privada está vinculada a las redes virtuales DNS personalizadas si están hospedadas en Azure.

  • No use la dirección IP de Azure DNS con las direcciones IP del servidor DNS personalizado. No se recomienda hacer esto.

  • Evite usar direcciones IP en lugar del servidor DNS en la configuración de DNS. Puede usar comandos de la CLI de Azure para comprobar esta situación en un conjunto de escalado de máquinas virtuales (VM) o un conjunto de disponibilidad.

    • Para los nodos del conjunto de escalado de máquinas virtuales, use el comando 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>"

    • Para los nodos del conjunto de disponibilidad de máquinas virtuales, use el comando 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>"

Para obtener más información, consulte Resolución de nombres para recursos en redes virtuales de Azure y concentrador y habló con DNS personalizado.

Solución 2: Corrección de tiempos de espera de red de API

Asegúrese de que se puede acceder al servidor de API y no está sujeto a retrasos. Para ello, siga estos pasos:

  • Compruebe la subred de AKS para ver si el grupo de seguridad de red (NSG) asignado está bloqueando el puerto de tráfico de salida 443 al servidor de API.

  • Compruebe el propio nodo para ver si el nodo tiene otro grupo de seguridad de red que bloquea el tráfico.

  • Compruebe la subred de AKS en busca de cualquier tabla de rutas asignada. Si una tabla de rutas tiene una aplicación virtual de red (NVA) o firewall, asegúrese de que el puerto 443 está disponible para el tráfico de salida. Para obtener más información, consulte Control del tráfico de salida para nodos de clúster en AKS.

  • Si el DNS resuelve los nombres correctamente y se puede acceder a la API, pero el CSE del nodo no se pudo realizar debido a un tiempo de espera de la API, realice la acción adecuada como se muestra en la tabla siguiente.

    Establecer tipo Acción
    Conjunto de disponibilidad de máquinas virtuales Elimine el nodo de la Azure Portal y la API de AKS mediante el comando kubectl delete node y, a continuación, vuelva a escalar verticalmente el clúster.
    Conjunto de escalado de máquinas virtuales Vuelva a crear una imagen del nodo o elimine el nodo y, a continuación, escale verticalmente de nuevo el clúster.

  • Si el servidor de API de AKS limita las solicitudes, actualice a un nivel de servicio superior. Para obtener más información, consulte Acuerdo de Nivel de Servicio de tiempo de actividad de AKS.

Más información