Pods einrichten

1. Erstellen Sie einen neuen privilegierten Namensbereich für Ihre Test-Pods. Durch das Erstellen eines neuen Namensbereichs wird verhindert, dass sich angepasste Richtlinien oder Konfigurationen in vorhandenen Namensbereichen auf Ihre Testpods auswirken. In diesem Beispiel heißt der neue Namensbereich pod-network-test.

   Erstellen Sie den Namensbereich.

   oc create ns pod-network-test
   

2. Fügen Sie dem neuen privilegierten Namensraum Bezeichnungen hinzu.

   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. Führen Sie den Befehl aus, damit der Namensbereich Pods mit einem privilegierten Sicherheitskontext ausführen kann.

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

4. Erstellen Sie das folgende Daemonset und wenden Sie es an, um einen Test-Pod auf jedem Knoten zu erstellen.

   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. Wenden Sie das Daemonset an, um einen Test-Pod auf jedem Arbeitsknoten zu installieren.

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

6. Überprüfen Sie, ob die Pods erfolgreich gestartet wurden, indem Sie alle Pods im Namespace auflisten.

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

Tests in den Pods ausführen

Führen Sie die Befehle curl, ping und nc aus, um die Netzverbindung jedes Pods und den Befehl dig zum Testen des Cluster-DNS zu testen. Überprüfen Sie jede Ausgabe. Lesen Sie dann Probleme identifizieren, um herauszufinden, was die Ergebnisse bedeuten könnten.

1. Listen Sie Ihre Testpods auf und notieren Sie den Namen und die IP-Adresse jedes Pods.

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

   Beispielausgabe

   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. Führen Sie den Befehl exec aus, um sich bei einem Pod anzumelden.

   kubectl exec -it --namespace pod-network-test <pod_name> -- sh
   

3. Führen Sie den Befehl curl für den Pod aus und notieren Sie die Ausgabe. Geben Sie die IP eines Testpods an, bei dem Sie sich nicht angemeldet haben. Dadurch wird die Netzverbindung zwischen Pods auf verschiedenen Knoten getestet.

   curl <pod_ip>:8080
   

   Beispiel für eine erfolgreiche Ausgabe

   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. Führen Sie den Befehl ping für den Pod aus und notieren Sie die Ausgabe. Geben Sie die IP eines Testpods an, bei dem Sie sich nicht mit dem Befehl exec angemeldet haben. Dadurch wird die Netzverbindung zwischen Pods auf verschiedenen Knoten getestet.

   ping -c 5 <pod_ip>
   

   Beispiel für eine erfolgreiche Ausgabe

   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. Führen Sie den Befehl nc für den Pod aus und notieren Sie die Ausgabe. Geben Sie die IP eines Testpods an, bei dem Sie sich nicht mit dem Befehl exec angemeldet haben. Dadurch wird die Netzverbindung zwischen Pods auf verschiedenen Knoten getestet.

   nc -vzw 5 <pod_ip> 8080
   

   Beispiel für eine erfolgreiche Ausgabe

   nc -vzw 5 172.17.61.240 8080
   172.17.61.240 (172.17.61.240:8080) open
   

6. Führen Sie die dig-Befehle zum Testen des DNS aus.

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

   Beispielausgabe

   172.21.0.1
   

   dig +short ibm.com
   

   Beispielausgabe

   23.50.74.64
   

7. Führen Sie curl Befehle aus, um eine vollständige TCP oder HTTPS Verbindung zum Dienst zu testen. In diesem Beispiel wird die Verbindung zwischen dem Pod und dem Cluster-Master getestet, indem die Versionsinformationen des Clusters abgerufen werden. Der erfolgreiche Abruf der Clusterversion weist auf eine einwandfreie Verbindung hin.

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

   Beispielausgabe

   "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. Melden Sie sich vom Pod ab.

   exit
   

9. Wiederholen Sie die vorherigen Schritte mit den verbleibenden Pods.

Probleme erkennen

Überprüfen Sie die Ausgaben aus dem vorherigen Abschnitt, um die Ursache für Ihre Probleme beim Pod-Netzbetrieb zu finden. In diesem Abschnitt werden einige allgemeine Ursachen aufgelistet, die im vorherigen Abschnitt angegeben werden können.

• Wenn die Befehle auf den Testpods normal funktionierten, Sie aber immer noch Netzwerkprobleme mit den Anwendungspods in Ihrem Standard-Namensraum haben, könnte es Probleme geben, die speziell mit Ihrer Anwendung zusammenhängen.

  • Möglicherweise sind Netzsicherheitsrichtlinien für Calico oder Kubernetes vorhanden, die Ihren Netzdatenverkehr einschränken. Wenn eine Netzrichtlinie auf einen Pod angewendet wird, wird der gesamte Datenverkehr, der von dieser Richtlinie nicht explizit zugelassen wird, gelöscht. Weitere Informationen zu Netzrichtlinien finden Sie in der Dokumentation zuKubernetes.
  • Wenn Sie Istio oder Red Hat OpenShift Service Mesh verwenden, kann es zu Problemen bei der Dienstkonfiguration kommen, die den Datenverkehr zwischen Pods unterbrechen oder blockieren. Weitere Informationen finden Sie in der Dokumentation zur Fehlerbehebung für Istio und Red Hat OpenShift Service Mesh.
  • Das Problem kann mit Programmfehlern in der Anwendung und nicht mit Ihrem Cluster zusammenhängen und erfordert möglicherweise eine eigene unabhängige Fehlerbehebung.

• Wenn die Befehle curl, ping oder nc für bestimmte Pods fehlgeschlagen sind, ermitteln Sie, auf welchen Workerknoten sich diese Pods befinden. Wenn das Problem nur auf einigen Ihrer Workerknoten auftritt, ersetzen Sie diese Workerknoten oder lesen Sie zusätzliche Informationen zur Fehlerbehebung für Workerknoten.

• Wenn die DNS-Suche über die dig-Befehle fehlgeschlagen ist, lesen Sie die Red Hat DNS-Fehlerbehebungsinformationen.

Wenn Sie Ihr Problem mit dem Pod-Netzbetrieb weiterhin nicht lösen können, öffnen Sie einen Supportfall und fügen Sie eine detaillierte Beschreibung des Problems, wie Sie versucht haben, es zu lösen, welche Arten von Tests Sie ausgeführt haben und relevante Protokolle für Ihre Pods und Workerknoten hinzu. Weitere Informationen zum Öffnen eines Supportfalls und zu den einzuschließenden Informationen finden Sie im allgemeinen Debugging-Handbuch.