IBM Cloud Docs
Débogage des connexions réseau entre les pods

Débogage des connexions réseau entre les pods

Passez en revue les options et les stratégies de débogage des problèmes de connexion entre les pods.

Vérifiez l'état de santé des composants de votre cluster et des pods de mise en réseau

Procédez comme suit pour vérifier la santé de vos composants. Des problèmes de mise en réseau peuvent se produire si les composants de votre cluster ne sont pas à jour ou ne sont pas dans un état sain.

  1. Vérifiez que le maître cluster et les noeuds worker s'exécutent sur une version prise en charge et sont dans un état sain. Si le maître cluster ou les noeuds worker n'exécutent pas une version prise en charge, effectuez les mises à jour nécessaires pour qu'ils exécutent une version prise en charge. Si l'état d'un composant n'est pas Normal ou Ready, examinez les états de santé du maître du cluster, états du cluster, états des nœuds ouvriers, ou étapes de dépannage des Critical ou NotReady nœuds ouvriers pour plus d'informations. Assurez-vous que tous les problèmes associés sont résolus avant de continuer.

    Pour vérifier la version et l'état de santé du maître cluster:

    ibmcloud ks cluster get -c <cluster-id>
    

    Pour vérifier les versions et la santé des noeuds worker:

    ibmcloud ks workers -c <cluster-id>
    
  2. Pour chaque noeud worker, vérifiez que les pods Calico et DNS de cluster sont présents et s'exécutent dans un état sain.

    1. Exécutez la commande pour obtenir les détails des pods de votre cluster.

       kubectl get pods -A -o wide | grep -e calico -e coredns
      
    2. Dans la sortie, assurez-vous que votre cluster inclut les pods suivants. Assurez-vous que le statut de chaque pod est Running et que les pods ne comportent pas trop de redémarrages.

      • Exactement un pod calico-node par noeud worker.
      • Au moins un pod calico-typha par cluster. Les clusters de plus grande taille peuvent en comporter plusieurs.
      • Exactement un pod calico-kube-controllers par cluster.
      • Au moins un pod coredns par cluster. La plupart des grappes ont trois coredns gousses ; les grappes plus importantes peuvent en avoir plus.
      • Exactement une coredns-autoscaler cosse.

      Exemple de sortie

      NAMESPACE        NAME                               READY   STATUS     RESTARTS    AGE    IP              NODE           NOMINATED     READINESS GATES
      calico-system     calico-kube-controllers-1a1a1a1   1/1     Running   0             16h   172.17.87.11    192.168.0.28   <none>         <none>
      calico-system     calico-node-1a1a1a1               1/1     Running   0             16h   192.168.0.28   192.168.0.28    <none>         <none>
      calico-system     calico-node-1a1a1a1               1/1     Running   0             16h   192.168.0.27   192.168.0.27    <none>         <none>
      calico-system     calico-typha-1a1a1a1              1/1     Running   0             16h   192.168.0.28   192.168.0.28    <none>         <none>
      kube-system       coredns-867bfb84df-1a1a1a1        1/1     Running   0             16h   172.17.87.1    192.168.0.28    <none>         <none>
      kube-system       coredns-867bfb84df-1a1a1a1        1/1     Running   0             16h   172.17.87.15   192.168.0.28    <none>         <none>
      kube-system       coredns-867bfb84df-1a1a1a1        1/1     Running   0             16h   172.17.87.14   192.168.0.28    <none>         <none>
      kube-system       coredns-autoscaler-1a1a1a1        1/1     Running   0             16h   172.17.87.2    192.168.0.28    <none>         <none>
      
    3. Si l'un des pods répertoriés n'est pas présent ou est dans un état défaillant, consultez la documentation relative au traitement des incidents de noeud worker et de cluster incluse dans les étapes précédentes. Assurez-vous que tous les problèmes liés aux pods dans cette étape sont résolus avant de passer à l'étape suivante.

Débogage avec des pods de test

Pour déterminer la cause des problèmes de mise en réseau sur vos pods, vous pouvez créer un pod de test sur chacun de vos noeuds worker. Ensuite, vous pouvez exécuter des tests et observer l'activité réseau dans le pod, ce qui peut révéler la source du problème.

