Kubernetes ネットワークポリシーを NSX 分散ファイアウォールポリシーに変換する

Antrea NSX Adapter は、登録済みの Antrea Kubernetes クラスタの Kubernetes ネットワークポリシーを NSX インベントリに同期します。ただし、これらの K8s ネットワークポリシーは、NSX 環境では更新または管理できません。

NSX で K8s ネットワークポリシーを編集する場合は、NSX 環境にインポートできます。このインポート機能は、NSX 4.2 以降で使用でき、NSX API でのみサポートされます。

K8s ネットワークポリシーのインポートの概要

インポート操作により、K8s ネットワークポリシーが同等のトラフィック動作を持つ NSX Distributed Firewall (DFW) ポリシーに変換されます。K8s ネットワークポリシーが NSX DFW ポリシーに変換されると、NSX は変換された DFW ポリシーを管理するための信頼できる情報源になります。その後、NSX Manager ユーザーインターフェイスまたは NSX API のいずれかを使用して、DFW ポリシーを編集できます。

この変換は一方向の操作です。NSX DFW ポリシーを K8s ネットワークポリシーに変換することはできません。

重要： NSX インベントリに、 NSX Container Plugin (NCP) によって管理されている Kubernetes ネットワークポリシーが含まれている場合、インポート機能はサポートされません。 NSX にインポートする K8s ネットワークポリシーは、 Antrea CNI によって管理されている必要があります。

インポートされた各 K8s ネットワークポリシーは、1 つまたは 2 つの NSX DFW ポリシーに変換されます。1 つの DFW ポリシーにはすべての許可ルールが含まれます（K8s ネットワークポリシーに入力方向または出力方向のルールがある場合）、もう 1 つの DFW ポリシーにはデフォルトのドロップトラフィックルールが含まれます。デフォルトのドロップルールを持つ DFW ポリシーは常に生成されます。

システムは、NSX DFW ポリシーの範囲（スコープ）を Antrea Kubernetes クラスタに設定します。さらに、DFW ポリシーの範囲は、Kubernetes ネームスペースの有効なポッドメンバーを含む Antrea グループに制限されます。

変換された DFW ポリシーは、NSX のアプリケーション層に配置されます。インポート API は、アプリケーション層の他の既存の Antrea ポリシーの後に、変換された DFW ポリシーを追加します。インポートされたポリシーは、NSX 内の既存の Antrea ポリシーが適用される後、ただし Kubernetes クラスタでネイティブに定義された Antrea クラスタネットワークポリシー (ACNP) および Antrea ネットワークポリシー (ANP) が適用される前に適用されます。K8s ネームスペース内の元のトラフィック動作は、NSX DFW ポリシーに変換された後も保持されます。

Antrea CNI は、変換された DFW ポリシーを Kubernetes クラスタ内の Antrea クラスタネットワークポリシーとして認識します。これらの Antrea クラスタネットワークポリシーは NSX によって管理され、NSX 環境でのみ編集できます。kubectl コマンドラインを使用して ACNP 構成を編集しようとすると、Antrea NSX Adapter は ACNP の変更を上書きするか、NSX に存在する元のポリシー定義に戻します。

K8s ネットワークポリシーが NSX に正常にインポートされると、システムは K8s インベントリから元の Kubernetes ネットワークポリシーを自動的に削除します。また、変換された DFW ポリシーには、K8s クラスタの名前、元の K8s ネットワークポリシー、および K8s ネームスペースのタグも付けられます。これらのタグは、NSX Manager ユーザーインターフェイスで変換された DFW ポリシーを検索するのに役立ちます。または、kubectl コマンドラインで kubectl get acnp -o wide コマンドを実行して、対応する認識された ACNP のタグ（つまり K8s のラベル）を表示できます。

K8s ネットワークポリシーをインポートするための前提条件

