複数ネットワーク

手順

1. オプション: プライマリーネットワークを使用する ClusterUserDefinedNetwork CR の場合は、次のコマンドを入力して、k8s.ovn.org/primary-user-defined-network ラベルを持つ namespace を作成します。

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     name: <cudn_namespace_name>
     labels:
       k8s.ovn.org/primary-user-defined-network: ""
   EOF

2. Layer2 または Layer3 トポロジータイプのいずれかに対してクラスター全体のユーザー定義ネットワークを作成します。

   1. Layer2 トポロジーのリクエストを定義するには、次の例のように、cluster-layer-two-udn.yaml などの YAML ファイルを作成します。

      apiVersion: k8s.ovn.org/v1
      kind: ClusterUserDefinedNetwork
      metadata:
        name: <cudn_name>
      spec:
        namespaceSelector:
          matchLabels:
            "<label_1_key>": "<label_1_value>"
            "<label_2_key>": "<label_2_value>"
        network:
          topology: Layer2
          layer2:
            role: Primary
            subnets:
              - "2001:db8::/64"
              - "10.100.0.0/16"

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

      名前

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

      namespaceSelector

      CUDN CR が適用される名前空間のセットに対するラベルクエリーを指定します。標準の Kubernetes MatchLabel セレクターを使用します。default または openshift-* namespace は指定しないでください。

      matchLabels

      matchLabels セレクタータイプを使用します。このセレクタータイプでは、用語が AND 関係で評価されます。この例では、CUDN CR は、<label_1_key>=<label_1_value> と <label_2_key>=<label_2_value> の両方のラベルを含む namespace にデプロイされます。

      network

      ネットワーク設定を記述します。

      topology

      このフィールドはネットワーク設定を記述します。許容される値は Layer2 と Layer3 です。Layer2 トポロジータイプを指定すると、すべてのノードで共有される 1 つの論理スイッチが作成されます。このフィールドは、トポロジー設定を指定します。layer2 または layer3 に指定できます。

      role

      Primary または Secondary を指定します。4.20 でサポートされる role 仕様は Primary のみです。

      subnets

      Layer2 トポロジータイプの場合、以下の項目はフィールドの設定詳細を指定します。

      • subnets フィールドは任意です。
      • subnets フィールドはタイプが string で、IPv4 と IPv6 の両方の標準 CIDR 形式を受け入れます。
      • subnets フィールドには 1 つまたは 2 つの項目を入力できます。2 つのアイテムは、異なるファミリーに属している必要があります。たとえば、subnets の値は 10.100.0.0/16 と 2001:db8::/64 です。
      • Layer2 サブネットは省略できます。省略した場合、ユーザーは Pod の静的 IP アドレスを設定する必要があります。結果として、ポートセキュリティーは MAC スプーフィングのみを防止します。詳細は、「静的 IP アドレスを使用した Pod 設定」を参照してください。

   2. Layer3 トポロジーの要求を定義するには、次の例のように、cluster-layer-three-udn.yaml などの YAML ファイルを作成します。

      apiVersion: k8s.ovn.org/v1
      kind: ClusterUserDefinedNetwork
      metadata:
        name: <cudn_name>
      spec:
        namespaceSelector:
          matchExpressions:
          - key: kubernetes.io/metadata.name
            operator: In
            values: ["<example_namespace_one>", "<example_namespace_two>"]
        network:
          topology: Layer3
          layer3:
            role: Primary
            subnets:
              - cidr: 10.100.0.0/16
                hostSubnet: 24

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

      名前

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

      namespaceSelector

      CUDN CR が適用される名前空間のセットに対するラベルクエリーを指定します。標準の Kubernetes MatchLabel セレクターを使用します。default または openshift-* namespace は指定しないでください。matchExpressions セレクタータイプを使用します。このセレクタータイプでは、用語が OR 関係で評価されます。

      Key

      照合するラベルキーを指定します。演算子の値を受け取ります。有効な値には、In、NotIn、Exists、および DoesNotExist が含まれます。matchExpressions タイプが使用されているため、<example_namespace_one> または <example_namespace_two> のいずれかに一致する namespace がプロビジョニングされます。

      network

      ネットワーク設定を記述します。

      topology

      topology フィールドはネットワーク設定を記述します。受け入れられる値は Layer2 と Layer3 です。Layer3 トポロジータイプを指定すると、ノードごとにレイヤー 2 セグメントが作成され、それぞれに異なるサブネットが割り当てられます。レイヤー 3 ルーティングは、ノードサブネットを相互接続するために使用されます。

      role

      Primary または Secondary を指定します。4.20 でサポートされる role 仕様は Primary のみです。

      subnets

      Layer3 トポロジータイプの場合、subnet フィールドの設定の詳細を次に示します。

      • subnets フィールドは必須です。

      • subnets フィールドのタイプは、cidr および hostSubnet です。

        • cidr はクラスターのサブネットであり、文字列値を受け入れます。
        • hostSubnet は、クラスターサブネットが分割されるノードサブネット接頭辞を指定します。
        • IPv6 の場合、hostSubnet では /64 の長さのみがサポートされます。

