OVN-Kubernetes ネットワークプラグイン

手順

1. 次のコマンドを実行して、OVN-Kubernetes プロジェクト内のすべてのリソース、エンドポイント、および ConfigMaps を取得します。

   $ oc get all,ep,cm -n openshift-ovn-kubernetes

   出力例

   Warning: apps.openshift.io/v1 DeploymentConfig is deprecated in v4.14+, unavailable in v4.10000+
   NAME                                         READY   STATUS    RESTARTS       AGE
   pod/ovnkube-control-plane-65c6f55656-6d55h   2/2     Running   0              114m
   pod/ovnkube-control-plane-65c6f55656-fd7vw   2/2     Running   2 (104m ago)   114m
   pod/ovnkube-node-bcvts                       8/8     Running   0              113m
   pod/ovnkube-node-drgvv                       8/8     Running   0              113m
   pod/ovnkube-node-f2pxt                       8/8     Running   0              113m
   pod/ovnkube-node-frqsb                       8/8     Running   0              105m
   pod/ovnkube-node-lbxkk                       8/8     Running   0              105m
   pod/ovnkube-node-tt7bx                       8/8     Running   1 (102m ago)   105m
   
   NAME                                   TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)             AGE
   service/ovn-kubernetes-control-plane   ClusterIP   None         <none>        9108/TCP            114m
   service/ovn-kubernetes-node            ClusterIP   None         <none>        9103/TCP,9105/TCP   114m
   
   NAME                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                 AGE
   daemonset.apps/ovnkube-node   6         6         6       6            6           beta.kubernetes.io/os=linux   114m
   
   NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/ovnkube-control-plane   3/3     3            3           114m
   
   NAME                                               DESIRED   CURRENT   READY   AGE
   replicaset.apps/ovnkube-control-plane-65c6f55656   3         3         3       114m
   
   NAME                                     ENDPOINTS                                               AGE
   endpoints/ovn-kubernetes-control-plane   10.0.0.3:9108,10.0.0.4:9108,10.0.0.5:9108               114m
   endpoints/ovn-kubernetes-node            10.0.0.3:9105,10.0.0.4:9105,10.0.0.5:9105 + 9 more...   114m
   
   NAME                                 DATA   AGE
   configmap/control-plane-status       1      113m
   configmap/kube-root-ca.crt           1      114m
   configmap/openshift-service-ca.crt   1      114m
   configmap/ovn-ca                     1      114m
   configmap/ovnkube-config             1      114m
   configmap/signer-ca                  1      114m

   クラスター内の各ノードには、1 つの ovnkube-node Pod があります。ovnkube-config config map には、OpenShift Container Platform OVN-Kubernetes 設定が含まれています。

2. 次のコマンドを実行して、ovnkube-node Pod 内のすべてのコンテナーを一覧表示します。

   $ oc get pods ovnkube-node-bcvts -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes

   予想される出力

   ovn-controller ovn-acl-logging kube-rbac-proxy-node kube-rbac-proxy-ovn-metrics northd nbdb sbdb ovnkube-controller

   ovnkube-node Pod は、複数のコンテナーで構成されています。これは、ノースバウンドデータベース (nbdb コンテナー)、サウスバウンドデータベース (sbdb コンテナー)、ノースデーモン (northd コンテナー)、ovn-controller および ovnkube-controller コンテナーをホストします。ovnkube-controller コンテナーは、Pod、Egress IP、namespace、サービス、エンドポイント、Egress ファイアウォール、ネットワークポリシーなどの API オブジェクトを監視します。また、そのノードの利用可能なサブネットプールから Pod IP への割り当ても行います。

3. 次のコマンドを実行して、ovnkube-control-plane Pod 内のすべてのコンテナーをリスト表示します。

   $ oc get pods ovnkube-control-plane-65c6f55656-6d55h -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes

   予想される出力

   kube-rbac-proxy ovnkube-cluster-manager

   ovnkube-control-plane Pod には、各 OpenShift Container Platform ノードに常駐するコンテナー (ovnkube-cluster-manager) があります。ovnkube-cluster-manager コンテナーは、Pod サブネット、トランジットスイッチサブネット IP、およびジョインスイッチサブネット IP をクラスター内の各ノードに割り当てます。kube-rbac-proxy コンテナーは ovnkube-cluster-manager コンテナーのメトリックを監視します。

1. 次のコマンドを実行して Pod をリスト表示します。

   $ oc get po -n openshift-ovn-kubernetes

   出力例

   NAME                                     READY   STATUS    RESTARTS      AGE
   ovnkube-control-plane-8444dff7f9-4lh9k   2/2     Running   0             27m
   ovnkube-control-plane-8444dff7f9-5rjh9   2/2     Running   0             27m
   ovnkube-node-55xs2                       8/8     Running   0             26m
   ovnkube-node-7r84r                       8/8     Running   0             16m
   ovnkube-node-bqq8p                       8/8     Running   0             17m
   ovnkube-node-mkj4f                       8/8     Running   0             26m
   ovnkube-node-mlr8k                       8/8     Running   0             26m
   ovnkube-node-wqn2m                       8/8     Running   0             16m

2. オプション: Pod とノード情報をリストするには、次のコマンドを実行します。

   $ oc get pods -n openshift-ovn-kubernetes -owide

   出力例

   NAME                                     READY   STATUS    RESTARTS      AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
   ovnkube-control-plane-8444dff7f9-4lh9k   2/2     Running   0             27m   10.0.0.3     ci-ln-t487nnb-72292-mdcnq-master-1         <none>           <none>
   ovnkube-control-plane-8444dff7f9-5rjh9   2/2     Running   0             27m   10.0.0.4     ci-ln-t487nnb-72292-mdcnq-master-2         <none>           <none>
   ovnkube-node-55xs2                       8/8     Running   0             26m   10.0.0.4     ci-ln-t487nnb-72292-mdcnq-master-2         <none>           <none>
   ovnkube-node-7r84r                       8/8     Running   0             17m   10.0.128.3   ci-ln-t487nnb-72292-mdcnq-worker-b-wbz7z   <none>           <none>
   ovnkube-node-bqq8p                       8/8     Running   0             17m   10.0.128.2   ci-ln-t487nnb-72292-mdcnq-worker-a-lh7ms   <none>           <none>
   ovnkube-node-mkj4f                       8/8     Running   0             27m   10.0.0.5     ci-ln-t487nnb-72292-mdcnq-master-0         <none>           <none>
   ovnkube-node-mlr8k                       8/8     Running   0             27m   10.0.0.3     ci-ln-t487nnb-72292-mdcnq-master-1         <none>           <none>
   ovnkube-node-wqn2m                       8/8     Running   0             17m   10.0.128.4   ci-ln-t487nnb-72292-mdcnq-worker-c-przlm   <none>           <none>

3. 次のコマンドを実行して、Pod に移動してノースバウンドデータベースを確認します。

   $ oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2

