Google Distributed Cloud 實體隔離方案 1.13.x 已知問題

Artifact Registry

子元件 sar-failoverregistry 對帳錯誤

版本：1.13.1、1.13.3、1.13.4

症狀：使用 gdcloud system admin-cluster install 指令建立根管理員叢集時，如果啟動程序中的伺服器清單很長，作業可能會失敗。錯誤輸出訊息如下：

Secret "sar-failoveregistry-backend-parameter" is invalid: data: Too long: must have at most 1048576 bytes

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

  1. 在與子元件相同的 Kubernetes 叢集中，列出伺服器並確認每個伺服器自訂資源都有標籤，且金鑰為 cluster.private.gdc.goog/inventory-machine：

    kubectl get servers -n gpc-system

  2. 找出類似下列內容的元件自訂資源：

      apiVersion: lcm.private.gdc.goog/v1
  kind: Component
  metadata:
    creationTimestamp: "2025-01-06T12:00:41Z"
    generation: 1
    name: sar-v1.14.2-sar-acbf97caf6
    resourceVersion: "3199"
    uid: 681ec5cb-9eb3-423b-ac1d-f6aa27abfd75
  spec:
    name: sar

  3. 在系統構件登錄 (SAR) 元件自訂資源中，於 sar-failover-registry 的 runtimeParameterSources 伺服器中新增標籤選取器：

    1. 查看現有 server 資源：

      servers:
  targetCluster: Local
  object:
    apiVersion: system.private.gdc.goog/v1alpha1
    kind: ServerList
    namespace: gpc-system

    2. 更新元件自訂資源中的伺服器欄位：

      servers:
  targetCluster: Local
  object:
    apiVersion: system.private.gdc.goog/v1alpha1
    kind: ServerList
    namespace: gpc-system
    labelSelector:
      - key: cluster.private.gdc.goog/inventory-machine
        operator: "in"
        strValues:
          - "bm-1"
          - "bm-2"
          - "bm-3"

  4. 確認上一個步驟中 SAR 元件的變更已傳播至子元件 sar-failverregistry：

    1. 取得 SAR 元件的詳細資料：

      kubectl get component | grep sar

    2. 取得 sar-failoverregistry 元件的詳細資料：

      kubectl get subcomponent sar-failoverregistry -n root

      使用 -n 標記指定命名空間。

備份與還原

磁碟區空間不足，因此快照建立失敗

版本：1.13.x 的所有版本

症狀：永久磁碟區備份發生間歇性問題，可能會影響定期備份工作的流程。如果某些磁碟區的變更率很高，為進行備份作業而建立的磁碟區快照可能會導致磁碟區空間不足，進而進入唯讀模式。

解決方法：為避免影響實際工作環境中的工作負載，請按照 BACK-R0104 執行手冊中的步驟操作。您也可以視需要按照 BACK-R0106 執行手冊，移除累積的快照。

記憶體不足，導致代理程式和控制層 Pod 重新啟動

版本：1.13.x 的所有版本

症狀：如果代理程式和控制層 Pod 記憶體不足，可能會重新啟動。

解決方法：按照 BACK-R0005 執行手冊中的說明，增加控制層和代理程式 Pod 的記憶體。將 Pod 的記憶體增加至 2 GiB。

PVC 快照備份失敗

版本：1.13.x 的所有版本

症狀：備份失敗，因為每個 (PVC) 資源的 ONTAP 快照限制為 1023 個，但已超出此限制。PersistentVolumeClaim

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

  1. 請更新備份方案，確保不會達到上限。設定備份方案，每小時備份一次，或將 deleteLockDays 減少至三，確保快照數量不超過 1023 個：

    apiVersion: backup.gdc.goog/v1
kind: BackupPlan
metadata:
  name: test-backup-plan
spec:
  clusterName: system-cluster
  backupSchedule:
    cronSchedule: "*/10 * * * *"
    paused: false
  backupConfig:
    backupScope:
      selectedApplications:
        namespacedNames:
        - name: test-protected-application
          namespace: release-namespace
    backupRepository: gdchservices-backup-repository
    includeVolumeData: true
    volumeStrategy: LocalSnapshotOnly
  retentionPolicy:
    backupDeleteLockDays: LOCK_DAYS
    backupRetainDays: RETENTION_DAYS

    更改下列內容：

    • LOCK_DAYS：備份作業完成後，系統會在指定天數內禁止刪除備份。請使用下列值：

      • 如果 volumeStrategy 欄位設為 LocalSnapshotOnly 值，請使用 2 值。
      • 如果 volumeStrategy 欄位設為 ProvisionerSpecific 值，請使用 7 值。

    • RETENTION_DAYS：在備份建立後，於指定天數內刪除備份。如果 volumeStrategy 欄位設為 LocalSnapshotOnly 值，請使用小於 3 的值。

  2. 如要使用磁碟區快照刪除指令，手動刪除環境中過多的快照，請按照下列步驟操作：

    1. 初始化變數：

      export RKCNF=/root/release/root-admin/root-admin-kubeconfig
export KCNF=/root/release/org-admin/gdchservices-admin-kubeconfig

export ORG_NAME=ORG_NAME
export PVC=PVC_NAME

      更改下列內容：

      • ORG_NAME：貴機構的名稱。
      • PVC_NAME：與備份方案相關的PVC資源名稱。

    2. NetApp ONTAP 是用來管理 GDC 儲存空間的作業系統。取得 ONTAP 存取權：

      export USERNAME="$(kubectl --kubeconfig ${RKCNF?} -n gpc-system get
secret storage-root-level1 -o jsonpath='{.data.username}' | base64 -d)"

export MGMT_IP="$(kubectl --kubeconfig ${RKCNF?} get storagecluster -A
-o jsonpath='{.items[0].spec.network.clusterManagement.ip}')"

export PASSWORD="$(kubectl --kubeconfig ${RKCNF?} -n gpc-system get
secret storage-root-level1 -o jsonpath='{.data.password}' | base64 -d)"

echo $PASSWORD

    3. 列出所選 PVC 資源的所有快照：

      ssh ${USERNAME?}@${MGMT_IP?} "volume snapshot show -vserver ${ORG_NAME?}
-fields volume,snapshot,size,create-time" | grep "snapshot-" >
/tmp/snapshot_unsort.list

      使用上一個步驟中的密碼，登入 MGMT_IP 變數定義的 IP 位址。

    4. 找出快照數量最多的 PVC：

      grep ${ORG_NAME?} /tmp/snapshot_unsort.list | grep snapshot | awk
'{print $2}' | sort | uniq -c

    5. 將 PVC 資源名稱設為快照數量較高的名稱：

      export PV_NAME=

    6. 刪除包含大量快照的 PVC 資源快照。PVC 資源的快照數量上限為 1023 個：

      for snap_name in `grep ${ORG_NAME?} /tmp/snapshot_unsort.list | grep
snapshot | grep ${PV_NAME?} | awk '{print $3}'` do
    echo "volume snapshot delete -vserver ${ORG_NAME} -volume ${PV_NAME} -snapshot $snap_name"
    echo "Y"
done

    7. 登入 ONTAP 並執行下列指令，刪除快照：

      echo $PASSWORD

#Use this password to login to ontap
ssh ${username?}@${mgmt_ip?}

    8. 執行上一個步驟列出的指令，刪除快照。完成後，請結束 SSH 工作階段

  3. 重複執行刪除步驟，直到所有違規的 PVC 快照都清除完畢為止。

從與 SVM 配額不相容的備份還原

版本：1.13.1

症狀：問題是 NetApp 功能不相容。這項不相容問題會導致系統無法提供租戶配額，也無法順利執行還原作業。只有在將備份檔還原至配額受限的使用者叢集時，才會發生這個問題。

解決方法：如果發生這個問題，還原作業會失敗並顯示 DP volumes are not supported on storage-limit enabled Vserver 錯誤訊息，基礎架構營運商 (IO) 必須停用該使用者叢集的配額，然後重新啟動還原程序。還原完成後，IO 必須重新啟用租戶配額，系統應會繼續正常運作。詳情請參閱 runbook FILE A0030。

帳單

帳單資訊主頁未正確顯示帳單指標

版本：1.13.1

症狀：由於缺少 MetricsProxySidecar，因此系統無法正確將帳單指標傳送至 Cortex。

解決方法：建立 billing-monetizer MetricsProxySidecar 資源。然後執行指令碼來更新 metricExpression。

  1. 匯出下列 kubeconfig 變數：

    export KUBECONFIG=KUBECONFIG_PATH

    將 KUBECONFIG_PATH 變數替換為機構管理員叢集的 kubeconfig 檔案路徑。請按照「Service-manual IAM-R0101」中的步驟，產生這個因應措施所需的 kubeconfig 檔案。

  2. 為 billing-monetizer MetricsProxySidecar和 billing-system partner-billing-system 命名空間建立資源：

    針對 billing-system：

    cat <<EOF | kubectl --kubeconfig=$KUBECONFIG apply -n billing-system -f -
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: billing-monetizer
  namespace: billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8080
    scrapeInterval: 60s
  destinations:
  - certificate:
      secretName: billing-monetizer-monitoring-target-infra-obs-cert
    port: 9090
  - certificate:
      secretName: billing-monetizer-monitoring-target-platform-obs-cert
    port: 9091
---
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: usagemetering
  namespace: billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8099
    scrapeInterval: 60s
  destinations:
  - port: 9090
    certificate:
      secretName: bil-usagemetering-monitoring-target-cert
EOF

    針對 partner-billing-system：

    cat <<EOF | kubectl --kubeconfig=$KUBECONFIG apply -n partner-billing-system -f -
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: billing-monetizer
  namespace: partner-billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8080
    scrapeInterval: 60s
  destinations:
  - certificate:
      secretName: billing-monetizer-monitoring-target-infra-obs-cert
    port: 9090
EOF

  3. 執行下列指令碼來更新 metricExpression。這會從「skuconfig」中移除「container_name="monetizer"」，包括「billing_total_cost{container_name="monetizer"」：

    cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bc73-b150-e0ea --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"BC4D-B784-EA3C|BC73-B150-E0EA|BD0C-C8CF-658B|BD1A-9464-9DF9|BD5A-044C-4860|BDB4-6C62-00BE|BDB4-BBA6-3EEE|3034-EE51-7404|3160-1596-5D9B|54AD-8EBC-8BB1\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bd1a-9464-9df9 --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"BC4D-B784-EA3C|BC73-B150-E0EA|BD0C-C8CF-658B|BD1A-9464-9DF9|BD5A-044C-4860|BDB4-6C62-00BE|BDB4-BBA6-3EEE|3034-EE51-7404|3160-1596-5D9B|54AD-8EBC-8BB1\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig b93c-effb-6d6b --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig b871-c5e5-bac1 --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig ba38-e4be-ba5d --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bbe8-7b7a-03de --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF

由於驗證 Webhook 發生錯誤，使用者無法建立 BillingAccountBinding

版本：1.13.0、1.13.1、1.13.3

症狀：錯誤位於 BillingAccountBinding 驗證 Webhook 邏輯中。如果使用者嘗試建立 BillingAccountBinding 資源，Webhook 會傳回 permission denied 錯誤。

解決方法：如要建立 BillingAccountBinding 資源，請通知基礎架構營運人員，並透過 IAC 建立對應的資源。

區塊儲存空間

由於磁碟區掛接錯誤，Grafana Pod 停滯在 Init 狀態。

版本：1.13.3

症狀：

由於磁碟區掛接錯誤，anthos-identity-service-obs-system 和 platform-obs-obs-system 命名空間中的 Grafana Pod 停滯在 Init 狀態。kubelet 記錄中的錯誤訊息指出多重連結問題。這個問題源自 Trident 的錯誤，因為該錯誤無法正確識別及驗證 LUKS 對應的基礎裝置，導致發生多重附加錯誤。

解決辦法：

檢查 PVC 的 deletionTimestamp。如果沒有 deletionTimestamp (Pod 遷移)，請按照下列步驟操作：

  1. 檢查 VolumeAttachment，找出目前附加磁碟區的 PVC。
  2. 在叢集中，封鎖與這個值不符的 Nodes。
  3. 刪除失敗的 Pod，這應該會導致該 Pod 遷移回原始 Node。

檢查後，如果出現 deletionTimestamp (磁碟區刪除)，請按照下列步驟操作：

  1. 檢查 VolumeAttachment，找出目前附加磁碟區的 PVC。

  2. 在 Node 上，輸出追蹤檔案的內容：

    cat /var/lib/trident/tracking/PVC_NAME.json

  3. 確認追蹤檔案輸出內容的 devicePath 欄位中找到的 LUKS 裝置確實已關閉。此時不應存在這個路徑：

    stat DEVICE_PATH

  4. 確認序號目前是否對應任何多路徑裝置。

    1. 複製追蹤檔案 iscsiLunSerial 欄位中的值。

    2. 將這個值轉換為預期的十六進位值：

      echo 'iISCSILUNSERIAL' | xxd -l 12 -ps

    3. 使用這個新值，找出多路徑項目是否仍然存在：

      multipath -ll | grep SERIAL_HEX

    4. 如果不存在，請刪除追蹤檔案。

    5. 如果存在，您會看到比搜尋值稍長的序號十六進位值，稱為 multipathSerial。執行下列指令，找出區塊裝置：

      multipath -ll MULTIPATH_SERIAL

    6. 接著，請執行下列指令，最後一個指令則須為每個區塊裝置分別執行：

      systemctl restart iscsid
systemctl restart multipathd
multipath -f MULTIPATH_SERIAL
echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete

虛擬機器啟動器 Pod 無法對應磁碟區

版本：1.13.1

症狀：

您可能會看到類似下方的警告訊息：

 Warning  FailedMapVolume  2m50s (x206 over 13h)  kubelet  MapVolume.SetUpDevice failed for volume "pvc-2a68356a-47da-422b-8781-15e3a6fe7ec9" : rpc error: code = DeadlineExceeded desc = context deadline exceeded

如要診斷問題，請按照下列步驟操作：

  1. 確認磁碟區和 Pod 位於相同節點。
  2. 找出 Pod 所在的節點，並檢查其健康狀態。
  3. 檢查節點連線。
  4. 檢查 IPSEC。
  5. 檢查多重路徑，確認是否有殭屍。

  6. 檢查 trident 記錄，找出 CSI 流程中可能導致這個無效物件的步驟：

    kubectl --kubeconfig /root/release/system/org-1-system-cluster logs -n netapp-trident -c trident-main

解決方法：如要解決這個問題，請按照下列 Runbook 中的步驟操作：

  1. 如要瞭解節點相關問題，請參閱 FILE-R0010 runbook。
  2. 如要解決 IPSEC 相關問題，請參閱 FILE-R0007 runbook。
  3. 如要解決無效 LUN 問題，請參閱 FILE-R0020 runbook。
  4. 如要解決超級殭屍 LUN 問題，請參閱 FILE-R0021 runbook。

儲存空間相關故障

版本：1.13.1

症狀：如果 file_block_zombie_luns_present 警報觸發，或由於 MountVolume 呼叫發生問題，導致 Pod 無法啟動，且問題持續超過一個協調迴圈，就表示發生儲存空間相關故障。逾時時間可能約為兩分鐘。 如果重複發生相同失敗情形，表示 NodeStage 或 NodePublish CSI 路徑發生錯誤，需要解決方法。唯一例外狀況是逾時失敗的指標。您可能會看到類似這樣的失敗訊息：

NMountVolume.SetUp failed for volume "pvc-a63313b2-3e30-4c92-b074-f9fffe0500a4" : rpc error: code = Internal desc = unable to mount device; exit status 32

MapVolume.SetUpDevice failed for volume "pvc-f594b0c7-a5b5-4a5b-8a53-bf13e95c4bb0" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: multipath device not found when it is expected

MapVolume.SetUpDevice failed for volume "pvc-f594b0c7-a5b5-4a5b-8a53-bf13e95c4bb0" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: failure when reconfiguring multipath

解決辦法：

  1. 如要查看 Node 是否有 Pod，可以修正失敗的 PVC，請封鎖排定 Pod 的目前節點，並刪除 Pod：

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl cordon node TARGET_NODE

    Pod 應排定至完全不同的 Node，這會導致 Trident 強制完整執行 NodeStage、NodePublish、NodeUnpublish 和 NodeUnstage。因為原始 Node 上可能仍有這個磁碟區的工作階段處於開啟狀態，因此這可能無法立即修正磁碟區問題。

  2. 完成上一個步驟後，請取消封鎖有問題的節點：

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl uncordon node TARGET_NODE

  3. 如果仍有失敗情形，請排除所有其他 Nodes，但最初排定 Pod 的 Nodes 除外，然後刪除 Pod。這應該會導致 Pod 從原始 Node 開始，現有裝置可能仍會停留在該處。

  4. 完成上一個步驟後，請取消受影響節點的封鎖。

  5. 最後，如要儲存 PV 及其資料，可以重新啟動 Node，清除 Node 上的多重路徑、udev 和 devmapper 故障。這個步驟相當費力，但最有可能成功。

  6. 如果上述緩解措施無法解決磁碟區問題，表示資料已損毀，無法有效使用。如要繼續使用預期的容器行為，唯一的方法是刪除失敗的 PV、PVC 和 Pod，然後重新啟動 PV 所在的節點。這項操作會導致已寫入磁碟區的所有資料完全遺失。

以錯誤大小建立的永久磁碟區

版本：1.13.1

症狀：建立具有永久磁碟區的工作負載時，大小會比預期小約 16 MiB。如果工作負載完全取決於持續性磁碟區宣傳的大小，則在擴充或佈建時，微小的差異會導致工作負載失敗。如果永久磁碟區是使用 standard-block 儲存空間類別佈建，而非 standard-rwo 儲存空間類別，就更有可能發生這個問題。如果永久磁碟區的儲存空間級別為 standard-rwo，且使用 volumemode:block 模式，就可能發生這個問題。

解決方法：配置的持續性磁碟區大小至少要比實際需求大 16 MiB。

無法刪除儲存空間虛擬機器

版本：1.13.1

症狀：StorageVirtualMachine 可能會顯示類似以下的錯誤訊息：

 Warning  SVMDeletion  27m (x32 over 4h9m)   StorageVirtualMachine  Reconcile error for svm deletion: failed to delete svm: failed to delete svm volumes: failed to call VolumeCollectionGet: error message: "SVM \"org-2-user\" does not exist. "; error target: "svm.name"

解決方法：從機構命名空間的 StorageVirtualMachines 中刪除終結程式。

停用機構不會清除資源

版本：1.13.1

症狀：停用機構時，會留下一些 StorageVirtualMachines 資源，例如：

  • gpc-system secret/org-2-admin-backup-agent-cert-secret
  • gpc-system secret/org-2-admin-client-cert-secret
  • gpc-system secret/org-2-admin-server-cert-secret
  • gpc-system secret/org-2-admin-svm-credential
  • gpc-system secret/org-2-admin-backup-agent-cert-secret
  • gpc-system secret/org-2-admin-client-cert-secret
  • gpc-system secret/org-2-admin-server-cert-secret
  • gpc-system secret/org-2-admin-svm-credential

解決方法：刪除這些資源。

刪除對帳失敗

版本：1.13.1

症狀：如果先刪除 StorageVirtualMachine，再清除依附於該 StorageVirtualMachine 的叢集，可能會發生無法清除部分叢集持續性磁碟區 (PV) 的問題。具體來說，如果未清除 LUKS 加密 PV，其密碼會阻止刪除所屬的命名空間。您可能會在記錄中看到類似以下的警告：

Warning  ReconcileBackoff  5m35s (x6 over 88m)  ClusterLifecycleReconciler  cluster namespace deletion is not completed: deletion is still ongoing for namespace: /g-org-2-shared-service-cluster

解決方法：從服務叢集命名空間中的 g-luks-gdc-vm-disk-* 密鑰刪除終結器。

不含作業系統的升級作業停滯

版本：1.13.1、1.13.5、1.13.6

症狀：有 Zombie LUN 時，Ansible 工作會停滯在收集事實的階段。執行 multipath -ll 指令時，可能會出現下列問題：

3600a098038314955593f574669785635 dm-11 NETAPP,LUN C-Mode
size=1.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 5:0:0:10 sdaf 65:240 failed faulty running
| `- 6:0:0:10 sdau 66:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
  |- 7:0:0:10 sdad 65:208 failed faulty running
  `- 8:0:0:10 sdar 66:176 failed faulty running

您也可能會看到下列錯誤訊息：

 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [Check inventory] *********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [set_fact] ****************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.018)       0:00:00.018 ********
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv ok: [10.252.151.3]
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [Verify inventory]********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [assert]******************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.031)       0:00:00.050 ********
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv ok: [localhost]
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [all] *********************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [Gathering Facts] *********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.064)       0:00:00.114 ********

解決方法：檢查與目標節點的 SSH 連線，然後使用下列 Runbook：FILE-R0020。

Trident 多重附加錯誤

版本：1.13.3

症狀：Pod 和 PVC 可能會滯留在不同節點上，而 Pod 會卡在初始化程序中，等待 PVC。

解決方法：

  1. 檢查 PVC 的 deletionTimestamp：

    kubectl --kubeconfig KUBECONFIGget pvc -n <namespace> | grep deletionTimestamp

  2. 如果沒有 deletionTimestamp (Pod 遷移)：

    1. 檢查 PVC 的 VolumeAttachment，找出磁碟區的附加位置。
    2. 將叢集中不符合這個值的節點設為保留。
    3. 刪除失敗的 Pod。這項操作會將 POD 遷移回原始節點。

  3. 如果出現 deletionTimestamp (刪除磁碟區)：

    1. 檢查 PVC 的 VolumeAttachment，找出磁碟區的附加位置。
    2. 在節點上，輸出追蹤檔案 /var/lib/trident/tracking/PVC_NAME.json 的內容。
    3. 驗證追蹤檔案輸出內容的 devicePath 欄位中找到的 LUKS 裝置是否確實已關閉。此路徑不應存在於這個時間點：stat DEVICE_PATH。如果路徑仍然存在，則發生其他問題。
    4. 確認序號是否對應任何多路徑裝置。
    5. 複製追蹤檔案 iscsiLunSerial 欄位中的值。
    6. 將這個值轉換為預期的十六進位值：echo ISCSI_LUN_SERIAL | xxd -l 12 -ps
    7. 使用這個新值，找出多重路徑項目是否仍然存在：multipath -ll | grep SERIAL_HEX。
    8. 如果不存在，請刪除追蹤檔案。

    9. 如果存在，您會看到比搜尋值稍長的序號十六進位值。請將這個值記錄為 MULTIPATH_SERIAL。執行 multipath -ll MULTIPATH_SERIAL，畫面會顯示類似以下的訊息：

      3600a09803831486f2d24575445314678 dm-32 NETAPP,LUN C-Mode
size=8.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 1:0:0:12 sde  8:64   active ready running
| `- 2:0:0:12 sdt  65:48  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 3:0:0:12 sdbc 67:96  active ready running
  `- 4:0:0:12 sdbe 67:128 active ready running

    10. 執行下列指令：

      1. systemctl restart iscsid
      2. systemctl restart multipathd
      3. multipath -f MULTIPATH_SERIAL
      4. echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete

    11. 針對每個區塊裝置，分別執行最後一個指令。

IPsec 設定錯誤

版本：1.13.4

症狀：ONTAP IPsec 設定發生錯誤，原因是無效的預先共用金鑰 (PSK) 含有 0X，這會解譯為十六進位字串。

您可能會看到類似下方的警告訊息：

Warning  ONTAPIPSecConfiguration  3m47s (x22 over 75m)  StorageEncryptionConnection  Reconcile error on ONTAP IPSec configuration: failed to call IpsecPolicyCreateDefault: error message: "The specified pre-shared key \"0XxBDkG8iHoAlOc
nCUfHl0AKYzClgGCH\" is not valid because it is not a valid hexadecimal string."; error target: ""

解決方法：

  1. 取得儲存空間加密連線：

    kubectl get  Storageencryptionconnections --kubeconfig ROOT_ADMIN_KUBECONFIG

    找出含有 Ready=False 的項目，並記下 PRESHAREKEY 的名稱。輸出內容可能如下所示：

    NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR        PRESHAREDKEY                 READY   AGE
vm-5a77b2a2   vm-5a77b2a2        gpu-org-user            192.0.2.0/27   vm-5a77b2a2-pre-shared-key   False   26h

  2. 這部機器正在執行 GPU 機構，因此請刪除 gpu-org-admin 中的 secrets gpc-system/vm-5a77b2a2-pre-shared-key。

  3. 等待系統重新建立 secret/vm-5a77b2a2-pre-shared-key。

  4. 找出類似 gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2 的工作。 請注意，最後 8 個字元是隨機產生。金鑰再次可用後，請刪除工作，例如 jobs gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2m8xdl 中的 gpu-org-admin。

未建立儲存空間虛擬機器

版本：1.13.5

症狀：由於佈建磁碟區時發生問題，gpu-org 上的 Harbor 服務無法啟動。這個問題是由於 file-storage-backend-controller Pod 參照不存在的庫存機器所致。

您可能會看到類似下方的儲存空間控制器錯誤，指出系統找不到 InventoryMachine：