3. 次のコマンドを実行してリクエストを適用します。

   $ oc create --validate=true -f <example_cluster_udn>.yaml

   この場合の <example_cluster_udn>.yaml は Layer2 または Layer3 設定ファイルの名前です。

4. 次のコマンドを実行して、リクエストが成功したことを確認します。

   $ oc get clusteruserdefinednetwork <cudn_name> -o yaml

   この場合の <cudn_name> は、クラスター全体のユーザー定義ネットワークに作成した名前です。

   出力例

   apiVersion: k8s.ovn.org/v1
   kind: ClusterUserDefinedNetwork
   metadata:
     creationTimestamp: "2024-12-05T15:53:00Z"
     finalizers:
     - k8s.ovn.org/user-defined-network-protection
     generation: 1
     name: my-cudn
     resourceVersion: "47985"
     uid: 16ee0fcf-74d1-4826-a6b7-25c737c1a634
   spec:
     namespaceSelector:
       matchExpressions:
       - key: custom.network.selector
         operator: In
         values:
         - example-namespace-1
         - example-namespace-2
         - example-namespace-3
     network:
       layer3:
         role: Primary
         subnets:
         - cidr: 10.100.0.0/16
       topology: Layer3
   status:
     conditions:
     - lastTransitionTime: "2024-11-19T16:46:34Z"
       message: 'NetworkAttachmentDefinition has been created in following namespaces:
         [example-namespace-1, example-namespace-2, example-namespace-3]'
       reason: NetworkAttachmentDefinitionReady
       status: "True"
       type: NetworkCreated

手順

1. Localnet トポロジーを使用してクラスター全体のユーザー定義ネットワークを作成します。

   1. Localnet トポロジーのリクエストを定義するために、次の例のように、cluster-udn-localnet.yaml などの YAML ファイルを作成します。

      apiVersion: k8s.ovn.org/v1
      kind: ClusterUserDefinedNetwork
      metadata:
        name: <cudn_name>
      spec:
        namespaceSelector:
          matchLabels:
            "<label_1_key>": "<label_1_value>"
            "<label_2_key>": "<label_2_value>"
        network:
          topology: Localnet
          localnet:
            role: Secondary
            physicalNetworkName: test
            ipam: {lifecycle: Persistent}
            subnets: ["192.168.0.0/16", "2001:dbb::/64"]

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

      名前

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

      namespaceSelector

      CUDN CR が適用される名前空間のセットに対するラベルクエリーを指定します。標準の Kubernetes MatchLabel セレクターを使用します。default または openshift-* namespace は指定しないでください。

      matchLabels

      matchLabels セレクタータイプを使用します。このセレクタータイプでは、用語が AND 関係で評価されます。この例では、CUDN CR は、<label_1_key>=<alabel_1_value> と <label_2_key>=<label_2_value> の 両方のラベルを含む名前空間にデプロイされます。

      network

      ネットワーク設定を記述します。

      topology

      Localnet トポロジータイプを指定すると、1 つのプロバイダーネットワークに直接ブリッジされる 1 つの論理スイッチが作成されます。

      role

      ネットワーク設定の role を指定します。Secondary は、localnet トポロジーでサポートされる唯一の role 仕様です。

      subnets

      Localnet トポロジータイプの場合、subnet フィールドの設定の詳細を次に示します。

      • subnets フィールドは任意です。
      • subnets フィールドはタイプが string で、IPv4 と IPv6 の両方の標準 CIDR 形式を受け入れます。
      • subnets フィールドには 1 つまたは 2 つの項目を入力できます。2 つの項目の場合、異なる IP ファミリーである必要があります。たとえば、subnets の値は 10.100.0.0/16 と 2001:db8::/64 です。
      • localnet サブネットは省略できます。省略した場合、ユーザーは Pod の静的 IP アドレスを設定する必要があります。結果として、ポートセキュリティーは MAC スプーフィングのみを防止します。詳細は、「静的 IP アドレスを使用した Pod 設定」を参照してください。