4. 次のコマンドを実行して、ノースバウンドデータベース内のすべてのオブジェクトを表示します。

   $ ovn-nbctl show

   出力は長すぎてここにリストできません。リストには、NAT ルール、論理スイッチ、ロードバランサーなどが含まれます。

   次の任意のコマンドのいくつかを使用すると、特定のコンポーネントに絞り込むことができます。

   1. 次のコマンドを実行して、論理ルーターのリストを表示します。

      $ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \
      -c northd -- ovn-nbctl lr-list

      出力例

      45339f4f-7d0b-41d0-b5f9-9fca9ce40ce6 (GR_ci-ln-t487nnb-72292-mdcnq-master-2)
      96a0a0f0-e7ed-4fec-8393-3195563de1b8 (ovn_cluster_router)

      注記

      この出力から、各ノードにルーターと ovn_cluster_router があることがわかります。

   2. 次のコマンドを実行して、論理スイッチのリストを表示します。

      $ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \
      -c nbdb -- ovn-nbctl ls-list

      出力例

      bdd7dc3d-d848-4a74-b293-cc15128ea614 (ci-ln-t487nnb-72292-mdcnq-master-2)
      b349292d-ee03-4914-935f-1940b6cb91e5 (ext_ci-ln-t487nnb-72292-mdcnq-master-2)
      0aac0754-ea32-4e33-b086-35eeabf0a140 (join)
      992509d7-2c3f-4432-88db-c179e43592e5 (transit_switch)

      注記

      この出力から、各ノードの ext スイッチに加えて、ノード名自体を持つスイッチと結合スイッチがあることがわかります。

   3. 次のコマンドを実行して、ロードバランサーのリストを表示します。

      $ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \
      -c nbdb -- ovn-nbctl lb-list

      出力例

      UUID                                    LB                  PROTO      VIP                     IPs
      7c84c673-ed2a-4436-9a1f-9bc5dd181eea    Service_default/    tcp        172.30.0.1:443          10.0.0.3:6443,169.254.169.2:6443,10.0.0.5:6443
      4d663fd9-ddc8-4271-b333-4c0e279e20bb    Service_default/    tcp        172.30.0.1:443          10.0.0.3:6443,10.0.0.4:6443,10.0.0.5:6443
      292eb07f-b82f-4962-868a-4f541d250bca    Service_openshif    tcp        172.30.105.247:443      10.129.0.12:8443
      034b5a7f-bb6a-45e9-8e6d-573a82dc5ee3    Service_openshif    tcp        172.30.192.38:443       10.0.0.3:10259,10.0.0.4:10259,10.0.0.5:10259
      a68bb53e-be84-48df-bd38-bdd82fcd4026    Service_openshif    tcp        172.30.161.125:8443     10.129.0.32:8443
      6cc21b3d-2c54-4c94-8ff5-d8e017269c2e    Service_openshif    tcp        172.30.3.144:443        10.129.0.22:8443
      37996ffd-7268-4862-a27f-61cd62e09c32    Service_openshif    tcp        172.30.181.107:443      10.129.0.18:8443
      81d4da3c-f811-411f-ae0c-bc6713d0861d    Service_openshif    tcp        172.30.228.23:443       10.129.0.29:8443
      ac5a4f3b-b6ba-4ceb-82d0-d84f2c41306e    Service_openshif    tcp        172.30.14.240:9443      10.129.0.36:9443
      c88979fb-1ef5-414b-90ac-43b579351ac9    Service_openshif    tcp        172.30.231.192:9001     10.128.0.5:9001,10.128.2.5:9001,10.129.0.5:9001,10.129.2.4:9001,10.130.0.3:9001,10.131.0.3:9001
      fcb0a3fb-4a77-4230-a84a-be45dce757e8    Service_openshif    tcp        172.30.189.92:443       10.130.0.17:8440
      67ef3e7b-ceb9-4bf0-8d96-b43bde4c9151    Service_openshif    tcp        172.30.67.218:443       10.129.0.9:8443
      d0032fba-7d5e-424a-af25-4ab9b5d46e81    Service_openshif    tcp        172.30.102.137:2379     10.0.0.3:2379,10.0.0.4:2379,10.0.0.5:2379
                                                                  tcp        172.30.102.137:9979     10.0.0.3:9979,10.0.0.4:9979,10.0.0.5:9979
      7361c537-3eec-4e6c-bc0c-0522d182abd4    Service_openshif    tcp        172.30.198.215:9001     10.0.0.3:9001,10.0.0.4:9001,10.0.0.5:9001,10.0.128.2:9001,10.0.128.3:9001,10.0.128.4:9001
      0296c437-1259-410b-a6fd-81c310ad0af5    Service_openshif    tcp        172.30.198.215:9001     10.0.0.3:9001,169.254.169.2:9001,10.0.0.5:9001,10.0.128.2:9001,10.0.128.3:9001,10.0.128.4:9001
      5d5679f5-45b8-479d-9f7c-08b123c688b8    Service_openshif    tcp        172.30.38.253:17698     10.128.0.52:17698,10.129.0.84:17698,10.130.0.60:17698
      2adcbab4-d1c9-447d-9573-b5dc9f2efbfa    Service_openshif    tcp        172.30.148.52:443       10.0.0.4:9202,10.0.0.5:9202
                                                                  tcp        172.30.148.52:444       10.0.0.4:9203,10.0.0.5:9203
                                                                  tcp        172.30.148.52:445       10.0.0.4:9204,10.0.0.5:9204
                                                                  tcp        172.30.148.52:446       10.0.0.4:9205,10.0.0.5:9205
      2a33a6d7-af1b-4892-87cc-326a380b809b    Service_openshif    tcp        172.30.67.219:9091      10.129.2.16:9091,10.131.0.16:9091
                                                                  tcp        172.30.67.219:9092      10.129.2.16:9092,10.131.0.16:9092
                                                                  tcp        172.30.67.219:9093      10.129.2.16:9093,10.131.0.16:9093
                                                                  tcp        172.30.67.219:9094      10.129.2.16:9094,10.131.0.16:9094
      f56f59d7-231a-4974-99b3-792e2741ec8d    Service_openshif    tcp        172.30.89.212:443       10.128.0.41:8443,10.129.0.68:8443,10.130.0.44:8443
      08c2c6d7-d217-4b96-b5d8-c80c4e258116    Service_openshif    tcp        172.30.102.137:2379     10.0.0.3:2379,169.254.169.2:2379,10.0.0.5:2379
                                                                  tcp        172.30.102.137:9979     10.0.0.3:9979,169.254.169.2:9979,10.0.0.5:9979
      60a69c56-fc6a-4de6-bd88-3f2af5ba5665    Service_openshif    tcp        172.30.10.193:443       10.129.0.25:8443
      ab1ef694-0826-4671-a22c-565fc2d282ec    Service_openshif    tcp        172.30.196.123:443      10.128.0.33:8443,10.129.0.64:8443,10.130.0.37:8443
      b1fb34d3-0944-4770-9ee3-2683e7a630e2    Service_openshif    tcp        172.30.158.93:8443      10.129.0.13:8443
      95811c11-56e2-4877-be1e-c78ccb3a82a9    Service_openshif    tcp        172.30.46.85:9001       10.130.0.16:9001
      4baba1d1-b873-4535-884c-3f6fc07a50fd    Service_openshif    tcp        172.30.28.87:443        10.129.0.26:8443
      6c2e1c90-f0ca-484e-8a8e-40e71442110a    Service_openshif    udp        172.30.0.10:53          10.128.0.13:5353,10.128.2.6:5353,10.129.0.39:5353,10.129.2.6:5353,10.130.0.11:5353,10.131.0.9:5353

      注記

      この出力 (一部省略あり) から、多くの OVN-Kubernetes ロードバランサーがあることがわかります。OVN-Kubernetes のロードバランサーはサービスの表現です。

5. 次のコマンドを実行して、コマンド ovn-nbctl で使用可能なオプションを表示します。

   $ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \
   -c nbdb ovn-nbctl --help

1. 次のコマンドを実行して、Pod を一覧表示します。

   $ oc get po -n openshift-ovn-kubernetes

   出力例

   NAME                                     READY   STATUS    RESTARTS      AGE
   ovnkube-control-plane-8444dff7f9-4lh9k   2/2     Running   0             27m
   ovnkube-control-plane-8444dff7f9-5rjh9   2/2     Running   0             27m
   ovnkube-node-55xs2                       8/8     Running   0             26m
   ovnkube-node-7r84r                       8/8     Running   0             16m
   ovnkube-node-bqq8p                       8/8     Running   0             17m
   ovnkube-node-mkj4f                       8/8     Running   0             26m
   ovnkube-node-mlr8k                       8/8     Running   0             26m
   ovnkube-node-wqn2m                       8/8     Running   0             16m

2. オプション: Pod とノード情報をリストするには、次のコマンドを実行します。

   $ oc get pods -n openshift-ovn-kubernetes -owide

   出力例

   NAME                                     READY   STATUS    RESTARTS      AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
   ovnkube-control-plane-8444dff7f9-4lh9k   2/2     Running   0             27m   10.0.0.3     ci-ln-t487nnb-72292-mdcnq-master-1         <none>           <none>
   ovnkube-control-plane-8444dff7f9-5rjh9   2/2     Running   0             27m   10.0.0.4     ci-ln-t487nnb-72292-mdcnq-master-2         <none>           <none>
   ovnkube-node-55xs2                       8/8     Running   0             26m   10.0.0.4     ci-ln-t487nnb-72292-mdcnq-master-2         <none>           <none>
   ovnkube-node-7r84r                       8/8     Running   0             17m   10.0.128.3   ci-ln-t487nnb-72292-mdcnq-worker-b-wbz7z   <none>           <none>
   ovnkube-node-bqq8p                       8/8     Running   0             17m   10.0.128.2   ci-ln-t487nnb-72292-mdcnq-worker-a-lh7ms   <none>           <none>
   ovnkube-node-mkj4f                       8/8     Running   0             27m   10.0.0.5     ci-ln-t487nnb-72292-mdcnq-master-0         <none>           <none>
   ovnkube-node-mlr8k                       8/8     Running   0             27m   10.0.0.3     ci-ln-t487nnb-72292-mdcnq-master-1         <none>           <none>
   ovnkube-node-wqn2m                       8/8     Running   0             17m   10.0.128.4   ci-ln-t487nnb-72292-mdcnq-worker-c-przlm   <none>           <none>

