Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

網路需求

本文僅說明安裝及運作裸機適用的 Distributed Cloud 軟體時，必須符合的網路需求。

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

外部網路需求

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

您可以透過 HTTPS、虛擬私人網路 (VPN) 或Dedicated Interconnect連線存取公開網際網路，藉此連線至 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 指定叢集內允許的 Service 數量。
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 和 Service 的 IP 位址範圍

您會指定一系列 IP 位址做為無類別跨網域路由 (CIDR) 區塊，供 Pod 使用，並指定另一個 CIDR 區塊，供 Kubernetes Service 的 ClusterIP 位址使用。使用私人位址空間中的 IP 位址，如 RFC 1918 所述。叢集設定檔會預先填入符合下表所述限制的值：

限制	Pod	服務
最低範圍	`/18` 的遮罩值 (16,384 個地址)	`/24` 的遮罩值 (256 個位址)
預填範圍	`/16` 的遮罩值 (65,536 個地址)	`/20` 的遮罩值 (4,096 個地址)
最大範圍	遮罩值 `/8` (16,777,216 個地址)	`/12` 的遮罩值 (1,048,576 個地址)

為避免與網路上可連線的 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 指派給每個節點的 CIDR 區塊大小，具體取決於設定的每個節點最多 Pod 數：

每節點的 Pod 數上限	每個節點的 CIDR 區塊	IP 位址數量
32	`/26`	64
33-64	`/25`	128
65-128	`/24`	256
129-250	`/23`	512

每個節點執行 250 個 Pod 時，Kubernetes 必須為每個節點保留 /23 CIDR 區塊。假設叢集為 clusterNetwork.pods.cidrBlocks 欄位使用預設值 /16，則叢集的節點上限為 (2^(23-16))=128 個節點。

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

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

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

下圖說明 Google Distributed Cloud 的多項重要網路概念，以及一種可能的網路設定。

Google Distributed Cloud 的典型網路設定

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

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

通訊埠用量

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

控制層節點

1.33 以上版本

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新管理員叢集節點	管理員工作站
TCP	傳入	2379 - 2381	etcd 伺服器用戶端 API、指標和健康狀態	`kube-apiserver` 和 `etcd`
TCP	傳入	2382 - 2384	etcd-events 伺服器用戶端 API、指標和健康狀態	`kube-apiserver` 和 `etcd-events`
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP	傳入	6444	Kubernetes API 伺服器	全部
TCP	傳入	9100	auth-proxy	`node-exporter`
TCP	傳入	9101	僅在 localhost 上提供節點指標 (適用於 1.28 以上版本)	`node-exporter`
TCP	傳入	9192 (預設值，但可以設定)	節點代理程式連接埠 (僅適用於使用節點代理程式的叢集) (適用於 1.33 以上版本)	`node-agent-port`
TCP	傳入	9977	從 API 伺服器接收稽核事件	`audit-proxy`
TCP	傳入	10250	`kubelet` 個 API	自身和控制層
TCP	傳入	10256	節點健康狀態檢查	全部
TCP	傳入	10257	`kube-controller-manager` (1.28 以上版本會變更通訊埠編號)	指標本身
TCP	傳入	10259	`kube-scheduler` (1.28 以上版本會變更通訊埠編號)	指標本身
TCP	傳入	11002	GKE Identity Service 核心容器會透過 `hostPort` 繫結至連接埠 (適用於 1.29 以上版本)	指標本身
TCP	傳入	14443	ANG Webhook 服務	`kube-apiserver` 和 `ang-controller-manager`

