GKE 網路的最佳做法

本頁面列出設定 Google Kubernetes Engine (GKE) 叢集網路選項的最佳做法。這份指南適用於雲端架構師和網路工程師，提供叢集設定建議，協助規劃架構，適用於大多數 GKE 叢集。建立 GKE 叢集之前，建議您先詳閱本頁所有章節，瞭解 GKE 支援的網路選項及其影響。

您選擇的網路選項會影響 GKE 叢集的架構。部分選項設定後就無法變更，必須重新建立叢集。

閱讀本頁內容前，請務必先熟悉 Kubernetes 網路概念和術語、一般網路概念，以及 Kubernetes 網路。詳情請參閱 GKE 網路總覽。

在查看這些最佳做法時，請考量下列事項：

• 您打算如何對虛擬私有雲 (VPC) 網路、叢集中的其他工作負載、其他 GKE 叢集，或網際網路公開工作負載。
• 您打算如何擴充工作負載。
• 您想使用的 Google 服務類型。

如需所有最佳做法的檢查清單摘要，請參閱「檢查清單摘要」。

VPC 設計最佳做法

設計虛擬私有雲網路時，請遵循虛擬私有雲設計最佳做法。

下節提供一些 VPC 網路設計的 GKE 專屬建議。

使用 VPC 原生叢集

建議您使用虛擬私有雲原生叢集。虛擬私有雲原生叢集會在 GKE 節點上使用別名 IP 位址範圍，且是虛擬私有雲端網路對等互連叢集和共用虛擬私有雲端叢集的必要條件，並具有許多其他優點。如為以 Autopilot 模式建立的叢集，VPC 原生模式一律會開啟，且無法關閉。

相較於路徑導向叢集，虛擬私有雲原生叢集更容易擴充，且不會耗用 Google Cloud 路徑，因此較不容易達到轉送限制。

使用虛擬私有雲原生叢集的優點與別名 IP 支援息息相關。舉例來說，網路端點群組 (NEG) 只能搭配次要 IP 位址使用，因此僅支援虛擬私有雲原生叢集。

使用共用虛擬私有雲網路

GKE 叢集需要仔細規劃 IP 位址。大多數機構通常會採用集中式管理架構，由網路管理團隊為叢集分配 IP 位址空間，並由平台管理員負責運作叢集。這類機構組織結構非常適合 Google Cloud的共用虛擬私有雲網路架構。在共用 VPC 網路架構中，網路管理員可以建立子網路，並與 VPC 共用。您可以在服務專案中建立 GKE 叢集，並使用主專案中共用虛擬私有雲共用的子網路。IP 位址元件會留在主專案中，其他叢集元件則會位於服務專案中。

一般來說，共用虛擬私有雲網路是常用的架構，適用於大多數設有中央管理團隊的機構。建議您使用共用虛擬私有雲網路，為 GKE 叢集建立子網路，並避免整個機構的 IP 位址發生衝突。您也可以使用共用虛擬私有雲，控管作業功能。舉例來說，您可以讓一個網路團隊專門負責網路元件和可靠性，另一個團隊則負責 GKE。

IP 位址管理策略

所有 Kubernetes 叢集 (包括 GKE 叢集) 都需要為每個 Pod 指派不重複的 IP 位址。詳情請參閱 GKE 網路模型。

在 GKE 中，所有這些 IP 位址都可在整個 VPC 網路中路由傳送。因此，您必須規劃 IP 位址，因為位址不得與內部 IP 位址空間重疊 (無論是內部部署或在其他連線環境中)。以下各節提供使用 GKE 管理 IP 位址的策略建議。

規劃所需的 IP 位址配額

建議您搭配使用 VPC 原生叢集與 Private Service Connect (PSC)。使用虛擬私有雲網路對等互連的叢集必須是虛擬私有雲原生叢集。

虛擬私有雲原生叢集需要下列 IP 位址範圍：