3. Pod に移動してサウスバウンドデータベースを確認します。

   $ oc rsh -c sbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2

4. 次のコマンドを実行して、サウスバウンドデータベース内のすべてのオブジェクトを表示します。

   $ ovn-sbctl show

   出力例

   Chassis "5db31703-35e9-413b-8cdf-69e7eecb41f7"
       hostname: ci-ln-9gp362t-72292-v2p94-worker-a-8bmwz
       Encap geneve
           ip: "10.0.128.4"
           options: {csum="true"}
       Port_Binding tstor-ci-ln-9gp362t-72292-v2p94-worker-a-8bmwz
   Chassis "070debed-99b7-4bce-b17d-17e720b7f8bc"
       hostname: ci-ln-9gp362t-72292-v2p94-worker-b-svmp6
       Encap geneve
           ip: "10.0.128.2"
           options: {csum="true"}
       Port_Binding k8s-ci-ln-9gp362t-72292-v2p94-worker-b-svmp6
       Port_Binding rtoe-GR_ci-ln-9gp362t-72292-v2p94-worker-b-svmp6
       Port_Binding openshift-monitoring_alertmanager-main-1
       Port_Binding rtoj-GR_ci-ln-9gp362t-72292-v2p94-worker-b-svmp6
       Port_Binding etor-GR_ci-ln-9gp362t-72292-v2p94-worker-b-svmp6
       Port_Binding cr-rtos-ci-ln-9gp362t-72292-v2p94-worker-b-svmp6
       Port_Binding openshift-e2e-loki_loki-promtail-qcrcz
       Port_Binding jtor-GR_ci-ln-9gp362t-72292-v2p94-worker-b-svmp6
       Port_Binding openshift-multus_network-metrics-daemon-mkd4t
       Port_Binding openshift-ingress-canary_ingress-canary-xtvj4
       Port_Binding openshift-ingress_router-default-6c76cbc498-pvlqk
       Port_Binding openshift-dns_dns-default-zz582
       Port_Binding openshift-monitoring_thanos-querier-57585899f5-lbf4f
       Port_Binding openshift-network-diagnostics_network-check-target-tn228
       Port_Binding openshift-monitoring_prometheus-k8s-0
       Port_Binding openshift-image-registry_image-registry-68899bd877-xqxjj
   Chassis "179ba069-0af1-401c-b044-e5ba90f60fea"
       hostname: ci-ln-9gp362t-72292-v2p94-master-0
       Encap geneve
           ip: "10.0.0.5"
           options: {csum="true"}
       Port_Binding tstor-ci-ln-9gp362t-72292-v2p94-master-0
   Chassis "68c954f2-5a76-47be-9e84-1cb13bd9dab9"
       hostname: ci-ln-9gp362t-72292-v2p94-worker-c-mjf9w
       Encap geneve
           ip: "10.0.128.3"
           options: {csum="true"}
       Port_Binding tstor-ci-ln-9gp362t-72292-v2p94-worker-c-mjf9w
   Chassis "2de65d9e-9abf-4b6e-a51d-a1e038b4d8af"
       hostname: ci-ln-9gp362t-72292-v2p94-master-2
       Encap geneve
           ip: "10.0.0.4"
           options: {csum="true"}
       Port_Binding tstor-ci-ln-9gp362t-72292-v2p94-master-2
   Chassis "1d371cb8-5e21-44fd-9025-c4b162cc4247"
       hostname: ci-ln-9gp362t-72292-v2p94-master-1
       Encap geneve
           ip: "10.0.0.3"
           options: {csum="true"}
       Port_Binding tstor-ci-ln-9gp362t-72292-v2p94-master-1

   この詳細な出力は、シャーシとシャーシに接続されているポート (この場合、すべてのルーターポートとホストネットワークのように動作するもの) を示しています。すべての Pod は、ソースネットワークアドレス変換 (SNAT) を使用して、より広いネットワークと通信します。Pod の IP アドレスは、Pod が実行されているノードの IP アドレスに変換され、ネットワークに送信されます。

   シャーシ情報に加えて、サウスバウンドデータベースにはすべての論理フローがあります。これらの論理フローは各ノードで実行されている ovn-controller に送信されます。ovn-controller は、論理フローをオープンフロールールに変換し、最終的に OpenvSwitch をプログラムして、Pod がオープンフロールールに従ってネットワークの外に出られるようにします。

5. 次のコマンドを実行して、コマンド ovn-sbctl で使用可能なオプションを表示します。

   $ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \
   -c sbdb ovn-sbctl --help

手順

1. 次のコマンドを実行して、ovnkube-node readiness プローブの詳細を確認します。

   $ oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node \
   -o json | jq '.items[0].spec.containers[] | .name,.readinessProbe'

   ovnkube-node Pod 内のノースバウンドおよびサウスバウンドのデータベースコンテナーの Readiness プローブは、データベースと ovnkube-controller コンテナーの正常性をチェックします。

   ovnkube-node Pod の ovnkube-controller コンテナーには、OVN-Kubernetes CNI 設定ファイルの存在を確認するための readiness プローブがあります。この設定ファイルがない場合、Pod が実行中でないか、Pod を設定するリクエストを受け入れる準備ができていません。

2. 次のコマンドを使用して、プローブの失敗を含む namespace のすべてのイベントを表示します。

   $ oc get events -n openshift-ovn-kubernetes

3. 特定の Pod のみのイベントを表示します。

   $ oc describe pod ovnkube-node-9lqfk -n openshift-ovn-kubernetes

4. クラスターネットワーク Operator からのメッセージとステータスを表示します。

   $ oc get co/network -o json | jq '.status.conditions[]'

5. 次のスクリプトを実行して、ovnkube-node Pod 内の各コンテナーの ready ステータスを表示します。

   $ for p in $(oc get pods --selector app=ovnkube-node -n openshift-ovn-kubernetes \
   -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); do echo === $p ===;  \
   oc get pods -n openshift-ovn-kubernetes $p -o json | jq '.status.containerStatuses[] | .name, .ready'; \
   done

   注記

   すべてのコンテナーのステータスが true として報告されることが期待されます。readiness プローブが失敗すると、ステータスが false に設定されます。

手順 (UI)

1. Administrator パースペクティブで、Observe → Alerting を選択します。このパースペクティブのアラート UI の主なページには、Alerts、Silences、および Alerting Rules という 3 つのページがあります。
2. Observe → Alerting → Alerting Rules を選択して、OVN-Kubernetes アラートのルールを表示します。

手順

1. 次のコマンドを実行して、アクティブまたは発生中のアラートを表示します。

   1. 次のコマンドを実行して、アラートマネージャーのルート環境変数を設定します。

      $ ALERT_MANAGER=$(oc get route alertmanager-main -n openshift-monitoring \
      -o jsonpath='{@.spec.host}')

   2. 以下のコマンドを実行してアラートマネージャールート API に curl リクエストを実行します。$ALERT_MANAGER は、Alertmanager インスタンスの URL に置き換えます。

      $ curl -s -k -H "Authorization: Bearer $(oc create token prometheus-k8s -n openshift-monitoring)" https://$ALERT_MANAGER/api/v1/alerts | jq '.data[] | "\(.labels.severity) \(.labels.alertname) \(.labels.pod) \(.labels.container) \(.labels.endpoint) \(.labels.instance)"'

2. 次のコマンドを実行して、アラートルールを表示します。

   $ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -s 'http://localhost:9090/api/v1/rules' | jq '.data.groups[].rules[] | select(((.name|contains("ovn")) or (.name|contains("OVN")) or (.name|contains("Ovn")) or (.name|contains("North")) or (.name|contains("South"))) and .type=="alerting")'

手順

