本頁面由 Cloud Translation API 翻譯而成。

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

備份與還原

編輯叢集備份還原方案時發生錯誤

版本：1.14.3、1.14.4、1.14.5、1.14.6、1.14.7

症狀：

您無法使用 GDC 控制台編輯 RestorePlan 自訂資源。

解決方法：

您可以建立新的還原計畫並刪除舊計畫，也可以使用 kubectl CLI 編輯還原計畫。

來源磁碟大小無效

版本：1.14.4、1.14.5

症狀：遷移至 v2 機構架構後，後端資料模型發生變更，導致 UI 錯誤地將磁碟大小顯示為 0 MB，建立時間則顯示為「不明」。

解決方法：目前無法透過使用者介面查看這項資訊。

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

版本：1.14.3、1.14.4

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

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

未套用備份與還原服務等級目標

版本：1.14.3、1.14.4

症狀：由於未安裝必要的自訂資源定義，因此系統預設不會設定 GDC 服務等級目標 (SLO) 指標和快訊。這些快訊會在 Grafana 中使用。

解決方法： 如要在 GDC 中啟用備份和還原的服務等級目標，請按照 BACK-T0001 執行手冊操作。

資料保留政策不會套用至匯入的備份資料

版本：所有版本的 Google Distributed Cloud (GDC) 氣隙隔離解決方案都可能受到影響。

症狀：將備份存放區附加至叢集時，系統會同步處理所有備份和還原中繼資料，並將存放區視為匯入的備份。在對帳期間，系統會錯誤地略過這些匯入的備份資料，也就是說，系統會忽略保留政策，並無限期保留備份資料。

解決方法：匯入的備份資料會標示 backup.gdc.goog/imported-repository:BACKUP_REPOSITORY_NAME。如要允許正常對帳及套用保留政策，請使用下列 kubectl 指令從備份中移除標籤：

設定必要環境變數：
```
export KUBECONFIG=KUBECONFIG
export BACKUP_REPOSITORY_NAME=BACKUP_REPOSITORY_NAME
export NAMESPACE=BACKUP_PLAN_NAMESPACE
```
更改下列內容：
- KUBECONFIG：kubeconfig 檔案的路徑。
- BACKUP_REPOSITORY_NAME：備份存放區的名稱。
- NAMESPACE：包含備份計畫的命名空間。

列出所有匯入的備份：

kubectl get backups.backup.gdc.goog -n $NAMESPACE -l backup.gdc.goog/imported-repository=$BACKUP_REPOSITORY_NAME

視需要移除標籤：

從所有備份中移除標籤：

kubectl get backups.backup.gdc.goog -l
backup.gdc.goog/imported-repository=$BACKUP_REPOSITORY_NAME -n $NAMESPACE
-o json | jq -r '.items[].metadata.name' | xargs -I{} kubectl label -n
$NAMESPACE backups.backup.gdc.goog {} backup.gdc.goog/imported-repository-

移除單一備份的標籤：

export BACKUP_NAME= kubectl label backups.backup.gdc.goog $BACKUP_NAME -n
$NAMESPACE backup.gdc.goog/imported-repository-

部分 VM 備份失敗

版本：1.14.3、1.14.4

症狀：如果多個 VM 中有一個 VM 無法備份，系統會將整個 VM 備份標示為失敗。

解決方法：限制每個備份方案的 VM 數量。

刪除使用者或服務叢集後，清除孤立的備份資源

版本：1.14.3、1.14.4、1.14.5、1.14.6、1.14.7

症狀：刪除使用者或服務叢集時，系統不會自動清除在機構基礎架構和管理叢集中建立的相關備份代理程式資源 (例如 StatefulSet、Pod、密碼等)。這可能會導致資源成為孤立資源，如果再次以相同名稱建立叢集，備份代理程式 Pod 就無法運作。

解決方法：孤立資源位於機構基礎架構叢集的專屬命名空間中。如要清除這些項目，請刪除這個命名空間。

設定機構基礎架構和管理叢集的 kubeconfig 檔案。

export ORG_INFRA_KUBECONFIG=<path_to_org_infra_kubeconfig>
export MGMT_KUBECONFIG=<path_to_management_kubeconfig>

找出孤立資源的命名空間。命名空間遵循 gpc-backup-<cluster-name>-system 模式。例如：
- gpc-backup-user-vm-1-cluster-system
- gpc-backup-user-vm-2-cluster-system
- gpc-backup-g-org-1-shared-service-cluster-system

刪除命名空間。這項操作會刪除其中的所有資源，包括基礎架構中的備份代理程式 StatefulSet 和 Pod，以及管理叢集中的密鑰。

# Replace <namespace-name> with the actual namespace
kubectl delete namespace <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}"
kubectl delete namespace <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"

如要確認清除作業是否成功，請再次執行 get all 指令。
```
# Replace <namespace-name> with the actual namespace
kubectl get all -n <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}"
kubectl get all -n <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"
```
由於命名空間已不存在，因此指令現在應該會失敗。您應該會看到類似 Error from server (NotFound): namespaces "<namespace-name>" not found 的錯誤。

CLI 或 UI 不支援刪除 VirtualMachineRestore

版本：1.14.3、1.14.4、1.14.5、1.14.6、1.14.7

症狀：刪除 VirtualMachineRestore 資源時，VirtualMachineRestore 控制器不會自動清除基礎資源 (VolumeRestore、Restore)。因此必須手動清除。無論是使用 kubectl delete 或使用者介面刪除，都會套用這項規定。

解決方法：解決方法是手動依正確順序刪除相依資源，然後從 VirtualMachineRestore 資源中移除終結器。

將 kubeconfig 檔案設為指向管理叢集。

export MGMT_KUBECONFIG=<path_to_management_kubeconfig>

找出要刪除的 VirtualMachineRestore 及其命名空間。

export VM_RESTORE_NAME=<vm-restore-to_be_deleted>
export NAMESPACE=<namespace-of-vm-restore>

找出並刪除相關聯的 VolumeRestore 資源。這些指標是使用連結至 VirtualMachineRestore 的標籤建立。

# Find and delete all associated VolumeRestores.
kubectl delete volumerestores.backup.gdc.goog --all-namespaces -l "virtualmachine.gdc.goog/virtual-machine-restore-name=${VM_RESTORE_NAME:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"

找出並刪除相關聯的 Restore 資源。這些指標是使用連結至 VirtualMachineRestore 的標籤建立。

# Find and delete all associated Restores.
kubectl delete restores.backup.gdc.goog -n "${NAMESPACE:?}" -l "virtualmachine.gdc.goog/virtual-machine-restore-name=${VM_RESTORE_NAME:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"

現在請執行 kubectl delete (如果尚未執行)，並從 VirtualMachineRestore 資源中移除終結器。這是最後一個步驟，可讓 Kubernetes 垃圾收集器刪除資源。

kubectl patch virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --type=merge -p '{"metadata":{"finalizers":null}}' --kubeconfig "${MGMT_KUBECONFIG:?}"

確認刪除。

kubectl get virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"

指令應傳回 NotFound 錯誤，確認資源已刪除。

備份控制層 Pod 因記憶體不足而當機

版本：1.14.4 以上版本

症狀：機構基礎架構叢集的 gpc-backup 系統命名空間中，gpcbackup-controlplane-controller Pod 的狀態為 CrashLoopBackOff。發生這類錯誤時，備份和還原作業會失敗、停止回應或無法正常運作。

解決方法：按照 BACK-R0005 的說明，提高 gpcbackup-controlplane-controller 部署作業的記憶體上限。這個方法會套用 SubcomponentOverride，調整 CPU、記憶體要求和限制。

使用者叢集刪除作業停滯

版本：1.14.7 以上版本

症狀：由於終結器問題，叢集停滯在刪除狀態。

解決方法：刪除叢集前，請先檢查儲存空間磁碟區是否具有 SnapMirror 關係。詳情請參閱 BACK-R0109。

永久磁碟區要求待處理，導致還原作業停滯

版本：1.14.3 以上版本

症狀：永久磁碟區聲明 (PVC) 控制器有時無法與機構基礎架構叢集中的備份代理程式通訊。雖然這個問題不會影響備份功能，但可能會導致磁碟區還原作業停滯在 Pending 狀態，最終逾時。這個問題會影響涉及磁碟區還原的還原作業，例如用於複製的資料庫服務還原功能，以及使用者工作負載還原。

如果發生這個問題，您必須手動重新啟動對應的備份代理程式，受影響叢集內的後續還原作業才會成功。

如要確認還原問題是否與這個特定問題有關，請調查備份代理程式記錄：

請按照 IAM-R0005 取得必要的 BACK Debugger 角色 (back-cluster-debugger)，方法是套用 ExpirationClusterRoleBinding 資源。
請按照 IAM-R0004，為機構基礎架構叢集產生 kubeconfig 檔案。所有備份代理程式都會在機構基礎架構叢集中執行。

找出負責還原作業的備份代理程式：

kubectl --kubeconfig ORG_INFRA_KUBECONFIG get statefulsets \
    --all-namespaces | grep gpcbackup-agent

將 ORG_INFRA_KUBECONFIG 替換為機構基礎架構叢集的 kubeconfig 檔案路徑。

輸出結果會與下列內容相似：

NAMESPACE                                          NAME                                     READY   AGE
gpc-backup-g-org-1-shared-service-cluster-system   gpcbackup-agent-g-org-1-shared-service   1/1     22d
gpc-backup-system                                  gpcbackup-agent                          1/1     22d
gpc-backup-system                                  gpcbackup-agent-cp                       1/1     22d
gpc-backup-user-vm-1-cluster-system                gpcbackup-agent-user-vm-1                1/1     22d
gpc-backup-user-vm-2-cluster-system                gpcbackup-agent-user-vm-2                1/1     22d

請閱讀輸出內容，找出與還原作業相應的備份代理程式。舉例來說，如果輸出內容中受影響的 StatefulSet 命名空間為 gpc-backup-user-vm-1-cluster-system，則備份代理程式為 gpcbackup-agent-user-vm-1。

在有狀態集記錄中搜尋錯誤訊息，確認問題：
```
kubectl --kubeconfig=ORG_INFRA_KUBECONFIG logs statefulsets/BACKUP_AGENT \
    -n NAMESPACE | grep "Failed to watch \*v1.PersistentVolumeClaim"
```
更改下列內容：
- ORG_INFRA_KUBECONFIG：機構基礎架構叢集 kubeconfig 檔案的路徑。
- BACKUP_AGENT：您在上一步中識別的備份代理程式。
- NAMESPACE：您在上一個步驟中識別的命名空間。
如果找到相符的記錄，表示您遇到這個已知問題。

解決方法：如要解決這個問題，請完成下列步驟：

重新啟動備份代理程式：
```
kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart \
   statefulsets/BACKUP_AGENT -n NAMESPACE
```
更改下列內容：
- ORG_INFRA_KUBECONFIG：機構基礎架構叢集 kubeconfig 檔案的路徑。
- BACKUP_AGENT：確認問題時識別的備份代理程式。
- NAMESPACE：確認問題時識別的命名空間。
輸出結果會與下列內容相似：
```
statefulset.apps/gpcbackup-agent-g-org-1-shared-service restarted
```
等待最多 20 分鐘，讓系統自動繼續執行待處理作業。

備份代理程式重新啟動後，您可以對同一個目的地叢集執行另一次還原作業。完成這項解決方法後，不會有任何副作用。每個受影響的叢集只需完成一次這項解決方法。

叢集管理

子元件 `kub-gpu-controller` 無法調解

版本：1.14.3

症狀：gdchservices 機構中的子元件 g-gdchservices-shared-service-cluster/kub-gpu-controller 不會進行協調。系統會傳回下列輸出內容：

│ Message: Reconciliation error: E0321 - runtime parameter: configRunner error
| (full log in oclcm-configrunner pod): rpc error: code = Unknown desc = failed
| to execute binary: exit status 1. Output:
│ <
│ I framework.go:159] "Reading input secret"
| inputSecretKey="g-gdchservices-shared-service-cluster/kub-gpu-controller-backend-parameter"
│ I framework.go:175] "Processing job" jobType=parameter
│ Error: no matched clusterName
│ >

這項失敗會導致 gdchservices 機構無法啟動 GPU 機器。

解決方法：升級至 1.14.4 以上版本，即可減輕問題影響。

標準叢集無法移除節點集區

版本：1.14.3、1.14.4、1.14.5

修正版本：1.14.6

症狀：從標準叢集中移除過時的節點集區失敗，且節點集區未在預期時間內刪除。標準叢集為不公開預先發布版，可能不適用於所有客戶。

解決方法：手動移除過時的節點集區。

叢集卡在刪除狀態

版本：1.14.6 以上版本

症狀：刪除 Kubernetes 叢集時，叢集可能會停滯在 Deleting 狀態。執行下列指令，檢查叢集狀態：

kubectl get cluster CLUSTER_NAME -n platform \
    --kubeconfig MANAGEMENT_API_SERVER

輸出結果會與下列內容相似：

NAMESPACE    NAME             STATE         K8S VERSION
platform     test-cluster     Deleting      1.28.15-gke.100

您也可以檢查叢集命名空間的狀態，確認問題：

kubectl describe ns/CLUSTER_NAME-cluster \
    --kubeconfig MANAGEMENT_API_SERVER

輸出結果會與下列內容相似：

Name:         test-cluster
Labels:       kubernetes.io/metadata.name=test-cluster
Status:       Terminating
Conditions:
  Type                            Status    LastTransitionTime      Reason                Message
  ----                            ------    ------------------      ------                -------
  NamespaceContentRemaining       True      DATE                    SomeResourcesRemain   Some resources are remaining: backendservices.networking.gdc.goog has 1 resource instances, forwardingruleinternals.networking.gdc.goog has 1 resource instances
  NamespaceFinalizersRemaining    True      DATE                    SomeFinalizersRemain  Some content in the namespace has finalizers remaining: backendservice.finalizers.networking.gdc.goog in 2 resource instances

叢集命名空間卡在 Terminating 狀態，且 NamespaceContentRemaining 和 NamespaceFinalizersRemaining 條件設為 True。

解決方法：如要解決這個問題，請完成下列步驟：

修補轉送規則 API：

kubectl patch forwardingruleinternals.networking.gdc.goog -n "CLUSTER_NAME-cluster" \
    cluster-control-plane-vip-fr -p '{"metadata":{"finalizers":[]}}' --type='merge'

修補後端服務 API：

kubectl patch backendservices.networking.gdc.goog -n "CLUSTER_NAME-cluster" \
    cluster-control-plane-vip-bes -p '{"metadata":{"finalizers":[]}}' --type='merge'

資料庫服務

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

AlloyDB Omni 資料庫複製作業停滯

版本：1.14.6 和更早版本

固定：1.14.7

症狀：使用者從特定時間點複製 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 值做為複製的時間點。請注意，時間採用的是世界標準時間。

DNS

GlobalCustomerRootDNSServerNotReachable 觸發錯誤快訊

版本：1.14.3、1.14.4、1.14.5、1.14.6、1.14.7、1.14.8

症狀：系統觸發 DNS 警報 DNS-A0021，表示 GlobalCustomerRootDNSServerNotReachable。 org-mp 中 global-customer-root-dns 的 Probe CR 規格沒有 egress: true。

解決方法：

設定 org-mgmt 的 KUBECONFIG 路徑：

export MGMT_KUBECONFIG=MANAGEMENT_KUBECONFIG

暫停管理探查 CR 的 core-mz 子元件：

kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" annotate subcomponent  -n global-kube-system dns-core-mz lcm.private.gdc.goog/paused=true

從 org-mp 編輯目前的探測要求 CR：

kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" edit probes -n dns-system global-customer-root-dns

更新規格以加入 egress: True，然後套用變更。請注意，CLUSTER_NAME 和 GLOBAL_CUSTOMER_ROOT_IP 不會變更。

apiVersion: prober.private.gdc.goog/v1alpha1
kind: Probe
metadata:
  name: global-customer-root-dns
spec:
  egress: True
  matchClusters:
  - CLUSTER_NAME
  probeJobs:
  - moduleName: dns_udp_global_customer_root
    name: healthy-dns-global-customer-root
    targets:
    - GLOBAL_CUSTOMER_ROOT_IP

這個解決方法會修正探測器，任何誤報都會在 15 分鐘內減少。

檔案/區塊儲存空間