• 控制層 IP 位址範圍：使用 RFC 1918 中 IP 位址私人範圍內的 /28 子網路。您必須確保這個子網路不會與虛擬私有雲網路中的任何其他無類別網域間路由 (CIDR) 重疊。
• 節點子網路：您要為叢集中的所有節點分配主要 IP 位址範圍的子網路。使用 cloud.google.com/load-balancer-type: "Internal" 註解的 LoadBalancer 類型服務也會預設使用這個子網路。您也可以使用內部負載平衡器專用的子網路。
• Pod IP 位址範圍：為叢集中的所有 Pod 分配的 IP 範圍。GKE 會將這個範圍佈建為子網路的別名。詳情請參閱「虛擬私有雲原生叢集的 IP 位址範圍」
• Service IP 位址範圍：您為叢集中的所有 Service 分配的 IP 位址範圍。GKE 會將這個範圍佈建為子網路的別名。

設定叢集網路時，您必須定義節點子網路、Pod IP 位址範圍和服務 IP 位址範圍。

如要更有效率地使用 IP 位址空間，請參閱減少 GKE 中的內部 IP 位址用量。

控制層 IP 位址範圍專用於 GKE 代管的控制層，該控制層位於與虛擬私有雲對等互連的 Google 代管租戶專案中。這個 IP 位址範圍不得與虛擬私有雲對等互連群組中的任何 IP 位址重疊，因為 GKE 會將這個路徑匯入專案。也就是說，如果專案中有任何前往相同 CIDR 的路徑，可能會發生路由問題。

建立叢集時，子網路會為叢集的節點提供主要範圍，且子網路應在建立叢集前就存在。子網路應能容納叢集中的預期節點數量上限，以及叢集內使用子網路的內部負載平衡器 IP 位址。

您可以使用叢集自動配置器來限制節點數量上限。

Pod 和服務 IP 位址範圍會以子網路的不同次要範圍表示，並在虛擬私有雲端原生叢集中以別名 IP 位址的形式實作。

請選擇足夠寬廣的 IP 位址範圍，以便容納叢集的所有節點、Pod 和 Service。

請注意下列限制：

• 您可以擴展主要 IP 位址範圍，但無法縮減範圍。這些 IP 位址範圍不得不連續。
• 您可以將其他 Pod 範圍附加至叢集，或使用其他次要 Pod 範圍建立新的節點集區，藉此擴充 Pod 範圍。
• Service 的次要 IP 位址範圍無法在叢集生命週期內擴充或變更。
• 查看 Pod 和 Service 的次要 IP 位址範圍限制。

使用私人 RFC 1918 IP 位址以外的位址

在某些環境中，大型連續 CIDR 區塊的 RFC 1918 空間可能已在機構中分配。如果 GKE 叢集的額外 CIDR 與 Google 擁有的公開 IP 位址不重疊，您可以使用非 RFC 1918 空間。建議使用 RFC 位址空間的 100.64.0.0/10 部分，因為E 類位址空間可能會導致與內部部署硬體互通性問題。您可以使用私下重複使用的公開 IP (PUPI)。

使用私人的公開 IP 位址時，請謹慎操作，並考慮在選擇這個選項時，控管內部部署網路向網際網路發布的路徑。

在具有 Pod 對 Pod 和 Pod 對 Service 流量的叢集中，不應使用來源網路位址轉譯 (SNAT)。這會破壞 Kubernetes 網路模型。

Kubernetes 會假設所有非 RFC 1918 IP 位址都是私下重複使用的公開 IP 位址，並對源自這些位址的所有流量使用 SNAT。

如果 GKE 叢集使用非 RFC 1918 IP 位址，則對於標準叢集，您需要明確停用 SNAT，或是設定 IP 偽裝代理程式，將叢集的 Pod IP 位址和服務的次要 IP 位址範圍從 SNAT 中排除。如為 Autopilot 叢集，則不需要任何額外步驟。

使用自訂子網路模式

