排解 Distributed Cloud connected 問題

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

Distributed Cloud 連結網路方案軟體升級

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

這項程序會使用下列 Monitoring 指標：

  • 「Current Cluster Version」(目前叢集版本) (/edge_cluster/current_cluster_version)：指出叢集上執行的 Distributed Cloud 連結軟體目前版本。

  • 「Target Cluster Version」(目標叢集版本) (/edge_cluster/target_cluster_version)：指出叢集要升級至的 Distributed Cloud connected 目標版本。

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

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

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

  1. 前往 Metrics Explorer：

    1. 前往 Google Cloud 控制台的「Monitoring」部分。

    2. 在左側導覽樹狀結構中，按一下「Metrics Explorer」。

  2. 選取目標資源類型：

    1. 在 Metrics Explorer 頁面中，前往「Configuration」(設定) 頁面。

    2. 按一下「Select a metric」(選取指標)。

    3. 使用搜尋列搜尋「Cluster」(叢集) 資源類型。您也可以使用完整資源 ID edgecontainer.googleapis.com/Cluster。

    4. 在傳回的結果中，按一下「Cluster」資源類型。

  3. 取得叢集目前的軟體版本：

    1. 在「Metric」(指標) 部分，搜尋 current_cluster_version 值。

    2. 選取「Machine Uptime」指標。完整路徑為 edgecontainer.googleapis.com/edge_cluster/current_cluster_version。

    3. (選用) 使用「篩選器」部分，依目標machine_id值篩選。

  4. 取得叢集的目標軟體版本：

    1. 按一下「新增查詢」。

    2. 在「Metric」(指標) 部分，搜尋 target_cluster_version 值。

    3. 選取「Target Cluster Version」(目標叢集版本) 指標。完整路徑為 edgecontainer.googleapis.com/edge_cluster/target_cluster_version。

    4. (選用) 使用「篩選器」部分，依目標machine_id值篩選。

  5. 在顯示的圖表中，查看叢集的軟體升級狀態。

    • 如果「Current Cluster Version」(目前叢集版本) 和「Target Cluster Version」(目標叢集版本) 行分別顯示不同的值，表示叢集正在進行軟體升級。

    • 如果「Current Cluster Version」(目前叢集版本) 和「Target Cluster Version」(目標叢集版本) 行顯示相同的值，表示叢集並未進行軟體升級。

  6. 使用下列指令，驗證上一個步驟的結果：

    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 連線實體機是否已重新啟動，並判斷重新啟動的原因。監控重新啟動作業，有助於判斷是預定維護作業，還是硬體故障或電力中斷所致。

這項程序會使用下列 Monitoring 指標：

  • 機器運作時間 (/machine/uptime)：表示自上次重新啟動後經過的時間 (以秒為單位)。

  • 裝置重新啟動 (/machine/restart_count)：表示目標裝置自部署以來重新啟動的總次數。

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

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

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

  1. 前往 Metrics Explorer：

    1. 前往 Google Cloud 控制台的「Monitoring」部分。

    2. 在左側導覽樹狀結構中，按一下「Metrics Explorer」。

  2. 選取目標資源類型：

    1. 在 Metrics Explorer 頁面中，前往「Configuration」(設定) 頁面。

    2. 按一下「Select a metric」(選取指標)。

    3. 使用搜尋列搜尋「Machine」資源類型。您也可以使用完整資源 ID edgecontainer.googleapis.com/Machine。

    4. 在傳回的結果中，按一下「Machine」(機器) 資源類型。

  3. 查看機器的運作時間：

    1. 在「Metric」(指標) 部分，搜尋 uptime 值。

    2. 選取「Machine Uptime」指標。完整路徑為 edgecontainer.googleapis.com/machine/uptime。

    3. (選用) 使用「篩選器」部分，依目標machine_id值篩選。

    4. 在顯示的時間圖表中，確認運作時間圖表持續上升。如果正常運作時間值在任何時間點降至零並重新啟動，表示機器已重新啟動。

  4. 查看機器的重新啟動次數：

    1. 在「Metric」(指標) 部分，搜尋 restart_count 值。

    2. 選取「Machine Restarts」指標。完整路徑為 edgecontainer.googleapis.com/machine/restart_count。

    3. (選用) 使用「篩選器」部分，依目標machine_id值篩選。

    4. 在顯示的時間圖表中，確認圖表線條維持在 0，表示未發生重新啟動。如果線條在任何時間點飆升至 1，表示機器已重新啟動。請記下重新啟動的確切時間戳記，以便進一步疑難排解。

    5. (選用) 如要查看個別事件而非圖表，請前往頁面的「Aggregation」(匯總) 區段，將「Alignment period」(校正週期) 欄位設為 1 minute，並將「Per-series aligner」(每個序列的校正器) 欄位設為「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 連線能力。

