ネットワーク

手順

1. ポリシールールを作成します。

   1. <policy-name>.yaml ファイルを作成します。<policy-name> はポリシールールを記述します。

   2. 作成したばかりのファイルで、以下の例のようなポリシーオブジェクトを定義します。

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: <policy-name> 1
      spec:
        podSelector:
        ingress: []

      1

      ポリシーオブジェクトの名前を指定します。

2. 以下のコマンドを実行してポリシーオブジェクトを作成します。

   $ oc create -f <policy-name>.yaml -n <project>

   以下の例では、新規 NetworkPolicy オブジェクトが project1 という名前のプロジェクトに作成されます。

   $ oc create -f default-deny.yaml -n project1

   出力例

   networkpolicy "default-deny" created

手順

1. オプション: 現在の NetworkPolicy オブジェクトを一覧表示します。

   1. 特定の namespace のポリシーオブジェクトを一覧表示するには、以下のコマンドを入力します。<namespace> をプロジェクトの namespace に置き換えます。

      $ oc get networkpolicy -n <namespace>

   2. クラスター全体についてのポリシーオブジェクトを一覧表示するには、以下のコマンドを入力します。

      $ oc get networkpolicy --all-namespaces

2. NetworkPolicy オブジェクトを編集します。

   1. ネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。<policy-file> を、オブジェクト定義が含まれるファイルの名前に置き換えます。

      $ oc apply -f <policy-file>.yaml

   2. NetworkPolicy オブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。<policy-name> を NetworkPolicy オブジェクトの名前に置き換え、<namespace> をオブジェクトが存在するプロジェクトの名前に置き換えます。

      $ oc edit <policy-name> -n <namespace>

3. NetworkPolicy オブジェクトが更新されていることを確認します。<namespace> をオブジェクトが存在するプロジェクトの名前に置き換えます。

   $ oc get networkpolicy -n <namespace> -o yaml

手順

1. cluster-admin 権限を持つユーザーとしてログインしている。

2. デフォルトのプロジェクトテンプレートを生成します。

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. オブジェクトを追加するか、または既存オブジェクトを変更することにより、テキストエディターで生成される template.yaml ファイルを変更します。

4. プロジェクトテンプレートは、openshift-config namespace に作成される必要があります。変更したテンプレートを読み込みます。

   $ oc create -f template.yaml -n openshift-config

5. Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。

   • Web コンソールの使用

     1. Administration → Cluster Settings ページに移動します。
     2. Global Configuration をクリックし、すべての設定リソースを表示します。
     3. Project のエントリーを見つけ、Edit YAML をクリックします。

   • CLI の使用

     1. project.config.openshift.io/cluster リソースを編集します。

        $ oc edit project.config.openshift.io/cluster

6. spec セクションを、projectRequestTemplate および name パラメーターを組み込むように更新し、アップロードされたプロジェクトテンプレートの名前を設定します。デフォルト名は project-request です。

   カスタムプロジェクトテンプレートを含むプロジェクト設定リソース

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestTemplate:
       name: <template_name>

7. 変更を保存した後、変更が正常に適用されたことを確認するために、新しいプロジェクトを作成します。

手順

1. 以下のコマンドを実行して、新規プロジェクトのデフォルトテンプレートを編集します。

   $ oc edit template <project_template> -n openshift-config

   <project_template> を、クラスターに設定したデフォルトテンプレートの名前に置き換えます。デフォルトのテンプレート名は project-request です。

2. テンプレートでは、各 NetworkPolicy オブジェクトを要素として objects パラメーターに追加します。objects パラメーターは、1 つ以上のオブジェクトのコレクションを受け入れます。

   以下の例では、objects パラメーターのコレクションにいくつかの NetworkPolicy オブジェクトが含まれます。

   objects:
   - apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: allow-from-same-namespace
     spec:
       podSelector:
       ingress:
       - from:
         - podSelector: {}
   - apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: allow-from-openshift-ingress
     spec:
       ingress:
       - from:
         - namespaceSelector:
             matchLabels:
               network.openshift.io/policy-group: ingress
       podSelector: {}
       policyTypes:
       - Ingress
   ...

3. オプション: 以下のコマンドを実行して、新規プロジェクトを作成し、ネットワークポリシーオブジェクトが正常に作成されることを確認します。

   1. 新規プロジェクトを作成します。

      $ oc new-project <project> 1

      1

      <project> を、作成しているプロジェクトの名前に置き換えます。

   2. 新規プロジェクトテンプレートのネットワークポリシーオブジェクトが新規プロジェクトに存在することを確認します。

      $ oc get networkpolicy
      NAME                           POD-SELECTOR   AGE
      allow-from-openshift-ingress   <none>         7s
      allow-from-same-namespace      <none>         7s

手順

1. 以下の NetworkPolicy オブジェクトを作成します。

   1. allow-from-openshift-ingress という名前のポリシー:

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-ingress
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: ingress
        podSelector: {}
        policyTypes:
        - Ingress
      EOF

   2. allow-from-openshift-monitoring という名前のポリシー。

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-monitoring
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: monitoring
        podSelector: {}
        policyTypes:
        - Ingress
      EOF

   3. allow-same-namespace という名前のポリシー:

      $ cat << EOF| oc create -f -
      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
      EOF

2. default Ingress コントローラー設定に spec.endpointPublishingStrategy: HostNetwork の値が設定されている場合、ラベルを default OpenShift Container Platform namespace に適用し、Ingress コントローラーとプロジェクト間のネットワークトラフィックを許可する必要があります。

   1. default Ingress コントローラーが HostNetwork エンドポイント公開ストラテジーを使用するかどうかを判別します。

      $ oc get --namespace openshift-ingress-operator ingresscontrollers/default \
        --output jsonpath='{.status.endpointPublishingStrategy.type}'

   2. 直前のコマンドによりエンドポイント公開ストラテジーが HostNetwork として報告される場合には、default namespace にラベルを設定します。

      $ oc label namespace default 'network.openshift.io/policy-group=ingress'

3. 以下のコマンドを実行し、NetworkPolicy オブジェクトが現在のプロジェクトに存在することを確認します。

   $ oc get networkpolicy <policy-name> -o yaml

   以下の例では、allow-from-openshift-ingress NetworkPolicy オブジェクトが表示されています。

   $ oc get -n project1 networkpolicy allow-from-openshift-ingress -o yaml

   出力例

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: allow-from-openshift-ingress
     namespace: project1
   spec:
     ingress:
     - from:
       - namespaceSelector:
           matchLabels:
             network.openshift.io/policy-group: ingress
     podSelector: {}
     policyTypes:
     - Ingress

手順