2. 次のコマンドを実行してリクエストを適用します。

   $ oc create --validate=true -f <example_cluster_udn>.yaml

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

   <example_cluster_udn>.yaml

   Localnet 設定ファイルの名前です。

3. 次のコマンドを実行して、リクエストが成功したことを確認します。

   $ oc get clusteruserdefinednetwork <cudn_name> -o yaml

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

   <cudn_name>

   クラスター全体のユーザー定義ネットワークに作成した名前です。

手順

1. Administrator パースペクティブから、Networking → UserDefinedNetworks をクリックします。
2. ClusterUserDefinedNetwork をクリックします。
3. Name フィールドで、クラスタースコープの UDN の名前を指定します。
4. Subnet フィールドに値を指定します。
5. Project(s) Match Labels フィールドに適切なラベルを追加して、クラスター UDN が適用される namespace を選択します。
6. Create をクリックします。クラスタースコープの UDN は、ステップ 5 で指定したラベルを含む namespace に配置された Pod のデフォルトプライマリーネットワークとして機能します。

手順

1. オプション: プライマリーネットワークを使用する UserDefinedNetwork CR の場合は、次のコマンドを入力して、k8s.ovn.org/primary-user-defined-network ラベルを持つ namespace を作成します。

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     name: <udn_namespace_name>
     labels:
       k8s.ovn.org/primary-user-defined-network: ""
   EOF