{"ts":1730135301218.1772,"caller":"controller/controller.go:329","msg":"Reconciler error","controller":"StorageEncryptionConnectionGenerator","controllerGroup":"baremetal.cluster.gke.io","controllerKind":"InventoryMachine","InventoryMachine":{"n
ame":"vm-26c89d33","namespace":"@org-1/org-1-admin"},"namespace":"@org-1/org-1-admin","name":"vm-26c89d33","reconcileID":"48ab38a8-385d-4fdb-bd7e-1212f287379c","err":"InventoryMachine.baremetal.cluster.gke.io \"vm-26c89d33\" not found"}

解決方法：

  1. 刪除 file-storage-backend-controller Pod。
  2. 讓儲存空間控制器重新擷取現有的機器。

儲存空間叢集間網路無法調解

版本：1.13.5、1.13.6

症狀：升級後，由於規格中叢集間子網路的設定有誤，根管理員叢集中的 StorageCluster 自訂資源無法就緒。儲存空間叢集會回報 Not Ready，並包含發生下列錯誤的事件：

Reconciler error: failed to configure additional networks: failed to configure intercluster LIF: the \"\" Kind is not currently supported

如果發生這個錯誤，表示儲存空間叢集使用的叢集間子網路聲明，不包含參照中的 kind 欄位。檢查 StorageCluster 自訂資源時，您會發現跨叢集子網路聲明參照，其中只有名稱和命名空間，如下所示：

spec:
  additionalNetworks:
  - destinationSubnets:
    - 10.252.112.0/20
    name: backup-agent-storage-network
    port: a0a
    subnetConfig:
      subnetClaimRef:
        name: file-block-storage-intercluster-lif-subnet
        namespace: root
    types:
    - BackupAgent

解決方法：更新 StorageCluster 規格，在子網路聲明參照中加入 kind: SubnetClaim 欄位：

spec:
  additionalNetworks:
  - destinationSubnets:
    - 10.252.112.0/20
    name: backup-agent-storage-network
    port: a0a
    subnetConfig:
      subnetClaimRef:
        kind: SubnetClaim
        name: file-block-storage-intercluster-lif-subnet
        namespace: root
    types:
    - BackupAgent

更新 StorageCluster 規格後，請重新啟動 file-storage-backend-controller Deployment，並確認儲存空間叢集已準備就緒。

叢集管理

machine-init 工作在叢集佈建期間失敗

版本：1.13.1

症狀：

  1. 在叢集佈建期間，第二個控制層節點的 machine-init 工作會失敗，並顯示以下訊息：

    FAILED! => {"changed": true, "cmd": "/usr/bin/kubeadm join phase control-plane-prepare certs --config /dev/stdin --v 5".

  2. 查看記錄：

    kubectl --kubeconfig=ADMIN_KUBECONFIG logs -p kube-apiserver-{first_node_name} -n kube-system | grep "etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied"

    輸出內容會顯示非空白結果。

解決方法：

  1. 切換 /etc/kubernetes/pki/etcd/ca.crt 的權限。這項作業的時效性非常重要。權限切換必須在上次執行 machine-init 工作後，以及下次執行 machine-init 工作前進行，因為 machine-init 會將權限覆寫回根目錄。

  2. 在第二個節點中重新啟動 etcd，從當機迴圈中復原第一個節點中的 etcd。

完成這兩個步驟後，第一個節點中的 kube-apiserver 就會開始執行，下一個 machine-init 工作也會成功。

服務叢集無法連線至物件儲存空間值區

版本：1.13.1

症狀：在服務叢集中執行的資料庫 Pod 無法連線至機構管理員叢集中的物件儲存空間值區。

解決方法：按照 KUB-R0305 執行手冊中的指示操作。

預檢失敗

版本：1.13.1

症狀：您可能會在叢集物件狀態中看到下列訊息：

conditions:
    message: Preflight check <cluster> failed
    reason: PreflightCheckFailed
    status: "False"
    type: PreflightCheckSuccessful

您也應該會看到對應的 PreflightCheck 物件，其名稱和命名空間與叢集物件相同，且已存在多時，而 PreflightCheck 物件中顯示的錯誤或失敗問題已知不再存在。

解決方法：刪除 PreflightCheck 物件。

無法建立使用者叢集工作站節點集區

版本：1.13.5

症狀：使用者叢集工作站節點集區建立作業可能會停止回應，原因與下列其中一種機器類型有關：

  • n2-standard-16-gdc
  • n2-standard-32-gdc
  • n2-highmem-16-gdc
  • n2-highmem-32-gdc

解決方法：刪除該節點集區，然後從使用者叢集建立 UI 下拉式選單中選取其他可用的機器類型，重新建立節點集區。

如果清除作業不當，重新建立的使用者叢集可能會卡在調解狀態

版本：1.13.x

症狀：如果使用者叢集與先前刪除的叢集同名，可能會無限期停留在 Reconciling 狀態，且狀態會顯示外掛程式安裝階段 ONE。

解決方法：解除安裝 helm 外掛程式 CLUSTER_NAME-abm-overrides，然後重新啟動 managed-adm-controller 部署作業。如需詳細步驟，請參閱 MKS-R0004。

資料庫服務

本節包含資料庫服務的已知問題。

AlloyDB Omni 資料庫複製作業停滯

版本：1.13.x 的所有版本

症狀：使用者從特定時間點複製 AlloyDB Omni 叢集時，複製的資料庫叢集會卡在 DBSE0005 錯誤，無法準備就緒。對應的 restore.alloydb 資源停滯在「ProvisionInProgress」階段。

解決方法：如要解決這個問題，請從備份成功時的 COMPLETETIME 中，仔細選擇時間點。

在管理 API 伺服器上，列出可供複製的 AlloyDB Omni 備份。

kubectl get backups.alloydb -n source-dbcluster-namespace

輸出範例：

NAMESPACE   NAME                         PHASE       COMPLETETIME
db1         backupplan1-20240908215001   Succeeded   2024-09-08T21:37:38Z
db1         backupplan1-20240909215001   Succeeded   2024-09-09T21:16:18Z
db1         backupplan1-20240910215001   Succeeded   2024-09-10T21:09:38Z
db1         backupplan1-20240911215001   Succeeded   2024-09-11T21:50:47Z

選擇 COMPLETETIME 值做為複製的時間點。請注意，時間採用的是世界標準時間。

強制執行 IOPS 會影響儲存空間效能

版本：1.13.1

解決方法：如要解決這個問題，請採取下列任一做法：

  • 增加儲存空間大小。
  • 覆寫 IOPS 配額。

升級 dbs-fleet 子元件時發生對帳錯誤

版本：1.13.3

症狀：將根機構從 1.13.1 升級至 1.13.3 時，您可能會看到協調錯誤。檢查對帳錯誤：

kubectl get subcomponent -n ${CLUSTER} -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "ReconciliationError") |  "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'

錯誤訊息可能如下所示：

Sub-Component: dbs-fleet - Reconciliation error: E0121 - rollback chart: no ControlPlaneAgentsVersion with the name "alloydbomni-v0.12.46" found

解決方法：按照 OCLCM-R0122 執行手冊中的步驟操作。

DBCluster 建立失敗

版本：1.13.3

症狀：升級至 1.13.3 後，新的 DBcluster 無法完成協調，狀態中會顯示下列錯誤：

status:
  criticalIncidents:
  - code: DBSE0001
    createTime: ""
    message: Internal. General Controller Error.
    resource:
      component: controller-default
      location: {}
    stackTrace:
    - component: controller-default
      message: 'DBSE0001: Internal. General Controller Error. Failed to reconcile
        Postgres DBCluster [<name>] DBSE0001: Internal.
        General Controller Error. target release is empty in ModuleInstance <name>'

解決方法

確認機構管理員叢集中有以 cpa-v0.12.46 和 cpa-v0.12.51 結尾的 localrollout CR。例如：

kubectl get localrollouts -A

dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.46         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.46         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.51         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.51         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.51--cpa-v0.12.51   true

找出並刪除結尾為 cpa-v0.12.46 的 localrollout CR，確保其他 localrollout CR 不受影響。

kubectl get localrollouts -A | grep cpa-v0.12.46

這應該會傳回類似下方的清單：

dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.46         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.46         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.46--cpa-v0.12.46   true

刪除每個項目：

kubectl delete -n dbs-fleet-system localrollout/dp-alloydbomni-15-5.2--cpa-v0.12.46
...
...

確認結尾為 cpa-v0.12.51 的 localrollout CR 仍存在：

NAMESPACE          NAME                                        PAUSED   IN PROGRESS   FINISHED
dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.51         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.51         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.51--cpa-v0.12.51   true

DNS

您必須在 resolved.conf 中明確關閉 DNSSEC

版本：1.13.1、1.13.3、1.13.4

症狀：裸機或 VM 節點上的 DNS 解析失敗。如要確認 DNS 解析失敗，請建立與受影響節點的 SSH 連線，然後執行 systemctl status systemd-resolved。輸出內容包含類似 DNSSEC validation failed for question . IN SOA: no-signature 的行。

解決方法：

  1. 在受影響節點的 /etc/systemd/resolved.conf 中新增下列程式碼。

    DNSSEC=false

  2. 重新啟動 systemd-resolved 服務：

    systemctl restart systemd-resolved.service

港口服務

無法建立 Harbor 服務

版本：1.13.6

症狀：由於 ServiceIsolationEnvironment 名稱的長度限制，導致命名空間不符，因此無法建立 Harbor 執行個體。您可能會看到類似以下的訊息：

Failed to reconcile ODSDatabase: failed to create or update ODS ProjectNetworkPolicy: namespaces "g-dbs-PROJECT_NAME-HARBOR_INSTANCE_NAME" not found

解決方法：縮短 Harbor 執行個體名稱，即可解決目前的問題。請確認 PROJECT_NAME 和 HARBOR_INSTANCE_NAME 的總長度少於 27 個字元。

刪除 Harbor 執行個體不會一併刪除相關聯的登錄檔映像檔

版本：1.13.1、1.13.3、1.13.4、1.13.5、1.13.6、1.13.7、1.13.8

症狀：刪除 Harbor 執行個體不會刪除相關聯的登錄檔映像檔。節點集區可能卡在 Provisioning 狀態。這是因為刪除 Harbor 執行個體時，MHS 控制器建立的登錄檔鏡像並未刪除所致。

解決方法： 您必須手動移除登錄檔鏡像。如要解決這個問題，請按照下列步驟操作：

  1. 連線至機構管理員叢集。詳情請參閱 GDC 叢集架構。

  2. 執行這個指令碼，從具有 lcm.private.gdc.goog/cluster-type=user 標籤的所有 Kubernetes 叢集中，移除與 HARBOR_INSTANCE_URL 環境變數值相符的所有登錄檔鏡像：

    LABEL="lcm.private.gdc.goog/cluster-type=user"
ENDPOINT=HARBOR_INSTANCE_URL

while read -r out; do
    info=${out% *}
    ns_name=${info%:*}
    name=${ns_name##*/}
    ns=${ns_name%%/*}
    INDEX=$(kubectl get cluster user-vm-1 -n user-vm-1-cluster -ojson | jq '.spec.nodeConfig.registryMirrors | map(.endpoint=='\"$ENDPOINT\"') | index(true)')
    kubectl patch clusters "${name}" -n "${ns}" --type=json -p="[{'op': 'remove', 'path': '/spec/nodeConfig/registryMirrors/$INDEX'}]"
done <<< $(kubectl get clusters -l "$LABEL" -o jsonpath="$JSONPATH" -A)

    將 HARBOR_INSTANCE_URL 替換為 Harbor 執行個體的網址。

硬體安全模組

系統仍可偵測到已停用的 HSM 試用授權

版本：1.13.1、1.13.3 至 1.13.11

症狀：由於 CipherTrust Manager 存在已知問題，因此系統仍會偵測到已停用的試用授權，並可能觸發錯誤的到期警告。

解決方法：請參閱 HSM-R0003，確認有效的一般授權，並刪除已停用的試用授權。

HSM 主機精靈檔案描述元洩漏

版本：1.13.x

症狀：如果 HSM 執行時間超過 30 天，檔案描述元洩漏可能會導致主機精靈服務停止回應，進而產生 ServicesNotStarted 錯誤。

解決方法：重新啟動主機 Daemon 服務。如要執行這項操作，請要求基礎架構營運人員 (IO) 以 ksadmin 使用者身分透過 SSH 連線至 HSM，並執行下列指令：

sudo systemctl restart host-daemon

如果問題仍未解決，IO 可以重新啟動狀況不良的 HSM。

HSM 憑證已過期

版本：1.13.11

症狀：升級機構時，您可能會看到類似以下的警告：

Warning  Unsuccessful  50m   OrganizationUpgrade  1 error occurred:
          * UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn't after 13h45m23.442682119s, last message was: Cluster upgrade for system cluster: in-progress

由於 HSM (硬體安全模組) 憑證過期，org-1-system-cluster 無法升級至 ABM 版本。

您也可能會在 HPE 伺服器 iLO、StorageGRID 或 ONTAP 中看到類似以下範例的錯誤：

Not able to connect SSL to Key Manager server at IP_ADDRESS

解決辦法：

使用 ksctl 手動輪替根 CA 和網頁介面憑證：

  1. 暫停所有 HSM、HSMCluster 和 HSMTenant 罐頭回應。

  2. 建立新的根 CA，並複製舊 CA 的屬性。使用 ksctl ca locals list 找出舊的 CA ID。範例如下：

    ksctl ca locals create --cn example.com --copy-from-ca 6d7f7fa7-df81-44b7-b181-0d3e6f525d46
{
    "id": "b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "uri": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2025-06-04T18:46:25.728332Z",
    "updatedAt": "2025-06-04T18:46:25.728332Z",
    "state": "pending",
    "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIHQMHgCAQAwFjEUMBIGA1UEAxMLZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggq\nhkjOPQMBBwNCAAR5pwW1UC1JNg79gkjK2rvnmgaZpGNwb4VxYN3dQCieHtHlYJUu\nQWk56RB9oPw4SKkf/Y1ZwEI4m2mx3d9XFHU7oAAwCgYIKoZIzj0EAwIDSAAwRQIh\nANWTPjkJNcY56lSARN714EBa1gLuvxJlMENVHKEbanooAiA1BQ3sz7mxykL/1t7v\nqRlIpxKGrhw56XC67vz4NvZ4Kg==\n-----END CERTIFICATE REQUEST-----\n",
    "subject": "/CN=example.com",
    "notBefore": "0001-01-01T00:00:00Z",
    "notAfter": "0001-01-01T00:00:00Z",
    "sha1Fingerprint": "21F033940A65657CC6C2C1EA0BB775F14FD5D193",
    "sha256Fingerprint": "31EF6E1316DF039F77DDDB051890CDEBBF67BBE8A14AEE04E01716D30DC90937",
    "sha512Fingerprint": "F200817829A23F30239C33DC2CED8C889954A252EBA2CC12A3977FD5F91239ED7A2A4CCF0EA3D90D50CEF7A779E5C487798AAC75617DB2F29AF7F4794AD66F17",
    "purpose": {}
}

  3. 自行簽署新 CA，效期為一年。範例如下：

    ksctl ca locals self-sign --id b0516120-6b4c-40ed-93f4-35e9fdc690e7 -x 365
{
    "id": "b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "uri": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2025-06-04T18:46:25.728332Z",
    "updatedAt": "2025-06-04T18:52:51.976847092Z",
    "state": "active",
    "csr": "",
    "cert": "-----BEGIN CERTIFICATE-----\nMIIBbTCCAROgAwIBAgIRAMyQJHhs4i2uwj4ghilVFJQwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTg1MjUxWhcNMjYwNjA0MTg1\nMjUxWjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABHmnBbVQLUk2Dv2CSMrau+eaBpmkY3BvhXFg3d1AKJ4e0eVglS5BaTnp\nEH2g/DhIqR/9jVnAQjibabHd31cUdTujQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV\nHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQ9uCnTZ+lHhiLx3f1xEn0+JC5J+TAKBggq\nhkjOPQQDAgNIADBFAiBsSiB5BRBJ8TZQ6O5TzMBgDoWzTZVMVXNLdZUiqHtcDwIh\nAOnqKNq5ytWLvMsBQKhulGgqqw1dccpkJJz01n3Smzyp\n-----END CERTIFICATE-----\n",
    "serialNumber": "271910941595574900448900837122680099988",
    "subject": "/CN=example.com",
    "issuer": "/CN=example.com",
    "notBefore": "2025-06-03T18:52:51Z",
    "notAfter": "2026-06-04T18:52:51Z",
    "sha1Fingerprint": "1114AF5ED6DF7D4A9F83A0F8DF5DFEF041A81622",
    "sha256Fingerprint": "93BAD9D44B320EFB446F65FE2A4F3A341147D15AF5315C000ADF644A3C1347A7",
    "sha512Fingerprint": "07386D7461B4013304CF0E0830517EA433E09EAB146A9F106F1B0DED4BBEC78BB4C89EAFAEC37178FE98AC4ACA234B98290D240607D5EA896F03DABF3DB56D5C",
    "purpose": {
            "client_authentication": "Enabled",
            "user_authentication": "Enabled"
    }
}

  4. 更新網頁介面，使用這個新 CA 自動產生憑證。範例如下：

    ksctl interfaces modify --name web --auto-gen-ca-id kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7                 
{                                                                                                                                                                      
    "id": "61aab814-2821-43ac-b652-41784b7b06bf",                                                                                                                  
    "name": "web",                                                                                                                                                 
    "mode": "tls-cert-opt-pw-opt",                                                                                                                                 
    "cert_user_field": "CN",                                                                                                                                       
    "auto_gen_ca_id": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",                                                                              
    "trusted_cas": {                                                                                                                                               
            "local": [                                                                                                                                             
                    "kylo:kylo:naboo:localca:6d7f7fa7-df81-44b7-b181-0d3e6f525d46"                                                                                 
            ]                                                                                                                                                      
    },                                                                                                                                                             
    "createdAt": "2023-11-13T22:46:56.251881Z",                                                                                                                    
    "updatedAt": "2025-06-04T19:02:12.710563Z",                                                                                                                    
    "port": 443,                                                                                                                                                   
    "network_interface": "all",                                                                                                                                    
    "interface_type": "web",                                                                                                                                       
    "minimum_tls_version": "tls_1_2",                                                                                                                              
    "maximum_tls_version": "tls_1_3",                                                                                                                              
    "local_auto_gen_attributes": {                                                                                                                                 
            "cn": "web.ciphertrustmanager.local",                                                                                                                  
            "dns_names": [                                                                                                                                         
                    "web.ciphertrustmanager.local"                                                                                                                 
            ],      
...

  5. 產生由新 CA 簽署的新網頁介面憑證。--url 標記是 HSM 的管理 IP (來自 kubectl get hsm -n gpc-system)。範例如下：

    ksctl interfaces auto-gen-server-cert --name "web" --url=https://10.128.52.18
{
    "certificates": "-----BEGIN CERTIFICATE-----\nMIICljCCAjygAwIBAgIRANPuw/42oHZAb9nzAYnrf9MwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTkwOTU5WhcNMjYwNjA0MTg1\nMjUxWjBjMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVFgxDzANBgNVBAcTBkF1c3Rp\nbjEPMA0GA1UEChMGVGhhbGVzMSUwIwYDVQQDExx3ZWIuY2lwaGVydHJ1c3RtYW5h\nZ2VyLmxvY2FsMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEy9T8uGa/N9ruRJMy\nxy4an+G/OyZjB/8nth1BPxpw5orljbTuOh9toS9c9FiOuMQQ13mGJSImadLP33PR\ngdXcHaOCARwwggEYMA4GA1UdDwEB/wQEAwIDiDATBgNVHSUEDDAKBggrBgEFBQcD\nATAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFD24KdNn6UeGIvHd/XESfT4kLkn5\nMGIGA1UdEQRbMFmCHHdlYi5jaXBoZXJ0cnVzdG1hbmFnZXIubG9jYWyBIXRlY2hu\naWNhbC5zdXBwb3J0QHRoYWxlc2dyb3VwLmNvbYcECoA0EocECgADAocErBMjAocE\nrBMLAjBeBgNVHR8EVzBVMFOgUaBPhk1odHRwOi8vY2lwaGVydHJ1c3RtYW5hZ2Vy\nLmxvY2FsL2NybHMvYjA1MTYxMjAtNmI0Yy00MGVkLTkzZjQtMzVlOWZkYzY5MGU3\nLmNybDAKBggqhkjOPQQDAgNIADBFAiEAusSKWMoFeTsK+OrbURch7XtMR31XD45E\n+w+wjf2VAk4CIAsHytphizTFQks4qqOMaHm6Ap58uU0HMNGSm0WW6mQY\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIIBbTCCAROgAwIBAgIRAMyQJHhs4i2uwj4ghilVFJQwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTg1MjUxWhcNMjYwNjA0MTg1\nMjUxWjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABHmnBbVQLUk2Dv2CSMrau+eaBpmkY3BvhXFg3d1AKJ4e0eVglS5BaTnp\nEH2g/DhIqR/9jVnAQjibabHd31cUdTujQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV\nHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQ9uCnTZ+lHhiLx3f1xEn0+JC5J+TAKBggq\nhkjOPQQDAgNIADBFAiBsSiB5BRBJ8TZQ6O5TzMBgDoWzTZVMVXNLdZUiqHtcDwIh\nAOnqKNq5ytWLvMsBQKhulGgqqw1dccpkJJz01n3Smzyp\n-----END CERTIFICATE-----\n"
}

  6. 此時 openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text 仍會顯示舊憑證。您必須重新啟動 HSM，才能擷取新憑證。

    ssh -i ~/.ksctl/ssh-privatekey ksadmin@10.128.52.18

sudo reboot

    現在 openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text 會顯示新憑證。

  7. 從 HSM CR 刪除舊的 CA：

    kubectl edit hsm zv-aa-hsm01 -n gpc-system and delete hsm.Spec.RootCACertificates

  8. 解除暫停 HSM：

    kubectl annotate hsm zv-aa-hsm01 -n gpc-system hsm.security.private.gdc.goog/paused-

    確認 HSM 恢復正常運作。

  9. 針對其他兩個 HSM 重複上述步驟。由於 CA 會在叢集中的 HSM 之間共用，因此這些 HSM 已經有新的自簽根 CA。略過步驟 2 和 3，但重複執行步驟 4 到 8。

  10. 請按照 HSM T0008 CA 輪替作業，自動輪替所有憑證，但請略過「Finalize the rotation by adding a new rotation annotation to hsmcluster」(在 hsmcluster 中新增輪替註解，完成輪替作業) 步驟，因為該步驟會新增 ca-rotation-finalizing annotation。

將新的 CA 名稱上傳至 iLO：

  1. 在 iLO 介面中，開啟「Administration - Key Manager」頁面，然後按一下「Key Manager」分頁標籤。
  2. 輪替憑證名稱。
  3. 執行冷重新啟動。
  4. 確認 SSL 交握程序是否恢復運作。

身分與存取權管理

gatekeeper-audit opa-system 命名空間中的 Pod 經常重新啟動

版本：1.13.3

症狀：檢查 opa-system 命名空間中 gatekeeper-audit-*** Pod 的狀態：

kubectl get pods/gatekeeper-audit-POD_ID -n opa-system-NAMESPACE_ID -n opa-system

輸出內容可能如下所示：

NAME                                READY   STATUS    RESTARTS        AGE
gatekeeper-audit-58d8c4c777-7hzvm   2/2     Running   987 (12h ago)   12d

這是因為資源限制過低所致。

基礎架構即程式碼 (IAC)

過度建立 Gitlab 權杖可能會填滿 Gitlab 資料庫

版本：1.13.1

症狀：iac-manager 子元件會重複為 configsync-ro 使用者建立新權杖，即使並非必要也會這麼做。這可能會導致 Gitlab 資料庫填滿，使 IAC 無法存取。gitlab-system 命名空間中的 pg-gitlab-database-0 Pod 可能無法啟動，並顯示下列事件：

  Warning  Unhealthy  84s (x18 over 4m14s)   kubelet  Startup probe failed: /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  could not write init file

解決方法：

請洽詢 Google 聯絡人，取得 1.13.1 版本的 hotfix_3 並套用。

金鑰管理系統 (KMS)

變更根金鑰類型會導致所有現有金鑰失效

版本：1.13.x

症狀：建立機構後，KMS 會自動佈建軟體根金鑰。如要從軟體根金鑰遷移至 CTM 金鑰，使用者必須覆寫子元件。這會變更根金鑰類型，導致 KMS 中的所有現有軟體金鑰失效。

解決方法：盡量避免更新根金鑰類型。如果更新根金鑰類型，所有現有金鑰都會失效。

kms-rootkey-controller CrashLoopBackOff，原因：OOMKILL

版本：1.13.1

症狀：當 kms-rootkey-controller 記憶體用量超過 600Mi 限制時，控制器會因 OOMKilled 狀態而進入 CrashLoopBackOff。

解決方法：建立 SubcomponentOverride，將記憶體限制更新為 1500Mi。如需操作說明，請參閱 KMS Runbook 0007。完成 Runbook 中的必要步驟後，請執行下列指令：

  1. 建立SubcomponentOverride自訂資源：

    cat << EOF > ~/kms-rootkey-subcomponentoverride.yaml

    在以下範例中，您會看到完整的 SubcomponentOverride 自訂資源：

    apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: kms-rootkey-subcomponentoverride
  namespace: root
spec:
  subComponentRef: kms-rootkey-cm
  backend:
    operableParameters:
      resourcesLimit:
        memory: 1500Mi
EOF

  2. 套用 SubcomponentOverride 資源：

    kubectl --kubeconfig ${KUBECONFIG:?} apply -f ~/kms-rootkey-subcomponentoverride.yaml

kubectl --kubeconfig ${KUBECONFIG:?} describe subcomponentoverride kms-rootkey-subcomponentoverride -n root

記錄

物件儲存空間稽核記錄器無法解析 DNS 主機

版本：1.13.x

症狀：

在根管理員叢集中，obs-system/log-remote-logger 部署作業包含多項錯誤，例如：

E1220 17:00:25.247258       1 manager.go:183] Failed to fetch obj audit logs for gce-gpcstgesite01: failed to get authorization token for Grid Management  API: Post "https://objectstorage-grid-mgmt.gpc-system.svc.cluster.local/api/v3/authorize": dial tcp: lookup objectstorage-grid-mgmt.gpc-system.svc.cluster.local: no such host

解決方法：使用下列指令修補 obs-system/log-remote-logger 部署作業：

kubectl --kubeconfig ${KUBECONFIG:?} patch deployment log-remote-logger -n obs-system -p '{"spec":{"template":{"spec":{"dnsPolicy":"ClusterFirstWithHostNet"}}}}'

HaaS Logger 在根管理員叢集中顯示錯誤

版本：1.13.x

症狀：

在根管理員叢集中，obs-system/log-remote-logger 部署作業包含多項錯誤，例如：

E0109 17:33:08.917876       1 manager.go:156] Failed to run logger haas: Failed to get log targets: failed to list harborinstances in the cluster: failed to get API group resources: unable to retrieve the complete list of server APIs: artifactregistry.gdc.goog/v1: the server could not find the requested resource

解決方法：升級至 1.13.8 即可修正錯誤。或者，按照下列方式修改 obs-system/log-remote-logger 部署作業：

在 remote-logger 容器引數中，更新 --disabled-loggers 旗標以加入 santricity 和 HaaS：

YAML

args:
  - --disabled-loggers=santricity,haas

Santricity Logger 失敗

版本：1.13.x

症狀：

在根管理員叢集中，obs-system/log-remote-logger 部署作業包含多項錯誤，例如：

E0109 17:33:10.931737       1 manager.go:183] Failed to fetch santricity audit logs for lb-aa-objs01: failed to get CA cert: failed to get ClusterIssuer internal-root-ca-issuer: no kind is registered for the type v1.ClusterIssuer in scheme "pkg/logging/manager.go:32"

解決方法：升級至 1.13.8 即可修正錯誤。

記錄目標記錄檔傳送至錯誤的專案

版本：1.13.x

症狀：obs-system/oplogs-forwarder DaemonSet 記錄的警告類似於下列內容：

oplogs-forwarder-2xrfw [2025/01/16 21:02:09] [ warn] [output:loki:log_output_loki_dbs_fleet_system_dbs_fleet] Tenant ID is overwritten platform-obs -> infra-obs
oplogs-forwarder-kxf8p [2025/01/16 21:05:23] [ warn] [output:loki:log_output_loki_workbench_system_nws_lt] Tenant ID is overwritten infra-obs -> platform-obs

這些警告會導致記錄檔轉送至錯誤的專案 (租戶 ID)。這個問題源自 Fluent Bit 的已知錯誤。詳情請參閱 Fluent Bit GitHub 問題。

解決方法：升級至 1.13.8 即可修正錯誤。

平台命名空間的稽核記錄不會向 PA 顯示

版本：1.13.x

症狀：平台命名空間的稽核記錄會顯示給基礎架構運算子 (IO)，而不是平台管理員 (PA)。

解決方法：在所有機構叢集的 platform 命名空間中，手動新增 observability.gdc.goog/auditlog-destination=pa 標籤。如要手動解決這個問題，請按照下列步驟操作：

  1. 將 KUBECONFIG 設為目標叢集。

  2. 在命名空間中新增必要標籤：

    KUBECONFIG=${KUBECONFIG:?} kubectl label namespace platform observability.gdc.goog/auditlog-destination=pa --overwrite

  3. 確認標籤是否已成功新增：

    KUBECONFIG=${KUBECONFIG:?} kubectl label namespace platform --list

Pod 無法初始化容器

版本：1.13.x

症狀：無法建立 Pod，並顯示類似下列的錯誤：

Events:
│   Type     Reason                  Age                     From     Message                                                                                                                                                 │
│   ----     ------                  ----                    ----     -------                                                                                                                                                 │
│   Warning  FailedCreatePodSandBox  10m (x2080 over 7h40m)  kubelet  Failed to create pod sandbox: mkdir /var/log/pods/org-1_managed-asm-local-readiness-xq75d_9a3275d7-5f16-4d67-8f4a-38fe0993be4a: no space left on device │

這些錯誤會導致 Pod 無法在特定節點上啟動。我們發現，在已知極端情況下，logrotate-daemon 狀態檔案會遭到鎖定，導致精靈無法執行預期的檔案輪替作業，進而產生上述行為。如要確認這項錯誤，請按照下列步驟操作：

  1. 將 KUBECONFIG 設為目標叢集。

  2. 找出節點上排定的 anthos-audit-logs-forwarder-xxxx 執行個體。

    KUBECONFIG=${KUBECONFIG:?} kubectl get po -n obs-system -o wide | grep anthos-audit-logs-forwarder

  3. 從節點上排定的 anthos-audit-logs-forwarder-xxxx 執行個體擷取記錄，以進行驗證。

    KUBECONFIG=${KUBECONFIG:?} kubectl logs -n obs-system anthos-audit-logs-forwarder-xxxx -c logrotate-daemon | grep "state file /var/lib/logrotate/status is already locked"

解決辦法：

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

  1. 在節點的 /var/log 目錄中手動回收磁碟空間。

  2. 將 KUBECONFIG 設為目標叢集。

  3. 找出叢集中的目標節點。

    KUBECONFIG=${KUBECONFIG:?} kubectl get no -o wide

  4. 使用 SSH 連線至節點，並手動釋放節點上 /var/log 目錄的空間。logrotate 會管理這些目錄下的檔案。

    /var/log/audit/*/*/*/audit.log
/var/log/audit*/*/*.log
/var/log/auditproxy-*/*.log
/var/log/global-api-*/audit.log
/var/log/ceph/ceph.audit.log
/var/log/fanout/audit/*.log
/var/log/fanout/audit/*/*.log
/var/log/netflow/*.log
/var/log/fanout/operational/*.log
/var/log/fanout/operational/*/*.log

  5. 檢查是否有異常大的記錄檔 (超過 100 MB) 或幾天前的檔案。取得目標檔案後，即可按照下列方式截斷記錄：

    truncate -s 1G <target_file>

  6. 找出節點上排定的 anthos-audit-logs-forwarder-xxxx 執行個體。

    KUBECONFIG=${KUBECONFIG:?} kubectl get po -n obs-system -o wide | grep anthos-audit-logs-forwarder

  7. 重新啟動節點上排定的 anthos-audit-logs-forwarder-xxxx 執行個體。

    KUBECONFIG=${KUBECONFIG:?} kubectl delete po -n obs-system anthos-audit-logs-forwarder-xxxx

Marketplace

Prisma Cloud 映像檔提取失敗

版本：1.13.7

症狀：從 Marketplace 建立 Prisma Cloud 服務執行個體失敗。問題是由不正確的圖片標記所致。

解決辦法：

  1. 編輯 twistlock-console deployment，修改映像檔標記：

    KUBECONFIG=${KUBECONFIG:?} kubectl edit deployment twistlock-console -n ${PROJECT:?}

  2. 找出下列程式碼：

    image: HARBOR_IP/library/twistlock/console:console_33_01_137

  3. 將 console_33_01_137 替換為 console_33.01.137：

    image: HARBOR_IP/library/twistlock/console:console_33.01.137

  4. 確認 Pod 正常運作：

    KUBECONFIG=${KUBECONFIG:?} kubectl get pods -n ${PROJECT:?}

    輸出內容可能如下所示：

    NAME                                 READY   STATUS    RESTARTS   AGE
twistlock-console-58b578cbf4-5nvbk   1/1     Running   0          2m45s

監控

在 ServiceNow 中建立大量快訊

版本：1.13.x

症狀：

使用 MON-T0016 和 MON-T1016 toil 工作，將快訊傳送至 ServiceNow 後，系統會在 ServiceNow 中自動建立大量事件。

這個問題具有下列特徵：

  • 所有事件都是空的。
  • 只有根管理員叢集和gdchservices機構可以將快訊傳送至 ServiceNow。

解決方法：執行 MON-T0016 和 MON-T1016 苦差事工作後，請立即執行 MON-T0018 苦差事工作。

在 ServiceNow 中建立多個重複快訊

版本：1.13.x

症狀：

使用 MON-T0016、MON-T1016 和 MON-T0018 toil 工作，將快訊傳送至 ServiceNow 後，系統會在 ServiceNow 中建立多個重複快訊。

這個問題具有下列特徵：

  • 套用 MON-T0018 雜務後，部分快訊仍會建立多個重複事件。

解決方法：執行 MON-T0016、MON-T1016 和 MON-T0018 雜務工作後，立即執行 MON-T0019 雜務工作。

無法查看 Vertex AI 指標

版本：1.13.1

症狀：dvs-frontend-server Pod 未發出指標。

解決方法：1.13.1 版不支援 Vertex AI 服務的加密指標。如果 Vertex AI 服務啟用時間超過一小時，請重新啟動 mon-admin 控制器 Pod。

「mon-cortex」中的對帳錯誤

版本：1.13.1、1.13.9

症狀：mon-cortex Pod 發生對帳錯誤。取得 mon-cortex pod 的狀態：

kubectl get subcomponent mon-cortex -n gpu-org-1-system-cluster

輸出內容可能如下所示：

NAME         AGE   STATUS
mon-cortex   15h   ReconciliationError

系統可能會記錄類似下列內容的訊息：

message: 'E0100 - deploy: failed to install chart: release mon-cortex-backend
        failed, and has been uninstalled due to atomic being set: context deadline
        exceeded'

解決辦法：

  1. 檢查哪個 Cortex Pod 顯示類似這樣的訊息：

    Warning  FailedMount             11s   kubelet                  MountVolume.MountDevice failed for volume "pvc-0ad24fdc-52ec-4080-8ac0-5784989d1da3" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: could not open LUKS device; could not open LUKS device; could not open LUKS device; exit status 1

  2. 刪除與該 Pod 相關聯的 PVC，然後重新啟動。

系統叢集中的 metrics-server-exporter Pod 發生當機迴圈

版本：1.13.1

症狀：系統叢集中的 metrics-server-exporter Pod 發生當機迴圈，並顯示 OOMKilled，但似乎未達到限制。診斷錯誤：

kubectl --kubeconfig $KUBECONFIG describe pod -n mon-system metrics-server-exporter-<id>

輸出內容可能如下所示：

[...]
Containers:
  [...]
  otel-collector:
    Container ID:  containerd://3a1373de4880cde9e09aa9cacc109a8059ec29d9355aef1f03735fdcdcd45596
    Image:         gcr.io/private-cloud-staging/opentelemetry-collector:v0.93.0-gke.2
    Image ID:      gcr.io/private-cloud-staging/opentelemetry-collector@sha256:2b14f8fe936e725efca24dace1abcc26449d996b1480eab1b25d469a16aac221
    Port:          3113/TCP
    Host Port:     0/TCP
    Command:
      /otelcol
      --config=/conf/otel-collector-config.yaml
      --feature-gates=pkg.translator.prometheus.PermissiveLabelSanitization
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Thu, 20 Jun 2024 15:55:35 +0000
      Finished:     Thu, 20 Jun 2024 15:56:57 +0000
    Ready:          False
    Restart Count:  570
    Limits:
      cpu:     200m
      memory:  200Mi
    Requests:
      cpu:        100m
      memory:     100Mi
    Environment:  <none>

解決方法：刪除 Pod 並讓它重新啟動，減少指標端點提供的資料量。這樣做會清除記憶體中保留的舊 time-series，減少所需記憶體。

忽略 ObservabilityPipeline 對帳錯誤訊息

版本：1.13

症狀：

ObservabilityPipeline 物件會在 root-admin-controller Pod 中顯示 Reconciler error 記錄，如下所示：

{"msg":"Reconciler error","controller":"observabilitypipeline","ObservabilityPipeline":{"name":"default","namespace":"infra-obs"},"namespace":"infra-obs","name":"default","err":"unable to reconcile project level ObservabilityPipeline: 1 error occurred:\n\t* failed to get system cluster client to install per project overrides: root admin cluster has no system cluster\n\n"}

解決辦法：

忽略符合下列所有條件的記錄：

  • "controller":"observabilitypipeline"
  • "namespace":"infra-obs"
  • "name":"default"
  • "err" 包含 failed to get system cluster client to install per project overrides: root admin cluster has no system cluster

如果因高和解錯誤而偵錯快訊，請忽略這些記錄，因為這些是偽陰性。

mon-prober-backend-prometheus-config ConfigMap 會重設

版本：1.13.0 和 1.13.1

症狀：

  • 已觸發快訊 MON-A0001。

  • mon-prober-backend-prometheus-config ConfigMap 會重設為不包含任何探查工作，例如：

    apiVersion: v1
data:
  prometheus.yaml: |
    remote_write:
    - url: http://cortex-tenant.mon-system.svc:9009/push
      name: cortex-tenant
kind: ConfigMap
metadata:
  creationTimestamp: "2024-06-26T14:55:07Z"
  name: mon-prober-backend-prometheus-config
  namespace: mon-system
  resourceVersion: "6606787"
  uid: 1a495af0-1fdc-40b8-845b-4976e3b0f899

解決辦法：

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

  1. 請設定下列環境變數：

    • KUBECONFIG：叢集中的 kubeconfig 檔案路徑。
    • TARGET_CLUSTER：要解決問題的叢集名稱。

  2. 在所有叢集上暫停 mon-prober 子元件：

    kubectl --kubeconfig $KUBECONFIG annotate subcomponent mon-prober -n $TARGET_CLUSTER lcm.private.gdc.goog/paused=true

    例如：

    kubectl --kubeconfig ~/root-admin-kubeconfig annotate subcomponent mon-prober -n my-org lcm.private.gdc.goog/paused=true

  3. 在每個管理員叢集上重新啟動 MON 管理員控制器：

    kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n obs-system mon-admin-backend-controller

    每註冊一個探測器，Prober ConfigMap 就會填入資料。

  4. 請按照 Runbook MON-R2009 忽略 MON-A0001 警報 Blackbox monitoring metrics pipeline down，因為這則警報會持續觸發。

Cortex 商店閘道元件 OOMKilled 發生 crashloop

版本：1.13.3

徵兆：如果在載入指標時 Grafana 顯示錯誤，或是指標完全無法載入，則 cortex-store-gateway Pod 可能會進入當機迴圈。

如要診斷 cortex-store-gateway Pod 並檢查是否發生當機迴圈，請查看其狀態：

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG describe pod \
  -l app=cortex-store-gateway -n mon-system

將 SYSTEM_CLUSTER_KUBECONFIG 替換為系統叢集的 kubeconfig 檔案路徑。

如果 Pod 發生當機迴圈，輸出內容會如下列範例所示：

State:          Waiting
Reason:       CrashLoopBackOff
Last State:     Terminated
Reason:       OOMKilled
Exit Code:    137

解決方法：暫時使用 SubcomponentOverride 提高 cortex-store-gateway 記憶體限制。如要瞭解如何實作 SubComponentOverride，請參閱 MON-R2008 執行手冊。

以下是指定記憶體限制的 SubcomponentOverride 範例：

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: mon-cortex-memory-bump
  namespace: org-1-system-cluster
spec:
  subComponentRef: 'mon-cortex'
  backend:
    operableParameters:
      storeGateway:
          resourcesLimit:
              memory: 16Gi

保留覆寫設定，直到所有 Pod 都處於 Ready 狀態，並確保 mon-cortex 子元件未暫停：cortex-store-gateway

  • 確認 cortex-store-gateway Pod 的狀態為 Ready：

    kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG get statefulset \
  -n mon-system cortex-store-gateway

    如果所有 Pod 的狀態都是 Ready，輸出內容會如下列範例所示：

    NAME                   READY   AGE
cortex-store-gateway   3/3     70d

    所有 Pod 的 READY 欄都必須顯示 N/N 值，Pod 才會準備就緒。 否則會顯示 1/3 或 2/3 等值。

  • 確認特定機構的 mon-cortex 子元件未暫停：

    kubectl --kubeconfig ORG_ADMIN_KUBECONFIG describe subcomponent \
  -n SYSTEM_CLUSTER mon-cortex | grep paused

    更改下列內容：

    • ORG_ADMIN_KUBECONFIG：機構管理員叢集的 kubeconfig 檔案路徑。
    • SYSTEM_CLUSTER：系統叢集的名稱。

    如果子元件已暫停，輸出內容會顯示下列行：

    lcm.private.gdc.goog/paused: true

    否則輸出內容會空白。

使用者叢集中的 Kube 控制層指標 Proxy 映像檔提取作業退避

版本：1.13.3

症狀：如果 Grafana 中未顯示與 kube-scheduler 或 kube-controller-manager 相關的指標 (例如 scheduler_pending_pods 和 workqueue_depth 指標)，可能是 kube-control-plane-metrics-proxy Pod 發生映像檔提取退避問題。

如要診斷 kube-control-plane-metrics-proxy Pod 並檢查是否有映像檔提取退避問題，請查看其狀態：

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe pod \
  -l k8s-app=kube-control-plane-metrics-proxy -n obs-system

將 USER_CLUSTER_KUBECONFIG 替換為使用者叢集的 kubeconfig 檔案路徑。

如果 Pod 發生映像檔提取延遲問題，輸出內容會如下列範例所示：

State:          Waiting
Reason:       ImagePullBackOff
Ready:          False
Restart Count:  0

解決方法：請按照下列步驟解決問題：

  1. 從 gpc-system-container-images Harbor 專案提取 gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 映像檔。如需提取映像檔的操作說明和必要權限，請參閱「使用 Docker 提取映像檔」。

  2. 將 gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 映像檔推送至 libraryHarbor 專案。如需推送映像檔的操作說明和必要權限，請參閱推送映像檔。

    library 專案用於將構件部署至使用者叢集。

WAL 成長會導致 Prometheus 耗用大量記憶體

版本：1.13.3

症狀：系統控制平面 VM 節點會回報 NodeHasInsufficientMemory 和 EvictionThresholdMet 事件：

kubectl describe node NODE_NAME | grep Events -A100

輸出內容可能如下列範例所示：

Events:
  Type     Reason                     Age                   From                   Message
  ----     ------                     ----                  ----                   -------
  Normal   NodeNotReady               12m (x8 over 10d)     node-controller        Node vm-e792c63a status is now: NodeNotReady
  Normal   NodeHasNoDiskPressure      12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeHasNoDiskPressure
  Normal   NodeHasSufficientPID       12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeHasSufficientPID
  Normal   NodeReady                  12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeReady
  Normal   NodeHasInsufficientMemory  12m (x34 over 13h)    kubelet                Node vm-e792c63a status is now: NodeHasInsufficientMemory
  Warning  EvictionThresholdMet       12m (x64 over 13h)    kubelet                Attempting to reclaim memory
  Normal   TridentServiceDiscovery    11m (x21 over 13h)    csi.trident.netapp.io  [iSCSI] detected on host.
  Normal   NodeHasSufficientMemory    6m52s (x31 over 24d)  kubelet                Node vm-e792c63a status is now: NodeHasSufficientMemory

由於 WAL (預先寫入記錄) 成長，Prometheus 會使用大量記憶體，進而影響節點的記憶體。WAL 成長可能是因為 Cortex 未部署，因此這個問題可能是 Cortex 停機的後果。Prometheus 執行個體與 Cortex 的連線中斷時間過長，因此會將資料緩衝到記憶體和持續性磁碟區 (PV)。Prometheus 終止時，會在啟動時將 WAL 中的所有資料載入記憶體。

另一個根本原因可能是網路連線問題 (服務網格、實體和上層網路)。

解決方法：如要從這個狀態復原，建議您解決根本原因，讓 Cortex 恢復正常運作，或是解決網路連線問題。接著，等待 Prometheus 的 WAL 清除。您不會遺失資料，但如果 Cortex 發生故障，節點在 Cortex 復原前將無法使用。

或者，您可以將 Prometheus STS 縮減為零，然後刪除 PV。這項操作可縮短節點無法使用的總時間，但會導致資料遺失。此外，只要 Cortex 仍處於離線狀態或網路連線發生問題，您就必須定期重複這個動作。只要 Prometheus 和 Cortex 之間有連線問題，PV 就會再次填滿。

請按照下列步驟將 Prometheus STS 縮減為零，並刪除 PV：

  1. 縮減 logmon-operator 元件：

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale deployment -n obs-system logmon-operator --replicas 0

    將 ORG_SYSTEM_KUBECONFIG 替換為機構系統叢集中的 kubeconfig 檔案路徑。

  2. 縮減 anthos-prometheus-k8s 元件：

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale statefulset -n obs-system anthos-prometheus-k8s --replicas 0

  3. 刪除永久磁碟區要求：

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG delete pvc -n obs-system anthos-prometheus-k8s-data-anthos-prometheus-k8s-0

  4. 向上擴充 logmon-operator：

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale deployment -n obs-system logmon-operator --replicas 1

  5. 等待 anthos-prometheus-k8s 準備就緒。

多可用區啟動程序

缺少叢集角色

版本：1.13.1

症狀：沒有可供啟動多區域的特定角色，因此無法在「新增必要角色」中使用。

解決方法：按照連結的操作說明，使用 cluster-admin 叢集角色。這樣一來，使用者就能取得執行後續工作所需的最低存取權。

不相容的Bootstrap資源

版本：1.13.1

症狀：在「建立啟動程序檔案」的步驟 3 中建立的 Bootstrap 資源，與處理該資源的邏輯不相容。

解決方法：按照步驟 4 的規定編輯產生的 YAML 檔案。

全域 API 中未建立 GlobalAPIZone 資源

版本：1.13.1

症狀：控制層不會在全域 API 中為區域建立 GlobalAPIZone 資源，導致依賴這項資源的元件無法正常運作。

解決方法：按照「建立 GlobalAPIZone 資源」的說明建立資源。

網路

物件儲存空間節點格線網路中斷

版本：1.13.1、1.13.3、1.13.4

症狀：

  1. 在物件儲存空間啟動階段，OBJ 管理節點安裝程式 UI 會顯示格線網路已關閉。
  2. cables.csv 和 Cell CR 顯示，objsadmin 節點與 TOR 交換器之間的連線，其 cables.csv 中的 MPN 值為 QSFP-100G-CU2.5M。

說明 在 1.13 版中，cables.csv 中的 MPN 欄位用於決定 Tor 交換器上設定的速度。 如果未在這些通訊埠上設定速度，tor 切換至 objsadmin 節點連線就會失敗。用來將 MPN 對應至速度的清單未考量系統整合商提供的值，導致物件儲存空間啟動程序失敗。在大多數 1.13 設定中，供應商使用的格式為：QSFP-100G-CU2.5M。

解決辦法：

  1. 在根管理員叢集上使用 kubectl get -A cell -oyaml，找出與物件儲存裝置和 TOR 交換器相關的連線。
  2. 將 objsadm -> torsw 連線的所有 mpn 變更為「QSFP-100G-CU3M」。

範例如下：

    - endA: "ap-aa-torsw01:Eth1/10"
      endB: "ap-aa-objsadm01:e3a"
      cableType: "DAC"
      mpn: "QSFP-100G-CU3M"
      length: "2m"
      color: "Black"

無法連線至節點

版本：1.13.1、1.13.3、1.13.4

症狀：

  1. 在網路啟動階段，部分交換器無法連線。
  2. 在 DHCP 安裝階段，部分伺服器無法透過 iLO IP 位址連線。

解決辦法：

  1. 重新載入受影響的管理交換器。詳情請參閱 PNET-R0018 執行手冊。

即使已建立 ClusterCIDRConfig，PodCIDR 仍未指派給節點

版本：1.13.1

症狀：ClusterCIDRConfig 是指派 PodCIDRs 的必要物件。 雖然已建立 ClusterCIDRConfig，但 PodCIDRs 未獲指派。如果 ClusterCIDRConfig 是在 ipam-controller Pod 啟動時建立，就會發生這個問題。叢集建立作業卡在協調狀態。

  1. 檢查叢集上是否已建立 ClusterCIDRConfig 物件：

    kubectl --kubeconfig=CLUSTER_KUBECONFIG get clustercidrconfigs -oyaml

    輸出內容可能如下所示：

    apiVersion: v1
items:
- apiVersion: networking.gke.io/v1alpha1
  kind: ClusterCIDRConfig
  metadata:
    annotations:
      baremetal.cluster.gke.io/managed: "true"
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"networking.gke.io/v1alpha1","kind":"ClusterCIDRConfig","metadata":{"annotations":{"baremetal.cluster.gke.io/managed":"true"},"creationTimestamp":null,"name":"root-admin-control-plane"},"spec":{"ipv4":{"cidr":"172.24.0.0/21","perNodeMaskSize":23},"ipv6":{"cidr":"fd00:1::2:0/112","perNodeMaskSize":119}},"status":{}}
    creationTimestamp: "2024-06-17T05:27:55Z"
    finalizers:
    - networking.kubernetes.io/cluster-cidr-config-finalizer
    generation: 1
    name: root-admin-control-plane
    resourceVersion: "2172"
    uid: d1216fe3-04ed-4356-a105-170d72d56c90
  spec:
    ipv4:
      cidr: 172.24.0.0/21
      perNodeMaskSize: 23
    ipv6:
      cidr: fd00:1::2:0/112
      perNodeMaskSize: 119
kind: List
metadata:
  resourceVersion: ""

  2. 針對卡在協調狀態的叢集，對其中一個節點物件執行說明，並檢查節點物件上是否有 CIDRNotAvailable 事件：

    kubectl --kubeconfig=CLUSTER_KUBECONFIG describe node NODE_NAME

    輸出事件可能如下所示：

      Type     Reason            Age                   From             Message
  ----     ------            ----                  ----             -------
  Normal   CIDRNotAvailable  3m22s (x96 over 21h)  cidrAllocator    Node gpc-adhoc-4f533d50vm-worker-node2-zone1 status is now: CIDRNotAvailable
  Warning  ReconcileError    3m22s (x96 over 21h)  ipam-controller  CIDRAssignmentFailed, retrying: failed to get cidrs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, unable to get clusterCIDRs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, no available CIDRs

解決辦法：

  1. 重新啟動 ipam-controller-manager Pod：

    kubectl --kubeconfig=CLUSTER_KUBECONFIG -n kube-system rollout restart ds ipam-controller-manager

  2. ipam-controller-manager Pod 處於執行狀態後，請檢查 podCIDR 是否已指派給節點：

    kubectl --kubeconfig=CLUSTER_KUBECONFIG get nodes -oyaml | grep podCIDR

    輸出內容可能如下所示：

    podCIDR: 172.24.4.0/23
podCIDRs:
podCIDR: 172.24.2.0/23
podCIDRs:
podCIDR: 172.24.0.0/23
podCIDRs:

NTP 偏移

版本：1.13.1

症狀：VM 節點在休眠或執行一段時間後，時間發生偏移或不準確。

解決辦法：

  1. 與 VM 節點建立 SSH 連線，並編輯 /etc/chrony.conf檔案。
  2. 將 makestep 1.0 3 這一行替換為 makestep 1.0 -1。

  3. 重新啟動 chronyd 服務：

    systemctl restart chronyd

每部 VM 只需要變更一次。系統不會覆寫變更。

如要立即快速修正時間，請建立與 VM 節點的 SSH 連線，然後執行 chronyc -a makestep。

未剖析 SyncServer 稽核記錄

版本：1.13.1、1.13.3、1.13.4、1.13.5、1.13.6、1.13.7

症狀：log-remote-logger無法正確剖析 SyncServer 的稽核記錄。部分稽核記錄不會顯示在 Grafana 中，您可能會在 root-admin log-remote-logger Pod 中看到類似下列的錯誤訊息：

Failed to fetch syncserver audit logs for syncserver-...

解決方法：稽核記錄仍可在 SyncServer 上查看。請按照 NTP-P0002 的步驟存取 SyncServer UI，並查看 Logs > Events 下的記錄。

無法擷取圖片，因此無法切換圖片

版本：1.13.3

症狀：執行 Switch RMA 或啟動根管理員叢集時，您可能會在物件上看到類似下方的訊息：SwitchImageHostRequest 

failed to pull or extract image "192.0.2.0:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004

如果您有 kubectl 存取權，請使用該存取權確認是否遇到這個問題：

kubectl --kubeconfig=<path/to/root-admin-kubeconfig> -n gpc-system get switchimagehostrequest -o yaml

輸出內容可能如下列範例所示：

kind: SwitchImageHostRequest
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    meta.helm.sh/release-name: pnet-core-assets
    meta.helm.sh/release-namespace: pnet-system
  creationTimestamp: "2024-08-20T04:16:36Z"
  generation: 1
  labels:
    app.kubernetes.io/managed-by: Helm
  name: v1.13.0-pnet-aa505d9004
  namespace: gpc-system
  resourceVersion: "149295"
  uid: f6c5b880-3fdb-4679-acd4-840b52998946
spec:
  fromVersion: v1.13.0-pnet-aa505d9004
  toVersion: v1.13.0-pnet-aa505d9004
status:
  conditions:
  - lastTransitionTime: "2024-08-20T05:10:17Z"
    message: ""
    observedGeneration: 1
    reason: TFTPRunning
    status: "True"
    type: TFTPReady
  - lastTransitionTime: "2024-08-20T04:16:36Z"
    message: 'exception: failed to pull images with config images: [{10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004
      /shared/tftpboot/switch/images}]: failed to pull or extract image "10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004":
      failed to pull image from source "10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004":
      GET https://10.249.48.5:10443/v2/gdch-switch/os/manifests/v1.13.0-pnet-aa505d9004:
      NOT_FOUND: artifact gdch-switch/os:v1.13.0-pnet-aa505d9004 not found'
    observedGeneration: 1
    reason: ReconcileBackoff
    status: Unknown
    type: Ready