1.29 至 1.32 版

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新管理員叢集節點	管理員工作站
TCP	傳入	2379 - 2381	etcd 伺服器用戶端 API、指標和健康狀態	`kube-apiserver` 和 `etcd`
TCP	傳入	2382 - 2384	etcd-events 伺服器用戶端 API、指標和健康狀態	`kube-apiserver` 和 `etcd-events`
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP	傳入	6444	Kubernetes API 伺服器	全部
TCP	傳入	9100	auth-proxy	`node-exporter`
TCP	傳入	9101	僅在 localhost 上提供節點指標 (適用於 1.28 以上版本)	`node-exporter`
TCP	傳入	9977	從 API 伺服器接收稽核事件	`audit-proxy`
TCP	傳入	10250	`kubelet` 個 API	自身和控制層
TCP	傳入	10256	節點健康狀態檢查	全部
TCP	傳入	10257	`kube-controller-manager` (1.28 以上版本會變更通訊埠編號)	指標本身
TCP	傳入	10259	`kube-scheduler` (1.28 以上版本會變更通訊埠編號)	指標本身
TCP	傳入	11002	GKE Identity Service 核心容器會透過 `hostPort` 繫結至連接埠 (適用於 1.29 以上版本)	指標本身
TCP	傳入	14443	ANG Webhook 服務	`kube-apiserver` 和 `ang-controller-manager`

1.28 版

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新管理員叢集節點	管理員工作站
TCP	傳入	2379 - 2381	etcd 伺服器用戶端 API、指標和健康狀態	`kube-apiserver` 和 `etcd`
TCP	傳入	2382 - 2384	etcd-events 伺服器用戶端 API、指標和健康狀態	`kube-apiserver` 和 `etcd-events`
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP	傳入	6444	Kubernetes API 伺服器	全部
TCP	傳入	8444	GKE Identity Service 核心容器會透過下列方式繫結至連接埠： `hostPort` (僅適用於 1.28 版)	全部
TCP	傳入	9100	auth-proxy	`node-exporter`
TCP	傳入	9101	僅在 localhost 上提供節點指標 (適用於 1.28 以上版本)	`node-exporter`
TCP	傳入	9977	從 API 伺服器接收稽核事件	`audit-proxy`
TCP	傳入	10250	`kubelet` 個 API	自身和控制層
TCP	傳入	10256	節點健康狀態檢查	全部
TCP	傳入	10257	`kube-controller-manager` (1.28 以上版本會變更通訊埠編號)	指標本身
TCP	傳入	10259	`kube-scheduler` (1.28 以上版本會變更通訊埠編號)	指標本身
TCP	傳入	14443	ANG Webhook 服務	`kube-apiserver` 和 `ang-controller-manager`

1.16 版

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新管理員叢集節點	管理員工作站
TCP	傳入	2379 - 2381	etcd 伺服器用戶端 API、指標和健康狀態	`kube-apiserver` 和 `etcd`
TCP	傳入	2382 - 2384	etcd-events 伺服器用戶端 API、指標和健康狀態 (適用於 1.16 以上版本)	`kube-apiserver` 和 `etcd-events`
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP	傳入	6444	Kubernetes API 伺服器	全部
TCP	傳入	9100	放送指標	`node-exporter`
TCP	傳入	9443	控制層元件的服務/Proxy 指標 (這個通訊埠需求適用於 1.16 以下的叢集版本)	`kube-control-plane-metrics-proxy`
TCP	傳入	9977	從 API 伺服器接收稽核事件	`audit-proxy`
TCP	傳入	10250	`kubelet` 個 API	自身和控制層
TCP	傳入	10251	`kube-scheduler`	指標本身
TCP	傳入	10252	`kube-controller-manager`	指標本身
TCP	傳入	10256	節點健康狀態檢查	全部
TCP	傳入	14443	ANG Webhook 服務	`kube-apiserver` 和 `ang-controller-manager`

1.15 以下版本

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新管理員叢集節點	管理員工作站
TCP	傳入	2379 - 2381	etcd 伺服器用戶端 API、指標和健康狀態	`kube-apiserver` 和 `etcd`
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP	傳入	6444	Kubernetes API 伺服器	全部
TCP	傳入	9100	放送指標	`node-exporter`
TCP	傳入	9443	控制層元件的服務/Proxy 指標 (這個通訊埠需求適用於 1.16 以下的叢集版本)	`kube-control-plane-metrics-proxy`
TCP	傳入	9977	從 API 伺服器接收稽核事件	`audit-proxy`
TCP	傳入	10250	`kubelet` 個 API	自身和控制層
TCP	傳入	10251	`kube-scheduler`	指標本身
TCP	傳入	10252	`kube-controller-manager`	指標本身
TCP	傳入	10256	節點健康狀態檢查	全部
TCP	傳入	14443	ANG Webhook 服務	`kube-apiserver` 和 `ang-controller-manager`