設定網路時，您也會選取子網路模式：auto (預設) 或 custom (建議)。auto 模式會將子網路分配作業交由 Google 處理，是開始使用時的好選擇，不必規劃 IP 位址。不過，建議您選取 custom 模式，因為這個模式可讓您選擇不會與環境中其他範圍重疊的 IP 位址範圍。如果您使用共用虛擬私有雲，機構管理員或網路管理員可以選取這個模式。

以下範例會建立名為 my-net-1 的網路，並使用自訂子網路模式：

gcloud compute networks create my-net-1 --subnet-mode custom

規劃每個節點的 Pod 密度

根據預設，標準叢集會從子網路的 Pod 位址空間中，為每個節點保留 /24 範圍，且每個節點最多可有 110 個 Pod。 不過，您可以設定 Standard 叢集，讓每個節點最多支援 256 個 Pod，並為每個節點保留 /23 範圍。視節點大小和 Pod 的應用程式設定檔而定，每個節點上執行的 Pod 數量可能會大幅減少。

如果您預期每個節點不會執行超過 64 個 Pod，建議您調整每個節點的最大 Pod 數，保留 Pod 子網路中的 IP 位址空間。

如果您預期每個節點會執行超過預設的 110 個 Pod，可以將每個節點的 Pod 數量上限提高至 256 個，並為每個節點保留 /23。採用這類高 Pod 密度設定時，建議使用具有 16 個以上 CPU 核心的執行個體，確保叢集的可擴充性和效能。

如果是 Autopilot 叢集，每個節點的 Pod 數量上限為 32 個，每個節點保留的範圍為 /26。這項設定無法在 Autopilot 叢集中設定。

避免與其他環境中使用的 IP 位址重疊

您可以透過 Cloud VPN 或 Cloud Interconnect，將虛擬私有雲網路連線至地端環境或其他雲端服務供應商。這些環境可以共用路徑，因此在規劃 GKE 的 IP 位址時，內部部署 IP 位址管理機制非常重要。建議您確認 IP 位址不會與其他環境中使用的 IP 位址重疊。

建立負載平衡器子網路

建立個別的負載平衡器子網路，透過內部 TCP/UDP 負載平衡公開服務。如果未使用獨立的負載平衡器子網路，這些服務會透過節點子網路的 IP 位址公開，這可能會導致該子網路中所有已分配空間比預期更早用盡，並阻礙您將 GKE 叢集擴充至預期節點數量。

使用獨立的負載平衡器子網路也表示，您可以分別篩選進出 GKE 節點的流量，以及內部 TCP/UDP 負載平衡公開的服務，進而設定更嚴格的安全界線。

為叢集自動調度器預留足夠的 IP 位址空間

您可以使用叢集自動配置器，動態新增及移除叢集中的節點，藉此控管費用並提升使用率。不過，使用叢集自動配置器時，請務必確保 IP 位址規劃考量到所有節點集區的大小上限。每個新節點都需要自己的節點 IP 位址，以及根據每個節點設定的 Pod 數，分配一組可用的 Pod IP 位址。每個節點的 Pod 數量可以與叢集層級設定不同。叢集或節點集區建立後，每個節點的 Pod 數量就無法再變更。您應考量工作負載類型，並將其指派給不同的節點集區，以獲得最佳 IP 位址分配。

建議您搭配叢集自動配置器使用節點自動佈建功能，特別是使用 VPC 原生叢集時。詳情請參閱「節點限制範圍」。

在叢集間共用 IP 位址

如果您有集中式團隊負責管理叢集基礎架構，可能需要在叢集之間共用 IP 位址。如要在 GKE 叢集之間共用 IP 位址，請參閱在 GKE 叢集之間共用 IP 位址範圍。您可以建立三個範圍 (分別用於 Pod、服務和節點)，並重複使用或共用這些範圍，特別是在共用虛擬私有雲模型中，藉此減少 IP 位址耗盡的情況。此外，網路管理員也不必為每個叢集建立特定子網路，因此可更輕鬆地管理 IP 位址。

請考量下列事項：