解決辦法：

手動建立含有正確圖片代碼的 SwitchImageHostRequest：

  1. 登入啟動程式伺服器。

  2. 使用 gdcloud 找出正確的交換器映像檔版本：

    release/gdcloud artifacts tree release/oci/ | grep -i gdch-switch

    輸出內容可能如下列範例所示：

    │   │   │   │   └── gdch-switch/os:1.13.3-gdch.5385

    從這個輸出內容來看，正確的切換按鈕圖片版本是 1.13.3-gdch.5385。

  3. 編輯回報錯誤的 SwitchImageHostRequest 物件：

    kubectl --kubeconfig=<path/to/root-admin-kubeconfig> -n gpc-system edit switchimagehostrequest <SWITCH_IMAGE_HOST_REQUEST_NAME>

  4. 編輯或取代 name、fromVersion 和 toVersion 欄位，以符合預期的切換圖片版本。在本例中，這是指 1.13.3-gdch.5385。 請參閱下列 diff 輸出內容，瞭解對 SwitchImageHostRequest 物件所做的變更。

    kind: SwitchImageHostRequest
metadata:
- name: v1.13.0-pnet-aa505d9004
+ name: 1.13.3-gdch.5385
  namespace: gpc-system
spec:
- fromVersion: v1.13.0-pnet-aa505d9004
+ fromVersion: 1.13.3-gdch.5385
- toVersion: v1.13.0-pnet-aa505d9004
+ toVersion: 1.13.3-gdch.5385

