Cloud Customer Care 會分析您的設定、記錄和指標,並與合作夥伴協作,協助您診斷及解決正式環境事件。
Cloud Customer Care 提供多種方案,可滿足您的營運需求,且所有方案都涵蓋 GKE 和 Google Distributed Cloud。如果您已訂閱支援方案,則已享有這項服務。詳情請參閱 Cloud Customer Care 中心。
Google Distributed Cloud 支援服務的需求條件
如要有效排解業務關鍵事件,請務必執行下列操作:
- 請確認環境為最新版本,且在已發布的支援終止時間範圍內。詳情請參閱「版本支援政策」一節。
- 為系統元件啟用 Cloud Logging 和 Cloud Monitoring。詳情請參閱下方的「支援工具」一節。
支援工具
如要排解 Google Distributed Cloud 事件,Cloud Customer Care 會依據下列三項資訊:
環境設定
開啟客服案件時,請執行下列指令,提供叢集設定的重要資訊:
無論叢集類型為何,請執行
bmctl check cluster --snapshot指令,擷取 Kubernetes 和節點的相關資訊。將產生的 tar 檔案附加至客服案件。如果是管理員、混合式和獨立叢集,請執行
bmctl check cluster指令,檢查叢集和節點的健康狀態。將產生的記錄附加至客服案件。記錄應位於bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP]目錄下。如果是使用者叢集,請先建立健康狀態檢查 YAML 檔案,並在檔案中指定叢集名稱和命名空間,然後在適當的管理員叢集中套用該檔案:
使用下列
healthcheck屬性建立 YAML 檔案。以下是cluster-user1命名空間中名為user1的叢集內容範例:apiVersion: baremetal.cluster.gke.io/v1 kind: HealthCheck metadata: generateName: healthcheck- namespace: cluster-user1 spec: clusterName: user1建立 YAML 檔案後,請使用
kubectl指令,在管理使用者叢集的管理員叢集中套用自訂資源。以下範例指令使用上一步建立的 YAML 檔案。在範例中,ADMIN_KUBECONFIG變數指定了管理員叢集 kubeconfig 檔案的路徑:kubectl --kubeconfig ADMIN_KUBECONFIG create -f healthcheck-user1.yaml指令會傳回下列回應:
healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf created等待健康狀態檢查工作完成。方法是測試健康狀態檢查工作是否已完成協調。在上述範例中,健康狀態檢查工作名稱為
healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf。以下是使用kubectl指令的測試範例,會等待 30 分鐘,讓健康狀態檢查工作完成:kubectl --kubeconfig ADMIN_KUBECONFIG wait healthcheck healthcheck-7c4qf \ -n cluster-user1 --for=condition=Reconciling=False --timeout=30m健康狀態檢查工作完成後,上述
kubectl指令會傳回:healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf condition met您可以使用下列指令查看健康狀態檢查工作結果:
kubectl --kubeconfig ADMIN_KUBECONFIG get healthcheck healthcheck-7c4qf \ -n cluster-user1指令會傳回下列結果:
NAME PASS AGE healthcheck-7c4qf true 17m使用
kubectl指令,將健康狀態檢查工作 Pod 的所有記錄檔收集到本機檔案。以下範例使用先前的健康狀態檢查工作範例:kubectl --kubeconfig ADMIN_KUBECONFIG logs -n cluster-user1 \ -l baremetal.cluster.gke.io/check-name=healthcheck-7c4qf --tail=-1 > \ healthcheck-7c4qf.log
叢集記錄檔
建立新的 Google Distributed Cloud 叢集時,系統預設會啟用 Cloud Logging 代理程式,且範圍僅限於系統層級元件。這會將系統層級記錄複製到與叢集相關聯的 Google Cloud 專案。系統層級記錄來自下列命名空間中的 Kubernetes Pod:
kube-systemgke-systemgke-connectistio-systemconfig-management-systemgatekeeper-systemcnrm-systemknative-serving
您可以在Logs Explorer中查詢記錄。
詳情請參閱「設定記錄和監控功能」。
Google Cloud CLI 和遠端叢集存取權
如果您提交客服案件,Cloud Customer Care 可能會要求您授予叢集的遠端唯讀存取權,以便更有效率地診斷及解決問題。為確保 Cloud Customer Care 有足夠的存取權,可從遠端排解叢集問題,請務必安裝並更新至最新版的 Google Cloud CLI。Google Cloud CLI 必須為 401.0.0 以上版本,才能將必要權限授予 Cloud Customer Care。建議您定期更新 Google Cloud CLI,以便取得新增的權限和其他強化功能。
如要安裝 gcloud CLI 的最新元件,請使用 gcloud components update 指令。如要進一步瞭解如何授予 Cloud Customer Care 叢集的遠端唯讀存取權,請參閱「遠端 GKE 叢集支援」。
叢集指標
除了記錄之外,Cloud Monitoring 代理程式也會擷取指標。這會將系統層級指標複製到與叢集相關聯的 Google Cloud 專案。系統層級指標來自 Kubernetes Pod,這些 Pod 在「叢集記錄檔」一節列出的相同命名空間中執行。
詳情請參閱「設定記錄和監控功能」。
我們如何排解環境問題
以下是常見的支援事件範例:
叢集管理員在 Google Cloud 控制台向 Cloud Customer Care 建立客服案件。接著,他們分別選取 GKE 和 Google Distributed Cloud 做為「Category」(類別) 和「Component」(元件)。他們輸入必要資訊,並將相關
bmctl指令的輸出內容附加到案件中。客服案件會轉送給專精於 Google Distributed Cloud 的技術支援工程師。
支援工程師會檢查快照內容,瞭解環境背景資訊。
支援工程師會檢查 Google Cloud專案中的記錄和指標。他們輸入客服案件 ID 做為業務理由,並記錄在內部。
支援工程師會回覆案件,提供評估結果和建議。支援工程師和使用者會持續排解問題,直到找出解決方案。
Google 支援哪些項目?
一般來說,Cloud Customer Care 支援 Google Distributed Cloud、Cloud Service Mesh、Policy Controller、Config Sync 和 Config Controller 隨附的所有軟體元件。下表列出更完整的支援和不支援項目:
| Google Cloud 支援 | 不支援 |
|---|---|
| Kubernetes 和容器執行階段 | 客戶選擇的負載平衡器 (手動負載平衡) |
| Connect 和 Connect 代理 | 客戶代碼 (請參閱開發人員支援) |
| Google Cloud 作業、Monitoring、Logging 和代理程式 | 客戶可選擇作業系統 |
| 隨附的負載平衡器 | 實體或虛擬伺服器、儲存空間和網路 |
| Ingress 控制器 | 外部 DNS、DHCP 和身分系統 |
| GKE 身分認證服務 | |
| Cloud Service Mesh | |
| Policy Controller | |
| Config Sync | |
| Config Controller |
版本支援政策
這項版本支援政策旨在讓您能彈性安排升級時程,滿足業務需求,同時兼顧 Kubernetes 和 Google Distributed Cloud 的快速演進。
Google Distributed Cloud 軟體僅遵循 Kubernetes 版本管理配置和發布週期。次要版本大約每年發布三次。每個支援的子版本大約每月會推出修補程式。與 Kubernetes 相同,Google Distributed Cloud 同時支援最新的三個子版本。
Google 支援每個 Google Distributed Cloud 子版本,期限為下列兩者中較晚者:
- 子版本首次發布後 12 個月。
- 第三個後續子版本發布。
例如,子版本 1.33 於 2025 年 9 月 2 日發布。這個子版本和所有修補程式的支援期限為 2026 年 9 月 2 日,或子版本 1.36 的發布日期,以較晚者為準。
建議您使用產品的最新子版本和建議的修補程式版本,維護 Google Distributed Cloud 環境。
這項版本支援政策包含:
- Cloud Customer Care 提供的故障維修支援。
- Kubernetes 和相關元件的 CVE 安全漏洞。
- Kubernetes 和相關元件的一般修補程式。
版本達到生命週期終點後,您仍可提交客服案件,取得下列支援:
- 技術問題相關說明。
- 協助解決帳單問題。
- 產品使用指南,包括疑難排解和測試。
延長支援服務可視情況核准為一次性事件,並須符合版本固定和未來升級時間軸規定。如需更多資訊,請洽詢您帳戶的主要客戶工程師或客戶經理。或者,您也可以透過 Google Cloud 控制台提交客服案件。這類要求會轉送至您帳戶的客戶工程團隊。
支援期
下表列出 Google Distributed Cloud 支援的次要版本,以及最早的生命週期結束 (EOL) 日期:
| Google Distributed Cloud 版本 | 發布日期 | 停售日期* |
|---|---|---|
| 1.35 | 2026-04-29 | 2027-04-29 或 1.38 版發布日期 |
| 1.34 | 2025-12-11 | 2026-12-11 或 1.37 發布日期 |
| 1.33 | 2025-09-02 | 2026-09-02 或 1.36 版發布日期 |
| 1.32 | 2025-05-06 | 2026-05-06 或 1.35 版發布日期 |
產品停產 (EOL) 日期將以這兩個日期中較晚者為準。
如要進一步瞭解 Google Distributed Cloud 和相關Google Cloud 產品的版本相容性,請參閱「版本和升級支援」。
版本管理架構
Google Distributed Cloud 使用 Kubernetes 語意版本管理來參照支援的 Kubernetes 版本,但會附加 GKE 修補程式版本。因此版本號碼的格式為:x.y.z-gke.N。
- Kubernetes 主要版本 (x)
- 如果公開 API 導入任何回溯不相容的變更,主要版本通常會遞增。主要版本會將 Kubernetes 版本從
x.y遞增至x+1.y。 - Kubernetes 子版本 (y)
- Kubernetes 一年會推出三個新的子版本。每個發布週期約 15 週。已淘汰的 API 可能會在新子版本中移除。子版本會將 Kubernetes 版本從
1.y遞增至1.y+1,例如 Kubernetes 1.29 是 Kubernetes 1.28 之後的次要版本。 - Google Distributed Cloud 修補程式版本 (z-gke.N)
- 修補程式版本 (例如 1.28.300-gke.131) 會將修補程式版本 (z) 遞增 100,並包含
-gke.N後置字串,表示建構作業。修補程式版本包含安全性更新和錯誤修正。Google Distributed Cloud 修補程式發布版本與 Kubernetes 修補程式版本無關。
共同責任模式
在 Google Distributed Cloud 執行重要業務正式版應用程式,需由多方各司其職,以下各節列出不同當事人的角色和責任,但並非完整清單。
Google 的責任
- 維護及發布 Google Distributed Cloud 軟體套件。
通知使用者 Google Distributed Cloud 有可用的升級版本,並產生舊版本的升級指令碼。
Google Distributed Cloud 僅支援依序升級叢集 (例如 1.34 → 1.35 → 1.36,而非 1.34 → 1.36)。升級節點集區時,在某些情況下可以略過子版本。如要進一步瞭解升級邏輯,請參閱「版本規則」。
操作 Connect 和 Cloud Operations 服務。
疑難排解、提供解決方法,以及修正與 Google 提供元件相關的任何問題根本原因。
使用者責任
- 地端部署叢集的整體系統管理。
- 維護部署在叢集上的任何應用程式工作負載。
- 執行、維護及修補資料中心基礎架構,包括網路、伺服器、作業系統、儲存空間,以及與Google Cloud的連線。
- 如果選擇手動負載平衡器選項,則須執行、維護及修補網路負載平衡器。
- 定期升級 Google Distributed Cloud 版本。
- 監控叢集和應用程式,並應對任何事件。
- 確保 Cloud 作業套件代理程式已部署至叢集。
- 提供所需的環境詳細資料,以利 Google 進行疑難排解。
開發人員支援
Google 不會專門為您的應用程式工作負載提供支援。不過,我們會盡力提供開發人員支援,確保開發人員能在 Google Distributed Cloud 執行應用程式。我們認為,在開發階段提早參與,可以避免在部署階段發生重大事件。
凡是購買付費支援方案的客戶,均可享有這項盡力而為的開發人員支援服務。如果問題阻礙產品推出,則會視為 P3 優先順序;如果是一般諮詢,則會視為 P4 優先順序。在這個分類中,優先順序等級 0 是最高優先順序。