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.
-
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
ouReady
, examinez les états de santé du maître du cluster, états du cluster, états des nœuds ouvriers, ou étapes de dépannage desCritical
ouNotReady
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>
-
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.
-
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
-
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 troiscoredns
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>
- Exactement un pod
-
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
-
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
-
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 ```
-
Appliquez le daemonset pour déployer des pods de test sur vos noeuds worker.
kubectl apply --namespace pod-network-test -f <daemonset-file>
- 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.
-
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>
-
Exécutez la commande
exec
pour vous connecter à un pod.kubectl exec -it --namespace pod-network-test <pod_name> -- sh
-
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
-
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 commandeexec
. 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
-
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 commandeexec
. 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
-
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
-
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" }
-
Se déconnecter du pod.
exit
-
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
ounc
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.