2. Layer2 または Layer3 トポロジータイプのいずれかのユーザー定義ネットワークを作成します。

   1. Layer2 トポロジーのリクエストを定義するには、次の例のように、my-layer-two-udn.yaml などの YAML ファイルを作成します。

      apiVersion: k8s.ovn.org/v1
      kind: UserDefinedNetwork
      metadata:
        name: udn-1
        namespace: <some_custom_namespace>
      spec:
        topology: Layer2
        layer2: 

      1

      
          role: Primary
          subnets:
            - "10.0.0.0/24"
            - "2001:db8::/60"

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

      name

      UserDefinedNetwork リソースの名前。これは default にすべきではありません。また、Cluster Network Operator (CNO) によって作成されたグローバル namespace と重複してはなりません。

      topology

      ネットワーク設定を指定します。許容される値は Layer2 と Layer3 です。Layer2 トポロジータイプを指定すると、すべてのノードで共有される 1 つの論理スイッチが作成されます。

      role

      Primary ロールまたは Secondary ロールを指定します。

      subnets

      Layer2 トポロジータイプの場合、以下は subnet フィールドの設定を指定します。

      • subnets フィールドは任意です。
      • subnets フィールドはタイプが string で、IPv4 と IPv6 の両方の標準 CIDR 形式を受け入れます。
      • subnets フィールドには 1 つまたは 2 つの項目を入力できます。2 つのアイテムは、異なるファミリーに属している必要があります。たとえば、subnets の値は 10.100.0.0/16 と 2001:db8::/64 です。
      • Layer2 サブネットは省略できます。省略すると、ユーザーは Pod の IP アドレスを設定する必要があります。結果として、ポートセキュリティーは MAC スプーフィングのみを防止します。
      • ipamLifecycle フィールドが指定されている場合、Layer2subnets フィールドは必須です。

   2. Layer3 トポロジーのリクエストを定義するには、次の例のように、my-layer-three-udn.yaml などの YAML ファイルを作成します。

      apiVersion: k8s.ovn.org/v1
      kind: UserDefinedNetwork
      metadata:
        name: udn-2-primary
        namespace: <some_custom_namespace>
      spec:
        topology: Layer3
        layer3:
          role: Primary
          subnets:
            - cidr: 10.150.0.0/16
              hostSubnet: 24
            - cidr: 2001:db8::/60
              hostSubnet: 64
      # ...

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

      name

      UserDefinedNetwork リソースの名前。これは default にすべきではありません。また、Cluster Network Operator (CNO) によって作成されたグローバル namespace と重複してはなりません。

      topology

      ネットワーク設定を指定します。許容される値は Layer2 と Layer3 です。Layer2 トポロジータイプを指定すると、すべてのノードで共有される 1 つの論理スイッチが作成されます。

      role

      Primary ロールまたは Secondary ロールを指定します。

      subnets

      Layer3 トポロジータイプの場合、subnet フィールドの設定の詳細を次に示します。

      • subnets フィールドは必須です。

      • subnets フィールドのタイプは、cidr および hostSubnet です。

        • cidr は、クラスターの clusterNetwork 設定に相当します。CIDR 内の IP アドレスは、ユーザー定義ネットワーク内の Pod に配布されます。このパラメーターは文字列値を受け入れます。
        • hostSubnet は、ノードごとのサブネット接頭辞を定義します。
        • IPv6 の場合、hostSubnet では /64 の長さのみがサポートされます。

3. 次のコマンドを実行してリクエストを適用します。

   $ oc apply -f <my_layer_two_udn>.yaml

   <my_layer_two_udn>.yaml は、Layer2 または Layer3 設定ファイルの名前です。

4. 次のコマンドを実行して、リクエストが成功したことを確認します。

   $ oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml

   ここでは、some_custom_namespace は、ユーザー定義ネットワーク用に作成した namespace です。

   出力例

   apiVersion: k8s.ovn.org/v1
   kind: UserDefinedNetwork
   metadata:
     creationTimestamp: "2024-08-28T17:18:47Z"
     finalizers:
     - k8s.ovn.org/user-defined-network-protection
     generation: 1
     name: udn-1
     namespace: some-custom-namespace
     resourceVersion: "53313"
     uid: f483626d-6846-48a1-b88e-6bbeb8bcde8c
   spec:
     layer2:
       role: Primary
       subnets:
       - 10.0.0.0/24
       - 2001:db8::/60
     topology: Layer2
   status:
     conditions:
     - lastTransitionTime: "2024-08-28T17:18:47Z"
       message: NetworkAttachmentDefinition has been created
       reason: NetworkAttachmentDefinitionReady
       status: "True"
       type: NetworkCreated

手順

1. Administrator パースペクティブから、Networking → UserDefinedNetworks をクリックします。
2. Create UserDefinedNetwork をクリックします。
3. Project name リストから、以前に作成した namespace を選択します。
4. Subnet フィールドに値を指定します。
5. Create をクリックします。ユーザー定義ネットワークは、この namespace で作成する Pod のデフォルトのプライマリーネットワークとして機能します。

手順

1. Pod リソース定義を編集します。既存の Pod リソースを編集する場合は、以下のコマンドを実行してデフォルトエディターでその定義を編集します。<name> を、編集する Pod リソースの名前に置き換えます。

   $ oc edit pod <name>

