如需版本資訊，請參閱「Distributed Cloud connected 版本資訊」。

Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

排解 Distributed Cloud connected 問題

Google 會從遠端監控及維護 Google Distributed Cloud 連結網路方案硬體。為此，Google 工程師可透過安全殼層 (SSH) 存取 Distributed Cloud 連結硬體。如果 Google 偵測到問題，Google 工程師會與您聯絡，協助您排解及解決問題。如果您自行發現問題，請立即與 Google 支援團隊聯絡，以便診斷及解決問題。

Distributed Cloud connected 軟體升級

本節說明如何使用 Metrics Explorer，檢查 Distributed Cloud 連線叢集是否正在進行軟體升級。

這個程序會使用下列監控指標：

目前叢集版本 (/edge_cluster/current_cluster_version)：指出叢集上執行的 Distributed Cloud 連結軟體目前版本。
目標叢集版本 (/edge_cluster/target_cluster_version)：指出叢集升級的 Distributed Cloud connected 目標版本。

如要完成本節中的步驟，必須符合下列必要條件：

存取 Google Cloud 控制台和 Distributed Cloud 連線 Google Cloud 專案。
Monitoring 檢視者 IAM 角色，可讓您查看 Monitoring 指標。
(選用) 目標 Distributed Cloud connected 機器的 machine_id 值，用於篩選傳回的結果。

使用 Metrics Explorer 檢查叢集的目前和目標軟體版本

前往 Metrics Explorer：
1. 在 Google Cloud 控制台中，前往「Monitoring」部分。
2. 在左側導覽樹狀結構中，按一下「指標探索器」。
選取目標資源類型：
1. 在「Metrics Explorer」頁面中，前往「Configuration」頁面。
2. 按一下「Select a metric」(選取指標)。
3. 使用搜尋列搜尋「叢集」資源類型。您也可以使用完整資源 ID edgecontainer.googleapis.com/Cluster。
4. 在傳回的結果中，按一下「叢集」資源類型。
取得叢集的目前軟體版本：
1. 在「指標」部分，搜尋 current_cluster_version 值。
2. 選取「機器正常運作時間」指標。完整路徑為 edgecontainer.googleapis.com/edge_cluster/current_cluster_version。
3. (選用) 使用「Filter」(篩選器) 區段，依目標 machine_id 值篩選。
取得叢集的目標軟體版本：
1. 按一下「新增查詢」。
2. 在「指標」部分，搜尋 target_cluster_version 值。
3. 選取「目標叢集版本」指標。完整路徑為 edgecontainer.googleapis.com/edge_cluster/target_cluster_version。
4. (選用) 使用「Filter」(篩選器) 區段，依目標 machine_id 值篩選。
在顯示的圖表中，查看叢集的軟體升級狀態。
- 如果「目前的叢集版本」和「目標叢集版本」行分別顯示不同的值，表示叢集正在進行軟體升級。
- 如果「目前的叢集版本」和「目標叢集版本」行顯示相同的值，表示叢集未進行軟體升級。
使用下列指令驗證上一個步驟的結果：
```
gcloud edge-cloud container clusters describe CLUSTER_ID --location=REGION
```
更改下列內容：
- CLUSTER_ID：目標叢集的 ID。
- REGION：叢集建立所在的 Google Cloud 區域。
在指令輸出中，請記下下列欄位的值：
- 如果 status 欄位的值為 UPDATING，表示叢集正在進行軟體升級。
- 如果 clusterVersion 和 targetVersion 欄位的值不同，請根據 Metrics Explorer 傳回的值檢查這些欄位。

解讀結果

下表說明 Metrics Explorer 和 gcloud 指令傳回的結果。

叢集狀態	診斷	解析度
正常 `currentVersion` 和 `targetVersion` 值相符 `status` 值為 `RUNNING`	叢集執行的是目標版本的 Distributed Cloud 連結網路方案軟體。	無
升級 `currentVersion` 值低於 `targetVersion` `status` 值為 `UPDATING`	叢集正在升級至 Distributed Cloud 連線軟體的目標版本。	在 Metrics Explorer 中監控叢集，直到目前和目標叢集版本值相符為止。
卡住 `currentVersion` 值無限期低於 `targetVersion` `status` 值無限期為 `UPDATING`	叢集至少有一個節點無法升級至目標版本的 Distributed Cloud 連線軟體。	檢查電腦連線和系統記錄，並向 Google 尋求協助。
回溯 `currentVersion` 值高於 `targetVersion` `status` 值為 `UPDATING`	叢集正在還原至舊版 Distributed Cloud 連結軟體。	請與 Google 聯絡，找出復原原因。