• 最佳做法是為所有叢集使用不同的子網路和 IP 位址範圍。
• 您可以共用次要 Pod IP 位址範圍，但建議不要這麼做，因為一個叢集可能會用完所有 IP 位址。
• 您可以共用次要服務 IP 位址範圍，但這項功能不適用於 GKE 的虛擬私人雲端範圍 Cloud DNS。

如果 IP 位址用盡，可以使用不連續的多 Pod CIDR 建立其他 Pod IP 位址範圍。

共用內部 LoadBalancer 服務的 IP 位址

您可以使用不同連接埠，與最多 50 個後端共用單一 IP 位址。 這樣一來，您就能減少內部 LoadBalancer 服務所需的 IP 位址數量。

詳情請參閱「共用 IP」。

網路安全最佳做法

本節將列出幾項叢集隔離的重要建議。 GKE 叢集的網路安全是 Google 與叢集管理員共同的責任。

使用 GKE Dataplane V2

GKE Dataplane V2 以 eBPF 為基礎，提供整合式網路安全和可視性體驗。使用 GKE Dataplane V2 建立叢集時，您不需要明確啟用網路政策，因為 GKE Dataplane V2 會管理服務路由、強制執行網路政策和記錄。建立叢集時，請使用 Google Cloud CLI --enable-dataplane-v2 選項啟用新的資料平面。設定網路政策後，可以設定預設的 NetworkLogging CRD 物件，記錄允許和拒絕的網路連線。建議您使用 GKE Dataplane V2 建立叢集，充分運用網路政策記錄等內建功能。

盡量減少節點曝光

在只有私人節點的叢集中，Pod 會與傳入和傳出通訊 (叢集邊界) 隔離。如要控管這些方向性流程，請使用負載平衡和 Cloud NAT 公開服務，詳情請參閱本文的叢集連線一節。下圖顯示這類設定：

下圖顯示具有私人節點的叢集如何通訊。地端用戶端可以使用 kubectl 用戶端連線至叢集。透過私人 Google 存取權存取 Google 服務，且只能使用 Cloud NAT 與網際網路通訊。

盡量減少叢集控制層的曝露風險

控制層有兩種叢集存取端點：

• 以 DNS 為基礎的端點
• 以 IP 為準的端點

您可以從 Google Cloud API 可連線的任何網路存取 DNS 端點，包括地端或其他雲端網路。如要啟用以 DNS 為基礎的端點，請使用 --enable-dns-access 旗標。

GKE API 伺服器也可以公開或私人 IP 為基礎的端點。建立叢集時，您可以決定要使用的端點。您可以使用授權網路控管存取權，其中公開和私人端點預設允許叢集中 Pod 和節點 IP 位址之間的所有通訊。如要在建立叢集時啟用私人端點，請使用 --enable-private-endpoint 標記。

授權存取控制層

授權網路可協助指定哪些 IP 位址子網路可以存取 GKE 控制層節點。啟用這些網路後，您可以限制特定來源 IP 位址範圍的存取權。如果停用公開端點，這些來源 IP 位址範圍應為私人範圍。如果啟用公開端點，您可以允許公開或內部 IP 位址範圍。設定自訂路徑通告，允許從內部部署環境連線至叢集控制層的私人端點。建立叢集時，可以使用 --enable-master-global-access 選項，讓私人 GKE API 端點可從全球各地存取。

下圖顯示使用授權網路的一般控制平面連線：

這張圖表顯示受信任的使用者屬於授權網路，因此能夠透過公開端點與 GKE 控制層通訊，而未受信任的行為人則遭到封鎖。與 GKE 叢集的通訊會透過控制層的私有端點進行。

允許控制層連線

每個工作節點上的特定系統 Pod 都需要連線至 Kubernetes API 伺服器 (kube-apiserver)、Google API 或中繼資料伺服器等服務。kube-apiserver也需要與某些系統 Pod 通訊，例如event-exporter。這類通訊預設為允許。如果在專案中部署虛擬私有雲防火牆規則 (詳情請參閱「限制叢集流量」一節)，請確保這些 Pod 能夠繼續與 kube-apiserver 和 Google API 通訊。

從對等互連網路部署 Proxy，以便存取控制層