1. アノテーションを Pod オブジェクトに追加します。以下のアノテーション形式のいずれかのみを使用できます。

   1. カスタマイズせずに追加ネットワークを割り当てるには、以下の形式でアノテーションを追加します。<network> を、Pod に関連付ける追加ネットワークの名前に置き換えます。

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 1

      1

      複数の追加ネットワークを指定するには、各ネットワークをコンマで区切ります。コンマの間にはスペースを入れないでください。同じ追加ネットワークを複数回指定した場合、Pod は複数のネットワークインターフェイスをそのネットワークに割り当てます。

   2. カスタマイズして追加のネットワークを割り当てるには、以下の形式でアノテーションを追加します。

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: |-
            [
              {
                "name": "<network>", 1
                "namespace": "<namespace>", 2
                "default-route": ["<default-route>"] 3
              }
            ]

      1

      NetworkAttachmentDefinition オブジェクトによって定義される追加のネットワークの名前を指定します。

      2

      NetworkAttachmentDefinition オブジェクトが定義される namespace を指定します。

      3

      オプション: 192.168.17.1 などのデフォルトルートのオーバーライドを指定します。

2. Pod を作成するには、以下のコマンドを入力します。<name> を Pod の名前に置き換えます。

   $ oc create -f <name>.yaml

3. オプション: アノテーションが Pod CR に存在することを確認するには、<name> を Pod の名前に置き換えて、以下のコマンドを入力します。

   $ oc get pod <name> -o yaml

   以下の例では、example-pod Pod が追加ネットワークの net1 に割り当てられています。

   $ oc get pod example-pod -o yaml
   apiVersion: v1
   kind: Pod
   metadata:
     annotations:
       k8s.v1.cni.cncf.io/networks: macvlan-bridge
       k8s.v1.cni.cncf.io/networks-status: |- 1
         [{
             "name": "openshift-sdn",
             "interface": "eth0",
             "ips": [
                 "10.128.2.14"
             ],
             "default": true,
             "dns": {}
         },{
             "name": "macvlan-bridge",
             "interface": "net1",
             "ips": [
                 "20.2.2.100"
             ],
             "mac": "22:2f:60:a5:f8:00",
             "dns": {}
         }]
     name: example-pod
     namespace: default
   spec:
     ...
   status:
     ...

   1

   k8s.v1.cni.cncf.io/networks-status パラメーターは、オブジェクトの JSON 配列です。各オブジェクトは、Pod に割り当てられる追加のネットワークのステータスについて説明します。アノテーションの値はプレーンテキストの値として保存されます。

1. 以下のコマンドを実行して CNO CR を編集します。

   $ oc edit networks.operator.openshift.io cluster

2. 以下のサンプル CR のように、作成される追加ネットワークの設定を追加して、作成している CR を変更します。

   以下の YAML はブリッジ CNI プラグインを設定します。

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     additionalNetworks: 1
     - name: test-network-1
       namespace: test-1
       type: Raw
       rawCNIConfig: '{
         "cniVersion": "0.3.1",
         "name": "test-network-1",
         "type": "bridge",
         "ipam": {
           "type": "static",
           "addresses": [
             {
               "address": "191.168.1.23/24"
             }
           ]
         }
       }'

   1

   追加ネットワーク割り当て定義の設定を指定します。

3. 変更を保存し、テキストエディターを終了して、変更をコミットします。

4. オプション: 以下のコマンドを実行して、CNO が NetworkAttachmentDefinition オブジェクトを作成していることを確認します。CNO が CR を作成するまでに遅延が生じる可能性があります。

   $ oc get network-attachment-definitions -n <namespace>

   出力例

   NAME                 AGE
   test-network-1       14m

1. 以下のコマンドを実行して CNO CR を編集します。

   $ oc edit networks.operator.openshift.io cluster

2. 以下のサンプル CR のように、作成される追加ネットワークの設定を追加して、作成している CR を変更します。

   以下の YAML は、macvlan CNI プラグインを設定します。

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     additionalNetworks: 1
     - name: test-network-1
       namespace: test-1
       type: SimpleMacvlan
       simpleMacvlanConfig:
         ipamConfig:
           type: static
           staticIPAMConfig:
             addresses:
             - address: 10.1.1.7/24

   1

   追加ネットワーク割り当て定義の設定を指定します。

3. 変更を保存し、テキストエディターを終了して、変更をコミットします。

4. オプション: 以下のコマンドを実行して、CNO が NetworkAttachmentDefinition オブジェクトを作成していることを確認します。CNO が CR を作成するまでに遅延が生じる可能性があります。

   $ oc get network-attachment-definitions -n <namespace>

   出力例

   NAME                 AGE
   test-network-1       14m

1. 以下のコマンドを実行して CNO CR を編集します。

   $ oc edit networks.operator.openshift.io cluster

2. 以下のサンプル CR のように、作成される追加ネットワークの設定を追加して、作成している CR を変更します。

   以下の YAML は IPVLAN CNI プラグインを設定します。

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     additionalNetworks: 1
     - name: test-network-1
       namespace: test-1
       type: Raw
       rawCNIConfig: '{
         "cniVersion": "0.3.1",
         "name": "test-network-1",
         "type": "ipvlan",
         "master": "eth1",
         "mode": "l2",
         "ipam": {
           "type": "static",
           "addresses": [
             {
               "address": "191.168.1.23/24"
             }
           ]
         }
       }'

   1

   追加ネットワーク割り当て定義の設定を指定します。

3. 変更を保存し、テキストエディターを終了して、変更をコミットします。

4. オプション: 以下のコマンドを実行して、CNO が NetworkAttachmentDefinition オブジェクトを作成していることを確認します。CNO が CR を作成するまでに遅延が生じる可能性があります。

   $ oc get network-attachment-definitions -n <namespace>

   出力例

   NAME                 AGE
   test-network-1       14m

1. 以下のコマンドを実行して CNO CR を編集します。

   $ oc edit networks.operator.openshift.io cluster

2. 以下のサンプル CR のように、作成される追加ネットワークの設定を追加して、作成している CR を変更します。

   以下の YAML は、ホストデバイス CNI プラグインを設定します。

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     additionalNetworks: 1
     - name: test-network-1
       namespace: test-1
       type: Raw
       rawCNIConfig: '{
         "cniVersion": "0.3.1",
         "name": "test-network-1",
         "type": "host-device",
         "device": "eth1"
       }'

   1

   追加ネットワーク割り当て定義の設定を指定します。

3. 変更を保存し、テキストエディターを終了して、変更をコミットします。

4. オプション: 以下のコマンドを実行して、CNO が NetworkAttachmentDefinition オブジェクトを作成していることを確認します。CNO が CR を作成するまでに遅延が生じる可能性があります。

   $ oc get network-attachment-definitions -n <namespace>

   出力例

   NAME                 AGE
   test-network-1       14m

1. 以下のコマンドを実行し、デフォルトのテキストエディターで Cluster Network Operator (CNO) CR を編集します。

   $ oc edit networks.operator.openshift.io cluster

2. additionalNetworks コレクションで、追加ネットワークを変更内容で更新します。
3. 変更を保存し、テキストエディターを終了して、変更をコミットします。

