Compartir por


Diagnóstico de problemas de conexión para clústeres de Kubernetes habilitados para Azure Arc

Si tiene problemas para conectar un clúster a Azure Arc, es probable que se deba a uno de los problemas que se enumeran aquí. Proporcionamos dos diagramas de flujo con ayuda guiada: uno si no usa un servidor proxy y otro que se aplica si la conexión de red usa un servidor proxy.

Sugerencia

Los pasos de este diagrama de flujo se aplican tanto si usa la CLI de Azure como Azure PowerShell para conectar el clúster. Sin embargo, algunos de los pasos requieren el uso de la CLI de Azure. Si aún no ha instalado la CLI de Azure, asegúrese de hacerlo antes de comenzar.

Conexiones sin un proxy

Revise este diagrama de flujo para diagnosticar el problema al intentar conectar un clúster a Azure Arc sin un servidor proxy. A continuación se ofrecen más detalles sobre cada paso.

Diagrama de flujo que muestra una representación visual de la comprobación de problemas de conexión cuando no se usa un proxy.

¿La identidad de Azure tiene permisos suficientes?

Revise los requisitos previos para conectar un clúster y asegúrese de que la identidad que usa para conectar el clúster tiene los permisos necesarios.

¿Ejecuta la versión más reciente de la CLI de Azure?

Asegúrese de que tiene la última versión instalada.

Si ha conectado el clúster mediante Azure PowerShell, asegúrese de que ejecuta la versión más reciente.

¿La extensión connectedk8s es la versión más reciente?

Actualice la extensión connectedk8s de la CLI de Azure a la versión más reciente mediante la ejecución de este comando:

az extension update --name connectedk8s

Si aún no ha instalado la extensión, puede hacerlo ejecutando el siguiente comando:

az extension add --name connectedk8s

¿Kubeconfig apunta al clúster correcto?

Ejecute kubectl config get-contexts para confirmar el nombre del contexto de destino. A continuación, establezca el contexto predeterminado en el clúster correcto mediante la ejecución de kubectl config use-context <target-cluster-name>.

¿Todos los proveedores de recursos necesarios están registrados?

Asegúrese de que los proveedores de recursos de Microsoft.Kubernetes, Microsoft.KubernetesConfiguration y Microsoft.ExtendedLocation están registrados.

¿Se cumplen todos los requisitos de red?

Revise los requisitos de red y asegúrese de que los puntos de conexión necesarios no estén bloqueados.

¿Se están ejecutando todos los pods del espacio de nombres azure-arc?

Si todo funciona correctamente, todos los pods deben estar en estado Running. Ejecute kubectl get pods -n azure-arc para confirmar si el estado de un pod no es Running.

¿Sigue teniendo problemas?

Los pasos anteriores resolverán muchos problemas comunes de conexión, pero si aún no puede conectarse correctamente, genere un archivo de registro de solución de problemas y abra una solicitud de soporte técnico para que podamos investigar el problema aún más.

Para generar el archivo de registro de solución de problemas, ejecute el siguiente comando:

az connectedk8s troubleshoot -g <myResourceGroup> -n <myK8sCluster>

Al crear la solicitud de soporte técnico, en la sección Detalles adicionales, use la opción Carga de archivos para cargar el archivo de registro generado.

Conexiones con un servidor proxy

Si usa un servidor proxy en al menos una máquina, complete los cinco primeros pasos del diagrama de flujo que no es de proxy (a través del registro del proveedor de recursos) para conocer los pasos básicos de solución de problemas. Después, si sigue experimentando problemas, revise el siguiente diagrama de flujo para ver los pasos de solución de problemas adicionales. A continuación se ofrecen más detalles sobre cada paso.

Diagrama de flujo que muestra una representación visual de la comprobación de problemas de conexión cuando se usa un proxy.

¿La máquina ejecuta comandos detrás de un servidor proxy?

Si la máquina ejecuta comandos detrás de un servidor proxy, deberá establecer todas las variables de entorno necesarias. Para obtener más información, consulte Conexión mediante un servidor proxy de salida.

Por ejemplo:

export HTTP_PROXY="http://<proxyIP>:<proxyPort>"
export HTTPS_PROXY="https://<proxyIP>:<proxyPort>"
export NO_PROXY="<cluster-apiserver-ip-address>:<proxyPort>"

¿El servidor proxy solo acepta certificados de confianza?

Asegúrese de incluir la ruta de acceso del archivo de certificado incluyendo --proxy-cert <path-to-cert-file> al ejecutar el comando az connectedk8s connect.

az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-cert <path-to-cert-file>

¿El servidor proxy puede acceder a los puntos de conexión de red necesarios?

Revise los requisitos de red y asegúrese de que los puntos de conexión necesarios no estén bloqueados.

¿El servidor proxy solo usa HTTP?

Si el servidor proxy solo usa HTTP, puede usar proxy-http para ambos parámetros.

Si el servidor proxy está configurado con HTTP y HTTPS, ejecute el comando az connectedk8s connect con los parámetros --proxy-https y --proxy-http especificados. Asegúrese de que usa --proxy-http para el proxy HTTP y --proxy-https para el proxy HTTPS.

az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-https https://<proxy-server-ip-address>:<port> --proxy-http http://<proxy-server-ip-address>:<port>  

¿El servidor proxy requiere intervalos de omisión para la comunicación entre servicios?