1. 特定の Pod のログを表示します。

   $ oc logs -f <pod_name> -c <container_name> -n <namespace>

   ここでは、以下のようになります。

   -f

   オプション: ログに書き込まれている内容に沿って出力することを指定します。

   <pod_name>

   Pod の名前を指定します。

   <container_name>

   オプション: コンテナーの名前を指定します。Pod に複数のコンテナーがある場合、コンテナー名を指定する必要があります。

   <namespace>

   Pod が実行されている namespace を指定します。

   以下に例を示します。

   $ oc logs ovnkube-node-5dx44 -n openshift-ovn-kubernetes

   $ oc logs -f ovnkube-node-5dx44 -c ovnkube-controller -n openshift-ovn-kubernetes

   ログファイルの内容が出力されます。

2. ovnkube-node Pod 内のすべてのコンテナーの最新のエントリーを調べます。

   $ for p in $(oc get pods --selector app=ovnkube-node -n openshift-ovn-kubernetes \
   -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); \
   do echo === $p ===; for container in $(oc get pods -n openshift-ovn-kubernetes $p \
   -o json | jq -r '.status.containerStatuses[] | .name');do echo ---$container---; \
   oc logs -c $container $p -n openshift-ovn-kubernetes --tail=5; done; done

3. 次のコマンドを使用して、ovnkube-node Pod 内のすべてのコンテナーのすべてのログの最後の 5 行を表示します。

   $ oc logs -l app=ovnkube-node -n openshift-ovn-kubernetes --all-containers --tail 5

手順

1. OpenShift Container Platform コンソールで Workloads → Pods に移動するか、調査するリソースから Pod に移動します。
2. ドロップダウンメニューから openshift-ovn-kubernetes プロジェクトを選択します。
3. 調査する Pod の名前をクリックします。
4. Logs をクリックします。ovnkube-master のデフォルトでは、northd コンテナーに関連付けられたログが表示されます。
5. ドロップダウンメニューを使用して、各コンテナーのログを順番に選択します。

手順

1. 現在の PodNetworkConnectivityCheck オブジェクトをリスト表示するには、以下のコマンドを入力します。

   $ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics

2. 次のコマンドを使用して、各接続オブジェクトの最新の成功を表示します。

   $ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \
   -o json | jq '.items[]| .spec.targetEndpoint,.status.successes[0]'

3. 次のコマンドを使用して、各接続オブジェクトの最新のエラーを表示します。

   $ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \
   -o json | jq '.items[]| .spec.targetEndpoint,.status.failures[0]'

4. 次のコマンドを使用して、各接続オブジェクトの最新の停止を表示します。

   $ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \
   -o json | jq '.items[]| .spec.targetEndpoint,.status.outages[0]'

   接続チェックコントローラーは、これらのチェックからのメトリクスも Prometheus に記録します。

5. 次のコマンドを実行して、すべてのメトリクスを表示します。

   $ oc exec prometheus-k8s-0 -n openshift-monitoring -- \
   promtool query instant  http://localhost:9090 \
   '{component="openshift-network-diagnostics"}'

6. 過去 5 分間のソース Pod と openshift api サービス間のレイテンシーを表示します。

   $ oc exec prometheus-k8s-0 -n openshift-monitoring -- \
   promtool query instant  http://localhost:9090 \
   '{component="openshift-network-diagnostics"}'

手順

1. OVS サンプリング機能を使用して OVNObservability を有効にするには、次のコマンドを入力して、cluster という名前の FeatureGate CR で TechPreviewNoUpgrade 機能セットを有効にします。

   $ oc patch --type=merge --patch '{"spec": {"featureSet": "TechPreviewNoUpgrade"}}' featuregate/cluster

   出力例

   featuregate.config.openshift.io/cluster patched

2. 次のコマンドを入力して、OVNObservability 機能が有効になっていることを確認します。

   $ oc get featuregate cluster -o yaml

   出力例

     featureGates:
   # ...
       enabled:
       - name: OVNObservability

3. 次のコマンドを入力して、関連するネットワーク API の 1 つを作成した namespace 内の Pod のリストを取得します。次の手順で使用するために、Pod の NODE 名をメモします。

   $ oc get pods -n <namespace> -o wide

   出力例

   NAME              READY   STATUS    RESTARTS   AGE     IP            NODE                                       NOMINATED NODE   READINESS GATES
   destination-pod   1/1     Running   0          53s     10.131.0.23   ci-ln-1gqp7b2-72292-bb9dv-worker-a-gtmpc   <none>           <none>
   source-pod        1/1     Running   0          56s     10.131.0.22   ci-ln-1gqp7b2-72292-bb9dv-worker-a-gtmpc   <none>           <none>

4. 次のコマンドを入力して、OVN-Kubernetes Pod のリストを取得し、前の手順の Pod と同じ NODE を共有する Pod を見つけます。

   $ oc get pods -n openshift-ovn-kubernetes -o wide

   出力例

   NAME
   ...                             READY   STATUS    RESTARTS      AGE   IP           NODE                                       NOMINATED NODE
   ovnkube-node-jzn5b              8/8     Running   1 (34m ago)   37m   10.0.128.2   ci-ln-1gqp7b2-72292-bb9dv-worker-a-gtmpc   <none>
   ...

5. 次のコマンドを入力して、ovnkube-node Pod 内で bash シェルを開きます。

   $ oc exec -it <pod_name> -n openshift-ovn-kubernetes -- bash

6. ovnkube-node Pod 内では、ovnkube-observ -add-ovs-collector スクリプトを実行し、OVS コレクターを使用してネットワークイベントを表示できます。以下に例を示します。

   # /usr/bin/ovnkube-observ -add-ovs-collector

   出力例

   ...
   2024/12/02 19:41:41.327584 OVN-K message: Allowed by default allow from local node policy, direction ingress
   2024/12/02 19:41:41.327593 src=10.131.0.2, dst=10.131.0.6
   
   2024/12/02 19:41:41.327692 OVN-K message: Allowed by default allow from local node policy, direction ingress
   2024/12/02 19:41:41.327715 src=10.131.0.6, dst=10.131.0.2
   ...

7. -filter-src-ip フラグと Pod の IP アドレスを指定して次のコマンドを入力すると、ソース Pod などのタイプ別にコンテンツをフィルタリングできます。以下に例を示します。

   # /usr/bin/ovnkube-observ -add-ovs-collector -filter-src-ip <pod_ip_address>

   出力例

   ...
   Found group packets, id 14
   2024/12/10 16:27:12.456473 OVN-K message: Allowed by admin network policy allow-egress-group1, direction Egress
   2024/12/10 16:27:12.456570 src=10.131.0.22, dst=10.131.0.23
   
   2024/12/10 16:27:14.484421 OVN-K message: Allowed by admin network policy allow-egress-group1, direction Egress
   2024/12/10 16:27:14.484428 src=10.131.0.22, dst=10.131.0.23
   
   2024/12/10 16:27:12.457222 OVN-K message: Allowed by network policy test:allow-ingress-from-specific-pod, direction Ingress
   2024/12/10 16:27:12.457228 src=10.131.0.22, dst=10.131.0.23
   
   2024/12/10 16:27:12.457288 OVN-K message: Allowed by network policy test:allow-ingress-from-specific-pod, direction Ingress
   2024/12/10 16:27:12.457299 src=10.131.0.22, dst=10.131.0.23
   ...

   /usr/bin/ovnkube-observ で渡すことができるフラグの完全なリストは、「OVS サンプリングフラグを持つ OVN-Kubernetes ネットワークトラフィック」を参照してください。

手順

1. 次のコマンドを使用して Pod 変数を作成します。

   $  POD=$(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-control-plane -o name | head -1 | awk -F '/' '{print $NF}')

2. ローカルホストで次のコマンドを実行して、ovnkube-control-plane Pod からバイナリーをコピーします。

   $  oc cp -n openshift-ovn-kubernetes $POD:/usr/bin/ovnkube-trace -c ovnkube-cluster-manager ovnkube-trace

   注記

   Red Hat Enterprise Linux (RHEL) 8 を使用して ovnkube-trace ツールを実行している場合は、/usr/lib/rhel8/ovnkube-trace ファイルをローカルホストにコピーする必要があります。

3. 次のコマンドを実行して、ovnkube-trace を実行可能にします。

   $  chmod +x ovnkube-trace