4. オプション: 以下のコマンドを実行して、CNO が NetworkAttachmentDefinition オブジェクトを更新していることを確認します。<network-name> を表示する追加ネットワークの名前に置き換えます。CNO が NetworkAttachmentDefinition オブジェクトを更新して変更内容が反映されるまでに遅延が生じる可能性があります。

   $ oc get network-attachment-definitions <network-name> -o yaml

   たとえば、以下のコンソールの出力は net1 という名前の NetworkAttachmentDefinition オブジェクトを表示します。

   $ oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'
   { "cniVersion": "0.3.1", "type": "macvlan",
   "master": "ens5",
   "mode": "bridge",
   "ipam":       {"type":"static","routes":[{"dst":"0.0.0.0/0","gw":"10.128.2.1"}],"addresses":[{"address":"10.128.2.100/23","gateway":"10.128.2.1"}],"dns":{"nameservers":["172.30.0.10"],"domain":"us-west-2.compute.internal","search":["us-west-2.compute.internal"]}} }

1. 以下のコマンドを実行して、デフォルトのテキストエディターで Cluster Network Operator (CNO) を編集します。

   $ oc edit networks.operator.openshift.io cluster

2. 削除しているネットワーク割り当て定義の additionalNetworks コレクションから設定を削除し、CR を変更します。

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     additionalNetworks: [] 1

   1

   additionalNetworks コレクションの追加ネットワーク割り当てのみの設定マッピングを削除する場合、空のコレクションを指定する必要があります。

3. 変更を保存し、テキストエディターを終了して、変更をコミットします。

4. オプション: 以下のコマンドを実行して、追加ネットワーク CR が削除されていることを確認します。

   $ oc get network-attachment-definition --all-namespaces

手順

1. 以下の PtpConfig CR を作成してから、YAML を <name>-ptp-config.yaml ファイルに保存します。<name> をこの設定の名前に置き換えます。

   apiVersion: ptp.openshift.io/v1
   kind: PtpConfig
   metadata:
     name: <name> 1
     namespace: openshift-ptp 2
   spec:
     profile: 3
     - name: "profile1" 4
       interface: "ens787f1" 5
       ptp4lOpts: "-s -2" 6
       phc2sysOpts: "-a -r" 7
     recommend: 8
     - profile: "profile1" 9
       priority: 10 10
       match: 11
       - nodeLabel: "node-role.kubernetes.io/worker" 12
         nodeName: "dev-worker-0" 13

   1

   PtpConfig CR の名前を指定します。

   2

   PTP Operator がインストールされている namespace を指定します。

   3

   1 つ以上の profile オブジェクトの配列を指定します。

   4

   プロファイルオブジェクトを一意に識別するために使用されるプロファイルオブジェクトの名前を指定します。

   5

   ptp4l サービスで使用するネットワークインターフェイス名を指定します (例: ens787f1)。

   6

   ptp4l サービスのシステム設定オプション (例: -s -2) を指定します。これには、インターフェイス名 -i <interface> およびサービス設定ファイル -f /etc/ptp4l.conf を含めないでください。これらは自動的に追加されます。

   7

   phc2sys サービスのシステム設定オプション (例: -a -r) を指定します。

   8

   profile がノードに適用される方法を定義する 1 つ以上の recommend オブジェクトの配列を指定します。

   9

   profile セクションに定義される profile オブジェクト名を指定します。

   10

   0 から 99 までの整数値で priority を指定します。数値が大きいほど優先度が低くなるため、99 の優先度は 10 よりも低くなります。ノードが match フィールドで定義されるルールに基づいて複数のプロファイルに一致する場合、優先順位の高い プロファイルがそのノードに適用されます。

   11

   match ルールを、nodeLabel または nodeName で指定します。

   12

   nodeLabel を、ノードオブジェクトの node.Labels の key で指定します。

   13

   nodeName をノードオブジェクトの node.Name で指定します。

2. 以下のコマンドを実行して CR を作成します。

   $ oc create -f <filename> 1

   1

   <filename> を、先の手順で作成したファイルの名前に置き換えます。

3. オプション: PtpConfig プロファイルが、 nodeLabel または nodeName に一致するノードに適用されることを確認します。

   $ oc get pods -n openshift-ptp -o wide

   出力例

   NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE           NOMINATED NODE   READINESS GATES
   linuxptp-daemon-4xkbb           1/1     Running   0          43m   192.168.111.15   dev-worker-0   <none>           <none>
   linuxptp-daemon-tdspf           1/1     Running   0          43m   192.168.111.11   dev-master-0   <none>           <none>
   ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.128.0.116     dev-master-0   <none>           <none>
   
   $ oc logs linuxptp-daemon-4xkbb -n openshift-ptp
   I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
   I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
   I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
   I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1 1
   I1115 09:41:17.117616 4143292 daemon.go:102] Interface: ens787f1    2
   I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -s -2       3
   I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r     4
   I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------
   I1115 09:41:18.117934 4143292 daemon.go:186] Starting phc2sys...
   I1115 09:41:18.117985 4143292 daemon.go:187] phc2sys cmd: &{Path:/usr/sbin/phc2sys Args:[/usr/sbin/phc2sys -a -r] Env:[] Dir: Stdin:<nil> Stdout:<nil> Stderr:<nil> ExtraFiles:[] SysProcAttr:<nil> Process:<nil> ProcessState:<nil> ctx:<nil> lookPathErr:<nil> finished:false childFiles:[] closeAfterStart:[] closeAfterWait:[] goroutine:[] errch:<nil> waitDone:<nil>}
   I1115 09:41:19.118175 4143292 daemon.go:186] Starting ptp4l...
   I1115 09:41:19.118209 4143292 daemon.go:187] ptp4l cmd: &{Path:/usr/sbin/ptp4l Args:[/usr/sbin/ptp4l -m -f /etc/ptp4l.conf -i ens787f1 -s -2] Env:[] Dir: Stdin:<nil> Stdout:<nil> Stderr:<nil> ExtraFiles:[] SysProcAttr:<nil> Process:<nil> ProcessState:<nil> ctx:<nil> lookPathErr:<nil> finished:false childFiles:[] closeAfterStart:[] closeAfterWait:[] goroutine:[] errch:<nil> waitDone:<nil>}
   ptp4l[102189.864]: selected /dev/ptp5 as PTP clock
   ptp4l[102189.886]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
   ptp4l[102189.886]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE

   1

   Profile Name は、ノード dev-worker-0 に適用される名前です。

   2

   Interface は、profile1 インターフェイスフィールドに指定される PTP デバイスです。ptp4l サービスはこのインターフェイスで実行されます。

   3

   PTP4lOpts は、profile1 Ptp4lOpts フィールドで指定される ptp4l sysconfig オプションです。

   4

   phc2sysOpts は、profile1 phc2sysOpts フィールドで指定される phc2sys sysconfig オプションです。

手順

1. SriovNetworkNodePolicy オブジェクトを作成してから、YAML を <name>-sriov-node-network.yaml ファイルに保存します。<name> をこの設定の名前に置き換えます。

