Partager via

Résoudre les problèmes de connexion à une application hébergée sur un cluster AKS

  • Article

Les problèmes de connexion à un cluster Microsoft Azure Kubernetes Service (AKS) peuvent signifier des choses différentes. Dans certains cas, cela peut signifier que la connexion au serveur d’API est affectée (par exemple, à l’aide de kubectl). Dans d’autres cas, cela peut signifier que les problèmes de connexion courants affectent une application hébergée sur le cluster AKS. Cet article explique comment résoudre les problèmes de connexion au cluster AKS.

Remarque

Pour résoudre les problèmes courants lorsque vous essayez de vous connecter au serveur d’API AKS, consultez Résolution des problèmes de connexion de cluster de base avec le serveur d’API.

Conditions préalables

Facteurs à prendre en compte

Cette section décrit les étapes de dépannage à suivre si vous rencontrez des problèmes lorsque vous essayez de vous connecter à l’application hébergée sur un cluster AKS.

Dans tout scénario de mise en réseau, les administrateurs doivent prendre en compte les facteurs importants suivants lors de la résolution des problèmes :

  • Quelles sont la source et la destination d’une requête ?

  • Quels sont les tronçons entre la source et la destination ?

  • Qu’est-ce que le flux demande-réponse ?

  • Quels tronçons ont des couches de sécurité supplémentaires en haut, comme les éléments suivants :

    • Pare-feu
    • Groupe de sécurité réseau (NSG)
    • Stratégie réseau

Lorsque vous case activée chaque composant, obtenez et analysez les codes de réponse HTTP. Ces codes sont utiles pour identifier la nature du problème et sont particulièrement utiles dans les scénarios dans lesquels l’application répond aux requêtes HTTP.

Si d’autres étapes de résolution des problèmes ne fournissent aucun résultat concluant, effectuez des captures de paquets à partir du client et du serveur. Les captures de paquets sont également utiles lorsque le trafic non HTTP est impliqué entre le client et le serveur. Pour plus d’informations sur la collecte de captures de paquets pour l’environnement AKS, consultez les articles suivants dans le guide de collecte de données :

Le fait de savoir comment obtenir les codes de réponse HTTP et prendre des captures de paquets facilite la résolution d’un problème de connectivité réseau.

Flux réseau de base pour les applications sur AKS

En général, le flux de requête pour accéder aux applications hébergées sur un cluster AKS est le suivant :

Nom DNS du client >> Adresse IP >> de l’équilibreur de charge AKS Nœuds >> Pods >> AKS

Il existe d’autres situations possibles dans lesquelles des composants supplémentaires peuvent être impliqués. Par exemple :

  • La passerelle d’application est utilisée via le contrôleur d’entrée Application Gateway (AGIC) au lieu de Azure Load Balancer.
  • Azure Front Door et Gestion des API peuvent être utilisés sur l’équilibreur de charge.
  • Le processus utilise un équilibreur de charge interne.
  • La connexion peut ne pas se terminer au pod et à l’URL demandée. Cela peut dépendre du fait que le pod peut se connecter à une autre entité, telle qu’une base de données ou tout autre service dans le même cluster.

Il est important de comprendre le flux de demande pour l’application.

Un flux de requête de base vers des applications sur un cluster AKS ressemblerait au flux illustré dans le diagramme suivant.

Diagramme d’un flux de requête de base vers des applications sur un cluster Azure Kubernetes Service (AKS).

Résolution des problèmes internes

La résolution des problèmes de connectivité peut impliquer de nombreuses vérifications, mais l’approche interne peut aider à trouver la source du problème et à identifier le goulot d’étranglement. Dans cette approche, vous commencez par le pod lui-même, en vérifiant si l’application répond sur l’adresse IP du pod. Ensuite, case activée chaque composant jusqu’au client final.

Étape 1 : Vérifier si le pod est en cours d’exécution et si l’application ou le conteneur à l’intérieur du pod répond correctement

Pour déterminer si le pod est en cours d’exécution, exécutez l’une des commandes kubectl get suivantes :

# List pods in the specified namespace.
kubectl get pods -n <namespace-name>

# List pods in all namespaces.
kubectl get pods -A

Que se passe-t-il si le pod n’est pas en cours d’exécution ? Dans ce cas, case activée les événements de pod à l’aide de la commande kubectl describe :

kubectl describe pod <pod-name> -n <namespace-name>

Si le pod n’est pas dans un Ready état ou Running ou s’il a redémarré plusieurs fois, case activée la kubectl describe sortie. Les événements révèlent tous les problèmes qui vous empêchent de démarrer le pod. Ou, si le pod a démarré, l’application à l’intérieur du pod peut avoir échoué, entraînant le redémarrage du pod. Résolvez les problèmes du pod en conséquence pour vous assurer qu’il est dans un état approprié.