無法在 VM 中掛接檔案共用磁碟區

版本：1.14.6、1.14.7

症狀：在叢集中新增節點時，系統無法更新網路儲存空間權限，導致 NFS 掛接要求遭到拒絕。掛接 NFS 檔案共用時，可能會看到 access denied by server 錯誤。

解決方法：重新啟動 file-share 或 proxy-group 調解器，或修改 FileShare 資源來觸發更新。

防火牆

子網路 CR 中的地址缺少安全性政策規則

版本：1.14.3

症狀：由於客戶在機構全域 API 伺服器中建立的全域子網路自訂資源缺少防火牆位址群組，因此無法連線至機構。

解決方法：按照服務手冊 FW-G0002 中的步驟，手動新增安全性政策規則，允許該流量通過。

GDC 防火牆會拒絕管理和資料層的 OIR 流量

版本：1.14.3、1.14.4

症狀：部署 OCITTopology 自訂資源後，OIR 與 GDC 管理層和資料層之間的連線會中斷。

解決方法：按照服務手冊 FW-G0002 中的步驟，在根管理員叢集中手動新增安全性政策規則，允許流量通過。

您必須遵守下列安全性政策規則：

  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-data-egress
    namespace: root
  spec:
    action: allow
    destination:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-data
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    source:
      addresses:
      - ZONE_INFRA_CIDR
      zones:
      - vsys1-oc-data
  ---
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-data-igress
    namespace: root
  spec:
    action: allow
    source:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-data
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    destination:
      addresses:
      - ZONE_INFRA_CIDR
      zones:
      - vsys1-oc-data
  —-
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-mgmt-egress
    namespace: root
  spec:
    action: allow
    destination:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-mgmt
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    source:
      addresses:
      - MGMT_CIDR
      zones:
      - vsys1-oc-mgmt
  ---
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-mgmt-ingress
    namespace: root
  spec:
    action: allow
    source:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-mgmt
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    destination:
      addresses:
      - MGMT_CIDR
      zones:
      - vsys1-oc-mgmt

更改下列內容：

OCIT_CIDR：客戶輸入問卷 (CIQ) 的 ocitCIDR 欄位中的 IP 位址範圍。
MGMT_CIDR：客戶輸入問卷 (CIQ) 的 oobManagementCIDRs 欄位中的 IP 位址範圍。
ZONE_INFRA_CIDR：客戶輸入問卷 (CIQ) 的 zoneInfraCIDRs 欄位中的 IP 位址範圍。

GDC 防火牆拒絕跨區域和跨機構的流量

版本：1.14.3、1.14.4、1.14.5

症狀：防火牆預設會封鎖跨區域和跨機構的流量。

解決方法：按照執行手冊中的步驟，手動新增安全政策規則，允許流量通過。

防火牆不支援識別碼與機構名稱相同的 AttachmentGroup

版本：1.14.3 以上版本

症狀：部署 AttachmentGroup 後，如果該 AttachmentGroup 物件中的 identifier 欄位與 orgName 相同，防火牆就無法剖析這個物件，且防火牆設定更新會停滯。以下是問題 AttachmentGroup 的範例：

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: myorg
    entities:
      - orgName: myorg
        domainType: OrgMixed

解決方法：避免使用機構名稱做為 ID。如要修正錯誤的 AttachmentGroup，有幾種做法。

請選擇下列其中一個選項，修正有問題的 AttachmentGroup。

在原始 ID 結尾附加字串，並以破折號分隔：

apiVersion: system.private.gdc.goog/v1alpha1
kind: AttachmentGroup
metadata:
  name: attachment-group-org-1234
  namespace: gpc-system
spec:
  identifier: myorg-orgdx
  entities:
    - orgName: myorg
      domainType: OrgMixed

在原始 ID 開頭附加字串，並以破折號分隔：

apiVersion: system.private.gdc.goog/v1alpha1
kind: AttachmentGroup
metadata:
  name: attachment-group-org-1234
  namespace: gpc-system
spec:
  identifier: orgdx-myorg
  entities:
    - orgName: myorg
      domainType: OrgMixed

將原始 ID 替換為其他字串：

apiVersion: system.private.gdc.goog/v1alpha1
kind: AttachmentGroup
metadata:
  name: attachment-group-org-1234
  namespace: gpc-system
spec:
  identifier: dxidentifier
  entities:
    - orgName: myorg
      domainType: OrgMixed

港灣

備份及還原後，Harbor CLI 密鑰會失效

版本：1.14.3

症狀：備份及還原 Harbor 後，CLI 密鑰會失效，必須重新建立。

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

使用 IAP 使用者帳戶登入 Harbor。
按一下使用者名稱，然後選取「使用者設定檔」。
按一下「更多」圖示。
自動或手動建立另一個 CLI 密鑰。

如要進一步瞭解 GDC 中的 Harbor，請參閱 Harbor 總覽。

Harbor 備份與還原作業會爭奪權限

版本：1.14.3、1.14.4

症狀：如果不同使用者專案中有多個 Harbor 執行個體，備份和還原作業會爭奪角色型存取控制項，導致失敗率偏高。

解決方法：如要減輕這個問題的影響，請按照下列步驟，為建立 Harbor 執行個體的每個命名空間手動建立角色繫結：

設定必要環境變數：
```
INSTANCE_NAMESPACE=INSTANCE_NAMESPACE
INFRA_CLUSTER_KUBECONFIG=INFRA_CLUSTER_KUBECONFIG
```
更改下列內容：
- INFRA_CLUSTER_KUBECONFIG：基礎架構叢集 kubeconfig 檔案的路徑。
- INSTANCE_NAMESPACE：建立 Managed Harbor Service (MHS) Harbor 執行個體的命名空間。

為解決方法建立角色繫結：

kubectl --kubeconfig ${INFRA_CLUSTER_KUBECONFIG:?} create \
rolebinding ${INSTANCE_NAMESPACE:?}-mhs-backup-manual-rolebinding \
--role=haas-backup-secret-access-role --serviceaccount=${INSTANCE_NAMESPACE:?}-haas-system:haas-backup-sa \
--namespace=haas-system

Harbor 備份大小顯示 0 值

版本：1.14.3、1.14.4

症狀：系統目前尚未實作 Harbor 備份的備份大小評估功能。在 GDC 控制台中，「SizeBytes」欄位會顯示「0」值，「Size」欄位則會顯示「0 MB」。目前這是預期中的設定行為。

Harbor Registry 控制台頁面中的備份資源發生權限錯誤

版本：1.14.3、1.14.4

症狀：如果您沒有 Harbor 執行個體管理員角色，在 GDC 控制台中查看「Harbor Container Registry」(Harbor Container Registry) 頁面時，備份資源會顯示權限錯誤。發生這項錯誤的原因是備份資訊剛新增至 Harbor Container Registry 頁面，但系統尚未授予備份資源的讀取權限給 Harbor Instance Admin 以外的 IAM 角色。

「Harbor Container Registry」頁面上的其他 GDC 控制台元素仍可正常運作。如要進一步瞭解 GDC 中的角色，請參閱「角色定義」。

資料庫密碼輪換作業停滯頁面

版本：1.14.3、1.14.4、1.14.5、1.14.6

症狀：系統會針對資料庫要求擲回驗證相關錯誤，例如 failed SASL auth (FATAL: password authentication failed for user "dbsadmin" (SQLSTATE 28P01))，且單一可輪替密鑰會產生許多自動輪替要求。

解決方法：刪除可輪替密鑰的其他未就緒輪替要求。

將 KUBECONFIG 設為 mp api 伺服器。
匯出命名空間：
```
NAMESPACE=haas-system
```

找出 haas-system 中是否有任何無法輪替的密鑰：

kubectl get rotatablesecrets -n ${NAMESPACE?}

輸出內容可能如下所示：

NAME                        CREDENTIALID   READY     AGE
haasdb-pw-ar-test           HAAS-0002      True      109d
haasdb-pw-gardener-harbor   HAAS-0002      True      178d
haasdb-pw-haas-alice        HAAS-0002      Unknown   166d
haasdb-pw-myinstance        HAAS-0002      True      80d
haasdb-pw-osd               HAAS-0002      True      158d
haasdb-pw-saptest           HAAS-0002      True      91d

匯出可輪替密鑰的名稱，例如：
```
ROTATABLE_SECRET=haasdb-pw-haas-alice
```

刪除尚未準備就緒的額外輪替要求：

CUR_ROTATABLE_SECRET=$(kubectl get rotatablesecret ${ROTATABLE_SECRET?} -n ${NAMESPACE?} -ojsonpath='{.status.currentRotationRequestRef.name}')

kubectl get rotationrequests -n ${NAMESPACE?} -o json | jq -r --arg rotatableSecret "${ROTATABLE_SECRET?}" --arg curRotatableSecret "${CUR_ROTATABLE_SECRET?}" '.items[] | select(.metadata.ownerReferences[0]? | .name==$rotatableSecret) | select(.status.conditions[0]? | .type=="Ready" and .status=="False") | select(.metadata.name != $curRotatableSecret) | .metadata.name' | xargs -r kubectl delete rotationrequests -n ${NAMESPACE?}

硬體安全模組

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

版本：1.14.3、1.14.4、1.14.5

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

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

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

版本：1.14.x

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

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

sudo systemctl restart host-daemon

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

啟動後 HSM 失敗，並顯示 `ValidateNetworkConfig` 錯誤

版本：1.14.x

症狀：HSM 自訂資源不會進入 Ready 狀態，且會因 ValidateNetworkConfig 錯誤而失敗。這項錯誤會顯示以下訊息：data0 interface MAC address {} is not active。如果系統重新啟動，且設定了不同的主要資料介面，就會發生這個錯誤。

解決方法：按照「HSM-R0059」執行手冊操作，重新套用資料網路的 HSM 網路設定。即使多個 HSM 發生這項錯誤，您也可以安心按照這本手冊操作。

健康狀態

服務等級目標快訊誤報

版本：1.14.3

症狀：成功範圍服務水準目標錯誤觸發。

解決方法：請基礎架構營運商 (IO) 確認警報是實際問題還是誤報。

如要解決問題，請在觸發快訊時，按照對應的執行手冊處理服務等級目標 (SLO) 快訊的根本原因。

情況一：如果 Runbook 成功解決問題，且警報停止觸發，IO 即可關閉相關事件。

情況二：如果執行手冊已完成，但快訊仍持續觸發，表示可能為誤報。檢查 SLO 是否中斷：

kubectl get servicelevelobjective {SLO_NAME} -n {SLO_NAMESPACE} -o yaml --kubeconfig root-admin-kubeconfig| awk '/successRange/ { found1 = 1 } /labelFilter/ { found2 = 1 } END { if (found1 && found2) print "Broken 1.14.3 SLO detected"; else print "SLO does not have a known 1.14.3 issue" }'

根據輸出內容：如果確認警報是誤報，IO 應在 GDC 氣隙執行個體中關閉警報；否則，請將問題提交給 Cloud 支援團隊。
無論是哪一種情況，IO 都應向 Cloud 支援團隊回報，確認可運作的元件是否正常。

無效的指標型服務水準目標設定

版本：1.14.3、1.14.4

症狀：由於設定錯誤，部分服務等級目標 (SLO) 不會填入良好、不良或總事件。相關服務等級目標是以 Prometheus 計量表為依據，因此必須據此進行設定。

解決辦法：

1.14.3 版：沒有解決方法。因此，受影響的 SLO 不會觸發 SLO 警告。

1.14.4 版：我們提供解決方法，可修正服務等級目標。如要解決這個問題，請將 isGauge: true 設定套用至 SLO 規格。

服務水準目標的量表設定範例：

```yaml
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: ServiceLevelObjective
metadata:
  namespace: infra-obs
  name: fw-packet-discard-errors-slo
spec:
  successRange:
  - resource: fw
    description: Firewall packet discard rate with errors SLO
    runbookURL: FW-R0006
    goal: "0.995"
    isGauge: true
    period: 30d
    metricName: fw_packet_discard_errors_ps
    max: 2
```

這項設定會修正下列已知 SLO：

防火牆服務等級目標：
- fw-packet-discard-errors-slo
- fw-packet-discard-no-error-slo
- fw-packet-discard-unknown-protocol-slo
- fw-uptime-slo
檔案 SLO：
- file-ontap-appliance-availability-slo
- file-ipsec-networking-availability-slo
- file-ontap-networking-availability-slo
- file-iscsi-client-availability-slo
- file-multipath-client-availability-slo
- file-trident-client-availability-slo

身分與存取權管理

無法建立 IAM 角色繫結

版本：1.14.3

症狀：系統會產生 IAM 角色繫結名稱。這些名稱的長度上限為 63 個字元，格式為 user-idp-prefix-rolename。如果產生的名稱超過 63 個字元的限制，角色繫結就無法建立。因此，使用預先定義或自訂角色定義的權限不會指派給使用者。

解決方法：如果預先定義或自訂的角色名稱很短 (例如 4 到 5 個半形字元)，角色繫結建立作業可能會成功。

無法為專案服務帳戶建立 IAM 角色繫結

版本：1.14.3、1.14.4、1.14.5、1.14.6

症狀：具有 organization-iam-admin 角色的專案服務帳戶 (PSA) 無法使用 gdcloud projects add-iam-policy-binding 指令指派其他角色給自己，例如 project-iam-admin 角色。這項缺點會導致 PSA 無法管理自己的權限。

解決方法：確認您具備 organization-iam-admin 角色。然後在目標 PSA 的專案命名空間中，將 project-iam-admin 角色指派給自己，並將 project-iam-admin 角色指派給 PSA。透過這項權限設定，PSA 可以為自己或其他 PSA 指派額外權限。

新專案建立預先定義角色時發生延遲

版本：1.14.3

症狀：建立新專案時，缺少預設角色，例如 project-bucket-object-admin。

解決方法：等待 15 到 60 分鐘，或在機構基礎架構叢集的 iam-system 命名空間中，手動重新啟動 iam-org-admin-cm-backend-controller 控制器。

GDC 控制台無法建立第一個角色繫結

版本：1.14.4

症狀：使用 GDC 控制台為新服務身分建立第一個角色繫結時，系統會回報角色繫結建立成功，但實際上並未生效。服務身分識別的任何後續動作都會失敗且無效，包括新增或刪除角色繫結。

解決方法：使用 gdcloud CLI 為服務身分建立第一個角色繫結。附加第一個角色繫結後，使用 GDC 控制台透過服務身分執行的所有後續動作，都會正常運作。詳情請參閱「將角色繫結指派給服務身分」。

AOS 無法授予自己在基礎架構叢集中的角色存取權

版本：1.14.3。1.14.4

已修正：1.14.3 Hotfix 21

症狀：AO 無法授予自己或任何其他使用者基礎架構叢集中任何角色的存取權。

解決方法：AO 使用者必須與 IO 聯絡，才能取得必要存取權。IO 可以使用 IAC，為 AO 使用者提供必要的存取權。

現有的服務帳戶權杖會失效

版本：1.14.3

已修正：1.14.3 Hotfix 21

症狀：使用者叢集發出的現有服務帳戶權杖會因 service-account-issuer apiserver arg 在叢集啟動後變更而失效。這個問題會導致使用者叢集上的 Pod (例如具有 istio-proxy Sidecar 容器的 Pod) 無法使用服務帳戶權杖進行驗證，且服務帳戶權杖需要數小時才能以新設定重新整理。

解決方法：在使用者叢集上，手動重新啟動 Pod，讓服務帳戶權杖以新設定更新。

基礎架構即程式碼 (IAC)

缺少命名空間，導致子元件協調失敗

版本：1.14.3

症狀：子元件無法調解。這是因為系統不會在 gdchservices-mp 叢集中自動建立必要的 config-management-monitoring 命名空間。

解決方法：使用下列資訊清單，在 gdchservices-mp 叢集中建立 config-management-monitoring 命名空間：

apiVersion: v1
kind: Namespace
metadata:
  labels:
    configmanagement.gke.io/system: "true"
  name: config-management-monitoring
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep

IAC ConfigSync 指標收集作業失敗

版本：1.14.3、1.14.4

症狀：IAC 的 ConfigSync 監控子系統發生問題，導致 otel-collector 無法開始部署。系統不會收集 ConfigSync 指標，用於監控和快訊。

解決方法：在 root-admin 叢集中完成下列步驟：