StatefulSet pod 通訊失敗

版本：1.13.1、1.13.3、1.13.4、1.13.5、1.13.6、1.13.7、1.13.8、1.13.9、1.13.10

症狀：由於刪除 Cilium 端點 (CEP) 物件後未正確處理 StatefulSet Pod 重新啟動，導致連線問題或中斷。這可能會導致未受管理的端點身分識別資訊，造成網路政策錯誤地捨棄合法流量。如要確認受影響的 Pod，請檢查對應的 CEP 物件是否不存在：

kubectl get cep -A | grep [*POD_IP*]

解決方法：重新啟動受影響的 StatefulSet Pod，更新其 UID 並重新整理相關中繼資料：

kubectl rollout restart statefulset [*STATEFULSET_NAME*] -n [*NAMESPACE*]

無法連線至 DBS 執行個體

版本：1.13.0、1.13.1

症狀：無法存取資料庫服務 (DBS) 執行個體，資料庫用戶端顯示連線逾時。

這個問題可能會透過依賴 DBS 的其他系統元件浮現。舉例來說，帳單可能會回報下列錯誤訊息：

DBSE0301: Healthcheck: DB cluster is not healthy. Cannot connect to DBdaemon
DBSE0005: DBDaemon Client Error. secure dbdaemon connection failed: context
deadline exceeded

解決方法：失敗原因是網路系統元件無法在機構的服務叢集上排定時間。

  1. 請設定下列環境變數：

    export KUBECONFIG=KUBECONFIG_PATH
export ORG_NAME=ORG_NAME

    更改下列內容：

    • KUBECONFIG_PATH：機構管理員叢集 kubeconfig 檔案的路徑。
    • ORG_NAME：機構名稱，例如 org-1。

  2. 更新網路元件設定，允許排定時間：

    kubectl --kubeconfig=KUBECONFIG_PATH kubectl -n g-ORG_NAME-shared-service-cluster   patch addonconfiguration ang-overrides   --type='json'   -p='[{"op": "replace", "path": "/spec/configs/1/patchContent", "value": "apiVersion: apps/v1\nkind: DaemonSet\nmetadata:\n  name: ang-node\n  namespace: kube-system\nspec:\n  template:\n    spec:\n      containers:\n      - name: angd\n      - name: bgpd\n        env:\n        - name: DISABLE_RECEIVED_ROUTES\n          value: \"true\"\n      tolerations:\n      - operator: \"Exists\"\n        effect: \"NoSchedule\""}]'

網路連線會在幾分鐘後恢復。

叢集網格未設定可用區資訊

版本：1.13.5

症狀：VM 無法連線至同一個專案中的資料庫叢集。與內部負載平衡器的連線受到影響。這個問題是由於叢集名稱設定中缺少區域資訊，導致 Clustermesh 無法在叢集間交換服務物件。

解決方法：在以多區域啟動的環境中，執行下列手動解決方法步驟，讓內部負載平衡器正常運作：

  1. 在機構管理員叢集上，取得可用區名稱：

    ZONENAME="$(kubectl get controlplanes -A -o jsonpath="{.items[0].spec.zone}")"
echo $ZONENAME

    輸出內容可能如下所示：

    zone1

  2. 在機構管理員叢集上，取得區域網站 ID：

    SITEID="$(kubectl -n mz-system get zones $ZONENAME -o jsonpath="{.spec.siteID}")"
echo $SITEID

    輸出內容可能如下所示：

    1

  3. 列出所有叢集：

    ​​kubectl get clusters -A

    輸出內容可能如下所示：

    NAMESPACE                        NAME                     ABM VERSION        DESIRED ABM VERSION   CLUSTER STATE
g-org-1-shared-service-cluster   g-org-1-shared-service   1.30.0-gke.1592    1.30.0-gke.1592       Running
org-1-system-cluster             org-1-system             1.30.0-gke.1592    1.30.0-gke.1592       Running
user-vm-1-cluster                user-vm-1                1.16.11            1.16.11               Running
user-vm-2-cluster                user-vm-2                1.28.700-gke.150   1.28.700-gke.150      Running

  4. 針對每個叢集，建構 CILIUM_CLUSTERNAME：

    CLUSTER_NAME=CLUSTER_NAME
CILIUM_CLUSTERNAME=$CLUSTERNAME-zone$SITEID
echo $CILIUM_CLUSTERNAME

    輸出內容可能如下所示：

    org-1-system-zone1

  5. 為每個叢集設定其他參數，如下所示。以下是 org-1-system 的範例：

    CLUSTER_NAMESPACE=org-1-system-cluster
CLUSTER_VERSION=1.30.0-gke.1592

  6. 為每個叢集建立 AddOnConfiguration 物件，並儲存在 addonconfig.yaml 檔案中。為所有現有叢集和日後建立的任何新叢集建立這個檔案：

    在這個頁面中，請設定下列變數來更新下列程式碼範例：

    CLUSTER_NAMESPACE=CLUSTER_NAMESPACE
CLUSTER_VERSION=CLUSTER_VERSION
CILIUM_CLUSTERNAME=CILIUM_CLUSTERNAME

    apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: AddOnConfiguration
metadata:
  name: cilium-addon
  namespace: CLUSTER_NAMESPACE
spec:
  anthosBareMetalVersions:
  - CLUSTER_VERSION
  configs:
  - name: cilium-config
    namespace: kube-system
    apiVersion: v1
    kind: ConfigMap
    patchContent: |
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cilium-config
        namespace: kube-system
      data:
        cluster-name: CILIUM_CLUSTERNAME

  7. 在機構管理員叢集上套用 addonconfig.yaml：

    kubectl apply -f addonconfig.yaml

  8. 在系統、服務和使用者叢集上，請確保叢集中的 cilium-config 已更新 cluster-name。更新作業可能需要一段時間，但這是重新啟動 clustermesh-apiserver 部署作業前必須完成的步驟。

    kubectl get configmap -n kube-system cilium-config -o jsonpath="{.data.cluster-name}" && echo

  9. 在系統、服務和使用者叢集上，重新啟動部署作業：clustermesh-apiserver

    kubectl rollout restart deployment -n kube-system clustermesh-apiserver

系統產生錯誤的 EVPN IP 位址

版本：1.13.1、1.13.3、1.13.4、1.13.5、1.13.6、1.13.7

症狀：硬體資產管理系統 (HAMS) 產生的多區域 (MZ) EVPN 互連工作階段對等互連 IP 位址，並非以 .65 或 .66 結尾，這是錯誤的行為，會導致 MZ EVPN BGP 工作階段無法建立。

解決辦法：

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

  1. 列出所有 InterconnectSession 資源：

    kubectl get interconnectsession -n gpc-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig | grep zoneevpnpeering

  2. 查看產生的 EVPN 多區域 InterconnectSession 資源，這些資源的 interconnectType 值為 ZonePeering，且 addressFamily 為 EVPN：

    apiVersion: system.private.gdc.goog/v1alpha1
kind: InterconnectSession
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
  creationTimestamp: null
  name: interconnect-session-am-aa-blsw01-zoneevpnpeering-3
  namespace: gpc-system
  labels:
    system.private.gdc.goog/ipv4-session-name-1: interconnect-session-am-aa-blsw01-zoneipv4peering-3
spec:
  interconnectLinkRef:
    name: interconnect-am-aa-blsw01-zoneevpnpeering-3
    namespace: gpc-system
  interconnectType: ZonePeering
  peerIP: 192.168.203.67
  md5HashKey: ""
  peerASN: 65402
  addressFamily: EVPN
status: {}

  3. 針對符合這些參數的每個 InterconnectSession 資源，套用下列修正方式：

    1. 檢查互連網路工作階段自訂資源名稱。
    2. 如果名稱結尾是奇數，請使用下一個步驟中的指令，將對等互連 IP 位址的最後一部分更新為 65。
    3. 如果名稱結尾是偶數，請使用下一個步驟中的指令，將對等互連 IP 位址的最後一部分更新為 66。

  4. 使用不正確的對等互連 IP 位址修改 InterconnectSession 資源：

    kubectl edit interconnectsession
interconnect-session-zy-aa-blsw01-zoneevpnpeering-1 -n gpc-system
--kubeconfig=/root/release/root-admin/root-admin-kubeconfig

  5. 對造成錯誤的所有 InterconnectSession 資源套用這項修正。

上方的網路控制層資訊主頁未顯示任何資料

版本：1.13.7

症狀：TestUpperNetworkingMetrics 中的 Prometheus 查詢失敗，原因是 org-1-system 叢集缺少指標。IO 組織管理員的上層網路控制層資訊主頁中，叢集網格面板不會顯示任何資料。問題源自於 Cilium 和監控系統之間的 source_cluster 標籤不符。

解決方法：從 UNET 控制平面資訊主頁移除 source_cluster 篩選器，即可顯示資料。

網路安裝時顯示的誤導性錯誤

版本：1.13.1

症狀：安裝網路時，系統會顯示一些纜線警告訊息。例如：

  W0725 18:01:19.127111   39319 switch_port.go:59] Got error on getting port speed for la-ac-mgmtsw01:Eth1/46<>la-ac-base03:ilo: no speed associated with cable model: 31342 (CAT6 5ft Black)
  W0725 18:01:19.127127   39319 switch_port.go:59] Got error on getting port speed for la-ac-mgmtsw01:Eth1/33<>la-ac-bm21:LOM1: no speed associated with cable model: 03982 (CAT6 4ft Black)

您可以放心忽略這些錯誤訊息。

建立允許所有輸出 PNP，拒絕非預期流量

版本：

所有版本的 Google Distributed Cloud (GDC) 實體隔離方案都可能受到影響。

症狀：allow-all-egress 專案網路政策 (PNP) 允許流量進入專案內的端點和叢集外的外部端點，但不允許流量進入系統端點。這個問題可能會導致系統和第一方服務存取權遭到封鎖，例如 DNS 解析和物件儲存空間。

allow-all-egress PNP 可能如下所示：

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-all-egress
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - {}

解決方法：刪除 allow-all-egress PNP。預設情況下，一旦停用資料竊取防護機制，流量就能傳輸至叢集和系統端點以外的專案和外部端點。

kubectl delete pnp  [*ALLOW_ALL_EGRESS_PNP_NAME*] -n [*NAMESPACE*]

物件儲存空間

無法刪除儲存空間機構

版本：1.13.1

症狀：由於問題導致 SVM 無法完成刪除作業，因此您可能無法成功刪除機構。您可能會看到類似下方的警告訊息：

Warning StorageOrganizationDeletion 49m (x97
over 23h) StorageOrganization Reconcile error for storage org
deletion: cannot delete storage organization resources, pre-checks failed:
subnet claim "poc2/poc2-admin-svm-mgmt-network-subnet" exists,
cannot continue before it is deleted

部分物件儲存空間升級警告可以忽略

版本：1.13.3

症狀：升級物件儲存空間時，您可能會看到類似以下的警告：

