排解虛擬私有雲叢集中的 IP 位址管理問題

本頁面可協助您解決 Google Kubernetes Engine (GKE) 虛擬私有雲叢集中的 IP 位址管理問題。

本頁面會引導平台管理員和運算子診斷及解決問題，例如節點和 Pod 的 IP 位址耗盡、排解會阻礙叢集作業 (例如範圍衝突) 的網路設定錯誤、管理 IP 位址 CIDR 範圍，以及正確設定預設 SNAT、Cloud NAT 和雙堆疊網路等功能。

應用程式開發人員也能透過本頁瞭解，IP 空間耗盡等基礎網路限制，如何影響工作負載，導致 Pod 無法排程等問題。開發人員可能不會直接設定虛擬私有雲，但瞭解這些常見問題有助於他們與平台管理員和作業人員合作，更快解決問題。如要進一步瞭解我們在Google Cloud 內容中提及的常見角色和範例工作，請參閱「常見的 GKE 使用者角色和工作」。

診斷 IP 位址耗盡問題

如果叢集中的 IP 位址用盡，節點就無法擴充，工作負載也會中斷。本節說明如何在 GKE 中使用 IP 位址用量監控功能，偵測及解決潛在的用盡問題。

GKE 會使用 網路分析器深入分析和其他 GKE 資料來源的資料，計算 IP 位址用量。這項監控功能適用於所有 VPC 原生叢集。

如要查看叢集的 IP 位址用量，請執行下列操作：

  1. 在 Google Cloud 控制台中，前往「Kubernetes clusters」(Kubernetes 叢集) 頁面。

    前往 Kubernetes 叢集

  2. 按一下要檢查的叢集名稱。這項操作會開啟叢集的「Details」(詳細資料) 頁面。

  3. 使用下列任一方法前往「IP 使用率」頁面：

    • 選取「Observability」(觀測能力) 分頁標籤，然後在觀測導覽選單中，按一下「IP utilization」(IP 使用率)。

    • 在「Networking」(網路) 區段中，找到「Cluster Pod IPv4 range (default)」(叢集 Pod IPv4 範圍 (預設)) 列，然後按一下「View IP utilization」(查看 IP 使用率)。

  4. 查看「IP 分配狀態」欄。這個資料欄會顯示 Pod IP 位址範圍中已分配 IP 位址的百分比。無論個別 IP 位址是否指派給 Pod，GKE 都會將節點指派的 CIDR 範圍內的所有 IP 位址視為已分配。這表示百分比反映的是節點的整個 Pod 範圍，而不只是使用的 IP 位址。如有叢集共用同樣的 IP 位址範圍，使用率百分比就會顯示合併總計。

  5. 如要查看 IP 位址使用情況的詳細資料，包括 CIDR 範圍、子網路資訊和建議，請按一下「顯示詳細資料」。

如果 IP 位址使用率偏高 (接近 100%)，請考慮下列解決方案，避免 IP 位址耗盡：

  • 使用不連續的多 Pod CIDR 新增更多 Pod IPv4 位址範圍。 這項功能可讓您為 Pod 新增更多 IPv4 位址，不必重新建立叢集或設定新的子網路。
  • 在叢集內加入更多子網路及其他 IPv4 位址範圍。這項功能可讓新節點集區使用新加入子網路的 IP 位址。
  • 建立 Pod 數量上限值較低的新叢集。這種做法可為每個節點保留較少的 IP 位址，有助於管理叢集網路範圍內的整體 IP 位址用量。詳情請參閱「設定每個節點的 Pod 數量上限」。
  • 如果沒有足夠的 IP 位址範圍或 RFC 1918 位址空間，請考慮非 RFC 1918 範圍 (包括 E 類位址空間)。

排解特定網路問題

下列各節說明如何解決虛擬私有雲原生叢集的相關問題。您也可以查看 GKE IP 位址使用率深入分析資訊。

預設網路資源尚未就緒

問題

您會收到類似以下的錯誤訊息：

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default
可能原因

同一個子網路上有多個平行作業，例如系統正在建立其他虛擬私有雲端原生叢集，或正在子網路中新增或刪除次要範圍。

解析度

重試該指令。

「IPCidrRange」的值無效

問題

您會收到類似以下的錯誤訊息：

resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'
可能原因

系統正在同時建立其他虛擬私人雲端原生叢集，並嘗試在相同虛擬私有雲網路中分配相同的範圍。

系統正在相同虛擬私有雲網路的子網路中新增相同的次要範圍。

解析度

如果您未指定次要範圍，當系統在建立叢集時傳回這個錯誤，請重試叢集建立指令。

沒有足夠的 IP 位址空間可供 Pod 使用

問題

叢集長時間卡在佈建狀態。