Antrea Kubernetes クラスタを NSX 4.2 以降に登録する必要があります。
インポート機能を使用するには、VMware Container Networking™ with Antrea™ 1.9.0 以降で使用可能な Antrea-NSX インターワーキングバージョンが必要です。
分散ファイアウォールセキュリティポリシーを構成する資格をシステムに付与する適切なセキュリティライセンスを NSX 環境に適用します。
NSX 環境のデフォルト領域でエンタープライズ管理者ロールまたはセキュリティ管理者ロールが割り当てられます。
Antrea NSX Adapter が Kubernetes ネットワークポリシーを NSX インベントリに正常に報告したことを確認します。
たとえば、 NSX Manager ユーザーインターフェイスで確認するには、次の手順を実行します。
1. [インベントリ] > [コンテナ] > [ネームスペース] の順に移動します。
2. 必要に応じて、[CNI タイプ] を [Antrea] に指定して、ネームスペースのリストをフィルタリングします。
3. ネームスペースを展開し、ネットワークポリシーの数をクリックして、Kubernetes ネットワークポリシーが NSX インベントリと同期されているかどうかを確認します。
  NSX がネームスペース内のすべての Kubernetes ネットワークポリシーを読み取っているかどうかを確認するには、ユーザーインターフェイスの数と、次の kubectl コマンドによって取得されたポリシーの数を比較できます。数は同じである必要があります。
```
kubectl get networkpolicies -n <namespace>
```

NSX 分散ファイアウォールポリシーフィールドへの K8s ネットワークポリシーフィールドのマッピング

前述のように、Kubernetes ネットワークポリシーが NSX にインポートされると、システムはこのネットワークポリシーを 1 つまたは 2 つの DFW ポリシーに変換します。1 つの DFW ポリシーにはすべての許可ルールが含まれ、もう 1 つの DFW ポリシーにはデフォルトのドロップトラフィックルールが含まれます。K8s ネットワークポリシーの仕様に従って、Antrea グループが作成されます。Antrea グループは、変換された DFW ポリシーの [送信元]、[宛先]、および [適用先] フィールドで使用されます。

次の表では、Kubernetes ネットワークポリシーのフィールドと、NSX 分散ファイアウォールポリシーのフィールドのマッピングについて説明します。

K8s ネットワークポリシーのフィールド	NSX リソース	説明
K8s ネットワークポリシー	1 つまたは 2 つの DFW ポリシー	K8s ネットワークポリシーの `spec.ingress` または `spec.egress` のすべてのルールが DFW の「許可」ポリシーに追加されます。つまり、この DFW ポリシー内のすべてのルールのルールアクションは [許可] に設定されます。デフォルトのドロップルールを持つ DFW ポリシーは、K8s ネットワークポリシーの `spec.policyTypes` リストの値に従って、受信トラフィック、送信トラフィック、または受送信トラフィックのいずれかをドロップするルールを使用して作成されます。たとえば、K8s ネットワークポリシー仕様の `spec.policyTypes` リストに `egress` のみが含まれている場合、DFW の「ドロップ」ポリシーには出力方向トラフィック（トラフィック方向：送信）のデフォルトのドロップルールがあります。 Kubernetes ネットワークポリシーに入力方向ルールと出力方向ルールが含まれていない場合は、デフォルトのドロップルールのみを含む DFW ポリシーが作成されます。
`spec.podSelector` および `metadata.namespace`	タイプ Antrea のグループ	`spec.podSelector` と `metadata.namespace` の両方を使用して、Antrea グループに変換します。作成された Antrea グループは、DFW の「許可」ポリシーと DFW の「ドロップ」ポリシーの [適用先] で参照されます。 `spec.podSelector` が指定されていない場合、Antrea グループにはネームスペースのみが含まれます。
`spec.ingress[]` および `spec.egress[]`	DFW の「許可」ポリシーのファイアウォールルール	K8s ネットワークポリシーの `spec.ingress` および `spec.egress` セクションの各ルールは、NSX DFW ルールに変換されます。これらの DFW ルールは、DFW の「許可」ポリシーに追加されます。
`spec.ingress[*].from` `podSelector` `namespaceSelector` `ipBlock`	タイプ Antrea のグループ	`ingress` `from` セクションのポッドとネームスペースのセレクタは、動的メンバーシップ基準を持つ Antrea グループに変換されます。 `ipBlock` セレクタの IP CIDR 範囲は、Antrea グループ内の静的 IP アドレスメンバーに変換されます。これらの Antrea グループは、DFW ルールの [送信元] フィールドで参照されます。
`spec.egress[*].to` `podSelector` `namespaceSelector` `ipBlock`	タイプ Antrea のグループ	`egress` `to` セクションのポッドとネームスペースのセレクタは、動的メンバーシップ基準を持つ Antrea グループに変換されます。 `ipBlock` セレクタの IP CIDR 範囲は、Antrea グループ内の静的 IP アドレスメンバーに変換されます。これらの Antrea グループは、DFW ルールの [宛先] フィールドで参照されます。
`spec.ingress[].ports` `protocol` `port` および `spec.egress[].ports` `protocol` `port`	DFW ルール内のサービスエントリ	K8s ネットワークポリシーの入力方向および出力方向ルール仕様のレイヤー 4 プロトコルとターゲットポート（ターゲットポートの範囲を含む）は、DFW ルール内の [サービス] エントリに変換されます。 K8s ルール仕様のターゲットポートまたはポート範囲は、常に [サービス] エントリの宛先ポートにマッピングされます。

