網路需求

本文概述在裸機上安裝及運作 Google Distributed Cloud (僅限軟體) 的網路需求。

本文適用於管理基礎技術基礎架構生命週期，以及為機構設計和建構網路的管理員、架構師、操作人員和網路專家。如要進一步瞭解我們在Google Cloud 內容中提及的常見角色和範例工作，請參閱「常見的 GKE Enterprise 使用者角色和工作」。

外部網路需求

Google Distributed Cloud 必須連上網際網路才能運作。Google Distributed Cloud 會從 Artifact Registry 擷取叢集元件，並透過 Connect 代理程式註冊叢集。

您可以透過 HTTPS、虛擬私人網路 (VPN) 或專屬互連網路連線，使用公開網際網路連線至 Google。

如果您用於管理員工作站和叢集節點的機器使用 Proxy 伺服器存取網際網路，Proxy 伺服器必須允許某些特定連線。詳情請參閱「透過 Proxy 安裝」一文的先決條件一節。

內部網路需求

Google Distributed Cloud 可在叢集節點之間使用第 2 層或第 3 層連線。負載平衡器節點可以是控制層節點，也可以是一組專屬節點。詳情請參閱「選擇及設定負載平衡器」。

使用搭配 MetalLB 的第 2 層套裝組合負載平衡 (spec.loadBalancer.mode: bundled 和 spec.loadBalancer.type: layer2) 時，負載平衡器節點需要第 2 層鄰近性。無論您是在控制層節點上執行負載平衡器，還是在一組專屬的負載平衡節點中執行，都適用第 2 層鄰近性規定。使用 BGP 進行套裝組合負載平衡支援第 3 層通訊協定，因此不需要嚴格的第 2 層鄰接。

負載平衡器機器的需求如下：

• 如要使用隨附的第 2 層負載平衡功能，特定叢集的所有負載平衡器都必須位於同一個第 2 層網域。控制層節點也必須位於同一個第 2 層網域。
• 如要使用隨附的第 2 層負載平衡功能，所有虛擬 IP 位址 (VIP) 都必須位於負載平衡器機器的子網路中，且可路由至該子網路的閘道。
• 使用者有責任允許輸入負載平衡器流量。

Pod 和 Service 網路

Service 和 Pod 可用的 IP 位址範圍是在叢集設定檔中指定。以下各節將討論位址範圍的最小和最大限制，以及規劃叢集安裝作業時需要考量的一些相關因素。

叢集中的 Pod 和 Service 數量受下列設定控管：

• clusterNetwork.pods.cidrBlocks 指定叢集允許的 Pod 數量。

• clusterNetwork.services.cidrBlocks 指定叢集中允許的服務數量。

• nodeConfig.podDensity.maxPodsPerNode 指定可在單一節點上執行的 Pod 數量上限。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin-basic
  namespace: cluster-admin-basic
spec:
  type: admin
  profile: default
  ...
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  ...
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250

Pod 和服務的 IP 位址範圍

您會以無類別跨網域路由 (CIDR) 區塊的形式，指定要用於 Pod 的 IP 位址範圍，並以另一個 CIDR 區塊的形式，指定要用於 Kubernetes 服務 ClusterIP 位址的 IP 位址範圍。使用私人位址空間中的 IP 位址，如 RFC 1918 所述。叢集設定檔會預先填入值，這些值會落在下表所述的限制內：

為避免與網路上可連線的 IP 位址重疊，您可能需要使用與預填值不同的 CIDR 範圍。具體來說，Service 和 Pod 範圍不得與下列項目重疊：

• 任何叢集內節點的 IP 位址

• 控制層節點和負載平衡器使用的 VIP

• DNS 伺服器或 NTP 伺服器的 IP 位址

如果發現 IP 位址重疊，預檢會禁止建立及升級叢集。

建立叢集後，您可以增加服務網路範圍 (clusterNetwork.services.cidrBlocks)，但無法減少或變更已分配的 IP 位址數量。您只能變更 CIDR 區塊的後置字元，減少遮罩值以增加 IP 位址數量。

clusterNetwork.pods.cidrBlocks 和 nodeConfig.podDensity.maxPodsPerNode (詳見下節) 都是不可變動的，因此請仔細規劃叢集的未來成長，以免節點容量不足。如要查看根據測試結果得出的建議叢集 Pod 數上限、節點 Pod 數上限和叢集節點數上限，請參閱「限制」一文。