如果叢集使用 VPC 網路對等互連，您無法從其他對等互連網路存取叢集的控制平面。

如果想在使用中樞輻射架構時，從其他對等互連網路或內部部署環境直接存取，請部署控制層流量的 Proxy。

使用網路政策限制叢集流量

叢集工作負載可採用多種網路安全層級，包括虛擬私有雲防火牆規則、階層式防火牆政策和 Kubernetes 網路政策。虛擬私有雲防火牆規則和階層式防火牆政策適用於虛擬機器 (VM) 層級，也就是 GKE 叢集 Pod 所在的背景工作節點。Kubernetes 網路政策會在 Pod 層級套用，以強制執行 Pod 對 Pod 的流量路徑。

如果您實作 VPC 防火牆，可能會中斷預設的必要控制層通訊，例如 kubelet 與控制層之間的通訊。GKE 預設會建立必要防火牆規則，但這些規則可以覆寫。部分部署作業可能需要控制層連上服務中的叢集。您可以使用虛擬私有雲防火牆設定可讓服務存取的連入政策。

GKE 網路政策是透過 Kubernetes Network Policy API 設定，可強制執行叢集的 Pod 通訊。建立叢集時，可以使用 gcloud container clusters create 選項 --enable-network-policy 啟用網路政策。如要使用網路政策限制流量，請參閱 Anthos 限制流量藍圖實作指南。

為 Ingress 啟用 Google Cloud Armor 安全性政策

使用 Google Cloud Armor 安全性政策，您可以透過在網路邊緣封鎖這類流量，保護使用外部應用程式負載平衡器的應用程式，防範 DDoS 攻擊和其他網路攻擊。在 GKE 中，使用外部應用程式負載平衡器的 Ingress，並將安全性政策新增至附加至 Ingress 物件的 BackendConfig，即可為應用程式啟用 Google Cloud Armor 安全性政策。

使用 Identity-Aware Proxy 為 IAM 使用者驗證應用程式

如要部署僅供機構內使用者存取的服務，但不需要連上公司網路，可以使用 Identity-Aware Proxy 為這些應用程式建立驗證層。如要為 GKE 啟用 Identity-Aware Proxy，請按照設定步驟，將 Identity-Aware Proxy 新增為服務 Ingress 的 BackendConfig 一部分。Identity-Aware Proxy 可與 Google Cloud Armor 搭配使用。

使用機構政策限制進一步提升安全性

您可以透過機構政策限制設定政策，進一步提升安全防護機制。舉例來說，您可以使用限制將負載平衡器建立作業限制為特定類型，例如僅限內部負載平衡器。

叢集連線資源調度

本節說明 DNS 和叢集對網際網路與 Google 服務的輸出連線可擴充選項。

使用 GKE 適用的 Cloud DNS

您可以使用 Cloud DNS for GKE，透過代管 DNS 提供 Pod 和服務 DNS 解析，而不需要叢集代管的 DNS 供應商。Cloud DNS 是 Google 代管服務，因此您不必管理叢集代管的 DNS 伺服器，也不需要擴充、監控或管理 DNS 執行個體，可大幅減少管理負擔。

啟用 NodeLocal DNSCache

GKE 會使用 kube-dns，將叢集的本機 DNS 服務做為預設叢集外掛程式提供。kube-dns 會在叢集中複製，複製數量取決於叢集中的核心和節點總數。

您可以透過 NodeLocal DNSCache 提升 DNS 效能。NodeLocal DNSCache 是以 DaemonSet 形式部署的附加元件，不需要變更任何 Pod 設定。對本機 Pod 服務的 DNS 查詢不會建立需要追蹤的開放連線，因此節點可擴充性更高。外部主機名稱查詢會轉送至 Cloud DNS，所有其他 DNS 查詢則會轉送至 kube-dns。

啟用 NodeLocal DNSCache，確保 DNS 查詢的查詢時間更加一致，並提升叢集規模。如為 Autopilot 叢集，NodeLocal DNSCache 預設為啟用，且無法覆寫。