フィールドマッピングの例

このセクションでは、K8s ネットワークポリシーが NSX にインポートされたときの Kubernetes ネットワークポリシーのフィールドと DFW ポリシーのフィールドのマッピングを理解するのに役立ついくつかの例を示します。

Example 1

K8s ネットワークポリシーの仕様：

apiVersion: v1
kind: Namespace
metadata:
  name: my-ns1
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: knp1
  namespace: my-ns1
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 8.8.8.8/32
      ports:
        - protocol: UDP
          port: 53

この K8s ネットワークポリシーは、my-ns1 ネームスペース内のすべてのポッドを選択し、このネームスペース内の任意のポッドから UDP ポート 53 の 8.8.8.8/32 CIDR への出力方向トラフィック（送信接続）を許可します。このネームスペース内のポッドからの他のすべての出力方向トラフィックはドロップされます。

この K8s ネットワークポリシーを NSX にインポートすると、2 つの DFW ポリシーが作成されます。1 つの DFW ポリシーには 1 つの許可ルールが含まれ、もう 1 つの DFW ポリシーには 1 つのドロップルールが含まれます。

spec.podSelector セクションは、動的メンバーシップ基準を持つ Antrea グループに変換されます。グループ内の基準は、my-ns1 ネームスペース内のすべてのポッドを選択します。この Antrea グループは、DFW 許可ポリシーと DFW ドロップポリシーの両方の [適用先] フィールドで参照されます。

spec.egress.to セクションの ipBlock セレクタは、静的 IP アドレスメンバー 8.8.8.8/32 を持つ Antrea グループに変換されます。この Antrea グループは、DFW 許可ルールの [宛先] フィールドで参照されます。このグループを Group-1 とします。

spec.egress.ports セクションは、UDP プロトコルと宛先ポート 53 を持つ [サービス] エントリに変換されます。

NSX での DFW 許可ルールの構成は次のとおりです。

送信元	宛先	サービス	コンテキストプロファイル	ルールの適用先	ルールアクション	ルールの方向
該当なし	Group-1	UDP 送信元：任意、宛先：53	該当なし	任意	許可	送信

送信元

宛先

サービス

コンテキストプロファイル

ルールの適用先

ルールアクション

ルールの方向

該当なし

Group-1

UDP

送信元：任意、宛先：53

該当なし

任意

許可

送信

NSX での DFW ドロップルールの構成は次のとおりです。

送信元	宛先	サービス	コンテキストプロファイル	ルールの適用先	ルールアクション	ルールの方向
任意	任意	任意	該当なし	任意	ドロップ	送信

Example 2

K8s ネットワークポリシーの仕様：