4. 次のコマンドを実行して、ovnkube-trace で使用可能なオプションを表示します。

   $  ./ovnkube-trace -help

   予想される出力

   Usage of ./ovnkube-trace:
     -addr-family string
       	Address family (ip4 or ip6) to be used for tracing (default "ip4")
     -dst string
       	dest: destination pod name
     -dst-ip string
       	destination IP address (meant for tests to external targets)
     -dst-namespace string
       	k8s namespace of dest pod (default "default")
     -dst-port string
       	dst-port: destination port (default "80")
     -kubeconfig string
       	absolute path to the kubeconfig file
     -loglevel string
       	loglevel: klog level (default "0")
     -ovn-config-namespace string
       	namespace used by ovn-config itself
     -service string
       	service: destination service name
     -skip-detrace
       	skip ovn-detrace command
     -src string
       	src: source pod name
     -src-namespace string
       	k8s namespace of source pod (default "default")
     -tcp
       	use tcp transport protocol
     -udp
       	use udp transport protocol

   サポートされているコマンドライン引数は、namespace、Pod、サービスなど、よく知られた Kubernetes コンストラクトであるため、MAC アドレス、宛先ノードの IP アドレス、または ICMP タイプを見つける必要はありません。

   ログレベルは次のとおりです。

   • 0 (最小出力)
   • 2 (トレースコマンドの結果を示すより詳細な出力)
   • 5 (デバッグ出力)

手順

1. 次のコマンドを入力して、default namespace で Web サービスを開始します。

   $ oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80

2. openshift-dns namespace で実行されている Pod を一覧表示します。

   oc get pods -n openshift-dns

   出力例

   NAME                  READY   STATUS    RESTARTS   AGE
   dns-default-8s42x     2/2     Running   0          5h8m
   dns-default-mdw6r     2/2     Running   0          4h58m
   dns-default-p8t5h     2/2     Running   0          4h58m
   dns-default-rl6nk     2/2     Running   0          5h8m
   dns-default-xbgqx     2/2     Running   0          5h8m
   dns-default-zv8f6     2/2     Running   0          4h58m
   node-resolver-62jjb   1/1     Running   0          5h8m
   node-resolver-8z4cj   1/1     Running   0          4h59m
   node-resolver-bq244   1/1     Running   0          5h8m
   node-resolver-hc58n   1/1     Running   0          4h59m
   node-resolver-lm6z4   1/1     Running   0          5h8m
   node-resolver-zfx5k   1/1     Running   0          5h

3. 次の ovnkube-trace コマンドを実行して、DNS 解決が機能していることを確認します。

   $ ./ovnkube-trace \
     -src-namespace default \ 

   1

   
     -src web \ 

   2

   
     -dst-namespace openshift-dns \ 

   3

   
     -dst dns-default-p8t5h \ 

   4

   
     -udp -dst-port 53 \ 

   5

   
     -loglevel 0 

   6

   1

   ソース Pod の namespace

   2

   ソース Pod 名

   3

   宛先 Pod の namespace

   4

   宛先 Pod 名

   5

   udp トランスポートプロトコルを使用します。ポート 53 は、DNS サービスが使用するポートです。

   6

   ログレベルを 0 に設定します (0 は最小限で、5 はデバッグです)。

   src&dst Pod が同じノードに配置された場合の出力例

   ovn-trace source pod to destination pod indicates success from web to dns-default-p8t5h
   ovn-trace destination pod to source pod indicates success from dns-default-p8t5h to web
   ovs-appctl ofproto/trace source pod to destination pod indicates success from web to dns-default-p8t5h
   ovs-appctl ofproto/trace destination pod to source pod indicates success from dns-default-p8t5h to web
   ovn-detrace source pod to destination pod indicates success from web to dns-default-p8t5h
   ovn-detrace destination pod to source pod indicates success from dns-default-p8t5h to web

   src&dst Pod が別のノードに配置された場合の出力例

   ovn-trace source pod to destination pod indicates success from web to dns-default-8s42x
   ovn-trace (remote) source pod to destination pod indicates success from web to dns-default-8s42x
   ovn-trace destination pod to source pod indicates success from dns-default-8s42x to web
   ovn-trace (remote) destination pod to source pod indicates success from dns-default-8s42x to web
   ovs-appctl ofproto/trace source pod to destination pod indicates success from web to dns-default-8s42x
   ovs-appctl ofproto/trace destination pod to source pod indicates success from dns-default-8s42x to web
   ovn-detrace source pod to destination pod indicates success from web to dns-default-8s42x
   ovn-detrace destination pod to source pod indicates success from dns-default-8s42x to web

   この出力は、デプロイされた Pod から DNS ポートへの解決が成功し、その反対方向への解決も成功したことを示しています。つまり、Web Pod がコア DNS からの DNS 解決を行う場合に、UDP ポート 53 で双方向のトラフィックがサポートされていることがわかります。

手順

1. すべての namespace におけるすべての Pod からの Ingress を拒否する deny-by-default ポリシーを定義する次の YAML を作成します。YAML を deny-by-default.yaml ファイルに保存します。

   kind: NetworkPolicy
   apiVersion: networking.k8s.io/v1
   metadata:
     name: deny-by-default
     namespace: default
   spec:
     podSelector: {}
     ingress: []

2. 次のコマンドを入力して、ポリシーを適用します。

   $ oc apply -f deny-by-default.yaml

   出力例

   networkpolicy.networking.k8s.io/deny-by-default created

3. 次のコマンドを入力して、default namespace で Web サービスを開始します。

   $ oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80

4. 次のコマンドを実行して、prod namespace を作成します。

   $ oc create namespace prod

5. 次のコマンドを実行して、prod namespace にラベルを付けます。

   $ oc label namespace/prod purpose=production

6. 次のコマンドを実行して、alpine イメージを prod namespace にデプロイし、シェルを開始します。

   $ oc run test-6459 --namespace=prod --rm -i -t --image=alpine -- sh

7. 別のターミナルセッションを開きます。

8. この新しいターミナルセッションで ovn-trace を実行して、namespace prod で実行されているソース Pod test-6459 と default namespace で実行されている宛先 Pod 間の通信の失敗を確認します。

   $ ./ovnkube-trace \
    -src-namespace prod \
    -src test-6459 \
    -dst-namespace default \
    -dst web \
    -tcp -dst-port 80 \
    -loglevel 0

   出力例

   ovn-trace source pod to destination pod indicates failure from test-6459 to web

9. 次のコマンドを実行して、ログレベルを 2 に上げて、失敗の理由を明らかにします。

   $ ./ovnkube-trace \
    -src-namespace prod \
    -src test-6459 \
    -dst-namespace default \
    -dst web \
    -tcp -dst-port 80 \
    -loglevel 2

   出力例

   ...
   ------------------------------------------------
    3. ls_out_acl_hint (northd.c:7454): !ct.new && ct.est && !ct.rpl && ct_mark.blocked == 0, priority 4, uuid 12efc456
       reg0[8] = 1;
       reg0[10] = 1;
       next;
    5. ls_out_acl_action (northd.c:7835): reg8[30..31] == 0, priority 500, uuid 69372c5d
       reg8[30..31] = 1;
       next(4);
    5. ls_out_acl_action (northd.c:7835): reg8[30..31] == 1, priority 500, uuid 2fa0af89
       reg8[30..31] = 2;
       next(4);
    4. ls_out_acl_eval (northd.c:7691): reg8[30..31] == 2 && reg0[10] == 1 && (outport == @a16982411286042166782_ingressDefaultDeny), priority 2000, uuid 447d0dab
       reg8[17] = 1;
       ct_commit { ct_mark.blocked = 1; }; 

   1

   
       next;
   ...

   1

   デフォルトの拒否ポリシーが設定されているため、Ingress トラフィックがブロックされています。

10. ラベルが purpose=production の特定の namespace 内にあるすべての Pod からのトラフィックを許可するポリシーを作成します。YAML を web-allow-prod.yaml ファイルに保存します。

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: web-allow-prod
      namespace: default
    spec:
      podSelector:
        matchLabels:
          app: web
      policyTypes:
      - Ingress
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              purpose: production

11. 次のコマンドを入力して、ポリシーを適用します。

    $ oc apply -f web-allow-prod.yaml

12. 次のコマンドを入力して、ovnkube-trace を実行し、トラフィックが許可されていることを確認します。

    $ ./ovnkube-trace \
     -src-namespace prod \
     -src test-6459 \
     -dst-namespace default \
     -dst web \
     -tcp -dst-port 80 \
     -loglevel 0

    予想される出力

    ovn-trace source pod to destination pod indicates success from test-6459 to web
    ovn-trace destination pod to source pod indicates success from web to test-6459
    ovs-appctl ofproto/trace source pod to destination pod indicates success from test-6459 to web
    ovs-appctl ofproto/trace destination pod to source pod indicates success from web to test-6459
    ovn-detrace source pod to destination pod indicates success from test-6459 to web
    ovn-detrace destination pod to source pod indicates success from web to test-6459