2. Pod リソース定義で、k8s.v1.cni.cncf.io/networks パラメーターを Pod の metadata マッピングに追加します。k8s.v1.cni.cncf.io/networks は、追加のプロパティーを指定するだけでなく、NetworkAttachmentDefinition カスタムリソース (CR) 名を参照するオブジェクトリストの JSON 文字列を受け入れます。

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

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

   <network>

   次の例に示すように、JSON オブジェクトに置き換えます。一重引用符が必要です。

   次の例では、アノテーション内で default-route パラメーターを使用して、デフォルトルートを持つネットワークアタッチメントを指定しています。

   apiVersion: v1
   kind: Pod
   metadata:
     name: example-pod
     annotations:
       k8s.v1.cni.cncf.io/networks: '[
       {
         "name": "net1"
       },
       {
         "name": "net2",
         "default-route": ["192.0.2.1"]
       }]'
   spec:
     containers:
     - name: example-pod
       command: ["/bin/bash", "-c", "sleep 2000000000000"]
       image: centos/tools

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

   net1、net2

   Pod に関連付けるセカンダリーネットワークを定義する NetworkAttachmentDefinition リソースの名前を指定します。

   192.0.2.1

   ルーティングテーブルに他のルーティングテーブルがない場合に、ルーティングされるトラフィックに使用されるゲートウェイ値を指定します。複数の default-route キーを指定すると、Pod がアクティブでなくなります。

   デフォルトのルートにより、他のルートに指定されていないトラフィックがゲートウェイにルーティングされます。

   重要

   OpenShift Container Platform のデフォルトのネットワークインターフェイス以外のインターフェイスへのデフォルトのルートを設定すると、Pod 間のトラフィックに予想されるトラフィックが別のインターフェイスでルーティングされる可能性があります。

   Pod のルーティングプロパティーを確認する場合、oc コマンドを Pod 内で ip コマンドを実行するために使用できます。

   $ oc exec -it <pod_name> -- ip route

   注記

   また、Pod の k8s.v1.cni.cncf.io/network-status を参照して、JSON 形式のオブジェクトリスト内の default-route キーの存在によって、どのセカンダリーネットワークにデフォルトルートが割り当てられているかを確認することもできます。

   Pod に静的 IP アドレスまたは MAC アドレスを設定するには、JSON 形式のアノテーションを使用できます。これには、この機能をとくに許可するネットワークを作成する必要があります。これは、CNO の rawCNIConfig で指定できます。

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

   $ oc edit networks.operator.openshift.io cluster

   以下の YAML は、CNO の設定パラメーターを説明しています。

   Cluster Network Operator YAML の設定

   name: <name>
   namespace: <namespace>
   rawCNIConfig: '{
     ...
   }'
   type: Raw

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

   name

   作成するセカンダリーネットワークアタッチメントの名前を指定します。名前は指定された namespace 内で一意である必要があります。

   namespace

   ネットワークアタッチメントの作成先とする namespace を指定します。値を指定しない場合、default の namespace が使用されます。

   rawCNIConfig

   以下のテンプレートに基づく CNI プラグイン設定を JSON 形式で指定します。

   以下のオブジェクトは、macvlan CNI プラグインを使用して静的 MAC アドレスと IP アドレスを使用するための設定パラメーターを説明しています。

   静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト

   {
     "cniVersion": "0.3.1",
     "name": "<name>",
     "plugins": [{
         "type": "macvlan",
         "capabilities": { "ips": true },
         "master": "eth0",
         "mode": "bridge",
         "ipam": {
           "type": "static"
         }
       }, {
         "capabilities": { "mac": true },
         "type": "tuning"
       }]
   }

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

   name

   作成するセカンダリーネットワークアタッチメントの名前を指定します。名前は指定された namespace 内で一意である必要があります。

   plugins

   CNI プラグイン設定の配列を指定します。1 つ目のオブジェクトは、macvlan プラグイン設定を指定し、2 つ目のオブジェクトはチューニングプラグイン設定を指定します。

   ips

   CNI プラグインのランタイム設定機能の静的 IP 機能を有効にするために要求が実行されるように指定します。

   master

   macvlan プラグインが使用するインターフェイスを指定します。

   mac

   CNI プラグインの静的 MAC アドレス機能を有効にするために要求が実行されるように指定します。

   上記のネットワークアタッチメントは、特定の Pod に割り当てる静的 IP と MAC アドレスを指定するためのキーとともに、JSON 形式のアノテーション内で参照できます。