apiVersion: v1
kind: Namespace
metadata:
  name: my-ns2
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: knp2
  namespace: my-ns2
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

この Kubernetes ネットワークポリシーは、my-ns2 ネームスペース内のすべてのポッドを選択し、これらのポッドからの入力方向トラフィックと出力方向トラフィックをすべてドロップします。このポリシーは基本的に、ネームスペースのすべての入力方向トラフィックと出力方向トラフィックをドロップするデフォルトルールを作成します。

この K8s ネットワークポリシーが NSX にインポートされると、1 つの DFW ドロップポリシーのみが作成されます。変換された DFW ポリシーには、ドロップアクションを含む単一のファイアウォールルールが含まれます。

spec.podSelector セクションは、動的メンバーシップ基準を持つ Antrea グループに変換されます。グループ内の基準は、my-ns2 ネームスペース内のすべてのポッドを選択します。この Antrea グループは、DFW ドロップポリシーの [適用先] フィールドで参照されます。

NSX での DFW ドロップルールの構成は次のとおりです。

送信元	宛先	サービス	コンテキストプロファイル	ルールの適用先	ルールアクション	ルールの方向
任意	任意	任意	該当なし	任意	ドロップ	受信/送信

変換された DFW ポリシーと Antrea グループの命名規則

システムは、変換された DFW 許可ポリシーとドロップポリシーに次の命名規則を使用します。

DFW 許可ポリシー: <cluster_name>-<namespace>-<K8s_networkpolicy_name>-<K8s_networkpolicy_uuid>-allow
DFW ドロップポリシー: <cluster_name>-<namespace>-<K8s_networkpolicy_name>-<K8s_networkpolicy_uuid>-drop

cluster_name、namespace、およびK8s_networkpolicy_name の値はそれぞれ 12 バイトに切り詰められます。

システムは、Antrea グループに次の命名規則を使用します。

DFW の許可ポリシーとドロップポリシーの [適用先] フィールドで参照されるグループ: <cluster_name>-<namespace>-<K8s_networkpolicy_uuid>
DFW ルールの [送信元] フィールドで参照されるグループ: <cluster_name>-<namespace>-<K8s_networkpolicy_uuid>-rule[rule index]-from-<peer index>
DFW ルールの [宛先] フィールドで参照されるグループ: <cluster_name>-<namespace>-<K8s_networkpolicy_uuid>-rule[rule index]-to-<peer index>

cluster_name と namespace の値はそれぞれ 12 バイトに切り詰められます。

Antrea グループ名のルールインデックスとピアインデックスにシステムが値を割り当てる方法を理解するには、3 つの入力方向ルールを含む K8s ネットワークポリシーの次の例を検討してください。

例

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: knp3
  namespace: my-ns3
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns1"]
        - podSelector:
            matchExpressions:
            - key: app
              operator: In
              values: ["nginx"]
      ports:
        - protocol: TCP
          port: 80
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: [""]
      ports:
        - protocol: TCP
          port: 443
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns4"]
      ports:
        - protocol: TCP
          port: 8080
          endPort: 8090

次に示す、最初の ingress.from ルールのスニペットについて考えてみましょう。

ingress:
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns1"]
        - podSelector:
            matchExpressions:
            - key: app
              operator: In
              values: ["nginx"]
      ports:
        - protocol: TCP
          port: 80

この入力方向ルールの from セクションには、2 つの要素が含まれています。1 つの要素はネームスペースセレクタを使用してポッドを選択し、もう 1 つの要素はポッドセレクタを使用してポッドを選択します。これら 2 つの要素をピアと言います。

システムは、ルール内のピアごとに 1 つの Antrea グループを作成します。変換された DFW ルールにはルールインデックス 0 があり、このルールにはルールの [送信元] フィールドに 2 つの Antrea グループが含まれています。次のように、1 つの Antrea グループ名にピアインデックス 0 があり、もう 1 つのグループ名にピアインデックス 1 があります。

<cluster_name>-my-ns3-knp3-rule[0]-from-0

