ポッドのセットアップ

1. テスト・ポッド用の新しい特権名前空間を作成します。 新しい名前空間を作成すると、既存の名前空間内のすべてのカスタム・ポリシーまたは構成がテスト・ポッドに影響を与えなくなります。 この例では、新しい名前空間は pod-network-test という名前です。

   名前空間を作成します。

   oc create ns pod-network-test
   

2. 新しい特権ネームスペースにラベルを追加する。

   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. 特権セキュリティー・コンテキストを使用して名前空間でポッドを実行できるようにするには、このコマンドを実行します。

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

4. 以下のデーモンセットを作成して適用し、各ノードにテストポッドを作成する。

   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. デーモンセットを適用して、各ワーカーノードにテストポッドをデプロイする。

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

6. ネームスペース内のすべてのポッドを一覧表示して、ポッドが正常に起動することを確認します。

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

ポッド内でのテストの実行

curl、 ping、および nc コマンドを実行して各ポッドのネットワーク接続をテストし、 dig コマンドを実行してクラスター DNS をテストします。 各出力を確認してから、 問題の特定 を参照して、結果の意味を確認してください。

1. テスト・ポッドをリストし、各ポッドの名前と IP をメモします。

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

   出力例

   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. exec コマンドを実行して、1つのポッドにログインします。

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

3. ポッドで curl コマンドを実行し、出力をメモします。 ログインしていないテストポッドのIPを指定する。 これにより、異なるノード上のポッド間のネットワーク接続がテストされます。

   curl <pod_ip>:8080
   

   成功した出力の例。

   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. ポッドで ping コマンドを実行し、出力をメモします。 exec コマンドでログインしていないテストポッドの IP を指定します。 これにより、異なるノード上のポッド間のネットワーク接続がテストされます。

   ping -c 5 <pod_ip>
   

   成功した出力の例。

   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. ポッドで nc コマンドを実行し、出力をメモします。 exec コマンドでログインしていないテストポッドの IP を指定します。 これにより、異なるノード上のポッド間のネットワーク接続がテストされます。

   nc -vzw 5 <pod_ip> 8080
   

   成功した出力の例。

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

6. dig コマンドを実行して DNS をテストします。

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

   出力例

   172.21.0.1
   

   dig +short ibm.com
   

   出力例

   23.50.74.64
   

7. curl コマンドを実行し、 TCP または HTTPS のサービスへのフル接続をテストする。 この例では、クラスターのバージョン情報を取得して、ポッドとクラスター・マスターの間の接続をテストします。 クラスター・バージョンを正常に取得した場合は、接続が正常であることを示しています。

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

   出力例

   "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. ポッドからログアウトしてください。

   exit
   

9. 残りのポッドを使用して、上記のステップを繰り返します。

問題の特定

前のセクションの出力を確認して、ポッド・ネットワーキングの問題の原因を見つけることができます。 このセクションでは、前のセクションで特定できる一般的な原因をいくつかリストします。

• コマンドはテストポッドで正常に機能したが、デフォルトのネームスペースにあるアプリケーションポッドでネットワークの問題が残っている場合は、アプリケーション固有の問題がある可能性があります。

  • ネットワーキング・トラフィックを制限する Calico または Kubernetes ネットワーク・セキュリティー・ポリシーが設定されている場合があります。 ネットワーキング・ポリシーがポッドに適用されている場合、 そのポリシーによって特に許可されていないすべてのトラフィックがドロップされます。 ネットワーキング・ポリシーについて詳しくは、 Kubernetes の資料を参照してください。
  • Istio または Red Hat OpenShift Service Mesh を使用している場合、ポッド間のトラフィックをドロップまたはブロックするサービス構成の問題が発生する可能性があります。 のトラブルシューティング・ドキュメントを参照してください。 Istio および Red Hat OpenShift Service Meshを参照してください。
  • この問題は、クラスターではなくアプリケーションのバグに関連している可能性があり、独自のトラブルシューティングが必要になる場合があります。

• 特定のポッドで curl、 ping、または nc コマンドが失敗した場合は、それらのポッドがどのワーカー・ノード上にあるかを確認します。 一部のワーカー・ノードでのみ問題が発生する場合は、 それらのワーカー・ノードを置き換える か、 ワーカー・ノードのトラブルシューティング に関する追加情報を参照してください。

• dig コマンドからの DNS ルックアップが失敗した場合は、 Red Hat DNS トラブルシューティング情報を参照してください。

それでもポッド・ネットワーキングの問題を解決できない場合は、 サポート Case を開き 、問題の詳細な説明、問題を解決しようとした方法、実行したテストの種類、ポッドとワーカー・ノードの 関連ログ を含めてください。 サポート Case のオープンおよび組み込む情報について詳しくは、 一般デバッグ・ガイド を参照してください。