如果叢集的軟體升級失敗，或叢集已復原為先前的軟體版本，請檢查下列事項：

節點健康狀態。確認每個實體 Distributed Cloud 連線機器都有網路連線，並回報正常運作時間，如下一節所述。
維護期間。確認軟體升級是否因維護作業排除時段而暫停。
系統記錄。檢查系統記錄，找出軟體升級失敗的可能原因，例如 Pod 驅逐逾時。

如果表格中列出的解決步驟無法解決問題，請與 Google 支援團隊聯絡，並提供受影響機器的 machine_id 值和中斷時間戳記。

Distributed Cloud connected 電腦重新啟動

本節說明如何使用 Metrics Explorer，檢查 Distributed Cloud 連線實體機器是否已重新啟動，並判斷重新啟動的原因。監控重新啟動作業有助於判斷這些作業是否為預先規劃的維護作業，或是硬體故障或電力中斷所致。

這個程序會使用下列監控指標：

機器運作時間 (/machine/uptime)：表示自上次重新啟動以來經過的時間 (以秒為單位)。
裝置重新啟動 (/machine/restart_count)：顯示目標裝置自部署以來重新啟動的總次數。

如要完成本節中的步驟，必須符合下列必要條件：

存取 Google Cloud 控制台和 Distributed Cloud 連線 Google Cloud 專案。
Monitoring 檢視者 IAM 角色，可讓您查看 Monitoring 指標。
(選用) 目標 Distributed Cloud connected 機器的 machine_id 值，用於篩選傳回的結果。

使用 Metrics Explorer 檢查機器運作時間和重新啟動次數

前往 Metrics Explorer：
1. 在 Google Cloud 控制台中，前往「Monitoring」部分。
2. 在左側導覽樹狀結構中，按一下「指標探索器」。
選取目標資源類型：
1. 在「Metrics Explorer」頁面中，前往「Configuration」頁面。
2. 按一下「Select a metric」(選取指標)。
3. 使用搜尋列搜尋「機器」資源類型。您也可以使用完整資源 ID edgecontainer.googleapis.com/Machine。
4. 在傳回的結果中，按一下「機器」資源類型。
檢查機器的運作時間：
1. 在「指標」部分，搜尋 uptime 值。
2. 選取「機器正常運作時間」指標。完整路徑為 edgecontainer.googleapis.com/machine/uptime。
3. (選用) 使用「Filter」(篩選器) 區段，依目標 machine_id 值篩選。
4. 在顯示的時間圖表中，確認運作時間圖表持續上升。如果正常運作時間值在任何時間點降至零並重新啟動，表示機器已重新啟動。
檢查裝置的重新啟動次數：
1. 在「指標」部分，搜尋 restart_count 值。
2. 選取「機器重新啟動」指標。完整路徑為 edgecontainer.googleapis.com/machine/restart_count。
3. (選用) 使用「Filter」(篩選器) 區段，依目標 machine_id 值篩選。
4. 在顯示的時間圖表中，確認圖表線維持在 0，這表示沒有重新啟動。如果這條線在任何時間點突然飆升至 1，表示電腦已重新啟動；請記下重新啟動的確切時間戳記，以利進一步排解問題。
5. (選用) 如要查看個別事件而非圖表，請前往頁面的「彙整」部分，將「對齊週期」欄位設為 1 minute，並將「每個序列的對齊器」欄位設為「Delta」。

解讀結果

下表說明 Metrics Explorer 傳回的結果。

機器狀態	診斷	解析度
穩定「機器正常運作時間」指標穩定上升「機器重新啟動」指標差異為 `0`	機器尚未重新啟動。	無
乾淨重新啟動「電腦正常運作時間」指標降至 `0` 「電腦重新啟動」指標飆升至 `1`	電腦已成功重新啟動，並重新連線至 Google Cloud。	查看系統記錄，找出重新啟動的原因。
電源故障「機器正常運作時間」指標圖表出現中斷，沒有資料機器正常運作時間中斷期間，「機器重新啟動」指標沒有變更	電腦在重新啟動前斷電或失去網路連線。	檢查電源線和網路線、本機網路設定、LED 指示燈狀態。
間歇性「已連線的電腦」指標值在 `0` 和 `1` 之間交替「網路連線」指標值在 `0` 和 `1` 之間交替	網路連線不穩定、封包遺失或延遲時間過長。	檢查本機網路是否壅塞或有故障的硬體。