暫停 iac-configsync-mon 子元件。
編輯 config-management-monitoring 命名空間中的 MetricsProxySidecar/iac-configsync-metrics 物件。

在 MetricsProxySidecar/iac-configsync-metrics YAML 中，找出下列項目：

spec:
  [...]
  destinations:
  - certificate:
      secretName: iac-configsync-mon-target-cert

將這個區段變更為下列內容：

spec:
  [...]
  destinations:
  - certificate:
      secretName: iac-configsync-mon-mon-target-cert

在 otel-collector 命名空間中重新啟動 config-management-monitoring 部署作業。

IAC RootSync 失敗

版本：1.14.3

症狀：由於缺少 iac-creds 密鑰，ConfigSync 無法將資源從 GitLab 同步至叢集。由於 iacmanager 發生問題，iac-creds 未輪替。

解決方法：在叢集中完成下列步驟：

請按照 IAC-R0015 Runbook 操作，解決缺少密鑰 iac-creds 的問題。輪替 IaC 管理員和 ConfigSync 的憑證。

庫存

商品目錄稽核無法完成對帳

版本：1.14.3

症狀：inv-audit 子元件無法調解，因為 HarborRobotAccount 僅適用於管理平面。

解決方法：在 AlertManager 中建立靜音，忽略 component: inv 的 component_reconciliation_errors 警報。

金鑰管理系統

如果 KMS 設定為使用 CTM 根金鑰，當 HSM 無法使用時，系統不會進行容錯移轉

版本：1.14.x

症狀：當 HSM 無法使用，但有其他可用的 HSM 時，對 KMS 發出的部分要求會失敗。只有在 KMS 設定為使用 CTM 根金鑰時，才會發生這個問題。

解決方法：按照 HSM-P0006 執行手冊的指示，從 HSMCluster 移除無法使用的 HSM。然後重新啟動 kms-backend 部署作業：

kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart deployment/kms-backend -n kms-system

這個指令會重新啟動 kms-backend Pod，並重新建立與 HSMCluster 中 HSM 的連線。

負載平衡器

子網路 CIDR 耗盡，因此無法建立全域負載平衡器

版本：1.14.3

症狀：全域子網路的 IP 位址不足，因此無法建立全域外部或內部負載平衡器。由於控制器使用的程式碼路徑有誤，系統無法為通用負載平衡器動態分配 IP 位址。負載平衡器只會參照一個子網路，如果該子網路沒有可用的 IP 位址，就無法切換至其他子網路。這項限制導致系統顯示錯誤。

解決方法：您必須建立自己的子網路，並為 ForwardingRule 資源建立靜態 IP 位址。如要進一步瞭解如何建立子網路，請參閱「設定工作負載網路的子網路」。建立 ForwardingRule 資源時，您可以在 cidrRef 欄位中指定子網路。

版本：1.14.3

症狀：負載平衡器物件未進入 Ready 狀態。

解決方法：您必須建立 Backend 資源，其中 spec 欄位有值。Backend 資源會識別負載平衡器的端點。如未提供 spec 欄位的值，可能會導致錯誤狀態。

修改負載平衡器資源不會協調服務

版本：1.14.3

症狀：修改負載平衡器自訂資源時，負載平衡器服務不會進行協調。

解決方法：如要解決這個問題，請刪除該負載平衡器的 BackendService 和 ForwardingRule 資源，然後重新建立負載平衡器。

系統不會拒絕不正確的區域名稱

版本：1.14.3

症狀：全域 BackendService 資源不會拒絕不正確的區域名稱。如果區域名稱有誤，負載平衡器會失敗，而不是驗證並拒絕設定。

解決方法：您必須提供所用區域的正確名稱。如果負載平衡器設定有誤，必須刪除並重新建立負載平衡器自訂資源。

全域和區域負載平衡器 Webhook 錯誤

版本：1.14.3

症狀：系統傳回下列錯誤：

Error from server (InternalError): error when creating "STDIN": Internal error
occurred: failed calling webhook
"projectnetworkpolicies.networking.global.gdc.goog": failed to call webhook:
Post
"https://unet-global-org-cm-webhooks.unet-system.svc/validate-networking-global-gdc-goog-v1-projectnetworkpolicy?timeout=10s":
context deadline exceeded

解決方法：如要解決這個問題，請重新啟動並刪除 unet-global-cm Pod：

root@bootstrapper-zone1:~# k8s.org get pods -n unet-system
unet-global-org-cm-backend-controller-7df58cd9db-8szkh   1/1     Running   42 (7h22m ago)   9d

root@bootstrapper-zone1:~# k8s.org delete pods -n unet-system
unet-global-org-cm-backend-controller-7df58cd9db-8szkh

記錄

Loki Pod 在 WAL 重播期間當機或遭到 OOMKilled

版本：1.14.3、1.14.4、1.14.5

症狀：

obs-system 命名空間中的 audit-logs-loki-io Pod 會進入 CrashLoopBackOff 狀態。這是因為 wal_replay_ceiling 值超過 Pod 的記憶體限制，導致系統在重播預先寫入記錄 (WAL) 時，過早發生即時性探查失敗或記憶體不足 (OOM) 終止作業。

解決辦法：

請按照下列步驟調整 Loki 的設定，允許成功重播 WAL。變更將套用至受影響的叢集 (例如 root-admin 或 org-infra)

將 KUBECONFIG=/path/to/affected-cluster.kubeconfig 設為環境變數。

暫停 LoggingPipelineReconciler，避免控制器還原手動變更。套用這個資訊清單：

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: log-logging-pipeline-pause
  namespace: root
spec:
  subComponentRef: "log-admin"
  backend:
    operableParameters:
      controller:
        disableReconcilers: "LoggingPipelineReconciler"

確認覆寫功能已啟用。輸出內容應包含 "disable-reconcilers=LoggingPipelineReconciler"。

kubectl get deploy -n obs-system log-admin-backend-controller -o jsonpath='{.spec.template.spec.containers[0].args}' --kubeconfig=${KUBECONFIG} | jq

將 audit-logs-loki-io-cm ConfigMap 中的 replay_memory_ceiling 降低至 8GB。

kubectl edit cm audit-logs-loki-io-cm -n obs-system --kubeconfig=${KUBECONFIG}

修改 wal 區段：

[...]
  wal:
    replay_memory_ceiling: 8GB ## <-- Change to 8GB
[...]

選用：縮放物件 Proxy。如果 obj-proxy Pod 即將達到資源上限，請擴充部署作業，以處理復原期間增加的負載。

a. 查看資源用量：
```
kubectl top po -n gpc-system -l name=obj-proxy-manager --kubeconfig=${KUBECONFIG}
```
b. 如果使用率偏高，請擴充部署作業：
```
kubectl scale deployment obj-proxy -n gpc-system --replicas=7 --kubeconfig=${KUBECONFIG}
```
c. 如有需要，您也可以提高 Pod 的記憶體限制 (例如從 12000Mi 提高至 16000Mi)。
增加受影響 Pod 的 PVC 大小 (例如 loki-storage-audit-logs-loki-io-0從 70Gi 到 75Gi)，以免磁碟壓力過大。請按照內部程序 SUPP-R001 調整 PVC 大小。在下一個步驟中重新啟動後，系統就會套用新大小。

在 audit-logs-loki-io StatefulSet 中新增 startupProbe，以便在開始執行存活檢查前，預留時間進行 WAL 重播。儲存變更會觸發 Pod 的滾動式重新啟動 (5 到 10 分鐘)。

kubectl edit sts audit-logs-loki-io -n obs-system --kubeconfig=${KUBECONFIG}

將此 startupProbe 新增至 audit-logs-loki-io 容器規格：

startupProbe:
  failureThreshold: 1000
  httpGet:
    path: /ready
    port: loki
    scheme: HTTP
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 10

驗證解決方法

檢查 Pod 和 StatefulSet 狀態：確認所有 audit-logs-loki-io Pod 都是 Running，且 StatefulSet 顯示所有副本都已準備就緒。

kubectl get po -n obs-system -l app=audit-logs-loki-io --kubeconfig=${KUBECONFIG}
kubectl get sts -n obs-system audit-logs-loki-io --kubeconfig=${KUBECONFIG}

確認 PVC 已調整大小。預期的輸出內容為 75Gi。

kubectl get pvc -n obs-system loki-storage-audit-logs-loki-io-0 -o jsonpath='{.status.capacity.storage}' --kubeconfig=${KUBECONFIG} ; echo

檢查 Pod 記錄檔中的 errors=false 訊息，確認 WAL 復原作業是否成功。

kubectl logs -n obs-system audit-logs-loki-io-0 --kubeconfig=${KUBECONFIG} | grep -i "wal"

確認 Pod 內 /wal 目錄的用量不高。

kubectl exec -n obs-system audit-logs-loki-io-0 -c audit-logs-loki-io --kubeconfig=${KUBECONFIG} -- df -Ph /wal

檢查 Loki Ring 狀態：

a. 轉送 Loki 服務的通訊埠：

DATA_IP=$(ip -br -4 a s dev bond0| awk '{print $3}' | cut -d / -f 1)
kubectl port-forward -n obs-system svc/audit-logs-loki-io --address $DATA_IP 43100:3100 --kubeconfig=${KUBECONFIG}

b. 在 http://<DATA_IP>:43100/ring 確認所有執行個體健康狀態良好。

清除覆寫和物件 Proxy

驗證成功後，請執行下列清除步驟。

移除子元件覆寫：

kubectl delete subcomponentoverride log-logging-pipeline-pause -n root --kubeconfig=${KUBECONFIG}

如果已調高 obj-proxy 部署作業的規模，請將其調回原始大小。

監控

AlertManager 網頁掛鉤無法傳送部分叢集的快訊

版本：1.14.3

症狀：AlertManager 網頁掛鉤無法從根管理員叢集或 ServiceNow 執行個體所在的叢集以外的任何叢集，將要求和快訊通知傳送至 ServiceNow。因此，系統不會在 ServiceNow 中為機構建立快訊。

如果系統重複顯示錯誤記錄訊息，表示 Webhook 無法傳送快訊。請按照下列步驟找出重複發生的錯誤：

匯出環境變數：
```
export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
```
將 MGMT_API_KUBECONFIG 替換為 Management API 伺服器的 kubeconfig 檔案路徑。

找出 Pod：

kubectl --kubeconfig ${MGMT_API_KUBECONFIG} get pods \
  -n mon-system -o name | grep mon-alertmanager-servicenow-webhook-backend-

取得記錄：

kubectl --kubeconfig ${MGMT_API_KUBECONFIG} logs POD_NAME -n mon-system

將 POD_NAME 替換為 Pod 的名稱。

找出類似下列內容的重複錯誤：

Errorsendingtherequest ... read: connection reset by peer

解決方法：建議的解決方法是暫停兩個子元件，一個用於中繼監控快訊，另一個用於一般快訊。然後，在受影響叢集的 mon-alertmanager-servicenow-webhook-backend 部署作業中，將標籤 egress.networking.gke.io/enabled: "true" 替換為 networking.private.gdc.goog/infra-access: enabled。這個標籤可讓 Pod 與其他基礎架構叢集通訊，不必依賴輸出閘道。

請按照下列步驟套用建議的解決方法：

匯出環境變數：
```
export ROOT_KUBECONFIG=ROOT_KUBECONFIG
export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
export ORG=ORG
```
更改下列內容：
- ROOT_KUBECONFIG：根管理員叢集的 kubeconfig 檔案路徑。
- MGMT_API_KUBECONFIG：Management API 伺服器的 kubeconfig 檔案路徑。
- ORG：機構的命名空間。

暫停子元件：

暫停 mon-alertmanager-servicenow-webhook 子元件：

kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-alertmanager-servicenow-webhook" \
  -n "${ORG}" lcm.private.gdc.goog/paused=true

暫停 mon-meta-monitoring 子元件：

kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-meta-monitoring" \
  -n "${ORG}" lcm.private.gdc.goog/paused=true

更新涵蓋大多數快訊的mon-alertmanager-servicenow-webhook-backend部署作業：

kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \
  -n mon-system mon-alertmanager-servicenow-webhook-backend

將 spec.template.metadata.labels 中的標籤從 egress.networking.gke.io/enabled: "true" 替換為 networking.private.gdc.goog/infra-access: "enabled"。

更新涵蓋監控堆疊相關快訊的 meta-alertmanager-servicenow-webhook 部署作業：

kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \
  -n mon-system meta-alertmanager-servicenow-webhook

將 spec.template.metadata.labels 中的標籤從 egress.networking.gke.io/enabled: "true" 替換為 networking.private.gdc.goog/infra-access: "enabled"。

您也可以使用 Grafana 查看相同的快訊。

ServiceNow 事件偶爾會重複

版本：1.14.3

症狀：您可能會看到同一 Pod 的 ServiceNow 事件重複出現。

解決方法：您可以比對事件說明中的指紋，找出重複的支援單。

基礎架構指標可能過於敏感

版本：1.14.3

症狀：你可能會看到警報 oclcm-reconciler-success-rate 的警報。

解決方法：您可以放心忽略警報。這項警示過於頻繁，我們正在改善信號。

對帳指標可能過於敏感

版本：1.14.3、1.14.4、1.14.5

症狀：你可能會看到警報 component_reconciliation_errors 的警報。

解決方法：您可以按照 Runbook MON-R2009 忽略警報。這則快訊的噪音過大。

根管理員叢集中有兩則誤報

版本：1.14.3

症狀：根管理員叢集中的 MON-A0001_slow 和 MON-A0001_fast 快訊處於觸發狀態。

ServiceNow 事件如下列範例所示：

number        priority        sys_created_on        u_organization_id   short_description   active
INC004043     1 - Critical    2025-04-30 08:29:00   root                MON-A0001_slow      true
INC0040427    1 - Critical    2025-04-30 08:28:55   root                MON-A0001_fast      true

事件說明如下：

Description:
Message: "Blackbox monitoring metrics pipeline down"
Runbook URL: MON-R0001
Generator URL: cortex.mon-system.svc:9009/graph?g0.expr=%28mon_metrics_pipeline_error_rate1h%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%2814.4+%2A+0.05%29+and+mon_metrics_pipeline_error_rate5m%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%2814.4+%2A+0.05%29%29+or+%28mon_metrics_pipeline_error_rate6h%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%286+%2A+0.05%29+and+mon_metrics_pipeline_error_rate30m%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%286+%2A+0.05%29%29&g0.tab=1
AlertCode: MON-A0001
Severity: critical
Cluster: org-1-admin
Namespace: <no value>
Pod Name: <no value>
fingerprint: 3b386f1373178e97

解決方法：請按照下列步驟操作，僅在根管理員叢集中解決問題：

刪除 mon-a0001-blackbox-monitoring-obs-system MonitoringRule 中的 monitoring.gdc.goog/metamonitoring-project=mon-system 標籤。

從 mon-a0001-blackbox-monitoring-obs-system MonitoringRule 中，刪除名稱為 mon_metrics_pipeline_absent 的所有記錄規則，以及叢集標籤值 ORG_NAME-admin。

以下範例顯示要刪除的 mon_metrics_pipeline_absent 記錄規則：

Expr:               absent(probe_success{job="mon-system/meta-monitoring-meta-prometheus/meta_prometheus_probe_metric",cluster="gdchservices-admin"}) OR on() vector(0)
    Labels:
      _source_project:  blackbox-monitoring-obs-system
      Cluster:          gdchservices-admin
      Job:              mon-system/meta-monitoring-meta-prometheus/meta_prometheus_probe_metric
    Record:             mon_metrics_pipeline_absent

MON_A0001_slow 和 MON_A0001_fast 警報都會在幾分鐘後 (約 40 分鐘) 回到 Normal 狀態。

根管理員控制器管理工具顯示高錯誤率

版本：1.14.3

症狀：你可能會看到警報的通知 ControllerReconciliationErrorRateHigh。控制器管理工具會顯示以下記錄：ApplianceStorage.ceph.storage.private.gdc.goog \"appliance-storage\" not found

解決方法：您可以放心停用發生錯誤的控制器。