工作站節點

1.33 以上版本

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新使用者叢集節點	管理員叢集節點
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP	傳入	9100	auth-proxy	`node-exporter`
TCP	傳入	9101	僅在 localhost 上提供節點指標 (適用於 1.28 以上版本)	`node-exporter`
TCP	傳入	9192 (預設值，但可以設定)	節點代理程式連接埠 (僅適用於使用節點代理程式的叢集) (適用於 1.33 以上版本)	`node-agent-port`
TCP	傳入	10250	`kubelet` 個 API	自身和控制層
TCP	傳入	10256	節點健康狀態檢查	全部
TCP	傳入	30000 - 32767	`NodePort` 項服務	指標本身

1.29 至 1.32 版

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新使用者叢集節點	管理員叢集節點
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP	傳入	9100	auth-proxy	`node-exporter`
TCP	傳入	9101	僅在 localhost 上提供節點指標 (適用於 1.28 以上版本)	`node-exporter`
TCP	傳入	10250	`kubelet` 個 API	自身和控制層
TCP	傳入	10256	節點健康狀態檢查	全部
TCP	傳入	30000 - 32767	`NodePort` 項服務	指標本身

1.28 版

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新使用者叢集節點	管理員叢集節點
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP	傳入	9100	auth-proxy	`node-exporter`
TCP	傳入	9101	僅在 localhost 上提供節點指標 (適用於 1.28 以上版本)	`node-exporter`
TCP	傳入	10250	`kubelet` 個 API	自身和控制層
TCP	傳入	10256	節點健康狀態檢查	全部
TCP	傳入	30000 - 32767	`NodePort` 項服務	指標本身

1.16 版

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新使用者叢集節點	管理員叢集節點
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP	傳入	9100	放送指標	`node-exporter`
TCP	傳入	10250	`kubelet` 個 API	自身和控制層
TCP	傳入	10256	節點健康狀態檢查	全部
TCP	傳入	30000 - 32767	`NodePort` 項服務	指標本身

1.15 以下版本

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新使用者叢集節點	管理員叢集節點
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP	傳入	9100	放送指標	`node-exporter`
TCP	傳入	10250	`kubelet` 個 API	自身和控制層
TCP	傳入	10256	節點健康狀態檢查	全部
TCP	傳入	30000 - 32767	`NodePort` 項服務	指標本身

負載平衡器節點

1.33 以上版本

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新使用者叢集節點	管理員叢集節點
TCP	傳入	443	叢集管理您可以在叢集設定檔中，使用 `controlPlaneLBPort` 欄位設定這個連接埠。	全部
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP 和 UDP	傳入	7946	MetalLB 健康狀態檢查	負載平衡器節點
TCP	傳入	9192 (預設值，但可以設定)	節點代理程式連接埠 (僅適用於使用節點代理程式的叢集) (適用於 1.33 以上版本)	`node-agent-port`
TCP	傳入	10256	節點健康狀態檢查	全部
TCP	傳入	11000	HAProxy 指標的監聽通訊埠 (不可變更) (適用於 1.29 以上版本)	全部
TCP	傳入	11001	GKE 身分認證服務的監聽通訊埠 (不可變更) (適用於 1.29 以上版本)	全部

1.29 至 1.32 版

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新使用者叢集節點	管理員叢集節點
TCP	傳入	443	叢集管理您可以在叢集設定檔中，使用 `controlPlaneLBPort` 欄位設定這個連接埠。	全部
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP 和 UDP	傳入	7946	MetalLB 健康狀態檢查	負載平衡器節點
TCP	傳入	10256	節點健康狀態檢查	全部
TCP	傳入	11000	HAProxy 指標的監聽通訊埠 (不可變更) (適用於 1.29 以上版本)	全部
TCP	傳入	11001	GKE 身分認證服務的監聽通訊埠 (不可變更) (適用於 1.29 以上版本)	全部

