Partager via


Diagnostiquer les problèmes de connexion pour les clusters Kubernetes avec Azure Arc

Si vous rencontrez des problèmes pour connecter un cluster à Azure Arc, examinez les problèmes listés ici. Nous fournissons deux organigrammes avec une aide guidée : le premier suppose que vous n’utilisez pas de serveur proxy et le deuxième s’applique si votre connexion réseau utilise un serveur proxy.

Conseil

Les étapes décrites dans cet organigramme s’appliquent si vous utilisez Azure CLI ou Azure PowerShell pour connecter votre cluster. Toutefois, certaines étapes nécessitent l’utilisation d’Azure CLI. Si vous n’avez pas encore installé Azure CLI, faites-le avant de commencer.

Connexions sans proxy

Passez en revue cet organigramme pour diagnostiquer le problème que vous rencontrez quand vous essayez connecter un cluster à Azure Arc sans serveur proxy. Plus d’informations sur chaque étape sont fournies ci-dessous.

Organigramme montrant une représentation visuelle de la recherche des problèmes de connexion quand vous n’utilisez pas de proxy.

L’identité Azure a-t-elle des autorisations suffisantes ?

Passez en revue les prérequis de la connexion d’un cluster et vérifiez que l’identité que vous utilisez pour connecter le cluster a les autorisations nécessaires.

Exécutez-vous la dernière version d’Azure CLI ?

Vérifiez que vous avez installé la dernière version.

Si vous avez connecté votre cluster à l’aide d’Azure PowerShell, vérifiez que vous êtes exécuter la dernière version.

La version de l’extension connectedk8s est-elle la dernière ?

Mettez à jour l’extension Azure CLI connectedk8s vers la dernière version en exécutant cette commande :

az extension update --name connectedk8s

Si vous n’avez pas encore installé l’extension, vous pouvez le faire en exécutant la commande suivante :

az extension add --name connectedk8s

Kubeconfig pointe-t-il vers le bon cluster ?

Exécutez kubectl config get-contexts pour vérifier le nom du contexte cible. Ensuite, définissez le contexte par défaut sur le bon cluster en exécutant kubectl config use-context <target-cluster-name>.

Tous les fournisseurs de ressources nécessaires sont-ils inscrits ?

Vérifiez que les fournisseurs de ressources Microsoft.Kubernetes, Microsoft.KubernetesConfiguration et Microsoft.ExtendedLocation sont inscrits.

Toutes les exigences réseau sont-elles satisfaites ?

Passez en revue les exigences réseau et vérifiez qu’aucun des points de terminaison nécessaires n’est bloqué.

Tous les pods de l’espace de noms azure-arc sont-ils en cours d’exécution ?

Si tout fonctionne correctement, vos pods doivent tous être dans l’état Running. Exécutez kubectl get pods -n azure-arc pour vérifier si l’état d’un pod n’est pas Running.

Vous rencontrez encore des problèmes ?

Les étapes ci-dessus résolvent de nombreux problèmes de connexion courants, mais si vous ne parvenez toujours pas à vous connecter, générez un fichier journal de résolution de problèmes, puis ouvrez une demande de support pour que nous puissions investiguer le problème plus en détail.

Pour générer le fichier journal de résolution de problèmes, exécutez la commande suivante :

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

Quand vous créez votre demande de support, dans la section Détails supplémentaires, utilisez l’option Chargement de fichier pour charger le fichier journal généré.

Connexions avec un serveur proxy

Si vous utilisez un serveur proxy sur au moins une machine, suivez les cinq premières étapes de l’organigramme sans proxy (inscription du fournisseur de ressources) pour la résolution de problèmes de base. Ensuite, si vous rencontrez toujours des problèmes, passez en revue l’organigramme suivant pour connaître les étapes supplémentaires de résolution de problèmes. Plus d’informations sur chaque étape sont fournies ci-dessous.

Organigramme montrant une représentation visuelle de la recherche des problèmes de connexion quand vous utilisez un proxy.

La machine exécute-t-elle des commandes derrière un serveur proxy ?

Si la machine exécute des commandes derrière un serveur proxy, vous devez définir toutes les variables d’environnement nécessaires. Pour plus d’informations, consultez Se connecter à l’aide d’un serveur proxy sortant.