2. SriovNetworkNodePolicy CR を作成します。

   $ oc create -f <name>-sriov-node-network.yaml

   ここで、<name> はこの設定の名前を指定します。

   設定の更新が適用された後に、sriov-network-operator namespace のすべての Pod が Running ステータスに移行します。

3. SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。<node_name> を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。

   $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'

手順

1. SriovNetwork オブジェクトを作成してから、YAML を <name>.yaml ファイルに保存します。<name> はこの追加ネットワークの名前になります。オブジェクト仕様は以下の例のようになります。

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetwork
   metadata:
     name: attach1
     namespace: openshift-sriov-network-operator
   spec:
     resourceName: net1
     networkNamespace: project2
     ipam: |-
     {
       "type": "host-local",
       "subnet": "10.56.217.0/24",
       "rangeStart": "10.56.217.171",
       "rangeEnd": "10.56.217.181",
       "gateway": "10.56.217.1"
     }

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

   $ oc create -f <name>.yaml

   ここで、<name> は追加ネットワークの名前を指定します。

3. オプション: 以下のコマンドを実行して、直前の手順で作成した SriovNetwork オブジェクトに関連付けられた NetworkAttachmentDefinition オブジェクトが存在することを確認するには、以下のコマンドを入力します。<namespace> を SriovNetwork オブジェクトで指定した networkNamespace に置き換えます。

   $ oc get net-attach-def -n <namespace>

手順

1. アノテーションを Pod オブジェクトに追加します。以下のアノテーション形式のいずれかのみを使用できます。

   1. カスタマイズせずに追加ネットワークを割り当てるには、以下の形式でアノテーションを追加します。<network> を、Pod に関連付ける追加ネットワークの名前に置き換えます。

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 1

      1

      複数の追加ネットワークを指定するには、各ネットワークをコンマで区切ります。コンマの間にはスペースを入れないでください。同じ追加ネットワークを複数回指定した場合、Pod は複数のネットワークインターフェイスをそのネットワークに割り当てます。

   2. カスタマイズして追加のネットワークを割り当てるには、以下の形式でアノテーションを追加します。

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: |-
            [
              {
                "name": "<network>", 1
                "namespace": "<namespace>", 2
                "default-route": ["<default-route>"] 3
              }
            ]

      1

      NetworkAttachmentDefinition オブジェクトによって定義される追加のネットワークの名前を指定します。

      2

      NetworkAttachmentDefinition オブジェクトが定義される namespace を指定します。

      3

      オプション: 192.168.17.1 などのデフォルトルートのオーバーライドを指定します。

2. Pod を作成するには、以下のコマンドを入力します。<name> を Pod の名前に置き換えます。

   $ oc create -f <name>.yaml

3. オプション: アノテーションが Pod CR に存在することを確認するには、<name> を Pod の名前に置き換えて、以下のコマンドを入力します。

   $ oc get pod <name> -o yaml

   以下の例では、example-pod Pod が追加ネットワークの net1 に割り当てられています。

   $ oc get pod example-pod -o yaml
   apiVersion: v1
   kind: Pod
   metadata:
     annotations:
       k8s.v1.cni.cncf.io/networks: macvlan-bridge
       k8s.v1.cni.cncf.io/networks-status: |- 1
         [{
             "name": "openshift-sdn",
             "interface": "eth0",
             "ips": [
                 "10.128.2.14"
             ],
             "default": true,
             "dns": {}
         },{
             "name": "macvlan-bridge",
             "interface": "net1",
             "ips": [
                 "20.2.2.100"
             ],
             "mac": "22:2f:60:a5:f8:00",
             "dns": {}
         }]
     name: example-pod
     namespace: default
   spec:
     ...
   status:
     ...

   1

   k8s.v1.cni.cncf.io/networks-status パラメーターは、オブジェクトの JSON 配列です。各オブジェクトは、Pod に割り当てられる追加のネットワークのステータスについて説明します。アノテーションの値はプレーンテキストの値として保存されます。

手順

1. 以下の SR-IOV Pod 仕様を作成してから、YAML を <name>-sriov-pod.yaml ファイルに保存します。<name> をこの Pod の名前に置き換えます。

   以下の例は、SR-IOV Pod 仕様を示しています。

   apiVersion: v1
   kind: Pod
   metadata:
     name: sample-pod
     annotations:
       k8s.v1.cni.cncf.io/networks: <name> 1
   spec:
     containers:
     - name: sample-container
       image: <image> 2
       command: ["sleep", "infinity"]
       resources:
         limits:
           memory: "1Gi" 3
           cpu: "2" 4
         requests:
           memory: "1Gi"
           cpu: "2"

   1

   <name> を、SR-IOV ネットワーク割り当て定義 CR の名前に置き換えます。

   2

   <image> を sample-pod イメージの名前に置き換えます。

   3

   Guaranteed QoS を指定して SR-IOV Pod を作成するには、メモリー要求 に等しい メモリー制限 を設定します。

   4

   Guaranteed QoS を指定して SR-IOV Pod を作成するには、cpu 要求 に等しい cpu 制限 を設定します。

2. 以下のコマンドを実行して SR-IOV Pod のサンプルを作成します。

   $ oc create -f <filename> 1

   1

   <filename> を、先の手順で作成したファイルの名前に置き換えます。

3. sample-pod が Guaranteed QoS を指定して設定されていることを確認します。

   $ oc describe pod sample-pod

4. sample-pod が排他的 CPU を指定して割り当てられていることを確認します。

   $ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus

5. sample-pod に割り当てられる SR-IOV デバイスと CPU が同じ NUMA ノード上にあることを確認します。

   $ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus

手順

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

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetworkNodePolicy
   metadata:
     name: policy-example
     namespace: openshift-sriov-network-operator
   spec:
     resourceName: example
     nodeSelector:
       feature.node.kubernetes.io/network-sriov.capable: "true"
     numVfs: 4
     nicSelector:
       vendor: "8086"
       pfNames: ['ens803f0']
       rootDevices: ['0000:86:00.0']

2. SriovNetwork オブジェクトを作成します。

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetwork
   metadata:
     name: net-example
     namespace: openshift-sriov-network-operator
   spec:
     networkNamespace: default
     ipam: | 1
       {
         "type": "host-local", 2
         "subnet": "10.56.217.0/24",
         "rangeStart": "10.56.217.171",
         "rangeEnd": "10.56.217.181",
         "routes": [
           {"dst": "224.0.0.0/5"},
           {"dst": "232.0.0.0/5"}
         ],
         "gateway": "10.56.217.1"
       }
     resourceName: example

   1 2

   DHCP を IPAM として設定する選択をした場合は、DHCP サーバー経由でデフォルトルート (224.0.0.0/5 および 232.0.0.0/5) をプロビジョニングするようにしてください。これにより、デフォルトのネットワークプロバイダーによって設定された静的なマルチキャストルートが上書きされます。