這項程序會使用下列 Monitoring 指標：

  • Machine Connected (/machine/connected)：指出機器是否已連線至 Google Cloud。

  • 網路連線 (/machine/network/connectivity)：指出機器的主要網路介面是否具備網際網路連線。

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

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

使用 Metrics Explorer 檢查機器連線能力

  1. 前往 Metrics Explorer：

    1. 前往 Google Cloud 控制台的「Monitoring」部分。

    2. 在左側導覽樹狀結構中，按一下「Metrics Explorer」。

  2. 選取目標資源類型：

    1. 在「Metrics Explorer」頁面中，前往「查詢」頁面。

    2. 使用搜尋列搜尋「Machine」資源類型。您也可以使用完整資源 ID edgecontainer.googleapis.com/Machine。

    3. 在傳回的結果中，按一下「Machine」(機器) 資源類型。

  3. 檢查機器與 Google Cloud的連線：

    1. 在「Metric」(指標) 部分，搜尋 connected 值。

    2. 選取「Machine Connected」指標。完整路徑為 edgecontainer.googleapis.com/machine/connected。

    3. (選用) 使用「篩選器」部分，依目標machine_id值篩選。

    4. 在顯示的時間圖表中，確認「健康狀態良好」線持續維持在 100%。如果這個值在任何時間點為 0% 或「Unhealthy」(健康狀態不佳)，表示機器在指定時間與 Google Cloud 失去連線能力。

  4. 檢查機器的網際網路連線：

    1. 在「Metric」(指標) 部分，搜尋 connectivity 值。

    2. 選取「網路連線」指標。完整路徑為 edgecontainer.googleapis.com/machine/network/connectivity。

    3. (選用) 使用「篩選器」部分，依目標 machine_id 值篩選。

    4. 在顯示的時間圖表中，確認「健康狀態良好」線條持續維持在 100%。如果這個值在任何時間點為 0%「Unhealthy」，表示機器在指定時間失去網際網路連線。

解讀結果

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

機器狀態 診斷 解析度
健康
「機器已連線」指標值為 1
「網路連線」指標值為 1
 正常運作。 無
已中斷連線
「機器已連線」指標值為 0
「網路連線」指標值為 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 作業時間、記憶體或磁碟空間) 分配給虛擬機器。
  • 虛擬機器設定有誤。
  • 虛擬機器的儲存空間發生錯誤。
  • 目標節點已遭污染。

請按照下列步驟解決這個問題：

  1. 按照「取得叢集憑證」一文的說明取得叢集憑證。

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

    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

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

  3. 檢查輸出內容，判斷排程失敗的原因，詳情請參閱後續章節。

資源不足

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

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

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

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

有污點的節點

您可能會看到訊息，指出目標節點已遭 taint。例如：

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

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

  1. 使用下列指令，檢查節點上的污點：

    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>

  2. 執行下列其中一個步驟：

    • 如要移除非預期的污點，請按照「污點和容忍度」一文中的說明操作。
    • 如要處理預期的污點，請按照「污點和容忍度」一文所述，在虛擬機器設定中新增對應的容忍度。

儲存空間故障

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

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

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

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

  1. 使用下列指令，取得受影響虛擬機器命名空間中的永久磁碟區要求 (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

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

許可 Webhook 失敗導致排程鎖定

透過許可 Webhook，您可以在物件永久保存之前，攔截傳送至 Kubernetes API 伺服器的要求。雖然 Webhook 有助於強制執行自訂安全性政策，但如果設定錯誤，可能會導致整個叢集服務中斷，尤其是在軟體升級和憑證重新整理等重要作業期間。具體來說，如果准入 Webhook 遭到封鎖或無法使用，Kubernetes 控制層可能會停滯，導致叢集無法進一步排定工作負載。

控制層死結

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

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

  • 軟體升級失敗：在節點軟體升級期間和之後，無法排定系統元件和 VM。
  • 系統服務無法啟動：Symcloud Storage 和 GDC VM 執行階段等基礎架構 Pod 無法啟動。
  • 節點卡在維護模式：控制器遭到許可邏輯封鎖，因此無法協調或退出處於維護模式的節點。

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。

  1. 找出失敗的 Webhook：

    1. 列出部署在叢集上的驗證用 Webhook：

      kubectl get validatingwebhookconfigurations

    2. 列出部署在叢集上的變更 Webhook：

      kubectl get mutatingwebhookconfigurations

  2. 確認支援這些 Webhook 的 Pod 是否正在運作：

    kubectl get pods -A | grep WEBHOOK_SERVICE

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

  3. 將失敗 Webhook 的 failurePolicy 設為 Ignore：

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

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

  4. (選用) 如果上一個步驟失敗，請強制刪除受影響的 Webhook 設定：

    kubectl delete validatingwebhookconfiguration WEBHOOK_CONFIG --timeout=10s

    將 WEBHOOK_CONFIG 替換為目標 Webhook 的設定名稱。

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