<cluster_name>-my-ns3-knp3-rule[0]-from-1

ここで、次のように、2 番目と 3 番目の ingress.from ルールのスニペットを考えてみましょう。

ingress:
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: [""]
      ports:
        - protocol: TCP
          port: 443
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns4"]
      ports:
        - protocol: TCP
          port: 8080
          endPort: 8090

これら 2 つの入力方向ルールの from セクションには、ネームスペースセレクタを使用してポッドを選択する単一の要素のみが含まれています。変換された DFW ルールには、それぞれルールインデックス 1 と 2 があり、各ルールにはルールの [送信元] フィールドに 1 つの Antrea グループが含まれています。この場合、ピアインデックスは Antrea グループの名前に追加されません。グループ名は次のとおりです。

<cluster_name>-my-ns3-knp3-rule[1]-from

<cluster_name>-my-ns3-knp3-rule[2]-from

API を使用した高度なインポートワークフロー

このドキュメントで前述したように、Kubernetes ネットワークポリシーをインポートするための前提条件を満たしていることを確認します。
次の kubectl コマンドを実行して、特定のネームスペース内の Kubernetes ネットワークポリシーのリストを表示します。
```
kubectl get networkpolicies -n <namespace>
```
次はその例です。
```
kubectl get networkpolicies -n test-ns5

NAME     POD-SELECTOR   AGE
k-np10   app=demo       82m
k-np11   app=myapp      82m
k-np12   app=demo       82m
k-np9    app=myapp      82m
```
この例では、test-ns5 ネームスペースに 4 つの Kuberentes ネットワークポリシーが含まれています。この手順では、「k-np9」および「k-np11」ポリシーを NSX にインポートします。
次の kubectl コマンドを実行して、インポートする各 Kubernetes ネットワークポリシーの ID を取得します。
```
kubectl get networkpolicies <policy-name> -n <namespace> -o yaml
```
たとえば、「k-np9」および「k-np11」ネットワークポリシーの ID を取得するには、次のコマンドを実行します。
```
kubectl get networkpolicies k-np9 -n test-ns5 -o yaml
kubectl get networkpolicies k-np11 -n test-ns5 -o yaml
```
これらの両方の kubectl コマンドの出力で、 metadata.uid フィールドに表示される ID を書き留めます。K8s クラスタでは、ポリシー ID は次のとおりです。
- k-np9 の場合：e5a59ae6-cc0e-42a5-80bd-f6fa13b5b70d
- k-np11 の場合：84b850fb-69ad-4e95-a563-a95ce6b70557
これらのポリシー ID は、例を示す目的のみに使用されます。実際の K8s クラスタでは異なる場合があります。次の手順で説明するインポート API を実行するには、これらのポリシー ID が必要です。

次の NSX API を実行して、Kubernetes ネットワークポリシーをインポートします。

次はその例です。

POST https://<nsx-mgr>/policy/api/v1/infra/import-k8s-np-to-dfw?on_error=ABORT  -k
{
    "network_policy_ids" : ["e5a59ae6-cc0e-42a5-80bd-f6fa13b5b70d", "84b850fb-69ad-4e95-a563-a95ce6b70557"],
    "sequence_number_upper" : 1000,
    "sequence_number_lower" : 2000
}

network_policy_ids パラメータは必須ですが、sequence_number_upper および sequence_number_lower パラメータはオプションです。

この例では、K8s ネットワークポリシー（k-np9 および k-np11）の ID を NSX にインポートするために指定します。

これらの要求パラメータ、API サンプル要求、API 応答の例の詳細については、『NSX API ガイド』を参照してください。

on_error クエリパラメータは、エラーが発生したときに API が実行する必要があるアクションを決定します。次の表では、このクエリパラメータの有効な値について説明します。

