減少 GKE 中的內部 IP 地址用量
GKE 使用完全集成的網路模型，其中集群部署在 VPC 網路中，該網路也可以包含其他應用。GKE 模型具有多種優勢。但是，這種類型的模型不允許重複使用 Pod IP 位址。如果不重複使用，您使用的 Pod IP 位址需要在整個 VPC 網路中唯一。因此，您必須仔細考慮您需要多少個唯一的 IP 位址。
您需要的唯一位址數量會影響您是否需要減少 IP 位址用量，如下所示：
如果您有足夠的位址空間來滿足您的 IP 位址需求，則不一定需要採取措施減少 IP 位址用量。但是，瞭解如何減少 IP 位址用量有助於確定要使用的 IP 位址數量下限。
如果您沒有足夠的位址空間，則需要減少 IP 位址用量，才能創建滿足位址空間限制的 GKE 集群。
為了減少 GKE 中的 IP 位址用量，您可以使用以下選項：
更改“每個節點的 Pod 數量”設置。預設情況下，GKE 標準集群會為每個節點預留一個 /24 子網範圍，最多可以允許每個節點有 110 個 Pod。如果您預計每個節點僅使用 64 個或更少的 Pod，則可以調整每個節點的最大 Pod 數，從而將 Pod IP 地址用量減少一半或以上。 Autopilot 集群允許每個節點 32 個 Pod，並且此設置無法更改。
使用多個 Pod IP 位址範圍。使用不連續的多 Pod 無類別域間路由 (CIDR)，您可以向現有集群添加次要 Pod IP 位址範圍。您可以選擇每個節點池使用的 Pod IP 位址範圍。通過選擇每個池使用的 IP 位址範圍，您可以在分配初始 Pod IP 位址空間時留有餘地，同時仍能增加集群。
使用非 RFC 1918 IP 位址。您的企業網路可能沒有足夠的未分配 RFC 1918 IP 位址用於 Pod IP 地址。如果您沒有足夠的未分配 RFC 1918 IP 位址，則可以使用非 RFC 1918 地址，例如 RFC 6598 位址空間中的地址 (100.64.0.0/10)。如果您已在企業網路中的其他位置使用 RFC 6598 空間，則可以將 Class E/RFC 5735 (240.0.0.0/4) 位址空間用於 Pod IP 位址。但是，來自這些 IP 位址的流量在 Windows 主機和一些本地硬體上會被遮罩。為避免遮罩 RFC 5735 位址，請考慮將流量偽裝成這些外部目的地，如僅隱藏本地網路中的 Pod IP 位址部分中所述。但是，在將流量偽裝成外部目的地時，會丟失一些定向到本地應用的遙測資料。
如果您的組織具有大型公共 IP 位址空間，您還可以使用以非公開方式使用的公共 IP (PUPI) 位址。使用 PUPI 位址時，您必須在 nonMasqueradeCIDRs 列表中添加 PUPI 地址才能不使用 NAT 在集群外部進行連接。
在 GKE 中選擇網路模型
GKE 網路模型上的文檔討論了標準集群在 GKE 中的工作原理，包括所涉及的 Pod IP 地址。在本文檔中，減少 GKE 中的內部 IP 地址用量部分介紹了如何減少這些集群中所需的內部 IP 位址數量。瞭解 GKE 網路模型的工作原理以及如何減少內部 IP 位址是 GKE 中使用的任何網路模型的基礎。
但是，僅僅知道和應用這些概念可能無法為您提供滿足需求的網路實現。您可以借助以下決策樹來確定如何實現最適合您的 GKE 網路模型：
決策樹始終從創建基於完全集成網路模型的 GKE 標準集群開始。樹中的下一步是應用本文檔中所述的所有選項，以減少 IP 位址用量。
如果您盡可能減少 IP 位址用量，但仍沒有足夠的 GKE 集群位址空間，則需要替代網路模型。決策樹可幫助您確定使用以下哪種可選網路模型：
一、 僅隱藏來自本地網路的 Pod IP 位址。如果您符合以下條件，請使用此模型：
您不能使用 RFC 6598 空間減少內部 IP 位址用量。
您可以使用 Class E/RFC 5735 位址空間，並從本地網路中隱藏此空間。
二、 使用 Private Service Connect 隱藏 Pod IP 位址。如果您符合以下條件，請使用此模型：
您不能使用 Class E/RFC 5735 位址空間。
您的集群不需要與更大網路上的服務進行私密通信。
您無需從集群所在區域以外的任何區域訪問集群。
三、 通過內部使用公共 IP 位址和 VPC 網路對等互連來隱藏 Pod IP 位址。雖然很少要求，但如果您符合以下條件，請使用此模型：
您不能使用 Class E/RFC 5735 位址空間。
您的集群確實需要與更大網路上的服務進行私密通信。
您的組織分配有公共 IP 位址空間，該空間尚未使用，並且足以容納您的最大集群。
四、 使用 Cloud VPN 隱藏 Pod IP 位址。如果您的集群不符合決策樹中列出的任何其他條件，請使用此模型。
請注意，此決策樹僅供參考。根據具體用例，您可能仍會根據每個模型的優缺點來選擇另一個模型。通常，多個模型都可用，您可以選擇更適合組織的方法。
在極少數情況下，決策樹中提供的備用模型無法滿足您的需求。對於這些罕見的情況，您可以使用使用多 NIC 實例來隱藏集群位址中所述的模型。
類比替代網路模型
為充分利用完全集成的網路模型的優勢，我們建議您將 GKE 集群與其他雲資源置於同一邏輯網路中。但是，您可能無法遵循此建議。您的 IP 位址空間可能不足，或者您可能需要從組織的較大網路中隱藏 Pod IP 位址。
本部分通過描述模仿 GKE 上各種替代網路模型的不同架構模式，提供使用完全集成網路模型的選項。這些替代架構模式為 GKE 創建了一個類似於孤島模式網路模型或隔離模式網路模型的操作模式。
每個替代架構模式都包含以下資訊：
架構模式的說明。
圖表展示如何實現該模式。每個實現圖都顯示了內部負載等化器的用法。如果圖中未顯示特定負載等化器，我們建議您使用內部 TCP/UDP 負載均衡。如果您要使用多個後端服務，則可以改用內部 HTTP(S) 負載均衡。
關於該模式優缺點的討論。
僅隱藏來自本地網路的 Pod IP 位址
向本地網路隱藏 IP 位址所用的架構模式使用了以下路由目標群組合：
讓 Google Cloud 上的 GKE 集群分配在整個 Google Cloud 部署中路由的 Pod IP 位址。
防止這些 IP 位址在沒有 NAT 的情況下路由到本地資源或者通過 Cloud VPN 或 Cloud Interconnect 路由到其他雲環境。
此架構模式通常與 Class E/RFC 5735 IP 位址空間一起使用，因為此空間包含許多 IP 位址。有太多可用 IP 位址有助於滿足為每個 Pod 提供唯一 IP 位址的需求。但是，Class E/RFC 5735 IP 位址無法輕鬆路由到本地資源，因為許多網路硬體供應商會遮罩此流量。
您可以使用 RFC 1918 IP 位址或內部非 RFC 1918 IP 位址集，而不是使用 Class E/RFC 5735 IP 位址空間。如果您使用其他一組 IP 位址，請確定用於 Pod 的 IP 位址與本地網路中使用的 IP 位址之間是否存在 IP 位址重疊。如果存在重疊，請確保使用這些位址的集群與使用相同位址的本地應用之間不存在任何通信。
以下步驟概述了如何設置此架構模式：
為 Pod 子網創建次要 IP 地址範圍。如本部分前面所述，您可以使用 Class E/RFC 5735 類、RFC 1918 空間或一組內部非 RFC 1918 IP 地址創建此地址範圍。通常使用 Class E/RFC 5735 空間。
使用自訂路由通告，並從 Cloud Router 上的通告中移除 Pod IP 地址範圍。移除這些地址有助於確保沒有通過邊界閘道協議 (BGP) 向您的本地路由器公佈 Pod IP 範圍。
使用次要 IP 位址範圍作為 Pod 的無類別域間路由 (CIDR) 來創建 GKE 集群。您可以使用減少 GKE 中的內部 IP 地址用量中描述的策略來減少 IP 地址用量。
將以下 IP 地址添加到偽裝代理中的 nonMasqueradeCIDRs 清單：
用於 Pod 的 IP 地址範圍。
用於節點的 IP 地址範圍。
僅在 Google Cloud 上使用的其他 IP 位址，例如 Google Cloud 上使用的主要 IP 位址範圍。
請勿添加本地環境或其他雲環境中使用的內部 IP 位址範圍。如果您在 Google Cloud 中具有 Windows 工作負載，請將這些工作負載保存在單獨的子網中，請勿包含這些範圍。
使用上述步驟設置此模式時，您可以將集群配置為具有以下行為：
充當 Google Cloud 中完全集成的網路模型。
與本地網路交互時，充當孤島模式網路模型。
如需讓此備用模式完全類比孤島模式網路模型，您需要將偽裝代理中的 nonMasqueradeCIDRs 清單更改為僅包含集群的節點和 Pod IP 地址範圍。創建此類列表始終會將集群外部的流量偽裝成節點 IP 位址，即使在 Google Cloud 內部也是如此。但是，執行此更改後，您無法在 VPC 網路中收集 Pod 級遙測資料。
下圖（架構模式A）展示了此架構模式的實現：
上圖展示了如何對外部網路隱藏 Pod IP 位址。如圖所示，Google Cloud 中的 Pod 可以直接相互通信，甚至可以在集群之間通信。此 Pod 通信類似於標準 GKE 模型。請注意，該圖還展示了 Pod 使用 Class E/RFC 5735 空間中的位址。
對於發送到集群外部的流量，該圖顯示了來源 NAT (SNAT) 在流量離開節點時如何應用於該流量。無論該流量通過 Cloud VPN 路由到本地應用，還是通過 Cloud NAT 路由到外部應用，系統都會使用 SNAT。
此架構模式使用 Pod IP 位址在 Google Cloud 內進行通信。僅在定向到本地應用或其他雲環境時才會偽裝流量。雖然您無法直接從本地應用連接到 Pod，但可以連接到通過內部負載均衡公開的服務。
向本地網路隱藏 Pod IP 位址具有以下優勢：
您仍然可以利用 Google Cloud 中完全集成的網路模型，例如使用防火牆和基於 Pod IP 位址收集遙測資料。此外，您還可以直接從 Google Cloud 連接到 Pod 以進行調試。
您仍然可以在 Google Cloud 中使用具有 Pod IP 位址的多集群服務網格。
但是，向外部網路隱藏 Pod IP 位址具有以下缺點：
您不能對 Google Cloud 中的不同集群重複使用 Pod 或 Service IP 位址範圍。
您可能需要管理兩組不同的防火牆規則：一組針對本地網路之間的流量，另一組針對完全在 Google Cloud 中的流量。
您不能在跨 Google Cloud 和本地或其他雲服務提供者環境的多集群服務網格中進行直接 Pod 到 Pod 通信。例如，使用 Istio 時，所有通信都必須在 Istio 閘道之間進行。
使用 Private Service Connect 隱藏 Pod IP 位址
此架構模式使用 Private Service Connect 隱藏 Pod IP 地址。如果您有以下需求，請使用此架構模式：
您只需要從 GKE 集群中公開有限數量的 Service。
您的 GKE 集群可以獨立工作，不需要與公司網路中的許多應用進行出站通信。
Private Service Connect 提供了發佈要從其他網路使用的服務的方法。您可以使用內部 TCP/UDP 負載等化器和服務連接公開 GKE Service，並使用其他 VPC 網路中的端點使用這些服務。
以下步驟概述了如何設置此架構模式：
在單獨的 VPC 網路中，創建一個 GKE 集群。VPC 網路應僅包含該集群。
對於集群中需要從其他 VPC 網路中的其他集群或應用訪問的每個 GKE Service，請使用 Private Service Connect 創建內部 TCP/UDP 負載等化器。
（可選）如果您的 GKE 集群需要與公司網路中的某些應用進行出站通信，請通過 Private Service Connect 發佈服務以公開這些應用。
下圖展示了此架構模式（架構模式B）的實現：
上圖（架構模式B）展示了 Private Service Connect 模型中的群集內部和之間的通信類似於隔離網路模型。但是，允許的通信通過 Private Service Connect 端點進行，而不是通過公共 IP 位址。如圖所示，每個集群都有自己的單獨 VPC 網路。此外，每個 VPC 網路可以共用同一 IP 位址，每個集群可以共用同一 IP 位址空間。只有集群中的 Pod 才能彼此直接通信。
對於來自集群外部的通信，該圖展示了外部應用如何通過 Private Service Connect 端點訪問集群。該端點連接到集群 VPC 網路中服務提供方提供的服務連接。集群之間的通信也通過 Private Service Connect 端點和服務提供方的服務連接進行。
使用 Private Service Connect 隱藏 Pod IP 位址具有以下優勢：
您無需規劃 IP 位址，因為 GKE 集群的 IP 位址空間對網路的其餘部分隱藏。此方法僅向使用中的 VPC 網路公開每個服務的單一 IP 位址。
保護集群更容易，因為此模型明確定義了公開的服務，並且只能從 VPC 網路的其餘部分訪問這些公開的服務。
但是，使用 Private Service Connect 隱藏 Pod IP 位址具有以下缺點：
集群內的 Pod 無法在集群外部建立私密通信。Pod 只能與公共服務（當 Pod 具有互聯網連接時）或 Google API（通過使用專用 Google 訪問通道）通信。如果集群外部的服務通過 Private Service Connect 公開，則 Pod 也可以訪問這些服務。但是，並非所有內部服務提供者都會創建服務連接。因此，只有在這些服務的數量受實際提供連接的提供商的限制時，才能使用 Private Service Connect。
只能從服務所在的區域訪問端點。此外，這些端點只能從連接的 VPC 網路本身訪問，而不能從對等互連的 VPC 網路或通過 Cloud VPN 或 Cloud Interconnect 連接的網路訪問。
使用 Cloud VPN 隱藏 Pod IP 位址
此架構模式使用 Cloud VPN 在 GKE 集群和主 VPC 網路之間實現隔離。創建這種隔離時，生成的網路的功能類似於孤島模式網路模型。與孤島模式模型一樣，此模式可為您提供在集群之間重複使用 Pod 和 Service IP 位址範圍的優勢。可以重複使用，因為與集群外部的應用通信使用 SNAT。節點在流量退出節點之前，使用 SNAT 將 Pod IP 位址映射到自己的節點 IP 地址。
以下步驟概述了如何設置此模型：
在單獨的 VPC 網路中，創建一個 GKE 集群。VPC 網路應僅包含該集群。
對於集群，請使用公共 IP 位址分配的未使用部分來定義兩個 IP 位址範圍：一個用於 Pod，另一個用於 Service。根據您預期使用的最大 GKE 集群的需求調整這些 IP 位址範圍的大小。請保留每個範圍，以便在 GKE 中獨佔使用。您還可以將這些範圍重複用於組織中的所有 GKE 集群。
有時，預留此類較大範圍的 IP 地址是無法實現的。您的組織可能已經為其他應用使用了 Pod 和/或 Service IP 位址範圍。如果該 IP 位址範圍正在使用中且無法預留，請確保使用這些 IP 位址的應用無需與 GKE 集群通信。
對於您剛剛創建的集群，請將偽裝代理中的 nonMasqueradeCIDRs 清單配置為包含集群節點和 Pod IP 地址範圍的列表。此列表會導致 GKE 始終偽裝離開集群前往節點 IP 地址的流量，即使在 Google Cloud 內部也是如此。
使用 Cloud VPN 將包含 GKE 集群的 VPC 網路連接到現有（主）VPC 網路。
使用自訂路由通告會阻止集群的 VPC 網路通告定向到您的主 VPC 網路的 Pod 和 Service IP 位址範圍。
對所需的其他 GKE 集群重複第 1-4 步。對於所有集群，請為 Pod 和 Service 使用相同的 IP 位址範圍。但是，請為每個節點使用不同的 IP 位址。
如果您通過 Cloud VPN 或 Cloud Interconnect 連接到本地網路，請使用自訂路由通告手動通告節點 IP 地址範圍。
如果您已通過 VPC 網路對等互連將其他網路連接到主 VPC 網路，請在這些對等互連上匯出自訂路由，以確保 GKE 集群節點可以訪問對等互連網路。
下圖展示了如何實現使用 Cloud VPN 隱藏 Pod IP 位址：
上圖展示了如何使用 Cloud VPN 隱藏 Pod IP 位址，這會創建一個類似於孤島模式網路模型的方法。如圖所示，每個 GKE 集群都有自己單獨的 VPC 網路。每個網路都有一個不同的節點 IP 位址空間，但使用相同的 Pod IP 位址空間。Cloud VPN 隧道將這些 VPC 網路相互連接並連接到公司網路，並且不會從包含集群的 VPC 網路通告 Pod IP 空間。
請注意，在該圖中，只有集群中的 Pod 可以直接相互通信。節點在集群外部與其他集群、公司網路或連接的本地網路通信時，使用 SNAT 偽裝 Pod IP 位址空間。您無法直接從其他集群或公司網路訪問 Pod。通過 Cloud VPN 連接，只能訪問使用內部負載等化器公開的集群 Service。
使用 Cloud VPN 隱藏 Pod IP 位址具有以下優勢：
如孤島模式網路模型中所述，您可以在集群之間重複使用 Pod 和 Service IP 位址範圍。
防火牆需要的配置可能較少，因為無法直接從主 VPC 網路和連接的網路訪問 Pod IP 位址。因此，您無需配置顯式防火牆規則即可阻止與 Pod 的通信。
但是，使用 Cloud VPN 隱藏 Pod IP 位址具有以下缺點：
孤島模式網路模型中提到的相同缺點適用。例如，您無法在 Pod 級層設置防火牆規則。您無法在主 VPC 網路或連接的網路中在 Pod 級層收集遙測資料。
與預設 GKE 網路模型相比，此模式會產生額外的費用：與 Cloud VPN 隧道相關的費用和資料傳輸費用。
Cloud VPN 對每個 VPN 隧道具有頻寬限制。如果達到此頻寬限制，您可以使用等價多路徑 (ECMP) 配置多個 Cloud VPN 隧道並分配流量。但是，執行這些操作會增加設置和維護 GKE 實現的複雜性。
路由通告保持同步會增加集群創建的複雜性。每當創建新的 GKE 集群時，您都需要設置 Cloud VPN 隧道，並在這些隧道上和向本地應用創建自訂路由通告。
通過內部使用的公共 IP 位址和 VPC 網路對等互連來隱藏 Pod IP 位址
如果您的組織擁有未使用的公共 IP 位址，則可以使用此類似於孤島模式網路模型的架構模式，但需要專用此公共 IP 位址空間。此架構與使用 Cloud VPN 的模型類似，但使用 VPC 網路對等互連在 GKE 集群和主網路之間創建隔離。
以下步驟概述了如何設置此架構模式：
在單獨的 VPC 網路中，創建一個 GKE 集群。VPC 網路應僅包含該集群。
對於集群，請使用公共 IP 位址分配的未使用部分來定義兩個 IP 位址範圍：一個用於 Pod，另一個用於 Service。根據您預期使用的最大 GKE 集群的需求調整這些 IP 位址範圍的大小。請保留每個範圍，以便在 GKE 中獨佔使用。您還可以將這些範圍重複用於組織中的所有 GKE 集群。
從理論上講，可以使用協力廠商擁有的較大、未使用的公共 IP 位址塊，而不是使用公共 IP 位址分配。但是，我們強烈建議不要使用此類設置，因為此類 IP 位址可能隨時被公開銷售或使用。位址的銷售或使用會導致在互聯網上使用公共服務時出現安全和連接問題。
對於您剛剛創建的集群，請將偽裝代理中的 nonMasqueradeCIDRs 清單配置為包含集群節點和 Pod IP 地址範圍的列表。此列表會導致 GKE 始終偽裝離開集群前往節點 IP 地址的流量，即使在 Google Cloud 內部也是如此。
使用 VPC 網路對等互連將包含 GKE 集群的 VPC 網路連接到現有（主）VPC 網路。由於您不希望在此模型中交換 PUPI 位址，因此請在配置對等互連時設置 --no-export-subnet-routes-with-public-ip 標誌。
對所需的其他 GKE 集群重複第 1-3 步。對於所有集群，請為 Pod 和 Service 使用相同的 IP 位址範圍。但是，請為每個節點使用不同的 IP 位址。
如果您通過 Cloud VPN 或 Cloud Interconnect 連接到本地網路，請使用自訂路由通告手動通告節點 IP 地址範圍。
下圖（架構模式C）展示了此架構模式的實現：
上圖（架構模式C）展示了如何使用 VPC 網路對等互連隱藏 IP 位址。如圖所示，每個 GKE 集群都有自己單獨的 VPC 網路。每個節點具有不同的節點 IP 位址空間，但使用的 Pod IP 位址空間由組織的 PUPI 位址空間定義。VPC 網路通過 VPC 網路對等互連相互連接並連接到 Google Cloud 中的非 Kubernetes 應用。對等互連之間不會通告 PUPI 位址空間。VPC 網路通過 Cloud VPN 隧道連接到公司網路。
只有集群中的 Pod 才能彼此直接通信。節點在集群外部與其他集群、公司網路或連接的本地網路通信時，使用 SNAT 偽裝 Pod IP 空間。您無法直接從其他集群或公司網路訪問 Pod。通過 VPC 網路對等互連連接只能訪問使用內部負載等化器公開的 Service。
此架構模式類似於上述 Cloud VPN 方法，但比該模式具有以下優勢：
與 Cloud VPN 架構模式不同，VPC 網路對等互連不會因 Cloud VPN 隧道或環境之間的頻寬產生任何額外費用。
VPC 網路對等互連沒有頻寬限制，並完全集成到 Google 的軟體定義網路中。因此，VPC 網路對等互連提供的延遲時間可能略低於 Cloud VPN，因為對等互連不需要 Cloud VPN 所需的閘道和處理。
但是，VPC 網路對等互連模型與 Cloud VPN 模型相比具有以下缺點：
您的組織需要這樣一個公共 IP 位址空間，該空間既未使用，又足夠大，可滿足您預期的最大 GKE 集群所需的 Pod IP 位址空間。
VPC 網路對等互連不具有傳遞性。因此，通過 VPC 網路對等互連連接到主 VPC 網路的 GKE 集群無法直接相互通信，也無法與與主 VPC 對等互連的 VPC 網路中的應用直接通信。您必須通過 VPC 網路對等互連直接連接這些網路，才能啟用此類通信，或者使用主 VPC 網路中的代理虛擬機器。
使用多 NIC 實例隱藏集群位址
此架構模式包含以下元件和技術，用於創建類似於孤島模式網路模型的模型：
它使用具有多個網路介面卡（多 NIC）的 Compute Engine 實例在 GKE 集群和主 VPC 網路之間創建隔離層。
它對在這些環境之間發送的 IP 位址使用 NAT。
如果您需要檢查、轉換或過濾進入或退出 GKE 集群的特定流量，則可以使用此模式。如果您需要執行此類檢查、轉換或過濾，請使用已部署的 Compute Engine 實例執行這些任務。如需瞭解詳情，請參閱 GKE 地址管理：所有 GKE CIDR 地址塊的 NAT。
使用多 NIC 實例隱藏集群位址具有以下優勢：
GKE 集群的 IP 位址空間對網路的其餘部分隱藏。每項服務只有一個 IP 位址會公開給使用中的 VPC 網路。
服務可在全球範圍內訪問，也可從連接的本地網路和對等互連網路訪問。
但是，使用多 NIC 實例隱藏集群位址具有以下缺點：
Comments