Antrea NSX 介面卡 會將已登錄的 Antrea Kubernetes 叢集的 Kubernetes 網路原則同步到 NSX 詳細目錄。但是，無法在 NSX 環境中更新或管理這些 K8s 網路原則。
如果您要在 NSX 中編輯 K8s 網路原則，可以將其匯入至 NSX 環境中。此匯入功能從 NSX 4.2 開始提供，並且僅支援使用 NSX API 實現該功能。
匯入 K8s 網路原則概觀
匯入作業會將 K8s 網路原則轉換為具有同等流量行為的 NSX 分散式防火牆 (DFW) 原則。在將 K8s 網路原則轉換為 NSX DFW 原則後，NSX 將成為管理轉換的 DFW 原則的事實來源。然後，您可以使用 NSX Manager UI 或 NSX API 編輯 DFW 原則。
此轉換是單向作業。無法將 NSX DFW 原則轉換回 K8s 網路原則。
每個匯入的 K8s 網路原則都將轉換為一或兩個 NSX DFW 原則。一個 DFW 原則將包含所有允許規則 (如果 K8s 網路原則中存在入口和出口規則)，另一個 DFW 原則將包含預設捨棄流量規則。將一律產生具有預設捨棄規則的 DFW 原則。
系統會將 NSX DFW 原則的跨度 (範圍) 設定為 Antrea Kubernetes 叢集。此外，可將 DFW 原則的跨度進一步限制為包含 Kubernetes 命名空間的有效網繭成員的 Antrea 群組。
轉換的 DFW 原則放置在 NSX 的應用程式層中。匯入的 API 會將轉換的 DFW 原則附加到應用程式層中的其他現有 Antrea 原則之後。匯入的原則在 NSX 中的現有 Antrea 原則之後強制執行，但在強制執行 Antrea 叢集網路原則 (ACNP) 和 Antrea 網路原則 (ANP) 之前強制執行，後兩者在 Kubernetes 叢集以原生方式定義。轉換為 NSX DFW 原則後，將保留 K8s 命名空間中的原始流量行為。
Antrea CNI 將轉換的 DFW 原則作為 Kubernetes 叢集中的 Antrea 叢集網路原則實現。這些 Antrea 叢集網路原則現在由 NSX 管理，並且只能在 NSX 環境中進行編輯。如果嘗試使用 kubectl 命令列編輯 ACNP 組態，Antrea NSX 介面卡 將覆寫或還原對原始原則定義的 ACNP 變更，因為它存在於 NSX 中。
將 K8s 網路原則成功匯入 NSX 後，系統會自動從 K8s 詳細目錄中刪除原始 Kubernetes 網路原則。系統還會使用 K8s 叢集的名稱、原始 K8s 網路原則和 K8s 命名空間來標記轉換的 DFW 原則。這些標籤可協助您在 NSX Manager UI 中搜尋轉換的 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 Interworking 版本。
- 在 NSX 部署中套用適當的安全性授權，以授權系統設定分散式防火牆安全性原則。
- 在 NSX 環境的預設空間中，會為您指派企業管理員角色或安全管理員角色。
- 確認 Antrea NSX 介面卡 已成功將 Kubernetes 網路原則報告給 NSX 詳細目錄。
例如，若要在 NSX Manager UI 中進行驗證，請執行以下步驟：
- 導覽至。
- 如有需要，請篩選出 CNI 類型為 Antrea 的命名空間清單。
- 展開命名空間，然後按一下網路原則計數，以驗證 Kubernetes 網路原則是否已同步到 NSX 詳細目錄。
若要檢查 NSX 是否讀取命名空間中的所有 Kubernetes 網路原則，可以將 UI 中的計數與透過以下 kubectl 命令擷取的原則數進行比較。計數必須相同。
kubectl get networkpolicies -n <namespace>
將 K8s 網路原則欄位對應到 NSX 分散式防火牆原則欄位
如前所述，將 Kubernetes 網路原則匯入至 NSX 時，系統會將此網路原則轉換為一或兩個 DFW 原則。一個 DFW 原則包含所有允許規則，另一個 DFW 原則包含預設捨棄流量規則。系統會根據 K8s 網路原則的規範建立 Antrea 群組。Antrea 群組在轉換的 DFW 原則的來源、目的地和套用至欄位中使用。
下表介紹了 Kubernetes 網路原則中的欄位與 NSX 分散式防火牆原則中欄位的對應情況。
| K8s 網路原則中的欄位 | NSX 資源 | 說明 |
|---|---|---|
| K8s 網路原則本身 |
一或兩個 DFW 原則 |
|
spec.podSelector和 metadata.namespace |
Antrea 類型的群組 |
將同時使用 建立的 Antrea 群組在 DFW「允許」原則和 DFW「捨棄」原則的套用至中參考。 如果未指定 |
spec.ingress[*]和 spec.egress[*] |
DFW「允許」原則中的防火牆規則 |
K8s 網路原則 這些 DFW 規則將新增至 DFW「允許」原則中。 |
spec.ingress[*].from
|
Antrea 類型的群組 |
|
spec.egress[*].to
|
Antrea 類型的群組 |
|
spec.ingress[*].ports
和 spec.egress[*].ports
|
DFW 規則中的服務項目 |
|
欄位對應範例
本節包含一些範例，可協助您瞭解將 K8s 網路原則匯入至 NSX 時，Kubernetes 網路原則中的欄位與 DFW 原則中的欄位的對應情況。
- 範例 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 時，將建立兩個 DFW 原則。一個 DFW 原則包含一個允許規則，另一個 DFW 原則包含一個捨棄規則。
spec.podSelector區段將轉換為具有動態成員資格準則的 Antrea 群組。群組中的準則將選取 my-ns1 命名空間中的所有網繭。此 Antrea 群組在 DFW 允許原則和 DFW 捨棄原則的套用至欄位中參考。ipBlock區段中的spec.egress.to選取器將轉換為具有靜態 IP 位址成員 8.8.8.8/32 的 Antrea 群組。此 Antrea 群組在 DFW 允許規則的目的地欄位中參考。我們將此群組稱為群組 1。spec.egress.ports區段將轉換為具有 UDP 通訊協定和目的地連接埠 53 的服務項目。NSX 中 DFW 允許規則的組態如下所示。
來源 目的地 服務 內容設定檔 規則 - 套用至 規則 - 動作 規則 - 方向 不適用 群組 1 UDP
來源：任何，目的地：53
不適用 任何 允許 傳出 NSX 中 DFW 捨棄規則的組態如下所示。
來源 目的地 服務 內容設定檔 規則 - 套用至 規則 - 動作 規則 - 方向 任何 任何 任何 不適用 任何 捨棄 傳出
- 範例 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 時，僅建立一個 DFW 捨棄原則。轉換的 DFW 原則包含具有捨棄動作的單一防火牆規則。
spec.podSelector區段將轉換為具有動態成員資格準則的 Antrea 群組。群組中的準則將選取 my-ns2 命名空間中的所有網繭。此 Antrea 群組在 DFW 捨棄原則的套用至欄位中參考。NSX 中 DFW 捨棄規則的組態如下所示。
來源 目的地 服務 內容設定檔 規則 - 套用至 規則 - 動作 規則 - 方向 任何 任何 任何 不適用 任何 捨棄 In_Out
轉換的 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 群組名稱中的規則索引和對等索引，請參考以下 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區段包含兩個元素。一個元素使用命名空間選取器來選取網繭，另一個元素使用網繭選取器來選取網繭。我們將這兩個元素稱為對等。系統會為規則中的每個對等建立一個 Antrea 群組。轉換的 DFW 規則的規則索引為 0，此規則在規則的來源欄位中包含兩個 Antrea 群組。一個 Antrea 群組名稱的對等索引為 0，另一個群組名稱的對等索引為 1，如下所示：
<cluster_name>-my-ns3-knp3-rule[0]-from-0
<cluster_name>-my-ns3-knp3-rule[0]-from-1
現在，請看第二個和第三個
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這兩個入口規則中每個規則的
from區段僅包含一個元素，它使用命名空間選取器來選取網繭。轉換的 DFW 規則的規則索引分別為 1 和 2，並且每個規則在規則的來源欄位中都包含一個 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命名空間包含四個 Kuberentes 網路原則。在此程序中，我們會將「k-np9」和「k-np11」原則匯入至 NSX 中。 - 執行以下 kubectl 命令，以擷取您要匯入的每個 Kubernetes 網路原則的識別碼。
kubectl get networkpolicies <policy-name> -n <namespace> -o yaml
例如，若要擷取「k-np9」網路原則和「k-np11」網路原則的識別碼，請執行以下命令：
kubectl get networkpolicies k-np9 -n test-ns5 -o yaml kubectl get networkpolicies k-np11 -n test-ns5 -o yaml
在這兩個 kubectl 命令的輸出中，記下您在metadata.uid欄位中看到的識別碼。在我們的 K8s 叢集中，原則識別碼如下所示：- 對於 k-np9：
e5a59ae6-cc0e-42a5-80bd-f6fa13b5b70d - 對於 k-np11：
84b850fb-69ad-4e95-a563-a95ce6b70557
這些原則識別碼僅供範例使用。它們在 K8s 叢集中可能會有所不同。您需要這些原則識別碼才能執行匯入 API，將在下一步中進行介紹。
- 對於 k-np9：
- 執行以下 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 參數為選用參數。
在此範例中，指定了將匯入至 NSX 的 K8s 網路原則 (k-np9 和 k-np11) 的識別碼。
如需有關這些要求參數、API 範例要求和 API 範例回應的詳細資訊，請參閱NSX API 指南。
on_error 查詢參數用於確定發生錯誤時 API 必須採取的行動。下表介紹了此查詢參數的有效值。
值 說明 中止 此值為預設值。
如果匯入 K8s 網路原則時發生錯誤，系統將阻止提交所有轉換的 DFW 原則和 Antrea 群組。匯入作業提前結束，並且不會轉換任何 K8s 網路原則。API 回應會針對導致錯誤的每個 K8s 網路原則傳回相應的錯誤訊息。
範例：
假設在 API 要求本文中指定了兩個 K8s 網路原則 (如 knp1 和 knp2) 的 UUID。knp1 原則在出口規則規範中包含不受支援的 SCTP 通訊協定。執行匯入 API 時，轉換 knp1 網路原則過程中會發生錯誤，並且匯入作業提前結束。系統不會轉換下一個 K8s 網路原則 (knp2)，即使此網路原則有效也是如此。
繼續 如果匯入目前 K8s 網路原則時發生錯誤，系統將略過此原則並繼續匯入下一個 K8s 網路原則。API 回應會針對匯入作業期間略過的每個 K8s 網路原則傳回相應的錯誤訊息。
注意： 如果將匯入的 K8s 網路原則和略過的 K8s 網路原則套用於同一個網繭，則流量行為可能會發生變化。範例：
繼續看上一行中提到的相同範例。如果匯入 knp1 網路原則時發生錯誤，系統會繼續匯入 knp2 網路原則，並成功轉換此網路原則。API 回應會針對 knp1 網路原則傳回相同的錯誤訊息，此原則在轉換過程中失敗。
在單一 API 要求中匯入的 K8s 網路原則可以屬於不同的已登錄 Antrea Kubernetes 叢集。或者，它們可以屬於單一 Antrea Kubernetes 叢集內的多個命名空間。
如果命名空間包含多個 K8s 網路原則，我們建議在單一 API 要求中匯入這些原則。原因是命名空間內的 K8s 網路原則可能會相互關聯。這種做法有助於確保在將網路原則匯入至 NSX 後，流量行為不會發生變化。
- 匯入成功後，移至 NSX Manager UI，並檢視 Antrea 群組和 DFW 原則的組態。
- 選用：透過執行以下 kubectl 命令，檢視實現的 Antrea 叢集網路原則，檢查 ACNP 規格和 ClusterGroup 規格：
kubectl get acnp
kubectl get acnp <acnp-id> -o yaml
kubectl get cg <cg-id> -o yaml
- 選用：透過執行以下 kubectl 命令，確認 K8s 叢集中不會顯示已成功匯入至 NSX 的 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
可以發現，在 K8s 叢集中不再顯示匯入的 Kubernetes 網路原則 (k-np9 和 k-np11)。
不受支援的 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 網路原則只能包含一個值，轉換才能成功。目前不支援將In運算子中的多個值轉換為 Antrea 群組。
不同 Antrea NSX 介面卡 版本的行為
您可以依任何順序分別升級 Antrea NSX 介面卡 和 NSX。Antrea NSX 介面卡 中的新變更與 4.2 之前的 NSX 版本相容。
考慮下列案例：
NSX 環境的版本為 4.2，並且登錄了多個 Antrea Kubernetes 叢集。某些 Kubernetes 叢集具有新版本的 Antrea NSX 介面卡 (如 v0.15)，而某些叢集則具有舊版本的 Antrea NSX 介面卡 (如 v0.11)。在此情況下，舊版本的 Antrea NSX 介面卡 在轉換後不會自動從 Kubernetes 叢集中刪除原始 Kubernetes 網路原則。Kubernetes 管理員或命名空間管理員需要手動刪除原始 Kubernetes 網路原則。請注意，仍會執行到 DFW 原則的轉換。轉換的 DFW 允許原則和預設捨棄原則在 Kubernetes 叢集中作為 Antrea 叢集網路原則實現，並由 Antrea CNI 在原始 Kubernetes 網路原則之前進行評估。如果未從 Kubernetes 叢集中刪除原始 Kubernetes 原則，轉換的 DFW 原則中定義的流量行為可能會與原始 Kubernetes 網路原則衝突。