4. 以下のコマンドを入力して Pod を編集します。

   $ oc edit pod <name>

   静的 IP および MAC アドレスを使用した macvlan CNI プラグイン JSON 設定オブジェクト

   apiVersion: v1
   kind: Pod
   metadata:
     name: example-pod
     annotations:
       k8s.v1.cni.cncf.io/networks: '[
         {
           "name": "<name>",
           "ips": [ "192.0.2.205/24" ],
           "mac": "CA:FE:C0:FF:EE:00"
         }
       ]'

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

   metadata.name

   作成するセカンダリーネットワークアタッチメントの名前を指定します。名前は指定された namespace 内で一意である必要があります。

   metadata.annotations.k8s.v1.cni.cncf.io/ips

   サブネットマスクを含む IP アドレスを指定します。

   metadata.annotations.k8s.v1.cni.cncf.io/mac

   MAC アドレスを指定します。

   注記

   静的 IP アドレスと MAC アドレスを同時に使用する必要はありません。個別に使用することも、組み合わせて使用することもできます。

手順

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

   1. <policy_name>.yaml ファイルを作成します。

      $ touch <policy_name>.yaml

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

      <policy_name>

      マルチネットワークポリシーのファイル名を指定します。

   2. 作成したファイルにマルチネットワークポリシーを定義します。次の例では、全 namespace 内の全 Pod からの Ingress トラフィックを拒否します。これは基本的なポリシーであり、他のネットワークポリシーの設定によって許可されたクロス Pod トラフィック以外のすべてのクロス Pod ネットワーキングをブロックします。

      apiVersion: k8s.cni.cncf.io/v1beta1
      kind: MultiNetworkPolicy
      endif:: multi[]
      metadata:
        name: deny-by-default
        annotations:
          k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
      spec:
        podSelector: {}
        policyTypes:
        - Ingress
        ingress: []

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

      <network_name>

      ネットワークアタッチメント定義の名前を指定します。

      次の設定例では、同じ namespace 内の全 Pod からの Ingress トラフィックを許可します。

      apiVersion: k8s.cni.cncf.io/v1beta1
      kind: MultiNetworkPolicy
      metadata:
        name: allow-same-namespace
        annotations:
          k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
      # ...

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

      <network_name>

      ネットワークアタッチメント定義の名前を指定します。

      次の例では、特定の namespace から 1 つの Pod への Ingress トラフィックを許可します。このポリシーは 、名前空間 y で実行されている Pod から、pod-a ラベルを持つ Pod へのトラフィックを許可します。

      apiVersion: k8s.cni.cncf.io/v1beta1
      kind: MultiNetworkPolicy
      metadata:
        name: allow-traffic-pod
        annotations:
          k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
      spec:
        podSelector:
         matchLabels:
            pod: pod-a
        policyTypes:
        - Ingress
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                 kubernetes.io/metadata.name: namespace-y
      # ...

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

      <network_name>

      ネットワークアタッチメント定義の名前を指定します。

      次の設定例では、サービスへのトラフィックを制限します。このポリシーを適用すると、app=bookstore と role=api の両方のラベルを持つすべての Pod に、app=bookstore というラベルを持つ Pod のみがアクセスできるようになります。この例では、アプリケーションは、ラベル app=bookstore および role=api でマークされた REST API サーバーである可能性があります。

      この設定例は、次のユースケースに対応しています。

      • サービスへのトラフィックを、それを使用する必要がある他のマイクロサービスのみに制限します。

      • データベースへの接続を制限して、それを使用するアプリケーションのみを許可します。

        apiVersion: k8s.cni.cncf.io/v1beta1
        kind: MultiNetworkPolicy
        metadata:
          name: api-allow
          annotations:
            k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
        spec:
          podSelector:
            matchLabels:
              app: bookstore
              role: api
          ingress:
          - from:
              - podSelector:
                  matchLabels:
                    app: bookstore
        # ...

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

      <network_name>

      ネットワークアタッチメント定義の名前を指定します。