3. マルチキャストアプリケーションで Pod を作成します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: testpmd
     namespace: default
     annotations:
       k8s.v1.cni.cncf.io/networks: nic1
   spec:
     containers:
     - name: example
       image: rhel7:latest
       securityContext:
         capabilities:
           add: ["NET_ADMIN"] 1
       command: [ "sleep", "infinity"]

   1

   NET_ADMIN 機能は、アプリケーションがマルチキャスト IP アドレスを SR-IOV インターフェイスに割り当てる必要がある場合にのみ必要です。それ以外の場合は省略できます。

手順

1. 以下の SriovNetworkNodePolicy オブジェクトを作成してから、YAML を intel-dpdk-node-policy.yaml ファイルに保存します。

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetworkNodePolicy
   metadata:
     name: intel-dpdk-node-policy
     namespace: openshift-sriov-network-operator
   spec:
     resourceName: intelnics
     nodeSelector:
       feature.node.kubernetes.io/network-sriov.capable: "true"
     priority: <priority>
     numVfs: <num>
     nicSelector:
       vendor: "8086"
       deviceID: "158b"
       pfNames: ["<pf_name>", ...]
       rootDevices: ["<pci_bus_id>", "..."]
     deviceType: vfio-pci 1

   1

   仮想機能 (VF) のドライバータイプを vfio-pci に指定します。

   注記

   SriovNetworkNodePolicy の各オプションに関する詳細は、SR-IOV ネットワークデバイスの設定 セクションを参照してください。

   SriovNetworkNodePolicy オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。設定の変更が適用されるまでに数分の時間がかかる場合があります。エビクトされたワークロードを処理するために、クラスター内に利用可能なノードが十分にあることを前もって確認します。

   設定の更新が適用された後に、openshift-sriov-network-operator namespace のすべての Pod が Running ステータスに変更されます。

2. 以下のコマンドを実行して SriovNetworkNodePolicy オブジェクトを作成します。

   $ oc create -f intel-dpdk-node-policy.yaml

3. 以下の SriovNetwork オブジェクトを作成してから、YAML を intel-dpdk-network.yaml ファイルに保存します。

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetwork
   metadata:
     name: intel-dpdk-network
     namespace: openshift-sriov-network-operator
   spec:
     networkNamespace: <target_namespace>
     ipam: "{}" 1
     vlan: <vlan>
     resourceName: intelnics

   1

   IPAM CNI プラグインの空のオブジェクト "{}" を指定します。DPDK はユーザー空間モードで機能し、IP アドレスは必要ありません。

   注記

   SriovNetwork の各オプションに関する詳細は、SR-IOV の追加ネットワークの設定 セクションを参照してください。

4. 以下のコマンドを実行して SriovNetworkNodePolicy オブジェクトを作成します。

   $ oc create -f intel-dpdk-network.yaml

5. 以下の Pod 仕様を作成してから、YAML を intel-dpdk-pod.yaml ファイルに保存します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: dpdk-app
     namespace: <target_namespace> 1
     annotations:
       k8s.v1.cni.cncf.io/networks: intel-dpdk-network
   spec:
     containers:
     - name: testpmd
       image: <DPDK_image> 2
       securityContext:
        capabilities:
           add: ["IPC_LOCK"] 3
       volumeMounts:
       - mountPath: /dev/hugepages 4
         name: hugepage
       resources:
         limits:
           openshift.io/intelnics: "1" 5
           memory: "1Gi"
           cpu: "4" 6
           hugepages-1Gi: "4Gi" 7
         requests:
           openshift.io/intelnics: "1"
           memory: "1Gi"
           cpu: "4"
           hugepages-1Gi: "4Gi"
       command: ["sleep", "infinity"]
     volumes:
     - name: hugepage
       emptyDir:
         medium: HugePages

   1

   SriovNetwork オブジェクトの intel-dpdk-network が作成される同じ target_namespace を指定します。Pod を異なる namespace に作成する場合、target_namespace を Pod 仕様および SriovNetowrk オブジェクトの両方で変更します。

   2

   アプリケーションとアプリケーションが使用する DPDK ライブラリーが含まれる DPDK イメージを指定します。

   3

   コンテナー内の hugepage メモリーを割り当てるためにアプリケーションが必要とする IPC_LOCK 機能を指定します。

   4

   hugepage ボリュームを、/dev/hugepages の下にある DPDK Pod にマウントします。hugepage ボリュームは、medium が Hugepages に指定されている emptyDir ボリュームタイプでサポートされます。

   5

   オプション: DPDK Pod に割り当てられる DPDK デバイスの数を指定します。このリソース要求および制限は、明示的に指定されていない場合、SR-IOV ネットワークリソースインジェクターによって自動的に追加されます。SR-IOV ネットワークリソースインジェクターは、SR-IOV Operator によって管理される受付コントローラーコンポーネントです。これはデフォルトで有効にされており、デフォルト SriovOperatorConfig CR で enableInjector オプションを false に設定して無効にすることができます。

   6

   CPU の数を指定します。DPDK Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これは、CPU マネージャーポリシーを static に設定し、Guaranteed QoS を持つ Pod を作成して実行されます。

   7

   hugepage サイズ hugepages-1Gi または hugepages-2Mi を指定し、DPDK Pod に割り当てられる hugepage の量を指定します。2Mi および 1Gi hugepage を別々に設定します。1Gi hugepage を設定するには、カーネル引数をノードに追加する必要があります。たとえば、カーネル引数 default_hugepagesz=1GB、hugepagesz=1G および hugepages=16 を追加すると、16*1Gi hugepage がシステムの起動時に割り当てられます。

6. 以下のコマンドを実行して DPDK Pod を作成します。

   $ oc create -f intel-dpdk-pod.yaml

手順

1. 以下の SriovNetworkNodePolicy オブジェクトを作成してから、YAML を mlx-dpdk-node-policy.yaml ファイルに保存します。

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetworkNodePolicy
   metadata:
     name: mlx-dpdk-node-policy
     namespace: openshift-sriov-network-operator
   spec:
     resourceName: mlxnics
     nodeSelector:
       feature.node.kubernetes.io/network-sriov.capable: "true"
     priority: <priority>
     numVfs: <num>
     nicSelector:
       vendor: "15b3"
       deviceID: "1015" 1
       pfNames: ["<pf_name>", ...]
       rootDevices: ["<pci_bus_id>", "..."]
     deviceType: netdevice 2
     isRdma: true 3

   1

   SR-IOV ネットワークデバイスのデバイス 16 進コードを指定します。Mellanox カードに許可される値は 1015、1017 です。

   2

   Virtual Function (VF) のドライバータイプを netdevice に指定します。Mellanox SR-IOV VF は、vfio-pci デバイスタイプを使用せずに DPDK モードで機能します。VF デバイスは、コンテナー内のカーネルネットワークインターフェイスとして表示されます。

   3

   RDMA モードを有効にします。これは、DPDK モードで機能するために Mellanox カードで必要とされます。

   注記

   SriovNetworkNodePolicy の各オプションに関する詳細は、SR-IOV ネットワークデバイスの設定 セクションを参照してください。

   SriovNetworkNodePolicy オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。設定の変更が適用されるまでに数分の時間がかかる場合があります。エビクトされたワークロードを処理するために、クラスター内に利用可能なノードが十分にあることを前もって確認します。

   設定の更新が適用された後に、openshift-sriov-network-operator namespace のすべての Pod が Running ステータスに変更されます。