13. 手順 6 で開いたシェルで次のコマンドを実行して、nginx を Web サーバーに接続します。

     wget -qO- --timeout=2 http://web.default

    予想される出力

    <!DOCTYPE html>
    <html>
    <head>
    <title>Welcome to nginx!</title>
    <style>
      body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
      }
    </style>
    </head>
    <body>
    <h1>Welcome to nginx!</h1>
    <p>If you see this page, the nginx web server is successfully installed and
    working. Further configuration is required.</p>
    
    <p>For online documentation and support please refer to
    <a href="http://nginx.org/">nginx.org</a>.<br/>
    Commercial support is available at
    <a href="http://nginx.com/">nginx.com</a>.</p>
    
    <p><em>Thank you for using nginx.</em></p>
    </body>
    </html>

手順

1. クラスターおよびサービスネットワークの IPv6 アドレスブロックを指定するには、次の例のような設定を持つ YAML 設定パッチファイルを作成します。

   - op: add
     path: /spec/clusterNetwork/-
     value: 

   1

   
       cidr: fd01::/48
       hostPrefix: 64
   - op: add
     path: /spec/serviceNetwork/-
     value: fd02::/112 

   2

   1

   cidr および hostPrefix パラメーターを使用してオブジェクトを指定します。ホストの接頭辞は 64 以上である必要があります。IPv6Classless Inter-Domain Routing (CIDR) 接頭辞は、指定されたホスト接頭辞を対応できる大きさである必要があります。

   2

   接頭辞が 112 である IPv6 CIDR を指定します。Kubernetes は最低レベルの 16 ビットのみを使用します。接頭辞が 112 の場合、IP アドレスは 112 から 128 ビットに割り当てられます。

2. CLI で次のコマンドを入力して、クラスターネットワーク設定にパッチを適用します。

   $ oc patch network.config.openshift.io cluster \

   1

   
     --type='json' --patch-file <file>.yaml

   1

   ここで、file は作成した YAML ファイルの名前を指定します。

   出力例

   network.config.openshift.io/cluster patched

3. API および Ingress サービス用の IPv6 仮想 IP を追加した installer-provisioned infrastructure で、次の手順を実行します。

   1. クラスターの API および Ingress サービスに IPv6 仮想 IP を指定します。次の例と同様の設定を含む YAML 設定パッチファイルを作成します。

      - op: add
        path: /spec/platformSpec/baremetal/machineNetworks/- 

      1

      
        value: fd2e:6f44:5dd8::/64
      - op: add
        path: /spec/platformSpec/baremetal/apiServerInternalIPs/- 

      2

      
        value: fd2e:6f44:5dd8::4
      - op: add
        path: /spec/platformSpec/baremetal/ingressIPs/-
        value: fd2e:6f44:5dd8::5

      1

      マシンが動作する machineNetwork ネットワークのアドレスブロックを指定していることを確認してください。マシンネットワークの API および Ingress の両方の IP アドレスを選択する必要があります。

      2

      プラットフォームに応じて各ファイルパスを指定してください。この例では、ベアメタルプラットフォーム上のファイルパスを示しています。

   2. CLI で次のコマンドを入力してインフラストラクチャーにパッチを適用します。

      $ oc patch infrastructure cluster \
        --type='json' --patch-file <file>.yaml

      詳細は、以下のようになります。

      <file>

      作成した YAML ファイルの名前を指定します。

      出力例

      infrastructure/cluster patched

検証

1. CLI で次のコマンドを入力して、クラスターネットワーク設定を表示します。

   $ oc describe network

2. クラスターネットワーク設定が YAML ファイルで指定した IPv6 アドレスブロックを認識していることを確認し、ネットワーク設定へのパッチのインストールが正常に行われたことを確認します。

   出力例

   # ...
   Status:
     Cluster Network:
       Cidr:               10.128.0.0/14
       Host Prefix:        23
       Cidr:               fd01::/48
       Host Prefix:        64
     Cluster Network MTU:  1400
     Network Type:         OVNKubernetes
     Service Network:
       172.30.0.0/16
       fd02::/112
   # ...

3. installer-provisioned infrastructure 上で実行されるクラスターに対して、次の追加タスクを完了します。

   1. CLI で次のコマンドを入力して、クラスターインフラストラクチャー設定を表示します。

      $ oc describe infrastructure

   2. YAML ファイルで指定した IPv6 アドレスブロックがインフラストラクチャーによって認識されるかどうかを確認して、クラスターインフラストラクチャーへのパッチのインストールが正常に行われたことを確認します。

      出力例

      # ...
      spec:
      # ...
        platformSpec:
          baremetal:
            apiServerInternalIPs:
            - 192.168.123.5
            - fd2e:6f44:5dd8::4
            ingressIPs:
            - 192.168.123.10
            - fd2e:6f44:5dd8::5
      status:
      # ...
        platformStatus:
          baremetal:
            apiServerInternalIP: 192.168.123.5
            apiServerInternalIPs:
            - 192.168.123.5
            - fd2e:6f44:5dd8::4
            ingressIP: 192.168.123.10
            ingressIPs:
            - 192.168.123.10
            - fd2e:6f44:5dd8::5
      # ...

手順

1. 以下のコマンドを実行して、networks.config.openshift.io カスタムリソース (CR) を編集します。

   $ oc edit networks.config.openshift.io

2. 「デュアルスタッククラスターネットワークへの変換」手順の実行時に cidr および hostPrefix パラメーターに追加した IPv4 または IPv6 設定を削除します。

手順

1. 次のコマンドを実行して、既存のネットワーク設定をバックアップします。

   $ oc get network.operator cluster -o yaml > network-config-backup.yaml

2. 次のコマンドを入力して、routingViaHost パラメーターを true に設定します。その後、Egress トラフィックは、ノードで設定されたルートに従って特定のゲートウェイを経由してルーティングされます。

   $ oc patch networks.operator.openshift.io cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"routingViaHost": true}}}}}'

3. 次のコマンドを実行して、routingViaHost=true 設定が正しく適用されていることを確認します。

   $ oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"

   出力例

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   # ...
   gatewayConfig:
           ipv4: {}
           ipv6: {}
           routingViaHost: true 

   1

   
         genevePort: 6081
         ipsecConfig:
   # ...

   1

   true の値は、Egress トラフィックが Pod をホストするノード上の特定のローカルゲートウェイを経由してルーティングされることを意味します。パラメーターの値が false の場合、ノードのグループが単一のゲートウェイを共有するため、トラフィックは単一のホストを経由してルーティングされません。

4. オプション: 次のコマンドを実行して、IP 転送をグローバルに有効にします。

   $ oc patch network.operator cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}'

   1. 次のコマンドを実行して、ipForwarding 仕様が Global に設定されていることを確認します。

      $ oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"

      出力例

      apiVersion: operator.openshift.io/v1
      kind: Network
      metadata:
        name: cluster
      # ...
      gatewayConfig:
              ipForwarding: Global
              ipv4: {}
              ipv6: {}
              routingViaHost: true
            genevePort: 6081
      # ...

手順

1. AdminPolicyBasedExternalRoute オブジェクトを含む YAML ファイルを作成します。

2. 管理ポリシーベースの外部ルートを作成するには、次のコマンドを入力します。

   $ oc create -f <file>.yaml

   ここでは、以下のようになります。

   <file>

   前の手順で作成した YAML ファイルの名前を指定します。

   出力例

   adminpolicybasedexternalroute.k8s.ovn.org/default-route-policy created

3. 管理ポリシーベースの外部ルートが作成されたことを確認するには、次のコマンドを入力します。

   $ oc describe apbexternalroute <name> | tail -n 6

   ここでは、以下のようになります。

   <name>

   AdminPolicyBasedExternalRoute オブジェクトの名前を指定します。

   出力例

   Status:
     Last Transition Time:  2023-04-24T15:09:01Z
     Messages:
     Configured external gateway IPs: 172.18.0.8
     Status:  Success
   Events:  <none>

手順

1. EgressIP オブジェクトを作成します。

   1. <egressips_name>.yaml ファイルを作成します。<egressips_name> はオブジェクトの名前になります。

   2. 作成したファイルで、以下の例のように EgressIP オブジェクトを定義します。

      apiVersion: k8s.ovn.org/v1
      kind: EgressIP
      metadata:
        name: egress-project1
      spec:
        egressIPs:
        - 192.168.127.10
        - 192.168.127.11
        namespaceSelector:
          matchLabels:
            env: qa

