Compartir a través de


Solución de problemas del código de error OutboundConnFailVMExtensionError (50)

En este artículo se describe cómo identificar y resolver el OutboundConnFailVMExtensionError error (también conocido como código ERR_OUTBOUND_CONN_FAILde error , número de error 50) que puede producirse si crea, inicia, escala o actualiza un clúster de Microsoft Azure Kubernetes Service (AKS).

Prerequisites

  • La herramienta de línea de comandos Netcat (nc)

  • La herramienta de línea de comandos dig

  • La herramienta Dirección URL de cliente (cURL)

Symptoms

Al intentar crear, escalar o actualizar un clúster de AKS, puede recibir el siguiente mensaje de error:

No se puede establecer la conexión saliente de los agentes, consulte https://aka.ms/aks-required-ports-and-addresses para obtener más información.

Detalles: Code="VMExtensionProvisioningError"

Message="VM ha notificado un error al procesar la extensión "vmssCSE".

Mensaje de error: "Error al habilitar: no se pudo ejecutar el comando: el comando finalizó con el estado de salida=50\n[stdout]\n\n[stderr]\nnc: error al conectarse al puerto 443 (tcp) mcr.microsoft.com: Error en el tiempo de espera de la conexión\nComando salió con un estado distinto de cero.

Detalles del error: "mensajes de error de vmssCSE: {vmssCSE exit status=50, output=pt/apt.conf.d/95proxy...}

Este error también puede hacer que los nodos en ejecución se conviertan en NotReady o causen errores de extracción de imágenes porque la conectividad saliente está bloqueada desde algunos o todos los nodos del clúster.

Cause

La extensión de script personalizado que descarga los componentes necesarios para aprovisionar los nodos no pudo establecer la conectividad saliente necesaria para obtener paquetes. En el caso de los clústeres públicos, los nodos intentan comunicarse con el punto de conexión de Microsoft Container Registry (mcr.microsoft.comMCR) en el puerto 443.

Hay muchas razones por las que se puede bloquear el tráfico saliente. La mejor manera de solucionar errores de conectividad saliente es ejecutar un análisis de conectividad con el comprobador de red virtual de Azure (versión preliminar). Al ejecutar un análisis de conectividad, puede visualizar los saltos dentro del flujo de tráfico y cualquier configuración incorrecta dentro de los recursos de red de Azure que bloquean el tráfico. Para solucionar manualmente los errores de conectividad saliente, puede usar el protocolo Secure Shell (SSH) para conectarse al nodo. En esta sección se describen las instrucciones para ambos tipos de investigaciones:

Compruebe si los recursos de red de Azure están bloqueando el tráfico al punto de conexión.

Para determinar si el tráfico está bloqueado al punto de conexión debido a los recursos de red de Azure, ejecute un análisis de conectividad de los nodos del clúster de AKS al punto de conexión mediante la herramienta Comprobador de red virtual de Azure (versión preliminar). El análisis de conectividad cubre los siguientes recursos:

  • Equilibrador de carga de Azure
  • Azure Firewall
  • Puerta de enlace de traducción de direcciones de red (NAT)
  • Grupo de seguridad de red (NSG)
  • Directiva de red
  • Rutas definidas por el usuario (tablas de rutas)
  • Emparejamiento de redes virtuales de Azure

Note

Azure Virtual Network Verifier (versión preliminar) no puede acceder a ningún recurso de red externo o de terceros, como un firewall personalizado. Si el análisis de conectividad no detecta ningún tráfico bloqueado, se recomienda realizar una comprobación manual de cualquier red externa para cubrir todos los saltos del flujo de tráfico.

Actualmente, los clústeres que usan la superposición de Azure CNI no son compatibles con esta característica. La compatibilidad con la superposición de CNI está prevista para agosto de 2025.

  1. Vaya al clúster en Azure Portal. En la barra lateral, vaya a la hoja Configuración:> grupos de nodos.
  2. Identifique el grupo de nodos desde el que desea ejecutar un análisis de conectividad. Haga clic en el grupo de nodos para seleccionarlo como ámbito.
  3. Seleccione "Análisis de conectividad (versión preliminar)" en la barra de herramientas de la parte superior de la página. Si no lo ve, haga clic en los tres puntos "..." en la barra de herramientas de la parte superior de la página para abrir el menú expandido. Un usuario ejecuta el análisis de conectividad en un grupo de nodos seleccionado.
  4. Seleccione una instancia del conjunto de escalado de máquinas virtuales (VMSS) como origen. Las direcciones IP de origen se rellenan automáticamente.
  5. Seleccione un nombre de dominio o punto de conexión público como destino para el análisis, un ejemplo es mcr.microsoft.com. Las direcciones IP de destino también se rellenan automáticamente.
  6. Ejecute el análisis y espere hasta 2 minutos para los resultados. En el diagrama resultante, identifique los recursos de red de Azure asociados y dónde se bloquea el tráfico. Para ver la salida de análisis detallada, haga clic en la pestaña "Salida JSON" o haga clic en las flechas del diagrama.

Solución de problemas manual