2. 以下のコマンドを実行して SriovNetworkNodePolicy オブジェクトを作成します。

   $ oc create -f mlx-dpdk-node-policy.yaml

3. 以下の SriovNetwork オブジェクトを作成してから、YAML を mlx-dpdk-network.yaml ファイルに保存します。

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetwork
   metadata:
     name: mlx-dpdk-network
     namespace: openshift-sriov-network-operator
   spec:
     networkNamespace: <target_namespace>
     ipam: |- 1
       ...
     vlan: <vlan>
     resourceName: mlxnics

   1

   IPAM CNI プラグインの設定オブジェクトを YAML ブロックスケーラーとして指定します。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。

   注記

   SriovNetwork の各オプションに関する詳細は、SR-IOV の追加ネットワークの設定 セクションを参照してください。

4. 以下のコマンドを実行して SriovNetworkNodePolicy オブジェクトを作成します。

   $ oc create -f mlx-dpdk-network.yaml

5. 以下の Pod 仕様を作成してから、YAML を mlx-dpdk-pod.yaml ファイルに保存します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: dpdk-app
     namespace: <target_namespace> 1
     annotations:
       k8s.v1.cni.cncf.io/networks: mlx-dpdk-network
   spec:
     containers:
     - name: testpmd
       image: <DPDK_image> 2
       securityContext:
        capabilities:
           add: ["IPC_LOCK","NET_RAW"] 3
       volumeMounts:
       - mountPath: /dev/hugepages 4
         name: hugepage
       resources:
         limits:
           openshift.io/mlxnics: "1" 5
           memory: "1Gi"
           cpu: "4" 6
           hugepages-1Gi: "4Gi" 7
         requests:
           openshift.io/mlxnics: "1"
           memory: "1Gi"
           cpu: "4"
           hugepages-1Gi: "4Gi"
       command: ["sleep", "infinity"]
     volumes:
     - name: hugepage
       emptyDir:
         medium: HugePages

   1

   SriovNetwork オブジェクトの mlx-dpdk-network が作成される同じ target_namespace を指定します。Pod を異なる namespace に作成する場合、target_namespace を Pod 仕様および SriovNetowrk オブジェクトの両方で変更します。

   2

   アプリケーションとアプリケーションが使用する DPDK ライブラリーが含まれる DPDK イメージを指定します。

   3

   コンテナー内の hugepage メモリーを割り当てるためにアプリケーションが必要とする IPC_LOCK 機能、およびアプリケーションがネットワークインターフェイスにアクセスするために NET_RAW を指定します。

   4

   hugepage ボリュームを、/dev/hugepages の下にある DPDK Pod にマウントします。hugepage ボリュームは、medium が Hugepages に指定されている emptyDir ボリュームタイプでサポートされます。

   5

   オプション: DPDK Pod に割り当てられる DPDK デバイスの数を指定します。このリソース要求および制限は、明示的に指定されていない場合、SR-IOV ネットワークリソースインジェクターによって自動的に追加されます。SR-IOV ネットワークリソースインジェクターは、SR-IOV Operator によって管理される受付コントローラーコンポーネントです。これはデフォルトで有効にされており、デフォルト SriovOperatorConfig CR で enableInjector オプションを false に設定して無効にすることができます。

   6

   CPU の数を指定します。DPDK Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これは、CPU マネージャーポリシーを static に設定し、Guaranteed QoS を持つ Pod を作成して実行されます。

   7

   hugepage サイズ hugepages-1Gi または hugepages-2Mi を指定し、DPDK Pod に割り当てられる hugepage の量を指定します。2Mi および 1Gi hugepage を別々に設定します。1Gi hugepage を設定するには、カーネル引数をノードに追加する必要があります。

6. 以下のコマンドを実行して DPDK Pod を作成します。

   $ oc create -f mlx-dpdk-pod.yaml

手順

1. 以下の SriovNetworkNodePolicy オブジェクトを作成してから、YAML を mlx-rdma-node-policy.yaml ファイルに保存します。

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetworkNodePolicy
   metadata:
     name: mlx-rdma-node-policy
     namespace: openshift-sriov-network-operator
   spec:
     resourceName: mlxnics
     nodeSelector:
       feature.node.kubernetes.io/network-sriov.capable: "true"
     priority: <priority>
     numVfs: <num>
     nicSelector:
       vendor: "15b3"
       deviceID: "1015" 1
       pfNames: ["<pf_name>", ...]
       rootDevices: ["<pci_bus_id>", "..."]
     deviceType: netdevice 2
     isRdma: true 3

   1

   SR-IOV ネットワークデバイスのデバイス 16 進コードを指定します。Mellanox カードに許可される値は 1015、1017 です。

   2

   Virtual Function (VF) のドライバータイプを netdevice に指定します。

   3

   RDMA モードを有効にします。

   注記

   SriovNetworkNodePolicy の各オプションに関する詳細は、SR-IOV ネットワークデバイスの設定 セクションを参照してください。

   SriovNetworkNodePolicy オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。設定の変更が適用されるまでに数分の時間がかかる場合があります。エビクトされたワークロードを処理するために、クラスター内に利用可能なノードが十分にあることを前もって確認します。

   設定の更新が適用された後に、openshift-sriov-network-operator namespace のすべての Pod が Running ステータスに変更されます。

2. 以下のコマンドを実行して SriovNetworkNodePolicy オブジェクトを作成します。

   $ oc create -f mlx-rdma-node-policy.yaml

3. 以下の SriovNetwork オブジェクトを作成してから、YAML を mlx-rdma-network.yaml ファイルに保存します。

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetwork
   metadata:
     name: mlx-rdma-network
     namespace: openshift-sriov-network-operator
   spec:
     networkNamespace: <target_namespace>
     ipam: |- 1
       ...
     vlan: <vlan>
     resourceName: mlxnics

   1

   IPAM CNI プラグインの設定オブジェクトを YAML ブロックスケーラーとして指定します。プラグインは、割り当て定義についての IP アドレスの割り当てを管理します。

   注記

   SriovNetwork の各オプションに関する詳細は、SR-IOV の追加ネットワークの設定 セクションを参照してください。

4. 以下のコマンドを実行して SriovNetworkNodePolicy オブジェクトを作成します。

   $ oc create -f mlx-rdma-network.yaml