値	説明
中止	この値がデフォルトです。 K8s ネットワークポリシーのインポート中にエラーが発生すると、変換されたすべての DFW ポリシーと Antrea グループがコミットされなくなります。インポート操作は途中で終了し、K8s ネットワークポリシーは変換されません。API 応答は、エラーが発生した各 K8s ネットワークポリシーのエラーメッセージを返します。例： API 要求の本文に knp1 と knp2 という 2 つの K8s ネットワークポリシーの UUID を指定したとします。knp1 ポリシーには、出力方向ルールの仕様でサポートされていない SCTP プロトコルが含まれています。インポート API を実行すると、knp1 ネットワークポリシーの変換でエラーが発生し、インポート操作が途中で終了します。次の K8s ネットワークポリシー (knp2) が有効であっても、システムはこのネットワークポリシーを変換しません。
続行	現在の K8s ネットワークポリシーのインポート中にエラーが発生した場合、システムはこのポリシーをスキップし、次の K8s ネットワークポリシーのインポートを続行します。API 応答は、インポート操作中にスキップされた各 K8s ネットワークポリシーのエラーメッセージを返します。注意：インポートされた K8s ネットワークポリシーとスキップされた K8s ネットワークポリシーが同じポッドに適用されている場合、トラフィックの動作が変更される可能性があります。例：前の行で説明したように、同じ例で続行します。knp1 ネットワークポリシーのインポートでエラーが発生すると、システムは knp2 ネットワークポリシーのインポートを続行し、このネットワークポリシーを正常に変換します。API 応答は、変換中に失敗した knp1 ネットワークポリシーに対して同じエラーメッセージを返します。

値

説明

中止

この値がデフォルトです。

K8s ネットワークポリシーのインポート中にエラーが発生すると、変換されたすべての DFW ポリシーと Antrea グループがコミットされなくなります。インポート操作は途中で終了し、K8s ネットワークポリシーは変換されません。API 応答は、エラーが発生した各 K8s ネットワークポリシーのエラーメッセージを返します。

例：

API 要求の本文に knp1 と knp2 という 2 つの K8s ネットワークポリシーの UUID を指定したとします。knp1 ポリシーには、出力方向ルールの仕様でサポートされていない SCTP プロトコルが含まれています。インポート API を実行すると、knp1 ネットワークポリシーの変換でエラーが発生し、インポート操作が途中で終了します。次の K8s ネットワークポリシー (knp2) が有効であっても、システムはこのネットワークポリシーを変換しません。

続行

現在の K8s ネットワークポリシーのインポート中にエラーが発生した場合、システムはこのポリシーをスキップし、次の K8s ネットワークポリシーのインポートを続行します。API 応答は、インポート操作中にスキップされた各 K8s ネットワークポリシーのエラーメッセージを返します。

注意：インポートされた K8s ネットワークポリシーとスキップされた K8s ネットワークポリシーが同じポッドに適用されている場合、トラフィックの動作が変更される可能性があります。

例：

前の行で説明したように、同じ例で続行します。knp1 ネットワークポリシーのインポートでエラーが発生すると、システムは knp2 ネットワークポリシーのインポートを続行し、このネットワークポリシーを正常に変換します。API 応答は、変換中に失敗した knp1 ネットワークポリシーに対して同じエラーメッセージを返します。

1 つの API 要求でインポートする K8s ネットワークポリシーは、登録されている別の Antrea Kubernetes クラスタに属している場合があります。または、1 つの Antrea Kubernetes クラスタ内の複数のネームスペースに属している場合があります。

ネームスペースに複数の K8s ネットワークポリシーが含まれている場合は、1 つの API 要求でインポートすることをお勧めします。これは、ネームスペース内の K8s ネットワークポリシーが相互に関連付けられている可能性があるからです。この方法は、ネットワークポリシーが NSX にインポートされた後にトラフィックの動作が変更されないようにするのに役立ちます。