如果表格中列出的解決步驟無法解決問題，請與 Google 支援團隊聯絡，並提供受影響機器的 machine_id 值和中斷時間戳記。

Distributed Cloud connected 機器的連線能力

本節說明如何使用 Cloud Monitoring 的 Metrics Explorer 功能，檢查 Distributed Cloud 連線機器是否連上網際網路和 Google Cloud 連線能力。

這個程序會使用下列監控指標：

已連線的健身器材 (/machine/connected)：指出健身器材是否已連線至 Google Cloud。
網路連線 (/machine/network/connectivity)：指出電腦的主要網路介面是否已連上網際網路。

如要完成本節中的步驟，必須符合下列必要條件：

存取 Google Cloud 控制台和 Distributed Cloud 連線 Google Cloud 專案。
Monitoring 檢視者 IAM 角色，可讓您查看 Monitoring 指標。
(選用) 目標 Distributed Cloud connected 機器的 machine_id 值，用於篩選傳回的結果。

使用 Metrics Explorer 檢查機器連線

前往 Metrics Explorer：
1. 在 Google Cloud 控制台中，前往「Monitoring」部分。
2. 在左側導覽樹狀結構中，按一下「指標探索器」。
選取目標資源類型：
1. 在「Metrics Explorer」頁面中，前往「Queries」頁面。
2. 使用搜尋列搜尋「機器」資源類型。您也可以使用完整資源 ID edgecontainer.googleapis.com/Machine。
3. 在傳回的結果中，按一下「機器」資源類型。
檢查機器與 Google Cloud的連線：
1. 在「指標」部分，搜尋 connected 值。
2. 選取「已連線的機器」指標。完整路徑為 edgecontainer.googleapis.com/machine/connected。
3. (選用) 使用「Filter」(篩選器) 區段，依目標 machine_id 值篩選。
4. 在顯示的時間圖表中，確認「健康狀態良好」線持續維持在 100%。如果這個值在任何時間點為 0% 或「不正常」，表示機器在指定時間與 Google Cloud 失去連線。
檢查機器的網際網路連線：
1. 在「指標」部分，搜尋 connectivity 值。
2. 選取「網路連線」指標。完整路徑為 edgecontainer.googleapis.com/machine/network/connectivity。
3. (選用) 使用「Filter」(篩選器) 區段，依目標 machine_id 值篩選。
4. 在顯示的時間圖表中，確認「健康狀態良好」線持續維持在 100%。如果這個值在任何時間點為 0%「不正常」，表示機器在該時間點失去網際網路連線。

解讀結果

下表說明 Metrics Explorer 傳回的結果。

機器狀態	診斷	解析度
正常「已連線的機器」指標值為 `1` 「網路連線」指標值為 `1`	正常運作。	無
已中斷連線「Machine Connected」指標值為 `0` 「Network Connectivity」指標值為 `1`	電腦已連上網際網路，但無法連上 Google Cloud。	檢查 Google 服務和 API 端點的防火牆規則。確認 Distributed Cloud 連線代理程式是否正在機器上執行。
已隔離「已連線的電腦」指標值為 `0` 「網路連線」指標值為 `0`	電腦沒有網際網路連線。	檢查電源線和網路線、本機網路設定、LED 指示燈狀態。驗證 VLAN 和轉送設定。
間歇性「已連線的電腦」指標值在 `0` 和 `1` 之間交替「網路連線」指標值在 `0` 和 `1` 之間交替	網路連線不穩定、封包遺失或延遲時間過長。	檢查本機網路是否壅塞或有故障的硬體。

如果發現任一指標的 0 值持續偏高，請按照表格中說明的疑難排解步驟解決問題。如果問題仍未解決，請與 Google 支援團隊聯絡，並提供受影響機器的 machine_id 值和中斷時間戳記。

虛擬機器停滯在 `Pending` 狀態

如果發生下列情況，虛擬機器工作負載可能會停留在 Pending 狀態，且無法排定在節點上執行：

Distributed Cloud Connected 無法將要求的資源 (例如 CPU 時間、記憶體或磁碟空間) 分配給虛擬機器。
虛擬機器的設定有誤。
虛擬機器的儲存空間有故障。
目標節點已遭汙染。

如要解決這個問題，請按照下列步驟操作：

如「取得叢集憑證」一文所述，取得叢集憑證。

取得受影響虛擬機器的相關資訊：

kubectl describe virtualmachine VM_NAME -n NAMESPACE

更改下列內容：

VM_NAME：目標虛擬機器的名稱。
NAMESPACE：目標虛擬機器的命名空間。

指令會傳回類似以下內容的輸出結果：