Si la herramienta Verificador de Red Virtual de Azure (Vista previa) no proporciona suficiente información sobre el problema, puede solucionar manualmente los fallos de conectividad saliente usando el protocolo SSH para conectar al nodo. Para establecer la conexión, siga las instrucciones de Conexión a nodos de clúster de Azure Kubernetes Service (AKS) para mantenimiento o solución de problemas. A continuación, pruebe la conectividad en el clúster siguiendo estos pasos:

  1. Después de conectarse al nodo, ejecute los nc comandos y dig :

    nc -vz mcr.microsoft.com 443 
    dig mcr.microsoft.com 443
    

    Note

    Si no puede acceder al nodo a través de SSH, puede probar la conectividad saliente ejecutando el comando az vmss run-command invoke en la instancia del conjunto de escalado de máquinas virtuales:

    # Get the VMSS instance IDs.
    az vmss list-instances --resource-group <mc-resource-group-name> \
        --name <vmss-name> \
        --output table
    
    # Use an instance ID to test outbound connectivity.
    az vmss run-command invoke --resource-group <mc-resource-group-name> \
        --name <vmss-name> \
        --command-id RunShellScript \
        --instance-id <vmss-instance-id> \
        --output json \
        --scripts "nc -vz mcr.microsoft.com 443"
    
  2. Si intenta crear un clúster de AKS mediante un proxy HTTP, ejecute los nccomandos , curly dig después de conectarse al nodo:

    # Test connectivity to the HTTP proxy server from the AKS node.
    nc -vz <http-s-proxy-address> <port>
    
    # Test traffic from the HTTP proxy server to HTTPS.
    curl --proxy http://<http-proxy-address>:<port>/ --head https://mcr.microsoft.com
    
    # Test traffic from the HTTPS proxy server to HTTPS.
    curl --proxy https://<https-proxy-address>:<port>/ --head https://mcr.microsoft.com
    
    # Test DNS functionality.
    dig mcr.microsoft.com 443
    

    Note

    Si no puede acceder al nodo a través de SSH, puede probar la conectividad saliente ejecutando el az vmss run-command invoke comando en la instancia del conjunto de escalado de máquinas virtuales:

    # Get the VMSS instance IDs.
    az vmss list-instances --resource-group <mc-resource-group-name> \
        --name <vmss-name> \
        --output table
    
    # Use an instance ID to test connectivity from the HTTP proxy server to HTTPS.
    az vmss run-command invoke --resource-group <mc-resource-group-name> \
        --name <vmss-name> \
        --command-id RunShellScript \
        --instance-id <vmss-instance-id> \
        --output json \
        --scripts "curl --proxy http://<http-proxy-address>:<port>/ --head https://mcr.microsoft.com"
    
    # Use an instance ID to test connectivity from the HTTPS proxy server to HTTPS.
    az vmss run-command invoke --resource-group <mc-resource-group-name> \
        --name <vmss-name> \
        --command-id RunShellScript \
        --instance-id <vmss-instance-id> \
        --output json \
        --scripts "curl --proxy https://<https-proxy-address>:<port>/ --head https://mcr.microsoft.com"
    
    # Use an instance ID to test DNS functionality.
    az vmss run-command invoke --resource-group <mc-resource-group-name> \
        --name <vmss-name> \
        --command-id RunShellScript \
        --instance-id <vmss-instance-id> \
        --output json \
        --scripts "dig mcr.microsoft.com 443"
    

Solution

En la tabla siguiente se enumeran los motivos específicos por los que se puede bloquear el tráfico y la solución correspondiente por cada motivo:

Issue Solution
Las reglas de firewall bloquean el tráfico, un servidor proxy o un grupo de seguridad de red (NSG) Este problema se produce cuando un firewall, un servidor proxy o un grupo de seguridad de red bloquean los puertos necesarios de AKS o nombres de dominio completos (FQDN). Asegúrese de que se permiten estos puertos y FQDN. Para determinar lo que está bloqueado, compruebe la conectividad proporcionada en la sección Causa anterior. Para más información sobre los puertos y FQDN necesarios de AKS, consulte Reglas de FQDN y red saliente para clústeres de Azure Kubernetes Service (AKS).
El registro AAAA (IPv6) está bloqueado en el firewall. En el firewall, compruebe que no existe nada que impida que el punto de conexión se resuelva en Azure DNS.
El clúster privado no puede resolver recursos internos de Azure En clústeres privados, la dirección IP de Azure DNS (168.63.129.16) debe agregarse como un servidor DNS ascendente si se usa DNS personalizado. Compruebe que la dirección está establecida en los servidores DNS. Para obtener más información, consulte Creación de un clúster de AKS privado y ¿Qué es la dirección IP 168.63.129.16?.

Información adicional

Aviso de declinación de responsabilidades sobre la información de contacto de terceros

Microsoft proporciona información de contacto de otros proveedores para ayudarle a encontrar información adicional sobre este tema. Esta información de contacto puede cambiar sin previo aviso. Microsoft no garantiza la precisión de esta información de contacto de terceros.