2. オブジェクトを作成するには、以下のコマンドを入力します。

   $ oc apply -f <egressips_name>.yaml

   ここでは、以下のようになります。

   <egressips_name>

   <egressips_name> をオブジェクトの名前に置き換えます。

   出力例

   egressips.k8s.ovn.org/<egressips_name> created

3. オプション: 後に変更できるように <egressips_name>.yaml ファイルを保存します。

4. Egress IP アドレスを必要とする namespace にラベルを追加します。手順 1 で定義した EgressIP オブジェクトの namespace にラベルを追加するには、以下のコマンドを実行します。

   $ oc label ns <namespace> env=qa

   ここでは、以下のようになります。

   <namespace>

   <namespace> は、Egress IP アドレスを必要とする namespace に置き換えてください。

検証

1. EgressIP オブジェクトをテストおよび検証するための Pod マニフェストファイルを作成します。Pod はクライアントワークロードとして機能し、EgressIP ポリシーが期待どおりに機能することを確認するために送信トラフィックを送信します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: ubi-egressip-pod
     namespace: test
     labels:
       egressip: ds
   spec:
     containers:
     - name: fedora-curl
       image: registry.redhat.io/ubi9/ubi
       command: ["/bin/bash", "-c", "sleep infinity"]
   # ...

   ここでは、以下のようになります。

   <labels>

   EgressIP オブジェクトがこれらのラベルを使用してターゲット Pod に Egress IP アドレスを適用できるように、カスタム識別子を設定します。

2. Pod 内から外部サーバーに curl リクエストを実行します。このアクションは、送信トラフィックが EgressIP オブジェクトで指定したアドレスを正しく使用していることを確認します。

   $ curl <ipv_address>

   ここでは、以下のようになります。

   <ipv_address>

   EgressIP オブジェクトに応じて、IPv4 アドレスまたは IPv6 アドレスを入力します。

手順

1. サービスに必要な IP を使用して IPAddressPool CR を作成します。

   1. 次の例のような内容を含むファイル (ip-addr-pool.yaml など) を作成します。

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        name: example-pool
        namespace: metallb-system
      spec:
        addresses:
        - 172.19.0.100/32

   2. 次のコマンドを実行して、IP アドレスプールの設定を適用します。

      $ oc apply -f ip-addr-pool.yaml

2. Service CR および EgressService CR を作成します。

   1. 次の例のような内容を含むファイル (service-egress-service.yaml など) を作成します。

      apiVersion: v1
      kind: Service
      metadata:
        name: example-service
        namespace: example-namespace
        annotations:
          metallb.io/address-pool: example-pool 

      1

      
      spec:
        selector:
          app: example
        ports:
          - name: http
            protocol: TCP
            port: 8080
            targetPort: 8080
        type: LoadBalancer
      ---
      apiVersion: k8s.ovn.org/v1
      kind: EgressService
      metadata:
        name: example-service
        namespace: example-namespace
      spec:
        sourceIPBy: "LoadBalancerIP" 

      2

      
        nodeSelector: 

      3

      
          matchLabels:
            node-role.kubernetes.io/worker: ""

      1

      LoadBalancer サービスは、example-pool IP アドレスプールから MetalLB によって割り当てられた IP アドレスを使用します。

      2

      この例では、LoadBalancerIP 値を使用して、LoadBalancer サービスの Ingress IP アドレスを Egress トラフィックの送信元 IP アドレスとして割り当てます。

      3

      LoadBalancerIP 値を指定すると、単一ノードが LoadBalancer サービスのトラフィックを処理します。この例では、トラフィックを処理する場合に worker ラベルが割り当てられたノードのみを選択できます。ノードが選択されると、OVN-Kubernetes はそのノードに egress-service.k8s.ovn.org/<svc-namespace>-<svc-name>: "" という形式でラベルを付けます。

      注記

      sourceIPBy: "LoadBalancerIP" 設定を使用する場合は、BGPAdvertisement カスタムリソース (CR) でロードバランサーノードを指定する必要があります。

   2. 次のコマンドを実行して、サービスと Egress サービスの設定を適用します。

      $ oc apply -f service-egress-service.yaml

3. BGPAdvertisement CR を作成してサービスをアドバタイズします。

   1. 次の例のような内容を含むファイル (service-bgp-advertisement.yaml など) を作成します。

      apiVersion: metallb.io/v1beta1
      kind: BGPAdvertisement
      metadata:
        name: example-bgp-adv
        namespace: metallb-system
      spec:
        ipAddressPools:
        - example-pool
        nodeSelectors:
        - matchLabels:
            egress-service.k8s.ovn.org/example-namespace-example-service: "" 

      1

      1

      この例では、EgressService CR は、ロードバランサーサービス IP アドレスを使用するように、Egress トラフィックの送信元 IP アドレスを設定します。したがって、Pod から発信されるトラフィックに同じリターンパスを使用するには、リターントラフィックのロードバランサーノードを指定する必要があります。

検証

1. 次のコマンドを実行して、MetalLB サービスの背後で実行されている Pod のアプリケーションエンドポイントにアクセスできることを確認します。

   $ curl <external_ip_address>:<port_number> 

   1

   1

   アプリケーションのエンドポイントに合わせて外部 IP アドレスとポート番号を更新します。

2. LoadBalancer サービスの Ingress IP アドレスを Egress トラフィックの送信元 IP アドレスとして割り当てた場合は、tcpdump などのツールを使用して外部クライアントで受信したパケットを分析し、この設定を確認します。

手順

1. Egress ルーター定義の作成

2. 他の Pod が Egress ルーター Pod の IP アドレスを見つられるようにするには、以下の例のように、Egress ルーターを使用するサービスを作成します。

   apiVersion: v1
   kind: Service
   metadata:
     name: egress-1
   spec:
     ports:
     - name: web-app
       protocol: TCP
       port: 8080
     type: ClusterIP
     selector:
       app: egress-router-cni 

   1

   1

   Egress ルーターのラベルを指定します。表示されている値は Cluster Network Operator によって追加され、設定不可能です。

   サービスの作成後に、Pod はサービスに接続できます。Egress ルーター Pod は、トラフィックを宛先 IP アドレスの対応するポートにリダイレクトします。接続は、予約された送信元 IP アドレスを起点とします。

1. Operator が Egress ルーター用に作成したネットワークアタッチメント定義を表示します。

   $ oc get network-attachment-definition egress-router-cni-nad

   このネットワークアタッチメント定義の名前は設定できません。

   出力例

   NAME                    AGE
   egress-router-cni-nad   18m

2. Egress ルーター Pod のデプロイメントを表示します。

   $ oc get deployment egress-router-cni-deployment

   デプロイメントの名前は設定できません。

   出力例

   NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
   egress-router-cni-deployment   1/1     1            1           18m

3. Egress ルーター Pod のステータスを表示します。

   $ oc get pods -l app=egress-router-cni

   出力例

   NAME                                            READY   STATUS    RESTARTS   AGE
   egress-router-cni-deployment-575465c75c-qkq6m   1/1     Running   0          18m

4. Egress ルーター Pod のログとルーティングテーブルを表示します。

1. Egress ルーター Pod のノード名を取得します。

   $ POD_NODENAME=$(oc get pod -l app=egress-router-cni -o jsonpath="{.items[0].spec.nodeName}")

2. ターゲットノードのデバッグセッションに入ります。この手順は、<node_name>-debug というデバッグ Pod をインスタンス化します。

   $ oc debug node/$POD_NODENAME

3. /host をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の /host にホストのルートファイルシステムをマウントします。ルートディレクトリーを /host に変更すると、ホストの実行可能パスに含まれるバイナリーを実行できます。

   # chroot /host

