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

網路需求

如要安裝及操作僅適用於裸機的 Distributed Cloud 軟體，網路必須符合本文件中的規定。這些需求涵蓋與 Google 的外部連線能力、叢集節點與負載平衡器之間的第 2 層和第 3 層連線能力、Pod 和 Service 的 IP 位址範圍，以及叢集元件使用的通訊埠。如果節點執行 Red Hat Enterprise Linux (RHEL) 且啟用 firewalld，本文也會說明如何開啟必要通訊埠。

外部網路需求

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 位址範圍

您需要指定無類別跨網域路由 (CIDR) 區塊形式的 IP 位址範圍，用於 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 根據每個節點設定的 Pod 數量上限，指派給每個節點的 CIDR 區塊大小：

每節點的 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 和 Service 數量及其他因素如何影響叢集擴充性，請參閱「擴充 Google Distributed Cloud 叢集」。

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

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

Google Distributed Cloud 典型網路設定

請考量下列資訊，確保符合網路需求：

控制層節點會執行負載平衡器，且都具備第 2 層連線能力，而其他連線 (包括 worker 節點) 只需要第 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	僅在本機主機上提供節點指標 (適用於 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 身分認證服務核心容器透過 `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	僅在本機主機上提供節點指標 (適用於 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 身分認證服務核心容器透過 `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 身分認證服務核心容器透過 `hostPort` 繫結至通訊埠 (僅適用於 1.28 版)	全部
TCP	傳入	9100	auth-proxy	`node-exporter`
TCP	傳入	9101	僅在本機主機上提供節點指標 (適用於 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`

worker 節點

1.33 以上版本

通訊協定	方向	通訊埠範圍	目的	使用端
TCP	傳入	22	佈建及更新使用者叢集節點	管理員叢集節點
TCP	兩者並用	4240	CNI 健康狀態檢查	全部
UDP	傳入	6081	GENEVE 封裝	指標本身
TCP	傳入	9100	auth-proxy	`node-exporter`
TCP	傳入	9101	僅在本機主機上提供節點指標 (適用於 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	僅在本機主機上提供節點指標 (適用於 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	僅在本機主機上提供節點指標 (適用於 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 節點設定範例

下列指令區塊示範如何在執行 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 的補充設定

1.29.400 以上版本正式支援 Red Hat Enterprise Linux (RHEL) 9.2 和 9.4 版。使用 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。

確認通訊埠設定

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

執行下列 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 鏈結。anetd Pod 啟動時，會新增 iptables 鏈結。失去 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 以下版本

worker 節點

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 的已知問題

網路需求