每節點的 Pod 數上限

在裸機上，Google Distributed Cloud 可讓您為每個節點設定最多 250 個 Pod。Kubernetes 會為每個節點指派 CIDR 區塊，讓每個 Pod 擁有一個不重複的 IP 位址。Pod CIDR 區塊的大小對應每個節點的最大 Pod 數。

下表列出 Kubernetes 依據每個節點設定的最大 Pod 數，指派給每個節點的 CIDR 區塊大小：

如果每個節點執行 250 個 Pod，Kubernetes 就必須為每個節點保留 /23 CIDR 區塊。假設叢集在 clusterNetwork.pods.cidrBlocks 欄位中使用預設值 /16，則叢集最多可有 (2^(23-16))=128 個節點。

如果您打算將叢集擴展到超過這個限制，強烈建議您將 clusterNetwork.pods.cidrBlocks 設為比預填值大得多的 Pod CIDR 區塊。

如要進一步瞭解 Pod 和 Service 數量及其他因素如何影響叢集擴充性，請參閱「擴大 Google Distributed Cloud 叢集」。

高可用性的單一使用者叢集部署作業

下圖說明 Google Distributed Cloud 的幾個重要網路概念，以及可能的網路設定。

請參考下列資訊，瞭解網路需求：

• 控制層節點會執行負載平衡器，且都具有第 2 層連線能力，而其他連線 (包括工作站節點) 只需要第 3 層連線能力。
• 設定檔會定義工作站節點集區的 IP 位址。 設定檔也會定義 VIP，用於下列用途：
  • 服務
  • Ingress
  • 透過 Kubernetes API 存取控制層
• 你必須連上 Google Cloud。

通訊埠用量

本節說明 Google Distributed Cloud 叢集的連接埠需求。下表顯示叢集和負載平衡器節點上的 Kubernetes 元件如何使用 UDP 和 TCP 連接埠。

控制層節點

工作站節點

負載平衡器節點

多叢集通訊埠需求

在多叢集設定中，新增的叢集必須包含下列通訊埠，才能與管理員叢集通訊。

設定 firewalld 通訊埠

您不必停用 firewalld，即可在 Red Hat Enterprise Linux (RHEL) 上執行 Google Distributed Cloud。如要使用 firewalld，您必須開啟控制平面、工作站和負載平衡器節點使用的 UDP 和 TCP 通訊埠，如本頁面「通訊埠使用情形」一節所述。下列範例設定說明如何使用 firewall-cmd (firewalld 指令列公用程式) 開啟連接埠。您應以超級使用者身分執行指令。

控制層節點設定範例

下列指令區塊提供範例，說明如何在執行控制平面節點的伺服器上開啟必要通訊埠：

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=10257/tcp
firewall-cmd --permanent --zone=public --add-port=10259/tcp
firewall-cmd --permanent --zone=public --add-port=2379-2380/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

如要瞭解您打算使用的叢集版本有哪些特定通訊埠需求，請參閱前一節的「通訊埠使用情形」。請視情況更新範例指令。

將 PODS_CIDR 替換為在 clusterNetwork.pods.cidrBlocks 欄位中為 Pod 保留的 CIDR 區塊。Pod 的預設 CIDR 區塊為 192.168.0.0/16。

工作站節點設定範例

下列指令區塊提供範例，說明如何在執行工作節點的伺服器上開啟必要連接埠：

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

如要瞭解您打算使用的叢集版本有哪些特定通訊埠需求，請參閱前一節的「通訊埠使用情形」。請視情況更新範例指令。

將 PODS_CIDR 替換為在 clusterNetwork.pods.cidrBlocks 欄位中為 Pod 保留的 CIDR 區塊。Pod 的預設 CIDR 區塊為 192.168.0.0/16。

負載平衡器節點設定範例

下列指令區塊提供範例，說明如何在執行負載平衡器節點的伺服器上開啟必要通訊埠：

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=7946/tcp
firewall-cmd --permanent --zone=public --add-port=7946/udp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

如要瞭解您打算使用的叢集版本有哪些特定通訊埠需求，請參閱前一節的「通訊埠使用情形」。請視情況更新範例指令。