2. マルチネットワークポリシーオブジェクトを作成するには、以下のコマンドを入力します。正常に処理された場合、ポリシーオブジェクトの名前と 作成 ステータスが表示されます。

   $ oc apply -f <policy_name>.yaml -n <namespace>

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

   <policy_name>

   マルチネットワークポリシーのファイル名を指定します。

   <namespace>

   オプションのパラメーター。現在の namespace とは異なる namespace でオブジェクトを定義した場合、パラメーターは namespace を指定します。

   正常に処理された場合、ポリシーオブジェクトの名前と 作成 ステータスが表示されます。

   注記

   cluster-admin 権限で Web コンソールにログインする場合、YAML で、または Web コンソールのフォームから、クラスターの任意の namespace でネットワークポリシーを直接作成できます。

手順

1. オプション: namespace のマルチネットワークポリシーオブジェクトをリスト表示するには、以下のコマンドを入力します。

   $ oc get multi-network policy -n <namespace>

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

   <namespace>

   オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

2. マルチネットワークポリシーオブジェクトを編集します。

   1. マルチネットワークポリシーの定義をファイルに保存した場合は、ファイルを編集して必要な変更を加えてから、以下のコマンドを入力します。

      $ oc apply -n <namespace> -f <policy_file>.yaml

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

      <namespace>

      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

      <policy_file>

      ネットワークポリシーを含むファイルの名前を指定します。

   2. マルチネットワークポリシーオブジェクトを直接更新する必要がある場合、以下のコマンドを入力できます。

      $ oc edit multi-network policy <policy_name> -n <namespace>

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

      <policy_name>

      ネットワークポリシーの名前を指定します。

      <namespace>

      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

3. マルチネットワークポリシーオブジェクトが更新されていることを確認します。

   $ oc describe multi-networkpolicy <policy_name> -n <namespace>

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

   <policy_name>

   マルチネットワークポリシーの名前を指定します。

   <namespace>

   オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

手順

1. namespace 内のマルチネットワークポリシーをリスト表示します。

   1. 次のコマンドを入力し、namespace 内に定義されているマルチネットワークポリシーオブジェクトを表示します。

      $ oc get multi-networkpolicy

   2. オプション: 特定のマルチネットワークポリシーを調べるには、次のコマンドを入力します。

      $ oc describe multi-networkpolicy <policy_name> -n <namespace>

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

      <policy_name>

      検査するマルチネットワークポリシーの名前を指定します。

      <namespace>

      オプション: オブジェクトが現在の namespace 以外の namespace に定義されている場合は namespace を指定します。

手順

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

   apiVersion: k8s.cni.cncf.io/v1beta1
   kind: MultiNetworkPolicy
   metadata:
     name: deny-by-default
     namespace: my-project
     annotations:
       k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
   spec:
     podSelector: {}
     policyTypes:
     - Ingress
     ingress: []

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

   namespace

   ポリシーをデプロイする namespace を指定します。たとえば、my-project という 名前空間。

   annotations

   namespace プロジェクトの名前と、それに続くネットワークアタッチメント定義名を指定します。

   podSelector

   このフィールドが空の場合、設定はすべての Pod と一致します。したがって、このポリシーは my-project 名前空間内のすべての Pod に適用されます。

   policyTypes

   NetworkPolicy が関連付けられるルールタイプのリストを指定します。

   - Ingress

   Ingress のみの policyTypes を指定します。

   ingress

   Ingress ルールを指定します。指定しない場合は、すべての Pod へのすべての着信トラフィックがドロップされます。

2. 次のコマンドを入力して、ポリシーを適用します。正常に処理された場合、ポリシーオブジェクトの名前と 作成 ステータスが表示されます。

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

手順