Par exemple :

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

Le serveur proxy accepte-t-il uniquement les certificats approuvés ?

Veillez à inclure le chemin du fichier de certificat en ajoutant --proxy-cert <path-to-cert-file> quand vous exécutez la commande az connectedk8s connect.

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

Le serveur proxy peut-il accéder aux points de terminaison réseau nécessaires ?

Passez en revue les exigences réseau et vérifiez qu’aucun des points de terminaison nécessaires n’est bloqué.

Le serveur proxy utilise-t-il uniquement HTTP ?

Si votre serveur proxy utilise uniquement HTTP, vous pouvez utiliser proxy-http pour les deux paramètres.

Si votre serveur proxy est configuré avec HTTP et HTTPS, exécutez la commande az connectedk8s connect avec les paramètres --proxy-https et --proxy-http spécifiés. Utilisez --proxy-http pour le proxy HTTP et --proxy-https pour le 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>  

Le serveur proxy nécessite-t-il des plages d’évitement pour la communication service à service ?

Si vous avez besoin de plages d’évitement, utilisez --proxy-skip-range <excludedIP>,<excludedCIDR> dans votre commande 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>

Tous les pods de l’espace de noms azure-arc sont-ils en cours d’exécution ?

Si tout fonctionne correctement, vos pods doivent tous être dans l’état Running. Exécutez kubectl get pods -n azure-arc pour vérifier si l’état d’un pod n’est pas Running.

Vérifier si la résolution DNS réussit pour le point de terminaison

À partir du pod, vous pouvez exécuter une recherche DNS sur le point de terminaison.

Que faire si vous ne pouvez pas exécuter la commande kubectl exec pour vous connecter au pod et installer le package DNS Utils ? Dans ce cas, vous pouvez démarrer un pod de test dans le même espace de noms que le pod problématique, puis exécuter les tests.

Remarque

Si la résolution DNS ou le trafic de sortie ne vous permet pas d’installer les packages réseau nécessaires, vous pouvez utiliser l’image Docker rishasi/ubuntu-netutil:1.0. Dans cette image, les packages requis sont déjà installés.

Voici un exemple de procédure pour vérifier la résolution DNS :

  1. Démarrez un pod de test dans le même espace de noms que le pod problématique :

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

    Une fois le pod de test en cours d’exécution, vous avez accès au pod.

  2. Exécutez les commandes apt-get suivantes pour installer d’autres packages d’outils :

    apt-get update -y
    apt-get install dnsutils -y
    apt-get install curl -y
    apt-get install netcat -y
    
  3. Une fois les packages installés, exécutez la commande nslookup pour tester la résolution DNS sur le point de terminaison :

    $ nslookup microsoft.com
    Server:         10.0.0.10
    Address:        10.0.0.10#53
    ...
    ...
    Name:   microsoft.com
    Address: 20.53.203.50
    
  4. Essayez directement la résolution DNS à partir du serveur DNS en amont. Cet exemple utilise 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. Exécutez la commande host pour vérifier si les requêtes DNS sont acheminées vers le serveur en amont :

    $ 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. Exécutez un pod de test dans le pool de nœuds 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. Exécutez la commande kubectl exec pour vous connecter au pod en utilisant PowerShell :

    kubectl exec -it dnsutil-win -- powershell
    
  8. Exécutez l’applet de commande Resolve-DnsName dans PowerShell pour vérifier si la résolution DNS fonctionne pour le point de terminaison :

    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 résolution DNS échoue, vérifiez la configuration DNS du cluster.

Vous rencontrez encore des problèmes ?

Les étapes ci-dessus résolvent de nombreux problèmes de connexion courants, mais si vous ne parvenez toujours pas à vous connecter, générez un fichier journal de résolution de problèmes, puis ouvrez une demande de support pour que nous puissions investiguer le problème plus en détail.

Pour générer le fichier journal de résolution de problèmes, exécutez la commande suivante :

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

Quand vous créez votre demande de support, dans la section Détails supplémentaires, utilisez l’option Chargement de fichier pour charger le fichier journal généré.

Étapes suivantes