匯出環境變數：
```
export ROOT_KUBECONFIG=ROOT_KUBECONFIG
```
編輯根管理員控制器管理員部署作業：
```
kubectl --kubeconfig ${ROOT_KUBECONFIG} edit deployment \
  -n gpc-system root-admin-controller
```
在 manager 容器中，如果沒有引數 --disable-reconcilers，請新增一個，並將值設為 --disable-reconcilers=ApplianceStorageTunnelReconciler。如果有，請以半形逗號新增 ApplianceStorageTunnelReconciler 調解器。例如： --disable-reconcilers=ManagementSwitch,ManagementAggSwitch,TORSwitch,AggSwitch,ApplianceTORSwitch,ApplianceStorageTunnelReconciler

錯誤記錄檔應會清除。

KUB 資訊主頁在所有 PA 面板中都不會顯示資料

版本：1.14.3

症狀：平台管理員在 Grafana 中查看 KUB 資訊主頁時，所有面板都顯示沒有資料。

解決方法：暫停 KSM 子元件，然後更新 monitoringtarget 和 metricsproxysidecar：

暫停子元件：

export SUBCOMPONENT_NAME=mon-kube-state-metrics
export SUBCOMPONENT_NAMESPACE=ORG_NAME
kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" lcm.private.gdc.goog/paused=true

更改下列內容：

ORG_NAME：機構名稱
ROOT_ADMIN_KUBECONFIG：root-admin kubeconfig 的路徑

在 .spec.destinations 區段中，將下列內容新增至 mon-kube-state-metrics-metrics-proxy metricsproxysidecar：

  - certificate:
  secretName: mon-pa-kube-state-metrics-cert
port: 8091

更新後的 metricsproxysidecar 可能如下所示：

...
spec:
  containerName: otel-collector
  destinations:
  - certificate:
      secretName: mon-io-kube-state-metrics-cert
    port: 8090
  - certificate:
      secretName: mon-pa-kube-state-metrics-cert
    port: 8091
  resources:
    limits:
...

從 mon-pa-kube-state-metrics monitoringtarget spec 中移除 matchClusters: 區段。更新後的 mon-pa-kube-state-metrics monitoringtarget spec 可能如下所示：

...
spec:
  podMetricsEndpoints:
    metricsRelabelings:
    - action: replace
      replacement: platform-obs
      targetLabel: _gdch_project
    path:
      value: /metrics
    port:
      value: 8091
    scheme:
      value: http
    scrapeInterval: 60s
    scrapeTimeout: 45s
  selector:
    matchLabels:
      monitoringtarget: mon-kube-state-metrics

observability-admin-debugger 角色的權限設定錯誤

版本：1.14.3、1.14.4

症狀：IO 無法在 mon-system 命名空間中重新啟動 Cortex 或 Prometheus Pod。

解決辦法：

機構：

暫停 iam-common 子元件。

將 observability-admin-debugger/iam-system roleTemplate 更新為以下內容：

apiVersion: iam.private.gdc.goog/v1alpha1
kind: RoleTemplate
metadata:
  name: observability-admin-debugger
  namespace: iam-system
spec:
  metadata:
    roleType: predefined
    hierarchyLevel: org
    persona: infra-operator
    displayName: "Observability Admin"
    bindingType: rolebinding
    roleNamespace: "mon-system"
    operableComponent: IAM
  rules:
  - apiGroups:
    - "apps"
    resources:
    - "deployments"
    resourceNames:
    - "logmon-operator"
    - "cortex-tenant"
    - "meta-blackbox-exporter"
    - "blackbox-exporter"
    verbs:
    - "*"
  - apiGroups:
    - "apps"
    resources:
    - "statefulsets"
    resourceNames:
    - "anthos-prometheus-k8s"
    - "meta-prometheus"
    - "mon-prober-backend-prometheus"
    - "primary-prometheus-shard0-replica0"
    - "primary-prometheus-shard0-replica1"
    - "primary-prometheus-shard1-replica0"
    - "primary-prometheus-shard1-replica1"
    verbs:
    - "*"
  - apiGroups:
    - ""
    resources:
    - "secrets"
    resourceNames:
    - "anthos-prometheus-scrape-cert"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    - "anthos-prometheus-etcd-scrape"
    verbs:
    - "*"
  - apiGroups:
    - "cert-manager.io"
    resources:
    - "certificates"
    resourceNames:
    - "anthos-prometheus-scrape"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    verbs:
    - "get"
    - "list"
    - "watch"

根管理員：

暫停 iam-common 子元件。

將 observability-admin-debugger-root/iam-system roleTemplate 更新為以下內容：

apiVersion: iam.private.gdc.goog/v1alpha1
kind: RoleTemplate
metadata:
  name: observability-admin-debugger
  namespace: iam-system
spec:
  metadata:
    roleType: predefined
    hierarchyLevel: org
    persona: infra-operator
    displayName: "Observability Admin"
    bindingType: rolebinding
    roleNamespace: "mon-system"
    operableComponent: IAM
  rules:
  - apiGroups:
    - "apps"
    resources:
    - "deployments"
    resourceNames:
    - "logmon-operator"
    - "cortex-tenant"
    - "meta-blackbox-exporter"
    - "blackbox-exporter"
    verbs:
    - "*"
  - apiGroups:
    - "apps"
    resources:
    - "statefulsets"
    resourceNames:
    - "anthos-prometheus-k8s"
    - "meta-prometheus"
    - "mon-prober-backend-prometheus"
    - "primary-prometheus-shard0-replica0"
    - "primary-prometheus-shard0-replica1"
    - "primary-prometheus-shard1-replica0"
    - "primary-prometheus-shard1-replica1"
    verbs:
    - "*"
  - apiGroups:
    - ""
    resources:
    - "secrets"
    resourceNames:
    - "anthos-prometheus-scrape-cert"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    - "anthos-prometheus-etcd-scrape"
    verbs:
    - "*"
  - apiGroups:
    - "cert-manager.io"
    resources:
    - "certificates"
    resourceNames:
    - "anthos-prometheus-scrape"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    verbs:
    - "get"
    - "list"
    - "watch"

缺少 Grafana 偵錯工具角色

版本：1.14.3、1.14.4

症狀：在可觀測性影子專案命名空間 (*-obs-system) 中，沒有 grafana-debugger-cp 角色。使用者無法取得偵錯 Grafana 相關問題所需的正確權限組合。

解決方法：在 infra-cp 中建立下列 ClusterRoleTemplate 自訂資源，並使用建立的對應 ClusterRole 取得 grafana-debugger 權限。

apiVersion: iam.private.gdc.goog/v1alpha1
kind: ClusterRoleTemplate
metadata:
  name: grafana-debugger-cp
spec:
  metadata:
    roleType: predefined
    hierarchyLevel: infra-cp
    persona: infra-operator
    displayName: "Grafana Admin"
    bindingType: rolebinding
    operableComponent: MON
  rules:
  - apiGroups:
    - "apps"
    resources:
    - "deployments"
    resourceNames:
    - "grafana-proxy-server"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - "apps"
    resources:
    - "statefulsets"
    resourceNames:
    - "grafana"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - ""
    resources:
    - "pods"
    resourceNames:
    - "grafana-0"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - ""
    resources:
    - "pods"
    verbs:
    - "get"
    - "list"
    - "watch"
  - apiGroups:
    - "monitoring.private.gdc.goog"
    resources:
    - "datasources"
    verbs:
    - "create"
    - "delete"
    - "get"
    - "list"
    - "update"
    - "patch"
    - "watch"
  - apiGroups:
    - "monitoring.global.private.gdc.goog"
    resources:
    - "datasourcereplicas"
    verbs:
    - "create"
    - "delete"
    - "get"
    - "list"
    - "update"
    - "patch"
    - "watch"

新增區域後，系統不會顯示跨區域指標和記錄

版本：1.14.*

症狀：Grafana 資訊主頁不會顯示新加入區域的記錄和指標。

解決方法 1：重新啟動 datasource-proxy 部署作業：

kubectl KUBECONFIG=${KUBECONFIG_ORG} rollout restart deployment datasource-proxy -n mon-system

這會重新啟動資料來源 Proxy Pod，並更新新加入區域的跨區域端點設定。

`MonitoringTarget` 終結器會封鎖命名空間刪除作業

版本：1.14.3、1.14.4

症狀：命名空間無法刪除，且相應的機構單位中有不正常的叢集。

解決方法：從阻礙命名空間刪除作業的 MonitoringTarget 自訂資源中，手動移除終結器。

資訊主頁和資料來源待處理的終結器導致專案刪除作業停滯

版本：1.14.3、1.14.4

已修正：1.14.3 Hotfix 22

症狀：專案無法刪除，且終止命名空間時發生錯誤，例如：

Some resources are remaining: dashboards.observability.gdc.goog has 2 resource instances, datasources.monitoring.private.gdc.goog has 2 resource instances.

解決方法：手動刪除資訊主頁和資料來源的終結器。

無法查看 KSM 的指標

版本：1.14.3

已修正：1.14.3 Hotfix 22

症狀：KUB 資訊主頁的所有面板都會顯示 。No Data

解決方法：暫停 KSM 子元件，然後更新 monitoringtarget 和 metricsproxysidecar。

暫停子元件：

export SUBCOMPONENT_NAME=mon-kube-state-metrics
export SUBCOMPONENT_NAMESPACE=ORG_NAME
kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" lcm.private.gdc.goog/paused=true

更改下列內容：

ORG_NAME：機構名稱。
ROOT_ADMIN_KUBECONFIG：根管理員 kubeconfig 的路徑。

在 .spec.destinations 中，將下列內容新增至 mon-kube-state-metrics-metrics-proxy metricsproxysidecar：

- certificate:
  secretName: mon-pa-kube-state-metrics-cert
port: 8091

更新後的 mon-kube-state-metrics-metrics-proxy metricsproxysidecar 如下例所示：

...
spec:
  containerName: otel-collector
  destinations:
  - certificate:
      secretName: mon-io-kube-state-metrics-cert
    port: 8090
  - certificate:
      secretName: mon-pa-kube-state-metrics-cert
    port: 8091
  resources:
    limits:
...

從 mon-pa-kube-state-metrics monitoringtarget 規格中移除 matchClusters: 區段。更新後的 mon-pa-kube-state-metrics monitoringtarget 規格如下所示：