4. chroot 環境コンソール内から、Egress ルーターログを表示します。

   # cat /tmp/egress-router-log

   出力例

   2021-04-26T12:27:20Z [debug] Called CNI ADD
   2021-04-26T12:27:20Z [debug] Gateway: 192.168.12.1
   2021-04-26T12:27:20Z [debug] IP Source Addresses: [192.168.12.99/24]
   2021-04-26T12:27:20Z [debug] IP Destinations: [80 UDP 10.0.0.99/30 8080 TCP 203.0.113.26/30 80 8443 TCP 203.0.113.27/30 443]
   2021-04-26T12:27:20Z [debug] Created macvlan interface
   2021-04-26T12:27:20Z [debug] Renamed macvlan to "net1"
   2021-04-26T12:27:20Z [debug] Adding route to gateway 192.168.12.1 on macvlan interface
   2021-04-26T12:27:20Z [debug] deleted default route {Ifindex: 3 Dst: <nil> Src: <nil> Gw: 10.128.10.1 Flags: [] Table: 254}
   2021-04-26T12:27:20Z [debug] Added new default route with gateway 192.168.12.1
   2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p UDP --dport 80 -j DNAT --to-destination 10.0.0.99
   2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p TCP --dport 8080 -j DNAT --to-destination 203.0.113.26:80
   2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p TCP --dport 8443 -j DNAT --to-destination 203.0.113.27:443
   2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat -o net1 -j SNAT --to-source 192.168.12.99

   この手順で説明されているように、EgressRouter オブジェクトを作成して Egress ルーターを起動する場合、ロギングファイルの場所とロギングレベルは設定できません。

5. chroot 環境コンソール内で、コンテナー ID を取得します。

   # crictl ps --name egress-router-cni-pod | awk '{print $1}'

   出力例

   CONTAINER
   bac9fae69ddb6

6. コンテナーのプロセス ID を判別します。この例では、コンテナー ID は bac9fae69ddb6 です。

   # crictl inspect -o yaml bac9fae69ddb6 | grep 'pid:' | awk '{print $2}'

   出力例

   68857

7. コンテナーのネットワーク namespace を入力します。

   # nsenter -n -t 68857

8. ルーティングテーブルを表示します。

   # ip route

   以下の出力例では、net1 ネットワークインターフェイスはデフォルトのルートです。クラスターネットワークのトラフィックは eth0 ネットワークインターフェイスを使用します。192.168.12.0/24 ネットワークのトラフィックは、net1 ネットワークインターフェイスを使用し、予約された送信元 IP アドレス 192.168.12.99 を起点とします。Pod は他のすべてのトラフィックを IP アドレス 192.168.12.1 のゲートウェイにルーティングします。サービスネットワークのルーティングは表示されません。

   出力例

   default via 192.168.12.1 dev net1
   10.128.10.0/23 dev eth0 proto kernel scope link src 10.128.10.18
   192.168.12.0/24 dev net1 proto kernel scope link src 192.168.12.99
   192.168.12.1 dev net1

1. 現在のプロジェクトを、マルチキャストを有効にしたプロジェクトに切り替えます。<project> をプロジェクト名に置き換えます。

   $ oc project <project>

2. マルチキャストレシーバーとして機能する Pod を作成します。

   $ cat <<EOF| oc create -f -
   apiVersion: v1
   kind: Pod
   metadata:
     name: mlistener
     labels:
       app: multicast-verify
   spec:
     containers:
       - name: mlistener
         image: registry.access.redhat.com/ubi9
         command: ["/bin/sh", "-c"]
         args:
           ["dnf -y install socat hostname && sleep inf"]
         ports:
           - containerPort: 30102
             name: mlistener
             protocol: UDP
   EOF

3. マルチキャストセンダーとして機能する Pod を作成します。

   $ cat <<EOF| oc create -f -
   apiVersion: v1
   kind: Pod
   metadata:
     name: msender
     labels:
       app: multicast-verify
   spec:
     containers:
       - name: msender
         image: registry.access.redhat.com/ubi9
         command: ["/bin/sh", "-c"]
         args:
           ["dnf -y install socat && sleep inf"]
   EOF

4. 新しいターミナルウィンドウまたはタブで、マルチキャストリスナーを起動します。

   1. Pod の IP アドレスを取得します。

      $ POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')

   2. 次のコマンドを入力して、マルチキャストリスナーを起動します。

      $ oc exec mlistener -i -t -- \
          socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname

5. マルチキャストトランスミッターを開始します。

   1. Pod ネットワーク IP アドレス範囲を取得します。

      $ CIDR=$(oc get Network.config.openshift.io cluster \
          -o jsonpath='{.status.clusterNetwork[0].cidr}')

   2. マルチキャストメッセージを送信するには、以下のコマンドを入力します。

      $ oc exec msender -i -t -- \
          /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"

      マルチキャストが機能している場合、直前のコマンドは以下の出力を返します。

      mlistener

手順

1. ネットワークフローコレクターのタイプおよびコレクターの IP アドレスとポート情報を指定するパッチファイルを作成します。

   spec:
     exportNetworkFlows:
       netFlow:
         collectors:
           - 192.168.1.99:2056

2. ネットワークフローコレクターで CNO を設定します。

   $ oc patch network.operator cluster --type merge -p "$(cat <file_name>.yaml)"

   出力例

   network.operator.openshift.io/cluster patched

1. Operator 設定を表示して、exportNetworkFlows フィールドが設定されていることを確認します。

   $ oc get network.operator cluster -o jsonpath="{.spec.exportNetworkFlows}"

   出力例

   {"netFlow":{"collectors":["192.168.1.99:2056"]}}

2. 各ノードから OVS のネットワークフロー設定を表示します。

   $ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node -o jsonpath='{range@.items[*]}{.metadata.name}{"\n"}{end}');
     do ;
       echo;
       echo $pod;
       oc -n openshift-ovn-kubernetes exec -c ovnkube-controller $pod \
         -- bash -c 'for type in ipfix sflow netflow ; do ovs-vsctl find $type ; done';
   done

   出力例

   ovnkube-node-xrn4p
   _uuid               : a4d2aaca-5023-4f3d-9400-7275f92611f9
   active_timeout      : 60
   add_id_to_interface : false
   engine_id           : []
   engine_type         : []
   external_ids        : {}
   targets             : ["192.168.1.99:2056"]
   
   ovnkube-node-z4vq9
   _uuid               : 61d02fdb-9228-4993-8ff5-b27f01a29bd6
   active_timeout      : 60
   add_id_to_interface : false
   engine_id           : []
   engine_type         : []
   external_ids        : {}
   targets             : ["192.168.1.99:2056"]-
   
   ...

手順

1. すべてのネットワークフローコレクターを削除します。

   $ oc patch network.operator cluster --type='json' \
       -p='[{"op":"remove", "path":"/spec/exportNetworkFlows"}]'

   出力例

   network.operator.openshift.io/cluster patched

手順

1. OVN-Kubernetes ハイブリッドネットワークオーバーレイを設定するには、次のコマンドを入力します。

   $ oc patch networks.operator.openshift.io cluster --type=merge \
     -p '{
       "spec":{
         "defaultNetwork":{
           "ovnKubernetesConfig":{
             "hybridOverlayConfig":{
               "hybridClusterNetwork":[
                 {
                   "cidr": "<cidr>",
                   "hostPrefix": <prefix>
                 }
               ],
               "hybridOverlayVXLANPort": <overlay_port>
             }
           }
         }
       }
     }'

   ここでは、以下のようになります。

   cidr

   追加のオーバーレイネットワーク上のノードに使用される CIDR 設定を指定します。この CIDR は、クラスターネットワーク CIDR と重複させることはできません。

   hostPrefix

   それぞれの個別ノードに割り当てるサブネット接頭辞の長さを指定します。たとえば、hostPrefix が 23 に設定されている場合、各ノードに指定の cidr から /23 サブネットが割り当てられます。これにより、510 (2^(32 - 23) - 2) Pod IP アドレスが許可されます。外部ネットワークからのノードへのアクセスを提供する必要がある場合には、ロードバランサーおよびルーターを、トラフィックを管理するように設定します。

   hybridOverlayVXLANPort

   追加のオーバーレイネットワークのカスタム VXLAN ポートを指定します。これは、vSphere にインストールされたクラスターで Windows ノードを実行するために必要であり、その他のクラウドプロバイダー用に設定することはできません。カスタムポートには、デフォルトの 6081 ポートを除くいずれかのオープンポートを使用できます。この要件の詳細は、Microsoft ドキュメントの Pod-to-pod connectivity between hosts is broken を参照してください。

   注記

   Windows Server Long-Term Servicing Channel (LTSC): Windows Server 2019 は、カスタムの VXLAN ポートの選択をサポートしないため、カスタムの hybridOverlayVXLANPort 値を持つクラスターではサポートされません。

   出力例

   network.operator.openshift.io/cluster patched

2. 設定がアクティブであることを確認するには、以下のコマンドを入力します。更新が適用されるまでに数分の時間がかかることがあります。

   $ oc get network.operator.openshift.io -o jsonpath="{.items[0].spec.defaultNetwork.ovnKubernetesConfig}"