Configuration des pods

  1. Créez un espace de nom privilégié pour vos pods de test. La création d'un nouvel espace de nom empêche toute politique ou configuration personnalisée dans des espaces de nom existants d'affecter vos pods de test. Dans cet exemple, le nouvel espace de nom est appelé pod-network-test.

    Créez l'espace de nom.

    kubectl create ns pod-network-test
    
  2. Créez et appliquez le daemonset suivant pour créer un pod de test sur chaque nœud.

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      labels:
        name: webserver-test
        app: webserver-test
      name: webserver-test
    spec:
      selector:
        matchLabels:
          name: webserver-test
      template:
        metadata:
          labels:
            name: webserver-test
            app: webserver-test
        spec:
          tolerations:
          - operator: "Exists"
          containers:
          - name: webserver
            securityContext:
              privileged: true
            image: us.icr.io/armada-master/network-alpine:latest
            env:
              - name: ENABLE_ECHO_SERVER
                value: "true"
              - name: POD_NAME
                valueFrom:
                  fieldRef:
                    fieldPath: metadata.name
          restartPolicy: Always
          terminationGracePeriodSeconds: 1
          ```
    
    
  3. Appliquez le daemonset pour déployer des pods de test sur vos noeuds worker.

kubectl apply --namespace pod-network-test -f <daemonset-file>
  1. Vérifier que les pods démarrent correctement en listant tous les pods de l'espace de noms.
    kubectl get pods --namespace pod-network-test -o wide
    

Exécution de tests dans les pods

Exécutez les commandes curl, ping et nc pour tester la connexion réseau de chaque pod et la commande dig pour tester le DNS de cluster. Passez en revue chaque sortie, puis consultez la rubrique Identification des problèmes pour trouver ce que les résultats peuvent signifier.

  1. Répertoriez vos pods de test et notez le nom et l'adresse IP de chaque pod.

    kubectl get pods --namespace pod-network-test -o wide
    

    Exemple de sortie

    NAME                   READY   STATUS    RESTARTS   AGE   IP               NODE        NOMINATED NODE   READINESS GATES
    webserver-test-1a1a1   1/1     Running   0          68s   172.17.36.169   10.245.0.4   <none>           <none>
    webserver-test-1a1a1   1/1     Running   0          68s   172.17.61.240   10.245.0.5   <none>           <none>
    
  2. Exécutez la commande exec pour vous connecter à un pod.

    kubectl exec -it --namespace pod-network-test <pod_name> -- sh
    
  3. Exécutez la commande curl sur le pod et notez la sortie. Indiquez l'adresse IP du pod auquel vous ne vous êtes pas connecté. Cette opération teste la connexion réseau entre les pods sur différents noeuds.

    curl <pod_ip>:8080
    

    Exemple de sortie réussie.

    Hostname: webserver-test-t546j
    
    Pod Information:
      node name:	env var NODE_NAME not set
      pod name:	webserver-test-t546j
      pod namespace:	env var POD_NAMESPACE not set
      pod IP:  	env var POD_IP not set
    
    Connection Information:
      remote address:	172.17.36.169
      remote port:	56042
      local address:	172.17.61.240
      local port:	8080
    
  4. Exécutez la commande ping sur le pod et notez la sortie. Spécifiez l'IP du pod auquel vous ne vous êtes pas connecté avec la commande exec. Cette opération teste la connexion réseau entre les pods sur différents noeuds.

    ping -c 5 <pod_ip>
    

    Exemple de sortie réussie.

    PING 172.30.248.201 (172.30.248.201) 56(84) bytes of data.
    64 bytes from 172.30.248.201: icmp_seq=1 ttl=62 time=0.473 ms
    64 bytes from 172.30.248.201: icmp_seq=2 ttl=62 time=0.449 ms
    64 bytes from 172.30.248.201: icmp_seq=3 ttl=62 time=0.381 ms
    64 bytes from 172.30.248.201: icmp_seq=4 ttl=62 time=0.438 ms
    64 bytes from 172.30.248.201: icmp_seq=5 ttl=62 time=0.348 ms
    
    --- 172.30.248.201 ping statistics ---
    5 packets transmitted, 5 received, 0% packet loss, time 4086ms
    rtt min/avg/max/mdev = 0.348/0.417/0.473/0.046 ms
    
  5. Exécutez la commande nc sur le pod et notez la sortie. Spécifiez l'IP du pod auquel vous ne vous êtes pas connecté avec la commande exec. Cette opération teste la connexion réseau entre les pods sur différents noeuds.

    nc -vzw 5 <pod_ip> 8080
    

    Exemple de sortie réussie.

    nc -vzw 5 172.17.61.240 8080
    172.17.61.240 (172.17.61.240:8080) open
    
  6. Exécutez les commandes dig pour tester le DNS.

    dig +short kubernetes.default.svc.cluster.local
    

    Exemple de sortie

    172.21.0.1
    
    dig +short ibm.com
    

    Exemple de sortie

    23.50.74.64
    
  7. Exécutez les commandes curl pour tester une connexion TCP ou HTTPS complète au service. Cet exemple teste la connexion entre le pod et le maître cluster en extrayant les informations de version du cluster. L'extraction de la version du cluster indique une connexion saine.

    curl -k https://kubernetes.default.svc.cluster.local/version
    

    Exemple de sortie

    {
    "major": "1",
    "minor": "25",
    "gitVersion": "v1.25.14+bcb9a60",
    "gitCommit": "3bdfba0be09da2bfdef3b63e421e6a023bbb08e6",
    "gitTreeState": "clean",
    "buildDate": "2023-10-30T21:33:07Z",
    "goVersion": "go1.19.13 X:strictfipsruntime",
    "compiler": "gc",
    "platform": "linux/amd64"
    }
    
  8. Se déconnecter du pod.

    exit
    
  9. Répétez les étapes précédentes avec les pods restants.

Identification des problèmes

Passez en revue les sorties de la section précédente pour trouver la cause des problèmes de mise en réseau de votre pod. Cette section répertorie certaines causes courantes qui peuvent être identifiées à partir de la section précédente.

  • Si les commandes fonctionnaient normalement sur les pods de test, mais que vous rencontrez toujours des problèmes de mise en réseau dans vos pods d'application dans votre espace de nom par défaut, il peut y avoir des problèmes liés spécifiquement à votre application.

    • Vous pouvez avoir des règles de sécurité réseau Calico ou Kubernetes en place qui limitent votre trafic réseau. Si une règle de mise en réseau est appliquée à un pod, tout le trafic qui n'est pas spécifiquement autorisé par cette règle est supprimé. Pour plus d'informations sur les règles de mise en réseau, voir la documentationKubernetes.
    • Si vous utilisez Istio ou Red Hat OpenShift Service Mesh, il peut y avoir des problèmes de configuration de service qui suppriment ou bloquent le trafic entre les pods. Pour plus d'informations, voir la documentation de traitement des incidents pour Istio et Red Hat OpenShift Service Mesh.
    • Le problème peut être lié à des bogues dans l'application plutôt qu'à votre cluster, et peut nécessiter votre propre traitement indépendant des incidents.
  • Si les commandes curl, ping ou nc ont échoué pour certains pods, identifiez les noeuds worker sur lesquels se trouvent ces pods. Si le problème n'existe que sur certains de vos noeuds worker, remplacez ces noeuds worker ou consultez des informations supplémentaires sur le traitement des incidents de noeud worker.

  • Si les recherches DNS à partir des commandes dig ont échoué, vérifiez que le serveur DNS de cluster est configuré correctement.

Si vous ne parvenez toujours pas à résoudre votre problème de réseau de pod, ouvrez un cas de support et incluez une description détaillée du problème, la manière dont vous avez tenté de le résoudre, les types de tests que vous avez exécutés et les journaux pertinents pour vos pods et noeuds worker. Pour plus d'informations sur l'ouverture d'un cas de support et sur les informations à inclure, voir le guide de débogage général.