Type     Reason          Age                From                              Message
  ----     ------          ----               ----                              -------
  Warning  ReconcileError  55m (x2 over 55m)  ObjectStorageAdminNodeReconciler  Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: {"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked

解決辦法：

  1. 確認每個節點在祕密中都儲存了對應的 SSH 憑證。

    1. 檢查管理員節點：

      kubectl get objectstorageadminnodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done

    2. 檢查儲存空間節點：

      kubectl get objectstoragestoragenodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done

      成功輸出結果會像以下儲存節點範例：

      NAME                                      TYPE     DATA   AGE
gpcstgecn01-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h
NAME                                      TYPE     DATA   AGE
gpcstgecn02-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h
NAME                                      TYPE     DATA   AGE
gpcstgecn03-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h

      如果找不到密鑰，錯誤訊息會如下所示：

      Error from server (NotFound): secrets "gpcstgeadm02-gce-gpcstgesite01-ssh-creds" not found

  2. 如果指令未傳回任何錯誤，您可以放心忽略協調工具回報的錯誤。

ObjectStorageStorageNodeReconciler 報表 maintenance.gdu.gdu_server_locked

版本：1.13.3

症狀：顯示 objectstoragestoragenode 的詳細資料：

kubectl describe objectstoragestoragenode zv-aa-objs02

輸出內容可能如下列範例所示：

Events:
  Type     Reason          Age                    From                                Message
  ----     ------          ----                   ----                                -------
  Warning  ReconcileError  54m (x2 over 54m)      ObjectStorageStorageNodeReconciler  Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: {"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked"}

解決方法：您可以忽略這個問題。如果收到過多要求，GDU 服務可能會暫時鎖定，但幾分鐘後就會解除鎖定。

Postflight 1.12.x -> 1.13.x 升級物件儲存空間檢查失敗

版本：1.13.x

問題：ObjectStorageUpgrade CR 失敗，並顯示下列錯誤：

Message:               check "ObjectStorageUpgrade" of operable component "OBJ" failed with reason "BackoffLimitExceeded", please check logs in pods: [gpc-system/upgrade-managed-check-objectstorageupgrade] 
Observed Generation:   2
Reason:                PostflightCheckFailed

Pod gpc-system/upgrade-managed-check-objectstorageupgrade 失敗並顯示錯誤

Error: check "ObjectStorageUpgrade" preflight check failed: ObjectStorageSite gce-gpcstgesite01 not ready                                                                      │
  Usage:                                                                                                                                                                         │
    managed [flags]                                                                                                                                                              │
  Flags:                                                                                                                                                                         │
        --component_name string              preflight check name                                                                                                                │
        --current_version string             current version of the Organization                                                                                                 │
    -h, --help                               help for managed                                                                                                                    │
        --organization-upgrade-name string   the name of current OrganizationUpgrade                                                                                             │
        --target_version string              target version of the Organization                                                                                                  │
  F1023 06:18:01.122723       1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: ObjectStorageSite gce-gpcstgesite01 not ready                                   │
  goroutine 1 [running]:

根本原因： 如果未停用或刪除啟動程序 KIND 叢集，將 Object Storage Operational Component 從 1.12.x 升級至 1.13.x 就會失敗。 即使升級成功，由於傳輸層安全標準 (TLS) 憑證驗證錯誤，常見的物件儲存服務 (例如透過 Kubernetes RBAC 建立新的 bucket 或 S3 憑證) 可能會失敗。 這是因為 KIND 叢集內的特定物件儲存空間 Pod 會持續嘗試安裝 StorageGRID 管理端點的 TLS 伺服器憑證，該憑證在 1.12.x 版中有效，但在 1.13.x 版中可能無法辨識。 升級期間，StorageGRID 會安裝新的可驗證 TLS 伺服器憑證，但 KIND 叢集 Pod 會將其替換為舊的無效憑證，導致 TLS 憑證錯誤。

解決方法： 必須符合下列條件：

  • 將物件儲存空間從 1.12.x 升級至 1.13.x
  • 啟動叢集 (KIND 叢集) 仍存在

請按照下列步驟操作：

  1. 取得 kubeconfig，該 kubeconfig 具有啟動叢集 (KIND 叢集) 中 ObjectStorageSite 資源的檢視和修改權限。

  2. 為連線至啟動程序叢集 (KIND 叢集) 的 kubectl 設定別名：

    alias kubectlkind="kubectl --kubeconfig <Full path to the kubeconfig of the bootstrapping cluster>

  3. 從啟動程序叢集取得 ObjectStorageSite 自訂資源執行個體。應有一個 ObjectStorageSite 資源執行個體：

    SITENAME=$(kubectlkind get ObjectStorageSite -A -o jsonpath='{.items[0].metadata.name}')

  4. 在 ObjectStorageSite 資源例項中新增物件儲存空間暫停註解：

    kubectlkind annotate ObjectStorageSite "${SITENAME:?}" storagegrid.netapp.storage.private.gdc.goog/paused=true

  5. 確認物件儲存空間暫停註解已新增至 ObjectStorageSite 執行個體：

    kubectlkind get ObjectStorageSite "${SITENAME:?}" -o jsonpath='{.metadata.annotations}' | jq

  6. 取得 kubeconfig，該 kubeconfig 具有根管理員叢集中 ObjectStorageCluster 資源的檢視權限和狀態修補權限。

  7. 為連線至根管理員叢集的 kubectl 設定別名：

    alias kubectlrootadmin="kubectl --kubeconfig <Full path to the kubeconfig of the root admin >"

  8. 檢查根管理員叢集中是否有任何 ObjectStorageCluster 資源執行個體：

    kubectlrootadmin get ObjectStorageCluster

    如果沒有 ObjectStorageCluster 資源執行個體，表示解決方法已完成。您可能需要再次執行物件儲存空間升級程序。

  9. 從啟動叢集中的 ObjectStorageSite 資源狀態取得管理端點網址：

    MGMT_ENDPOINT=$(kubectlkind get ObjectStorageSite -o jsonpath='{.items[0].status.managementAPIEndpointURL}')

  10. 驗證環境變數 $MGMT_ENDPOINT 是否已設定。端點開頭應為 https://：

    echo ${MGMT_ENDPOINT:?}

  11. 只有在根管理叢集中只有一個 ObjectStorageCluster 資源執行個體時，才執行其餘步驟。否則，請再次執行物件儲存空間升級程序：

    kubectlrootadmin patch ObjectStorageCluster <the name of ObjectStorageCluster> --type=merge --subresource status --patch "status: {managementAPIEndpointURL: '${MGMT_ENDPOINT:?}'}"

  12. 重新啟動 gpc-system/obj-infra-cluster-cm Pod：

    kubectlrootadmin rollout restart deployment -n gpc-system obj-infra-cluster-cm-backend-controller

  13. 確認管理端點是否已新增至 ObjectStorageCluster 資源的狀態：

    kubectlrootadmin get ObjectStorageCluster -o jsonpath='{.items[0].status}' | jq

  14. 刪除後續檢查 Kubernetes 工作 gpc-system/upgrade-managed-check-objectstorageupgrade-<random suffix>，重新啟動後續檢查。系統很快就會重新建立工作。

無法透過資料網路連上節點

如果 anetd Pod 陷入當機迴圈，就可能發生這種罕見問題。

節點連線不可或缺的核心資源可能會陷入損毀狀態。

本指南將說明這個問題的徵兆，以及解決問題的步驟。

版本：

所有版本的 Google Distributed Cloud (GDC) 實體隔離方案都可能受到影響。

症狀：

如果發生這個問題，您可能會看到下列現象：

  • 節點停滯在 NotReady 狀態
  • 描述節點會顯示 kubelet:kubelet was found unhealthy; repair flag : true 訊息
  • 無法透過資料網路以 SSH 存取節點

解決方法：

請按照下列指示修復每個健康狀態不良的節點：

  1. 取得受影響節點的管理 IP 位址：

    kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get -n gpc-system servers/NODE_NAME -ojsonpath='{.spec.managementNetwork.ips[0]}'

  2. 取得受影響節點的 SSH 存取權。

  3. 使用節點的管理 IP 位址，透過 SSH 連線至節點。

  4. 在節點上執行下列指令，然後關閉 SSH 連線：

    tc filter del dev bond0 egress

  5. 重新啟動受影響節點的叢集 anetd DaemonSet：

    kubectl --kubeconfig AFFECTED_CLUSTER_KUBECONFIG rollout restart ds/anetd -n kube-system

    StorageGRID 負載平衡器端點憑證已過期

版本：1.13.10、1.13.11、1.13.12

症狀：物件儲存空間 Proxy 傳回 502 閘道錯誤。

解決方法：請按照 OBJ T0003 操作。

作業系統

Pod 停滯在 init 狀態

版本：1.13.1

症狀：節點回報已就緒，但 SSH 存取節點的速度緩慢，且 top -n 1 顯示的無效程序數超過 100 個。

解決辦法：

  1. 請按照 OS-P0001 的步驟排空伺服器。電池耗盡可能需要 20 分鐘以上。如果一小時後仍無法順利放電，請繼續下一個步驟。

  2. 建立伺服器的 SSH 連線，然後發出下列指令，重新啟動伺服器：

    systemctl reboot

  3. 可能需要再次重新啟動伺服器，才能完全復原。

  4. 確認 SSH 存取不再緩慢，且無效程序數量大幅減少，最好少於 30 個。

  5. 在伺服器上將 maintenance 設為 false，即可取消排空伺服器。

bm-system-machine-preflight-check 裸機或 VM 節點的 Ansible 工作失敗

版本：1.13.1

症狀：重新啟動後，核心模組 nf_tables 未載入，導致叢集 Ansible 工作失敗，並出現 Either ip_tables or nf_tables kernel module must be loaded 錯誤。如果裸機或 VM 節點在完全佈建完成前重新啟動，就會發生這個問題。Ansible 工作可能會擲回類似以下的錯誤：

fatal: [172.20.128.23]: FAILED! => {"changed": false, "msg": "following are the error messages for each failed preflight check {'check_netw
orking_kernel_module_pass': 'Either ip_tables or nf_tables kernel module must be loaded. Use the command \"modprobe <ip_tables OR nf_tables
>\" to load the module.'}"}

解決方法：

建立與節點的 SSH 連線，然後執行下列指令：

modprobe nf_tables

裝置空間不足的 VM

版本：1.13.1、1.13.3、1.13.4、1.13.5

症狀：如果記錄目錄 /var/log 已滿，Node 可能會停留在 NotReady 狀態，且 Pod 可能會因 no space left on device 錯誤而無法啟動。如要檢查，請在節點上執行下列指令，並確認用量是否接近 100%。

df -h /var/log
Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/rocky-rl--var_log   15G   15G   20K 100% /var/log

解決辦法：

  1. 登入發生問題的節點，並清除 /var/log/messages 的舊記錄檔封存檔。

    find /var/log -name "messages*" -mtime +4 -delete

    此外，建議您繼續套用下列解決方法，防止問題再次發生。因應措施是建立 AnsiblePlaybook，並透過自訂 OSPolicy CR 套用變更，負責安全地設定目標 OS (BM+VM 機器)。詳情請參閱程序 OS-P0005。

  2. 請設定下列環境變數：

    export KUBECONFIG=<the path to the kubeconfig file>

  3. 為解決方法建立 Ansible Playbook：

    kubectl --kubeconfig=${KUBECONFIG:?must be set} apply -f - <<EOF
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
  name: update-logrotate
  namespace: gpc-system
spec:
  playbook: |
    - name: Set the default context for the /etc/kubernetes path to etc_t
      hosts: all
      gather_facts: no
      tasks:
        - name: Change log rotation for /var/log/messages
          block:
            - name: Check if /etc/logrotate.d/syslog exists
              check_mode: false
              ansible.builtin.stat:
                path: '/etc/logrotate.d/syslog'
              register: syslog_exists
            - name: Comment out /var/log/messages lines in syslog
              ansible.builtin.replace:
                path: '/etc/logrotate.d/syslog'
                regexp: '^/var/log/messages'
                replace: '# /var/log/messages'
              when: syslog_exists.stat.exists
            - name: Change logrotate config for /var/log/messages
              ansible.builtin.blockinfile:
                path: '/etc/logrotate.d/syslog'
                block: |
                  /var/log/messages
                  {
                      daily
                      rotate 4
                      missingok
                      notifempty
                      sharedscripts
                      postrotate
                          /usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
                      endscript
                  }
              when: syslog_exists.stat.exists
EOF

  4. 找出需要套用變更的目標目錄，目標可以是個別 InventoryMachine 或 NodePool。請參閱程序 OS-P0005 (2. 識別執行階段設定的目標目錄) 的詳細資料。

    下列 OSPolicy 範例在 spec.inventory 下方包含兩個目標廣告空間，您可以視需要新增更多廣告空間。

    kubectl --kubeconfig=${KUBECONFIG:?must be set} apply -f - <<EOF
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
  name: manual-update-logrotate
  namespace: gpc-system
spec:
  inventory:
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    name: control-plane-node-pool
    namespace: org-1-system-cluster
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    name: control-plane-node-pool
    namespace: user-vm-1-cluster
  policy:
    installPlaybook:
      name: update-logrotate
EOF

  5. 驗證

    請參閱程序 OS-P0005 (驗證)，追蹤政策執行狀態。

Pod 停滯在 ContainerCreating 狀態

版本：1.13.3、1.13.5、1.13.6

症狀：節點顯示為正常，但有許多 Pod 處於 ContainerCreating 狀態，且您無法建立與伺服器的 SSH 連線。

解決方法：重新啟動伺服器，並確認節點恢復運作後，你可以建立 SSH 連線。

無法透過 SSH 連線至已佈建的節點

版本：1.13.5

症狀：節點已佈建，但管理和資料 IP 的 SSH 都逾時。

解決方法：透過 iLO 重新啟動節點。啟動後，請透過 SSH 登入並使用 systemctl stop clamonacc; systemctl disable clamonacc 停用 clamonacc。

由於安全啟動無法辨識 OS 簽章，因此 Bare Metal 節點無法從最新的 OS 映像檔啟動

版本：1.13.12

症狀：升級至 1.13.12 版後，如果節點重新啟動，OS 就無法啟動新核心。iLO 控制台畫面會顯示與安全啟動相關的問題：

../../grub-core/loader/i386/efi/linux.c:385:(hd0,gpt2)/vmlinuz-4.18.0-425.131.e.18.ciqfipscompliant.40.1.x86_64 has invalid signature,..:
 ../../grub-core/loader/i386/efi/linux.c:256: you need to load the kernel first.

解決辦法：

  1. 如果節點因這個問題而無法啟動，請透過 iLO 控制台進入 GRUB 畫面，然後選取 Rocky Linux 4.18.0-425.131.e.18.ciqfipscompliant.38.1.x86_64 做為啟動目標。這個程序會讓節點啟動先前的已知良好核心。

  2. 如果所有裸機伺服器都升級至 GDC 1.13.12 版，請執行下列步驟，避免啟動失敗：

    1. 建立與伺服器的 SSH 連線。
    2. 在伺服器上執行下列指令，移除有問題的 Kernel：
    dnf remove kernel-core-4.18.0-425.131.e.18.ciqfipscompliant.40.1.x86_64
    1. 確認預設核心已成功恢復為已知正常版本：
    grubby --default-kernel

結果為 /boot/vmlinuz-4.18.0-425.131.e.18.ciqfipscompliant.38.1.x86_64。

作業套件基礎架構 (OI)

硬體 3.0 不需 SSA

Hardware 3.0 的 RAID 轉接器設定不同。Hardware 3.0 OIC 伺服器使用自行加密的硬碟，因此不再需要啟動 Smart Storage Administration (SSA)。您必須完成額外步驟，才能判斷每個伺服器的磁碟 ID。請參閱「OI 伺服器啟動」。

周邊安全

機構啟動期間，機構系統叢集卡住

版本：1.13.1

症狀：機構啟動期間，機構系統叢集可能會停滯。edr-sidecar-injector 個 Pod 處於待處理狀態。嘗試刪除這些 Pod 時，您可能會看到類似以下的錯誤訊息：

Delete failed with `Internal error occurred: failed calling webhook "validation.gatekeeper.sh": failed to call webhook: Post "https://gatekeeper-webhook-service.opa-system.svc:443/v1/"

同時，其他待處理的 Pod 可能會顯示類似這樣的錯誤訊息：

Error creating: Internal error occurred: failed calling webhook "edr-sidecar-injector.gpc-system.internal": failed to call webhook: Post "https://edr-sidecar-injector.gpc-system.svc:443/mutate?timeout=10s": dial tcp 172.20.3.222:443: connect: connection refused

系統需要手動介入才能解鎖。

解決辦法：

  1. 在系統叢集上複製 MutatingWebhookConfiguration CR edr-sidecar-injector-webhook-cfg。
  2. 在系統叢集上複製 ValidatingWebhookConfiguration CR gatekeeper-validating-webhook-configuration。
  3. 從系統叢集中刪除 edr-sidecar-injector-webhook-cfg CR 和 gatekeeper-validating-webhook-configuration CR。
  4. 等待 edr-sidecar-injector Pod 和 gatekeeper-controller-manager 重新啟動。
  5. 使用 kubectl apply 指令還原 Webhook CR。

PANW 防火牆位址群組不會隨著 CIDR 聲明變更而更新

版本：1.13.1

症狀：在啟動期間，OCIT cidr-claim 會更新為正確值，但防火牆 AddressGroups 不會。一對 AddressGroups，具體來說是 vsys1-root-ocit-network-cidr-group 和 ocvsys1-root-ocit-network-cidr-group，使用與 OIR 實際使用的網路區塊不重疊的網路區塊。OIR 無法解析 GDC 區域記錄，且查詢逾時，沒有收到任何回應。

解決方法： cidr-claim 變更後，請在根管理員叢集的 fw-system 命名空間中重新啟動 fw-core-backend-controller 部署作業，確保 AddressGroup 已更新為最新的 cidr-claim。

實體伺服器

HPE 伺服器發生 POST 問題，導致伺服器啟動失敗

版本：1.13.1

症狀：伺服器無法通過 POST 啟動程序，導致伺服器啟動失敗。登入 ILO 並檢查伺服器控制台時，會顯示下列錯誤：

Symptom: An Invalid Opcode Exception has occurred indicating
that the processor tried to execute an invalid, undefined opcode,
or an instruction with invalid prefixes.

Causes: This issue is typically a software or firmware issue and
not indicative of a hardware problem

Causes: This issue is typically a software or firmware issue and
not indicative of a hardware problem.

ACTION : Reboot the server.

解決方法：

在 iLO 中按一下「電源按鈕」，然後選取 Cold Boot。

伺服器卡在佈建狀態

版本：1.13.1、1.13.3、1.13.5

症狀：伺服器在伺服器啟動期間停滯在佈建狀態。檢查伺服器狀態：

k get servers -A | grep -v availabl

輸出內容可能如下所示：

NAMESPACE    NAME         AGE   RACK    MACHINE-CLASS               MANAGEMENT-IP   DATA-IP    DATA-IP   BMC-IP           CLUSTER   NODEPOOL   STATE          PROVISION-READY
gpc-system   ag-aa-bm01   21h   ag-aa   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.0         203.0.113.0                         provisioning
gpc-system   ag-ab-bm01   21h   ag-ab   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.1         203.0.113.0                         provisioned    true
gpc-system   ag-ac-bm01   21h   ag-ac   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.2         203.0.113.0                         provisioning

解決辦法：

  1. 使用從 KIND 叢集下載的設定，手動啟動 dhcp。在本例中，/tmp/dhcp.conf 是 KIND 叢集的 DHCP 設定：

    docker run  -d -it --network host --name dnsmasq -v /tmp/dhcp.conf:/etc/dnsmasq.conf --cap-add=NET_ADMIN --restart always 198.51.100.255/gpc-system-container-images/private-cloud-staging/dnsmasq:VERSION

    如「Manual File component upgrade for Root & Org Admin Clusters」一文的升級說明所述，將 VERSION 替換為發布版本，例如 1.13.1-gdch.525。

  2. 檢查伺服器上的 BIOS 設定，確認資料層 NIC (以 Slot{i}Nic{i} 模式命名) 未啟用 NetworkBoot。

  3. 透過 API 呼叫檢查 BIOS：

    curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios -u $bmcUser:$bmcPassword

    其中 $bmcUser 和 $bmcPassword 是 ILO 的密碼，可在名為 bmc-credentials-<server-name> 的密碼 (例如 bmc-credentials-ai-aa-bm01) 中的 cellcfg 檔案或目錄中找到。確認這項指令的輸出內容顯示 Slot1Nic1: Disabled。

  4. 如果其中任何一個 Slot{i}Nic{i} 具有 NetworkBoot，請使用 BIOS 設定 API 停用。

    curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios/settings -u $bmcUser:$bmcPassword -X PATCH -d '{"Attributes": {"Slot{i}Nic{i}":"Disabled"}}' -H 'content-type: application/json'

    將 Slot{i}Nic{i} 替換為酬載中發生問題的時段名稱。

  5. 重新啟動伺服器。

DL380a 伺服器無法佈建

版本：1.13.3、1.13.4、1.13.5

症狀：HPE DL380a 型號的加密工作伺服器佈建失敗。伺服器 CR 的狀態在伺服器啟動期間停滯在 available：

# server name
export SERVER_NAME=

kubectl --kubeconfig "${KUBECONFIG:?must be set}" get servers ${SERVER_NAME} -n gpc-system

解決方法：

  1. 按照 IAM-R0004 產生 root-admin-cluster 的 KUBECONFIG。

  2. 按照 PLATAUTH-G0001 產生 CLUSTER_NS=root 的 SSH 金鑰 root-id_rsa。

  3. 將註解 server.system.private.gdc.goog/paused 新增至伺服器自訂資源，暫停伺服器：

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" annotate server ${SERVER_NAME:?} -n gpc-system --overwrite server.system.private.gdc.goog/paused=''

  4. 透過管理 IP 登入伺服器：

    export MGMT_IP=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -o=jsonpath='{.spec.managementNetwork.ips[0]}')

ssh $MGMT_IP -i ~/.ssh/root-id_rsa

  5. 手動啟用加密：

    /opt/MegaRAID/storcli/storcli64 /call/eall/sall secureerase force

/opt/MegaRAID/storcli/storcli64 /c0 delete securitykey

/opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j

    指令輸出內容應如下所示：

    root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /call/eall/sall secureerase force
CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = Drive Secure Erase Succeeded.

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 delete securitykey
CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = None

Controller Properties :
=====================

------------------------
Ctrl Method     Result
------------------------
  0 delete Key Success
------------------------

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j
{
"Controllers":[
{
        "Command Status" : {
                "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
                "Operating system" : "Linux 5.4.0-1072-fips",
                "Controller" : 0,
                "Status" : "Success",
                "Description" : "None"
        },
        "Response Data" : {
                "Controller Properties" : [
                        {
                                "Ctrl" : 0,
                                "Method" : "Set Security using EKMS",
                                "Result" : "Please reboot the system for the changes to take effect"
                        }
                ]
        }
}
]
}

    如果發現上一個指令未成功執行，或看到「Invalid BIOS EKM status」等錯誤訊息，請嘗試重新啟動伺服器和 iLO，然後重新執行這個步驟。

    root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j
{
"Controllers":[
{
        "Command Status" : {
                "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
                "Operating system" : "Linux 5.4.0-1072-fips",
                "Controller" : 0,
                "Status" : "Failure",
                "Description" : "None",
                "Detailed Status" : [
                        {
                                "Ctrl" : 0,
                                "Method" : "Set Security using EKMS",
                                "Result" : "-",
                                "ErrMsg" : "Invalid BIOS EKM status",
                                "ErrCd" : 255
                        }
                ]
        }
}
]
}

    如果最後一個指令成功執行，請按照指示重新啟動伺服器。

  6. 手動建立邏輯磁碟機：

    伺服器完成重新啟動後，請再次從管理 IP 登入伺服器，並列出所有可用磁碟機：

    ssh $MGMT_IP -i ~/.ssh/root-id_rsa

/opt/MegaRAID/storcli/storcli64 /c0 show j

    上一個指令的輸出內容可能如下所示：

    {
  "Controllers":[
  {
    "Command Status" : {
      "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
      "Operating system" : "Linux 5.4.0-1072-fips",
      "Controller" : 0,
      "Status" : "Success",
      "Description" : "None"
    },
    "Response Data" : {
      "Product Name" : "HPE MR416i-o Gen11",
      "Serial Number" : "******",
      "PCI Slot Number" : 17,
      "SAS Address" : "******",
      "PCI Address" : "00:12:00:00",
      "System Time" : "09/12/2024 23:32:48",
      "Mfg. Date" : "09/15/23",
      "Controller Time" : "09/12/2024 23:32:47",
      "FW Package Build" : "52.26.3-5379",
      "BIOS Version" : "7.26.00.0_0x071A0000",
      "FW Version" : "5.260.03-3985",
      "Driver Name" : "megaraid_sas",
      "Driver Version" : "07.713.01.00-rc1",
      "Current Personality" : "RAID-Mode ",
      "Vendor Id" : 4096,
      "Device Id" : 4322,
      "SubVendor Id" : 5520,
      "SubDevice Id" : 808,
      "Host Interface" : "PCI-E",
      "Device Interface" : "SAS-12G",
      "Bus Number" : 18,
      "Device Number" : 0,
      "Function Number" : 0,
      "Domain ID" : 0,
      "Security Protocol" : "SPDM-1.0.0",
      "Physical Drives" : 8,
      "Drive LIST" : [
        {
          "EID:Slt" : "252:1",
          "DID" : 0,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "1.60 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "MO001600PXVRU   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:2",
          "DID" : 1,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "1.60 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "MO001600PXVRU   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:3",
          "DID" : 2,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:4",
          "DID" : 3,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:5",
          "DID" : 4,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:6",
          "DID" : 5,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:7",
          "DID" : 6,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:8",
          "DID" : 7,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        }
      ],
      "Enclosures" : 1,
      "Enclosure LIST" : [
        {
          "EID" : 252,
          "State" : "OK",
          "Slots" : 8,
          "PD" : 8,
          "PS" : 0,
          "Fans" : 0,
          "TSs" : 0,
          "Alms" : 0,
          "SIM" : 0,
          "Port#" : "2I"
        }
      ]
    }
  }
  ]
}

    您應儲存 2 個 EID:Slt ID，且 Size 等於 1.60 TB，在此情況下：

    252:1,252:2

    然後使用 EID:Slt ID 建立邏輯磁碟機：

    /opt/MegaRAID/storcli/storcli64 /c0 add vd type=raid1 drives=252:1,252:2 SED

    上一個指令的輸出內容如下列範例所示：

    /opt/MegaRAID/storcli/storcli64 /c0 add vd type=raid1 drives=252:1,252:2 SED

CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = Add LD Succeeded.

  7. 在伺服器 CR 中模擬磁碟加密狀態。

    編輯 Server CR 的狀態：

    kubectl edit-status --kubeconfig "${KUBECONFIG:?must be set}" server ${SERVER_NAME:?} -n gpc-system

    將 DiskEncryptionEnabled 狀態新增或修改為 true：

      - lastTransitionTime: "<time>"
    message: ""
    observedGeneration: 1
    reason: DiskEncryptionJobSucceeded
    status: "True"
    type: DiskEncryptionEnabled

  8. 刪除伺服器加密工作 (如有)：

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" delete job server-encrypt-and-create-logical-drive-${SERVER_NAME:?} -n gpc-system

  9. 取消暫停伺服器，以便繼續佈建：

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" annotate server ${SERVER_NAME:?} -n gpc-system --overwrite server.system.private.gdc.goog/paused-

沒有授權就無法安全清除資料

版本：1.13.5

徵兆：如果伺服器在安裝期間停止運作，您可能會在伺服器 CR 上看到類似下列的狀態：

- lastTransitionTime: "2024-09-10T20:28:33Z"
   message: 'unable to trigger secure erase: unable to complete secure erase
     for server "zx-ad-bm07": failed to post payload to /redfish/v1/Systems/1/Actions/Oem/Hpe/HpeComputerSystemExt.SecureSystemErase:
     400: {"error":{"code":"iLO.0.10.ExtendedInfo","message":"See @Message.ExtendedInfo
     for more information.","@Message.ExtendedInfo":[{"MessageId":"iLO.2.27.LicenseKeyRequired"}]}}'
   reason: Succeeded
   status: "False"
   type: BMCConfigPreinstallSecureEraseTriggered

解決方法：請按照 SERV-R0014 執行手冊中的指示操作。

平台安全性

BYO SubCA 調解器不會驗證憑證是否具有相符的公開金鑰

版本：1.13.1

症狀：當 PKI BYO SubCA 模式產生新的憑證簽署要求 (CSR)，且先前簽署的憑證已上傳至 SubCA 時，協調器不會檢查新的 CSR 是否與舊的簽署憑證相符，並將 cert-manager CertificateRequest 自訂資源 (CR) 標示為 Ready。這會在 SubCA 憑證更新或手動輪替期間發生。cert-manager 控制器嘗試更新 Certificate CR 狀態，但觸發了下列錯誤訊息：

The certificate request has failed to complete and will be retried: Error signing certificate: error creating x509 │
│  certificate: x509: provided PrivateKey doesn't match parent's PublicKey

解決方法：

按照操作說明，為新的 CSR上傳新的已簽署 BYO SubCA 憑證。

cert-manager 問題導致無法透過 ACME 成功核發 PKI BYO

版本：1.13.1

症狀：使用自動化憑證管理環境 (ACME) 首次核發或更新自備憑證時發生失敗。執行指令檢查憑證狀態時，您會看到憑證為 not ready：

kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert

輸出看起來類似以下內容：

status:
  conditions:
  - lastTransitionTime: "2024-07-23T17:27:02Z"
    message: 'reconciling Certificate status failed: cert-manager Certificate CR "default-wildcard-cert-pki-ct"/"pki-system" is not ready'
    observedGeneration: 1
    reason: ReconcileBackoff
    status: "False"
    type: Ready

解決方法：

在機構管理員叢集中重新啟動 cert-manager 部署作業：

export KUBECONFIG=ORG_ADMIN_KUBECONFIG

kubectl rollout restart deployment/cert-manager -n cert-manager

Resource Manager

無法透過 GDC 控制台查看專案狀態

版本：1.13.1 以上

症狀：GDC 控制台不會顯示專案狀態。 如果專案不處於 Ready 狀態，就無法支援新資源或處理現有資源的新修改內容。由於無法確認專案狀態，因此不清楚何時可以管理專案資源，導致嘗試執行新的專案動作時發生錯誤。

解決方法：請參閱 RM-R0100 執行手冊，使用 kubectl CLI 列印專案狀態。

升級

「bm-system」和其他工作停滯

版本：1.13.1

症狀：執行 Ansible Playbook 的 bm-system 和其他工作停滯在 gathering facts。

解決方法：輸入卡住的節點名稱，然後執行 multipath -ll | grep failed 和 multipath -ll | grep #。如果結果不為空，請按照 Runbook FILE R0020 和 FILE R0021 操作。

無法連上管理 IP

版本：1.13.1、1.13.3、1.13.4、1.13.5

症狀：升級期間，伺服器的管理 IP 無法連線，特別是在交換器之後。

使用 Rocky Linux 新增靜態路徑時，必須先連上用於連線至靜態路徑的目的地 IP，才能新增靜態路徑。如果交換器在作業系統升級後重新啟動，管理 IP 可能暫時無法連線。

解決方法：使用資料 IP 位址建立伺服器的 SSH 連線，然後重新啟動網路服務，重新建立缺少的靜態路由：

systemctl restart NetworkManager.service

系統不會顯示 storagecluster 的版本號碼

版本：1.13.3

症狀：升級後，StorageCluster CR 的 StorageVersion 狀態欄位沒有任何值。

查看版本：

kubectl --kubeconfig <var>ROOT_ADMIN_KUBECONFIG</var> get StorageCluster -n gpc-system

如果版本欄位空白，請按照解決方法中的步驟操作。

解決方法：重新啟動 file-storage-backend-controller 部署作業：

kubectl --kubeconfig  <var>ROOT_ADMIN_KUBECONFIG</var> rollout restart deployment -n file-system file-storage-backend-controller

裸機伺服器停滯在佈建狀態

版本：1.13.1

症狀：

建立機構時，裸機伺服器長時間卡在「佈建」狀態。

解決辦法：

伺服器的 BIOS 設定可能已變更，導致伺服器使用不正確的網路卡進行 Pxebooting。

請按照下列步驟停用資料平面 NIC 網路開機。

  • 必要存取權：
    • 您需要有卡住伺服器的 BMC 管理員憑證存取權。
    • 請按照 IAM-R0005 的指示，在根管理員叢集中取得 ClusterRole hardware-admin 角色 1 小時。
    • 按照 IAM-R0004 產生根管理員叢集的 KUBECONFIG。

  1. 設定停滯伺服器的名稱。

    export SERVER_NAME=

  2. 設定伺服器 BMC 的 IP 和憑證。

    export ip=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -ojsonpath='{.spec.bmc.ip}')
export BMC_CREDENTIALS_SECRET=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -ojsonpath='{.spec.bmc.credentialsRef.name}')
export user=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get secret ${BMC_CREDENTIALS_SECRET:?} -n gpc-system -ojsonpath='{.data.username}' | base64 -d)
export pass=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get secret ${BMC_CREDENTIALS_SECRET:?} -n gpc-system -ojsonpath='{.data.password}' | base64 -d)

  3. 找出伺服器上資料平面網路卡的 PCIe 插槽。

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME} -n gpc-system -o jsonpath={.spec.serverHardware.portBond.nicPortNames}

    舉例來說，以下輸出內容表示網路卡安裝在插槽 3。

    ["s3p1","s3p2"]

    設定 PCIEslot 變數：

    export DATA_NIC_SLOT=3

  4. 確認網路開機未停用。

    curl -ks -u $user:$pass https://$ip/redfish/v1/systems/1/bios/settings  | jq .Attributes | grep "Slot${DATA_NIC_SLOT}NicBoot1"

    如果結果是「NetworkBoot」，則需要明確停用。

  5. 使用 BMC 停用資料平面網路卡上的網路開機功能。

    在下列指令中，將「Slot3」替換為實際的運算單元編號。

    curl -k -u "$user":"$pass" -H "Content-Type: application/json" https://$ip/redfish/v1/systems/1/bios/settings/ -X PUT --data '{"Attributes":{"Slot3NicBoot1":"Disabled"}}' | jq

    然後重新啟動裝置。

    curl -k -u "$user":"$pass" -H "Content-Type: application/json" https://$ip/redfish/v1/Systems/1/Actions/ComputerSystem.Reset/ -X POST -d '{"ResetType": "ForceRestart"}' | jq

    伺服器需要 10 到 15 分鐘才能恢復運作，並自動繼續佈建程序。

物件儲存空間升級作業在預檢或後檢期間顯示錯誤

版本：1.13.1

症狀：預檢或後檢失敗，並顯示錯誤訊息。 檢查記錄：

kubectl logs -n gpc-system upgrade-managed-check-objectstorageupgrade-87698-rrjhrW0410

錯誤訊息可能如下所示：

 03:42:05.701163       1 upgrade_check.go:276] 1 error occurred:
      * Group "/rbac.sysstd.role.vm-system.wtwf7txfmbhvujhpxrfampnrkdwqsvzro6i7rmo5tsfst4wbxldq" not ready for RBAC resource {Role vm-system g-vm-image-bucket-reader    }

   Error: check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
      * Bucket "gpc-system/range-read-internal" not ready

  F0410 03:42:05.701901       1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
      * Bucket "gpc-system/range-read-internal" not ready

解決辦法：

  1. 如果錯誤發生在後續檢查期間，且所有其他檢查都順利完成，請略過後續檢查。升級作業重新啟動時，您也必須使用根管理員 kubeconfig 略過前置檢查：

    kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

    舉例來說，如果錯誤發生在 org-1，指令會如下所示：

    kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok

  2. 如果預檢期間發生錯誤，且所有其他預檢都順利完成，請略過預檢：

    kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

    舉例來說，如果錯誤發生在 org-1，指令會如下所示：

    kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok

如果無法套用此解決方法，可能需要多次嘗試。

Helm 升級復原

版本：1.13.3

症狀：Helm 升級問題導致一系列復原作業，無法找到 Certificate 和 ServiceEntry。您可能會看到類似以下的訊息：

REVISION        UPDATED                         STATUS          CHART                                   APP VERSION             DESCRIPTION
91              Thu Jul 18 13:26:42 2024        deployed        iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Upgrade complete
9138            Fri Jul 19 22:21:56 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9139            Fri Jul 19 22:22:04 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9140            Fri Jul 19 22:22:16 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9141            Fri Jul 19 22:22:30 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9142            Fri Jul 19 22:22:35 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9143            Fri Jul 19 22:22:42 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9144            Fri Jul 19 22:22:48 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9145            Fri Jul 19 22:22:56 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9146            Fri Jul 19 22:23:04 2024        failed          iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found

解決方法：按照 OCLCM-R0122 執行手冊中的步驟操作。

由於 dhcp-tftp-core-server Pod 未排空，導致節點升級或 ABM 停滯

版本：1.13.3、1.14.4、1.14.5

症狀：節點升級作業可能會停滯。在裸機狀態中，dhcp-tftp-core-server Pod 不會排空。您可能會看到類似以下的訊息：

bareMetalMachineDrainingStatus:
    currentDrainingStage: SystemCriticalPriorityClass
    podsYetToDrain:
    - name: dhcp-tftp-core-server-7ffcfcbb97-6wlg7
      namespace: dhcp-system
      resourceVersion: "5005530"
      uid: f77826ea-1d57-46ff-a699-f42faa36c1d2

解決方法：強制刪除 dhcp-tftp-core-server-* Pod，然後繼續。指令如下所示：

kubectl delete pod dhcp-tftp-core-server-7ffcfcbb97-6wlg7 -n dhcp-system --force

OrganizationUpgrade 停滯在節點升級階段

版本：1.13.3

症狀：OrganizationUpgrade 停滯在節點升級階段。您可能會看到類似以下的訊息：

  Last Transition Time: 2024-08-27T12:37:40Z
    Message:             observed the following reason: [JobRunning]
    Observed Generation: 614
    Reason:              Unsuccessful
    Status:              Unknown
    Type:                service/Node

解決辦法：

  1. 檢查根叢集中的 upgradetaskrequest CR ka get upgradetaskrequest -n gpc-system。檢查節點是否仍處於執行狀態。確認裝置是否卡在服務工作。

    spec:
    clusterType: service
Last Transition Time: 024-08-27T12:37:40Z
  Message:            job gpc-system/v1.13.0-os-aa505d9004-upg-task-org-1-os-node-upgra-czwwd is running
  Observed Generation: 1
  Reason:              JobRunning
  Status:              Unknown
  Type:                Succeeded

  2. 手動為每個節點集區聲明建立 nodeupgrade CR：

    export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get nodepoolclaims -n g-org-1-shared-service-cluster
NAME                                                     AGE
control-plane-node-pool                                  34d
dbs-billing-system-billing-dbcluster-n2-standard-4-gdc   34d
shared-service-default-worker                            34d

  3. 為每個節點集區聲明建立 nodeupgrade CR。註解 upgrade.private.gdc.goog/target-release-version 的詳細資料必須從目標的 OS CRMD 名稱取得：

    kubectl get crmd  --kubeconfig ${ROOT_ADMIN_KUBECONFIG} | grep "os"
os-1.13.1-gdch.525                     35d
os-v1.13.0-os-4175a6dce6               27d
os-v1.13.0-os-aa505d9004               5d18h

  4. 在註解中使用此處的版本 upgrade.private.gdc.goog/target-release-version：

    kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get crmd os-v1.13.0-os-aa505d9004 -o json | jq -r '.spec.config.vmNodeImage'
rocky-86-1.13-v20240731-1.13-r191

  5. 針對每個 nodepoolclaim 套用下列 yaml：

        apiVersion: upgrade.private.gdc.goog/v1alpha1
    kind: NodeUpgrade
    metadata:
      annotations:
        upgrade.private.gdc.goog/target-release-version: VERSION
      name: NAME
      labels:
        addon.private.gdc.goog/cluster-type: service
      namespace: NAMESPACE
    spec:
      inFlightConf:
        maxConcurrentNodes: 1
      nodePoolClaimRef:
        name: NAME
        namespace: NAMESPACE
      nodeType: Virtual
      software:
        osImage:
          name: NAME
          version: VERSION

  6. 服務叢集節點升級完成後，請將 UpgradeTaskRequest CR 狀態更新為 True，以便機構升級作業進入下一個階段：

        kubectl patch upgradetaskrequest  upg-task-org-1-os-node-upgrade-task-pckxn --type='json' -p='[{"op": "replace", "path": "/status/conditions/0/status", "value": "True"}]' --subresource=status -n gpc-system --kubeconfig /root/release/root-admin/root-admin-kubeconfig

  7. 機構升級作業現在應會進入下一個階段，服務或節點的狀態將為「完成」：

    Last Transition Time: 2024-08-27T22:44:09Z
  Message:             observed the following reason: [JobRunning]
  Observed Generation: 614
  Reason:              Complete
  Status:              True
  Type:                service/Node

核心無法建立容器

版本：1.13.3

症狀：核心無法分配記憶體 cgroup，導致無法建立新容器。

您可能會看到類似以下的訊息：

Conditions:
  Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          Message
  ----                          ------    -----------------                 ------------------                ------                          -------
  FrequentContainerdRestart     False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentContainerdRestart     containerd is functioning properly
  KernelDeadlock                False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   KernelHasNoDeadlock             kernel has no deadlock
  ReadonlyFilesystem            False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   FilesystemIsNotReadOnly         Filesystem is not read-only
  ContainerRuntimeUnhealthy     False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 10:52:30 +0000   ContainerRuntimeIsHealthy       Container runtime on the node is functioning properly
  FrequentUnregisterNetDevice   False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentUnregisterNetDevice   node is functioning properly
  KubeletUnhealthy              False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   KubeletIsHealthy                kubelet on the node is functioning properly
  FrequentKubeletRestart        False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentKubeletRestart        kubelet is functioning properly
  FrequentDockerRestart         False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentDockerRestart         docker is functioning properly
  MemoryPressure                Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  DiskPressure                  Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  PIDPressure                   Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  Ready                         Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.

[root@zv-aa-bm01 ~]# journalctl -u kubelet -f | grep cilium-agent
Aug 29 17:29:47 zv-aa-bm01 kubelet[48625]: E0829 17:29:47.941493   48625 pod_workers.go:1298]
"Error syncing pod, skipping" err="failed to \"StartContainer\" for \"cilium-agent\" with CrashLoopBackOff: \"back-off 5m0s restarting failed container=cilium-agent pod=anetd-pvmz4_kube-system(db55cbd2-36e3-4d20-8c6b-edbb5191232d)\"" pod="kube-system/anetd-pvmz4" podUID="db55cbd2-36e3-4d20-8c6b-edbb5191232d"
Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.

節點使用的 cgroup 數量非常多：

# cat /proc/cgroups | grep memory
memory  12      380360  1

解決辦法：

請按照下列其中一個主題操作：

  1. 在節點上執行 echo 3 > /proc/sys/vm/drop_caches，然後重新啟動 kubelet。
  2. 如果上述方法無效，請嘗試重新啟動節點。

間歇性無法連線至外部叢集 VIP

版本：1.13.3

症狀：間歇性無法連線至外部叢集虛擬 IP (VIP)，例如控制層 VIP、istio-gateway VIP 或 Harbor VIP，導致 dial tcp :: connect: no route to host 錯誤。

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

  1. 連線至根管理員叢集。這個解決方法假設您要對根管理員叢集中的 IP 位址進行偵錯。如果您要偵錯其他 Kubernetes 叢集 (例如機構管理員或機構系統叢集) 的連線問題，請將 KUBECONFIG 值變更為正確的叢集 kubeconfig 路徑。

  2. 目前已知有兩類 IP 可能會受到影響。 檢查邊界閘道通訊協定 (BGP) 是否將 IP 位址通告至機架頂端 (ToR) 交換器：

    • 如果 IP 是 Kubernetes 控制層 IP 位址 (例如 192.0.2.100)，請使用下列指令取得設定資訊：

      KUBECONFIG=KUBECONFIG
kubectl cluster-info
# Kubernetes control plane is running at https://192.0.2.100:443`

      將 KUBECONFIG 替換為根管理員叢集中的 kubeconfig 檔案路徑。

    • 在某些設定中，BGPAdvertisedRoute 自訂資源會定義 IP 位址中的哪些路徑會透過 BGP 通告至其他網路或系統。如果 IP 位址是由BGPAdvertisedRoute自訂資源宣傳，請使用下列指令取得設定資訊：

      TARGET_IP=TARGET_IP_ADDRESS
KUBECONFIG=KUBECONFIG
kubectl get BGPAdvertisedRoute -A --kubeconfig=$KUBECONFIG | grep $TARGET_IP

      將 TARGET_IP_ADDRESS 替換為發生間歇性連線問題的 IP 位址。

  3. 檢查BGPSession自訂資源的狀態。BGPSession 代表 Kubernetes 叢集與外部 BGP 對等互連之間建立的個別 BGP 對等互連工作階段。檢查 BGPAdvertiser Pod 的記錄，並確認所有 BGPSession 資源都處於 Established 狀態：

    KUBECONFIG=KUBECONFIG
kubectl get pods -l app=bgpadvertiser -n kube-system

# Based on the name of pods, check their logs
kubectl logs pod/bgpadvertiser-gpc-adhoc-6a265a03vm-worker-node0-zone1 -n
kube-system --kubeconfig=$KUBECONFIG`

    運作正常的 BGPAdvertiser Pod 輸出內容會包含下列程式碼片段：

    I0904 04:32:19.999906       1 main.go:217] BGP advertiser serving...\
time="2024-09-04T04:32:25Z" level=info msg="Peer Up" Key=10.200.0.1
State=BGP_FSM_OPENCONFIRM Topic=Peer\

  4. 確認連線是否穩定。建立並執行指令碼，檢查連線是否不穩定或間歇性中斷：

    1. 建立指令碼：

      #!/bin/bash

TARGET=$1
CNT=0
for i in {1..100}; do
    output=$(curl --no-progress-meter -k https://$TARGET 2>&1)
    if echo "$output" | grep -q "No route to host"; then
            CNT=$((CNT+ 1))
            echo "Attempt $i: $output"
    fi
    sleep 0.1
done
echo "$CNT out of 100 runs hit No route to host error"

    2. 執行指令碼：

      ./script.sh TARGET_IP_ADDRESS:PORT

      將 PORT 替換為發生問題的通訊埠編號。

      如果連線有問題，您會看到如下所示的輸出內容：

      Attempt 2: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host
Attempt 4: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host
Attempt 7: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host`

  5. 先前的輸出內容確認了問題。檢查 TOR 交換器上的路徑，確認問題是否源自 TOR 交換器設定。

    假設流量因 IP 位址 192.0.2.201 而遭到捨棄，且該 IP 位址是由 BGPAdvertisedRoute 資源放送，請檢查 BGPAdvertisedRoute 資源中的躍點，找出可能的故障點：

    apiVersion: networking.gke.io/v1
kind: BGPAdvertisedRoute
metadata:
  annotations:
    bgploadbalancer.networking.gke.io/servicename: istio-ingressgateway
    bgploadbalancer.networking.gke.io/servicens: istio-system
  creationTimestamp: "2024-08-20T19:03:02Z"
  generation: 150
  name: default-istio-system-istio-ingressgateway-rj2fv
  namespace: kube-system
  ownerReferences:
  - apiVersion: networking.gke.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: BGPLoadBalancer
    name: default
    uid: f681f3e5-c66a-45d6-a3ac-9d7ae26f555f
  resourceVersion: "27133500"
  uid: 8ede0c81-3aba-40ce-a441-4aec334b41bd
spec:
  bgpPeerNames:
  - 192.0.2.6-peer-10.0.1.1
  - 192.0.2.5-peer-10.0.1.0
  - 192.0.2.5-peer-10.0.1.1
  - 192.0.2.6-peer-10.0.1.0
  nextHops:
  - 192.0.2.2
  - 192.0.2.3
  - 192.0.2.4
  prefix: 192.0.2.201/32

  6. 查看 nextHops 欄位中的 IP 位址。找出每個 IP 位址的伺服器名稱。例如：

    - 192.0.2.2 zt-aa-bm08
- 192.0.2.3 zt-aa-bm09
- 192.0.2.4 zt-ab-bm01

  7. 這項輸出內容顯示，下一個躍點是機架 aa 和機架 ab 中的伺服器。登入機架 aa 和 ab 中的 TOR 交換器，並比較兩個機架中的路徑：

    show ip route 192.0.2.201 vrf root-external-vrf

  8. 如果兩個機架中 TOR 交換器的路徑不同，表示您遇到這個問題，而解決方法可減輕問題影響。這個問題的輸出內容如下：

    zt-aa-torsw01# show ip route 192.0.2.201 vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 3/0, all-best
*via 192.0.2.2, [20/0], 1w1d, bgp-65070, external, tag 64513
*via 192.0.2.3, [20/0], 1w1d, bgp-65070, external, tag 64513
*via 192.0.2.4, [20/0], 1w1d, bgp-65070, external, tag 64513

zt-aa-torsw02# sh ip route 192.0.2.201  vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 3/0, all-best
*via 192.0.2.2, [20/0], 1w3d, bgp-65070, external, tag 64513
*via 192.0.2.3, [20/0], 1w3d, bgp-65070, external, tag 64513
*via 192.0.2.4, [20/0], 1w3d, bgp-65070, external, tag 64513

zt-ab-torsw01# show ip route 192.0.2.201 vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 2/0, all-best
*via 10.249.88.2, [200/0], 1w1d, bgp-65070, internal, tag 64513
*via 192.0.2.3, [200/0], 1w1d, bgp-65070, internal, tag 64513

zt-ab-torsw02# sh ip route  192.0.2.201  vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 2/0, all-best
*via 192.0.2.2, [200/0], 1w3d, bgp-65070, internal, tag 64513
*via 192.0.2.3, [200/0], 1w3d, bgp-65070, internal, tag 64513

    在這個輸出內容中，機架 aa 中的路徑處於預期狀態，顯示針對前置字串列出的三個下一個躍點。不過，在機架 ab 中，前置字元只有兩個下一個躍點。當流量要前往前置字元，但雜湊至機架 ab 時，對應至遺失下一個躍點的節點永遠不會收到流量，網路也會發生連線問題。

請按照解決方法操作，緩解這個問題。

解決辦法：

這項解決方法有助於解決 Kubernetes 叢集中特定 IP 位址的間歇性連線問題。

如要解決這個問題，您必須對匯總交換器之間的 BGP 工作階段套用多項設定變更。匯總 (AGG) 交換器會匯總多個 TOR 交換器的流量。請按照下列步驟更新所有必要設定：

  1. 名為 switchstaticconfig 的設定檔代表單一交換器的靜態設定。下載兩個 AGG 切換開關的 switchstaticconfig 檔案：

    export KUBECONFIG=KUBECONFIG
kubectl get switchstaticconfig za-ab-aggsw01-static-config -n gpc-system -oyaml > /tmp/za-ab-aggsw01-static-config.yaml
kubectl get switchstaticconfig za-ac-aggsw01-static-config -n gpc-system -oyaml > /tmp/za-ac-aggsw01-static-config.yaml

  2. 取得環境的自治系統編號 (ASN)：

    root@bootstrapper:/tmp# kubectl get ClusterBGPRouter --kubeconfig KUBECONFIG -A -o yaml | grep networkASN | head -1
    networkASN: 65030

    這項輸出內容會顯示 65030 的 ASN 值。您必須在後續步驟中使用這裡傳回的 ASN 值。

  3. AGG 交換器上的迴路 IP 位址可做為管理、路由和疑難排解的穩定且永遠開啟的位址，即使其他網路連線中斷也沒問題。取得每個 AGG 交換器的迴路 IP 位址：

    root@bootstrapper:~# kubectl get --kubeconfig KUBECONFIG
aggswitchinternal -n gpc-system -o
jsonpath='{range.items[*]}{.metadata.name}{":\t"}{.spec.loopbackIPs}{"\n"}{end}'

    輸出看起來類似以下內容：

    za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]

  4. 更新 za-ab-aggsw01 AGG 交換器的 staticswitchconfig。 將這個程式碼片段新增至 config 區段：

    spec:
  config: |