Si le pod est en cours d’exécution, il peut également être utile d’case activée les journaux des pods et des conteneurs qu’ils contiennent. Exécutez la série suivante de commandes kubectl logs :

kubectl logs <pod-name> -n <namespace-name>

# Check logs for an individual container in a multicontainer pod.
kubectl logs <pod-name> -n <namespace-name> -c <container-name>

# Dump pod logs (stdout) for a previous container instance.
kubectl logs <pod-name> --previous                      

# Dump pod container logs (stdout, multicontainer case) for a previous container instance.
kubectl logs <pod-name> -c <container-name> --previous

Le pod est-il en cours d’exécution ? Dans ce cas, testez la connectivité en démarrant un pod de test dans le cluster. À partir du pod de test, vous pouvez accéder directement à l’adresse IP du pod de l’application et case activée si l’application répond correctement. Exécutez les commandes kubectl run, apt-getet cURL comme suit :

# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable

# After the test pod is running, you will gain access to the pod.
# Then you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y

# After the packages are installed, test the connectivity to the application pod:
curl -Iv http://<pod-ip-address>:<port>

Pour les applications qui écoutent d’autres protocoles, vous pouvez installer les outils appropriés à l’intérieur du pod de test, puis case activée la connectivité au pod d’application.

Pour plus de commandes permettant de résoudre les problèmes de pods, consultez Déboguer des pods en cours d’exécution.

Étape 2 : Vérifier si l’application est accessible à partir du service

Pour les scénarios dans lesquels l’application à l’intérieur du pod est en cours d’exécution, vous pouvez vous concentrer principalement sur la résolution des problèmes d’exposition du pod.

Le pod est-il exposé en tant que service ? Dans ce cas, case activée les événements de service. En outre, case activée si l’adresse IP du pod et le port d’application sont disponibles en tant que point de terminaison dans la description du service :

# Check the service details.
kubectl get svc -n <namespace-name>

# Describe the service.
kubectl describe svc <service-name> -n <namespace-name>

Vérifiez si l’adresse IP du pod est présente en tant que point de terminaison dans le service, comme dans l’exemple suivant :

$ kubectl get pods -o wide  # Check the pod's IP address.
NAME            READY   STATUS        RESTARTS   AGE   IP            NODE                                
my-pod          1/1     Running       0          12m   10.244.0.15   aks-agentpool-000000-vmss000000  

$ kubectl describe service my-cluster-ip-service  # Check the endpoints in the service.
Name:              my-cluster-ip-service
Namespace:         default
Selector:          app=my-pod
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.0.174.133
IPs:               10.0.174.133
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.0.15:80     # <--- Here

$ kubectl get endpoints  # Check the endpoints directly for verification.
NAME                      ENDPOINTS           AGE
my-cluster-ip-service     10.244.0.15:80      14m

Si les points de terminaison ne pointent pas vers l’adresse IP du pod correcte, vérifiez les Labels et Selectors pour le pod et le service.

Les points de terminaison du service sont-ils corrects ? Si c’est le cas, accédez au service et case activée si l’application est accessible.

Accéder au service ClusterIP

Pour le ClusterIP service, vous pouvez démarrer un pod de test dans le cluster et accéder à l’adresse IP du service :

Diagramme de l’utilisation d’un pod de test dans un cluster Azure Kubernetes Service (AKS) pour accéder à l’adresse IP du cluster. 

# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable
  
# After the test pod is running, you will gain access to the pod.
# Then, you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y
  
# After the packages are installed, test the connectivity to the service:
curl -Iv http://<service-ip-address>:<port>

Si la commande précédente ne retourne pas de réponse appropriée, case activée les événements de service pour toutes les erreurs.

Accéder au service LoadBalancer

Pour le LoadBalancer service, vous pouvez accéder à l’adresse IP de l’équilibreur de charge à partir de l’extérieur du cluster.

Diagramme d’un utilisateur de test accédant à l’adresse IP de l’équilibreur de charge à partir de l’extérieur d’un cluster Azure Kubernetes Service (AKS). 

curl -Iv http://<service-ip-address>:<port>

L’adresse IP du LoadBalancer service renvoie-t-elle une réponse correcte ? Si ce n’est pas le cas, procédez comme suit :

  1. Vérifiez les événements du service.

  2. Vérifiez que les groupes de sécurité réseau (NSG) associés aux nœuds AKS et au sous-réseau AKS autorisent le trafic entrant sur le port de service.

Pour plus de commandes permettant de résoudre les problèmes liés aux services, consultez Déboguer les services.