將 PODS_CIDR 替換為在 clusterNetwork.pods.cidrBlocks 欄位中為 Pod 保留的 CIDR 區塊。Pod 的預設 CIDR 區塊為 192.168.0.0/16。

RHEL 9.2 和 9.4 的補充設定

在 1.29.400 以上版本中，Red Hat Enterprise Linux (RHEL) 9.2 和 9.4 版已正式推出。使用 RHEL 9.2 和 9.4 版時，您必須在節點上執行額外的 firewalld 設定，服務和 Pod 才能正常運作：

1. 列出節點的有效介面，找出主要節點介面：

   firewall-cmd --list-interfaces
   

   根據 Linux 機器介面的命名慣例，主要介面名稱可能如下：eth0、eno1、ens1 或 enp2s0。

2. 列出節點的區域，找出主要介面使用的區域：

   firewall-cmd --list-all-zones
   

   舉例來說，如果主要介面為 eno1，回應的下列部分會指出主要介面位於 public 區域：

   ...
   public (active)
     target: default
     icmp-block-inversion: no
     interfaces: eno1
     sources:
     ...
   

3. 執行下列 firewalld 指令，為 RHEL 9.2 或 9.4 設定自訂區域和政策詳細資料：

   firewall-cmd --permanent --new-zone=cilium
   firewall-cmd --permanent --zone=cilium --add-interface=cilium_host
   firewall-cmd --permanent --zone=cilium --set-target ACCEPT
   firewall-cmd --permanent --zone=cilium --add-masquerade
   firewall-cmd --permanent --zone=cilium --add-forward
   firewall-cmd --permanent --new-policy cilium-host-port-forwarding
   firewall-cmd --permanent --policy cilium-host-port-forwarding --add-ingress-zone IN_ZONE
   firewall-cmd --permanent --policy cilium-host-port-forwarding --add-egress-zone cilium
   firewall-cmd --permanent --policy cilium-host-port-forwarding --set-target ACCEPT
   firewall-cmd --reload
   

   根據您在先前步驟中找到的內容，將 IN_ZONE 替換為下列其中一個值：

   • public：預先定義的區域，適用於僅接受特定連入連線的公共區域。
   • trusted：受控環境中的預先定義區域，可接受所有網路連線。
   • 您定義的自訂區域名稱。

4. 請按照供應商的說明文件設定儲存解決方案。

   舉例來說，如果您使用 Portworx 管理有狀態的工作負載，請參閱 Portworx 網路需求，瞭解需要保持開啟的連接埠。

   針對廠商文件中列出的每個連接埠，執行下列指令：

   firewall-cmd --permanent --zone=public --add-port=PORT_INFO
   

   請將 PORT_INFO 改成通訊埠編號或通訊埠編號範圍，並在後方接上通訊協定。例如：10250-10252/tcp。

確認通訊埠設定

如要驗證連接埠設定，請在控制層、工作站和負載平衡器節點上執行下列步驟：

1. 執行下列網路對應器指令，查看開啟的連接埠：

   nmap localhost
   

2. 執行下列指令，取得 firewalld 設定：

   firewall-cmd --info-zone=public
   firewall-cmd --info-zone=k8s-pods
   firewall-cmd --list-all-policies
   

3. 如有必要，請重新執行前幾節的指令，正確設定節點。您可能需要以超級使用者身分執行指令。

firewalld 的已知問題

在 Red Hat Enterprise Linux (RHEL) 上執行 Google Distributed Cloud 時，如果啟用 firewalld，變更 firewalld 可能會移除主機網路上的 Cilium iptables 鏈結。iptables 鏈結會在 anetd Pod 啟動時新增。Cilium iptables 鏈結遺失會導致節點上的 Pod 失去節點外部的網路連線。

移除 iptables 鏈結的 firewalld 變更包括但不限於：

• 正在重新啟動「firewalld」，使用「systemctl」

• 使用指令列用戶端 (firewall-cmd --reload) 重新載入 firewalld

如要套用 firewalld 變更，但不要移除 iptables 鏈結，請在節點上重新啟動 anetd：

1. 使用下列指令找出並刪除 anetd Pod，以重新啟動 anetd：

   kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
   

   將 ANETD_XYZ 替換為 anetd Pod 的名稱。