...
spec:
  podMetricsEndpoints:
    metricsRelabelings:
    - action: replace
      replacement: platform-obs
      targetLabel: _gdch_project
    path:
      value: /metrics
    port:
      value: 8091
    scheme:
      value: http
    scrapeInterval: 60s
    scrapeTimeout: 45s
  selector:
    matchLabels:
      monitoringtarget: mon-kube-state-metrics`

系統指標管道已關閉

版本：1.14.3

症狀：即使按照 MON-R0001 執行手冊操作，MON-A0001 警報仍處於啟用狀態。

解決方法：

如果問題出現在管理員叢集中，請使用 IAC-R0004 執行手冊，在 root-admin 中建立下列 SubcomponentOverride。如果是使用者、周邊或共用等其他叢集，請在 ${ORG}-mp 中建立 SubcomponentOverride。

kind: SubcomponentOverride
metadata:
  name: mon-cortex-tenant
  namespace: <NAMESPACE>
spec:
  backend:
    operableParameters:
      concurrency: 1024
      resourcesLimit:
        cpu: "8"
        memory: 16Gi
  subComponentRef: mon-cortex-tenant

找出正確的 NAMESPACE：

kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get subcomponent -A | grep "mon-cortex-tenant"

輸出看起來像這樣：

org-1-mp             mon-cortex-tenant                      27h   ReconciliationCompleted
org-1                mon-cortex-tenant                      46h   ReconciliationCompleted
root                 mon-cortex-tenant                      47h   ReconciliationCompleted

如果管道因 root-admin 而停用，命名空間就是根目錄；如果管道因 org-1 admin 而停用，命名空間就是 org-1：

kubectl --kubeconfig=ORG_ADMIN_KUBECONFIG get subcomponent -A | grep "mon-cortex-tenant"

輸出看起來像這樣：

g-org-1-perimeter-cluster        mon-cortex-tenant                     40h   ReconciliationCompleted
g-org-1-shared-service-cluster   mon-cortex-tenant                     40h   ReconciliationCompleted
user-vm-1-cluster                mon-cortex-tenant                     40h   ReconciliationCompleted
user-vm-2-cluster                mon-cortex-tenant                     40h   ReconciliationCompleted

視系統指標管道中斷的叢集而定，正確的命名空間可能是 g-org-1-perimeter-cluster、g-org-1-shared-service-cluster、user-vm-1-cluster 或 user-vm-2-cluster。

套用 SubcomponentOverride 後，請在各自的叢集中重新啟動 cortex-tenant 部署作業。檢查相應叢集中的值是否已更新：
```
kubectl --kubeconfig ${KUBECONFIG:?} get configmap cortex-tenant-config -n mon-system -o yaml
```
更新並行欄位。

重新啟動 cortex-tenant 部署作業：

kubectl --kubeconfig ${KUBECONFIG:?} rollout restart deployment/cortex-tenant -n mon-system

多用戶群架構

主控台未顯示節點集區建立失敗

版本：1.14.4、1.14.5、1.14.6

固定：1.14.7

症狀：在 GDC 控制台中，如果節點集區建立失敗，使用者介面會錯誤顯示 creation in progress 訊息，指出節點集區已成功建立。

解決方法：使用 gdcloud CLI 驗證節點集區建立作業。

多可用區

無法存取的區域會重新導向至驗證頁面

版本：1.14.x

症狀：無法存取區域時，GDC 控制台會重新導向至顯示驗證錯誤的頁面。不過，區域無法存取可能不是驗證問題所致，而是區域中斷所致。

解決方法：使用區域網址解決這個問題。如果區域網址也無法運作，請要求基礎架構營運商 (IO) 診斷您收到驗證問題的區域是否已停機。

無法使用 gcloud CLI 查看區域

版本：1.14.x

症狀：使用 gdcloud zones list 指令所需的 IAM 角色預設不會套用至 GDC 領域。缺少預先定義角色中沒有的角色，導致無法使用 gcloud CLI 列出可用區。

解決方法：將 IAM 角色 global-zone-viewer 和角色繫結資源套用至全域 API 伺服器：

建立角色 YAML 檔案 (例如 global-zone-viewer.yaml)，並包含下列內容：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: global-zone-viewer
  namespace: mz-system
rules:
- apiGroups:
  - location.mz.global.private.gdc.goog
  resources:
  - zones
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: global-zone-viewer-binding
  namespace: mz-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: global-zone-viewer
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated

將 YAML 檔案套用至機構組織的全球 API 伺服器：

kubectl --kubeconfig ORG_GLOBAL_API_SERVER_KUBECONFIG apply -f global-zone-viewer.yaml

這個角色繫結會驗證系統中的所有使用者，以使用 gdcloud zones list 查看區域。

全球控制台網址登入錯誤間歇性發生

版本：1.14.x

症狀：使用全域網址登入 GDC 控制台時，可能會收到工作階段無效的錯誤訊息。這項錯誤可能是由底層網路錯誤所致，並非工作階段狀態的準確呈現方式。

解決方法：使用區域網址登入 GDC 控制台，從各個區域內管理全域資源。如要進一步瞭解如何從 GDC 控制台切換區域環境，請參閱跨區域管理資源。

網路

調整 `MultiZoneNetworkConfig` 區域順序導致設定取代失敗

版本：所有 1.14.x 版本都可能受到影響。

症狀：

上層機架 (ToR) 交換器的 READY 狀態為 False。執行下列指令即可確認：
```
kubectl get torswitches -A
```
交換器設定替換作業失敗，並顯示項目已存在的錯誤訊息。您可以在交換器設定取代記錄中查看這項資訊。錯誤訊息類似於下列內容：
```
% Insertion failed - entry already exists
```

這個問題是由於調整 MultiZoneNetworkConfig 內的區域順序所致。系統會根據設定清單中每個區域的位置，為 BGP 存取控制清單規則產生序號。如果變更區域順序，系統會產生新的規則，這些規則的序號不同，因此會與交換器上已有的規則衝突。

解決方法：

如要解決這個問題，請從每個受影響的 ToR 交換器手動移除衝突的 BGP AS 路徑存取控制清單設定。這樣一來，系統就能比對並套用正確的設定。

與每個不在 Ready 狀態的 ToR 交換器建立 SSH 連線。
進入全域設定模式：
```
config t
```
移除衝突的存取清單設定：
```
no ip as-path access-list other-zones
```
結束設定模式。

在所有受影響的交換器上執行這項指令後，協調器會套用正確的設定，交換器也會轉換為 READY 狀態。

Config-replace 提交到期時間

版本：所有 1.14.x 版本都可能受到影響。

症狀：

如果存取控制清單 (ACL) 數量過多，設定網路交換器時就會發生逾時問題。BorderLeafSwitch 自訂資源不在 Ready 狀態，且建立與未就緒交換器的 SSH 連線時，會看到 Commit expiry 狀態。

舉例來說，下列指令會顯示狀態：

sh config-replace log verify

輸出結果會與下列內容相似：

  Config-replace type: atomic .replace_tmp_11924
  Start Time: Wed Jul 09 18:08:33 2025
  Operation Status: Success
  Commit Status: Commit expiry

解決方法：

在 1.14.3 或 1.14.7 以上版本中，編輯 root 命名空間中名為 pnet-core-override 的 SubcomponentOverride 自訂資源，並將 httpTimeout 欄位新增至 .spec.operableParameters.netDevGW。

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: pnet-core-override
  namespace: root
spec:
  backend:
    bootstrapParameters:
      enableMetricsEncryption: true
    operableParameters:
      disableNetworkReconcilerFeatures: ""
      enableOperationStoragePVC: false
      netDevGW:
        httpTimeout: 10m
  subComponentRef: pnet-core

請等待 15 分鐘，讓自動化基礎架構將新設定推送至交換器。視需要設定 httpTimeout，直到 Commit expiry 訊息消失為止。

在 1.14.4、1.14.5 和 1.14.6 版中，請手動執行 config-replace 並提交變更。

暫停切換：

export SWITCH_NAME=SWITCH_NAME # example: aa-aa-blsw01
export SWITCH_TYPE=SWITCH_TYPE # example: borderleafswitch

kubectl -n gpc-system annotate $SWITCH_TYPE $SWITCH_NAME system.private.gdc.goog/paused="true"

請按照 PNET-P0001 執行手冊操作，取得交換器存取權。
找出要取代的設定：
```
switch-cli# dir | grep new_config
```
完成設定取代作業：
```
switch-cli# configure replace <new_config_file>
```
這項作業可能需要超過五分鐘的時間。
config-replace 成功後，請提交變更：
```
switch-cli# configure replace commit
```

取消暫停切換：

kubectl -n gpc-system annotate $SWITCH_TYPE $SWITCH_NAME system.private.gdc.goog/paused-

使用 4 位元組 BGP ASN 部署失敗

版本：1.14.3、1.14.4

症狀：在網路交換器上設定邊界閘道通訊協定 (BGP) 時，使用 4 位元組的自治系統編號 (ASN) 會導致設定失敗。如果未正確套用 BGP 設定，該 GDC 區域內的網路可能無法建立適當的路徑，導致連線問題、無法宣傳路徑，或一般網路不穩定。目前沒有解決方法。

全域任播流量遭到封鎖

版本：1.14.3

症狀：存取控制清單 (ACL) 會封鎖前往全域任播端點的流量。

解決方法：

如要解決存取控制清單 (ACL) 封鎖全域任播流量的問題，您需要在根管理員叢集中建立SubcomponentOverride自訂資源，明確允許流量流向全域 DNS 伺服器的任播 CIDR 區塊。步驟如下：

找出所有全域任播 CIDR 區塊。如要找出要更新的全球任播 CIDR 區塊，請按照下列步驟操作：
1. 連線至根層級的全球 API 伺服器。
2. 使用下列指令，列出所有命名空間中的所有子網路自訂資源：
```
kubectl get subnet -A
```
3. 篩選輸出內容，找出 metadata.name 篩選器包含關鍵字 anycast 的子網路資源。
4. 針對名稱中含有 anycast 的每個子網路資源，請記下 spec.subnet 的值。這個值代表全域任播 CIDR 區塊。

在根管理員叢集中，於根命名空間中建立名為 pnet-trafficpolicy-dc-override 的 SubcomponentOverride 自訂資源。針對上一步驟中識別的每個任播子網路，新增規則，如 YAML 檔案所示：

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: pnet-trafficpolicy-dc-override
  namespace: root
spec:
  backend:
    operableParameters:
      breakglassRules:
        default-traffic-policy-data:
        - IPVersions:
          - IPv4
          L4Protocol: IP
          action: Accept
          description: INTERCONNECT_RULE_DESCRIPTION
          destinationEndPoint:
            host:
              hostPrefix: GLOBAL_ANYCAST_CIDR
            port:
              portType: ANY
          direction: Ingress
          enforcePoints:
          - enableLogging: false
            enforcePointType: DataInterconnect
          sourceEndPoint:
            host:
              hostType: ANY
            port:
              portType: ANY
        - IPVersions:
          - IPv4
          L4Protocol: IP
          action: Accept
          description: HAIRPIN_RULE_DESCRIPTION
          destinationEndPoint:
            host:
              hostType: ANY
            port:
              portType: ANY
          direction: Ingress
          enforcePoints:
          - enableLogging: false
            enforcePointType: DataHairpin
          sourceEndPoint:
            host:
              hostPrefix: GLOBAL_ANYCAST_CIDR
            port:
              portType: ANY
  subComponentRef: pnet-trafficpolicy-dc

更改下列內容：

INTERCONNECT_RULE_DESCRIPTION：互連網路規則的說明文字。
GLOBAL_ANYCAST_CIDR：全域任播 CIDR 區塊，例如 136.125.38.128/28。針對上一個步驟中找到的每個任播，使用這個 YAML 檔案建立規則。
HAIRPIN_RULE_DESCRIPTION：髮夾網路規則的說明文字。

部分 DCI 失敗導致流量損失

版本：1.14.3

症狀：當連接可用區邊界 Leaf 交換器與電信業者交換器的資料中心互連 (DCI) 連結都發生問題，或可用區邊界 Leaf 交換器發生硬體故障時，大約有 50% 的跨可用區網路流量會遺失。

VRF 名稱過長

版本：1.14.2

症狀：執行這項指令時，您可能會看到類似以下範例的訊息，表示交換器健康狀態不良：

sh config-replace log verify

輸出內容可能如下所示：

Operation            : Config-replace to user config
Checkpoint file name : .replace_tmp_20791
Scheme               : tmp
Cfg-replace done By  : admin
Cfg-replace mode     : atomic
Verbose              : disabled
Start Time           : Fri, 20:03:38 08 Nov 2024
Start Time UTC       : Fri, 20:03:38 08 Nov 2024
-------------------------------------------
Command : snmp-server context gdch-services-orginfrainternal-vrf vrf gdch-servic
es-orginfrainternal-vrf, parse error : -20, mode : /exec/configure/vrf
Failed to parse: snmp-server context gdch-services-orginfrainternal-vrf vrf gdch
-services-orginfrainternal-vrf
Configuration above is invalid or not supported via CR/rollback feature

解決方法：機構 CR 名稱最多可有 19 個字元。

StatefulSet pod 通訊失敗

版本：1.14.3、1.14.4

已修正：1.14.3 hotfix 23、1.14.5

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

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

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

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

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

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

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

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

版本：

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

症狀：

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

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

解決方法：

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

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

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

取得受影響節點的 SSH 存取權。
使用節點的管理 IP 位址，透過 SSH 連線至節點。
在節點上執行下列指令，然後關閉 SSH 連線：
```
tc filter del dev bond0 egress
```

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

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

建立允許所有輸出 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*]

多可用區跨可用區可用性 SLO Grafana 資訊主頁問題

版本：1.14.3

症狀：在 Grafana 中，pnet-cross-zone-availability 服務水準目標資訊主頁不會顯示任何指標。

解決方法：請按照 PNET-P0001 執行手冊操作，取得交換器存取權，並手動檢查多區域 BGP 工作階段和連線狀態。

資料層和管理 Ingress 閘道無法完成調解

版本：1.14.3

症狀：子元件 asm-dataplane-ingress 或 asm-management-ingress 無法調解，並出現下列錯誤：

message: 'Reconciliation error: E0111 - upgrade chart: cannot patch "management-ingress-gateway" with kind BackendService: BackendService.networking.gdc.goog "management-ingress-gateway" is invalid: spec.targetPorts: Invalid value: "array": TargetPorts list is immutable'

錯誤字串中可能出現 ForwardingRuleInternal 和 ForwardingRuleExternal，而非 BackendService。同樣地，資源名稱可能是 dataplane-ingress-gateway、dataplane-ingress-gateway-global 或 management-ingress-gateway-global，而非 management-ingress-gateway。

解決方法：判斷資源是否位於管理 API 伺服器或全域 API 伺服器中。您可以從錯誤字串中的資源類型 API 版本推斷出此資訊。舉例來說，管理 API 伺服器中存在後置字元為 networking.gdc.goog 的資源，而全域 API 伺服器中存在後置字元為 networking.global.gdc.goog 的資源。

找出 API 伺服器後，請使用對應的 kubeconfig 檔案刪除資源。例如：

kubectl --kubeconfig API_SERVER_KUBECONFIG delete Backendservice dataplane-ingress-gateway -n istio-system

專案網路政策頁面不支援 ProjectNetworkPolicy API 中的專案選取器欄位

版本：1.14.3、1.14.4

症狀：建立包含 projectSelector 欄位的專案網路政策，並在 GDC 控制台中查看時，使用者介面會顯示為政策選取的所有專案，而非 projectSelector 欄位中的專案。

解決方法：使用 API 建立及讀取包含 projectSelector 欄位的專案網路政策。

作業系統

伺服器佈建失敗

版本：1.14.3

症狀：在伺服器佈建期間，從 Harbor 登錄檔下載 OS 映像檔時，對應的BaremetalHost自訂資源可能會顯示下列 401 錯誤，且伺服器會卡在取消佈建和重新佈建的迴圈中。

如要檢查這些錯誤，請說明 BaremetalHost 自訂資源：

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG describe baremetalhost SERVER_NAME -n gpc-system

輸出內容可能如下所示：

Normal  InspectionComplete     14m    metal3-baremetal-controller  Hardware inspection completed
Normal  ProvisioningStarted    5m39s  metal3-baremetal-controller  Image provisioning started for https://robot%24om5hgylsfvzxs43umvwtu43boiwwc4djmv4hizloonuw63rnmjqwg23fnzsc2ylqnfsxq5dfnzzws33ofvzwk4twmvza:4usy4JXE6BAdEVU2t8LMqDPhfM4EnW73@10.129.24
.66:31714/artifacts/serve/Z3BjLXN5c3RlbS1vcy1pbWFnZXMvZ2RjaC1ub2RlLW9zOnJvY2t5LTg2LTEuMTQtdjIwMjQxMDIzLTEuMTQtcjI4MQ==
Normal  ProvisioningError      5m28s  metal3-baremetal-controller  Image provisioning failed: Failed to prepare to deploy: Validation of image href https://robot%24om5hgylsfvzxs43umvwtu43boiwwc4djmv4hizloonuw63rnmjqwg23fnzsc2ylqnfsxq5dfnzzws33ofvzwk
4twmvza:4usy4JXE6BAdEVU2t8LMqDPhfM4EnW73@10.129.24.66:31714/artifacts/serve/Z3BjLXN5c3RlbS1vcy1pbWFnZXMvZ2RjaC1ub2RlLW9zOnJvY2t5LTg2LTEuMTQtdjIwMjQxMDIzLTEuMTQtcjI4MQ== failed, reason: Got HTTP code 401 instead of 200 in response to HEAD request.
Normal  DeprovisioningStarted  5m17s  metal3-baremetal-controller  Image deprovisioning started

解決辦法：

取得伺服器所屬 nodePoolClaim 的名稱和命名空間：

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get server SERVER_NAME -n gpc-system -ojson | jq '.spec.nodePoolClaimRef'

輸出內容可能如下所示：

{
"name": "control-plane-extension-pool-o2-standard1-96-gdc-metal",
"namespace": "gpu-org-lancer"
}

從 NodePoolClaim 取得 OS 映像檔名稱：

kubectl get nodepoolclaim NODEPOOLCLAIM_NAME -n NODEPOOLCLAIM_NAMESPACE -o json | jq '.spec.machineSpec.osImageName'

從 OSImageMetadata 取得 OS 映像檔網址：

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get osimagemetadata OS_IMAGE_NAME -o json | jq '.commonMetadata.servingURL'

使用最新的 OS 映像檔網址更新 Server 自訂資源：

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG patch server SERVER_NAME -n gpc-system --type=json -p='[{"op": "replace", "path": "/spec/image/urlSpec/url", "value" : "'OS_IMAGE_URL'"}]'

OS NodeUpgrade 可能會停滯在 NodeOSInPlaceUpgradePostProcessingCompleted 步驟

版本：1.14.3、1.14.4

症狀：

節點升級期間，NodeUpgradeTask會停留在 NodeOSInPlaceUpgradePostProcessingCompleted 步驟，並顯示調解器錯誤，訊息為「failed verifying delta after upgrade」，且無法完成升級。這項錯誤表示升級驗證程序在節點上發現非預期的套件差異。具體來說，這項功能會找出仍處於「需要升級」狀態的套件，或是在嘗試升級後顯示為「僅限新版」的套件。

錯誤訊息會列出未通過驗證的特定套件。程式碼片段範例：

{"ts":1748758118826.9954,"caller":"controller/controller.go:329","msg":"Reconciler error","controller":"NodeUpgradeTask","controllerGroup":"upgrade.private.gdc.goog","controllerKind":"NodeUpgradeTask","NodeUpgradeTask":{"name":"lancer-org1-data-plane-pool-o2-standard1-96-gdc-metal-nmw2h-zx-ac-bm15","namespace":"lancer-org1"},"namespace":"lancer-org1","name":"lancer-org1-data-plane-pool-o2-standard1-96-gdc-metal-nmw2h-zx-ac-bm15","reconcileID":"26585774-7059-46b7-a0f7-0e627b2a2bb5","err":"failed verifying delta after upgrade: 2 errors occurred:\n\t* failed to make \"need-upgrade\" empty, found\n  - bind-export-libs\n  from: 9.11.36-16.el8_6.86ciq_lts.2\n  to: 9.11.36-16.el8_6.86ciq_lts.4\n...\n- strongswan-sqlite\n  from: 5.9.10-1.el8_6.ciqlts\n  to: 5.9.10-2.el8\n\t* failed to make \"only-in-new\" empty, found lsof=4.93.2-1.el8\nstrace=5.13-4.el8\n\n"}

這個症狀可能是由兩個問題所致。請先找出問題原因：

Cause-A：機器無法連線，導致 OSArtifactSnapShot 過時。

檢查升級中的節點是否仍正常運作，以及對應的 OSArtifactSnapShot 工作是否失敗。

如果 OSArtifactSnapShot 過時，且機器無法連線超過 20 分鐘，請繼續執行 Mitigation-A。否則請繼續檢查 Cause-B。
Cause-B：無聲 RPM 升級失敗

在極少數情況下，機器上的 RPM 升級可能會在部分升級後無聲失敗。升級前後應有兩個 ConfigMap，分別包含套件差異：
```
in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-before-upgrade
in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-after-upgrade
```
如果「升級後」的套件數量少於「升級前」的 ConfigMap，表示升級作業已無聲中止，並非所有套件都已升級。前往「Mitigation-B」。

解決辦法：

Mitigation-A：修復無法連線的電腦

嘗試重新啟動電腦來修復問題。如果嘗試重新啟動後仍無法連線，請聯絡 SERV 團隊尋求進一步協助。電腦恢復連線後，請刪除 OSArtifactSnapShot 強制進行協調。OSArtifactSnapShot完成對帳後，NodeUpgradeTask應繼續執行下一個步驟。

Mitigation-B：重試 NodeUpgradeTask

透過 SSH 連線至要升級的電腦，並收集下列記錄以供日後排解問題。請收集下列檔案：
- /var/log/dnf.log
- /var/log/dnf.rpm.log
- dnf 記錄 > dnf_history.log
- rpm -qa --last > rpm_last.log
刪除失敗的 NodeUpgradeTask。這會觸發特定節點的 NodeUpgradeTask 重試。新的 NodeUpgradeTask 應完成 RPM 升級，然後繼續下一個步驟。

OS NodeUpgrade 可能會在建立套件伺服器的步驟中停滯

版本：1.14.3、1.14.4

症狀：

如果 NodeUpgrade CR 建立後未暫停，且在 in-progress 中停留超過 30 分鐘，可能會在套件伺服器建立階段無聲無息地失敗。症狀是 NodeUpgrade 停留在：.status.upgradeStatus=in-progress 但沒有載入 .status.tasks：

status:
  duration: 0s
  upgradeStatus: in-progress

如要進一步確認套件伺服器建立失敗，請讀取 OS 升級控制器記錄：

kubectl logs deployment/os-upgrade-controller -n os-system --kubeconfig=/path/to/admin-cluster-kubeconfig-of-the-nodeupgrade-object

如果控制器記錄顯示 failed to create package server 和 failed to create package repo server DNS registration，並附上詳細原因 (下列任一項)

spec.fqdnPrefix already used in an existing DNS registration
name already used in an existing DNS。

然後建議其他 NodeUpgrade 使用的某些其他套件伺服器資源仍處於存留狀態，並與目前暫止 NodeUpgrade 的待建立資源發生衝突。

解決辦法：

如要進一步確認，您可以檢查實際的套件伺服器資源 (適用於特定 API，例如管理 NodeUpgrade CR 的叢集管理 API 伺服器中的 dnsregistration.network.private.gdc.goog)，並找出擁有這些資源的 NodeUpgrade。如果 NodeUpgrade (DNSRegistration 的擁有者) 已完成，但 DNSRegistration 資源仍未刪除，則當所有參照的 NodeUpgrade 物件都已完成時，您就可以刪除 DNSRegistration 物件。

列出 NodeUpgrade 套件伺服器的所有 DNSRegistration CR：

kubectl get dnsregistration.network.private.gdc.goog -n $NAMESPACE $NAME $ -ojson --kubeconfig=/path/to/mgmt-api-server-kubeconfig-of-the-nodeupgrade-object | grep nu-bm

查詢特定 DNSRegistration 的擁有者 NodeUpgrade CR：

kubectl get dnsregistration.network.private.gdc.goog -n $NAMESPACE $NAME $ -ojson --kubeconfig=/path/to/mgmt-api-server-kubeconfig-of-the-nodeupgrade-object | jq -r '.metadata.annotations."package-server-owners"'

節點 OS 升級作業可能會發生問題，並在程序中的任何階段停止

版本：1.14.4、1.14.5、1.14.6

症狀：

NodeUpgradeTask CR 仍低於 in-progress 超過 2 小時，但如果時間足夠，系統可能會自動完成。

NodeUpgradeTask CR 已進行超過兩小時，雖然最終可能會自動完成，但根本問題是 os-policy-reconciler 無法有效管理大量 OSPolicy CR。這個問題發生在 NodeOSInPlaceUpgradeCompleted 步驟。

如要進一步確認套件伺服器建立期間發生這項失敗，請參閱 OS 升級控制器記錄。

kubectl logs deployment/os-upgrade-controller -n os-system --kubeconfig=/path/to/admin-cluster-kubeconfig-of-the-nodeupgrade-object

如果控制器記錄缺少 NodeUpgradeTask 的 OSPolicy 項目，表示控制器負載過重。

解決辦法：

在升級過程中，請暫停所有非必要的 OSPolicy CR。

「storage cp」大型檔案會導致機構管理 kube-api 停止運作

版本：1.14.3 以上版本

症狀：在 gdcloud storage cp 作業或 OIC 工作站的 gdcloud system container-registry load-oci 作業期間，存取機構基礎架構的權限可能會遺失，接著 org-mgmt 的 kube-api 會停止運作。這是罕見的問題，收集工程資料有助於解決問題。

解決方法：發生這個問題時，請嘗試下列步驟：

針對每個控制層 (CP) 節點，執行 uptime，查看節點是否在過去 24 小時內重新啟動。
記下重新啟動的時間。
執行 dmesg | grep -i 'kernel panic'，檢查每個 CP 節點在重新啟動前是否發生核心恐慌。
在每個 CP 節點上，執行 lspci | grep -i eth | grep -i mellanox，檢查是否已安裝 Mellanox NIC 卡。如果沒有 Mellanox NIC，請停止閱讀這個已知問題。

在每個 CP 節點上，檢查 data0 的下列網路設定：

[root@cp-node-01 ~]# ethtool -k data0 | grep -E 'generic-receive-offload|large-receive-offload|rx-checksumming|rx-gro-hw'
rx-checksumming: off
generic-receive-offload: on
large-receive-offload: off
rx-gro-hw: on  # <--- Check this value

如果所有節點的 rx-gro-hw (如上所示) 都設為「off」，請停止閱讀這個已知問題。

請收集一些資訊，協助 Google 診斷問題：

k8s.org get po -n anthos-identity-service -l k8s-app=ais

k8s.org get po -n management-kube-system

k8s.org get po -n kube-system -l component=kube-apiserver

k8s.org get nodes -l node-role.kubernetes.io/control-plane

在每個 CP 節點上執行下列指令：

dmesg | grep -i 'kernel panic'

journalctl -u disable-rx-gro-hw.service

systemctl status disable-rx-gro-hw

modinfo mlx5_core | grep ^version:

如要解決網路設定問題，請在所有控制平面節點上執行下列指令，將 rx-gro-hw 設為 off：

ethtool -K data0 rx off gro off lro off
ethtool -K data1 rx off gro off lro off
ethtool -K bond00 rx off gro off lro off

再次檢查設定：

[root@cp-node-01 ~]# ethtool -k data0 | grep -E 'generic-receive-offload|large-receive-offload|rx-checksumming|rx-gro-hw'
rx-checksumming: off
generic-receive-offload: on
large-receive-offload: off
rx-gro-hw: off # <--- Check this, should be "off"

重試原始作業，例如 gdcloud storage cp 或 gdcloud system container-registry load-oci。如果仍無法成功，請與工程團隊聯絡。

作業套件基礎架構核心服務 (OIC)

Jumphost 效能不佳

版本：所有版本的 Google Distributed Cloud (GDC) 氣隙隔離解決方案都可能受到影響。

症狀：瀏覽器或系統作業需要過長的時間才能完成。

解決辦法：

透過 BM03 和 BM04 上的 Hyper-V 管理員，增加 Jumphost 上的 vCPU 數量：

選取 Jumphost VM，然後按一下動作窗格中的「設定」。
選取「處理器」，然後視工作負載將「虛擬處理器數量」增加至 4 個以上。
對其餘 Jumphost 重複執行上述步驟。

Resource Manager

無法在 GDC 控制台中刪除專案

版本：1.14.3、1.14.4

症狀：GDC 控制台會在「Project details」(專案詳細資料) 頁面中，為現有專案提供「delete」(刪除)「Delete」(刪除) 按鈕，但該按鈕無法運作。

解決方法：如要刪除現有專案，請使用 gdcloud CLI。詳情請參閱「刪除專案」。

缺少機構 Ansible 應對手冊

版本：1.14.3

症狀：建立機構時，建立必要 Ansible 劇本的 create-ansible-playbooks 工作會無聲無息地失敗。缺少 Ansible 劇本會導致問題，例如缺少周邊虛擬機器，以及無法建立全球機構。

解決方法：按照 OS-R0009 執行手冊，手動建立缺少的機構 Ansible 應對手冊。

非對稱全球機構會顯示不存在的區域設定

版本：1.14.4

症狀：建立 v1 全球機構時，如果只使用部分區域機構設定，所有區域仍會顯示機構副本狀態。舉例來說，如果您有三個區域的 GDC 宇宙，但只為兩個區域建立區域性機構設定，第三個區域仍會顯示不存在的第三個區域性機構的錯誤副本狀態。

如要確認錯誤狀態，請列印全球機構的狀態：

kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get organization \
    ORG_NAME -n gpc-system -o yaml

YAML 輸出內容如下所示：

...

- name: zone3
  replicaStatus:
    systemInfo:
      cidrInfo: {}
  rolloutStatus:
    conditions:
    - lastTransitionTime: "2025-03-12T02:09:21Z"
      message: ""
      observedGeneration: 1
      reason: Current
      status: "True"
      type: Synced
    - lastTransitionTime: "2025-03-12T02:09:22Z"
      message: rollout succeeded
      observedGeneration: 1
      reason: RolloutSucceeded
      status: "True"
      type: Replicated

...

請注意，這只會發生在 v1 機構，因為 v2 機構不支援非對稱區域設定。

解決方法：您可以忽略錯誤的副本狀態，因為除非您特別建立，否則區域性機構不會存在。

叢集

基礎架構叢集工作站節點集區未刪除

版本：1.14.3、1.14.4

症狀：從 Organization CR 規格移除工作站節點集區時，系統不會自動刪除節點集區，也就是說，kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} 指令仍會輸出要刪除的節點集區。

# Organization CR example
apiVersion: resourcemanager.private.gdc.goog/v1alpha1
kind: Organization
...
spec:
  resourceCapacities:
    workloadServers:
      o2-standard1-96-gdc-metal: 4 # worker node pool to remove
...

解決方法：從 Organization CR 規格移除工作站節點集區後，請執行下列指令，從根管理員叢集手動刪除這個節點集區的 NodePoolClaim CR： sh kubectl delete nodepoolclaim data-plane-pool-{machine-class} -n {org-name}

等待 NodePoolClaim 和相關聯的 NodePool CR 完全刪除，也就是 kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} 指令不再輸出工作站節點集區。

儲存空間

使用 `gdcloud config set zone` 指令建立的值區無法刪除

版本：1.14.7 以上版本

症狀：使用 gdcloud config set zone 指令建立的 bucket 無法刪除，這是因為權限問題，導致指令嘗試在錯誤的區域中運作。

解決方法：使用主控台為值區設定特定區域，或在 gdcloud 指令中將 --zone 標記替換為 --location。

OBJ 服務等級目標快訊已啟動

版本：1.14.3、1.14.4

症狀：OBJ 的服務等級目標快訊因 OBJ Proxy 發生 ErrFailedStreamingDecryptRequest 錯誤而觸發：obj-list-object-ops-availability-slo、obj-rw-object-ops-error-rate-slo。

解決方法：忽略警報。使用者終止連線時，系統會誤判為系統錯誤，但這類錯誤不會計入服務等級目標。

S3 UploadPart Empty ETag

版本：1.14.3

症狀：傳送 UploadPart 要求後，您會在回應訊息中取得 200 Success 狀態碼，但 ETag 欄位為空白。發生這項錯誤的原因是網路中斷導致 InternalServerError，且狀態碼未更新為 500 InternalServerError。

解決方法：重新嘗試要求，就像先前失敗一樣。

Trident `mkfs.ext4` 錯誤導致 Pod 無法掛接

版本：1.14.3

症狀：嘗試掛接 Pod 後，您會發現所有正在移往或移出特定節點的 Pod 都失敗。顯示 rpc 錯誤訊息 DeadlineExceeded desc = context deadline exceeded，表示節點卡住。發生這類訊息時，您就無法在相關節點上執行其他 Trident 作業。提供資料的磁碟區不會受到影響，但移入及移出節點的磁碟區可能會發生中斷。

解決辦法：

檢查 Pod 嘗試掛接的節點上的 Trident 記錄，並確認佇列正在增加。記錄可能類似如下：

2025-01-24T00:27:22.783599667Z time="2025-01-24T00:27:22Z" level=debug msg="Attempting to acquire shared lock (NodeUnstageVolume-pvc-0f04a9c5-00fc-4c3c-9fc1-6730598f7caa); 421 position in the queue." lock=csi_node_server logLayer=csi_frontend requestID=94c8ad12-6479-4e1c-8791-118b565d6c6b requestSource=CSI workflow="node_server=unstage"

登入節點並查看 dmesg 輸出內容。記錄可能類似如下：

Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
Jan 31 02:43:47 ap-ae-bm18 kernel: device-mapper: multipath: 253:40: Failing path 65:144.
Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
Jan 31 02:43:47 ap-ae-bm18 kernel: device-mapper: multipath: 253:40: Failing path 65:160.
Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)

確認發生 Trident mkfs.ext4 錯誤後，請重新啟動節點。

Trident 無法建立磁碟區，因為已發生錯誤

版本：1.14.3

症狀：

PVC 未佈建，並顯示類似下列的事件：

failed to create cloned volume {pvc-bab6bc52-fd37-4ead-a57b-e833e14c172a} on backend iscsi-san: volume trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a already exists

發生這類事件時，您必須執行解決方法，PVC 才會佈建。

解決辦法：

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

請記下事件中的內部磁碟區名稱。舉例來說，「症狀」部分顯示的範例事件會顯示內部磁碟區名稱 trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a。
按照 FILE-R0105 執行手冊存取 ONTAP。

刪除磁碟區：

volume delete trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a

`file_block_iscsi_sessions_unhealthy alert` 報告誤判

版本：1.14.3

症狀：在某些環境中，file_block_iscsi_sessions_unhealthy 警報會觸發，指出一或多個節點發生 iSCSI 故障。file-observability 控制器會使用自訂指標收集器，追蹤每個 Kubernetes 節點上 iSCSI 工作階段的健康狀態，但在某些情況下，指標收集器無法剖析 iscsiadm 指令的輸出內容，即使 iSCSI 工作階段健康狀態良好，仍會回報零個正在執行的 iSCSI 工作階段。

解決辦法：

請按照下列步驟確認 iSCSI 是否有問題，如果警報實際上是誤報，請將警報設為靜音：

在 Grafana 的探索頁面中，執行查詢 fb_sessions_running_count{job="file-observability-backend-target.file-system"}。查詢會傳回叢集中每個節點的指標。如果任何節點回報 fb_sessions_running_count 指標為 0，請記下節點名稱。
針對每個傳回 0 的 fb_sessions_running_count 指標節點，執行下列指令：
1. 與受影響的節點建立 SSH 連線。
2. 執行 iscsiadm -m session 指令。系統必須傳回多行資料。每一行都是執行中的 iSCSI 工作階段。如果指令未傳回任何內容，或輸出內容有錯誤，請將問題提報給檔案封鎖工程團隊。
3. 如果先前的指令順利傳回 iSCSI 工作階段，則表示您已確認這個節點的快訊是誤判。
確認所有受影響的節點都有正常的 iSCSI 工作階段，且導致警示錯誤觸發後，請在 AlertManager 中建立靜音，讓 file_block_iscsi_sessions_unhealthy 警示靜音。

`file_block_storage_disk_failure` 備用磁碟觸發快訊

版本：1.14.3

症狀：在某些環境中，file_block_storage_disk_failure 警報會觸發，指出 ONTAP 中有一或多個磁碟健康狀態不良。file-observability 控制器會使用自訂指標收集器追蹤 ONTAP 中每個磁碟的健康狀態，但在舊版 GDC 中，收集器不會將備用磁碟視為健康狀態良好的磁碟，因此會針對備用磁碟觸發快訊。

解決辦法：

請按照下列步驟確認磁碟為備用磁碟，並關閉磁碟的快訊：

在 Grafana 的探索頁面中，執行查詢 disks_labels_healthy{job="file-observability-backend-target.file-system"}。查詢會傳回 ONTAP 中每個磁碟的指標。如果任何磁碟回報的指標為 0 (不正常)，請記下該磁碟的名稱。
針對每個傳回 0 的 disks_labels_healthy 指標磁碟，執行下列指令：
1. 透過 SSH 連線至 ONTAP 叢集，然後使用從指標查詢收集的磁碟名稱執行 disk show -disk <disk-name> -fields state 指令。
2. 確認指令輸出內容顯示磁碟狀態為 present 或 spare。如果磁碟處於 present 或 spare 以外的任何狀態，請將問題提交給檔案封鎖工程團隊。
3. 如果問題磁碟回報 present 或 spare，我們可以確認該磁碟不應觸發快訊。在 AlertManager 中建立靜音，將 disk_name 標籤設為磁碟名稱，即可讓 file_block_storage_disk_failure 快訊靜音。
為所有備用磁碟建立靜音後，請前往 Grafana 確認警報已停止觸發。

連線恢復後，系統會觸發 file_block_storage_node_peer_connection_unhealthy 警報

版本：1.14.3

症狀：在某些環境中，系統會觸發 file_block_storage_node_peer_connection_unhealthy 警報，指出 ONTAP 節點之間的一或多個連線失敗。file-observability 控制器會使用自訂指標收集器追蹤這些連線的健康狀態。已知問題：即使連線失敗後已恢復正常，系統仍會持續觸發這項快訊。

解決辦法：

請按照下列步驟，確認節點之間的連線正常運作，並將節點的快訊設為靜音：

在 Grafana 的探索頁面中，執行查詢 storage_node_peer_connections{job="file-observability-backend-target.file-system"}。查詢會傳回叢集中儲存節點之間每個連線的指標。如果任何連線回報的 storage_node_peer_connections 指標為 0，請記下該指標的 source_node、destination_ip 和 storage_cluster_name 標籤。
針對每個傳回  的  指標，執行下列指令：storage_node_peer_connections0
1. 從 storage_cluster_name 標籤建立與 ONTAP 儲存空間叢集的 SSH 連線。
2. 使用 source_node 和 destination_ip 標籤中的值，在 ONTAP 叢集上執行下列指令：
```
ping -node <node-name> -destination <destination-ip> -verbose -show-detail
```
如果 ping 指令失敗，請將問題提報給檔案封鎖工程團隊。如果 ping 指令成功，表示節點連線正常，警報是錯誤觸發。
1. 在 AlertManager 中建立靜音，將 file_block_storage_node_peer_connection_unhealthy 快訊設為靜音，並將 source_node 和 destination_ip 標籤設為指標中的來源節點和目的地 IP。
為所有正常節點建立靜音後，請前往 Grafana，確認警報已停止觸發。

連線恢復後，系統會觸發 file_block_nodes_not_reachable 警報

版本：1.14.3

症狀：在某些環境中，file_block_nodes_not_reachable 警報會觸發，指出 Kubernetes 節點上的一或多個 IPsec 服務與 ONTAP 的連線失敗。file-observability 控制器會使用自訂指標收集器追蹤這些連線的健康狀態。已知問題：即使連線失敗後已恢復正常，系統仍會持續觸發這項快訊。

解決辦法：

請按照下列步驟，確認節點上的連線正常運作，並將節點的快訊設為靜音：

在 Grafana 的探索頁面中，執行查詢 fb_all_nodes_reachable{job="file-observability-backend-target.file-system"}。查詢會傳回叢集中每個節點的指標。如果任何節點回報 fb_all_nodes_reachable 指標為 0，請記下節點名稱。
針對每個傳回 0 的 fb_all_nodes_reachable 指標節點，執行下列指令：
1. 與受影響的節點建立 SSH 連線。
2. 執行下列指令：
```
journalctl -u strongswan | grep "sending packet" | sed "s/\[/ /g" | sed "s/\]/ /g" | awk '{ print $14 }' | sort -n | uniq | awk '{print "ping -c 5 " $1}' | sh
```
  這項指令會嘗試透過所有 IPsec 連線 ping ontap。如果指令中的任何 Ping 失敗，請將問題提報給檔案封鎖工程團隊。如果 ping 指令成功，表示節點連線正常，警報是錯誤觸發。
3. 如果指令中的所有 Ping 都成功，表示節點上的連線正常，警報是誤觸。在 AlertManager 中建立靜音，將 node_name 標籤設為節點名稱，即可讓 file_block_nodes_not_reachable 快訊靜音。
為所有正常節點建立靜音後，請前往 Grafana，確認警報已停止觸發。

`file_block_storage_high_node_total_latency` 警示會在工作負載過重時觸發

版本：1.14.3

症狀：在某些環境中，由於儲存節點上的工作負載過重，可能會觸發 file_block_storage_high_node_total_latency 快訊。直到這些工作負載完全處理完畢為止，這項快訊都會持續顯示。即使磁碟區的讀寫效能很快，儲存空間節點仍可能回報特定區塊作業的延遲時間較長。

解決辦法：

如要確認磁碟區延遲時間是否正常，並關閉儲存空間節點延遲時間警報，請按照下列步驟操作：

檢查音量延遲警報：
1. 在 Grafana 中，確認 file_block_storage_high_volume_write_latency 和 file_block_storage_high_volume_read_latency 快訊未觸發，且回報的磁碟區延遲時間為最佳。
如果磁碟區延遲時間過長，請呈報上級處理：
1. 如果系統觸發磁碟區寫入或磁碟區讀取快訊，表示整個儲存系統的延遲時間偏高。將這個問題提報給檔案封鎖工程團隊。
如果磁碟區健康狀態良好，請關閉節點延遲警報：
1. 如果磁碟區寫入和磁碟區讀取快訊都正常，節點延遲快訊可能就是誤判。
2. 在 AlertManager 中為 file_block_storage_high_node_total_latency 警報建立靜音。
3. 建立靜音後，請前往 Grafana 確認快訊已停止觸發。

節點升級遭封鎖

版本：1.14.3、1.14.4、1.14.5、1.14.6、1.14.7

症狀：當 LUN (邏輯單元編號) 變成唯讀時，就會發生這種阻斷情形，通常是快照發生問題所致。發生這種情況時，節點會遭到封鎖，以便將受影響的 Pod 移至其他節點。由於節點升級程序會進行前置檢查，確保節點未遭隔離，因此這個狀態會阻止升級程序繼續進行。

解決方法：在啟動升級程序前，手動停用 file-read-only-lun-cleanup 子元件：

找出受影響的每個機構。

為環境中的每個機構套用 SubcomponentOverride。

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: file-read-only-lun-cleanup
  namespace: ORG_NAMESPACE
spec:
  subComponentRef: "file-read-only-lun-cleanup"
  disable: true

確認受影響機構中的節點皆未遭隔離：

列出機構中的節點：

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes

輸出結果會與下列內容相似：

NAME                STATUS                     ROLES           AGE   VERSION
admin-node0-zone1   Ready,SchedulingDisabled   control-plane   14h   v1.30.8-gke.200
admin-node1-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
admin-node2-zone1   Ready                      control-plane   14h   v1.30.8-gke.200

請記下狀態為 SchedulingDisabled 的節點名稱。在這個輸出範例中，遭封鎖的節點是 admin-node0-zone1。

取消封鎖在上一步中傳回 SchedulingDisabled 狀態的節點：
```
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG uncordon NODE_NAME
```

確認所有節點都已準備就緒：

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes

輸出結果會與下列內容相似：

NAME                STATUS                     ROLES           AGE   VERSION
admin-node0-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
admin-node1-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
admin-node2-zone1   Ready                      control-plane   14h   v1.30.8-gke.200

解決多重路徑錯誤後，系統會觸發 `file_block_zombie_luns_present` 快訊

版本：1.14.3 以上版本

症狀：在特定環境中，file-observability 控制器無法剖析 multipath -ll 指令的輸出內容，因此可能會觸發 file_block_zombie_luns_present 警報。即使所有節點上的多重路徑服務運作正常，這種情況仍會導致系統持續觸發無效 LUN 警告。

解決辦法：

如要驗證有問題節點上的多路徑服務是否正常運作，請按照下列步驟操作：

在 Grafana 的探索頁面中，執行查詢 zombie_lun_exists{job="file-observability-backend-target.file-system"}。查詢會傳回叢集中每個節點的指標。如果任何節點回報 zombie_lun_exists 指標為 1，請記下該節點的名稱。
針對每個傳回 1 的 zombie_lun_exists 指標節點，執行下列指令：
1. 與受影響的節點建立 SSH 連線。
2. 執行下列指令：
```
multipath -ll
```
  這個指令會傳回多重路徑服務管理的所有區塊裝置相關資訊。確認所有區塊裝置的狀態都不含 failed undef unknown 或 failed faulty running 字串。
3. 如果任何裝置包含 failed faulty running 狀態，請按照 FILE-R0020 執行手冊操作，解決無效 LUN 的問題。
4. 如果任何裝置包含 failed undef unknown 狀態，請按照 FILE-R0021 執行手冊解決超級殭屍 LUN。
如果節點健康狀態良好，請忽略殭屍 LUN 快訊：
1. 如果任何節點上都沒有無效的區塊裝置，則殭屍 LUN 警報為誤報。
2. 在 AlertManager 中為 file_block_zombie_luns_present 警報建立靜音。
3. 建立靜音後，請前往 ServiceNow 確認快訊已停止觸發。

無法從控制台刪除空白值區

版本：1.14.4 以上版本

症狀：在 GDC 控制台中，您無法刪除空白 bucket。啟用物件版本管理和保留政策後，值區可能會有刪除標記，以及其他版本的物件。您可能會看到類似以下的錯誤訊息：

can't delete bucket containing empty objects: Delete the bucket inside to delete
the object

解決方法：使用 gdcloud storage rm -a 指令刪除物件 (包括刪除標記)，即可刪除值區。

系統 Artifact Registry

Harbor 複製工作停滯

版本：1.14.3

症狀：Harbor 構件複製作業停滯。這個問題會導致構件無法發布至機構，且機構也無法建立。

解決方法：如要解決這個問題，請按照 SAR-R1010 執行手冊中的步驟操作。

在調解 Harbor 機器人帳戶自訂資源時，未清除暫時性錯誤狀態

版本：1.14.3

症狀：標有 kind=HarborRobotAccount 和 code=SAR2002 的 CustomResourceErrorStatusAlert 快訊會錯誤啟動。舉例來說，錯誤快訊的 message 欄位設為「Error getting robot: failed to list robots: 503 Service Unavailable」。

解決方法：請基礎架構營運人員 (IO) 按照下列操作說明，確認警報是真正問題還是誤報，如果是誤報，請將警報設為靜音。

快訊觸發時，請按照應對手冊 SAR-E2002 找出並解決快訊的根本原因。

由於這項已知問題，即使 Runbook 成功解決根本原因，系統仍可能繼續誤發快訊。持續檢查收到快訊的目標 HarborRobotAccount (HRD) 自訂資源 (CR) 物件的錯誤狀態：

設定必要環境變數：
```
export KUBECONFIG=KUBECONFIG
export HRD_NAME=HRD_NAME
export HRD_NAMESPACE=HRD_NAMESPACE
```
更改下列內容：
- KUBECONFIG：kubeconfig 檔案的路徑。
- HRD_NAME：目標 HarborRobotAccount CR 的名稱。
- HRD_NAMESPACE：包含目標 HarborRobotAccount CR 的命名空間。

檢查目標 HarborRobotAccount CR 的錯誤狀態：

kubectl get harborrobotaccount ${HRD_NAME?} -n ${HRD_NAMESPACE?} -ojsonpath='{.status.errorStatus} {"\n"}'

如果 lastUpdateTime 值指出 errorStatus 欄位上次更新時間超過 30 分鐘前，則這項快訊為誤報。如要減少誤報，請按照 MON-R2009 執行手冊，在 GDC 氣隙隔離執行個體中將快訊設為靜音。

SAR-R0003 警報誤報

版本：1.14.3 以上版本

症狀：系統誤觸代碼為 SAR-R0003、OC SAR 且嚴重程度為 critical 的快訊。

解決方法：按照 MON-R2009 執行手冊的說明，忽略快訊。

票務系統

ServiceNow MID Server 無法正常啟動

版本：1.14.3

修正：1.14.4

症狀：與 Splunk 整合的 ServiceNow MID Server 無法在啟動時向 ServiceNow 註冊，原因是版本不符。

解決辦法：

暫停 ts-mid-server 子元件。

KUBECONFIG=ROOT_ADMIN_KUBECONFIG kubectl annotate subcomponent ts-mid-server -n gdchservices lcm.private.gdc.goog/paused=true

覆寫 MID 伺服器版本字串。

KUBECONFIG=GDCHSERVICES_ADMIN_KUBECONFIG kubectl set env statefulset/midserver-set -n support MID_CONFIG_mid__pinned__version=washingtondc-12-20-2023__patch5-06-21_06-26-2024_1335

升級

叢集升級成功後，共用服務叢集註解未更新

版本：1.14.4

症狀：升級後，clusters.baremetal.cluster.gke.io 的邊界和共用服務叢集 CR 會反映正確的 GKE 版本。clusters.cluster.gdc.goog CR 仍會顯示先前的 GKE 版本。

解決方法：將 clusters.baremetal.cluster.gke.io 中的註解 upgrade.gdc.goog/version 更新為與升級後 GKE 版本對應的新 UserClusterMetadata 名稱。

機構管理員節點升級作業停滯

版本：1.14.6

固定：1.14.7

症狀：gdchservices 機構的管理控制層節點升級程序停滯。無法與節點建立 SSH 連線，導致節點升級失敗，並出現 Connection timed out 錯誤。

外掛程式升級作業停滯

版本：1.14.6

固定：1.14.7

症狀：從任何先前的 1.14.x 版本升級至 1.14.6 時，根管理員叢集的附加元件升級作業會停滯。狀態訊息可能會指出升級作業超出預期時間限制：

message: 'UPG1401: addon upgrade expected to finish within 2h0m0s but hasn''t
      after 8h8m24.00395866s, last message was: Addon upgrade for root-admin cluster
      in progress'

解決方法：手動更新 root-admin addonset 資源的 spec.addOnSetTemplateRef，指向新版本的正確範本。

支援報告失敗

版本：1.14.3、1.14.4、1.14.5、1.14.6

固定：1.14.7

症狀：由於權限問題，為使用者叢集執行 gdcloud resource-support get-report 指令時會失敗。

OS 節點升級完成後，VM 可能會無法啟動

版本：1.14.6

症狀：在 1.14.3 至 1.14.6 升級期間，周邊或共用服務叢集中的虛擬機器無法啟動，且在作業系統升級後無法連線。

舉例來說，下列指令可確認問題：

kubectl --kubeconfig CP_KUBECONFIG logs -n VM_NAMESPACE VIRT_LAUNCHER_POD_NAME -c guest-console-log

VM 控制台記錄輸出內容會顯示類似下列內容的 Kernel Panic 訊息：

[    2.005806] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    2.008100] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 #1
[    2.011153] Hardware name: KubeVirt None/RHEL, BIOS 1.14.0-2 04/01/2014
[    2.013401] Call Trace:
[    2.015365]  dump_stack+0x41/0x60
[    2.016641]  panic+0xe7/0x2ac
[    2.017864]  mount_block_root+0x2be/0x2e6
[    2.019176]  ? do_early_param+0x95/0x95
[    2.020287]  prepare_namespace+0x135/0x16b
[    2.021476]  kernel_init_freeable+0x210/0x23a
[    2.022724]  ? rest_init+0xaa/0xaa
[    2.023721]  kernel_init+0xa/0x110
[    2.024698]  ret_from_fork+0x1f/0x40
[    2.025913] Kernel Offset: 0x33c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    2.028706] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

解決方法：如要解決這個問題，請完成下列步驟：

請設定下列環境變數：

export MP_KUBECONFIG=MANAGEMENT_API_KUBECONFIG
export CP_KUBECONFIG=ORG_INFRA_KUBECONFIG
export VM_NAMESPACE=VM_NAMESPACE
export VM_NAME=FAILED_VM_NAME

停止失敗的 VM：

kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE \
    $VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'

開啟編輯器，從失敗的 VM 卸離開機磁碟：

kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAME

在 VM 規格中，將開機磁碟替換為預留位置名稱：

# Several lines of code are omitted here.
spec:
  disks:
  - boot: true
    virtualMachineDiskRef:
      # This is a random placeholder name you put here. Doesn't need to exist
      name: VM_DISK_PLACEHOLDER_NAME

建立開機指令碼密鑰：

cat <<'EOF' > script
#!/bin/bash
username="newuser"
password="Lime+blaze8legend"
sudo useradd -m -s /bin/bash "$username"
echo "$username:$password" | sudo chpasswd
sudo usermod -aG sudo "$username"
EOF

kubectl --kubeconfig=$MP_KUBECONFIG create secret generic configure-password -n $VM_NAMESPACE --from-file=script

建立輔助 VM：

取得 VM 開機磁碟的 VM 映像檔。映像檔的 OS 系列不得與有問題的 VM 節點開機磁碟相同，因此請使用 grep 尋找 Ubuntu 映像檔：

# find the latest ubuntu-20.04 OS version
UBUNTU_OS_VERSION=$(kubectl --kubeconfig $MP_KUBECONFIG get vmimage -A --sort-by=.metadata.creationTimestamp | grep ubuntu-20.04 | tail -n 1 | awk '{print $2}')

建立 VM 開機磁碟和 VM。建立新的開機磁碟和 VM，並附加次要磁碟和開機指令碼，以存取控制台：

kubectl --kubeconfig $MP_KUBECONFIG apply -n $VM_NAMESPACE -f - <<EOF
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
  name: HELPER_VM_BOOT_DISK_NAME
spec:
  source:
    image:
      name: UBUNTU_OS_VERSION
      namespace: vm-system
  size: 20Gi
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachine
metadata:
  name: HELPER_VM_NAME
spec:
  compute:
    virtualMachineType: n3-standard-2-gdc
  disks:
  - virtualMachineDiskRef:
      name: HELPER_VM_NAME-disk
    boot: true
    autoDelete: true
  - virtualMachineDiskRef:
      name: PROBLEM_VM_BOOT_DISK
    autoDelete: false
  startupScripts:
  - scriptSecretRef:
      name: configure-password
    name: configure-password
EOF

確認輔助 VM 正在執行：

kubectl --kubeconfig $MP_KUBECONFIG get gvm -n ${VM_NAMESPACE} HELPER_VM_NAME

控制台，然後重新產生 initramfs：

控制台連線至輔助 VM：

kubectl virt console HELPER_VM_NAME  -n ${VM_NAMESPACE} --kubeconfig=$CP_KUBECONFIG

使用下列憑證：

username="newuser"

password="Lime+blaze8legend"

掛接所連磁碟的分區：

sudo mkdir /mnt/kernelpanic/
sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
sudo mount /dev/sdb2 /mnt/kernelpanic/boot/
sudo mount /dev/sdb1 /mnt/kernelpanic/boot/efi/
sudo mount /dev/rocky/rl-home /mnt/kernelpanic/home/
sudo mount /dev/rocky/rl-var /mnt/kernelpanic/var/
sudo mount /dev/rocky/rl-var_tmp /mnt/kernelpanic/var/tmp/
sudo mount /dev/rocky/rl-var_log /mnt/kernelpanic/var/log/
sudo mount /dev/rocky/rl-var_log_audit /mnt/kernelpanic/var/log/audit/
sudo mount /dev/rocky/rl-tmp /mnt/kernelpanic/tmp/

sudo mount -t sysfs sysfs /mnt/kernelpanic/sys/
sudo mount -t proc procfs /mnt/kernelpanic/proc/
sudo mount -t devtmpfs devtmpfs /mnt/kernelpanic/dev/
sudo mount -t devpts devpts /mnt/kernelpanic/dev/pts/
sudo mount -o bind /dev/pts/ /mnt/kernelpanic/dev/pts/

建立掛接點的 chroot 連線，然後重新產生 initramfs：

sudo chroot /mnt/kernelpanic/
dracut --regenerate-all --force

確認是否已為新核心版本產生新的 initramfs：4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64

ls /boot/initramfs-* -l

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

-rw-------. 1 root root 184937778 Feb  5  2025 /boot/initramfs-0-rescue-e4d67258cb64499f98609307ac4a93e8.img
-rw-------. 1 root root 119867729 Aug  7 17:35 /boot/initramfs-4.18.0-553.16.1.el8_6.ciqfips.0.6.1.x86_64.img
-rw-------. 1 root root  35321114 Aug  7 17:36 /boot/initramfs-4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64.img

停止輔助 VM：

kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE HELPER_VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'

從輔助 VM 卸離磁碟：

在編輯器中開啟輔助 VM 規格：

kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE HELPER_VM_NAME

從 YAML 檔案中移除下列程式碼：

- virtualMachineDiskRef:
    name: PROBLEM_VM_BOOT_DISK
  autoDelete: false

將開機磁碟重新連結至失敗的 VM：

在編輯器中開啟失敗 VM 的規格：

kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAME

更新規格，如下所示：

# Several lines of code are omitted here.
spec:
  disks:
  - boot: true
    virtualMachineDiskRef:
      name: PROBLEM_VM_BOOT_DISK

啟動失敗的 VM：

kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE $VM_NAME --type='merge' -p='{"spec": {"runningState": "Running"}}'

確認升級問題是否已修正：

檢查這個 VM 的 Node 自訂資源是否顯示 Ready，並使用較新的核心版本 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64：

kubectl --kubeconfig=$CP_KUBECONFIG get node NODE_NAME -owide

輸出結果會與下列內容相似：

NAME          STATUS   ROLES           AGE    VERSION            INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                           KERNEL-VERSION                               CONTAINER-RUNTIME
vm-45b03137   Ready    worker          139d   v1.30.12-gke.300   10.204.0.7    <none>        Rocky Linux 8.6 (Green Obsidian)   4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64   containerd://1.6.38-gke.0

建立 VM 的 SSH 連線後，請檢查核心版本：
```
uname -a
```
輸出內容必須顯示新的核心版本 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64。

升級後，擷取器仍處於不良狀態，且不會自動忘記

版本：1.14.x

症狀：升級後，log-infra 子元件未處於正常狀態。如要檢查，請執行： none kubectl --kubeconfig ${KUBECONFIG:?} get subcomponent -n ${CLUSTER_NAMESPACE:?} log-infra 如要檢查子元件的健康狀態，您需要使用父項叢集的 kubeconfig 做為 KUBECONFIG，並使用目前叢集的命名空間做為 CLUSTER_NAMESPACE。指令會傳回子元件的 STATUS。如果 STATUS 不是 ReconciliationCompleted，表示該叢集中的子元件健康狀態不良。

叢集中的部分 Loki Pod 狀況不佳。如要列出所有 Loki Pod，請執行下列指令： none kubectl --kubeconfig ${KUBECONFIG:?} get pods -n obs-system | awk 'NR==1 || /loki/' 這項指令會顯示所有 Loki Pod，包括 STATUS 和 READY 欄。如果 Pod 的 STATUS 不是 Running，或部分容器尚未就緒，系統就會將其視為健康狀態不良。READY 欄會以 a/b 格式顯示就緒容器的數量 a (以總數 b 為準)。當 a 和 b 相等時，Pod 的健康狀態良好。

檢查記錄檔，找出狀況不佳的 Loki Pod： none kubectl --kubeconfig ${KUBECONFIG:?} logs <pod-name> -n obs-system

來自異常 Pod 的輸出記錄檔範例如下：

level=warn ts=2024-12-21T05:01:42.331048596Z caller=ingester.go:385 component=ingester msg="autoforget have seen 2 unhealthy ingesters out of 3, network may be partitioned, skip forgeting ingesters this round"
level=warn ts=2024-12-21T05:01:45.928939929Z caller=lifecycler.go:291 component=ingester msg="found an existing instance(s) with a problem in the ring, this instance cannot become ready until this problem is resolved. The /ring http endpoint on the distributor (or single binary) provides visibility into the ring." ring=ingester err="instance 10.99.196.153:9095 past heartbeat timeout"

解決方法：如要從 Loki 環中刪除狀況不佳的擷取器，請參閱 Runbook AL-R0031。

Vertex AI

翻譯要求可能會產生 `RESOURCE_EXHAUSTED` 錯誤代碼

版本：1.14.3

症狀：傳送翻譯要求後，您會在回應訊息中收到 RESOURCE_EXHAUSTED 錯誤代碼。如果超出系統頻率限制，就會發生這個錯誤。已耗盡資源，例如每位使用者的配額、每秒查詢次數上限，或是整個檔案系統的空間不足。

解決方法：請基礎架構營運商 (IO) 重新啟動翻譯服務後端分片。然後，再次傳送翻譯要求，但要求間隔時間要更長，或傳送較短的要求。

`batchTranslateDocument` 要求傳回錯誤 `503`

版本：1.14.3

症狀：傳送 batchTranslateDocument 要求後，您會在回應訊息中收到 503 "Batch Document translation is not implemented" 錯誤代碼。發生這項錯誤的原因是 BatchTranslateDocument 方法需要 Aspose 服務，而只有在叢集中將 enableRAG 可運作參數設為 true 時，才會部署 Aspose 服務。

解決方法：請基礎架構營運商 (IO) 按照下列步驟，在機構管理叢集中將 enableRAG operable 參數設為 true：

在名為 vai-translation.yaml 的 YAML 檔案中建立 SubcomponentOverride 自訂資源，並將 enableRAG 可操作參數設為 true：

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: "vai-translation"
  namespace: SHARED_SERVICE_CLUSTER_NAMESPACE
spec:
  subComponentRef: "vai-translation"
  backend:
    operableParameters:
      enableRAG: true

將 SHARED_SERVICE_CLUSTER_NAMESPACE 改為共用服務叢集的命名空間。

將 SubcomponentOverride 自訂資源套用至機構管理員叢集：
```
kubectl --kubeconfig ORG_MGMT_KUBECONFIG apply -f vai-translation.yaml
```
將 ORG_MGMT_KUBECONFIG 替換為機構管理員叢集中的管理 kubeconfig 檔案路徑。

翻譯或 OCR 前端 Pod 和服務無法初始化。

版本：1.11.x、1.12.x、1.13.x、1.14.x

症狀：升級期間，系統會重新建立資料庫叢集，導致共用服務叢集上的 ODS 密碼存放區密碼過時且不同步。因此，翻譯或 OCR 前端 Pod 和服務無法初始化。

解決辦法：

在共用服務叢集中刪除密鑰：

kubectl --kubeconfig SHARED_SERVICEG_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n VAI_API_NAMESPACE

將 SHARED_SERVICE_CLUSTER_KUBECONFIG 替換為共用服務叢集中 kubeconfig 檔案的路徑。

如果問題服務是 Translation，請將 VAI_API_NAMESPACE 替換為「g-vai-translation-sie」；如果問題服務是 OCR，請將 VAI_API_NAMESPACE 替換為「g-vai-ocr-sie」。

控制器會自動重建密碼，並與資料庫叢集重新同步。

Vertex AI Search

搜尋處於協調狀態的元件

版本：1.14.6

症狀：如果機構中未建立任何 SearchConfig 自訂資源，vaisearch-conversation 和 vaisearch-frontend 子元件會停留在 Reconciling 狀態。

解決方法：您可以忽略這個問題。建立 SearchConfig 自訂資源後，子元件應完成調解。

伺服器

BIOS 憑證輪替停滯在要求重設階段

版本：1.14.4

症狀：BIOS 憑證輪替作業停滯在「要求重設」狀態。如要驗證這點，請檢查伺服器 bios-credentials 密鑰的 gdch.cluster.gke.io/rotation-status 註解：

kubectl get secret bios-credentials-SERVER_NAME -n gpc-system -o jsonpath='{.metadata.annotations.gdch\.cluster\.gke\.io/rotation-status}'

將 SERVER_NAME 改為伺服器名稱。如果輪替作業停滯，指令輸出內容會是「reset-requested」。

解決方法：如要完成 BIOS 憑證輪替，請按照 SERV-R0018 執行手冊操作。

無法佈建先前安裝的伺服器

版本：1.14.6

症狀：伺服器取消佈建後重新佈建失敗，特別是與 iLO (Integrated Lights-Out) 和 HSM (硬體安全模組) 金鑰管理相關的問題。這些伺服器先前屬於已停用的機構，在佈建映像檔時發生錯誤，表示系統找不到合適的裝置，通常是因為舊金鑰或已刪除的金鑰鎖定磁碟。您可能會看到類似以下的錯誤訊息：

No suitable device was found for deployment - root device hints were not
provided and all found block devices are smaller than 4294967296B

解決方法：刪除並重新安裝受影響的伺服器，協助伺服器進入佈建狀態。詳情請參閱 SERV-R0020 和 SERV-R0021 執行手冊。

虛擬機器

無法匯入圖片

版本：1.14.4。1.14.5

修正版本：1.14.6

症狀：使用 gdcloud compute images import 指令匯入圖片時，由於工作階段逾時，作業會失敗並顯示 Unauthorized 錯誤。

解決方法：使用 KRM API 匯入自備映像檔，而非 gdcloud CLI。

KRM 圖片匯入作業耗時過長

版本：1.14.6 以上版本

症狀：使用 KRM API 匯入映像檔時，需要很長時間才能完成。 VirtualMachineImageImport 資源長時間處於 TranslationJobInProgress 狀態，表示翻譯階段未如預期完成。image-translation Pod 進入 CrashLoopBackOff 狀態。

解決辦法：

請建立名稱不同的新 VirtualMachineImageImport 資源，然後再次嘗試匯入。
請定期檢查資源，監控 VirtualMachineImageImport 狀態，直到狀態變更為 WaitingForTranslationJob 為止。詳情請參閱 VMM R0007 runbook。

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

備份與還原

編輯叢集備份還原方案時發生錯誤

來源磁碟大小無效

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

未套用備份與還原服務等級目標

資料保留政策不會套用至匯入的備份資料

部分 VM 備份失敗

刪除使用者或服務叢集後，清除孤立的備份資源

CLI 或 UI 不支援刪除 VirtualMachineRestore

備份控制層 Pod 因記憶體不足而當機

使用者叢集刪除作業停滯

永久磁碟區要求待處理，導致還原作業停滯

叢集管理

子元件 kub-gpu-controller 無法調解

標準叢集無法移除節點集區

叢集卡在刪除狀態

資料庫服務

AlloyDB Omni 資料庫複製作業停滯

DNS

GlobalCustomerRootDNSServerNotReachable 觸發錯誤快訊

檔案/區塊儲存空間

無法在 VM 中掛接檔案共用磁碟區

防火牆

子網路 CR 中的地址缺少安全性政策規則

GDC 防火牆會拒絕管理和資料層的 OIR 流量

GDC 防火牆拒絕跨區域和跨機構的流量

防火牆不支援識別碼與機構名稱相同的 AttachmentGroup

港灣

備份及還原後，Harbor CLI 密鑰會失效

Harbor 備份與還原作業會爭奪權限

Harbor 備份大小顯示 0 值

Harbor Registry 控制台頁面中的備份資源發生權限錯誤

資料庫密碼輪換作業停滯頁面

硬體安全模組

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

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

啟動後 HSM 失敗，並顯示 ValidateNetworkConfig 錯誤

健康狀態

服務等級目標快訊誤報

無效的指標型服務水準目標設定

身分與存取權管理

無法建立 IAM 角色繫結

無法為專案服務帳戶建立 IAM 角色繫結

新專案建立預先定義角色時發生延遲

GDC 控制台無法建立第一個角色繫結

AOS 無法授予自己在基礎架構叢集中的角色存取權

現有的服務帳戶權杖會失效

基礎架構即程式碼 (IAC)

缺少命名空間，導致子元件協調失敗

IAC ConfigSync 指標收集作業失敗

IAC RootSync 失敗

庫存

商品目錄稽核無法完成對帳

金鑰管理系統

如果 KMS 設定為使用 CTM 根金鑰，當 HSM 無法使用時，系統不會進行容錯移轉

負載平衡器

子網路 CIDR 耗盡，因此無法建立全域負載平衡器

修改負載平衡器資源不會協調服務

系統不會拒絕不正確的區域名稱

全域和區域負載平衡器 Webhook 錯誤

記錄

Loki Pod 在 WAL 重播期間當機或遭到 OOMKilled

驗證解決方法

清除覆寫和物件 Proxy

監控

AlertManager 網頁掛鉤無法傳送部分叢集的快訊

ServiceNow 事件偶爾會重複

基礎架構指標可能過於敏感

對帳指標可能過於敏感

根管理員叢集中有兩則誤報

根管理員控制器管理工具顯示高錯誤率

KUB 資訊主頁在所有 PA 面板中都不會顯示資料

observability-admin-debugger 角色的權限設定錯誤

缺少 Grafana 偵錯工具角色

新增區域後，系統不會顯示跨區域指標和記錄

MonitoringTarget 終結器會封鎖命名空間刪除作業

資訊主頁和資料來源待處理的終結器導致專案刪除作業停滯

無法查看 KSM 的指標

系統指標管道已關閉

子元件 `kub-gpu-controller` 無法調解

啟動後 HSM 失敗，並顯示 `ValidateNetworkConfig` 錯誤

`MonitoringTarget` 終結器會封鎖命名空間刪除作業

調整 `MultiZoneNetworkConfig` 區域順序導致設定取代失敗

使用 `gdcloud config set zone` 指令建立的值區無法刪除

Trident `mkfs.ext4` 錯誤導致 Pod 無法掛接

`file_block_iscsi_sessions_unhealthy alert` 報告誤判

`file_block_storage_disk_failure` 備用磁碟觸發快訊

`file_block_storage_high_node_total_latency` 警示會在工作負載過重時觸發

解決多重路徑錯誤後，系統會觸發 `file_block_zombie_luns_present` 快訊

翻譯要求可能會產生 `RESOURCE_EXHAUSTED` 錯誤代碼

`batchTranslateDocument` 要求傳回錯誤 `503`