1.28 版

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新使用者叢集節點	管理員叢集節點
TCP	傳入	443	叢集管理您可以在叢集設定檔中，使用 `controlPlaneLBPort` 欄位設定這個連接埠。	全部
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP 和 UDP	傳入	7946	MetalLB 健康狀態檢查	負載平衡器節點
TCP	傳入	8443	GKE 身分認證服務的監聽通訊埠 (不可變更) (僅適用於 1.28 版)	全部
TCP	傳入	10256	節點健康狀態檢查	全部

1.16 版

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新使用者叢集節點	管理員叢集節點
TCP	傳入	443	叢集管理您可以在叢集設定檔中，使用 `controlPlaneLBPort` 欄位設定這個連接埠。	全部
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP	傳入	7946	MetalLB 健康狀態檢查	負載平衡器節點
TCP	傳入	10256	節點健康狀態檢查	全部

1.15 以下版本

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新使用者叢集節點	管理員叢集節點
TCP	傳入	443	叢集管理您可以在叢集設定檔中，使用 `controlPlaneLBPort` 欄位設定這個連接埠。	全部
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP	傳入	7946	MetalLB 健康狀態檢查	負載平衡器節點
TCP	傳入	10256	節點健康狀態檢查	全部

多叢集通訊埠需求

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

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新叢集節點	所有節點
TCP	傳入	443	新增叢集的 Kubernetes API 伺服器您可以使用 `controlPlaneLBPort` 欄位，在叢集設定中設定這個連接埠。	控制層和負載平衡器節點

設定 firewalld 通訊埠

您不需要停用 firewalld，即可在 Red Hat Enterprise Linux (RHEL) 上執行 Google Distributed Cloud。如要使用 firewalld，您必須開啟控制層、worker 和負載平衡器節點使用的 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。

Worker 節點設定範例

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

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 的補充設定

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

列出節點的有效介面，找出主要節點介面：
```
firewall-cmd --list-interfaces
```
根據 Linux 電腦介面的命名慣例，主要介面名稱可能如下：eth0、eno1、ens1 或 enp2s0。
列出節點的區域，找出主要介面使用的區域：
```
firewall-cmd --list-all-zones
```
舉例來說，如果主要介面是 eno1，回應的下列部分會指出主要介面位於 public 區域：
```
...
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eno1
  sources:
  ...
```

執行下列 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：受控環境中的預先定義區域，可接受所有網路連線。
您定義的自訂區域名稱。

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

舉例來說，如果您使用 Portworx 管理具狀態的工作負載，請參閱「Portworx 網路需求」一文，瞭解需要保持開啟的通訊埠。

針對供應商文件列出的每個連接埠，執行下列指令：
```
firewall-cmd --permanent --zone=public --add-port=PORT_INFO
```
將 PORT_INFO 替換為埠號或埠號範圍，然後輸入通訊協定。例如：10250-10252/tcp。

確認通訊埠設定

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

執行下列 Network Mapper 指令，查看開啟的通訊埠：
```
nmap localhost
```

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

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

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

firewalld 的已知問題

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

對 firewalld 進行的變更會移除 iptables 鏈結，包括但不限於：

正在重新啟動「firewalld」，使用「systemctl」
使用指令列用戶端 (firewall-cmd --reload) 重新載入 firewalld

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

使用下列指令找出並刪除 anetd Pod，重新啟動 anetd：
```
kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
```
將 ANETD_XYZ 替換為 anetd Pod 的名稱。

網路需求 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

外部網路需求

內部網路需求

Pod 和 Service 網路

Pod 和 Service 的 IP 位址範圍

每節點的 Pod 數上限

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

通訊埠用量

控制層節點

1.33 以上版本

1.29 至 1.32 版

1.28 版

1.16 版

1.15 以下版本

工作站節點

1.33 以上版本

1.29 至 1.32 版

1.28 版

1.16 版

1.15 以下版本

負載平衡器節點

1.33 以上版本

1.29 至 1.32 版

1.28 版

1.16 版

1.15 以下版本

多叢集通訊埠需求

設定 firewalld 通訊埠

控制層節點設定範例

Worker 節點設定範例

負載平衡器節點設定範例

RHEL 9.2 和 9.4 的補充設定

確認通訊埠設定

firewalld 的已知問題

網路需求