5. 以下の Pod 仕様を作成してから、YAML を mlx-rdma-pod.yaml ファイルに保存します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: rdma-app
     namespace: <target_namespace> 1
     annotations:
       k8s.v1.cni.cncf.io/networks: mlx-rdma-network
   spec:
     containers:
     - name: testpmd
       image: <RDMA_image> 2
       securityContext:
        capabilities:
           add: ["IPC_LOCK"] 3
       volumeMounts:
       - mountPath: /dev/hugepages 4
         name: hugepage
       resources:
         limits:
           memory: "1Gi"
           cpu: "4" 5
           hugepages-1Gi: "4Gi" 6
         requests:
           memory: "1Gi"
           cpu: "4"
           hugepages-1Gi: "4Gi"
       command: ["sleep", "infinity"]
     volumes:
     - name: hugepage
       emptyDir:
         medium: HugePages

   1

   SriovNetwork オブジェクトの mlx-rdma-network が作成される同じ target_namespace を指定します。Pod を異なる namespace に作成する場合、target_namespace を Pod 仕様および SriovNetowrk オブジェクトの両方で変更します。

   2

   アプリケーションとアプリケーションが使用する RDMA ライブラリーが含まれる RDMA イメージを指定します。

   3

   コンテナー内の hugepage メモリーを割り当てるためにアプリケーションが必要とする IPC_LOCK 機能を指定します。

   4

   hugepage ボリュームを、/dev/hugepages の下にある RDMA Pod にマウントします。hugepage ボリュームは、medium が Hugepages に指定されている emptyDir ボリュームタイプでサポートされます。

   5

   CPU の数を指定します。RDMA Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これは、CPU マネージャーポリシーを static に設定し、Guaranteed QoS を持つ Pod を作成して実行されます。

   6

   hugepage サイズ hugepages-1Gi または hugepages-2Mi を指定し、RDMA Pod に割り当てられる hugepage の量を指定します。2Mi および 1Gi hugepage を別々に設定します。1Gi hugepage を設定するには、カーネル引数をノードに追加する必要があります。

6. 以下のコマンドを実行して RDMA Pod を作成します。

   $ oc create -f mlx-rdma-pod.yaml

手順

1. 以下の JSON を使用して、NetNamespace オブジェクトを egress IP アドレスで更新します。

    $ oc patch netnamespace <project_name> --type=merge -p \ 1
     '{
       "egressIPs": [
         "<ip_address>" 2
       ]
     }'

   1

   プロジェクトのターゲットを指定します。

   2

   単一 egress IP アドレスを指定します。複数の IP アドレスの使用はサポートされません。

   たとえば、project1 を IP アドレスの 192.168.1.100 に、project2 を IP アドレスの 192.168.1.101 に割り当てるには、以下を実行します。

   $ oc patch netnamespace project1 --type=merge -p \
     '{"egressIPs": ["192.168.1.100"]}'
   $ oc patch netnamespace project2 --type=merge -p \
     '{"egressIPs": ["192.168.1.101"]}'

2. 以下の JSON を使用して、各ホストの egressCIDRs パラメーターを設定して egress IP アドレスをホストできるノードを示します。

   $ oc patch hostsubnet <node_name> --type=merge -p \ 1
     '{
       "egressCIDRs": [
         "<ip_address_range_1>", "<ip_address_range_2>" 2
       ]
     }'

   1

   ノード名を指定します。

   2

   CIDR 形式で 1 つ以上の IP アドレス範囲を指定します。

   たとえば、node1 および node2 を、192.168.1.0 から 192.168.1.255 の範囲で egress IP アドレスをホストするように設定するには、以下を実行します。

   $ oc patch hostsubnet node1 --type=merge -p \
     '{"egressCIDRs": ["192.168.1.0/24"]}'
   $ oc patch hostsubnet node2 --type=merge -p \
     '{"egressCIDRs": ["192.168.1.0/24"]}'

   OpenShift Container Platform はバランスを取りながら特定の egress IP アドレスを利用可能なノードに自動的に割り当てます。この場合、egress IP アドレス 192.168.1.100 を node1 に、egress IP アドレス 192.168.1.101 を node2 に割り当て、その逆も行います。

手順

1. 以下の JSON オブジェクトを必要な IP アドレスで指定して、NetNamespace オブジェクトを更新します。

   $ oc patch netnamespace <project> --type=merge -p \ 1
     '{
       "egressIPs": [ 2
         "<ip_address>"
         ]
     }'

   1

   プロジェクトのターゲットを指定します。

   2

   1 つ以上の egress IP アドレスを指定します。egressIPs パラメーターは配列です。

   たとえば、project1 プロジェクトを 192.168.1.100 の IP アドレスに割り当てるには、以下を実行します。

   $ oc patch netnamespace project1 --type=merge \
     -p '{"egressIPs": ["192.168.1.100"]}'

   egressIPs を異なるノードの 2 つ以上の IP アドレスに設定し、高可用性を確保することができます。複数の egress IP アドレスが設定される場合、Pod は egress の一覧にある最初の IP を使用しますが、IP アドレスをホストするノードが失敗する場合、Pod は短時間の遅延の後に一覧にある次の IP の使用に切り替えます。

2. egress IP をノードホストに手動で割り当てます。egressIPs パラメーターを、ノードホストの HostSubnet オブジェクトに設定します。以下の JSON を使用して、そのノードホストに割り当てる必要のある任意の数の IP を含めることができます。

   $ oc patch hostsubnet <node_name> --type=merge -p \ 1
     '{
       "egressIPs": [ 2
         "<ip_address_1>",
         "<ip_address_N>"
         ]
     }'

   1

   ノードの名前を指定します。

   2

   1 つ以上の egress IP アドレスを指定します。egressIPs フィールドは配列です。

   たとえば、node1 に Egress IP 192.168.1.100、 192.168.1.101、および 192.168.1.102 が設定されるように指定するには、以下を実行します。

   $ oc patch hostsubnet node1 --type=merge -p \
     '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'

   直前の例では、project1 のすべての egress トラフィックは、指定された egress IP をホストするノードにルーティングされてから、その IP アドレスに (NAT を使用して) 接続されます。

手順

1. ポリシールールを作成します。

   1. <policy-name>.yaml ファイルを作成します。 この場合、<policy-name> は egress ポリシールールを記述します。
   2. 作成したファイルで、egress ポリシーオブジェクトを定義します。

2. 以下のコマンドを入力してポリシーオブジェクトを作成します。

   $ oc create -f <policy-name>.yaml -n <project>

   以下の例では、新規の EgressNetworkPolicy オブジェクトが project1 という名前のプロジェクトに作成されます。

   $ oc create -f default-rules.yaml -n project1

   出力例

   egressnetworkpolicy.network.openshift.io/default-rules created

3. オプション: 後に変更できるように <policy-name>.yaml を保存します。

1. プロジェクトの EgressNetworkPolicy オブジェクトの名前を検索します。<project> をプロジェクトの名前に置き換えます。

   $ oc get -n <project> egressnetworkpolicy

2. オプション: egress ネットワークファイアウォールの作成時に EgressNetworkPolicy オブジェクトのコピーを保存しなかった場合には、以下のコマンドを入力してコピーを作成します。

   $ oc get -n <project> \ 1
     egressnetworkpolicy <name> \ 2
     -o yaml > <filename>.yaml 3

   1

   <project> をプロジェクトの名前に置き換えます。

   2

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

   3

   <filename> をファイルの名前に置き換え、YAML を保存します。

