ポッドのセットアップ

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

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

   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
         ```
   
   

2. デーモン・セットを適用して、ワーカー・ノードにテスト・ポッドをデプロイします。

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

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

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

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

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

   curl <pod_ip>:8080
   

   成功した出力の例。

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

   ping -c 5 <pod_ip>
   

   成功した出力の例。

   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. ポッドで 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": "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. ポッドからログアウトする。

   exit
   

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

問題の特定

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

• テスト・ポッドでコマンドが正常に機能したにもかかわらず、デフォルトの名前空間内のアプリケーション・ポッドにまだネットワーキングの問題がある場合は、特にアプリケーションに関連する問題が存在する可能性があります。

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

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

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

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