route-map onlydefault permit 10
match ip address prefix default
router bgp ASN
      neighbor LOOPBACK_ADDRESS
  address-family l2vpn evpn
      route-map onlydefault in

...
    key chain OSPF_AUTH_KEYCHAIN_0
      key 1

    更改下列內容：

    • ASN：上一步的 ASN 值。在本範例中，這個值為 65030。
    • LOOPBACK_ADDRESS：這是 AGG 交換器的迴路 IP 位址 za-ac-aggsw01。在本例中，這個值為 192.0.2.2。

  5. 將相同更新套用至其他 AGG 交換器 za-ac-aggsw01。你必須提供正確的迴路位址。每個交換器的迴路 IP 位址都不相同：

    za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]

  6. 建立並執行與這個步驟中用於診斷問題的指令碼相同的指令碼，確認修正作業是否成功。輸出內容不會顯示任何錯誤訊息。

升級時出現 Incorrect version of Trident 錯誤

版本：1.13.3、1.13.4、1.13.5

症狀：從 1.13.3 以下版本升級時，ontap 會顯示 Incorrect version of Trident 錯誤。您可能會看到類似以下的訊息：

Status:
  Conditions:
  Last Transition Time: 2024-08-27T15:19:07Z
  Message:              Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke5
  Observed Generation:  1
  Reason:               QualificationFailed
  Status:               False
  Type:                 AllComplete
  Events:

解決辦法：

  1. 更新要升級版本的 releasemetadata：

    export KUBECONFIG=<point to ROOT Admin Kubeconfig>
To get the list of all releasemetadata:
`kubectl get releasemetadata`

    輸出內容可能如下所示：

    NAME AGE 1.12.2-gdch.785 24d 1.12.4-gdch.96 13d 1.13.3-gdch.5548 11h

  2. 選擇要升級的版本，如下例所示：

    kubectl get releasemetadata 1.13.3-gdch.5548 -o yaml > releasemetadata.yaml

  3. 將 .yaml 檔案的 fileBlockStorage 區段下方的 tridentVersion 更新為錯誤訊息中提及的版本。如果錯誤訊息如下所示：

    Message: Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke.5

    將 releasemetadata.yaml 中的 tridentVersion 變更為 v23.10.0-gke.5。

    舉例來說，如果原始值為： infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.6，

    請變更為以下值：

    infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.5。

  4. 套用變更：

    kubectl apply -f releasemetadata.yaml

  5. 再次套用 ontap 儲存空間升級。

Pod 無法排程

版本：1.13.3。1.13.4、1.13.5

症狀：在使用者叢集佈建期間，部分 Pod 無法排程。您可能會看到類似以下的訊息：

0/6 nodes are available: 1 Insufficient cpu. preemption: 0/6 nodes are available: 6 No preemption victims found for incoming pod

解決辦法：

調高使用者叢集控制層節點集區的規模：

  kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch addresspoolclaim/control-plane-node-pool -n ${CLUSTER_NAME}-cluster --type=json -p="[{'op': 'replace', 'path': '/spec/size', 'value': 5}]"
  kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch nodepoolclaim/control-plane-node-pool -n ${CLUSTER_NAME}-cluster --type=json -p="[{'op': 'replace', 'path': '/spec/nodeCount', 'value': 5}]"

iac-zoneselection-global 子元件升級失敗

版本：1.13.1

症狀：升級至 1.13.3 時，子元件 iac-zoneselection-global 發生錯誤。您可能會看到類似以下的訊息：

== Subcomponents with failures in root org ===
Sub-Component: iac-zoneselection-global - Reconciliation error: E0100 - deploy: failed to install chart: release iac-zoneselection-global-backend failed, and has been uninstalled due to atomic being set: 1 error occurred:
        * ZoneSelection.location.mz.global.private.gdc.goog "iac" is invalid: spec.resultObjectName: Required value

Events: Type     Reason               Age                   From          Message
----     ------               ----                  ----          -------
Warning  ReconciliationError  119s (x521 over 20h)  Subcomponent  E0100 - deploy: failed to install chart: release iac-zoneselection-global-backend failed, and has been uninstalled due to atomic being set: 1 error occurred:
         * ZoneSelection.location.mz.global.private.gdc.goog "iac" is invalid: spec.resultObjectName: Required value

解決辦法：

升級至 1.13.3 版即可修正錯誤。

升級檢查工作已超過期限

版本：1.12.x、1.13.x

症狀：在機構升級期間，升級檢查會顯示 False 狀態，原因為 DeadlineExceeded。您可能會看到類似以下的訊息：

  Preflight Check:                                                                                                                                                                                                          
    Conditions:                                                                                                                                                                                                             
      Last Transition Time:  2024-10-29T18:57:47Z                                                                                                                                                                           
      Message:               the result has status: False, reason: PreflightCheckFailed, and err: [check "OPAUpgrade" of operable component "OPA" failed with reason "DeadlineExceeded", no existing pods found, check "Arti
actAvailability" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods found, check "PackageValidation" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods foun
d, check "IAMUpgrade" of operable component "IAM" failed with reason "DeadlineExceeded", no existing pods found, check "NodeHealth" of operable component "OS" failed with reason "DeadlineExceeded", no existing pods found
, check "DNSHealth" of operable component "DNS" failed with reason "DeadlineExceeded", no existing pods found, check "AdminClusterCheck" of operable component "UPORC" failed with reason "DeadlineExceeded", no existing po
ds found[]                                                                                                                                                                                                                  
      Observed Generation:   3                                                                                                                                                                                              
      Reason:                PreflightCheckFailed                                                                                                                                                                           
      Status:                False                                                                                                                                                                                          
      Type:                  Succeeded                                                                                                                                                                                      
    Start Time:              2024-10-29T17:57:47Z

解決辦法：

  1. 刪除與升級檢查失敗項目對應的升級檢查工作。
  2. 等待升級檢查作業重新建立。
  3. 查看重新建立的工作記錄，並分類問題。

meta-monitoring 外掛程式失敗，因為 strongswan 位於不同的執行階段目錄中

版本：1.12.x、1.13.x

症狀：升級至 1.13.4 或 1.13.5 時，meta-monitoring 外掛程式會失敗：

kubectl --kubeconfig ORG_ADMIN_KUBECONFIGget addons -A | grep meta-monitoring
org-1-system-cluster                                      meta-monitoring                                      false                                        false                                      1.12.4-gdch.96

檢查外掛程式：

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG get -n org-1-system-cluster addon meta-monitoring -o yaml

條件訊息可能如下所示：

status:
  conditions:
  - lastTransitionTime: "2024-11-19T02:57:30Z"
    message: 'Error occurred during addon installation: failed to rollback chart:
      create: failed to create: Internal error occurred: failed calling webhook "validation.gatekeeper.sh":
      failed to call webhook: Post "https://gatekeeper-webhook-service.opa-system.svc:443/v1/admit?timeout=3s":
      context deadline exceeded'
    observedGeneration: 2
    reason: InstallationError
    status: "False"
    type: Deployed

解決辦法：

  1. 確認 Org System Cluster 中的 BGP 工作階段是否失敗，例如：

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG get bgpsessions -A
NAME                                           LOCAL ASN   PEER ASN   LOCAL IP        PEER IP     STATE   LAST REPORT
10.252.122.10-peer-10.0.1.32-vm-7351eebe       64513       65030      10.252.122.10   10.0.1.32           
10.252.122.10-peer-10.0.1.33-vm-7351eebe       64513       65030      10.252.122.10   10.0.1.33           
10.252.122.11-peer-10.0.1.32-vm-7351eebe       64513       65030      10.252.122.11   10.0.1.32           
10.252.122.11-peer-10.0.1.33-vm-7351eebe       64513       65030      10.252.122.11   10.0.1.33           
172.20.128.3-peer-10.0.1.48-za-aa-bm02-hltg2   64513       65030      172.20.128.3    10.0.1.48           
172.20.128.3-peer-10.0.1.49-za-aa-bm02-hqblq   64513       65030      172.20.128.3    10.0.1.49

  2. 確認 ang-node Pods 卡在 ContainerCreating，例如：

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG get pods -n kube-system -l app=ang-node
NAME                                                 READY   STATUS              RESTARTS        AGE
ang-node-5c6c8                                       0/3     ContainerCreating   0               2d21h
ang-node-6skkl                                       0/3     ContainerCreating   0               2d14h
ang-node-7d7dj                                       0/3     ContainerCreating   0               2d20h
ang-node-9l4xc                                       0/3     ContainerCreating   0               2d17h

    系統會顯示下列錯誤訊息：

    Warning  FailedMount  112s (x2056 over 2d21h)  kubelet  MountVolume.SetUp failed for volume "vici" : hostPath type check failed: /var/run/strongswan is not a directory

  3. 在機構管理員叢集中，對 ang-overrides AddonConfiguration 進行下列變更：

    kubectl --kubeconfig ORG_ADMIN_KUBECONFIG edit addonconfiguration ang-overrides -n org-1-system-cluster

    變更下列項目：

                volumes:
            - hostPath:
                path: /var/run/strongswan
                type: Directory
              name: vici

    變更為下列項目：

                volumes:
            - hostPath:
                path: /var/run
                type: Directory
              name: vici

  4. 大約一分鐘後，確認 ang-node Pod 現在處於 Running 狀態：

    NAME             READY   STATUS    RESTARTS   AGE
ang-node-7hj5q   3/3     Running   0          15s
ang-node-xps2m   3/3     Running   0          34s
ang-node-krx8p   3/3     Running   0          34s
ang-node-cbm1a   3/3     Running   0          34s

  5. 確認 Org System Cluster 中的 BGP 工作階段現在正在執行。

  6. meta-monitoring 外掛程式會繼續進行下一個階段。

根機構升級作業因簽章工作失敗而停滯

版本：1.13.3、1.13.4

症狀：從 1.13.3 升級至 1.13.4 時，您可能會看到類似以下的訊息：

Message:       [the result has status: False, reason: PreflightCheckFailed, and err: check "PackageValidation" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods found, the result has status: Unknown, reason: UpgradeCheckJobsInProgress

解決辦法：

  1. 停用預檢：

    kubectl annotate -n gpc-system organization root upgrade.private.gdc.goog/skip-preflight-check=ok

  2. 刪除失敗的 artifact-signature-verification-*** 工作。

  3. 等待根目錄升級完成。

  4. 選用：如果環境升級至 1.13.4 以上版本，請啟用飛行前檢查。

控制器的版本達到 1.13.4 後，升級時就不會發生這個問題。

租戶機構升級作業在「預檢」階段失敗，並顯示 ErrImagePull

版本：1.13.3

症狀：租戶機構升級作業在預檢階段失敗，並顯示套件驗證 Pod 的 ErrImagePull。您可能會看到類似以下的訊息：

export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get po -n package-validation-system  | grep artifact-signature-verification

Pod 會顯示 ImagePullBackOff 錯誤：

kubectl describe po -n package-validation-system POD_NAME

系統會顯示映像檔提取錯誤，如下列範例所示：

Name:             artifact-signature-verification-20240823224755-4ppkt
Namespace:        package-validation-system
Priority:         0
Service Account:  package-validation
Node:             ak-ab-base02/203.0.113.250
Start Time:       Fri, 23 Aug 2024 22:47:55 +0000
Labels:           batch.kubernetes.io/controller-uid=bf81d5eb-d597-464e-a907-67c1c8a11c11
                  batch.kubernetes.io/job-name=artifact-signature-verification-20240823224755
                  controller-uid=bf81d5eb-d597-464e-a907-67c1c8a11c11
                  job-name=artifact-signature-verification-20240823224755
Annotations:      <none>
Status:           Pending
IP:               203.0.113.255
IPs:
  IP:           203.0.113.255
Controlled By:  Job/artifact-signature-verification-20240823224755
Containers:
  artifact-signature-verification:
    Container ID:
    Image:          gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004
    Image ID:
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       ImagePullBackOff
    Ready:          False
    Restart Count:  0
...
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                     From               Message
  ----     ------     ----                    ----               -------
  Normal   Scheduled  10m                     default-scheduler  Successfully assigned package-validation-system/artifact-signature-verification-20240823224755-4ppkt to ak-ab-base02
  Normal   Pulling    7m25s (x4 over 9m22s)   kubelet            Pulling image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004"
  Warning  Failed     7m14s (x4 over 9m12s)   kubelet            Failed to pull image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": failed to pull and unpack image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": failed to resolve reference "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": unexpected status from HEAD request to https://203.0.113.255/v2/private-cloud-staging/signature-verifier/manifests/v1.13.0-uporc-aa505d9004?ns=gcr.io: 401 Unauthorized
  Warning  Failed     7m14s (x4 over 9m12s)   kubelet            Error: ErrImagePull
  Warning  Failed     7m3s (x6 over 9m11s)    kubelet            Error: ImagePullBackOff
  Normal   BackOff    4m11s (x17 over 9m11s)  kubelet            Back-off pulling image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004"

解決辦法：

略過預檢：

kubectl annotate -n gpc-system organization ORG_NAME \
upgrade.private.gdc.goog/skip-preflight-check=ok

在根機構升級期間找不到 serviceaccount

版本：1.13.8、1.13.9

症狀：升級至 1.13.8 時，如果先前已升級且附加元件已存在，RBAC 的 addon 部署作業就會失敗。症狀可能處於下列其中一個階段：

  1. 預檢或後檢
  2. 任何涉及升級工作的階段，且訊息顯示工作正在執行，即使工作停滯也一樣。status.conditions 訊息表示工作已執行很長一段時間，這代表有問題。

如要檢查升級前檢查是否失敗，請檢查升級機構對應的 OrganizationUpgrade 物件狀態：

  kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml

  1. 如果工作在 PreflightCheck 失敗，可能會顯示類似這樣的失敗訊息或 UpgradeCheckRBACDeploymentInProgress 訊息：

      - lastTransitionTime: "2024-09-27T00:28:21Z"
    message: ""
    observedGeneration: 2
    reason: Unknown
    status: "False"
    type: PreflightCheck

  2. 如果工作在執行工作工作的 AnthosBareMetal (ABM) 階段失敗，系統會顯示下列輸出內容：

    - Last Transition Time:  2024-09-26T19:55:13Z
  message:               observed the following reason: [JobRunning]
  observedGeneration:    3
  reason:                Unsuccessful
  status:                Unknown
  type:                  root-admin/AnthosBareMetal

  3. 如果檢查失敗，upgradecheckrequest CR 會失敗：

    kubectl get upgradecheckrequests -n gpc-system  --kubeconfig /root/release/root-admin/root-admin-kubeconfig

    輸出內容可能如下所示：

    NAME                                   AGE
upgrade-check-root-postflight-xc7p8    6h32m

  4. 如果工作失敗，upgradetaskrequests CR 會失敗：

    kubectl get upgradetaskrequests -n gpc-system  --kubeconfig /root/release/root-admin/root-admin-kubeconfig

    輸出內容可能如下所示：

    NAME                                          AGE
upg-task-org-1-mz-mz-location-upgrade-5n6wp   2d19h

  5. 如果失敗訊息指出查詢服務帳戶時發生 RBAC 錯誤，請檢查是否已部署先前的外掛程式：

    Type     Reason        Age                   From            Message
----     ------        ----                  ----            -------
Warning  FailedCreate  38s (x11 over 5m41s)  job-controller  Error creating: pods "v1.13.0-mz-2837f80328-upg-task-root-mz-mz-location-jkv69-" is forbidden: error looking up service account gpc-system/upgrade-task-mz-sa-v1.13.0-mz-2837f80328: serviceaccount "upgrade-task-mz-sa-v1.13.0-mz-2837f80328" not found

解決方法：

  1. 檢查是否已部署先前的外掛程式：

      Type     Reason        Age                    From            Message
  ----     ------        ----                   ----            -------
  Warning  FailedCreate  4m30s (x101 over 99m)  job-controller  Error creating: pods "v1.13.0-os-2837f80328-upg-task-root-os-node-upgrad-fdblm-" is forbidden: error looking up service account gpc-system/upgrade-task-os-sa-v1.13.0-os-2837f80328: serviceaccount "upgrade-task-os-sa-v1.13.0-os-2837f80328" not foundcount gpc-system/upgrade-task-mz-sa-v1.13.0-mz-2837f80328: serviceaccount "upgrade-task-mz-sa-v1.13.0-mz-2837f80328" not found

  2. 取得相同元件的先前外掛程式 (適用於工作)：upgrade-task-mz

    kubectl get addons -n gpc-system | grep upgrade-task
upgrade-task-mz-lsqzc            true       true    v1.13.0-mz-7cf810d7a5

  3. 刪除這項加購內容：

    kubectl delete addon -n gpc-system upgrade-task-mz-lsqzc upgrade-task-os-px5wj
addon.addon.private.gdc.goog "upgrade-task-mz-lsqzc" deleted

  4. 刪除外掛程式後，請一併刪除對應的 upgradetaskrequest 或 upgradecheckrequest。系統會重新建立該檔案。

    kubectl delete upgradetaskrequest -n gpc-system upgrade-task-mz-lsqzc

  5. 繼續監控新建立的 upgradetaskrequest、upgradecheckrequest 或對應工作。

無法在「shared-service-cluster upgrade」上完成升級

版本：1.13.3

症狀：Anthos Bare Metal 升級作業停滯，且有一或多部 Bare Metal 機器。所有其他裸機都已成功升級，或尚未開始升級。其中一部裸機處於維護模式，但「目前的 ABM 版本」和「所需的 ABM 版本」欄位仍顯示舊版。

請按照 Anthos 裸機的指示，取得叢集的 baremetalmachine 狀態和詳細資料：

kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG}

預期輸出內容：

NAME           CLUSTER                  READY   INSTANCEID                  MACHINE         ABM VERSION        DESIRED ABM VERSION
192.0.2.0      g-org-1-shared-service   true    baremetal://192.0.2.0       192.0.2.0       1.29.300-gke.185   1.29.300-gke.185
192.0.2.18     g-org-1-shared-service   true    baremetal://192.0.2.18      192.0.2.18      1.29.300-gke.185   1.29.300-gke.185
192.0.2.19     g-org-1-shared-service   true    baremetal://192.0.2.19      192.0.2.19      1.29.300-gke.185   1.29.300-gke.185
192.0.2.10     g-org-1-shared-service   true    baremetal://192.0.2.10      192.0.2.10      1.29.300-gke.185   1.29.300-gke.185
192.0.2.22     g-org-1-shared-service   true    baremetal://192.0.2.22      192.0.2.22      1.29.300-gke.185   1.29.300-gke.185
192.0.2.9      g-org-1-shared-service   true    baremetal://192.0.2.9       192.0.2.9       1.29.0-gke.1449    1.29.0-gke.1449 

kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG} ${MACHINE_IP}  -o json | jq '.status.underMaintenance'