3. 以下のコマンドを入力し、EgressNetworkPolicy オブジェクトを置き換えます。<filename> を、更新された EgressNetworkPolicy オブジェクトを含むファイルの名前に置き換えます。

   $ oc replace -f <filename>.yaml

1. プロジェクトの EgressNetworkPolicy オブジェクトの名前を検索します。<project> をプロジェクトの名前に置き換えます。

   $ oc get -n <project> egressnetworkpolicy

2. 以下のコマンドを入力し、EgressNetworkPolicy オブジェクトを削除します。<project> をプロジェクトの名前に、 <name> をオブジェクトの名前に置き換えます。

   $ oc delete -n <project> egressnetworkpolicy <name>

手順

1. egress ルーター Pod の作成

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

   apiVersion: v1
   kind: Service
   metadata:
     name: egress-1
   spec:
     ports:
     - name: http
       port: 80
     - name: https
       port: 443
     type: ClusterIP
     selector:
       name: egress-1

   Pod がこのサービスに接続できるようになります。これらの接続は、予約された egress IP アドレスを使用して外部サーバーの対応するポートにリダイレクトされます。

手順

1. egress ルーター Pod の作成

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

   apiVersion: v1
   kind: Service
   metadata:
     name: egress-1
   spec:
     ports:
     - name: http-proxy
       port: 8080 1
     type: ClusterIP
     selector:
       name: egress-1

   1

   http ポートが常に 8080 に設定されていることを確認します。

3. http_proxy または https_proxy 変数を設定して、クライアント Pod (egress プロキシー Pod ではない) を HTTP プロキシーを使用するように設定します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: app-1
     labels:
       name: app-1
   spec:
     containers:
       env:
       - name: http_proxy
         value: http://egress-1:8080/ 1
       - name: https_proxy
         value: http://egress-1:8080/
       ...

   1

   先の手順で作成したサービス。

   注記

   すべてのセットアップに http_proxy および https_proxy 環境変数が必要になる訳ではありません。上記を実行しても作業用セットアップが作成されない場合は、Pod で実行しているツールまたはソフトウェアについてのドキュメントを参照してください。

手順

1. egress ルーター Pod の作成

2. egress ルーター Pod のサービスを作成します。

   1. 以下の YAML 定義が含まれる egress-router-service.yaml という名前のファイルを作成します。spec.ports を、 EGRESS_DNS_PROXY_DESTINATION 環境変数に先に定義したポートの一覧に設定します。

      apiVersion: v1
      kind: Service
      metadata:
        name: egress-dns-svc
      spec:
        ports:
          ...
        type: ClusterIP
        selector:
          name: egress-dns-proxy

      以下に例を示します。

      apiVersion: v1
      kind: Service
      metadata:
        name: egress-dns-svc
      spec:
        ports:
        - name: con1
          protocol: TCP
          port: 80
          targetPort: 80
        - name: con2
          protocol: TCP
          port: 100
          targetPort: 100
        type: ClusterIP
        selector:
          name: egress-dns-proxy

   2. サービスを作成するには、以下のコマンドを入力します。

      $ oc create -f egress-router-service.yaml

      Pod がこのサービスに接続できるようになります。これらの接続は、予約された egress IP アドレスを使用して外部サーバーの対応するポートにプロキシー送信されます。

手順

1. 以下の例のように、egress ルーター Pod のマッピングデータが含まれるファイルを作成します。

   # Egress routes for Project "Test", version 3
   
   80   tcp 203.0.113.25
   
   8080 tcp 203.0.113.26 80
   8443 tcp 203.0.113.26 443
   
   # Fallback
   203.0.113.27

   空の行とコメントをこのファイルに追加できます。

2. このファイルから ConfigMap オブジェクトを作成します。

   $ oc delete configmap egress-routes --ignore-not-found

   $ oc create configmap egress-routes \
     --from-file=destination=my-egress-destination.txt

   直前のコマンドで、egress-routes 値は、作成する ConfigMap オブジェクトの名前で、 my-egress-destination.txt はデータの読み取り元のファイルの名前です。

3. egress ルーター Pod 定義を作成し、environment スタンザの EGRESS_DESTINATION フィールドに configMapKeyRef スタンザを指定します。

   ...
   env:
   - name: EGRESS_DESTINATION
     valueFrom:
       configMapKeyRef:
         name: egress-routes
         key: destination
   ...

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/ubi8
         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/ubi8
         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. 以下のコマンドを使用して、プロジェクトを既存のプロジェクトネットワークに参加させます。

   $ oc adm pod-network join-projects --to=<project1> <project2> <project3>

   または、特定のプロジェクト名を指定する代わりに --selector=<project_selector> オプションを使用し、関連付けられたラベルに基づいてプロジェクトを指定できます。

2. オプション: 以下のコマンドを実行し、結合した Pod ネットワークを表示します。

   $ oc get netnamespaces

   同じ Pod ネットワークのプロジェクトには、NETID 列に同じネットワーク ID があります。

手順

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

   $ oc edit network.operator.openshift.io cluster

2. 以下のサンプル CR のように、kube-proxy 設定への変更内容で、CR の kubeProxyConfig パラメーターを変更します。

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     kubeProxyConfig:
       iptablesSyncPeriod: 30s
       proxyArguments:
         iptables-min-sync-period: ["30s"]

3. ファイルを保存し、テキストエディターを編集します。

   構文は、ファイルを保存し、エディターを終了する際に oc コマンドによって検証されます。変更内容に構文エラーが含まれる場合、エディターはファイルを開き、エラーメッセージを表示します。

4. 以下のコマンドを実行して、設定の更新を確認します。

   $ oc get networks.operator.openshift.io -o yaml

   出力例

   apiVersion: v1
   items:
   - apiVersion: operator.openshift.io/v1
     kind: Network
     metadata:
       name: cluster
     spec:
       clusterNetwork:
       - cidr: 10.128.0.0/14
         hostPrefix: 23
       defaultNetwork:
         type: OpenShiftSDN
       kubeProxyConfig:
         iptablesSyncPeriod: 30s
         proxyArguments:
           iptables-min-sync-period:
           - 30s
       serviceNetwork:
       - 172.30.0.0/16
     status: {}
   kind: List

5. オプション: 以下のコマンドを実行し、Cluster Network Operator が設定変更を受け入れていることを確認します。

   $ oc get clusteroperator network

   出力例

   NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
   network   4.1.0-0.9   True        False         False      1m

   設定の更新が正常に適用されると、AVAILABLE フィールドが True になります。

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/ubi8
         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/ubi8
         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. oc annotate コマンドを使用して、ルートにタイムアウトを追加します。

   $ oc annotate route <route_name> \
       --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit> 1

   1

   サポートされる時間単位は、マイクロ秒 (us)、ミリ秒 (ms)、秒 (s)、分 (m)、時間 (h)、または日 (d) です。

   以下の例では、2 秒のタイムアウトを myroute という名前のルートに設定します。

   $ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s