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.
¿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.
¿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:
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:stableDespués de ejecutar el pod de prueba, obtendrá acceso al pod.
Ejecute los siguientes comandos
apt-getpara instalar otros paquetes de herramientas:apt-get update -y apt-get install dnsutils -y apt-get install curl -y apt-get install netcat -yUna 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.50Pruebe 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.85Ejecute el comando
hostpara 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 msEjecute 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"Ejecute el comando kubectl exec para conectarse al pod mediante PowerShell:
kubectl exec -it dnsutil-win -- powershellEjecute 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
- Consulte más sugerencias de solución de problemas para usar Kubernetes habilitado para Azure Arc.
- Revise el proceso para conectar un clúster de Kubernetes existente a Azure Arc.