預期輸出內容：

true

解決方法：

  1. 將庫存機器移出維護模式：

    export InventoryMachineName=$(kubectl --kubeconfig=${ADMIN_KUBECONFIG} get inventorymachines -A  -o json | jq '.items[] | select(.spec.address=="${MACHINE_IP}") | .metadata.name')
kubectl --kubeconfig "${ADMIN_KUBECONFIG:?}" patch inventorymachine/${InventoryMachineName:?} --type=merge  -p '{"spec": {"maintenance": false}}'

  2. 等待庫存機退出維護模式。這項作業最多可能需要 10 分鐘的時間。

    kubectl --kubeconfig "${ADMIN_KUBECONFIG:?}" wait inventorymachine/${InventoryMachineName} --for=jsonpath=.status.maintenance=true --timeout=600s

  3. 監控裸機，確認機器已更新至所選的 ABM 版本。

    kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG}

無法安裝 system-dashboards 外掛程式

版本：1.13.5

症狀：從 1.12.4 升級至 1.13.5 時，system-dashboards 外掛程式的外掛程式升級失敗：

│ Status:                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                  │
│     Last Transition Time:  2024-10-22T00:34:54Z                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to rollback chart: no ConfigMap with the name "cluster-etcd-platform-obs" found                    │
│     Observed Generation:   2                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                   │
│     Status:                False

解決方法：按照 OCLCM-R0122 執行手冊中的步驟操作。

NodeUpgradeTask CR 停滯在 NodeOSInPlaceUpgradePostProcessingCompleted 條件

版本：1.13.5

症狀：升級至 1.13.5 時，NodeUpgradeTask CR 卡在 NodeOSInPlaceUpgradePostProcessingCompleted 條件。

確認對應的 os-artifact-collector 工作是否已完成。如果工作停滯數小時，系統會顯示下列訊息：

  root@gpc-adhoc-7e017e71vm-bootstrapper-zone1:~# kag logs  os-artifact-collector-bm-45942837-p8hrk-z56gh 
  I1020 22:06:11.844634       1 main.go:30] BuildDate: 2024-10-19T16:54:08Z
  I1020 22:06:11.844695       1 main.go:31] Version: 0.0.0-gdch.1.v3f2043

解決方法：

  1. 刪除工作或 Pod，強制重試。

升級期間，映像檔發布失敗

版本：1.13.5

症狀：從 1.12.4 升級至 1.13.x 時，圖片發布作業失敗：

Error: error uploading the VM image to object storage: failed to upload to object storage: BadRequest: Bad Request
    status code: 400, request id: , host id: 
F1018 02:04:46.191627       1 main.go:88] VM Image Distributor quit: error uploading the VM image to object storage: failed to upload to object storage: BadRequest: Bad Request
    status code: 400, request id: , host id: 
goroutine 1 [running]:

在機構的 gpc-system 中檢查 obj-proxy Pod，確認憑證驗證失敗：