叢集建立作業傳回代管執行個體群組 (MIG) 錯誤。

將一或多個節點新增至叢集時，會出現下列錯誤：

[IP_SPACE_EXHAUSTED] Instance 'INSTANCE_NAME' creation failed: IP space of 'projects/PROJECT_ID/regions/REGION/subnetworks/[SUBNET_NAME]-[SECONDARY_RANGE_NAME]-[HASH_8BYTES]' is exhausted. The secondary range name is in the format of 'gke-[CLUSTER_NAME]-[HASH_8BYTES]'.
可能原因

節點 IP 位址耗盡：指派給叢集的子網路主要 IP 位址範圍，已沒有可用的 IP 位址。這通常發生在擴充節點集區或建立大型叢集時。

Pod IP 位址用盡：指派給叢集的 Pod CIDR 範圍已滿。當 Pod 數量超過 Pod CIDR 的容量時，就會發生這種情況，特別是每個節點的 Pod 密度很高或部署作業規模龐大時。

特定子網路命名慣例：錯誤訊息中子網路的命名方式，有助於判斷問題是出在節點 IP 位址範圍 (節點本身會從這個範圍取得 IP 位址)，還是 Pod IP 位址範圍 (Pod 內的容器會從這個範圍取得 IP 位址)。

次要範圍耗盡 (Autopilot)：在 Autopilot 叢集中，由於調度或 Pod 密度偏高，指派給 Pod IP 位址的次要範圍已耗盡。

解決方案

收集叢集的下列資訊：名稱、控制平面版本、作業模式、相關聯的 VPC 名稱，以及子網路名稱和 CIDR。此外，請記下預設和任何額外的叢集 Pod IPv4 範圍 (包括名稱和 CIDR)、是否已啟用虛擬私有雲原生流量轉送功能，以及叢集和節點集區層級的每個節點 Pod 數量上限設定 (如適用)。如果受影響的節點集區的 IPv4 Pod IP 位址範圍和每個節點的 Pod 數量上限設定與叢集範圍設定不同，請記下這些設定。此外，請記錄節點集區設定中，每個節點的 Pod 數量上限預設和自訂 (如有) 設定。

確認 IP 位址用盡問題

  • Network Intelligence Center：在 GKE 叢集的 Network Intelligence Center 中，檢查 Pod IP 位址範圍的 IP 位址分配率是否偏高。

    如果在 Network Intelligence Center 內觀察到 Pod 範圍中的 IP 位址分配率偏高，表示 Pod IP 位址範圍已用盡。

    如果 Pod IP 位址範圍顯示正常分配率，但您仍遇到 IP 位址耗盡問題，則可能是節點 IP 位址範圍已耗盡。

  • 稽核記錄：檢查 IP_SPACE_EXHAUSTED 項目中的 resourceName 欄位，並與子網路名稱或次要 Pod IP 位址範圍名稱進行比較。

  • 確認耗盡的 IP 位址範圍是節點 IP 位址範圍還是 Pod IP 位址範圍。

    如要確認 IP 位址範圍用盡的原因是節點 IP 位址範圍還是 Pod IP 位址範圍，請檢查 IP_SPACE_EXHAUSTED 記錄項目 ipSpaceExhausted 部分的 resourceName 值，是否與受影響 GKE 叢集使用的子網路名稱或 Pod 的次要 IPv4 位址範圍名稱相關。

    如果 resourceName 的值採用「[Subnet_name]」格式，則節點 IP 位址範圍已用盡。如果 resourceName 的值採用「[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]」格式，表示 Pod IP 位址範圍已用盡。

解決 Pod IP 位址用盡的問題：

  • 調整現有 Pod CIDR 的大小：增加目前的 Pod IP 位址範圍大小。您可以使用不連續的多 Pod CIDR，將 Pod IP 範圍新增至叢集。
  • 建立額外的子網路：將具有專屬 Pod CIDR 的子網路新增至叢集。

減少每個節點的 Pod 數，釋出 IP 位址：

位址節點 IP 位址耗盡：

  • 檢查 IP 位址規劃：確認節點 IP 位址範圍符合您的擴充需求。
  • 建立新叢集 (如有必要)：如果節點 IP 位址範圍受到嚴重限制，請建立適當 IP 位址範圍大小的替代叢集。請參閱虛擬私有雲原生叢集的 IP 範圍和IP 範圍規劃。

使用 gcpdiag 偵錯 IP 位址耗盡問題

gcpdiag 是開放原始碼工具。這並非正式支援的 Google Cloud 產品。您可以使用 gcpdiag 工具找出並修正 Google Cloud專案問題。詳情請參閱 GitHub 上的 gcpdiag 專案。

