Compartir a través de

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

  • Artículo

Este artículo le ayuda a solucionar los 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 estado Succeeded .

Causa

Se produce un error en la implementación de la extensión de nodo y se 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 del kubelet, ha comprobado que el escenario que se describe aquí es la causa del error No preparado del nodo.

En general, los códigos de salida identifican el problema específico que está causando 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 avisarle a los tiempos de espera de la red de API o a un error de nodo que necesite un reemplazo.

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

Configure el servidor personalizado del Sistema de nombres de dominio (DNS) para que pueda realizar la resolución de nombres correctamente. Configure el servidor para cumplir los siguientes requisitos:

  • Si usa servidores DNS personalizados, asegúrese de que los servidores son correctos y accesibles a través de la red.

  • Asegúrese de que los servidores DNS personalizados tienen 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 privada de AKS esté vinculada a las redes virtuales DNS personalizadas si están hospedadas en Azure.

  • No utilice la dirección IP de Azure DNS con las direcciones IP del servidor DNS personalizado. No se recomienda hacerlo.

  • 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 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>"

    • En el caso de 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 más información, consulte Resolución de nombres para recursos en redes virtuales de Azure y concentrador y radio 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 que 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 está bloqueando 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 un firewall, asegúrese de que el puerto 443 está disponible para el tráfico de salida. Para obtener más información, vea Control del tráfico de salida de los nodos de clúster en AKS.

  • Si el DNS resuelve correctamente los nombres y la API es accesible, pero el nodo CSE produjo un error debido a un tiempo de espera de la API, realice la acción adecuada, como se muestra en la tabla siguiente.

    Establecer tipo Action
    Conjunto de disponibilidad de VM Elimine el nodo de Azure Portal y la API de AKS mediante el comando kubectl delete node y vuelva a escalar verticalmente el clúster.
    Conjunto de escalado de máquinas virtuales Vuelva a crear la imagen del nodo desde Azure Portal o elimine el nodo y, a continuación, vuelva a escalar verticalmente el clúster. Para eliminar el nodo específico, use el comando az aks nodepool delete-machines . Acordonará y purgará primero y luego eliminará el nodo.

  • Si el servidor de API de AKS limita las solicitudes, actualice a un nivel de servicio superior. Para más información, consulte Planes de tarifa para AKS.

Más información