インポートが成功したら、NSX Manager ユーザーインターフェイスに移動し、Antrea グループと DFW ポリシーの構成を表示します。
オプション：次の kubectl コマンドを実行して、認識された Antrea クラスタネットワークポリシーを表示し、ACNP 仕様と ClusterGroup 仕様を確認します。
```
kubectl get acnp
```
```
kubectl get acnp <acnp-id> -o yaml
```
```
kubectl get cg <cg-id> -o yaml
```
オプション：次の kubectl コマンドを実行して、NSX に正常にインポートされた K8s ネットワークポリシーが K8s クラスタに表示されないことを確認します。
```
kubectl get networkpolicies -n <namespace>
```
例では、コマンドは次のとおりです。
```
kubectl get networkpolicies -n test-ns5

NAME     POD-SELECTOR   AGE
k-np10   app=demo       84m
k-np12   app=demo       84m
```
インポートされた Kubernetes ネットワークポリシー（k-np9 および k-np11）が K8s クラスタに表示されなくなったことを確認します。

サポートされていない Kubernetes ネットワークポリシー機能

Kubernetes ネットワークポリシーの一部の機能は、現在、NSX DFW ポリシーおよび Antrea グループへの変換ではサポートされていません。次のサポートされていない機能のいずれかが原因で変換に失敗すると、API 応答に適切なエラーメッセージが表示されます。

ポッドにレイヤー 4 のポート名を使用する K8s ネットワークポリシーは変換されません。DFW ポリシーはポート番号のみをサポートします。
SCTP プロトコルを含む K8s ネットワークポリシーは変換されません。NSX DFW ポリシーは SCTP トラフィックをサポートしません。
K8s ネットワークポリシーには、podSelector または NetworkPolicyPeer セクションで多数の matchLabels または matchExpressions を設定できます。ただし、Antrea グループ内の動的メンバーシップ基準は、メンバータイプが混在する場合は最大 15 個の条件、同じメンバータイプの場合は 5 つの条件をサポートできます。グループメンバーシップ基準でこの上限を超えると、変換は失敗します。
DoesNotExist 演算子を持つ matchExpressions を含む Kubernetes ネットワークポリシーは、Antrea グループに変換されません。Kubernetes の DoesNotExist 演算子は、NSX の範囲演算子の NotEquals 値にマッピングされます。ただし、現在、Antrea グループ定義の範囲演算子はこの値をサポートしていません。
変換を成功させるには、In 演算子を持つ matchExpressions を含む Kubernetes ネットワークポリシーに 1 つの値のみを含める必要があります。In 演算子の複数の値は、現在、Antrea グループへの変換ではサポートされていません。

異なる Antrea NSX Adapter バージョンでの動作

Antrea NSX Adapter と NSX を個別に、任意の順序でアップグレードできます。Antrea NSX Adapter の新しい変更は、4.2 より前のバージョン NSX と互換性があります。

次のシナリオについて考えます。

NSX 環境はバージョン 4.2 で、複数の Antrea Kubernetes クラスタが登録されています。Kubernetes クラスタには、新しいバージョンの Antrea NSX Adapter（v0.15 など）を持つものと古いバージョンの Antrea NSX Adapter（v0.11 など）を持つものがあります。この場合、古いバージョンの Antrea NSX Adapter は、変換後に元の Kubernetes ネットワークポリシーを Kubernetes クラスタから自動的に削除しません。Kubernetes 管理者またはネームスペース管理者は、元の Kubernetes ネットワークポリシーを手動で削除する必要があります。DFW ポリシーへの変換は引き続き実行されることに注意してください。変換された DFW 許可ポリシーとデフォルトのドロップポリシーは、Kubernetes クラスタ内で Antrea クラスタネットワークポリシーとして認識され、元の Kubernetes ネットワークポリシーの前に Antrea CNI によって評価されます。元の Kubernetes ポリシーが Kubernetes クラスタから削除されない場合、変換された DFW ポリシーで定義されているトラフィックの動作が元の Kubernetes ネットワークポリシーと競合する可能性があります。

K8s ネットワーク ポリシーのインポートの概要

K8s ネットワーク ポリシーをインポートするための前提条件

NSX 分散ファイアウォール ポリシー フィールドへの K8s ネットワーク ポリシー フィールドのマッピング

フィールド マッピングの例