E1021 19:10:31.710076       1 token_source.go:185] Unable to rotate token: failed to initialize aisClient: failed to initialise AIS client: failed to obtain login config from the provided path "https://console.org-1.zone1.google.gdch.test/.well-known/login-config" with error: unable to parse centralized login config file: unsuccessful get request to config URL (https://console.org-1.zone1.google.gdch.test/.well-known/login-config) with error: Get "https://console.org-1.zone1.google.gdch.test/.well-known/login-config": tls: failed to verify certificate: x509: certificate signed by unknown authority

解決方法：

  1. 使用發生失敗的機構的 KUBECONFIG 重新啟動 obj-proxy Pod：

    export KUBECONFIG=<ORG_KUBECONFIG>
kubectl delete pods -n gpc-system -l name=obj-proxy-manager

  2. 檢查 obj-proxy 的記錄：

    kubectl get pods -n gpc-system | grep obj-proxy

    預期的輸出內容如下：

    obj-proxy-gdgzp                                                1/1     Running     0              5d1h
obj-proxy-nhnsm                                                1/1     Running     0              5d1h
obj-proxy-wrxlq                                                1/1     Running     0              5d1h

  3. 檢查可用 Pod 的記錄，例如：

    kubectl logs obj-proxy-gdgzp -n gpc-system

  4. 套用解決方法後，映像檔發布作業應會完成。

使用者叢集升級期間節點發生故障

版本：1.13.3

症狀：使用者叢集升級期間，節點上執行的工作失敗，並顯示類似下列的錯誤訊息：

 Reason: mkdir: cannot create directory '/root/.ansible/tmp/ansible-tmp-1727810181.4584012-29-114086005628321': No space left on device

  1. 登入節點，檢查分區是否已滿：

    df -h /

    輸出內容可能如下所示：

    Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/rocky-rl--root   31G   31G  120K 100% /

  2. 檢查 /etc/kubernetes/tmp 是否佔用大量空間：du -s /etc/kubernetes/tmp。如果 Kubernetes 備份次數超出正常範圍，就會發生這個問題。

解決方法：

  1. 清除「rm -f /etc/kubernetes/tmp/*」上的所有備份：

    df -h /

    輸出內容可能如下所示：

    Filesystem                  Size  Used Avail Use% Mounted on
/dev/m

系統正在重新建立根管理員升級作業，但預檢失敗

版本：1.13.3、1.13.4、1.13.5、1.13.6、1.13.7、1.13.8、1.13.9

問題：預檢失敗，導致根機構無法升級，例如：

│   Preflight Check:                                                                                                                                                             │
│     Conditions:                                                                                                                                                                │
│       Last Transition Time:  2024-10-28T14:17:31Z                                                                                                                              │
│       Message:               [the result has status: False, reason: PreflightCheckFailed, and err: check "ASMStable" of operable component "ASM" failed with reason "BackoffLi │
│ mitExceeded", please check logs in pods: [gpc-system/upgrade-managed-check-asmstable-4dw66-cld74, gpc-system/upgrade-managed-check-asmstable-4dw66-k8xk5, gpc-system/upgrade-m │
│ anaged-check-asmstable-4dw66-wtc6q, gpc-system/upgrade-managed-check-asmstable-4dw66-l9b6v, gpc-system/upgrade-managed-check-asmstable-4dw66-nf62h, gpc-system/upgrade-managed │
│ -check-asmstable-4dw66-6m7p2, gpc-system/upgrade-managed-check-asmstable-4dw66-4mqmb], the result has status: Unknown, reason: UpgradeCheckJobsInProgress, and err: upgrade ch │
│ eck jobs in progress for Operable Components: haas,bil]                                                                                                                        │
│       Observed Generation:   2                                                                                                                                                 │
│       Reason:                PreflightCheckFailed                                                                                                                              │
│       Status:                False                                                                                                                                             │
│       Type:                  Succeeded                                                                                                                                         │
│     Start Time:              2024-10-28T14:46:42Z

根管理員叢集和根管理員的 kubeapiserver 已升級至所選的 abm 版本。

範例：

export KUBECONFIG=<path to root admin kubeconfig>
kubectl describe kubeapiserver root-admin -n root
kubectl get cluster root-admin -n root

kubectl describe kubeapiserver root-admin -n root 的輸出內容範例：

Name:         root-admin
Namespace:    root
Labels:       lcm.private.gdc.goog/cluster-type=root-admin
              lcm.private.gdc.goog/cluster-version=1.29.600-gke.108
              lcm.private.gdc.goog/component-version=v1.13.0-oclcm-f4c190e0f2

kubectl get cluster root-admin -n root 的輸出內容範例：

NAME         ABM VERSION        DESIRED ABM VERSION   CLUSTER STATE
root-admin   1.29.600-gke.108   1.29.600-gke.108      Running

解決方法

套用預檢略過，繼續升級：

export KUBECONFIG=<path to root admin kubeconfig>
kubectl delete organizationupgrade root -n gpc-system && kubectl annotate -n gpc-system organization root upgrade.private.gdc.goog/skip-preflight-check=ok 
kubectl delete organizationupgrade root -n gpc-system

命名空間 platform-obs-obs-system 或 platform-obs 停滯在終止狀態

版本：1.13.5

症狀：升級或啟動期間，外掛程式無法部署，並顯示類似以下的錯誤訊息：

 export KUBECONFIG=ROOT_ADMIN
 kubectl get addon -n org-1 system-alerts system-dashboards

畫面會顯示以下輸出內容：

  NAME                DEPLOYED   READY   VERSION
  system-alerts
  system-dashboards   false      false   1.12.4-gdch.96

如果「已部署」或「就緒」狀態顯示 false 或空白，請檢查相關外掛程式是否有錯誤，例如：

  export KUBECONFIG=ROOT_ADMIN
  kubectl describe addon -n org-1 system-alerts

畫面會顯示以下輸出內容：

  ...
  ... unable to create new content in namespace platform-obs-obs-system because it is being terminated                             
  ...

由於外掛程式嘗試在刪除中的命名空間建立內容，因此遭到封鎖。由於命名空間刪除作業也遭到封鎖，因此這項封鎖會持續存在。

解決方法：

  1. 升級前，請先為專案加上註解，避免遭到刪除：

    export KUBECONFIG=ORG_ADMIN
kubectl annotate project -n gpc-system platform-obs helm.sh/resource-policy="keep"

    畫面會顯示以下輸出內容：

    project.resourcemanager.gdc.goog/platform-obs annotated
kubectl annotate project -n gpc-system platform-obs-obs-system helm.sh/resource-policy="keep"
project.resourcemanager.gdc.goog/platform-obs-obs-system annotated

    如果環境已出現上述症狀，請按照下列解決方法操作：

  2. 由於資源含有終結器，因此系統會封鎖命名空間刪除作業。如要繼續刪除，請使用提供的指令碼移除終結器： 

      export KUBECONFIG=ORG_ADMIN
  function rm_finalizer() {
      export TYPE=$1
      export NS=$2
      RESOURCES=$(kubectl get $TYPE -n $NS --no-headers -o custom-columns=":metadata.name")
      for rc in $RESOURCES; do
          kubectl patch $TYPE $rc -n $NS \
                  --type json \
                  --patch '{"metadata":{"finalizers":[]}}' --type=merge
      done
    }
    rm_finalizer "monitoringrule" "platform-obs-obs-system"
    rm_finalizer "monitoringrule" "platform-obs"
    rm_finalizer "loggingrule" "platform-obs"
```
Note: Use a bash terminal (default on bootstrappers) to run the script.

  3. 等待資源刪除完成。執行指令碼後，請刪除資源和終止命名空間。如果命名空間仍處於終止狀態，您可能需要再次執行指令碼。終止後，系統會自動重新建立命名空間。確認命名空間已重新建立，且處於 ACTIVE 狀態：

      export KUBECONFIG=ORG_ADMIN
  kubectl get namespace platform-obs platform-obs-obs-system

    畫面會顯示以下輸出內容：

      NAME                      STATUS   AGE
  platform-obs              Active   45s
  platform-obs-obs-system   Active   49s

    啟用命名空間後，卡住的附加元件應該會在幾分鐘內完成部署。確認 DEPLOYED 和 READY 狀態現在為 true：

      export KUBECONFIG=ROOT_ADMIN
  kubectl get addon -n org-1 system-alerts system-dashboards

    畫面會顯示以下輸出內容：

      NAME                DEPLOYED   READY   VERSION
  system-alerts       true       true    1.14.0-gdch.143998
  system-dashboards   true       true    1.14.0-gdch.143998

啟動期間，KIND 叢集中的 UPORC 發生當機迴圈

版本：1.13.x

症狀：命名空間 uporc-system 下的 Deployment uporc-root-backend-controller 在 KIND 叢集中發生當機迴圈。

解決方法：

  1. 檢查 ComponentGroupReleaseMetadata 和 ReleaseMetadata 物件是否相符：

    export KUBECONFIG=KIND
kubectl get componentgroupreleasemetadata
kubectl get releasemetadata

    如果物件相符，則不需要替代方法。

  2. 如果物件不相符，請聯絡 UPORC 團隊尋求協助，因為這可能表示有其他潛在問題。

節點升級作業失敗

版本：1.13.6

症狀：節點升級作業在 NodeOSInPlaceUpgradeCompleted 失敗。

  1. 查看 os-upgrade ospolicy 工作的記錄。
  2. 如果記錄中包含的錯誤指出設定檔已損毀，請輸入節點機器並手動檢查檔案內容，確認檔案是否損毀。記錄檔錯誤可能會提及 configparser.DuplicateOptionError 錯誤代碼和 /etc/yum.repos.d/gdch.repo 檔案。

解決方法：只有在確認檔案已毀損時，才手動刪除損壞節點上的毀損 /etc/yum.repos.d/gdch.repo 檔案。

升級的 Ansible 工作會自動重新產生檔案，這是 Ansible Playbook 的一部分。

### NodeUpgradeTask CR is stuck at the NodeOSInPlaceUpgradePostProcessingCompleted condition

版本：1.13.5

症狀：升級至 1.13.5 時，NodeUpgradeTask CR 卡在 NodeOSInPlaceUpgradePostProcessingCompleted 條件。

確認對應的 os-artifact-collector 工作是否已完成。如果工作停滯數小時，系統會顯示下列訊息：

  root@gpc-adhoc-7e017e71vm-bootstrapper-zone1:~# kag logs  os-artifact-collector-bm-45942837-p8hrk-z56gh 
  I1020 22:06:11.844634       1 main.go:30] BuildDate: 2024-10-19T16:54:08Z
  I1020 22:06:11.844695       1 main.go:31] Version: 0.0.0-gdch.1.v3f2043

解決方法：

  1. 刪除工作或 Pod，強制重試。

NodeUpgradeTask CR 停滯在 NodeBIOSFirmwareUpgradeCompleted 條件

版本：1.13.5

症狀：升級至 1.13.5 時，NodeUpgradeTask CR 卡在 NodeBIOSFirmwareUpgradeCompleted 條件。

檢查對應的 NodeBIOSFirmwareUpgradeCompleted 條件是否停滯，並顯示下列條件：

  {
  "lastTransitionTime": "2024-12-03T04:03:37Z",
  "message": "",
  "observedGeneration": 1,
  "reason": "InProgress",
  "status": "False",
  "type": "NodeBIOSFirmwareUpgradeCompleted"
  }

解決方法：

  1. 在 NodeUpgrade CR 中，手動將 "U30 v3.20 (05/29/2024)" 編輯為 "U30 v3.20 (05/27/2024)"。

節點無法進入維護模式，因此叢集升級作業遭到封鎖

版本：1.13.5、1.13.6、1.13.7

症狀：節點無法進入維護模式，導致叢集 (機構組織管理員、系統或使用者叢集) 無法升級。

叢集顯示 MaintenanceMode 設為 true，但執行下列指令時，Status 停滯在 false：

kubectl get baremetalmachines -A -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,MaintenanceMode:.spec.maintenanceMode,Status:.status.underMaintenace

畫面會顯示以下輸出內容：

NAMESPACE           NAME            MaintenanceMode   Status
user-vm-1-cluster   10.8.4.22       true              false
user-vm-1-cluster   10.8.4.23       false             false
user-vm-1-cluster   10.8.4.24       false             false
user-vm-1-cluster   172.20.128.13   false             false
user-vm-1-cluster   172.20.128.14   false             false
user-vm-1-cluster   172.20.128.15   false             false

解決方法：

將 KUBECONFIG 設為包含未排空節點的叢集 kubeconfig 檔案。叢集可以是使用者叢集或共用服務叢集。

for VM in $(kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints --no-headers | grep "baremetal.cluster.gke.io/maintenance" | awk '{print $1}'); do
  for i in {1..50}; do
    kubectl delete po -n kube-system $(kubectl get po -A -o wide  | grep ang | grep -e $VM| awk '{print $2}');
  done
done

初始根目錄 organizationupgrade 期間持續逾時

版本：1.13.3

症狀：如果機構升級期間出現忽略維護期間註解，系統會重複修補 organizationupgrade CR，導致進度重設。

解決方法：

暫停子元件 rm-org，並縮減 rm-org-backend-controller 副本。

  1. 如果未宣告別名，請執行下列指令：

    alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"

  2. 暫停子元件，並縮減 rm-org 的 Deployment 資源：

    kubectl --kubeconfigROOT_ADMIN_KUBECONFIG annotate subcomponent -n root rm-org lcm.private.gdc.goog/paused=true
kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=0

  3. 叢集升級完成後，請縮減部署規模：

    kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=1

子元件 obj-syslog-server 無法在根機構單位中完成對帳

版本：1.13.3、1.13.4、1.13.5、1.13.6

症狀：升級至 1.13.x 版時，發現子元件 obj-syslog-server 處於 ReconciliationError 狀態：

root        obj-syslog-server     ReconciliationError

條件類似於：

Sub-Component: obj-syslog-server - Reconciliation error: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded

Last Transition Time: 2024-09-17T21:49:25Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     ReconciliationError
     Status:True
     Type: Reconciling
     Last Transition Time: 2024-09-17T21:49:23Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     Reason: DeployError
     Status: False
     Type: Deployed

您可能會發現 Pod syslog-server-abcdefg-wxyz 處於 CrashLoopBackOff 狀態，並出現下列錯誤：

       containerID: containerd://65d460176a1dcae412af698fa02fa5ffb0c5f0ef9bf0d0e2111ef88845630827
       exitCode: 128
       finishedAt: "2024-09-18T19:14:45Z"
       message: 'failed to create containerd task: failed to create shim task: OCI
         runtime create failed: runc create failed: unable to start container process:
         error during container init: error mounting "/var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2"
         to rootfs at "/etc/ssl/certs/obs-ca-cert.pem": mount /var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2:/etc/ssl/certs/obs-ca-cert.pem
         (via /proc/self/fd/6), flags: 0x5001: not a directory: unknown'
       reason: StartError
       startedAt: "1970-01-01T00:00:00Z"

解決方法：

如要讓子元件恢復正常狀態，請移除不必要的 volumeMounts。

  1. 編輯目前的部署作業：

    export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig

    kubectl edit deployments syslog-server -n istio-system

  2. 移除 spec.containers.volumeMounts 中不需要的 volumeMounts。移除下列掛接路徑：

        - mountPath: /etc/ssl/certs/obs-ca-cert.pem
      name: observability-ca
      readOnly: true1.
      subPath: ca.crt
    - mountPath: /etc/ssl/certs/obj-ca-cert.pem
      name: obj-ca
      readOnly: true
      subPath: ca.crt

  3. 套用變更後，子元件會回到 ReconciliationCompleted。

ABM 或節點升級作業停滯在 maintenanceMode false

版本：1.13.4

症狀：節點在 Anthos Bare Metal 叢集升級期間停滯，且節點未進入維護模式。

檢查服務叢集節點上的 baremetalmachine，例如：

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
false

解決辦法：

重新啟動 anthos-cluster-operator 以傳播 BMM.MaintenanceMode：

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
true

升級租戶機構的 atat-webhooks 外掛程式時失敗

版本：1.13.5

症狀：atat-webhooks 外掛程式升級失敗，無法復原：

org-1                                         atat-webhooks                                    false                                        false                                     1.13.4-gdch.5582

您可能會看到類似以下的訊息：

Status:                                                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                                                  │
│     Last Transition Time:  2024-10-30T17:57:06Z                                                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to generate parameters for AddOn[atat-webhooks]: failed to generate runtime parameters: parameter job not ready yet                │
│     Observed Generation:   4                                                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                                                   │
│     Status:                False                                                                                                                                                                               │
│     Type:                  Deployed                                                                                                                                                                            │
│     Last Transition Time:  2024-10-30T17:56:36Z                                                                                                                                                                │
│     Message:               Reconciliation error

檢查 Pod 是否有 atat-webhooks-parameters-*****：

kubectl logs -n org-1 atat-webhooks-parameters-***** --kubeconfig ROOT_ADMIN_KUBECONFIG

您可能會看到類似以下的錯誤訊息：

E1030 22:04:33.242244       7 main.go:39] failed to generate parameter for AddOn [atat-webhooks], error: ATAT0003: Organization.resourcemanager.private.gdc.goog "org-1" is invalid: metadata.labels[atat.config.google.com/task-order-number]: Invalid value: "TO1234": The current date 2024-10-30 is not within the valid range of this TaskOrder: 2024-06-30 - 2024-10-30.

解決辦法：

  1. 複製目前的投資組合：

    export KUBECONFIG=ROOT_ADMIN_KUBECONFIG

    kubectl get portfolios -n atat-system portfolio-org-1 -oyaml > portfolio-org-1

  2. 將 portfolio-org-1 Pop End Date 更新為未來的日期：

    kubectl delete portfolios -n atat-system portfolio-org-1

    如果這個指令停止回應，請先從有效組合中刪除 .Metadata.Finalizers 條件，再刪除組合。條件可能如下所示：

    │     portfolio.finalizers.atat.config.google.com

  3. 重新套用複製的 YAML 檔案：

    kubectl apply -f portfolio-org-1

  4. 請仔細檢查日期，確保投資組合和 configmap 都已更新。

  5. 如果工作未復原，請刪除失敗的 atat-webhooks-parameters 工作，系統就會復原。等待完成：

    kubectl delete jobs -n org-1 atat-webhooks-parameters

由於 DeadlineExceeded 或 BackoffLimitExceeded 錯誤，導致後續檢查或升級檢查失敗。

版本：1.13.8

症狀：

從 1.13.7 升級至 1.13.8 時，飛行後檢查仍處於待處理狀態，並顯示 DeadlineExceeded 或 BackoffLimitExceeded 錯誤。

Message:postflight check result: pending, [NodeHealth (OS) HarborClusterHealth (AR)] still running 
Observed Generation: 3
Reason: ReconcileBackoff
Status: Unknown 
Type: ManagedCheckSucceeded 
Last Transition Time: 2025-02-13T02:11:41Z
Message: observed the following failure reasons: [ReconcileBackoff UpgradeCheckJobsInProgress]

解決辦法：

找出工作失敗的原因：

  1. 檢查預檢或後檢期間是否發生工作失敗情形：

    kubectl get jobs -A -l "upgrade.private.gdc.goog/use" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

  2. 檢查升級期間工作是否失敗：

    kubectl get jobs -A -l "upgrade.private.gdc.goog/upgrade-check-owner" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

  3. 刪除工作：

    kubectl delete jobs -n gpc-system CHECK_NAME

升級檢查包含與檢查等級無關的結果

版本：1.13.x

症狀：

如果錯誤納入其他層級的結果，組織升級檢查可能會失敗。舉例來說，根機構檢查可能會顯示租戶機構結果，或租戶機構檢查可能會顯示使用者叢集結果。

根機構單位檢查的失敗記錄範例：

kubectl logs -n gpc-system upgrade-check-postflight-haas-n2rk2-zv9rr --kubeconfig /root/release/root-admin/root-admin-kubeconfig
... {org-1 admin } failure ...

解決辦法：

如要完全略過預檢或後檢，請使用：

預檢：

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

預檢後：

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check=ok

Vertex AI

預先訓練的 API 會在使用者介面中顯示 Enabling 狀態

版本：1.13.1

症狀：建立使用者叢集時，MonitoringTarget 會顯示 Not Ready 狀態，導致預先訓練的 API 持續在使用者介面中顯示 Enabling 狀態。

解決辦法：

  1. 開啟 Chrome 瀏覽器的選單 (三點圖示)。
  2. 依序點選「更多工具」 >「開發人員工具」，開啟控制台。
  3. 按一下控制台的「網路」分頁標籤。
  4. 找出 ai-service-status 要求。
  5. 在 ai-service-status 要求中按一下「回應」分頁，即可顯示該要求的內容。
  6. 確認除了 MonitoringTarget 和 LoggingTarget 元件以外，一切都準備就緒。

Speech-to-Text 的 streaming_recognize 預先訓練 API 函式失敗

版本：1.13.3

症狀：呼叫 Speech-to-Text 的 streaming_recognize 預先訓練 API 函式時，用戶端程式庫發生問題，導致出現類似下列內容的 400 錯誤訊息：

google.api_core.exceptions.InvalidArgument: 400 The header 'x-goog-user-project' should be set

解決方法：使用下列 Python 指令碼，讓 streaming_recognize 函式正常運作：

import base64

from google.cloud import speech_v1p1beta1
from google.cloud.speech_v1p1beta1.services.speech import client
import google.auth
from google.auth.transport import requests
import requests as reqs
from google.api_core.client_options import ClientOptions
import os

audience= "https://ENDPOINT:443"
api_endpoint="ENDPOINT:443"
os.environ["GOOGLE_APPLICATION_CREDENTIALS"] = "APPLICATION_DEFAULT_CREDENTIALS_FILENAME"
os.environ["GRPC_DEFAULT_SSL_ROOTS_FILE_PATH"] = "CERT_NAME"

def get_client(creds):
  opts = ClientOptions(api_endpoint=api_endpoint)
  return client.SpeechClient(credentials=creds, client_options=opts)

def main():
  creds = None
  try:
    creds, project_id = google.auth.default()
    creds = creds.with_gdch_audience(audience)
    sesh = reqs.Session()
    sesh.verify = False
    req = requests.Request(session=sesh)
    creds.refresh(req)
  except Exception as e:
    print("Caught exception" + str(e))
    raise e
  return creds

def speech_func(creds):
  tc = get_client(creds)
  content="[ENCODED CONTENT STRING HERE]"

  audio = speech_v1p1beta1.RecognitionAudio()
  audio.content = base64.standard_b64decode(content)
  config = speech_v1p1beta1.StreamingRecognitionConfig()
  config.config.encoding= speech_v1p1beta1.RecognitionConfig.AudioEncoding.LINEAR16
  config.config.sample_rate_hertz=16000
  config.config.language_code="en-US"
  config.config.audio_channel_count=1

  request_config = speech_v1p1beta1.StreamingRecognizeRequest(
    streaming_config = config,
  )

  request_audio = speech_v1p1beta1.StreamingRecognizeRequest(
    audio_content = audio.content
  )

  requests = [request_config, request_audio]

  def request_generator():
      for request in requests:
          yield request

  metadata = (("x-goog-user-project", "projects/vtx-pretrained"),)
  resp = tc.streaming_recognize(requests=request_generator(), metadata=metadata)

  for response in resp:
    print(response)

if __name__=="__main__":
  creds = main()
  speech_func(creds)

更改下列內容：

Python 指令碼會導入 streaming_recognize 和 recognize 函式的下列差異，讓 streaming_recognize 的解決方法正常運作：

  • 第 4 行：與 recognize 指令碼相比，多了一個 import 陳述式 (from google.cloud.speech_v1p1beta1.services.speech import client)。
  • 第 18 行：用戶端是由 client.SpeechClient() 傳回，而非 speech_v1p1beta1.SpeechClient()。

Translation 前端 Pod 和服務無法初始化

版本：1.11.x、1.12.x、1.13.x

症狀：升級期間，系統會重新建立 Translation DB 叢集，導致 ODS 系統叢集 secret-store 密鑰過時且不同步。因此，翻譯前端 Pod 和服務無法初始化。

解決辦法：

刪除系統叢集中的密鑰：

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n ai-translation-system

將 SYSTEM_CLUSTER_KUBECONFIG 替換為系統叢集中的 kubeconfig 檔案路徑。

控制器會自動重新建立密鑰，並與資料庫叢集重新同步。

batchTranslateDocument API 不支援輪詢工作狀態

版本：1.13.3

症狀：Vertex AI 不支援 Translation 服務 API 中的 GET 和 LIST 作業。呼叫 Translation BatchTranslateDocument API 會傳回類似下列範例的長時間執行作業：

{
  "name": "projects/PROJECT_ID/operations/OPERATION_ID",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.translation.v3.BatchTranslateDocumentMetadata",
    "state": "RUNNING"
  }
}

這是因為 APIP (授權) 限制，導致您無法直接呼叫端點。端點不支援輪詢作業狀態，且由於 APIP 限制，您無法對長時間執行的作業執行 GET 作業。

解決方法：以應用程式運算子 (AO) 身分定期檢查 s3_destination 資料夾，查看工作狀態並尋找新建立的工作輸出檔案。如果資料夾包含輸出檔案，表示工作已順利完成。

batchTranslateDocument 要求可能會導致效能問題

版本：1.13.3

症狀：批次文件翻譯服務會讀取一或多個使用者輸入檔案，並在 StorageGRID 中寫入暫時處理和翻譯的輸出檔案。由於重複使用用戶端會失敗，因此系統會為每個讀寫動作建立新的 curl 用戶端。

二進位檔中的 S3 curl 用戶端為一次性使用，也就是說，每個用戶端只能對 StorageGRID 值區執行單一讀寫動作。因此，每當從 batchTranslateDocument 伺服器建立與 StorageGRID 用戶端的通訊，以讀取和寫入 bucket 中的檔案時，系統都會建立新的 curl 用戶端。

不過，這對 curl 用戶來說並非最佳做法。可能導致下列問題：

  • 效能降低：延遲時間增加，處理量減少
  • 資源耗盡：記憶體和 CPU 負擔，以及通訊端耗盡
  • 伺服器超載：頻率限制或節流

啟用預先訓練的 API 後，GDC 控制台顯示的狀態不一致

版本：1.13.3

症狀：首次啟用預先訓練的 API 時，啟用服務幾分鐘後，GDC 控制台可能會顯示不一致的狀態。即使服務實際上已啟用，GDC 控制台仍會將 Enabling 狀態切換回 Disabled，並在使用者介面上再次顯示「啟用」按鈕。

解決方法：幾分鐘後，狀態就會一致，服務也會反映正確狀態。

如要驗證服務狀態，請開啟瀏覽器控制台的「網路」分頁，然後檢查 ai-service-status 要求狀態。酬載必須顯示已啟用 L2 運算子。

如果翻譯要求超過 250 個字元，translation-prediction-server Pod 會當機

版本：1.13.3

症狀：當您傳送約 250 個半形字元以上的翻譯要求 (包括文件翻譯要求) 時，translation-prediction-0 或 translation-prediction-1 Pod 可能會當機，需要重新載入模型。模型會自動重新載入，這個程序可能需要大約 30 分鐘才能完成。

這是因為翻譯容器有使用限制。

解決方法：將翻譯要求拆開，確保每項要求長度不超過 250 個字元。200 到 250 個字元是所有語言的長度上限。如果長時間的要求導致 Pod 損毀，您無須採取其他行動來解決問題。

共用服務叢集的 GPUAllocation 設定有誤

版本：1.13.3

症狀：由於 GPU 資源不足，Vertex AI 工作負載無法排程。舉例來說，如果無法查看或啟用 Vertex AI 服務端點，可能是因為 GPU 資源不足。

如果共用服務叢集中的部分 GPUAllocation 資源缺少下列註解，就可能導致資源調度問題：

processed: "true"

解決辦法：

  1. 請按照 IAM-R0004，為 g-ORG_NAME-shared-service-cluster 產生 kubeconfig 檔案。

  2. 列出服務叢集中所有沒有 processed: "true" 註解的 GPU 分配項目：

    kubectl get gpuallocations -A -n vm-system \
    --kubeconfig SERVICE_CLUSTER_KUBECONFIG \
    -o json | jq \
    '.items[] | select(.metadata.annotations.processed == null ) | .metadata.name'

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

    zi-ad-bm08

  3. 針對未分配的 GPUAllocation 資源，請在編輯器中開啟：

    kubectl edit gpuallocation -n vm-system NODE_NAME

  4. 根據服務叢集中的 GPU 分配總數，編輯 GPU 分配：

    • 如果只有一個 GPU 分配自訂資源，請將 processed: "true" 註解新增至該資源，並修改其規格，如下所示：

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 4
    profiles:
    - mixed-5
    - uniform-3g.40gb
    - uniform-3g.40gb
    - uniform-7g.80gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

    • 如果有兩個 GPU 分配自訂資源，請找出沒有 processed: "true" 註解的資源，為其新增 processed: "true" 註解，然後將規格修改為如下所示：

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 2
    profiles:
    - mixed-5
    - uniform-3g.40gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

    • 如果有四個 GPU 分配自訂資源，請找出沒有 processed: "true" 註解的資源，為其新增 processed: "true" 註解，並修改規格，使其類似下列規格：

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 1
    profiles:
    - mixed-5
  node: $node_name // unchanged
  pod: 0
  vm: 0

  5. 儲存對 GPUAllocation 自訂資源所做的變更，並確認其分配狀態已更新為 true：

    kubectl get gpuallocations -A --kubeconfig SERVICE_CLUSTER_KUBECONFIG

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

    NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
vm-system   zi-ad-bm08   true        H100L 94GB
vm-system   zi-ad-bm09   true        H100L 94GB

從 1.9.x 版升級至 1.13.3 版時，OCLCM 控制器會顯示錯誤

版本：1.13.3

症狀：從 1.9.x 版升級至 1.13.3 版時，Vertex AI 子元件的可操作元件生命週期管理 (OCLCM) 控制器可能會顯示錯誤。這個問題是由 ai_platform 外掛程式工作發生錯誤所導致。升級期間收到的錯誤訊息表示 OCLCM 無法轉移這些 Vertex AI 元件的擁有權。

以下是機構管理員叢集中受影響的 Vertex AI 元件：

名稱 命名空間
aip-l1operator-deployment ai-system
aip-l2operator-deployment ai-system
aip-web-plugin-frontend ai-system
aip-web-plugin-backend ai-system
aip-l1operator-sa ai-system
aip-l2operator-sa ai-system
aip-web-plugin-sa ai-system
aip-l1operator-role 不適用
aip-l2operator-role 不適用
aip-web-plugin-role 不適用
aip-l1operator-rolebinding 不適用
aip-l2operator-rolebinding 不適用
aip-web-plugin-rolebinding 不適用
aip-l1operator-log ai-system
aip-l2operator-log ai-system
aip-web-plugin-frontend-log ai-system
aip-web-plugin-backend-log ai-system
log-rule-aipl-a004 platform-obs
mon-rule-aipl-a0001 platform-obs
mon-rule-aipl-a0003 platform-obs
aip-l1operator-mon ai-system
aip-l1operator-mon-cm ai-system
aip-l2operator-mon ai-system
aip-l2operator-mon-cm ai-system
aip-l1operator-webhook-svc ai-system
aip-web-plugin-frontend-svc ai-system
aip-web-plugin-backend-svc ai-system
aip-web-plugin-frontend-virtualsvc ai-system
aip-web-plugin-backend-virtualsvc ai-system
aip-l1operator-selfsigned-issuer ai-system
aip-l1operator-serving-cert ai-system
aip-l1operator-validating-webhook ai-system
aip-l1operator-mutating-webhook ai-system

解決方法：如要解決這個問題，您必須從機構管理員叢集中手動移除受影響的 Vertex AI 元件。然後，新版 Vertex AI 會根據 OCLCM 重新安裝這些項目。

在機構管理員叢集中手動移除受影響的 Vertex AI 元件：

kubectl --kubeconfig=ORG_ADMIN_CLUSTER_KUBECONFIG delete deployment -n NAMESPACE COMPONENT_NAME

更改下列內容：

  • ORG_ADMIN_CLUSTER_KUBECONFIG：機構管理員叢集中的 kubeconfig 檔案路徑。
  • NAMESPACE：要移除的 Vertex AI 元件的命名空間。如果元件沒有命名空間，請從指令中移除 -n NAMESPACE。
  • COMPONENT_NAME：要移除的 Vertex AI 元件名稱。

以下範例說明如何移除機構管理員叢集 ai-system 命名空間中的 aip-l1operator-deployment 元件：

kubectl --kubeconfig=ORG-ADMIN-CLUSTER-KUBECONFIG delete deployment -n ai-system aip-l1operator-deployment

翻譯要求可能會產生 RESOURCE_EXHAUSTED 錯誤代碼

版本：1.13.3

症狀：傳送翻譯要求後，您會在回應訊息中收到 RESOURCE_EXHAUSTED 錯誤代碼。如果超出系統頻率限制，就會發生這個錯誤。已耗盡資源，例如每位使用者的配額、每秒查詢次數上限，或是整個檔案系統的空間不足。

解決方法：請基礎架構營運商 (IO) 重新啟動翻譯服務後端分片。然後，再次傳送翻譯要求，但要求間隔時間要更長，或傳送較短的要求。

batchTranslateDocument 要求傳回錯誤 503

版本：1.13.3

症狀：傳送 batchTranslateDocument 要求後，您會在回應訊息中收到 503 "Batch Document translation is not implemented" 錯誤代碼。發生這項錯誤的原因是 BatchTranslateDocument 方法需要 Aspose 服務，而只有在叢集中將 enableRAG 可運作參數設為 true 時，才會部署 Aspose 服務。

解決方法：請基礎架構營運商 (IO) 按照下列步驟，在機構管理叢集中將 enableRAG operable 參數設為 true：

  1. 在名為 vai-translation.yaml 的 YAML 檔案中建立 SubcomponentOverride 自訂資源，並將 enableRAG 可操作參數設為 true：

    apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: "vai-translation"
  namespace: ORG_ADMIN_NAMESPACE
spec:
  subComponentRef: "vai-translation"
  backend:
    operableParameters:
      enableRAG: true

    將 ORG_ADMIN_NAMESPACE 替換為機構管理員叢集的命名空間。

  2. 將 SubcomponentOverride 自訂資源套用至機構管理員叢集：

    kubectl --kubeconfig ORG_ADMIN_KUBECONFIG apply -f vai-translation.yaml

    將 ORG_ADMIN_KUBECONFIG 替換為機構管理員叢集中的 kubeconfig 檔案路徑。

無法使用 Vertex AI 預先訓練服務

版本：1.13.7、1.13.9

症狀：由於 Kubernetes 排程問題，Vertex AI OCR 和 Translation 服務無法啟動。您可能會在記錄中看到類似以下的警告：

 Warning  FailedScheduling  105s (x40 over 3h18m)  default-scheduler  0/9 nodes are available: 1 Insufficient nvidia.com/mig-3g.40gb-NVIDIA_A100_80GB_PCIE, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-billing-
system-billing-dbcluster: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-ocr-sie-g-vai-ocr-sie: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-translation-sie-g-v-1gvg:
 }, 3 Insufficient cpu, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/9 nodes are available: 3 No preemption victims found for incoming pod, 6 Preemption is not helpful for scheduling.

解決方法：在預設集區中新增更多工作站節點，並清空 GPU 節點上的 Pod，以便排定 AI 工作負載。

虛擬機器

無法匯入 qcow2 和原始映像檔

版本：1.13.1、1.13.3

症狀：使用 gdcloud compute images import CLI 匯入本機 VM 映像檔時，匯入狀態會停滯在 WaitingForTranslationVM 或 ImportJobNotCreated。這是因為用於翻譯或匯入作業的暫時磁碟與 qcow2/原始映像檔的大小完全相同，但 LUKS 會增加幾 MiB 的額外負荷，導致磁碟佈建失敗。

解決方法：

手動建立新的 VirtualMachineImageImport，使用相同的圖片名稱，但 spec.minimumDiskSize 較大

舉例來說，如果這是用來匯入圖片的指令：

gdcloud compute images import $IMPORT_NAME --project $PROJECT --source-file=$LOCAL_FILENAME --os=$OS

如果 CLI 自動建立的原始 VirtualMachineImageImport 為 X Gi，請建立新的 minimumDiskSize，大小為 X+1 Gi。這個值會根據匯入的圖片大小而定。如果是 qcow2，則為虛擬大小，例如 20Gi 應替換為 21Gi。

根據呼叫 CLI 的方式，替換預留位置值。

  1. 找出 VirtualMachineImageImport：

    kubectl get virtualmachineimageimport $IMPORT_NAME -n $PROJECT -o yaml

    如果沒有物件，請再次觸發 gdcloud compute images import ... 指令。 當控制台輸出內容從 Uploading image to .. 轉換為 Image import has started for ... 時，請按下 Ctrl+C，將本機圖片上傳至物件儲存空間，並保留 VirtualMachineImageImport 以供參考，建立新圖片。

  2. 使用較大的 minimumDiskSize 建立新的 VirtualMachineImageImport：

    apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineImageImport
metadata:
  name: $IMPORT_NAME_NEW
  namespace: $NAMESPACE
spec:
  imageMetadata:
    minimumDiskSize: $NEW_SIZE
    name: $IMAGE_NAME
    operatingSystem: $OS
  source:
    objectStorage:
      bucketRef:
        name: vm-images-bucket
      objectName: $LOCAL_FILENAME

從映像檔佈建磁碟失敗

版本：1.13.1、1.13.3

症狀：從自訂映像檔佈建磁碟時，minimumDiskSize 可能太接近虛擬大小，導致磁碟佈建失敗。VM 磁碟處於待處理狀態，但從未佈建。

解決方法：手動建立新磁碟，並使用較大的 spec.minimumDiskSize。

叢集有 GPU 時，NVIDIA 裝置外掛程式 DaemonSet 會失敗

版本：1.13.3

症狀：在搭載 GPU 的叢集節點上，NVIDIA 裝置外掛程式 DaemonSet 失敗，並顯示 driver rpc error 訊息：

kubectl --kubeconfig KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

請將 KUBECONFIG 改成叢集中的 kubeconfig 檔案路徑。

您會取得類似下列範例的輸出內容：

Warning  Failed     23m (x4 over 25m)  kubelet            Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running hook #0: error running hook: exit status 1, stdout: , stderr: Auto-detected mode as 'legacy'
nvidia-container-cli: initialization error: driver rpc error: timed out: unknown

這個問題會導致虛擬機器 (VM) 和 Pod 無法使用 GPU。影響取決於下列叢集類型：

  • 系統叢集：系統不會為該裸機節點建立 GPUAllocation 自訂資源，也不會將該節點中的 GPU 設定為 VM 模式，供服務和使用者叢集使用。請參閱系統叢集的解決方法，瞭解如何解決這個問題。
  • 服務或使用者叢集：系統不會為該 VM 節點建立 GPUAllocation 自訂資源，且叢集上的 Pod 無法使用該節點中的 GPU。如要解決這個問題，請參閱服務或使用者叢集的解決方法。

系統叢集的暫時解決方法：

請按照下列步驟解決系統叢集中的問題：

  1. 使用系統叢集中的 kubeconfig 檔案路徑設定 KUBECONFIG 環境變數。詳情請參閱 IAM-R0004 執行手冊。

  2. 找出發生問題的節點：

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:

    輸出內容必須列印節點名稱和 Kubernetes 節點的 IP 位址。

    如有數個節點，請在所有節點上執行這些步驟。在本例中，輸出內容如下所示：

    Node:                 yy-ab-bm04/172.20.128.26

  3. 使用節點名稱設定 NODE_NAME 環境變數，例如：

    export NODE_NAME=yy-ab-bm04

  4. 建立與節點的 SSH 連線。詳情請參閱 PLATAUTH-G0001 執行手冊。

  5. 確認節點是否含有 GPU：

    nvidia-smi -L

    輸出內容必須列印節點中的 GPU，如下列範例所示：

    GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)
GPU 2: NVIDIA H100 NVL (UUID: GPU-5827b65a-3841-d877-fc17-881a2b71d416)
GPU 3: NVIDIA H100 NVL (UUID: GPU-31448904-9ae2-c95a-1986-a56cce004f49)

  6. 在 GPU 上啟用常駐模式：

    nvidia-smi -pm 1

    這項動作可確保 NVIDIA 驅動程式一律會載入，避免裝置外掛程式逾時。

    輸出內容必須如下列範例所示：

    Enabled persistence mode for GPU 00000000:4E:00.0.
Enabled persistence mode for GPU 00000000:62:00.0.
Enabled persistence mode for GPU 00000000:C9:00.0.
Enabled persistence mode for GPU 00000000:DE:00.0.
All done.

  7. 結束 SSH 工作階段：

    exit

  8. 查詢 DaemonSet，確認裝置外掛程式是否正在執行：

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

  9. 確認 GPUAllocation 自訂資源已在 VM 模式中建立及設定：

    kubectl --kubeconfig $KUEBCONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

    輸出內容必須如下列範例所示：

    apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: yy-ab-bm04
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: yy-ab-bm04
  pod: 0
  vm: 4
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/0
    vm: 4/4
  deviceModel: H100L 94GB

服務或使用者叢集的解決方法：

請按照下列步驟解決服務或叢集中的問題：

  1. 使用服務或使用者叢集中 kubeconfig 檔案的路徑，設定 KUBECONFIG 環境變數。詳情請參閱 IAM-R0004 執行手冊。

  2. 找出發生問題的節點：

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:

    輸出內容必須列印節點名稱和 Kubernetes 節點的 IP 位址。

    如有數個節點，請在所有節點上執行這些步驟。在本例中，輸出內容如下所示：

    Node:                 vm-948fa7f4/172.20.128.21

  3. 使用節點名稱設定 NODE_NAME 環境變數，例如：

    export NODE_NAME=vm-948fa7f4

  4. 建立與節點的 SSH 連線。詳情請參閱 PLATAUTH-G0001 執行手冊。

  5. 確認節點是否含有 GPU：

    nvidia-smi -L

    輸出內容必須列印節點中的 GPU，如下列範例所示：

    GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)

  6. 在 GPU 上啟用常駐模式：

    nvidia-smi -pm 1

    這項動作可確保 NVIDIA 驅動程式一律會載入，避免裝置外掛程式逾時。

    輸出內容必須如下列範例所示：

    Enabled persistence mode for GPU 00000000:05:00.0.
Enabled persistence mode for GPU 00000000:06:00.0.
All done.

  7. 結束 SSH 工作階段：

    exit

  8. 查詢 DaemonSet，確認裝置外掛程式是否正在執行：

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

  9. 確認 GPUAllocation 自訂資源已在 VM 模式中建立及設定：

    kubectl --kubeconfig $KUBECONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

    輸出內容必須如下列範例所示：

    apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: vm-948fa7f4
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: vm-948fa7f4
  pod: 2
  vm: 0
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/2
    vm: 0/0
  deviceModel: H100L 94GB

系統叢集 VM 尚未準備就緒

版本：1.13.3

症狀：系統叢集 VM 尚未準備就緒。您可能會看到類似以下的訊息：

│ Conditions:                                                                                                                                   │
│   Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          │
│  Message                                                                                                                                      │
│   ----                          ------    -----------------                 ------------------                ------                          │
│  -------                                                                                                                                      │
│   KubeletUnhealthy              False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:37 +0000   KubeletIsHealthy                │
│  kubelet on the node is functioning properly                                                                                                  │
│   KernelDeadlock                False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   KernelHasNoDeadlock             │
│  kernel has no deadlock                                                                                                                       │
│   ReadonlyFilesystem            False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   FilesystemIsNotReadOnly         │
│  Filesystem is not read-only                                                                                                                  │
│   FrequentUnregisterNetDevice   False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentUnregisterNetDevice   │
│  node is functioning properly                                                                                                                 │
│   ContainerRuntimeUnhealthy     False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:39 +0000   ContainerRuntimeIsHealthy       │
│  Container runtime on the node is functioning properly                                                                                        │
│   FrequentKubeletRestart        False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:41 +0000   NoFrequentKubeletRestart        │
│  kubelet is functioning properly                                                                                                              │
│   FrequentDockerRestart         False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentDockerRestart         │
│  docker is functioning properly                                                                                                               │
│   FrequentContainerdRestart     False     Tue, 20 Aug 2024 02:10:42 +0000   Thu, 15 Aug 2024 01:44:23 +0000   NoFrequentContainerdRestart     │
│  containerd is functioning properly                                                                                                           │
│   MemoryPressure                Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   DiskPressure                  Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   PIDPressure                   Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   Ready                         Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.

解決辦法：

  1. 找出並刪除 VirtualMachineInstance。
  2. 重新啟動新的 VM。

找不到資料量報告的暫存空間

版本：1.13.3、1.13.4

症狀：建立 VM 磁碟時，資料磁碟區會回報成功：

gdch-vm-infra   gdc-vm-disk-vm-ce34b8ea-disk   Succeeded   100.0%     1          18h

不過，匯入器 Pod (例如 importer-gdc-vm-disk-vm-ce34b8ea-disk) 會因類似下列內容的訊息而進入當機迴圈：

E0823 16:14:15.920008       1 data-processor.go:251] scratch space required and none found
E0823 16:14:15.920017       1 importer.go:185] scratch space required and none found

解決方法：確認資料量狀態為 Succeeded 後，刪除匯入器 Pod。

如果專案名稱超過 45 個字元，專案中的 VM 會維持停止狀態

版本：1.13.5

症狀：建立 VM 時，如果專案名稱超過 45 個字元，VM 會維持在 Stopped 狀態。

解決方法：建立名稱長度不超過 45 個字元的專案。

服務叢集缺少 GPU 分配

版本：1.13.5

症狀：共用服務叢集 gpu-org 中缺少 GPUAllocation。取得 GPU 分配時，您可能會看到以下訊息：

KUBECONFIG=/root/release/user/gpu-org-shared-service-kubeconfig kubectl get gpuallocations -A

輸出如下所示：

No resources found

解決辦法：

  1. 在 GPU 節點中新增 taint：

    taints:
  - effect: NoExecute
    key: vmm.gdc.goog/gpu-node
    value: a3-highgpu-4g

  2. 移除 taint，允許排定 VM virt-launcher Pod。

無法排定共用服務叢集工作站 VM

版本：1.13.6

症狀：Kubernetes 工作站 VM 無法排程，因為指定節點上的 CPU 資源不足，即使有可用的 GPU 也是如此。您可能會看到類似這樣的事件：

Warning  FailedScheduling  33m (x29 over 92m)    default-scheduler  0/9 nodes are available: 1 Insufficient memory, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 5 Insufficient cpu, 5 Insufficient nvidia.com/gpu-vm-H100L_94GB. preemption: 0/
9 nodes are available: 3 Preemption is not helpful for scheduling, 6 No preemption victims found for incoming pod.

解決辦法：

  1. 手動停止非 GPU VM，釋放 CPU 資源。
  2. 排定待處理的 VM 後，請啟動非 GPU VM。