使用下列 Google Cloud CLI 選項建立叢集時，即可啟用 NodeLocal DNSCache：--addons NodeLocalDNS.

如果您可以控管應用程式要解析的名稱，就能改善 DNS 擴充性。舉例來說，請使用 FQDN (主機名稱結尾須加上半形句號)，或透過 Pod.dnsConfig 資訊清單選項停用搜尋路徑擴展功能。

使用 Cloud NAT 從叢集存取網際網路

根據預設，啟用私人節點的叢集無法存取網際網路。如要允許 Pod 存取網際網路，請為每個區域啟用 Cloud NAT。至少要為 GKE 子網路中的主要和次要範圍啟用 Cloud NAT。請務必為每個 VM 分配足夠的 Cloud NAT IP 位址和通訊埠。

在叢集使用 Cloud NAT 時，請遵循下列 Cloud NAT 閘道設定最佳做法：

• 建立 Cloud NAT 閘道時，請只為叢集使用的子網路範圍啟用閘道。計算所有叢集中的所有節點，即可判斷專案中的 NAT 消費端 VM 數量。

• 使用動態通訊埠分配功能，根據 VM 用量為每個 VM 分配不同數量的通訊埠。開始時，通訊埠數量下限為 64 個，上限為 2048 個。

• 如果需要管理多個同時連線至相同目的地 3 元組的連線，請將 TCP TIME_WAIT 超時從預設值 120s 降低至 5s。詳情請參閱「為 NAT 指定不同的逾時時間」。

• 啟用 Cloud NAT 錯誤記錄，即可查看相關記錄。

• 設定閘道後，請檢查 Cloud NAT 閘道記錄。如要減少分配狀態遭捨棄的問題，您可能需要增加每個 VM 的通訊埠數量上限。

您應避免對 Pod 流量進行雙重 SNAT (先在 GKE 節點進行 SNAT，然後再次使用 Cloud NAT)。除非您需要 SNAT 來隱藏 Pod IP 位址，以免這些位址傳送到透過 Cloud VPN 或 Cloud Interconnect 連線的內部部署網路，否則請disable-default-snat將 SNAT 追蹤作業卸載至 Cloud NAT，以提高可擴充性。這個解決方案適用於所有主要和次要子網路 IP 範圍。啟用 Cloud NAT 後，請使用網路政策限制外部流量。存取 Google 服務時，不需要 Cloud NAT。

使用私人 Google 存取權存取 Google 服務

在具備私人節點的叢集中，Pod 沒有公開 IP 位址，因此無法連上公開服務，包括 Google API 和服務。私人 Google 存取權可讓私人Google Cloud 資源連線至 Google 服務。

在具備私人節點的叢集中，系統預設會啟用私人 Google 存取權，共用虛擬私有雲叢集除外。

應用程式資源調度最佳做法

建立可從外部或貴機構內部存取的應用程式時，請務必使用正確的負載平衡器類型和選項。本節提供一些建議，說明如何透過 Cloud Load Balancing 公開及擴充應用程式。

使用容器原生負載平衡

使用 HTTP(S) 從外部公開服務時，請使用容器原生負載平衡 。容器原生負載平衡功能可減少網路躍點、縮短延遲時間，並更精確地分配流量。此外，這項功能還能提高往返時間的能見度，並讓您使用 Google Cloud Armor 等負載平衡功能。

選擇正確的 GKE 資源來公開應用程式

視用戶端範圍 (內部、外部，甚至是叢集內部)、應用程式的區域性，以及您使用的通訊協定而定，您可以選擇使用不同的 GKE 資源來公開應用程式。服務網路總覽說明瞭這些選項，並可協助您選擇最佳資源，透過 Google Cloud 負載平衡選項公開應用程式的各個部分。

根據 BackendConfig 建立健康狀態檢查

如果您使用 Ingress 公開服務，請在 BackendConfig CRD 中使用健康狀態檢查設定，以便使用外部應用程式負載平衡器的健康狀態檢查功能。您可以將健康狀態檢查導向適當的端點，並自行設定閾值。如果沒有 BackendConfig CRD，系統會根據完備性探測參數推斷健康檢查，或使用預設參數。

