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

Dans les environnements cloud dynamiques actuels, la connectivité transparente aux applications hébergées dans des clusters Azure Kubernetes Service (AKS) est essentielle pour maintenir des performances et une expérience utilisateur optimales. Cet article explique comment résoudre et résoudre les problèmes de connectivité causés par différents facteurs, notamment les problèmes côté application, les stratégies réseau, les règles de groupe de sécurité réseau (NSG) ou d’autres.

Note

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

Prerequisites

• Outil d’URL client (cURL) ou d’un outil en ligne de commande similaire.

• Outil en ligne de commande apt-get pour la gestion des packages.

• Outil en ligne de commande Netcat (nc) pour les connexions TCP.

• L’outil Kubernetes kubectl ou un outil similaire pour se connecter au cluster. Pour installer kubectl à l’aide d’Azure CLI, exécutez la commande az aks install-cli .

Facteurs à prendre en compte

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

Dans n’importe quel 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 :

• Quelle est la source et la destination d’une demande ?

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

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

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

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

Lorsque vous vérifiez 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, prenez 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 des captures de paquets pour l’environnement AKS, consultez les articles suivants dans le guide de collecte de données :

• Capturez un vidage TCP à partir d’un nœud Linux dans un cluster AKS.

• Capturez un vidage TCP à partir d’un nœud Windows dans un cluster AKS.

• Capturez des paquets TCP à partir d’un pod sur un cluster AKS.

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, lorsque les applications sont exposées à l’aide du type de service Azure Load Balancer, le flux de demande pour y accéder est le suivant :

Pods de nœuds >> AKS du nom DNS du client >> >> AKS load balancer >>

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

• L’entrée NGINX gérée avec la fonctionnalité de module complémentaire de routage d’application est activée.
• La passerelle d’application est utilisée via le contrôleur d’entrée Application Gateway (AGIC) au lieu d’Azure Load Balancer.
• Azure Front Door et Gestion des API peuvent être utilisés au-dessus de l’équilibreur de charge.
• Le processus utilise un équilibreur de charge interne.
• La connexion peut ne pas se terminer au niveau du pod et de 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 du même cluster.

Il est important de comprendre le flux de requête de l’application.

Un flux de requête de base pour les applications d’un cluster AKS ressemble au flux présenté dans le diagramme suivant.

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 vous 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, vérifiez 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 get kubectl 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, vérifiez 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 qu’il a redémarré plusieurs fois, vérifiez 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 a peut-être échoué, ce qui entraîne 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 de vérifier les journaux des conteneurs qui se trouvent à l’intérieur du pod. Exécutez la série suivante de commandes de journaux kubectl :

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 vérifier si l’application répond correctement. Exécutez l’exécution kubectl, apt-getet cURL les commandes 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 && apt-get install netcat-traditional -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 des outils pertinents dans le pod de test comme l’outil netcat, puis vérifier la connectivité au pod d’application en exécutant la commande suivante :

# After the packages are installed, test the connectivity to the application pod using netcat/nc command:
nc -z -v <pod-ip-address> <port>

Pour plus de commandes pour résoudre les problèmes de pods, consultez Déboguer les 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 façon dont le pod est exposé.

Le pod est-il exposé en tant que service ? Dans ce cas, vérifiez les événements de service. Vérifiez également 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 de pod correcte, vérifiez le Labels pod et Selectors le service.

Les points de terminaison du service sont-ils corrects ? Si c’est le cas, accédez au service et vérifiez 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 :

# 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 && apt-get install netcat-traditional -y
  
# After the packages are installed, test the connectivity to the service:
curl -Iv http://<service-ip-address>:<port>

Pour les applications qui écoutent d’autres protocoles, vous pouvez installer des outils pertinents dans le pod de test comme l’outil netcat, puis vérifier la connectivité au pod d’application en exécutant la commande suivante :

# After the packages are installed, test the connectivity to the application pod using netcat/nc command:
nc -z -v <pod-ip-address> <port>

Si la commande précédente ne retourne pas de réponse appropriée, vérifiez les événements de service pour connaître 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.

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

Pour les applications qui écoutent d’autres protocoles, vous pouvez installer des outils pertinents dans le pod de test comme l’outil netcat, puis vérifier la connectivité au pod d’application en exécutant la commande suivante :

nc -z -v <pod-ip-address> <port>

L’adresse IP du LoadBalancer service retourne-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 pour résoudre les problèmes de services, consultez Services de débogage.

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 :

>> Équilibreur de charge dns client >> ou pods >> du contrôleur d’entrée de passerelle d’application dans le service de cluster >> ou les pods

Vous pouvez également appliquer l’approche de résolution des problèmes à l’intérieur. Vous pouvez également consulter les détails de la ressource Kubernetes d’entrée et du contrôleur 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 .
• A deux Path chaînes configurées.
• Itinéraires vers deux Services dans le back-end.

Vérifiez que les services principaux s’exécutent et répondent au port mentionné dans la description d’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 au nom d’hôte ou à l’adresse IP d’entrée, mais 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 peut recevoir un message d’erreur Connection Timed Out .

Une autre possibilité est que les composants situés au-dessus des pods d’entrée, tels que Load Balancer ou Application Gateway, ne routent pas correctement les requêtes vers le cluster. Si c’est le cas, vous pouvez vérifier la configuration principale de ces ressources.

Si vous recevez un Connection Timed Out message d’erreur, vérifiez le groupe de sécurité réseau associé aux nœuds AKS. Vérifiez également 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, Nginx Ingress), 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 changer sans préavis. Microsoft ne garantit pas l’exactitude des informations concernant les sociétés externes.