Status:
...
State:                    Pending
...
Events:
Type     Reason                  Age   From                       Message
----     ------                  ----  ----                       -------
Normal   SuccessfulCreate        15m   virtualmachine-controller  Created virtual machine my-stuck-vm
Warning  DiskProvisioningFailed  14m   virtualmachine-controller  Failed to provision disk: DataVolume my-stuck-vm-data-disk not ready
Warning  PVCNotBound             14m   virtualmachine-controller  PersistentVolumeClaim my-stuck-vm-data-disk is in phase Pending
Warning  VMINotCreated           10m   virtualmachine-controller  VirtualMachineInstance cannot be created: dependencies not ready

指令輸出內容包含的訊息可能指出資源限制、排程失敗、儲存空間故障和其他問題。

檢查輸出內容，找出排程失敗的原因，詳情請參閱下幾節。

資源不足

您可能會看到資源不足的訊息，例如 CPU、記憶體或磁碟空間。例如：

5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.

如要解決這個問題，請檢查分配給受影響虛擬機器和節點上排定其他工作負載的資源，然後視業務需求執行下列操作：

縮減節點上排定的其他工作負載，
減少分配給受影響虛擬機器的資源量，
在受影響的叢集中新增更多機器。

遭汙染的節點

系統可能會顯示訊息，指出目標節點已遭汙染。例如：

5/8 nodes are available: 3 node(s) had taint {<taint-key>:<taint-value>}, that the pod didn't tolerate.

如要解決這個問題，請按照下列步驟操作：

使用下列指令檢查節點上的汙點：

kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

指令會傳回類似以下內容的輸出結果：

NAME                           TAINTS
node-name-1   [map[effect:PreferNoSchedule key:node-role.kubernetes.io/master] map[effect:PreferNoSchedule key:node-role.kubernetes.io/control-plane]]
node-name-2   <none>

執行下列其中一個步驟：
- 如遇到非預期的汙點，請按照「汙點和容許度」一文的說明移除。
- 如要處理預期的汙點，請按照「汙點和容許度」一文所述，在虛擬機器的設定中加入對應的容許度。

儲存空間故障

系統可能會顯示訊息，指出虛擬機器的儲存空間發生故障。例如：

5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.

這則訊息可能表示對應的永久磁碟區無法掛接至目標節點。

如要解決這個問題，請按照下列步驟操作：

使用下列指令，取得受影響虛擬機器命名空間中永久磁碟區聲明 (PVC) 的狀態：

kubectl get pvc -n NAMESPACE

將 NAMESPACE 替換為目標命名空間的名稱。

指令會傳回類似以下內容的輸出結果：

NAME                                               STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            AGE
windows-robin-disk-0                               Bound     pvc-b1a1d264-84bf-4e58-857d-f37f629d5082   25Gi       RWX            robin-block-immediate   30h
windows-robin-disk-1                               Bound     pvc-0130b9a8-7fed-4df0-8226-d79273792a16   25Gi       RWX            robin-block-immediate   30h
windows-robin-vm-0-restored-windows-robin-disk-0   Pending                                                                        gce-pd-gkebackup-in     26m

確認對應的 PVC 處於 Bound 狀態；如果狀態為 Pending，表示儲存子系統無法佈建磁碟區。在這種情況下，您必須排解儲存子系統設定問題，並確保可使用適當的 StorageClass。

許可 Webhook 失敗導致排程鎖定

透過 Admission Webhook，您可以在物件變成持續性物件之前，攔截對 Kubernetes API 伺服器的要求。雖然網路鉤子有助於強制執行自訂安全政策，但設定錯誤可能會導致叢集全面中斷，尤其是在軟體升級和憑證重新整理等重要作業期間。具體來說，如果 Admission Webhook 遭到封鎖或無法使用，Kubernetes 控制層可能會停滯，導致叢集無法再排定任何工作負載。

控制層死結

如果准入 Webhook 負責驗證 Webhook 自身復原所需的資源，就可能發生循環依附關係死結。舉例來說，如果設定了准入 Webhook 來驗證 Pod，且該 Webhook Pod 需要在節點軟體升級期間重新排程，Kubernetes API 伺服器可能會嘗試聯絡該 Webhook，授權建立新的 Pod。如果無法連上 Webhook，要求就會失敗，Pod 不會建立，叢集也會進入死結狀態，無法排定任何新的工作負載。

如果使用 failurePolicy: Fail 設定 Webhook，API 伺服器與 Webhook 之間的任何通訊錯誤或逾時，都會導致 API 要求遭到拒絕。這會造成下列問題：