使用本機流量政策保留原始 IP 位址

使用內部直通式網路負載平衡器搭配 GKE 時，請將 externalTrafficPolicy 選項設為 Local，保留要求的來源 IP 位址。如果應用程式需要原始來源 IP 位址，請使用這個選項。不過，externalTrafficPolicy local 選項可能會導致負載分散效果不佳，因此請僅在必要時使用這項功能。如果是 HTTP(S) 服務，您可以使用 Ingress 控制器，並讀取 HTTP 要求中的 X-Forwarded-For 標頭，取得原始 IP 位址。

使用 Private Service Connect

您可以使用 Private Service Connect，在其他虛擬私有雲網路之間共用內部直通網路負載平衡器服務。如果服務是託管在 GKE 叢集上，但為在不同專案和不同 VPC 中執行的客戶提供服務，這項功能就非常實用。

您可以透過 Private Service Connect，在 IP 位址重疊的 VPC 之間建立連線，減少 IP 位址耗用量。

營運最佳做法

以下各節包含作業最佳做法，有助於確保工作負載的精細授權選項。如要避免手動建立防火牆規則，請按照本節中的營運最佳做法操作。此外，本文也提供在 GKE 中分配工作負載，以及監控和記錄的建議。

使用 GKE 權限的 IAM 控制共用 VPC 網路中的政策

使用共用虛擬私有雲端網路時，系統會在主專案中自動建立負載平衡器的防火牆規則。

為避免手動建立防火牆規則，請在名為 service-HOST_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com 的主專案中，將最低權限自訂角色指派給 GKE 服務帳戶。

將 HOST_PROJECT_NUMBER 替換為共用 VPC 的主專案專案編號。

您建立的自訂角色應具備下列權限：

• compute.firewalls.create
• compute.firewalls.get
• compute.firewalls.list
• compute.firewalls.delete

此外，GKE 建立的防火牆規則一律採用預設優先順序 1000，因此您可以建立優先順序較高的防火牆規則，禁止特定流量流動。

如要限制建立特定類型的負載平衡器，請使用機構政策限制負載平衡器的建立作業。

使用區域叢集並分配工作負載，確保高可用性

地區叢集可提高叢集中應用程式的可用性，因為叢集控制層和節點會分散在多個區域。

不過，為了在區域故障時提供最佳使用者體驗，請使用叢集自動調度器，確保叢集隨時都能處理所需負載。

您也可以使用 Pod 反相依性，確保特定服務的 Pod 會排定在多個可用區中。

如要進一步瞭解如何設定這些高可用性和成本最佳化設定，請參閱「高可用性 GKE 叢集最佳做法」。

使用 Cloud Logging 和 Cloud Monitoring，並啟用網路政策記錄功能

雖然每個機構的瀏覽權限和稽核需求不同，但我們建議啟用網路政策記錄。這項功能僅適用於 GKE Dataplane V2。網路政策記錄可讓您瞭解政策強制執行情況和 Pod 流量模式。請注意，網路政策記錄會產生費用。

如果 GKE 叢集使用 1.14 以上版本，系統預設會啟用 記錄和監控功能。Monitoring 會為 GKE 叢集提供資訊主頁。啟用記錄功能後，您也可以為 VPC Flow Logs 啟用 GKE 註解。根據預設，Logging 會收集部署至叢集的所有工作負載記錄，但您也可以只收集系統記錄。使用 GKE 資訊主頁觀察及設定快訊。如為以 Autopilot 模式建立的叢集，系統會自動啟用監控和記錄功能，且無法設定。

請注意，Google Cloud Observability 會產生相關費用。

檢查清單摘要

後續步驟

• GKE 最佳做法洞察
• 企業多用戶群的最佳做法

• 透過 Ingress 和 Service 公開 GKE 應用程式

• 虛擬私有雲設計的最佳做法與參考架構