如要檢查 Autopilot 和 Standard GKE 叢集上的 IP 位址耗盡原因，請考慮下列事項：
  • 叢集狀態：如果系統回報 IP 位址耗盡，請檢查叢集狀態。
  • 網路分析器：查詢網路分析器記錄的 Stackdriver 記錄，確認是否有 Pod 或節點 IP 位址耗盡的情況。
  • 叢集類型：檢查叢集類型，並根據叢集類型提供相關建議。

Google Cloud 控制台

  1. 完成下列指令後，請複製指令。
    2. gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \
  2. 開啟 Google Cloud 控制台並啟用 Cloud Shell。
    3. 開啟 Cloud 控制台
  3. 貼上複製的指令。
  4. 執行 gcpdiag 指令，下載 gcpdiag Docker 映像檔，然後執行診斷檢查。如適用，請按照輸出內容中的操作說明修正失敗的檢查。

Docker

您可以使用在 Docker 容器中啟動 gcpdiag 的 wrapper 執行 gcpdiag。必須安裝 Docker 或 Podman。

  1. 複製下列指令，並在本機工作站上執行。 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. 執行 gcpdiag 指令。 
    ./gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \

查看這本 Runbook 的可用參數。

更改下列內容：

  • PROJECT_ID：包含資源的專案 ID
  • CLUSTER_NAME：專案中目標 GKE 叢集的名稱。
  • LOCATION：叢集所在的可用區或區域。
  • start_time：問題開始時間。
  • end_time：問題結束時間。如果問題仍未解決，請設定目前時間。

實用標記：

如需所有 gcpdiag 工具旗標的清單和說明，請參閱 gcpdiag 使用說明。

確認預設 SNAT 是否已停用

使用下列指令檢查預設 SNAT 的狀態：

gcloud container clusters describe CLUSTER_NAME

將 CLUSTER_NAME 替換為叢集名稱。

輸出結果會與下列內容相似：

networkConfig:
  disableDefaultSnat: true
  network: ...

無法在沒有 --enable-ip-alias 的情況下使用 --disable-default-snat

這則錯誤訊息和 must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster 表示您在私人叢集中使用公開 IP 位址，因此建立叢集時應明確設定 --disable-default-snat 標記。

如果看到 cannot disable default sNAT ... 等錯誤訊息，表示叢集無法停用預設 SNAT。如要解決這個問題，請檢查叢集設定。

停用預設 SNAT 後偵錯 Cloud NAT

如果您使用 --disable-default-snat 旗標建立私人叢集，並已設定 Cloud NAT 來存取網際網路，但 Pod 傳出的流量並未連上網際網路，請確認 Pod 範圍已納入 Cloud NAT 設定。

如果 Pod 間的通訊發生問題，請檢查節點上的 iptables 規則，確認 iptables 規則不會偽裝 Pod 範圍。

詳情請參閱 GKE IP 偽裝說明文件。

如果尚未為叢集設定 IP 偽裝代理程式，GKE 會自動確保 Pod 間的通訊不會遭到偽裝。不過，如果已設定 IP 偽裝代理程式，系統會覆寫預設的 IP 偽裝規則。確認 IP 偽裝代理程式中已設定額外規則，可忽略 Pod 範圍的偽裝。

雙堆疊叢集網路通訊無法正常運作

可能原因
GKE 叢集建立的防火牆規則不包含已分配的 IPv6 位址。
解析度
如要驗證防火牆規則，請按照下列步驟操作：

  1. 確認防火牆規則內容：

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME

    將 FIREWALL_RULE_NAME 替換為防火牆規則的名稱。

    每個雙堆疊叢集都會建立防火牆規則，允許節點和 Pod 彼此通訊。防火牆規則內容類似於下列內容：

    allowed:
- IPProtocol: esp
- IPProtocol: ah
- IPProtocol: sctp
- IPProtocol: tcp
- IPProtocol: udp
- IPProtocol: '58'
creationTimestamp: '2021-08-16T22:20:14.747-07:00'
description: ''
direction: INGRESS
disabled: false
enableLogging: false
id: '7326842601032055265'
kind: compute#firewall
logConfig:
  enable: false
name: gke-ipv6-4-3d8e9c78-ipv6-all
network: https://www.googleapis.com/compute/alpha/projects/my-project/global/networks/alphanet
priority: 1000
selfLink: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/gke-ipv6-4-3d8e9c78-ipv6-all
selfLinkWithId: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/7326842601032055265
sourceRanges:
- 2600:1900:4120:fabf::/64
targetTags:
- gke-ipv6-4-3d8e9c78-node

    sourceRanges 值必須與 subnetIpv6CidrBlock 相同。 targetTags 值必須與 GKE 節點上的標記相同。如要修正這個問題，請更新防火牆規則，並提供叢集 ipAllocationPolicy 區塊資訊。

後續步驟