軟體升級失敗：節點軟體升級期間和升級後，系統元件和 VM 都無法排定時間。
系統服務無法啟動：基礎架構 Pod 無法啟動，例如 GDC 上的 Symcloud Storage 和 VM Runtime。
節點停滯在維護模式：由於控制器遭到准入邏輯封鎖，處於維護模式的節點無法進行協調或退出。

Webhook 設定最佳做法

請按照本節所述最佳做法操作，避免發生先前所述的控制平面死結。這些最佳做法適用於所有 ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 物件。

使用`failurePolicy: Ignore`

除非貴商家的需求規定 API 要求必須在無法驗證時失敗，否則請一律將 failurePolicy 欄位設為 Ignore。即使受影響的 Webhook 服務停止運作，Kubernetes API 伺服器仍可繼續運作，確保系統關鍵 Pod 能夠排程及復原。

排除保留的命名空間

Webhook 絕不能攔截保留命名空間中的資源要求。您必須使用 namespaceSelector 欄位，從 Webhook 設定中排除這些命名空間。如需保留命名空間的完整清單，請參閱「管理命名空間限制」。例如：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "customer-policy-webhook"
webhooks:
- name: "validate-labels.example.com"
  failurePolicy: Ignore
  sideEffects: None
  admissionReviewVersions: ["v1"]
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system
      - kube-node-lease
      - kube-public
      - capi-system
      - capi-kubeadm-bootstrap-system
      - gke-system
      - gke-connect
      - gke-operators
      - gke-managed-metrics-server
      - anthos-identity-service
      - anthos-creds
      - robinio
      - robin-admin
      - vm-system
      - cert-manager
      - cert-manager-cluster-resources
      - dns-system
      - g-istio-system
      - nf-operator
      - prom-monitoring
      - gpu-system
      - oclcm-system
      - saas-system
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["*"]
    apiVersions: ["*"]
    resources: ["pods", "deployments"]

從失敗的 Webhook 導致的叢集死結中復原

如果叢集因 Webhook 失敗而發生死結，且您建立資源的 kubectl 指令逾時或傳回錯誤，通常是因為 Webhook 的 failurePolicy 設為 Fail。請按照本節中的步驟，從死結中復原叢集。如果失敗的 Webhook 是變動型 Webhook，請使用 mutatingwebhookconfiguration，而非 validatingwebhookconfiguration。

找出失敗的 Webhook：
1. 列出部署在叢集上的驗證 Webhook：
```
kubectl get validatingwebhookconfigurations
```
2. 列出部署在叢集上的修改 Webhook：
```
kubectl get mutatingwebhookconfigurations
```
確認支援這些 Webhook 的 Pod 是否正在執行：
```
kubectl get pods -A | grep WEBHOOK_SERVICE
```
將 WEBHOOK_SERVICE 替換為目標 Webhook 服務的名稱。

將失敗的 Webhook 的 failurePolicy 設為 Ignore：

kubectl patch validatingwebhookconfiguration WEBHOOK_CONFIG \
  --type='json' \
  -p='[{"op": "replace", "path": "/webhooks/0/failurePolicy", "value":"Ignore"}]'

將 WEBHOOK_SERVICE 替換為目標 Webhook 服務的名稱。

(選用) 如果上一個步驟失敗，請強制刪除受影響的 Webhook 設定：
```
kubectl delete validatingwebhookconfiguration WEBHOOK_CONFIG --timeout=10s
```
將 WEBHOOK_CONFIG 替換為目標 Webhook 的設定名稱。

修改或強制刪除 Webhook 的設定後，Kubernetes API 伺服器會繼續處理要求，解決死結並讓遭封鎖的程序完成。

排解 Distributed Cloud connected 問題 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

Distributed Cloud connected 軟體升級

使用 Metrics Explorer 檢查叢集的目前和目標軟體版本

解讀結果

Distributed Cloud connected 電腦重新啟動

使用 Metrics Explorer 檢查機器運作時間和重新啟動次數

解讀結果

Distributed Cloud connected 機器的連線能力

使用 Metrics Explorer 檢查機器連線

解讀結果

虛擬機器停滯在 Pending 狀態

資源不足

遭汙染的節點

儲存空間故障

許可 Webhook 失敗導致排程鎖定

控制層死結

Webhook 設定最佳做法

使用failurePolicy: Ignore

排除保留的命名空間

從失敗的 Webhook 導致的叢集死結中復原

排解 Distributed Cloud connected 問題

虛擬機器停滯在 `Pending` 狀態

使用`failurePolicy: Ignore`