透過 Google Distributed Cloud,您可以設定來源網路位址轉譯 (SNAT),為使用者叢集的特定輸出流量提供可預測的來源 IP 位址。
本文說明如何為使用者叢集設定輸出 NAT 閘道。
簡介
有時,您會在使用者叢集中執行 Pod,但這些 Pod 需要將封包傳送至機構中執行的元件,而不是叢集外部。您可能會想設計這些外部元件,根據一組已知的來源 IP 位址篩選連入網路流量。
以下列舉幾種情況:
資料庫前方有防火牆,只允許透過 IP 位址存取。管理資料庫防火牆的團隊,與管理使用者叢集的團隊不同。
使用者叢集中的工作負載必須透過網際網路存取第三方 API。基於安全考量,API 供應商會使用 IP 位址做為身分,驗證及授權流量。
有了輸出 NAT 閘道,您就能精細控管叢集輸出網路流量時使用的來源 IP 位址。
定價
預先發布期間使用這項功能不會產生費用。
輸出 NAT 閘道的運作方式
一般來說,當 Pod 將封包傳送至叢集外部時,封包會透過 SNAT 轉換,並使用 Pod 執行所在節點的 IP 位址。
如果已設定輸出 NAT 閘道,您可以指定先將特定輸出封包傳送至專用閘道節點。閘道節點上的網路介面會設定兩個 IP 位址:主要 IP 位址和輸出來源 IP 位址。
選取封包以使用輸出 NAT 閘道後,封包會從閘道節點離開叢集,並透過網路介面上設定的輸出來源 IP 位址進行 SNAT 轉譯。
下圖說明封包流程:
在上圖中,您可以看到從 Pod 傳送封包的流程。
在 IP 位址為 192.168.1.1 的節點上,IP 位址為 10.10.10.1 的 Pod 會產生輸出封包。
封包符合輸出規則,因此會轉送至閘道節點。
閘道節點會將來源 IP 位址變更為 192.168.1.100,並將封包傳送出叢集。
回程流量會回到閘道節點,目的地為 192.168.1.100。
閘道節點會使用 conntrack 將目的地 IP 位址修改為 10.10.10.1。
封包會視為叢集內流量,轉送至原始節點,並傳回原始 Pod。
職位
本主題會提到兩種角色:
叢集管理員。這個人會建立使用者叢集,並指定 Anthos Network Gateway 要使用的浮動 IP 位址。
開發人員。這個人會在使用者叢集上執行工作負載,並建立輸出政策。
啟用輸出 NAT 閘道
本節內容適用於叢集管理員。
如要設定輸出 NAT 閘道,請使用使用者叢集設定檔中的 enableDataplaneV2
和 advancedNetworking
欄位,並建立一或多個 NetworkGatewayGroup 物件。
在叢集設定檔中,將下列欄位設為 true
:
enableDataplaneV2: true ... advancedNetworking: true
指定浮動 IP 位址
本節內容適用於叢集管理員。
選擇要用做輸出來源位址的一組 IP 位址。這些 IP 位址稱為「浮動 IP 位址」,因為 Network Gateway Group 會視需要將這些位址指派給所選節點的網路介面,做為輸出閘道。
浮動 IP 位址必須與節點 IP 位址位於同一個子網路。
浮動 IP 位址集不得與您為節點指定的 IP 位址集重疊。
舉例來說,假設子網路的位址範圍為 192.168.1.0/24。假設您選擇使用 192.168.1.1 到 192.168.1.99 做為節點。然後您可以使用 192.168.1.100 到 192.168.1.104 做為浮動 IP 位址。
建立 NetworkGatewayGroup 物件
本節內容適用於叢集管理員。
以下是 NetworkGatewayGroup 物件的資訊清單範例:
kind: NetworkGatewayGroup apiVersion: networking.gke.io/v1 metadata: namespace: kube-system name: default spec floatingIPs: - 192.168.1.100 - 192.168.1.101 - 192.168.1.102 - 192.168.1.103 - 192.168.1.104
將 floatingIPs
陣列替換為浮動 IP 位址,然後將資訊清單儲存為名為 my-ngg.yaml
的檔案。
建立 NetworkGatewayGroup 物件:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-ngg.yaml
輸出 NAT 政策範例
本節內容適用於開發人員。
以下是 EgressNatPolicy 自訂資源的範例:
kind: EgressNATPolicy apiVersion: networking.gke.io/v1 metadata: name: alice-paul spec: sources: - namespaceSelector: matchLabels: user: alice podSelector: matchLabels: role: frontend - namespaceSelector: matchLabels: user: paul podSelector: matchLabels: role: frontend action: SNAT destinations: - cidr: 8.8.8.0/24 gatewayRef: name: default namespace: kube-system
在上述資訊清單中,我們看到:
如果 Pod 符合下列任一條件,即為輸出 NAT 的候選項目:
Pod 具有
role: frontend
標籤,且 Pod 位於具有user: alice
標籤的命名空間中。Pod 具有
role: frontend
標籤,且 Pod 位於具有user: paul
標籤的命名空間中。
從候選 Pod 到 8.8.8.0/24 範圍內位址的流量,會傳送至輸出 NAT 閘道。
gatewayRef
區段會決定輸出來源 IP 位址。EgressNATPolicy 自訂資源會使用gatewayRef.name
和gatewayRef.namespace
值尋找 NetworkGatewayGroup 物件。這項政策會使用 NetworkGatewayGroup 的其中一個浮動 IP 位址,做為輸出流量的來源 IP 位址。如果相符的 NetworkGatewayGroup 中有多個浮動 IP 位址,政策會使用floatingIPs
清單中的第一個 IP 位址,並忽略任何其他 IP 位址。如果gatewayRef
區段中有無效欄位,系統就無法套用 EgressNATPolicy 物件。
建立 EgressNATPolicy 物件
建立自己的 EgressNATPolicy 資訊清單。將 metadata.name
設為 "my-policy"
。
將資訊清單儲存到名為 my-policy.yaml
的檔案。
建立 EgressNatPolicy 物件:
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f my-policy.yaml
查看輸出 NAT 政策的相關資訊
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get egressnatpolicy my-policy --output yaml kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkgatewaygroup --namespace kube-system --output yaml kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe egressnatpolicy my-policy
作業順序
輸出 NAT 政策與網路政策 API 相容。系統會在輸出 NAT 政策之前評估網路政策。如果網路政策規定要捨棄封包,無論輸出 NAT 政策為何,封包都會遭到捨棄。
多個輸出政策
如先前所述,每個 EgressNATPolicy 都會使用 NetworkGatewayGroup 中與 gatewayRef.name
和 gatewayRef.namespace
相符的 floatingIPs
清單中的第一個 IP 位址。如果您建立多項政策,並打算使用不同的 IP 位址,則需要建立多個 NetworkGatewayGroup 物件,並分別參照這些物件。如果建立多項政策,每項政策的 gatewayRef
物件都必須是專屬的。
每個 NetworkGatewayGroup
資源都必須包含專屬的浮動 IP 位址。
如要設定多個 EgressNATPolicy
物件使用相同的 IP 位址,請為兩者使用相同的 gatewayRef.name
和 gatewayRef.namespace
。
如要設定多個輸出政策和多個閘道物件,請按照下列步驟操作:
在
kube-system
命名空間中建立閘道物件,管理每個浮動 IP 位址。一般來說,每個輸出政策都應有對應的閘道物件,確保系統分配正確的 IP 位址。然後使用
kubectl
驗證每個閘道物件,取得浮動 IP 位址的分配狀態:kind: NetworkGatewayGroup apiVersion: networking.gke.io/v1 metadata: namespace: kube-system name: gateway1 spec: floatingIPs: - 192.168.1.100 status: ... floatingIPs: 192.168.1.100: worker1 --- kind: NetworkGatewayGroup apiVersion: networking.gke.io/v1 metadata: namespace: kube-system name: gateway2 spec: floatingIPs: - 192.168.1.101 status: ... floatingIPs: 192.168.1.101: worker2 --- kind: NetworkGatewayGroup apiVersion: networking.gke.io/v1 metadata: namespace: kube-system name: gateway3 spec: floatingIPs: - 192.168.1.102 status: ... floatingIPs: 192.168.1.102: worker1
建立參照閘道物件的多項政策,例如在上一個步驟中建立的
gateway1
:kind: EgressNATPolicy apiVersion: networking.gke.io/v1 metadata: name: egresspolicy1 spec: ... gatewayRef: name: gateway1 namespace: kube-system --- kind: EgressNATPolicy apiVersion: networking.gke.io/v1 metadata: name: egresspolicy2 spec: ... gatewayRef: name: gateway2 namespace: kube-system --- kind: EgressNATPolicy apiVersion: networking.gke.io/v1 metadata: name: egresspolicy3 spec: ... gatewayRef: name: gateway3 namespace: kube-system
(選用) 指定要放置浮動 IP 位址的節點
NetworkGatewayGroup
資源支援節點選取器。如要指定一組節點,供系統考慮是否要託管浮動 IP 位址,您可以將節點選取器新增至 NetworkGatewayGroup
物件,如下列範例所示:
kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
namespace: cluster-cluster1
name: default
spec:
floatingIPs:
- 192.168.1.100
- 192.168.1.101
- 192.168.1.102
nodeSelector:
node-type: "egressNat"
節點選取器會比對具有指定標籤的節點,且只有這些節點會納入考量,用來代管浮動 IP 位址。如果指定多個選取器,其邏輯為加法,因此節點必須符合每個標籤,才會被視為可代管浮動 IP 位址。如果沒有許多具有相符標籤的節點,節點選取器可能會降低浮動 IP 位址放置位置的高可用性 (HA) 品質。