1. パブリックインターネットからのトラフィックが直接、またはロードバランサーを使用して Pod にアクセスできるようにするポリシーを作成します。YAML を web-allow-external.yaml ファイルに保存します。

   apiVersion: k8s.cni.cncf.io/v1beta1
   kind: MultiNetworkPolicy
   metadata:
     name: web-allow-external
     namespace: default
     annotations:
       k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
   spec:
     policyTypes:
     - Ingress
     podSelector:
       matchLabels:
         app: web
     ingress:
       - {}

2. 次のコマンドを入力して、ポリシーを適用します。正常に処理された場合、ポリシーオブジェクトの名前と 作成 ステータスが表示されます。

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

   このポリシーは、次の図に示すように、外部トラフィックを含むすべてのリソースからのトラフィックを許可します。

   

手順

1. すべての namespace のすべての Pod から特定のアプリケーションへのトラフィックを許可するポリシーを作成します。YAML を web-allow-all-namespaces.yaml ファイルに保存します。

   apiVersion: k8s.cni.cncf.io/v1beta1
   kind: MultiNetworkPolicy
   metadata:
     name: web-allow-all-namespaces
     namespace: default
     annotations:
       k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
   spec:
     podSelector:
       matchLabels:
        app: web
     policyTypes:
     - Ingress
     ingress:
     - from:
       - namespaceSelector: {}

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

   app

   デフォルト名前空間の app:web Pod にのみポリシーを適用します。

   namespaceSelector

   すべての namespace のすべての Pod を選択します。

   注記

   デフォルトでは、ポリシーオブジェクトで namespaceSelector パラメーターを指定しない場合、名前空間は選択されません。これは、そのネットワークポリシーがデプロイされている namespace からのみのトラフィックを許可することを意味します。

2. 次のコマンドを入力して、ポリシーを適用します。正常に処理された場合、ポリシーオブジェクトの名前と 作成 ステータスが表示されます。

   $ oc apply -f web-allow-all-namespaces.yaml

検証

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

   $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

2. 次のコマンドを実行して、alpine イメージを secondary 名前空間にデプロイし、シェルを開始します。

   $ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh

3. シェルで次のコマンドを実行し、サービスがリクエストを許可することを確認します。

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

   <!DOCTYPE html>
   <html>
   <head>
   <title>Welcome to nginx!</title>
   <style>
   html { color-scheme: light dark; }
   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. ラベルが Purpose=production の特定の名前空間内のすべての Pod からのトラフィックを許可するポリシーを作成します。YAML を web-allow-prod.yaml ファイルに保存します。

   apiVersion: k8s.cni.cncf.io/v1beta1
   kind: MultiNetworkPolicy
   metadata:
     name: web-allow-prod
     namespace: default
     annotations:
       k8s.v1.cni.cncf.io/policy-for:<namespace_name>/<network_name>
   spec:
     podSelector:
       matchLabels:
         app: web
     policyTypes:
     - Ingress
     ingress:
     - from:
       - namespaceSelector:
           matchLabels:
             purpose: production

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

   app

   デフォルトの名前空間の app:web Pod にのみポリシーを適用します。

   purpose

   ラベルが purpose=production の名前空間内の Pod のみにトラフィックを制限します。

2. 次のコマンドを入力して、ポリシーを適用します。正常に処理された場合、ポリシーオブジェクトの名前と 作成 ステータスが表示されます。

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

検証

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

   $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80

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

   $ oc create namespace prod

3. 次のコマンドを実行して、prod 名前空間にラベルを付けます。

   $ oc label namespace/prod purpose=production

4. 次のコマンドを実行して、dev 名前空間を作成します。

   $ oc create namespace dev

5. 次のコマンドを実行して、dev 名前空間にラベルを付けます。

   $ oc label namespace/dev purpose=testing

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

   $ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh

7. シェルで次のコマンドを実行し、ブロックされた要求の理由を確認します。たとえば、期待される出力は wget: download timed out です。

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

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

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

9. シェルで次のコマンドを実行し、リクエストが許可されていることを確認します。

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

   <!DOCTYPE html>
   <html>
   <head>
   <title>Welcome to nginx!</title>
   <style>
   html { color-scheme: light dark; }
   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>