Scénarios qui utilisent une entrée au lieu d’un service

Pour les scénarios dans lesquels l’application est exposée à l’aide d’une Ingress ressource, le flux de trafic ressemble à la progression suivante :

Nom >> DNS du client >> Équilibreur de charge ou d’adresse >> IP de passerelle d’application Pods d’entrée à l’intérieur du ou des pods de service de cluster >>

Diagramme du flux de trafic réseau lorsqu’une application à l’intérieur d’un cluster Azure Kubernetes Service (AKS) est exposée à l’aide d’une ressource d’entrée.

Vous pouvez également appliquer l’approche interne-out de la résolution des problèmes ici. Vous pouvez également case activée les détails du contrôleur d’entrée et d’entrée pour plus d’informations :

$ kubectl get ing -n <namespace-of-ingress>  # Checking the ingress details and events.
NAME                         CLASS    HOSTS                ADDRESS       PORTS     AGE
hello-world-ingress          <none>   myapp.com            20.84.x.x     80, 443   7d22h

$ kubectl describe ing -n <namespace-of-ingress> hello-world-ingress
Name:             hello-world-ingress
Namespace:        <namespace-of-ingress>
Address:          20.84.x.x
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  tls-secret terminates myapp.com
Rules:
  Host                Path  Backends
  ----                ----  --------
  myapp.com
                      /blog   blog-service:80 (10.244.0.35:80)
                      /store  store-service:80 (10.244.0.33:80)

Annotations:          cert-manager.io/cluster-issuer: letsencrypt
                      kubernetes.io/ingress.class: nginx
                      nginx.ingress.kubernetes.io/rewrite-target: /$1
                      nginx.ingress.kubernetes.io/use-regex: true
Events:
  Type    Reason  Age    From                      Message
  ----    ------  ----   ----                      -------
  Normal  Sync    5m41s  nginx-ingress-controller  Scheduled for sync
  Normal  Sync    5m41s  nginx-ingress-controller  Scheduled for sync

Cet exemple contient une Ingress ressource qui :

  • Écoute sur l’hôte myapp.com .
  • Path Deux chaînes sont configurées.
  • Itinéraires vers deux Services dans le back-end.

Vérifiez que les services principaux sont en cours d’exécution et répondez au port mentionné dans la description de l’entrée :

$ kubectl get svc -n <namespace-of-ingress>
NAMESPACE       NAME                                     TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      
ingress-basic   blog-service                             ClusterIP      10.0.155.154   <none>        80/TCP                       
ingress-basic   store-service                            ClusterIP      10.0.61.185    <none>        80/TCP             
ingress-basic   nginx-ingress-ingress-nginx-controller   LoadBalancer   10.0.122.148   20.84.x.x     80:30217/TCP,443:32464/TCP

Vérifiez les journaux des pods du contrôleur d’entrée en cas d’erreur :

$ kubectl get pods -n <namespace-of-ingress>  # Get the ingress controller pods.
NAME                                                     READY   STATUS    RESTARTS   AGE
aks-helloworld-one-56c7b8d79d-6zktl                      1/1     Running   0          31h
aks-helloworld-two-58bbb47f58-rrcv7                      1/1     Running   0          31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q   1/1     Running   0          31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-grzdr   1/1     Running   0          31h

$ # Check logs from the pods.
$ kubectl logs -n ingress-basic nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q

Que se passe-t-il si le client effectue des demandes à l’adresse IP ou au nom d’hôte d’entrée, mais qu’aucune entrée n’est visible dans les journaux du pod du contrôleur d’entrée ? Dans ce cas, les requêtes peuvent ne pas atteindre le cluster et l’utilisateur reçoit peut-être un Connection Timed Out message d’erreur.

Une autre possibilité est que les composants sur les pods d’entrée, tels que Load Balancer ou Application Gateway, n’acheminent pas correctement les requêtes vers le cluster. Si c’est le cas, vous pouvez case activée la configuration principale de ces ressources.

Si vous recevez un Connection Timed Out message d’erreur, case activée le groupe de sécurité réseau associé aux nœuds AKS. En outre, case activée le sous-réseau AKS. Il peut bloquer le trafic de l’équilibreur de charge ou de la passerelle d’application vers les nœuds AKS.

Pour plus d’informations sur la résolution des problèmes d’entrée (par exemple, l’entrée Nginx), consultez résolution des problèmes d’entrée-nginx.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.

Exclusion de responsabilité sur les coordonnées externes

Microsoft fournit des informations de contacts externes afin de vous aider à obtenir un support technique sur ce sujet. Ces informations de contact peuvent être modifiées sans préavis. Microsoft ne garantit pas l’exactitude des informations concernant les sociétés externes.