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.

   oc create ns pod-network-test
   

2. Ajouter des étiquettes au nouvel espace de noms privilégié.

   oc label namespace pod-network-test --overwrite=true \
               pod-security.kubernetes.io/enforce=privileged \
               pod-security.kubernetes.io/enforce-version=latest \
               pod-security.kubernetes.io/audit=privileged \
               pod-security.kubernetes.io/audit-version=latest \
               pod-security.kubernetes.io/warn=privileged \
               pod-security.kubernetes.io/warn-version=latest \
               security.openshift.io/scc.podSecurityLabelSync="false"
   

3. Exécutez la commande pour permettre à l'espace de nom d'exécuter des pods avec un contexte de sécurité privilégié.

   oc adm policy add-scc-to-group privileged system:serviceaccounts:pod-network-test
   

4. 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
   

5. Appliquer le daemonset pour déployer un pod de test sur chaque nœud de travailleur.

   oc apply --namespace pod-network-test -f <daemonset-file>
   

6. Vérifier que les pods démarrent correctement en listant tous les pods de l'espace de noms.

   oc 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.

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

   Exemple de sortie

   NAME                   READY   STATUS    RESTARTS   AGE   IP               NODE        NOMINATED NODE   READINESS GATES
   webserver-test-2fv7c   1/1     Running   0          68s   172.17.36.169    10.245.0.4  <none>           <none>
   webserver-test-4mktb   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'IP d'un pod de test 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-4mktb
   Pod Information:
     node name:	env var NODE_NAME not set
     pod name:	webserver-test-4mktb
     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 d'un pod de test 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.17.61.240 (172.17.61.240) 56(84) bytes of data.
   64 bytes from 172.17.61.240: icmp_seq=1 ttl=62 time=0.473 ms
   64 bytes from 172.17.61.240: icmp_seq=2 ttl=62 time=0.449 ms
   64 bytes from 172.17.61.240: icmp_seq=3 ttl=62 time=0.381 ms
   64 bytes from 172.17.61.240: icmp_seq=4 ttl=62 time=0.438 ms
   64 bytes from 172.17.61.240: icmp_seq=5 ttl=62 time=0.348 ms
   --- 172.17.61.240 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 d'un pod de test 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 complète TCP ou HTTPS 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": "34",
   "emulationMajor": "1",
   "emulationMinor": "34",
   "minCompatibilityMajor": "1",
   "minCompatibilityMinor": "33",
   "gitVersion": "v1.34.7+IKS",
   "gitCommit": "67bf12be5abc8e65743a243172693ad1a098a2c4",
   "gitTreeState": "clean",
   "buildDate": "2026-04-16T04:24:50Z",
   "goVersion": "go1.25.9",
   "compiler": "gc",
   "platform": "linux/amd64"
   

8. Déconnectez-vous 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 ont fonctionné normalement sur les pods de test, mais que vous avez toujours des problèmes de réseau avec les pods d'application dans votre espace de noms par défaut, il se peut qu'il y ait 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 interrompent ou bloquent le trafic entre les pods. Pour plus d'informations, consultez la documentation de dépannage de 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é, voir Red Hat DNS troubleshooting information.

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.