本節說明如何解決虛擬私有雲原生叢集的相關問題。您也可以查看 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 位址範圍已耗盡。
稽核記錄：檢查項目中的
resourceName欄位，並與子網路名稱或次要 Pod IP 位址範圍名稱進行比較。resourceNameIP_SPACE_EXHAUSTED檢查耗盡的 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 位址：
- 建立新的節點集區，並減少每個節點的 Pod 數量上限。
- 將工作負載遷移至該節點集區，然後刪除先前的節點集區。減少每個節點的最大 Pod 數，可讓您在 Pod 的固定次要 IP 位址範圍內支援更多節點。如要進一步瞭解相關計算，請參閱「Pod 的子網路次要 IP 位址範圍」和「節點限制範圍」。
位址節點 IP 位址耗盡：
- 檢查 IP 位址規劃：確保節點 IP 位址範圍符合您的擴充需求。
- 建立新叢集 (如有必要)：如果節點 IP 位址範圍受到嚴重限制，請建立替代叢集，並適當調整 IP 位址範圍大小。請參閱虛擬私有雲原生叢集的 IP 範圍和IP 範圍規劃。
使用 gcpdiag 偵錯 IP 位址耗盡問題
gcpdiag
是開放原始碼工具。這並非正式支援的 Google Cloud 產品。您可以使用 gcpdiag 工具找出並修正 Google Cloud專案問題。詳情請參閱 GitHub 上的 gcpdiag 專案。
- 叢集狀態：如果系統回報 IP 位址耗盡，請檢查叢集狀態。
- 網路分析器：查詢網路分析器記錄的 Stackdriver 記錄，確認是否有 Pod 或節點 IP 位址耗盡的情況。
- 叢集類型：檢查叢集類型，並根據叢集類型提供相關建議。
Google Cloud 控制台
- 完成下列指令，然後複製。
- 開啟 Google Cloud 控制台並啟用 Cloud Shell。 開啟 Cloud 控制台
- 貼上複製的指令。
- 執行
gcpdiag指令，下載gcpdiagDocker 映像檔，然後執行診斷檢查。如適用，請按照輸出內容中的操作說明修正失敗的檢查。
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 \Docker
您可以使用在 Docker 容器中啟動 gcpdiag 的
wrapper 執行 gcpdiag。必須安裝 Docker 或 Podman。
- 複製下列指令，並在本機工作站上執行。
curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
- 執行
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：問題結束時間。如果問題仍未解決，請設定目前時間。
實用標記：
--universe-domain：如果適用，代管資源的信任合作夥伴主權雲端網域--parameter或-p：Runbook 參數
如需所有 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 對 Pod 通訊發生問題，請檢查節點上的 iptables 規則，確認 iptables 規則不會偽裝 Pod 範圍。
詳情請參閱 GKE IP 偽裝說明文件。
如果尚未為叢集設定 IP 偽裝代理程式，GKE 會自動確保 Pod 間的通訊不會遭到偽裝。不過，如果已設定 IP 偽裝代理程式，系統會覆寫預設的 IP 偽裝規則。確認 IP 偽裝代理程式中已設定額外規則，可忽略 Pod 範圍的偽裝。
雙堆疊叢集網路通訊無法正常運作
- 可能原因
- GKE 叢集建立的防火牆規則不包含已分配的 IPv6 位址。
- 解決方法
- 如要驗證防火牆規則，請按照下列步驟操作：
確認防火牆規則內容：
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-nodesourceRanges值必須與subnetIpv6CidrBlock相同。targetTags值必須與 GKE 節點上的標記相同。如要修正這個問題，請更新防火牆規則，並提供叢集ipAllocationPolicy區塊資訊。
後續步驟
如需診斷 Kubernetes DNS 問題的一般資訊，請參閱「偵錯 DNS 解析」。
如果無法在說明文件中找到問題的解決方法，請參閱「取得支援」一文，尋求進一步的協助， 包括下列主題的建議：
- 與 Cloud 客戶服務聯絡，建立支援案件。
- 在 StackOverflow 上提問，並使用
google-kubernetes-engine標記搜尋類似問題，向社群尋求支援。你也可以加入#kubernetes-engineSlack 頻道，取得更多社群支援。 - 使用公開問題追蹤工具回報錯誤或提出功能要求。