Si necesita intervalos de omisión, use --proxy-skip-range <excludedIP>,<excludedCIDR> en el comando az connectedk8s connect.

az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-https https://<proxy-server-ip-address>:<port> --proxy-http http://<proxy-server-ip-address>:<port> --proxy-skip-range <excludedIP>,<excludedCIDR>

¿Se están ejecutando todos los pods del espacio de nombres azure-arc?

Si todo funciona correctamente, todos los pods deben estar en estado Running. Ejecute kubectl get pods -n azure-arc para confirmar si el estado de un pod no es Running.

Compruebe si la resolución DNS se ha realizado correctamente para el punto de conexión.

Desde el pod, puede ejecutar una búsqueda DNS en el punto de conexión.

¿Qué ocurre si no puede ejecutar el comando kubectl exec para conectarse al pod e instalar el paquete DNS Utils? En esta situación, puede iniciar un pod de prueba en el mismo espacio de nombres que el pod problemático y, a continuación, ejecutar las pruebas.

Nota:

Si el tráfico de salida o resolución DNS no permite instalar los paquetes de red necesarios, puede usar la imagen de Docker de rishasi/ubuntu-netutil:1.0. En esta imagen, los paquetes necesarios ya están instalados.

Este es un procedimiento de ejemplo para comprobar la resolución DNS:

  1. Inicie un pod de prueba en el mismo espacio de nombres que el pod problemático:

    kubectl run -it --rm test-pod --namespace <namespace> --image=debian:stable
    

    Después de ejecutar el pod de prueba, obtendrá acceso al pod.

  2. Ejecute los siguientes comandos apt-get para instalar otros paquetes de herramientas:

    apt-get update -y
    apt-get install dnsutils -y
    apt-get install curl -y
    apt-get install netcat -y
    
  3. Una vez instalados los paquetes, ejecute el comando nslookup para probar la resolución DNS en el punto de conexión:

    $ nslookup microsoft.com
    Server:         10.0.0.10
    Address:        10.0.0.10#53
    ...
    ...
    Name:   microsoft.com
    Address: 20.53.203.50
    
  4. Pruebe la resolución DNS desde el servidor DNS ascendente directamente. En este ejemplo se usa Azure DNS:

    $ nslookup microsoft.com 168.63.129.16
    Server:         168.63.129.16
    Address:        168.63.129.16#53
    ...
    ...
    Address: 20.81.111.85
    
  5. Ejecute el comando host para comprobar si las solicitudes DNS se enrutan al servidor ascendente:

    $ host -a microsoft.com
    Trying "microsoft.com.default.svc.cluster.local"
    Trying "microsoft.com.svc.cluster.local"
    Trying "microsoft.com.cluster.local"
    Trying "microsoft.com.00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net"
    Trying "microsoft.com"
    Trying "microsoft.com"
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62884
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 5
    
    ;; QUESTION SECTION:
    ;microsoft.com.                 IN      ANY
    
    ;; ANSWER SECTION:
    microsoft.com.          30      IN      NS      ns1-39.azure-dns.com.
    ...
    ...
    ns4-39.azure-dns.info.  30      IN      A       13.107.206.39
    
    Received 2121 bytes from 10.0.0.10#53 in 232 ms
    
  6. Ejecute un pod de prueba en el grupo de nodos de Windows:

    # For a Windows environment, use the Resolve-DnsName cmdlet.
    kubectl run dnsutil-win --image='mcr.microsoft.com/windows/servercore:1809' --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "windows"}}}' -- powershell "Start-Sleep -s 3600"
    
  7. Ejecute el comando kubectl exec para conectarse al pod mediante PowerShell:

    kubectl exec -it dnsutil-win powershell
    
  8. Ejecute el cmdlet Resolve-DnsName en PowerShell para comprobar si la resolución DNS funciona para el punto de conexión:

    PS C:\> Resolve-DnsName www.microsoft.com 
    
    Name                           Type   TTL   Section    NameHost
    ----                           ----   ---   -------    --------
    www.microsoft.com              CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net
    www.microsoft.com-c-3.edgekey. CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
    net
    www.microsoft.com-c-3.edgekey. CNAME  20    Answer     e13678.dscb.akamaiedge.net
    net.globalredir.akadns.net
    
    Name       : e13678.dscb.akamaiedge.net 
    QueryType  : AAAA
    TTL        : 20
    Section    : Answer
    IP6Address : 2600:1408:c400:484::356e   
    
    
    Name       : e13678.dscb.akamaiedge.net 
    QueryType  : AAAA
    TTL        : 20
    Section    : Answer
    IP6Address : 2600:1408:c400:496::356e 
    
    
    Name       : e13678.dscb.akamaiedge.net
    QueryType  : A
    TTL        : 12
    Section    : Answer
    IP4Address : 23.200.197.152
    

Si la resolución DNS no se realiza correctamente, compruebe la configuración de DNS para el clúster.

¿Sigue teniendo problemas?

Los pasos anteriores resolverán muchos problemas comunes de conexión, pero si aún no puede conectarse correctamente, genere un archivo de registro de solución de problemas y abra una solicitud de soporte técnico para que podamos investigar el problema aún más.

Para generar el archivo de registro de solución de problemas, ejecute el siguiente comando:

az connectedk8s troubleshoot -g <myResourceGroup> -n <myK8sCluster>

Al crear la solicitud de soporte técnico, en la sección Detalles adicionales, use la opción Carga de archivos para cargar el archivo de registro generado.

Pasos siguientes