備份與還原
1.12.1
磁碟區備份的儲存空間叢集會使用外部 DNS 伺服器，而非轉送器，這會導致磁碟區備份無法解析機構層級的物件儲存空間端點。在 1.12 版中，備份流量需要前往各機構的新路徑。
解決方法：
IO 必須更新儲存空間叢集，才能啟用機構層級的 DNS 解析，並在每個機構中，從複寫邏輯介面 (LIF) 建立到物件儲存空間端點的路徑。複製並貼上啟動程式中的下列指令。
設定 KUBECONFIG 環境變數：
export KUBECONFIG = /root/release/root-admin/root-admin-kubeconfig
找出儲存空間叢集：
storage_cluster = $( kubectl get storagecluster -n gpc-system | awk 'NR == 2{print $1}' )
找出執行個體外部 CIDR：
instance_external_cidr = $( kubectl get cidrclaim -n gpc-system instance-external-cidr -ojsonpath= '{.spec.ipv4Spec.staticCidrBlocks}' )
更新儲存空間叢集，使用轉送器並設定執行個體外部 CIDR 的路徑：
kubectl patch storagecluster " ${ storage_cluster } " -n gpc-system --type= 'json' -p= '[{"op": "replace", "path": "/spec/additionalNetworks/0/destinationSubnets", "value": ' " ${ instance_external_cidr } " '}, {"op": "replace", "path": "/spec/dnsConfig/serviceRef/name", "value": "gpc-coredns-forwarder-udp"}]'
重新啟動控制器，確保變更已實作：
kubectl rollout restart deploy/file-storage-backend-controller -n file-system
備份與還原
1.12.1
症狀：
由於備份子網路沒有通往機構控制層的路徑，因此從 ONTAP 節點捲曲機構管理員 Ingress 閘道會失敗。
解決方法：
IO 必須更新儲存空間叢集，才能啟用機構層級的 DNS 解析，並在每個機構中，從複寫邏輯介面 (LIF) 建立到物件儲存空間端點的路徑。複製並貼上啟動程式中的下列指令。
設定 KUBECONFIG 環境變數：
export KUBECONFIG = /root/release/root-admin/root-admin-kubeconfig
找出儲存空間叢集：
storage_cluster = $( kubectl get storagecluster -n gpc-system | awk 'NR == 2{print $1}' )
找出執行個體外部 CIDR：
instance_external_cidr = $( kubectl get cidrclaim -n gpc-system instance-external-cidr -ojsonpath= '{.spec.ipv4Spec.staticCidrBlocks}' )
更新儲存空間叢集，使用轉送器並設定執行個體外部 CIDR 的路徑：
kubectl patch storagecluster " ${ storage_cluster } " -n gpc-system --type= 'json' -p= '[{"op": "replace", "path": "/spec/additionalNetworks/0/destinationSubnets", "value": ' " ${ instance_external_cidr } " '}, {"op": "replace", "path": "/spec/dnsConfig/serviceRef/name", "value": "gpc-coredns-forwarder-udp"}]'
重新啟動控制器，確保變更已實作：
kubectl rollout restart deploy/file-storage-backend-controller -n file-system
備份與還原
1.12.4
症狀：
如果永久磁碟區處於快照鏡像關係中，就無法刪除。
解決方法：
IO 會刪除以磁碟區為目的地的 SnapMirror 關係。
設定 KUBECONFIG 環境變數：
export KUBECONFIG = /root/release/root-admin/root-admin-kubeconfig
將有問題的 PV 名稱儲存在變數中：
PV_NAME ={ PV_NAME }
取得內部磁碟區名稱：
volume_name = $( kubectl get pv ${ PV_NAME ? } -o jsonpath = '{.spec.csi.volumeAttributes.internalName}' )
請按照 FILE-A0006 執行手冊中的步驟，取得 ONTAP 存取權。
使用先前收集的密碼，刪除以這個磁碟區為來源的關係：
ssh ${ username ? } @${ mgmt_ip ? } snapmirror delete -source-volume ${ volume_name ? } -destination-path "*"
# enter the password collected from the breakglass secret
備份與還原
1.12.0
如果備份存放區沒有任何錯誤狀態，但系統發出相關快訊，則存放區的快訊指標可能錯誤發出。這是 1.12.0 版的已知問題，已在 1.12.4 版中修正。造成這個問題的原因是備份儲存庫會定期嘗試連線至物件儲存空間，進行健康狀態檢查，如果連線失敗，就會進入不健康的狀態。不過，如果備份存放區復原，表示健康狀態的指標不會正確切換回來，導致警報無限期觸發。
如要解決這個問題，可以手動刪除並重新建立備份儲存空間，藉此重設健康狀態指標。按照
BACK-R0003 執行手冊中的步驟，重新建立備份儲存空間。
帳單
1.12.4
症狀：
錯誤訊息：bil-storage-system-cluster - Reconciliation error: E0121- rollback chart: no Job with the name "billing-storage-system-init-job-628" found由於工作過時，bil-storage-system-cluster 子元件無法進行協調。成功完成後，billing-storage-system-init-job-628 和 billing-storage-system-init-job-629 會保留下來。
解決方法：
請完成下列步驟：
備份過時的帳單工作：
cd /root/USERNAME
kubectl --kubeconfig /root/release/gdchservices/gdchservices-system-kubeconfig get jobs billing-storage-system-init-job-628 -n billing-system -o yaml > billing-storage-system-init-job-628.yaml
kubectl --kubeconfig /root/release/gdchservices/gdchservices-system-kubeconfig get jobs billing-storage-system-init-job-629 -n billing-system -o yaml > billing-storage-system-init-job-629.yaml
暫停子元件：
export SUBCOMPONENT_NAME = bil-storage-system-cluster
export SUBCOMPONENT_NAMESPACE = gdchservices-system-cluster
kubectl annotate subcomponent " ${ SUBCOMPONENT_NAME :? } " -n " ${ SUBCOMPONENT_NAMESPACE :? } " lcm.private.gdc.goog/paused= true
刪除過時的工作。
重新啟動「oclcm-backend-controller」。
取消暫停子元件。
區塊儲存空間
1.12.4
症狀：
由於磁碟區掛接錯誤，anthos-identity-service-obs-system 和 platform-obs-obs-system 命名空間中的 Grafana Pod 停滯在 Init 狀態。kubelet 記錄中的錯誤訊息指出多重連結問題。這個問題源自 Trident 的錯誤，因為該錯誤無法正確識別及驗證 LUKS 對應的基礎裝置，導致發生多重附加錯誤。
解決方法：
檢查 PVC 的 deletionTimestamp。如果沒有 deletionTimestamp (Pod 遷移)，請按照下列步驟操作：
檢查 VolumeAttachment，找出目前附加磁碟區的 PVC。
在叢集中，將不符合這個值的 Nodes 隔離。
刪除失敗的 Pod，這會導致該 Pod 遷移回原始 Node。
檢查完畢後，如果發現有 deletionTimestamp (磁碟區刪除)，請按照下列步驟操作：
檢查 VolumeAttachment，找出目前附加磁碟區的 PVC。
在 Node 上，輸出追蹤檔案的內容：
cat /var/lib/trident/tracking/PVC_NAME .json
確認追蹤檔案輸出內容的 devicePath 欄位中找到的 LUKS 裝置確實已關閉。此時，這個路徑不應存在：
stat DEVICE_PATH
驗證序號目前是否對應任何多路徑裝置。
複製追蹤檔案 iscsiLunSerial 欄位中的值。
將這個值轉換為預期的十六進位值：
echo 'iISCSILUNSERIAL >' | xxd -l 12 -ps
使用這個新值，找出多路徑項目是否仍然存在：
multipath -ll | grep SERIAL_HEX
如果不存在，請刪除追蹤檔案。
如果存在，您會看到比搜尋值稍長的序號十六進位值，稱為 multipathSerial。執行下列指令，找出區塊裝置：
multipath -ll MULTIPATH_SERIAL
接著，請執行下列指令，最後一個指令則須為每個區塊裝置分別執行：
systemctl restart iscsid
systemctl restart multipathd
multipath -f MULTIPATH_SERIAL
echo 1 > /sys/block/BLOCK_DEVICE_NAME /device/delete
叢集管理
1.12.0
症狀：
在叢集佈建期間，第二個控制層節點的 machine-init 工作會失敗，並顯示以下訊息：
FAILED! = > { "changed" : true, "cmd" : "/usr/bin/kubeadm join phase control-plane-prepare certs --config /dev/stdin --v 5" .
查看記錄：
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" 輸出內容會顯示非空白結果。
解決方法：
切換 /etc/kubernetes/pki/etcd/ca.crt 的權限。這項作業的時效性非常重要。權限切換必須在上次執行 machine-init 工作後，以及下次執行 machine-init 工作前進行，因為 machine-init 會將權限覆寫回根目錄。
重新啟動第二個節點中的 etcd，從當機迴圈中復原第一個節點中的 etcd。完成這兩個步驟後，第一個節點中的 kube-apiserver 會開始執行，下一個 machine-init 工作也會成功。
叢集管理
1.12.2
症狀：
cilium 代理程式會顯示下列警告：
level = warning msg = "Waiting for k8s node information" error = "required IPv4 PodCIDR not available" subsys = k8s 解決方法：
找出要移除節點的 IP 位址。
從自訂資源的 spec.nodes 中移除 IP 位址。NodePool
等待節點完全從 NodePool 中移除。
如果節點未移除，請執行 force-remove：
將 baremetal.cluster.gke.io/force-remove=true 註解新增至 Machine 自訂資源：
kubectl -n org-1-system-cluster annotate machine IP_ADDRESS baremetal.cluster.gke.io/force-remove= true
將 IP 位址加回 NodePool 自訂資源中的 spec.nodes。
記錄
1.12.0
症狀：
完成匯出至外部 SIEM 系統 的設定後，SIEM 輸入內容不會納入 Fluent Bit 處理管道，且 Kubernetes API 伺服器記錄不會出現在這個 SIEM 中。
網路
1.12.4
症狀：
從 1.12.2 版升級至 1.12.4 版時，如果節點遭到移除，然後隨後重新新增，該節點的 machine-init 程序可能會失敗。
發生這項錯誤的原因是，政策 ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes 拒絕將重新新增節點的網路流量傳送至必要的控制層服務。
這個範例輸出內容中的狀態訊息會醒目顯示這項錯誤：
Feb 17 18 :52:52.330: 30 .0.0.9:41046 ( world) <> 30 .0.0.7:2379 ( host) policy-verdict:none INGRESS DENIED ( TCP Flags: SYN)
Feb 17 18 :52:52.330: 30 .0.0.9:41046 ( world) <> 30 .0.0.7:2379 ( host) Policy denied DROPPED ( TCP Flags: SYN) 解決方法：
如要解決這個問題，請按照下列步驟操作：
如果是根管理員叢集：
從 CIDRClaim/org-external-cidr -n root 取得 CIDR (具體來說是 .status.ipv4AllocationStatus.allocatedCidrBlocks 欄位)。在根管理員叢集中執行下列指令：
ROOTCIDRs = $( ka get cidrclaim/org-external-cidr -n root -o json | jq '.status.ipv4AllocationStatus.allocatedCidrBlocks' )
將這些 CIDR 新增至 ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes，特別是 .spec.ingress.fromCIDR 欄位。在根管理員叢集中，使用下列指令套用這項變更：
ka get ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes -o json \
| jq '.spec.ingress += [{"fromCIDR":' " ${ ROOTCIDRs } " '}]' \
| ka apply -f -
適用於機構管理員叢集：
取得機構的 CIDR (例如 org-1) (具體來說是 .status.ipv4AllocationStatus.allocatedCidrBlocks 欄位)。CIDRClaim/org-external-cidr -n org-1這個指令會針對根管理員叢集執行，以取得「org-1」的 CIDR：
ORGCIDRs = $( ka get cidrclaim/org-external-cidr -n org-1 -o json | jq '.status.ipv4AllocationStatus.allocatedCidrBlocks' )
將這些 CIDR 新增至 ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes，特別是 .spec.ingress.fromCIDR 欄位。在相應的機構管理員叢集中，使用下列指令套用這項變更：
ko get ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes -o json \
| jq '.spec.ingress += [{"fromCIDR":' " ${ ORGCIDRs } " '}]' \
| ko apply -f -
這項變更只需在開始升級前進行一次。
網路
1.12.0
症狀：
在系統叢集的裸機節點上，無法終止兩個 anetd 容器。強制停止程序後，重新啟動 kubelet 和 containerd，anetd Pod 會重新建立，但所有容器都停滯在 podInit，且 containerd 會回報以下錯誤訊息：
` failed to create containerd task: failed to create shim task: context deadline exceeded: unknown` .這樣做會禁止啟動容器網路介面 (CNI)，並停止排定其他 Pod 的時間。
解決方法：
請採取下列緩解措施，避免發生這種節點狀態：
單一節點一次排定的 PVC 不得超過 10 個。請等待這些磁碟掛接完成，再安排更多磁碟。嘗試建立 VM 時，最容易發現這個問題。
更新每個節點上的 /etc/lvm/lvm.conf 檔案，在 devices{} 區塊中加入 filter = [ "r|/dev/dm.|", "r|/dev/sg.|" ] 這行程式碼
如果節點進入某種狀態，導致磁碟區附加和掛接作業逾時，或無法刪除磁碟區，請檢查節點上擱置的 vgs 程序數量，判斷節點是否處於這種特別糟糕的狀態。如要修正處於這種狀態的節點，最可靠的方法是重新啟動節點。
您可能會遇到另一種故障模式。該失敗模式在掛接嘗試時具有下列簽章：mount(2) system call failed: No space left on device。這可能是節點上的掛接傳播所致。請執行 cat /proc/mounts | grep devtmpfs | awk '{ print $2 }' | sort -n | uniq -c 檢查。如果這些值有任何一個大於 1，請刪除使用該值的 Pod，這應該會觸發卸載。如果無法卸載，請手動卸載該路徑。如果仍無法解決問題，請重新啟動裝置。
網路
1.12.2
在某些情況下，由於競爭條件，Google Distributed Cloud (GDC) Air-gapped 無法在 Distributed Cloud 的初始啟動期間，建立必要的交換器 ACL Kubernetes 自訂資源。
症狀：
列出交換器 ACL CR：
kubectl get switchacls -n gpc-system --kubeconfig= /root/release/root-admin/root-admin-kubeconfig 這項指令的輸出內容表示沒有建立任何管理交換器 ACL (mgmt-switch-acl)。
No resources found in gpc-system namespace. 解決方法：
列出流量政策 CR：
kubectl get trafficpolicies -n gpc-system --kubeconfig= /root/release/root-admin/root-admin-kubeconfig 輸出會傳回兩個流量政策 Kubernetes CR：
NAME AGE NAME
default-traffic-policy-data 4d17h default-traffic-policy-data
default-traffic-policy-mgmt 4d17h default-traffic-policy-mgmt
編輯 default-traffic-policy-mgmt 流量政策 Kubernetes CR：
kubectl edit trafficpolicies default-traffic-policy-mgmt -n gpc-system --kubeconfig= /root/release/root-admin/root-admin-kubeconfig
前往這個檔案中的最後一條政策規則，可能位於檔案結尾。
找出最後一項政策規則的說明欄位。欄位可能如下所示：
Deny All rule for Management Network
編輯這項說明，並在說明行開頭加入 The：
The Deny All rule for Management Network
儲存檔案並結束。
再次列出 Kubernetes 交換器 ACL CR：
kubectl get switchacls -n gpc-system --kubeconfig= /root/release/root-admin/root-admin-kubeconfig
輸出內容會列出管理交換器 ACL (mgmt-switch-acl)：
NAME AGE NAME
mgmt-switch-acl 23h mgmt-switch-acl
實體伺服器
1.12.1
症狀：
在任何叢集建立期間佈建 Server 時，伺服器可能會標示為已佈建，但缺少 Provision-Ready 條件。因此
NodePool無法使用這個伺服器。NodePool 中的錯誤事件訊息範例如下：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileError xxx Server policy failure PolicyPreflightCompleted( UnreachableError) : { PolicyPreflightCompleted False 3 2023 -11-07 22 :10:56 +0000 UTC UnreachableError reachability err: Failed to connect to the host via ssh: ssh: connect to host xx.xx.xx.xx port 22 : Connection timed out}
解決方法：
執行下列指令碼，重設 ILO：
SERVER_NAME =
ROOT_ADMIN_KUBECONFIG =
ILO_IP = $( kubectl get servers ${ SERVER_NAME } -n gpc-system --template= {{.spec.bmc.ip}} --kubeconfig= ${ ROOT_ADMIN_KUBECONFIG } )
SECRET_NAME = $( kubectl get secrets -o go-template= '{{range $index,$pod := .items}}{{.metadata.name}}{{"\n"}}{{end}}' -n gpc-system --kubeconfig= ${ ROOT_ADMIN_KUBECONFIG } | grep bmc | grep ${ SERVER_NAME } )
ILO_USER = $( kubectl get secrets ${ SECRET_NAME } -n gpc-system --template= {{.data.username}} --kubeconfig= ${ ROOT_ADMIN_KUBECONFIG } | base64 -d)
ILO_PASS = $( kubectl get secrets ${ SECRET_NAME } -n gpc-system --template= {{.data.password}} --kubeconfig= ${ ROOT_ADMIN_KUBECONFIG } | base64 -d)
# Perform iLO Reset
curl -k -u ${ ILO_USER } :${ ILO_PASS } -H "Content-Type: application/json" -H "OData-Version: 4.0" https://${ ILO_IP } /redfish/v1/Managers/1/Actions/Manager.Reset --data '{"ResetType":"ForceRestart"}' -X POST | jq
# Perform server power cycle, start with power off target server
curl -k -u ${ ILO_USER } :${ ILO_PASS } -H "Content-Type: application/json" -H "OData-Version: 4.0" -X POST https://${ ILO_IP } /redfish/v1/Systems/1/Actions/ComputerSystem.Reset --data '{"ResetType":"ForceOff"}' | jq .
# Verify target server powered off successfully
curl -kqs -u ${ ILO_USER } :${ ILO_PASS } https://${ ILO_IP } /redfish/v1/Systems/1 | jq '.PowerState'
# Power server back
curl -k -u ${ ILO_USER } :${ ILO_PASS } -H "Content-Type: application/jsonls " -H "OData-Version: 4.0" -X POST https://${ ILO_IP } /redfish/v1/Systems/1/Actions/ComputerSystem.Reset --data '{"ResetType":"On"}' | jq .
在極少數情況下，上述 iLO 重設程序可能無法完全解決問題，這時就需要重新佈建伺服器。如需詳細程序，請參閱 OS-P0002 和 OS-P0003 執行手冊。
實體伺服器
1.12.2
症狀：
裸機節點升級作業卡在 in-progress 狀態超過三小時。
解決方法：
按照 SERV-R0005 執行手冊中的步驟操作。
網路
1.12.1
症狀：
POAP 持續失敗，且 POAP 的記錄顯示類似下列的訊息：
2024 Feb 27 20 :20:25 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[ FDO26391GHS] -MAC[ 98 :A2:C0:F8:60:6A] - Running: 'nxos.10.3.1.bin' - /script.sh
2024 Feb 27 20 :20:25 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[ FDO26391GHS] -MAC[ 98 :A2:C0:F8:60:6A] - Target: 'nxos64-cs.10.3.4a.M.bin' - /script.sh您找不到 nxos.10.3.1.bin，但在交換器的 bootflash 目錄中找到類似的項目，例如 nxos64-cs.10.3.1.F.bin。
解決方法：
在啟動程序電腦上完成下列步驟。預先安裝程序進行期間，您必須完成這些步驟。如有數個 /tmp/preinstall-bootstrap- 資料夾，請檢查預先安裝程序的記錄，然後將變更套用至預先安裝程序使用的目前資料夾。如果需要重新啟動預先安裝指令，這項動作也會建立新的 /tmp/preinstall-bootstrap- 資料夾。
前往 /tmp/preinstall-bootstrap-RANDOM_NUMBER 資料夾。
在資料夾中找出 poap.py 檔案。
從這個檔案中完全移除含有 md5 檢查碼的行，讓 head -n 4 poap.py 如下所示：
#!/bin/env python3
import glob
import os
import pkgutil
在同一個檔案中，將下列幾行新增至 version_to_image_file：
"nxos.10.2.1.bin" : "nxos64.10.2.1.F.bin" ,
"nxos.10.2.2.bin" : "nxos64-cs.10.2.2.F.bin" ,
"nxos.10.2.3.bin" : "nxos64-cs.10.2.3.F.bin" ,
"nxos.10.2.4.bin" : "nxos64-cs.10.2.4.M.bin" ,
"nxos.10.2.5.bin" : "nxos64-cs.10.2.5.M.bin" ,
"nxos.10.2.6.bin" : "nxos64-cs.10.2.6.M.bin" ,
"nxos.10.2.7.bin" : "nxos64-cs.10.2.7.M.bin" ,
"nxos.10.3.1.bin" : "nxos64-cs.10.3.1.F.bin" ,
"nxos.10.3.2.bin" : "nxos64-cs.10.3.2.F.bin" ,更新後檔案的區段如下所示：
version_to_image_file = {
"nxos.10.2.1.bin": "nxos64.10.2.1.F.bin",
"nxos.10.2.2.bin": "nxos64-cs.10.2.2.F.bin",
"nxos.10.2.3.bin": "nxos64-cs.10.2.3.F.bin",
"nxos.10.2.4.bin": "nxos64-cs.10.2.4.M.bin",
"nxos.10.2.5.bin": "nxos64-cs.10.2.5.M.bin",
"nxos.10.2.6.bin": "nxos64-cs.10.2.6.M.bin",
"nxos.10.2.7.bin": "nxos64-cs.10.2.7.M.bin",
"nxos.10.3.1.bin": "nxos64-cs.10.3.1.F.bin",
"nxos.10.3.2.bin": "nxos64-cs.10.3.2.F.bin",
"nxos.10.3.3.bin": "nxos64-cs.10.3.3.F.bin",
"nxos.10.3.4a.bin": "nxos64-cs.10.3.4a.M.bin",
}
執行 md5sum poap.py 取得 md5 總和，然後加回 poap.py，讓 head -n 4 poap.py 如下所示：
#!/bin/env python3
#md5sum="396bed5a5f579b80da5fac6edf0b590c"
import glob
import os
網路
1.12.1
從 1.11.x 升級至 1.12.1 時會失敗，因為 pnet 控制器無法成功產生 hairpinlink 自訂資源 (CR)。
解決方法：
升級後，請在根管理員叢集中編輯 clusterroles/pnet-core-backend-controllers-role 檔案。
搜尋 hairpinlinks，然後將 create,update,delete 權限新增至資源。
確認是否已產生 hairpinlinks 和 hairpinbgpsessions CR。
NTP 伺服器
1.12.1
症狀：
執行 kubectl get pods 指令時，您可能會看到下列訊息：
ntp-system ntp-relay-server-75bbf 1 /2 CrashLoopBackOff 123 ( 5m12s ago) 24h
您可能會在記錄中看到存活探查警告：
Warning BackOff 5m55s ( x82 over 28m) kubelet Back-off restarting failed container ntp-image in pod ntp-relay-server-75bbf_ntp-system( 28e4e28f-4f99-4c6e-8c26-d271f0c7995c)
Warning Unhealthy <invalid> ( x37 over 35m) kubelet Liveness probe failed: Leap status is Not synchronised
這個問題可能會導致伺服器時間未同步。
解決方法：
開啟 NTP DaemonSet 進行編輯：
kubectl edit daemonset/ntp-relay-server -n ntp-system
移除「livenessProbe:」區段，直到「timeoutSeconds: 30」行。
在 ntp-image 容器中新增下列區段：
securityContext:
capabilities:
add:
- SYS_TIME
這會產生類似下列的設定：
containers:
- name: ntp-image
image: "DOCKER_REGISTRY /DOCKER_REPOSITORY /ntp-relay-server:DOCKER_TAG "
imagePullPolicy: Always
securityContext:
capabilities:
add:
- SYS_TIME 開啟 OS NTP 政策進行編輯：
kubectl edit ospolicy/bm-ntp-policy -n gpc-system
移除政策部分中的所有 NTP IP 位址。之後，政策會如下所示：
policy:
installPlaybook:
extraVars:
ntp_servers: {}
name: server-ntp-config
secrets: {}
NTP 伺服器
1.12.1
症狀：
執行 kubectl get pods 指令時，您可能會看到下列訊息：
NAMESPACE NAME READY STATUS RESTARTS AGE
ntp-system ntp-relay-job-1707869137-kd7p4 0 /1 CrashLoopBackOff 3 ( 15s ago) 59s 這個問題是由於升級作業清理不當所致。您不必採取任何動作，工作可以留在當機迴圈狀態。
NTP 伺服器
1.12.2
症狀：
您可能會在系統叢集記錄中看到以下訊息：
INFO: task umount:200725 blocked for more than 120 seconds. 如果伺服器未保持時間同步，就會發生問題。設定未正確套用，必須變更為其他命名空間才能正確套用。
解決方法：
請對所有叢集執行下列步驟：
列出現有的 OS 政策：
kubectl get ospolicies -n ntp-system 輸出結果會顯示 admin-ntp-policy 或 worker-ntp-policy。
根據政策名稱，將政策儲存至 .yaml 檔案：
kubectl get ospolicy/admin-ntp-policy -n ntp-system -o yaml > ntp-ospolicy.yaml
kubectl get ospolicy/worker-ntp-policy -n ntp-system -o yaml > ntp-ospolicy.yaml
編輯檔案，將 metadata.namespace 從
ntp-system 變更為 gpc-system，並移除
status: line 和後續所有內容。
將編輯後的檔案套用至叢集：
kubectl apply -f ntp-ospolicy.yaml
請稍候幾分鐘，讓控制器套用 OS 政策。
建立與 OSPolicy 適用的其中一個節點的 SSH 連線，然後執行 cat /etc/chrony.conf。輸出內容會在檔案開頭顯示訊息，指出檔案是由 Ansible 管理，且已從設定中移除 nist.time.gov 或 ntp.pool 伺服器。
VM 備份與還原
1.12.0
症狀：
由於 VM 管理工具中的角色型存取權控管 (RBAC) 和結構定義設定不正確，使用者無法啟動 VM 備份和還原程序。
Internal error occurred: failed calling webhook
"vvirtualmachinebackupplantemplates.virtualmachine.gdc.goog" :
failed to call webhook: Post "https://vmm-vm-controller-webhooks.vm-system.svc:443/validate-virtualmachine-gdc-goog-v1-virtualmachinebackupplantemplate?timeout=10s" :
context deadline exceeded 解決方法：
VM 備份方案名稱是 VirtualMachineBackupPlanTemplate 名稱、資源類型 (vm 或 vm-disk) 和該資源名稱的串連。這個串連字串的長度不得超過 63 個半形字元。
建立及啟動 VM 執行個體 」和「為 VM 建立備份計畫 」。
資料庫服務
1.12.0
症狀：
資料庫服務工作負載會在 Distributed Cloud 系統叢集上的個別專案中佈建及設定。雖然專案用於在 Distributed Cloud 中強制執行管理界線，但不會影響工作負載的執行方式和位置。因此，這些工作負載可與其他資料庫執行個體和各種控制平面系統共用基礎運算基礎架構。
解決方法：
如果資料庫工作負載需要額外的隔離措施，使用者可以要求在系統叢集上建立節點集區。這個節點集區必須在專案建立期間參照，確保資料庫工作負載是在專屬運算基礎架構上佈建及執行。基礎架構運算子必須完成隔離節點集區的設定。
資料庫服務
1.12.2
症狀：
如果是 AlloyDB Omni 15.2.1 版，在同一個節點上建立多個 AlloyDB Omni 叢集時，最後建立的叢集會停滯在調解狀態。使用指令取得 postgresql 記錄
kubectl --kubeconfig $ORG_SYSTEM_KUBECONFIG exec -ti $DATABASE_POD_NAME -n $SHADOW_NS -- cat /obs/diagnostic/postgresql.log
2024 -08-19 21 :20:15.594 UTC: [ 9400 /walwriter] LOG: [ auxprocess.c:129] BaseInit started for AuxProcType: walwriter
2024 -08-19 21 :20:15.595 UTC: [ 9400 /walwriter] LOG: [ auxprocess.c:131] BaseInit finished for AuxProcType: walwriter
*** SIGABRT received at time = 1724102415 on cpu 25 ***
PC: @ 0x7f03140a9d3c ( unknown) ( unknown)
2024 -08-19 21 :20:15.601 UTC: [ 9399 /client backend] alloydbadmin@localhost( 33906 ) [ unknown] postgres 66c3b70f.24b7 57P03:FATAL: [ postmaster.c:2601] the database system is not yet accepting connections
2024 -08-19 21 :20:15.601 UTC: [ 9399 /client backend] alloydbadmin@localhost( 33906 ) [ unknown] postgres 66c3b70f.24b7 57P03:DETAIL: Consistent recovery state has not been yet reached.
@ 0x5557f3b17e31 208 absl::AbslFailureSignalHandler()
@ 0x7f031405afd0 4677136 ( unknown)
@ 0x7f0314e75b20 ( unknown) ( unknown)
[ PID: 9400 ] : *** SIGABRT received at time = 1724102415 on cpu 25 ***
[ PID: 9400 ] : PC: @ 0x7f03140a9d3c ( unknown) ( unknown)
[ PID: 9400 ] : @ 0x5557f3b17f75 208 absl::AbslFailureSignalHandler()
[ PID: 9400 ] : @ 0x7f031405afd0 4677136 ( unknown)
[ PID: 9400 ] : @ 0x7f0314e75b20 ( unknown) ( unknown) 解決方法：
1. 進入資料庫 Pod 的 Shell
kubectl --kubeconfig $ORG_SYSTEM_KUBECONFIG exec -ti $DATABASE_POD_NAME -n $SHADOW_NS -- bash
echo "enable_lux_wal_writer = off" > /mnt/disks/pgsql/data/postgresql.conf.d/55user.conf
supervisorctl restart postgres
Chose default config file: /etc/supervisor/supervisord.conf
postgres: ERROR ( not running)
postgres: started
防火牆
1.12.0
症狀：
在客戶部署期間，檔案管理員使用者名稱必須是 secret.yamladmin。檔案在首次建立後會包含 TO-BE-FILLED。admin 使用者名稱必須用於初始化防火牆上的第一個設定，並透過迴路 IP admin\admin
解決方法：
確認下列防火牆憑證中沒有 TO-BE-FILLED：
CELL_ID /CELL_ID -secret.yamlCELL_ID -ab-rack/CELL_ID -secret.yamlCELL_ID -ac-rack/CELL_ID -secret.yaml確認所有防火牆管理員帳戶都使用 admin 這個使用者名稱。
防火牆
1.12.2
症狀：
預設 IDPS 防火牆政策不支援直接連線 (DX) 互連 的機構自訂 IP。因此，自訂 IP 無法連線至根管理員中的 Harbor，導致無法使用自訂 IP 建立機構。
解決方法：
如要解除封鎖流量，請手動為機構自訂 IP 建立 SecurityPolicyRule，並部署至 IDPS 防火牆。請按照 runbook FW-G0002
1. 在根防火牆虛擬系統中建立輸入 SecurityPolicyRule，允許機構自訂 IP 存取根 Harbor
apiVersion: firewall.private.gdc.goog/v1alpha2
kind: SecurityPolicyRule
metadata:
labels:
firewall.private.gdc.goog/policy-type: idps
name: root-default-ingress-ORG_NAME -custom
namespace: root
spec:
action: allow
destination:
addresses:
- root-external-group
zones:
- vsys1-gpc
firewallVirtualSystemRef:
name: vsys1-root
priority: 150
profile:
group: gdch-threat-profile-group
type: group
service:
option: selected
ports:
- ports: "123"
protocol: UDP
- ports: "1122"
protocol: TCP
- ports: "5140"
protocol: TCP
- ports: "10443"
protocol: TCP
source:
addresses:
- org.customIPConfig.externalCIDRs # example: 30.0.0.0/22
zones:
- vsys1-cp
2. 在機構防火牆 vsys 中建立 Ingress SecurityPolicyRule，允許根目錄存取機構 APIServer。
apiVersion: firewall.private.gdc.goog/v1alpha2
kind: SecurityPolicyRule
metadata:
labels:
firewall.private.gdc.goog/policy-type: idps
name: ORG_NAME -custom-default-ingress-root
namespace: ORG_NAME # example: gpu-org-1
spec:
action: allow
destination:
addresses:
- org.customIPConfig.externalCIDRs # example: 30.0.0.0/22
zones:
- ORG_VSYS_ID -gpc # example: vsys3-gpc
firewallVirtualSystemRef:
name: ORG_VSYS_ID -ORG_NAME # example: vsys3-gpu-org-1
priority: 110
profile:
group: gdch-threat-profile-group
type: group
service:
option: selected
ports:
- ports: "22"
protocol: TCP
- ports: "5140"
protocol: TCP
- ports: "6443"
protocol: TCP
- ports: "10443"
protocol: TCP
source:
addresses:
- root-external-group
zones:
- ORG_VSYS_ID -cp # example: vsys3-cp
3. 觸發防火牆設定替換作業，部署 SecurityPolicyRules。
硬體安全模組
1.12.0
症狀：
由於 CipherTrust Manager 存在已知問題，因此系統仍會偵測到已停用的試用授權，並可能觸發錯誤的到期警告。
解決方法：
請參閱 HSM-R0003 ，確認有效的一般授權，並刪除已停用的試用授權。
硬體安全模組
1.12.0
症狀：
刪除 KMS CTMKey 時，硬體安全模組 (HSM) 會發生非預期行為。舉例來說，機構可能無法啟動 KMS 服務。
解決方法：
使用者可以刪除 KMS 金鑰 (而非 KMS 根金鑰)，藉此加密銷毀資料，這會顯示為 CTMKey。
硬體安全模組
1.12.0
症狀：
取得不明可輪替密鑰清單：
kubectl get rotatablesecret -A | grep -i unknown 輸出內容可能如下所示：
gpc-system yz-aa-hsm01-kmip-certificate HSM-0016 Unknown
gpc-system yz-aa-hsm01-nae-certificate HSM-0016 3d19h <invalid> Unknown
gpc-system yz-aa-hsm01-web-certificate HSM-0016 2d <invalid> Unknown 必要條件：
根管理員叢集的存取權
jq 工具
按照 IAM-R0004 產生根管理員叢集的 KUBECONFIG。
請按照 IAM-R0005 取得根管理員叢集中的 clusterrole/hsm-admin。
解決方法：
取得 HSM 資料網路 IP 位址的清單：
kubectl --kubeconfig ${ KUBECONFIG :? } get hsm -A -o json | jq -r '.items[] | "\(.spec.dataNetwork.ip)"' 輸出內容可能如下所示：
10 .89.3.2
10 .89.3.3
10 .89.3.4
針對上一個步驟中的每個 HSM 資料網路 IP 位址：
將 IP 位址匯出至名為 HSM_DATA_IP 的變數：
export HSM_DATA_IP = HSM_DATA_IP_ADDRESS
擷取網路 (通訊埠 443)、nae (通訊埠 9000) 和 kmip (通訊埠 5696) 伺服器憑證，並檢查憑證的有效性：
openssl s_client -showcerts -connect $HSM_DATA_IP :443 2 >/dev/null | openssl x509 -text
openssl s_client -showcerts -connect $HSM_DATA_IP :9000 2 >/dev/null | openssl x509 -text
openssl s_client -showcerts -connect $HSM_DATA_IP :5696 2 >/dev/null | openssl x509 -text 輸出內容可能如下所示：
Validity
Not Before: Mar 12 20 :36:58 2024 GMT
Not After : Jun 16 20 :36:58 2026 GMT
如果 Not After 日期在今天起 30 天內，請按照 HSM T0016 執行手冊中的步驟更新伺服器憑證。
監控
1.12.0
症狀：
建立機構時，憑證無法就緒：
$ kubectl --kubeconfig /root/release/user/org-1-system-user-kubeconfig get certificate -n mon-system
NAME READY SECRET AGE
mon-node-exporter-backend-consumers False mon-node-exporter-backend-consumers-cert 20h
mon-node-exporter-backend-providers False mon-node-exporter-backend-providers-cert 20h 由於 `SecretForwarder`，密鑰仍存在：
$ kubectl --kubeconfig /root/release/user/org-1-system-user-kubeconfig get secret -n mon-system | grep -E "node-exporter.+cert"
mon-node-exporter-backend-consumers-cert kubernetes.io/tls 3 20h
mon-node-exporter-backend-providers-cert kubernetes.io/tls 3 20h 解決方法：
暫停 Lifecycle Manager，以免重新建立及刪除憑證：
kubectl --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig annotate subcomponent mon-node-exporter -n org-1-system-cluster lcm.private.gdc.goog/paused= "true"
kubectl --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig annotate subcomponent mon-node-exporter -n user-vm-1-cluster lcm.private.gdc.goog/paused= "true"
kubectl --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig annotate subcomponent mon-node-exporter -n user-vm-2-cluster lcm.private.gdc.goog/paused= "true"
kubectl --kubeconfig /root/release/user/org-1-system-user-kubeconfig delete certificate -n mon-system mon-node-exporter-backend-consumers mon-node-exporter-backend-providers 請注意，node-exporter 不會在使用者叢集上完成協調。
監控
1.12.0
症狀：
設定 ServiceNow Webhook 後，生命週期管理 (LCM) 會重新調解並還原對 mon-system 命名空間中 ConfigMap 物件 mon-alertmanager-servicenow-webhook-backend 和 Secret 物件 mon-alertmanager-servicenow-webhook-backend 所做的變更。
解決方法：
暫停 LCM 子元件，讓變更生效，不會遭到還原：
取得根管理員和機構管理員叢集的 kubeconfig 檔案路徑。將路徑分別儲存在 ROOT_ADMIN_KUBECONFIG 和 ORG_ADMIN_KUBECONFIG 環境變數中。
在下列其中一個叢集中暫停 LCM 子元件：
在根管理員叢集中暫停 LCM 子元件：
kubectl --kubeconfig $ROOT_ADMIN_KUBECONFIG annotate subcomponent mon-alertmanager-servicenow-webhook -n root lcm.private.gdc.goog/paused= "true"
在機構管理員叢集中暫停 LCM 子元件：
kubectl --kubeconfig $ORG_ADMIN_KUBECONFIG annotate subcomponent mon-alertmanager-servicenow-webhook -n org-1-system-cluster lcm.private.gdc.goog/paused= "true"
監控
1.12.0
症狀：
系統不會收集部分使用者群組的指標。這個問題會影響使用者 VM 叢集，但不會影響系統叢集。
您可以查看 Prometheus 伺服器的下列記錄：
prometheus-server ts = 2024 -02-21T16:07:42.300Z caller = dedupe.go:112 component = remote level = warn remote_name = cortex-remote-write url = http://cortex-tenant.mon-system.svc:9009/push msg = "Failed to send batch, retrying" err = "server returned HTTP status 500 Internal Server Error: 2 errors occurred:"
您可以從 Cortex 租戶查看下列記錄：
cortex-tenant time = "2024-02-23T18:03:44Z" level = error msg = "proc: src=127.0.0.6:55021 lookup cortex.mon-system.svc on 172.25.38.10:53: no such host"
解決方法：
請按照下列步驟解決問題：
取得叢集的 kubeconfig 檔案路徑。將路徑儲存在 KUBECONFIG 環境變數中。
在使用者 VM 叢集中部署 Stub 服務：
kubectl --kubeconfig $KUBECONFIG apply -f - & lt& ltEOF
apiVersion: v1
kind: Service
metadata:
labels:
app: cortex
name: cortex
spec:
ports:
- protocol: TCP
targetPort: 9009
port: 9009
name: cortex
type: ClusterIP
sessionAffinity: ClientIP
EOF
重新啟動 Cortex 租戶部署作業：
kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n mon-system cortex-tenant
監控
1.12.0
症狀：
基礎架構運算子的 Grafana 執行個體指標可能位於平台管理員的 Grafana 執行個體中，反之亦然。問題的原因是 ASM 跨叢集邊界進行負載平衡要求，而這些叢集邊界有不同的預設租戶。
解決方法：
如要使用這個解決方法，您必須存取 private-cloud 來源，並有權推出元件更新。您必須變更網格設定，將 cortex-tenant 服務限制為只能接收來自本機叢集的流量，並推出 ASM 元件。
開啟 manifests/plain/asm/1.19/asm-primary-cluster-operator.yaml 檔案。
介紹 meshConfig 欄位中的 serviceSettings 欄位。
meshConfig 欄位原本如下所示：
...
profile: minimal
revision: 1 -19
meshConfig:
localityLbSetting:
enabled: false
...
因此，您必須變更 meshConfig 欄位，使其看起來像下列範例：
profile: minimal
revision: 1 -19
meshConfig:
serviceSettings:
- settings:
clusterLocal: true
hosts:
- 'cortex-tenant.mon-system.svc.cluster.local'
localityLbSetting:
enabled: false
將 ASM 元件推出至叢集。
升級
1.12.0
症狀：
從 1.11.0 升級至 1.11.3 時，節點 NodeOSInPlaceUpgradeCompleted 的升級作業會失敗。
ka logs -n gpc-system os-policy-preflight-os-upgrade-bm-86efcc8en8sh2-6h5cn | grep GDCH-OS-ANSIBLE-CHECK -A 50
[ GDCH-OS-ANSIBLE-CHECK]
{
"syntax" : {
"success" : true,
"msg" : ""
} ,
"apply" : {
"reachablity" : {
"success" : true,
"msg" : ""
} ,
"execution" : {
"success" : false,
"msg" : "errors found when simluating play execution on host: 10.3.20.9" ,
"tasks" : [
{
"task" : "os/upgrade : Copy GRUB file to BOOT location" ,
"error" : "Source /boot/efi/EFI/ubuntu/grubx64.efi not found"
}
]
}
} ,
"diff" : null
}
解決方法：
登入要升級的裸機。檢查 fstab 是否有 /boot/efi，以及是否已掛接目錄：
# cat /etc/fstab
LABEL = cloudimg-rootfs / ext4 defaults 0 1
LABEL = UEFI /boot/efi vfat umask = 0077 0 1
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8 :0 0 3 .5T 0 disk
├─sda1 8 :1 0 3 .5T 0 part /
├─sda2 8 :2 0 64 .3M 0 part
├─sda14 8 :14 0 4M 0 part
└─sda15 8 :15 0 106M 0 part 暫停「nodeupgradetask」
執行 mount -a，然後檢查目錄是否已掛接：
# mount -a
root@mb-aa-bm04:~# ls /boot/efi/
EFI
請按照這裡的步驟進行檢查。執行下列指令：
C
# Ensure all three cmds prints `Files are identical`
if [ " $( sha256sum /boot/efi/EFI/ubuntu/shimx64.efi | awk '{ print $1 }' ) " == " $( sha256sum /boot/efi/EFI/BOOT/BOOTX64.EFI | awk '{ print $1 }' ) " ] ; then echo "Files are identical." ; else echo "Files are different." ; fi
if [ " $( sha256sum /boot/efi/EFI/ubuntu/grubx64.efi | awk '{ print $1 }' ) " == " $( sha256sum /boot/efi/EFI/BOOT/grubx64.efi| awk '{ print $1 }' ) " ] ; then echo "Files are identical." ; else echo "Files are different." ; fi
if [ " $( sha256sum /boot/efi/EFI/ubuntu/grub.cfg | awk '{ print $1 }' ) " == " $( sha256sum /boot/efi/EFI/ubuntu/grub.cfg | awk '{ print $1 }' ) " ] ; then echo "Files are identical." ; else echo "Files are different." ; fi
如果並非所有檔案都相同，請在電腦上執行這項指令，然後重複檢查。
/usr/local/update-efi-files.sh
取消暫停「nodeupgradetask」
升級
1.12.0
症狀：
交換器升級無法新增 bootflash：
Conditions:
Last Transition Time: 2024 -01-10T20:06:30Z
Message: exception: add and activate package nxos.CSCwh72780-n9k_ALL-1.0.0-9.3.10.lib32_n9000.rpm: nx-api RPC request failed
with status code 400 and body "{\n\t\"jsonrpc\":\t\"2.0\",\n\t\"error\":\t{\n\t\t\"code\":\t-32602,\n\t\t\"message\":\t\"Invalid params\",\n\t\
t\"data\":\t{\n\t\t\t\"msg\":\t\"Adding the patch (/nxos.CSCwh72780-n9k_ALL-1.0.0-9.3.10.lib32_n9000.rpm)\\n\\n[### ] 10%\\n[#│ # [] 10%\\n[##### ] 20%\\n[####### ] 30%\\n[######### ] 40%\\n[######### ] 4
0%\\n[####################] 100%\\n[####################] 100%\\nInstall operation 21 failed because this patch already exists. at Wed Jan 10 2
1:00:06 2024\\n\\n\"\n\t\t}\n\t},\n\t\"id\":\t1\n}" for requests "install add bootflash:///nxos.CSCwh72780-n9k_ALL-1.0.0-9.3.10.lib32_n9000.rpm
activate forced" 解決方法：
登入發生故障的交換器，並從套件中的交換器執行安裝啟用指令：
install activate nxos.CSCwh72780-n9k_ALL-1.0.0-9.3.10.lib32_n9000.rpm
升級
1.12.1、1.12.2、1.12.4
症狀：
叢集升級作業已停滯超過一小時。裸機維護模式狀態和規格不符。舉例來說，以下指令：
kubectl get baremetalmachines -A -o custom-columns= NAMESPACE:.metadata.namespace,NAME:.metadata.name,MaintenanceMode:.spec.maintenanceMode,Status:.status.underMaintenance 顯示：
root 10 .252.135.4 false true 裸機電腦的預檢工作會顯示下列錯誤訊息：
The error was: 'dict object' has no attribute 'stdout' \n\n The error appears to be in '/playbook/roles/machine_check_common/tasks/main.yaml' : line 215 , column 3 , but may\n be elsewhere in the file depending on the exact syntax problem.\n\n The offending line appears to be:\n\n\n - name: Check if bypass the time check in node agent mode\n ^ here\n "} 解決方法：
使用下列指令：
export KUBECONFIG = ${ ROOT_OR_ORG_ADMIN_KUBECONFIG }
kubectl get cluster -A
kubectl annotate cluster ${ CLUSTER_NAME } -n= ${ CLUSTER_NAMESPACE } "baremetal.cluster.gke.io/bypass-check=ntp"
節點 OS
1.11.3
症狀：
手動解決 os-policy Pod 問題後，VM 重新啟動工作會失敗。系統會顯示下列訊息：
ko logs os-policy-preflight-os-reboot-vm-b1fb94147x8r9-nqmvp -n gpc-system
playbook: server-reboot.yaml
{
"custom_stats" : {} ,
"global_custom_stats" : {} ,
"plays" : [
{
"play" : {
"duration" : {
"end" : "2024-01-12T03:50:52.749714Z" ,
"start" : "2024-01-12T03:50:42.694226Z"
} ,
"id" : "5251f140-5a01-5cce-6150-000000000006" ,
"name" : "Run OS Upgrade Tasks"
} ,
"tasks" : [
{
"hosts" : {
"172.20.128.10" : {
"action" : "setup" ,
"changed" : false,
"msg" : "Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out" ,
"unreachable" : true
}
} ,
"task" : {
"duration" : {
"end" : "2024-01-12T03:50:52.749714Z" ,
"start" : "2024-01-12T03:50:42.704562Z"
} ,
"id" : "5251f140-5a01-5cce-6150-00000000000b" ,
"name" : "os/reboot : Gather OS distribution information"
}
}
]
}
] ,
"stats" : {
"172.20.128.10" : {
"changed" : 0 ,
"failures" : 0 ,
"ignored" : 0 ,
"ok" : 0 ,
"rescued" : 0 ,
"skipped" : 0 ,
"unreachable" : 1
}
}
}
[ GDCH-OS-ANSIBLE-CHECK]
{
"syntax" : {
"success" : true,
"msg" : ""
} ,
"apply" : {
"reachablity" : {
"success" : false,
"msg" : "Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out"
} ,
"execution" : {
"success" : false,
"msg" : "" ,
"tasks" : null
}
} ,
"diff" : null
}
[ GDCH-OS-ANSIBLE-CHECK]
Error: reachability err: Failed to connect to the host via ssh: ssh: connect to host 172 .20.128.10 port 22 : Connection timed out
解決方法：
停止並啟動 VM 即可解決問題。按照「啟動及停止 VM 」中的指示操作。
上層網路
1.12.0
症狀：
使用者 VM 叢集卡住，說明處於 ContainerCreating 狀態的 Pod 會顯示下列警告：
# kubectl --kubeconfig path/to/usercluster_kubeconfig describe pods/bm-system-machine-preflight-check-172.204c807f67d2cab60d5d8q58q -n user-vm-1-cluster
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedCreatePodSandBox 108s ( x62 over 79m) kubelet ( combined from similar events) : Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "ec4d2021ae9d76adf49a6d3c88d678b3b5d9
50990daa6ffee3fcfeed8291dfa8" : plugin type = "cilium-cni" name = "cilium" failed ( add) : Unable to create endpoint: [ PUT /endpoint/{ id}][ 429 ] putEndpointIdTooManyRequests 解決方法：
按照 NET-P0001 執行手冊中的步驟，在系統叢集上重新啟動 anetd。
系統構件登錄檔
1.12.1
症狀：
將根機構從 1.11.1 升級至 1.12.1 時，升級作業可能會在外掛程式階段失敗，並出現 Helm 提取錯誤：
harbor-system harbor-harbor-harbor-core-657d86bcf8-zl8d2 1 /1 Running 0 14h
harbor-system harbor-harbor-harbor-core-7d66b4c7c-7g6t4 0 /1 CrashLoopBackOff 155 ( 76s ago) 12h 解決方法：
提交支援要求。詳情請參閱「申請支援 」。
升級
1.12.0
症狀：
升級期間，系統叢集不會安裝 OPA Gatekeeper 子元件。不過，系統會安裝限制條件和強制執行這些限制條件的 Webhook。
系統叢集中的數個 Pod 可能會卡在 TaintToleration 狀態：
mon-system mon-cortex-pre-upgrade-job-mn29x 0 /1 TaintToleration 0 96m <none> zb-aa-bm07 <none> <none>
mon-system mon-kube-state-metrics-backend-d49b868dc-fmp62 0 /2 TaintToleration 0 97m <none> zb-aa-bm07 <none> <none>
mon-system primary-prometheus-shard1-replica0-0 0 /3 TaintToleration 0 103m <none> zb-aa-bm07 <none> <none>
netapp-trident netapp-trident-controller-7ffb4c5f89-rvwjj 0 /5 TaintToleration 0 103m <none> zb-aa-bm07 <none> <none>
obs-system alertmanager-0 0 /2 TaintToleration 0 98m <none> zb-aa-bm07 <none> <none>
obs-system audit-logs-loki-io-0 0 /3 TaintToleration 0 97m <none> zb-aa-bm07 <none> <none>
obs-system log-audit-backend-failure-detector-6lgsq 0 /1 TaintToleration 0 105m <none> zb-aa-bm07 <none> <none>
obs-system meta-alertmanager-0 0 /1 TaintToleration 0 102m <none> zb-aa-bm07 <none> <none>
obs-system meta-alertmanager-servicenow-webhook-5679f48895-ggkg6 0 /2 TaintToleration 0 102m <none> zb-aa-bm07 <none> <none>
platform-obs-obs-system grafana-proxy-server-7b6b79f787-2x92t 0 /2 TaintToleration 0 103m <none> zb-aa-bm07 <none> <none>
vm-system gdch-rocky-yum-repo-distributor-zfwp6 0 /1 TaintToleration 0 97m <none> zb-aa-bm07 <none> <none>
vm-system gdch-rocky-yum-repo-server-568768c97b-c9hm2 0 /2 TaintToleration 0 97m <none> zb-aa-bm07 <none> <none>
Istio
1.12.1
症狀：
容器名稱為「istio-proxy」的 Pod 尚未就緒，且狀態為「ImagePullBackOff」，並發生「Back-off pulling image "auto"」事件。
解決方法：
確認叢集中有 istio-revision-tag-default 修改 Webhook。如果沒有，請等待約 10 分鐘，看看系統是否會自動復原。如果沒有，請提報問題。
如果變動 Webhook 存在，請刪除有問題的 Pod，並確認 Pod 是否恢復運作。.spec.containers[].image 不得為 auto，必須看起來像實際圖片，類似於以下圖片：gcr.io/gke-release/asm/proxyv2:<image version>。
記錄
1.12.1
症狀：
從 1.11.1 升級至 1.12.1 時，Log 元件部署的 ValidatingWebhookConfigurations、MutatingWebhookConfigurations 和 MonitoringRules 可能無法升級。
解決方法：
確認您有 kubectl，且可以存取 IAM-R0004 執行手冊，取得根管理員叢集的 KUBECONFIG。
從根管理員叢集刪除 ValidatingWebhookConfiguration root-admin-private-logging-validation-webhook：
kubectl delete validatingwebhookconfiguration root-admin-private-logging-validation-webhook 從根管理員叢集刪除 MutatingWebhookConfiguration root-admin-private-logging-defaulter-webhook：
kubectl delete mutatingwebhookconfiguration root-admin-private-logging-defaulter-webhook 從根管理員叢集刪除 ValidatingWebhookConfiguration root-admin-logging-webhook：
kubectl delete validatingwebhookconfiguration root-admin-logging-webhook 從根管理員叢集的 infra-obs 命名空間中刪除 MonitoringRule operational-logs-alerts：
kubectl delete monitoringrule operational-logs-alerts -n infra-obs 從根管理員叢集中的 infra-obs namespace 刪除 MonitoringRules audit-logs-alerts、audit-logs-sli-syslog-prober、audit-logs-sli-filelog-prober、audit-logs-sli-fluentbit-to-loki、audit-logs-sli-fluentbit-to-splunk、audit-logs-sli-fluentbit-backlog、audit-logs-sli-loki-ingester-failed-rate、audit-logs-sli-loki-io-up 和 audit-logs-sli-loki-pa-up：
kubectl delete monitoringrule audit-logs-alerts audit-logs-sli-syslog-prober audit-logs-sli-filelog-prober audit-logs-sli-fluentbit-to-loki audit-logs-sli-fluentbit-to-splunk audit-logs-sli-fluentbit-backlog audit-logs-sli-loki-ingester-failed-rate audit-logs-sli-loki-io-up audit-logs-sli-loki-pa-up -n infra-obs 確認根管理叢集中的子元件 log-admin 已準備就緒：
export RECONCILING = "`kubectl get subcomponent log-audit -n root -o json | jq '.status.conditions | .[] | select(.type == " Reconciling") | .status'`" ; if [[ $RECONCILING = ~ "False" ]] ; then echo "log-audit is ready" ; else echo "log-audit is not ready" ; fi 如果成功，指令會列印 log-audit is ready。否則輸出內容為 log-audit is not ready。
確認根管理叢集中的子元件 log-admin 已準備就緒：
export RECONCILING = "`kubectl get subcomponent log-operational -n root -o json | jq '.status.conditions | .[] | select(.type == " Reconciling") | .status'`" ; if [[ $RECONCILING = ~ "False" ]] ; then echo "log-operational is ready" ; else echo "log-operational is not ready" ; fi 如果成功，指令會列印 log-operational is ready。否則輸出內容為 log-operational is not ready。
記錄
1.12.1
由於 log-infra-backend-preinstall 工作發生問題，因此系統不會安裝稽核記錄和作業記錄 Loki，也不會收集記錄。
症狀：
您可能會在系統叢集中看到 CrashLoopBackoff：
obs-system anthos-log-forwarder-5ghbm 2 /3 CrashLoopBackOff 135 ( 3m52s ago) 15h
記錄
1.12.1
症狀：
您可能會在 mon-system 命名空間中看到 Pod 的 OOMKilled 狀態：
NAMESPACE NAME READY STATUS RESTARTS AGE
mon-system cortex-ingester-0 1 /2 OOMKilled 6 ( 3h5m ago) 11h
解決方法：
調高每個擷取器的記憶體，增加擷取器數量，或同時進行這兩項操作。如要這麼做，請在機構管理員叢集上部署 SubcomponentOverride，如下列範例所示：
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
name: mon-cortex-ingester-override
namespace: org-1-system-cluster
spec:
backend:
operableParameters:
ingester:
resourcesLimit:
memory: "6Gi" # 6Gi is the default, increase to add more memory to each ingester
replicas: 4 # 4 is the default, increase to create more ingester instances.
subComponentRef: mon-cortex
升級
1.12.1
症狀：
從 1.11.x 升級至 1.12.1 時，節點升級作業會失敗，並顯示下列錯誤訊息：
{
"lastTransitionTime" : "2024-02-13T22:53:36Z" ,
"message" : "following checks failed, ['check_registry_mirror_reachability_pass']" ,
"observedGeneration" : 3 ,
"reason" : "JobStatus" ,
"status" : "False" , <----
"type" : "MaintenanceModeHealthCheckReady"
} ,
解決方法：
使用下列指令：
kubectl --kubeconfig= ${ ROOT_OR_ORG_ADMIN_KUBECONFIG } annotate cluster ${ CLUSTER_NAME } -n= ${ CLUSTER_NAMESPACE } "baremetal.cluster.gke.io/maintenance-mode-ignore-healthcheck=true"
升級
1.12.1、1.12.2、1.12.4
症狀：
1. OrganizationUpgrade 停滯在 anthosBareMetal、addOn 或 node 階段，並顯示 Succeeded 條件的 Unknown 狀態。
kubectl --kubeconfig= ${ ROOT_ADMIN_KUBECONFIG } get organizationupgrade -n gpc-system ${ ORG_NAME } -o yaml
addOn: {}
anthosBareMetal:
conditions:
- lastTransitionTime: "2024-09-12T12:10:55Z"
message: 'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t
after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin
cluster: in-progress'
observedGeneration: 1
reason: ABMUpgradeTimeout
status: Unknown
type: Succeeded
startTime: "2024-09-12T12:10:55Z"
node:{}
check_registry_mirror_reachability_pass 檢查失敗。
kubectl --kubeconfig= ${ ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG } get baremetalmachines -A -o json | jq '.items[] | select(.status.underMaintenace != .spec.maintenanceMode) | .metadata.name as $name | .status.underMaintenace as $statm | .spec.maintenanceMode as $specm | .status.conditions[] | select(.status == "False") | select(.type == "MaintenaceModeHealthCheckReady")'
{
"lastTransitionTime" : "2024-02-13T19:17:27Z" ,
"message" : "following checks failed, ['check_registry_mirror_reachability_pass']" ,
"observedGeneration" : 3 ,
"reason" : "JobStatus" ,
"status" : "False" ,
"type" : "MaintenaceModeHealthCheckReady"
} ,
解決方法：
使用下列指令：
export KUBECONFIG = ${ ROOT_OR_ORG_ADMIN_KUBECONFIG }
kubectl get cluster -A
kubectl annotate cluster ${ CLUSTER_NAME } -n= ${ CLUSTER_NAMESPACE } "baremetal.cluster.gke.io/maintenance-mode-ignore-healthcheck=true"
升級
1.12.1、1.12.2、1.12.4
症狀：
1. OrganizationUpgrade 停滯在 anthosBareMetal、addOn 或 node 階段，並顯示 Succeeded 條件的 Unknown 狀態。
kubectl --kubeconfig= ${ ROOT_ADMIN_KUBECONFIG } get organizationupgrade -n gpc-system ${ ORG_NAME } -o yaml
addOn: {}
anthosBareMetal:
conditions:
- lastTransitionTime: "2024-09-12T12:10:55Z"
message: 'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t
after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin
cluster: in-progress'
observedGeneration: 1
reason: ABMUpgradeTimeout
status: Unknown
type: Succeeded
startTime: "2024-09-12T12:10:55Z"
node:{}
netutil 的錯誤。
kubectl --kubeconfig= ${ ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG } get healthchecks -n kube-system -o json | jq '.items[].status | select(.lastHealthcheck.lastStatus == "Error")'
{
"lastHealthcheck" : {
"error" : {
"code" : "500" ,
"reason" : "[Errno 2] No such file or directory: /usr/local/bin/abm-tools10.5.23.4/netutil"
} ,
"lastCompletedTime" : "2024-09-14T05:11:39Z" ,
"lastStatus" : "Error" ,
"monitoredComponentVersion" : "1.28.900-gke.112" ,
"version" : "1.28.900-gke.112"
} ,
"lastScheduledTime" : "2024-09-14T05:26:00Z"
}
解決方法：
刪除對應於失敗健康檢查的 Kubernetes 工作
kubectl --kubeconfig= ${ ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG } get job -A -l Command = machine-health-check --field-selector status.successful= 0
NAMESPACE NAME COMPLETIONS DURATION AGE
root bm-system-10.200.0.2-machine-28771464 0 /1 67m 67m
root bm-system-10.200.0.2-machine-28771524 0 /1 7m33s 7m33s
kubectl --kubeconfig= ${ ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG } delete job -A -l Command = machine-health-check --field-selector status.successful= 0
job.batch "bm-system-10.200.0.2-machine-28771464" deleted
job.batch "bm-system-10.200.0.2-machine-28771524" deleted
VM 管理員
1.12.1
症狀：
從 1.11.x 升級至 1.12.x 時，VM 可能會因為 Pod 過多而無法就緒，導致 Bare Metal 節點排空作業遭到封鎖。
解決方法：
重新啟動 VM。
實體伺服器
1.12.1
症狀：
從 1.11.x 升級至 1.12.1 時，NodeUpgrade 包含相同硬體型號的多個版本，導致韌體升級驗證遭到封鎖。
解決方法：
請按照下列步驟修改 NodeUpgrade CR spec：
如果升級適用於 HPE Gen10 伺服器 (GDC-4D)，請移除 ilo6 型號韌體。否則，請移除 ilo5 型號韌體。
保留每個說明中最新 redfishVersion 的項目。2.98 Oct 10 2023 的項目：
- description: SystemBMC
model: ilo5
redfishVersion: 2 .98 Oct 10 2023
- description: SystemBMC
model: ilo5
redfishVersion: 2 .95 Jul 19 2023
實體伺服器
1.12.1
症狀：
Ironic 等待伺服器啟動時發生逾時。狀態會從 cleaning 變更為 clean failed，再變更為 available：
2024 -02-23 18 :53:00.659 1 DEBUG ironic.api.method [ req-3a22ed15-d5cd-4d77-bb0b-0e7a3042e793 - - - - -] Client-side error: Node facc133f-898c-46d4-974b-92e3560892d5 is locked by host 10 .128.120.2, please retry after the current operation is completed. format_exception /usr/lib/python3.6/site-packages/ironic/api/method.py:124判斷切換開關是否已開啟：
curl -kqs -u ${ ILO_USER } :${ ILO_PASS } https://${ ILO_IP } /redfish/v1/Systems/1 | jq '.PowerState' 如果開啟切換開關，輸出會傳回 "On"。
解決方法：
從有問題的伺服器中移除 image 區塊，然後等待伺服器恢復可用狀態。等這些函式可用後，請加回 image 區塊。
實體伺服器
1.12.2
症狀：
您可能會看到類似以下的偵錯訊息：
[ DEBUG] GET https://172.22.240.103/redfish/v1/
2024 /03/22 21 :46:46 [ DEBUG] GET https://172.22.240.111/redfish/v1/Systems/1/
panic: runtime error: invalid memory address or nil pointer dereference如果忽略 iLO 錯誤，並讀取 HTTP 回應 (而非立即傳回)，就會發生這個問題，導致空指標取消參照。
系統構件登錄檔
1.12.1
症狀：
從 1.11.1 升級至 1.12.1 時，Harbor 叢集狀態可能會變成 unhealthy，並顯示下列錯誤：
root@abc-bootstrapper:/home/ubuntu# ka get harborclusters -A
NAMESPACE NAME PUBLIC URL STATUS
harbor-system harbor https://10.252.119.11:10443 unhealthy 診斷步驟：
檢查 harborclusters 的狀態：
root@abc-bootstrapper:/home/ubuntu# ka get harborclusters -A
NAMESPACE NAME PUBLIC URL STATUS
harbor-system harbor https://10.252.119.11:10443 unhealthy 如果狀態不佳，請檢查 Harbor 元件的狀態：
root@abc-bootstrapper:~# ka get pods -n harbor-system
NAME READY STATUS RESTARTS AGE
harbor-harbor-harbor-core-68d9764d8c-rgg4h 0 /1 Running 0 3d2h
harbor-harbor-harbor-exporter-54d559fdb8-nzjk7 1 /1 Running 0 3d2h
harbor-harbor-harbor-jobservice-6f5db4779-sqmlc 1 /1 Running 0 3d2h
harbor-harbor-harbor-portal-8458c847dc-z2l6n 1 /1 Running 0 3d4h
harbor-harbor-harbor-registry-7577f5d9d6-qp45c 3 /3 Running 0 3d4h
harbor-operator-harbor-operator-755b5cfc96-x2bxh 1 /1 Running 0 3d4h
harbor-operator-redisoperator-bf96ffc59-5d457 1 /1 Running 0 3d4h
harbor-operator-redisoperator-bf96ffc59-tbd8j 1 /1 Running 0 3h38m
harbor-operator-redisoperator-bf96ffc59-vlqfl 1 /1 Running 0 3h38m
pg-harbor-db-0 0 /3 Pending 0 3h37m
pg-harbor-db-monitor-776b946c74-c7pt9 0 /1 Pending 0 3h38m
rfr-harbor-redis-0 1 /1 Running 0 3d4h
rfr-harbor-redis-1 1 /1 Running 0 3d4h
rfr-harbor-redis-2 1 /1 Running 0 3h37m
rfs-harbor-redis-64d9d8df4f-fds79 1 /1 Running 0 3d4h
rfs-harbor-redis-64d9d8df4f-p9l9h 1 /1 Running 0 3d3h
rfs-harbor-redis-64d9d8df4f-x5x8c 1 /1 Running 0 3h38m 如果 harbor-core 和 pg-harbor-db 尚未準備就緒，請檢查 harbor-db 的狀態：
root@abc-bootstrapper:~# ka get dbclusters.postgresql.dbadmin.gdc.goog harbor-db -n harbor-system
NAME PRIMARYENDPOINT PRIMARYPHASE DBCLUSTERPHASE
harbor-db 172 .20.0.146 InProgress DBClusterReconciling 如果 harbor-db 處於 InProgress 模式，請檢查是否有任何 root-admin-control-plane 節點處於 UNDERMAINTENANCE 模式。
root@abc-bootstrapper:~# ka get nodepool -A
NAMESPACE NAME READY RECONCILING STALLED UNDERMAINTENANCE UNKNOWN
org-1 admin-control-plane-node-pool 0 0 0 0 0
root root-admin-control-plane 3 0 0 1 0 升級期間，節點預計會處於維護模式。如果某個節點正在維護，您可能沒有足夠的資源來排定 harbor-db。
解決方法：
如要修正這個問題，請按照下列步驟操作：
設定 KUBECONFIG
:
export KUBECONFIG = /root/release/root-admin/root-admin-kubeconfig縮減 dbs 控制器：
kubectl scale --replicas= 0 deployment -n dbs-fleet-system fleet-controller-manager
kubectl scale --replicas= 0 deployment -n dbs-postgres-system pg-controller-manager 在 Pod 範本中，將優先順序類別名稱設為 system-cluster-critical 或 system-node-critical：
kubectl patch statefulset pg-harbor-db -n harbor-system --type= 'json' \
-p= '[{"op": "add", "path": "/spec/template/spec/priorityClassName", "value": "system-cluster-critical"}]' 重新啟動 pg-harbor-db Pod：
kubectl delete pods -n harbor-system pg-harbor-db-0 確認 harborcluster 正常運作後，請調回 dbs 控制器的規模：
kubectl scale --replicas= 1 deployment -n dbs-fleet-system fleet-controller-manager
kubectl scale --replicas= 1 deployment -n dbs-postgres-system pg-controller-manager
系統構件登錄檔
1.12.2
症狀：
工作服務 Pod 無法準備就緒：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Unhealthy 35m ( x8153 over 3d16h) kubelet Readiness probe failed: Get "https://172.16.1.142:8443/api/v1/stats" : net/http: request canceled while waiting for connection ( Client.Timeout exceeded while awaiting headers)
Warning Unhealthy 10m ( x60 over 13h) kubelet Readiness probe failed: Get "https://172.16.1.142:8443/api/v1/stats" : context deadline exceeded
Normal Pulled 5m47s ( x1733 over 3d16h) kubelet Container image "gcr.io/private-cloud-staging/goharbor/harbor-jobservice:v2.8.4-gke.7" already present on machine
Warning BackOff 43s ( x21352 over 3d16h) kubelet Back-off restarting failed container jobservice in pod harbor-harbor-harbor-jobservice-6f59fbf974-q9h9g_harbor-system( 51ab9697-98b9-4315-9ab9-f67b19a28d0a) 解決方法：
重新啟動工作服務 Pod。
kubectl delete pod POD_NAME -n NAMESPACE 輸出如下所示：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 2m20s default-scheduler Successfully assigned harbor-system/harbor-harbor-harbor-jobservice-6f59fbf974-p872s to zx-ab-bm02
Normal Pulling 2m15s kubelet Pulling image "gcr.io/private-cloud-staging/goharbor/harbor-jobservice:v2.8.4-gke.7"
Normal Pulled 2m12s kubelet Successfully pulled image "gcr.io/private-cloud-staging/goharbor/harbor-jobservice:v2.8.4-gke.7" in 3 .25s ( 3 .25s including waiting)
Normal Created 2m12s kubelet Created container jobservice
Normal Started 2m12s kubelet Started container jobservice
在啟動程序中取得機構狀態：
kubectl get org -A 輸出內容可能如下所示：
NAMESPACE NAME CURRENT VERSION DESIRED VERSION READY
gpc-system org-1 1 .12.1-gdch.402 1 .12.1-gdch.402 True
gpc-system org-2 1 .12.1-gdch.402 1 .12.1-gdch.402 True
gpc-system root 1 .12.1-gdch.402 1 .12.1-gdch.402 True
監控
1.12.1
症狀：
從 1.11.1 升級至 1.12.1 時，Cortex Bucket 刪除作業可能會失敗，並顯示以下錯誤訊息：
upgrade_post_root_org_validation.go:74: unable to create cortex client to check metrics creating Cortex client failed: can' t make a metrics API because of an error getting the Cortex pod: unable to find any matching cortex pods using list options / label selector: { TypeMeta:{ Kind: APIVersion:} LabelSelector:app= cortex FieldSelector: Watch:false AllowWatchBookmarks:false ResourceVersion: ResourceVersionMatch: TimeoutSeconds: Limit:0 Continue: SendInitialEvents:}
upgrade_post_root_org_validation.go:117: Bucket( s) not ready: 3 errors occurred:
* Bucket "obs-system/cortex-metrics-alertmanager" not ready
* Bucket "obs-system/cortex-metrics-blocks" not ready
* Bucket "obs-system/cortex-metrics-ruler" not ready解決方法：
請按照下列步驟強制刪除 bucket：
完成 MON-R0017 繁瑣工作中的步驟，即可存取 StorageGRID UI。
在使用者介面中前往 bucket。
按一下「Delete objects in bucket」(刪除 bucket 中的物件)
監控
1.12.0
症狀：
Prometheus StatefulSet 物件設定有誤，使用的是 standard 儲存空間類別，而非 standard-rwo。這個問題會導致監控元件無法啟動 Anthos Prometheus StatefulSet 物件。
發生這個問題的原因是 ObservabilityPipeline 調解器只會在第一次安裝時設定這個值，而 ObsProjectInfra 調解器會監控叢集自訂資源。
解決方法：
在機構管理員叢集中重新啟動 fleet-admin-controller 部署作業，即可解決問題。
監控
1.12.2
症狀：
mon-common 子元件必須在機構管理員叢集中部署 Istio Telemetry 物件，才能防止系統記錄 Cortex 的所有要求。但建構檔案不含資訊清單檔案。
解決方法：
請按照下列步驟，在機構管理員叢集中部署 Istio Telemetry 物件：
在機構管理員叢集的 mon-system 命名空間中，建立定義 Istio Telemetry 自訂資源 (CR) 的 YAML 檔案：
# Disable access logging from workloads internal to GDCH.
# Telemetry CR to disable Istio access logs from obs-system namespace.
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
name: disable-audit-logging
namespace: mon-system
spec:
accessLogging:
- providers:
- name: otel
disabled: true 將資訊清單檔案套用至 mon-system 命名空間中的機構管理員叢集：
kubectl apply -f disable-audit-logging.yaml
監控
1.12.0
症狀：
已觸發快訊 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
解決方法：
請按照下列步驟解決問題：
設定下列環境變數：
KUBECONFIG：叢集中 kubeconfig 檔案的路徑。TARGET_CLUSTER：要解決問題的叢集名稱。
在所有叢集上暫停 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
在每個管理員叢集上重新啟動 MON 管理員控制器：
kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n obs-system mon-admin-backend-controller
每註冊一個探測器，Prober ConfigMap 就會填入資料。
請按照 Runbook MON-R2009 忽略 MON-A0001 警報 Blackbox monitoring metrics pipeline down，因為這則警報會持續觸發。
節點平台
1.12.1
症狀：
從 1.11.x 升級至 1.12.x 時，切換映像檔下載 Pod 可能會停留在 ErrImagePull 狀態，並顯示下列警告：
Warning Failed 145m ( x4 over 169m) kubelet Failed to pull image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" : failed to pull and unpack image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" : failed to resolve reference "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" : failed to do request: Head "https://10.252.119.4:5000/v2/library/private-cloud-staging/switch-image-downloader/manifests/1.12.1-gdch.330?ns=gcr.io" : dial tcp 10 .252.119.4:5000: connect: no route to host
Warning Failed 45m ( x262 over 25h) kubelet Failed to pull image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" : failed to pull and unpack image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" : failed to resolve reference "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" : pulling from host 10 .252.119.11:10443 failed with status code [ manifests 1 .12.1-gdch.330] : 401 Unauthorized
Normal Pulling 40m ( x287 over 26h) kubelet Pulling image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330"
Normal BackOff 22s ( x6504 over 25h) kubelet Back-off pulling image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" 解決方法：
如要修正這個問題，請將圖片重新標記為 pnet-core-switch-image-downloader，然後再標記為 switch-image-downloader。
節點平台
1.12.1
症狀：
從 1.11.x 升級至 1.12.1 時，主機防火牆會因主機防火牆使用的介面不符，而封鎖交換器映像檔下載作業。
解決方法：
如果您要從 1.11.x 升級至 1.12.x，請先套用下列解決方法。
更新根管理員和機構管理員叢集。
取得根管理員裸機節點和機構管理員裸機節點的節點集區名稱和命名空間。如果是根管理員叢集，請使用根管理員 kubeconfig。下列指令會列出機器清單，並依裸機篩選清單：
kubectl --kubeconfig= KUBECONFIG get inventorymachines -l cluster.private.gdc.goog/provisioner= baremetal-provisioner.cluster.private.gdc.goog -o json | jq -c -r '.items[].spec.nodePoolRef | [.name, .namespace] | @csv | sub("\"";"";"g")' | sort | uniq
admin-control-plane-node-pool,org-1
root-admin-control-plane,root 輸出內容中的值對應下列項目：
ORG_ADMIN_NODEPOOL_NAME：admin-control-plane-node-poolORG_ADMIN_NODEPOOL_NAMESPACE：org-1ROOT_ADMIN_NODEPOOL_NAME：root-admin-control-planeROOT_ADMIN_NODEPOOL_NAMESPACE：根目錄
在 root-admin 和 org-admin 叢集中建立下列物件，將節點上的 eth0 重新命名為 mgmt0：
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
name: eth0-to-mgmt0-int-rename
namespace: gpc-system
spec:
playbook: |
- name: Rename interface from eth0 to mgmt0
hosts: all
gather_facts: no
tasks:
- name: Rename interface in netplan file
ansible.builtin.lineinfile:
path: /etc/netplan/50-cloud-init.yaml
regexp: '^(.*)set-name: eth0(.*)$'
line: '\1set-name: mgmt0\2'
backrefs: true
register: netplan
- name: Disable cloud-init network configuration
ansible.builtin.lineinfile:
path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
line: 'network: {config: disabled}'
state: present
create: true
- name: Restart netplan
command: netplan apply
when: netplan.changed
---
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
name: interface-renaming
namespace: gpc-system
labels:
ospolicy.system.private.gdc.goog/override-maintenance: "true"
spec:
interval:
period: 1m
inventory:
- apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
name: ${ ORG_ADMIN_NODEPOOL_NAME }
namespace: ${ ORG_ADMIN_NODEPOOL_NAMESPACE }
- apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
name: ${ ROOT_ADMIN_NODEPOOL_NAME }
namespace: ${ ROOT_ADMIN_NODEPOOL_NAMESPACE }
policy:
installPlaybook:
name: eth0-to-mgmt0-int-rename
部署上述 YAML 檔案後，NODEPOOL_NAME 和 NODEPOOL_NAMESPACE 欄位會填入相應叢集中的所有節點集區清單。
以下是根管理員叢集的 yaml 檔案範例，其中包含實際的根管理員節點集區和機構管理員節點集區名稱：
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
name: eth0-to-mgmt0-int-rename
namespace: gpc-system
spec:
playbook: |
- name: Rename interface from eth0 to mgmt0
hosts: all
gather_facts: no
tasks:
- name: Rename interface in netplan file
ansible.builtin.lineinfile:
path: /etc/netplan/50-cloud-init.yaml
regexp: '^(.*)set-name: eth0(.*)$'
line: '\1set-name: mgmt0\2'
backrefs: true
register: netplan
- name: Disable cloud-init network configuration
ansible.builtin.lineinfile:
path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
line: 'network: {config: disabled}'
state: present
create: true
- name: Restart netplan
command: netplan apply
when: netplan.changed
---
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
name: interface-renaming
namespace: gpc-system
labels:
ospolicy.system.private.gdc.goog/override-maintenance: "true"
spec:
interval:
period: 1m
inventory:
- apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
name: admin-control-plane-node-pool
namespace: org-1
- apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
name: root-admin-control-plane
namespace: root
policy:
installPlaybook:
name: eth0-to-mgmt0-int-rename 將 YAML 檔案套用至根管理員叢集：
kubectl --kubeconfig= ROOT_ADMIN_KUBECONFIG -f YAML_FILE_NAME
更新系統叢集：
取得機器清單，並依裸機篩選清單：
kubectl --kubeconfig= _ORG_ADMIN_KUBECONFIG get inventorymachines -l cluster.private.gdc.goog/provisioner= baremetal-provisioner.cluster.private.gdc.goog -o json | jq -c -r '.items[].spec.nodePoolRef | [.name, .namespace] | @csv | sub("\"";"";"g")' | sort | uniq
worker-node-pool-o1-highgpu1-48-gdc-metal,org-1-system-cluster 輸出內容中的值對應下列項目：
SYSTEM_CLUSTER_NODEPOOL_NAME：worker-node-pool-o1-highgpu1-48-gdc-metalSYSTEM_CLUSTER_NODEPOOL_NAMESPACE：org-1-system-cluster
NODEPOOL_NAME 和 NODEPOOL_NAMESPACE 欄位會從前一個指令的輸出內容清單填入。
在系統叢集中建立下列物件，將節點上的 eth0 重新命名為 mgmt0，並更新 OS 政策：
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
name: eth0-to-mgmt0-int-rename
namespace: gpc-system
spec:
playbook: |
- name: Rename interface from eth0 to mgmt0
hosts: all
gather_facts: no
tasks:
- name: Rename interface in netplan file
ansible.builtin.lineinfile:
path: /etc/netplan/50-cloud-init.yaml
regexp: '^(.*)set-name: eth0(.*)$'
line: '\1set-name: mgmt0\2'
backrefs: true
register: netplan
- name: Disable cloud-init network configuration
ansible.builtin.lineinfile:
path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
line: 'network: {config: disabled}'
state: present
create: true
- name: Restart netplan
command: netplan apply
when: netplan.changed
---
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
name: interface-renaming
namespace: gpc-system
labels:
ospolicy.system.private.gdc.goog/override-maintenance: "true"
spec:
interval:
period: 1m
inventory:
- apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
name: ${ SYSTEM_CLUSTER_NODEPOOL_NAME }
namespace: ${ SYSTEM_CLUSTER_NODEPOOL_NAMESPACE }
policy:
installPlaybook:
name: eth0-to-mgmt0-int-rename 系統叢集的 yaml 檔案範例 (含實際節點集區名稱) 可能如下所示：
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
name: eth0-to-mgmt0-int-rename
namespace: gpc-system
spec:
playbook: |
- name: Rename interface from eth0 to mgmt0
hosts: all
gather_facts: no
tasks:
- name: Rename interface in netplan file
ansible.builtin.lineinfile:
path: /etc/netplan/50-cloud-init.yaml
regexp: '^(.*)set-name: eth0(.*)$'
line: '\1set-name: mgmt0\2'
backrefs: true
register: netplan
- name: Disable cloud-init network configuration
ansible.builtin.lineinfile:
path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
line: 'network: {config: disabled}'
state: present
create: true
- name: Restart netplan
command: netplan apply
when: netplan.changed
---
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
name: interface-renaming
namespace: gpc-system
labels:
ospolicy.system.private.gdc.goog/override-maintenance: "true"
spec:
interval:
period: 1m
inventory:
- apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
name: worker-node-pool-o1-highgpu1-48-gdc-metal
namespace: org-1-system-cluster
policy:
installPlaybook:
name: eth0-to-mgmt0-int-rename
將 YAML 檔案套用至機構管理員叢集：
kubectl --kubeconfig= ORG_ADMIN_KUBECONFIG -f YAML_FILE_NAME
網路效能較低
1.12.2
症狀：
預先載入 9.3.10 以下版本的網路交換器無法啟動，因為交換器的預期版本為 10.3(4a)。
解決方法：
手動將交換器韌體從 9.3.5 升級至 9.3.10，然後從 9.3.10 升級至 10.3.4a。
網路效能較低
1.12.2
症狀：
由於交換器上的憑證已過期，交換器沒有最新設定，因此連線會中斷。
解決方法：
輪替交換器上的憑證。
啟用新憑證：
nxapi certificate httpskey keyfile bootflash:api-private-key.pem
nxapi certificate httpscrt certfile bootflash:api-certificate.pem
nxapi certificate enable
檔案和區塊儲存空間
1.12.1
症狀：
升級期間，Linux Unified Key Setup (LUKS) 子元件不會重新部署。如要檢查 file-netapp-trident 子元件：
設定別名：
alias ka = 'kubectl --kubeconfig=/path/to/root-admin/root-admin-kubeconfig'
alias ko = 'kubectl --kubeconfig=/path/to/org-admin/org-admin-kubeconfig'
取得子元件：
ka get subcomponent -n root file-netapp-trident -o yaml
ko get subcomponent -n root file-netapp-trident -o yaml
輸出內容可能如下所示：
conditions:
- lastTransitionTime: "2024-03-28T01:37:20Z"
message: 'Reconciliation error: E0100 - deploy: failed to install chart: release
file-netapp-trident-backend failed, and has been uninstalled due to atomic being
set: cannot patch "standard-rwo" with kind StorageClass: StorageClass.storage.k8s.io
"standard-rwo" is invalid: parameters: Forbidden: updates to parameters are
forbidden. && cannot patch "standard-block" with kind StorageClass: StorageClass.storage.k8s.io
"standard-block" is invalid: parameters: Forbidden: updates to parameters are
forbidden.'
observedGeneration: 1
reason: ReconciliationError
status: "True"
type: Reconciling 在這個範例中，有兩個儲存空間類別失敗：standard-rwo 和 standard-block。
解決方法：
刪除工作無法建立的 StorageClasses，例如 standard-rwo、standard-block、standard-rwo-non-luks 和 standard-block-non-luks。
如要重新建立 StorageClasses，請為叢集重新啟動 oclcm-backend-controller (根叢集和機構管理員叢集的根管理員控制器，系統和使用者叢集的機構管理員控制器)。
如果是 1.12.4 版，請確認已安裝的儲存空間類別是否已將註解 disk.gdc.goog/luks-encrypted: 設為 true (非 LUKS 儲存空間類別除外)。如果註解未設為 true，請重複步驟 1 和 2。
在叢集中重新啟動 netapp-trident 部署作業和 netapp-trident DaemonSet。
確認已為 PersistentVolumeClaim (PVC) 資源建立 LUKS 密鑰。每個 PVC 都必須有 g-luks-$pvc_name 格式的密鑰。
確認 file-netapp-trident 子元件的狀態沒有錯誤。
物件儲存空間
1.12.2
症狀：
將根機構從 1.12.1 升級至 1.12.x 後，升級後驗證會失敗，並顯示下列錯誤：
upgrade_post_root_org_validation.go:121: Bucket( s) not ready: 8 errors occurred:
* Bucket "atat-system/invoice-export-bucket" not ready
* Bucket "mon-system/cortex-metrics-alertmanager" not ready
* Bucket "mon-system/cortex-metrics-blocks" not ready
* Bucket "mon-system/cortex-metrics-ruler" not ready
* Bucket "obs-system/audit-logs-loki-io" not ready
* Bucket "obs-system/cortex-metrics-alertmanager" not ready
* Bucket "obs-system/cortex-metrics-blocks" not ready
* Bucket "obs-system/cortex-metrics-ruler" not ready
解決方法：
請先手動新增終結器，再開始升級。
叢集管理
1.12.1、1.12.2
症狀：
在 Kubernetes 1.27.x 版上執行的使用者叢集，節點集區可能無法初始化，導致使用者叢集無法處理容器工作負載。
解決方法：
請勿使用 Kubernetes 1.27.x 版建立使用者叢集。
虛擬機器
1.12.0
症狀：
如果 Ubuntu 來源映像檔在 sources.list 中包含預設 APT 來源，VM 映像檔匯入作業會在映像檔轉換步驟失敗。
解決方法：
確認來源圖片中的 /var/lib/apt/lists/ 目錄為空白。
虛擬機器
1.12.2
症狀：
取得匯入器 Pod 清單：
kubectl get pods -A | grep import 輸出內容可能如下所示：
user-vm-1-cluster importer-vm-1b19e25c-disk-8dwzz 0 /1 ContainerCreating 0 2d9h
user-vm-1-cluster importer-vm-72b96d39-disk-frv4f 0 /1 CreateContainerError 124 ( 43h ago) 2d9h
user-vm-1-cluster importer-vm-c7a7a320-disk-qjgt2 0 /1 CreateContainerError 124 ( 43h ago) 2d9h
user-vm-2-cluster importer-vm-06ca7e94-disk-b66fz 0 /1 CreateContainerError 124 ( 43h ago) 2d9h
user-vm-2-cluster importer-vm-7e63b71b-disk-jxqfz 0 /1 CreateContainerError 116 ( 43h ago) 2d9h
user-vm-2-cluster importer-vm-e0651556-disk-k8scf 0 /1 CreateContainerError 123 ( 43h ago) 2d9h 記錄檔可能會顯示類似下列的事件：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedAttachVolume 2m14s ( x1630 over 2d9h) attachdetach-controller AttachVolume.Attach failed for volume "pvc-2000efe0-b4a0-4856-899b-7e0c9fd33405" : rpc error: code = Unknown desc = error publishing ontap-san driver: problem mapping LUN /vol/trident_pvc_2000efe0_b4a0_4856_899b_7e0c9fd33405/lun0: results: { http://www.netapp.com/filer/admin results}
status,attr: failed
reason,attr: No such LUN exists
errno,attr: 9017
lun-id-assigned: nil 解決方法：
從錯誤訊息中取得 PersistentVolumeClaim (PVC) 名稱，例如 pvc-2000efe0-b4a0-4856-899b-7e0c9fd33405。
使用這個名稱查閱 PersistentVolume (PV)，並記下 spec.csi.volumeAttributes.internalName 以供稍後使用。
按照 FILE-A0006 執行手冊中的步驟，建立儲存空間叢集的 SSH 連線。
顯示磁碟區，並記下指令傳回的 Vserver 名稱：
volume show -volume INTERNAL_NAME
離線調高音量：
volume offline -volume INTERNAL_NAME -vserver VSERVER_NAME
刪除磁碟區：
volume delete -volume INTERNAL_NAME -vserver VSERVER_NAME
虛擬機器
1.12.1
症狀：
目標叢集 (可能是管理員或系統叢集) 上的 VMRuntime 狀態為「ready = false」，且 kube-system 命名空間中的 network-controller-manager 處於待處理狀態
kubectl --kubeconfig= ${ TARGET_CLUSTER_KUBECONFIG } get vmruntime vmruntime
apiVersion: virtualmachine.private.gdc.goog/v1
kind: VMRuntime
metadata:
...
spec:
...
status:
ready: false
kubectl --kubeconfig= ${ TARGET_CLUSTER_KUBECONFIG } describe deploy network-controller-manager -n kube-system
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedMount 3m36s ( x122 over 3h55m) kubelet MountVolume.SetUp failed for volume "cert" : secret "network-webhook-server-cert" not found
解決方法：
刪除部署 network-controller-manager 後，VMM 運算子應會自動重新建立部署，並提供必要憑證。部署作業應進入 Running 狀態，隨後 VMRuntime 狀態應變更為 ready=true。
kubectl --kubeconfig= ${ TARGET_CLUSTER_KUBECONFIG } delete deploy network-controller-manager -n kube-system
虛擬機器
1.12.2
症狀：
VM 匯入器 Pod 進入當機迴圈，且資料量停滯在匯入狀態超過 90 分鐘。Pod 的狀態可能如下所示：
test-vm-project importer-disk-ops-test-vm-boot-disk-tbdtz 0 /1 CrashLoopBackOff 14 ( 47s ago) 90m 172 .16.20.94 zb-aa-bm08 <none> <none>
test-vm-project importer-test-vm-1-boot-disk-plsxk 1 /1 Running 1 ( 2m53s ago) 8m59s 172 .16.22.244 zb-ab-bm09 <none> <none>
test-vm-project importer-test-vm-2-boot-disk-npjc8 1 /1 Running 6 ( 12m ago) 40m 172 .16.22.180 zb-ab-bm09 <none> <none> 所有磁碟匯入作業最終都會在三小時內完成。
升級
1.12.2
症狀：
失敗訊息可能如下所示：
message: 'Reconciliation error: E0111 - upgrade chart: release unet-nodenetworkpolicy-infra-assets
failed, and has been rolled back due to atomic being set: cannot patch "mgmt-network"
with kind Network: admission webhook "vnetwork.networking.gke.io" denied the
request: Network.networking.gke.io "mgmt-network" is invalid: Spec.NodeInterfaceMatcher:
Forbidden: Field is immutable'
observedGeneration: 2
解決方法：
如果失敗的是根目錄，請在下列步驟中將 KUBECONFIG 替換為根管理員 kubeconfig。
如果失敗的是機構，請在下列步驟中將 KUBECONFIG 換成機構管理員 kubeconfig。
執行下列指令：
alias k = "kubectl --kubeconfig=KUBECONFIG "
k get networks mgmt-network -o json | jq '.spec.nodeInterfaceMatcher.interfaceName'
如果輸出結果為 eth0，請執行下列指令：
k patch network mgmt-network -p '{"metadata":{"finalizers":null}}' --type= merge
刪除 mgmt-network。
k delete network mgmt-network
確認 unet-nodenetworkpolicy-infra 的狀態沒有錯誤。
例如：
alias k = "kubectl kubeconfig=KUBECONFIG "
k get subcomponent unet-nodenetworkpolicy-infra -n org-1
輸出內容如下所示：
NAME AGE STATUS
unet-nodenetworkpolicy-infra 34d ReconciliationCompleted
升級
1.12.2
症狀：
從 1.11.x 升級至 1.12.2 期間或之後，名稱為 bm-system-add-ons-* 的工作可能會失敗，並顯示下列錯誤：
E0326 17 :04:22.997270 1 main.go:180] configdrift: Config drift health check failed
F0326 17 :04:22.997365 1 main.go:184] One or more checks failed.解決方法：
在開始從 1.11 升級至 1.12.2 之前，請將下列註解套用至所有 Kubernetes 叢集。
# To bypass preflight check errors:
baremetal.cluster.gke.io/bypass-check= "vip_subnet"
舉例來說，在根管理員叢集上使用：
kubectl annotate -n root cluster root-admin baremetal.cluster.gke.io/bypass-check= "vip_subnet" --kubeconfig= ROOT_ADMIN_KUBECONFIG
升級
1.12.2
症狀：
從 1.11.1 升級至 1.12.2 時，會發生這個問題。
查看 file-observability 子元件的 .yaml 檔案：
kubectl get subcomponent file-observability -n org-1-system-cluster -o yaml 檔案的 backendStatus 區段中可能會有以下訊息。
message: 'E0100 - deploy: failed to install chart: release file-observability-backend
failed, and has been uninstalled due to atomic being set: deployments.apps
"file-observability-backend-controller" not found' 解決方法：
檢查 file-system 命名空間，確認該命名空間並未在 org-admin cluster 中終止：
kubectl --kubeconfig ORG_ADMIN_KUBECONFIG get namespace file-system
如果正在終止，請刪除 file-system 命名空間中的所有監控目標：
kubectl --kubeconfig ORG_ADMIN_KUBECONFIG delete monitoringtarget -n file-system --all
在 mon-admin 子項啟動前，先暫停 file-observability 子元件，方法是在子元件中新增下列註解：
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG annotate -n org-1 subcomponent file-observability lcm.private.gdc.goog/paused= 'true'
kubectl --kubeconfig ORG_ADMIN_KUBECONFIG annotate -n org-1-system-cluster subcomponent file-observability lcm.private.gdc.goog/paused= 'true'
升級完成後，請移除註解，暫停子元件：
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG annotate -n org-1 subcomponent file-observability lcm.private.gdc.goog/paused-
kubectl --kubeconfig ORG_ADMIN_KUBECONFIG annotate -n org-1-system-cluster subcomponent file-observability lcm.private.gdc.goog/paused-
升級
1.12.2
症狀：
從 1.11.1 升級至 1.12.2 時，會發生這個問題。
完成 hsmupgraderequest 和 ctmclusterupgraderequest 的所有升級步驟後，會出現下列錯誤：
HSMCluster "hsmcluster" is not ready. 例如：
- lastTransitionTime: "2024-04-08T15:18:45Z" message: HSMCluster "hsmcluster" is not ready observedGeneration:
2 reason: ziabhsm01PostUpgradeCheckFailed status: "False" type: AllComplete解決方法：
確認 HSM 升級完成，並取得每個 HSM 的 IP 位址：
kubectl get hsm -A --kubeconfig= ROOT_ADMIN_KUBECONFIG 輸出結果如下所示：
NAMESPACE NAME AGE IP READY REASON
gpc-system zi-aa-hsm01 11d 10 .252.96.192 True ReconcileHSMSuccess
gpc-system zi-ab-hsm01 11d 10 .252.97.192 True ReconcileHSMSuccess
gpc-system zi-ac-hsm01 11d 10 .252.98.192 True ReconcileHSMSuccess
下載並設定 ksctl。
執行 ksctl system info get --url=https://HSM_MANAGEMENT_IP ，確認所有 HSM 版本都已升級至 ctmclusterupgraderequest 的 .Spec.TargetVersion：
輸出結果如下所示：
ksctl system info get
{
"name" : "zi-aa-hsm01" ,
"version" : "2.13.1+10196" ,
"model" : "CipherTrust Manager k570" ,
"vendor" : "Thales Group" ,
"crypto_version" : "1.7.0" ,
"uptime" : "0 days, 1 hours, 20 minutes" ,
"system_time" : "2024-04-08T19:51:27Z"
}
將每個 HSM 的 Status.FirmwareVersion 欄位更新為上一步取得的升級版本：
例如：
kubectl edit-status hsm HSM_NAME -n gpc-system
將 ctmclusterupgraderequest.status.conditions 最後的條件狀態從 False 更新為 True。之後，hsmupgraderequest.status.conditions 最後一個條件的狀態也會變成 true。
例如：
kubectl edit-status ctmclusterupgraderequest CTM_VERSION -n gpc-system
kubectl get ctmclusterupgraderequest CTM_VERSION -n gpc-system -o yaml
升級
1.12.2
升級 期間，伺服器的管理 IP 無法連線，特別是在交換器 OS 升級後。
使用 Rocky Linux 新增靜態路徑時，必須先連上用於連線至靜態路徑的目的地 IP，才能新增靜態路徑。如果交換器在作業系統升級後重新啟動，該管理 IP 可能會暫時無法連線。
解決方法：
使用資料 IP 位址建立伺服器的 SSH 連線，然後重新啟動網路服務，重新建立缺少的靜態路由：
systemctl restart NetworkManager.service
票證系統
1.12.2
症狀：
在知識庫同步 期間，您可能會看到下列錯誤訊息：
Error: Article creation request failed status:400, body:map[ error:map[ detail:Rejected large REST payload with content-length = 10725676 bytes. Max allowed: 10485760 bytes. 解決方法：
新增系統屬性，增加長度上限：
在 ServiceNow 平台中，於導覽篩選器輸入 sys_properties.list。
按一下 [New]
在「Name」(名稱)glide.rest.max_content_length。
在「類型」string」。
在「Value」(值)15。
按一下「提交」
再次同步知識庫。
票證系統
1.12.2
症狀：
手動部署 gdchservices 機構時，票證系統沒有健全的上游，沒有建立 VM，且 support 命名空間中 gdchservices-system 叢集的 midserver Pod 狀況不佳。
解決方法：
在 gdchservices-admin 叢集中，使用正確的 VM 映像檔建立新的 TicketingSystem 自訂資源：
apiVersion: ticketing.private.gdc.goog/v1
kind: TicketingSystem
metadata:
name: as-replacement
namespace: support
spec:
replicas: 2
spec:
image: ts-controller-app-server-2024-02-07-231907
imagenamespace: vm-system
memory: 12G
size: 100G
vcpus: 8
version:
name: glide-vancouver-07-06-2023__patch5-12-01-2023_12-11-2023_2006.zip
升級
1.12.2
症狀：
登入存取權不適用於具有管理 IP 的 VM。您可能會在 anetd Pod 記錄中看到類似以下的錯誤：
Unable to create endpoint:[ PUT /endpoint/{ id}][ 400 ] putEndpointIdInvalid failed setting up layer2 interface
解決方法：
刪除 VM 的 virt-launcher Pod。
升級
1.12.2
症狀：
從 1.11x 升級至 1.12.x 時，您可能會看到類似下列的錯誤：
kubectl --kubeconfig PATH_TO_ROOT_ADMIN_KUBECONFIG get subcomponent -n root mz-etcd -o yaml
kubectl --kubeconfig PATH_TO_ROOT_ADMIN_KUBECONFIG get subcomponent -n org-1 mz-etcd -o yaml升級前，mz-etcd 子元件的規格如下：
spec:
crds:
helmManifestSpec:
chartURL: gcr.io/mz-etcd-crds:1.11.1-gdch.260
upgradeHookPolicy: OnVersionChange
deployTarget: Local
namespace: ""
解決方法：
在根管理員叢集上刪除下列子元件：
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG delete subcomponent -n root mz-etcd
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG delete subcomponent -n org-1 mz-etcd
檢查根命名空間和機構命名空間中的子元件：
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get subcomponent -n root mz-etcd -o yaml
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get subcomponent -n org-1 mz-etcd -o yaml
新子元件必須符合下列規格，且 chatURL 必須顯示叢集已升級的版本：
backend:
helmManifestSpec:
chartURL: gcr.io/mz-etcd-backend:1.12.2-gdch.785
...
dash:
helmManifestSpec:
chartURL: gcr.io/mz-etcd-dash:1.12.2-gdch.785
...
deployTarget: Remote
namespace: mz-system
mon:
helmManifestSpec:
chartURL: gcr.io/mz-etcd-mon:1.12.2-gdch.785
upgradeHookPolicy: OnVersionChange
...
targetClusterName: root-admin
targetClusterNamespace: root
webhooks:
helmManifestSpec:
chartURL: gcr.io/mz-etcd-webhooks:1.12.2-gdch.785
upgradeHookPolicy: OnVersionChange
升級
1.12.2
症狀：
預檢或後檢失敗並出現錯誤。檢查記錄：
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
解決方法：
如果錯誤發生在後續檢查期間，且所有其他檢查都順利完成，請略過後續檢查。升級作業重新啟動時，您也必須使用根管理員 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 org1 && 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如果預檢期間發生錯誤，且所有其他預檢都順利完成，請略過預檢：
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 如果無法套用此解決方法，您可能需要多次嘗試。
ATAT 產品組合
1.12.0
症狀：
ConfigSync 發生錯誤，並顯示以下訊息：
KNV2009: failed to apply Portfolio.atat.config.google.com, atat-system/***: failed to create typed patch object ( atat-system/***; atat.config. ││ google.com/v1alpha1, Kind = Portfolio) : .spec.portfolioName: field not declared in schema.
解決方法：
GDC 1.12 版的 Portfolio 結構定義已變更。portfolioName 欄位已重構為 portfolioID。找出包含錯誤訊息中提及的投資組合自訂資源的 YAML 檔案。將欄位 portfolioName 重新命名為 portfolioID。
升級
1.12.2
症狀：
如果修補程式工作只完成預檢工作，而未建立執行中的工作，可能原因如下：
如果 NTP 失敗，所有其他修補程式工作都無法執行。
節點處於不健康的狀態。
OS 設定代理程式未執行。
OS 設定代理程式無法與 OS 設定服務通訊。
OS 設定服務發生問題。
解決方法：
檢查節點的 `NodeTargetPolicy` CR。
搜尋 `NodeTargetPolicy` CR 的 `.spec.osPolicies`，其中 `ref.name=admin-ntp-policy` 且 `type: Ready` 的狀態為 false：
# Enter the node InventoryMachine name.
NAME =
kubectl get nodetargetpolicy -n gpc-system $NAME -ojsonpath= "{.spec.osPolicies}" | jq
輸出結果如下所示：
- conditions:
- lastTransitionTime: "2024-04-19T19:12:01Z"
message: ""
observedGeneration: 7
reason: Complete
status: "True"
type: PolicyPreflightCompleted
- lastTransitionTime: "2024-04-19T19:12:01Z"
message: ""
observedGeneration: 7
reason: None
status: "True"
type: PolicyConflictNone
- lastTransitionTime: "2024-04-19T19:56:35Z"
message: ""
observedGeneration: 7
reason: Reconciled
status: "True"
type: Ready
diff: os-policy-preflight-admin-ntp-policymf2w4-dpbxw
playbookName: server-ntp-config
ref:
name: admin-ntp-policy
namespace: gpc-system
刪除這些 `osPolicies` 的所有條件，只保留以下部分：
- conditions:
diff: os-policy-preflight-admin-ntp-policymf2w4-dpbxw
playbookName: server-ntp-config
ref:
name: admin-ntp-policy
namespace: gpc-system
升級
1.12.3
症狀：
即使升級的節點是 Ubuntu，NodeUpgrade CR 仍會在規格中提及 version: rocky-86-xyz 。
解決方法：
這項資訊無害，因此不需要替代方法。節點會正確升級至較新版本的 Ubuntu。
SIEM
1.12.0
症狀：
根管理員叢集根目錄和 org-1 命名空間中的 siem-*-preinstall 工作會重複失敗。
解決方法：
停用 SIEMComponent 功能閘道時，工作預計會失敗。失敗不代表元件損壞，如果干擾過多，可以暫停 SIEM 元件的對帳作業，但一般建議盡可能啟用元件。如果元件對帳作業已暫停，日後升級時不再限制安裝 SIEM 元件，就必須手動重新啟用。
節點升級
1.12.0
症狀：
vgs、blkid 和 Ansible 的 gather_facts 可能沒有回應。這個問題會影響 Rocky 和 Ubuntu 作業系統。
如果節點已升級，請執行下列步驟。更新 lvm.conf 檔案的程序包含下列步驟：
取得所有節點的清單，以便將修正檔套用至所有節點。
建立 Ansible Playbook 和 OS 政策檔案。
將修正檔套用至節點。
確認修正程式是否已套用。
必要條件：
按照 IAM-R0004 執行手冊中的步驟，為根管理員叢集產生 ROOTCONFIG，並為機構管理員叢集產生 ORGCONFIG。
請按照 IAM-R0005 執行手冊中的步驟，取得機構的下列角色。
解決方法：
找出與叢集對應的 InventoryMachines：
kubectl --kubeconfig= $ROOTCONFIG get inventorymachines
kubectl --kubeconfig= $ORGCONFIG get inventorymachines 請將輸出內容分開。一次修正一個叢集。輸出內容可能如下所示：
NAME
bm-2bca8e3f
bm-4caa4f4e
建立應對手冊和政策檔案：
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
name: lvm-conf-device-filter-node-update
namespace: gpc-system
spec:
playbook: |
- name: Add a device filter to /etc/lvm/lvm.conf
hosts: all
gather_facts: no
tasks:
# Change lvm.conf
- name: Configure lvm for filtering out "dm" and "sg" devices
ansible.builtin.lineinfile:
path: /etc/lvm/lvm.conf
insertafter: '^(\s+|)devices(\s+|)\{'
line: ' filter = [ \"r|/dev/dm.|\", \"r|/dev/sg.|\" ]'
---
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
name: lvm-conf-device-filter-node-update
namespace: gpc-system
spec:
interval:
period: 1m
inventory:
# this is the inventory from step 1 above,
# see the syntex below
policy:
installPlaybook:
name: lvm-conf-device-filter-node-update
請務必按照這個範例填寫上述目錄部分。
為步驟 1 中找到的每個節點新增一個段落。您一次會處理一個叢集，因此請在清單部分填入一個叢集的節點。
inventory:
# Node: bm-2bca8e3f
- apiVersion: baremetal.cluster.gke.io/v1
kind: InventoryMachine
name: bm-2bca8e3f
# Node: bm-4caa4f4e
- apiVersion: baremetal.cluster.gke.io/v1
kind: InventoryMachine
name: bm-4caa4f4e
將修正檔套用至根管理員叢集：
kubectl --kubeconfig= $ROOTCONFIG apply -f PRECEDING_FILENAME_WITH_ROOT_NODES
將修正檔套用至機構管理員叢集：
kubectl --kubeconfig= $ORGCONFIG apply -f PRECEDING_FILENAME_WITH_ORG_NODES
重新啟動伺服器，新設定就會生效。
請按照 OS-P0005 執行手冊中的步驟，驗證節點是否已更新。
確認政策已順利完成後，請使用 k9s 工具刪除政策：
前往 OS 政策，例如 :ospolicies。
找出並選取 lvm-conf-device-filter-node-update 政策。
按下 Ctrl + D 鍵。
確認刪除。
如要回報這個問題，請使用 SUPP-G0008 執行手冊提出要求。票券應包含下列資訊：
執行的指令及其輸出訊息
詳細資料，例如 InventoryMachineName 和叢集
記錄訊息
作業系統 (OS)
1.12.0
症狀：
如果先前部署環境時使用的是 1.11 版，後來升級至 1.12 版，就會發生這個問題。在 1.12.x 版中建立新叢集或機構時，系統會為裸機和虛擬機器節點佈建選取 Rocky OS，而非 Ubuntu OS，這是因為 ReleaseMetadata 和 Userclustermetadata CR 中指定了 Rocky OS 版本。
解決方法：
請先套用下列解決方法，再建立新機構：
檢查是否有 OrganizationUpgrade CR 不處於 Succeeded: true 狀態：
for item in $( kubectl --kubeconfig= KUBECONFIG get OrganizationUpgrade -A -o custom-columns= NAME:.metadata.name,NAMESPACE:.metadata.namespace --no-headers) ; do
NAME = $( echo $item | awk '{print $1}' )
NAMESPACE = $( echo $item | awk '{print $2}' )
STATUS = $( kubectl --kubeconfig= KUBECONFIG get organizationupgrade ${ NAME } -n ${ NAMESPACE } -o json | jq '.status.conditions[] | select(.type=="Succeeded") | .status' )
if [[ " $STATUS " != "True" ]] ; then
echo "Not in Succeeded: true state, stop following operations"
fi
done 如果是這種情況，請先提報給工程團隊，再繼續進行下一個步驟。
移除所有現有的 OrganizationUpgrade CR，避免節點 OS 意外升級：
for item in $( kubectl --kubeconfig= KUBECONFIG get OrganizationUpgrade -A -o custom-columns= NAME:.metadata.name,NAMESPACE:.metadata.namespace --no-headers) ; do
NAME = $( echo $item | awk '{print $1}' )
NAMESPACE = $( echo $item | awk '{print $2}' )
echo "Deleting OrganizationUpgrade $NAME in namespace $NAMESPACE "
kubectl --kubeconfig= KUBECONFIG delete OrganizationUpgrade $NAME -n $NAMESPACE
done
為新機構建立作業定義目標 GDC 版本。這個目標版本應有對應的 ReleaseMetadata：
TARGET_RELEASE =
在根管理員叢集中，找出目標 Ubuntu 作業系統的最新 OSImageMetadata CR，並定義 OS_VERSION 變數：
OS_VERSION = $( kubectl --kubeconfig= KUBECONFIG get osimagemetadata --sort-by= .metadata.creationTimestamp | grep -wv rocky | tail -1 | awk '{print $1}' | sed 's/gdch-node-os-//g' )
echo $OS_VERSION 輸出內容可能如下所示：
1 .12.4-gdch.4請確認變數使用的 major.minor.patch 版本與 TARGET_RELEASE 相同，例如 1.12.4。如果沒有，請先將問題轉交給工程團隊，再繼續下一個步驟。
更新目標 ReleaseMetadata，在根管理員叢集中使用 Ubuntu OS_VERSION：
kubectl --kubeconfig= KUBECONFIG patch releasemetadata " ${ TARGET_RELEASE } " --type= 'json' -p= '[{"op": "replace", "path": "/spec/adminCluster/bmNodeImage", "value": ' " ${ OS_VERSION } " '}, {"op": "replace", "path": "/spec/adminCluster/vmNodeImage", "value": ' " ${ OS_VERSION } " '}, {"op": "replace", "path": "/spec/systemCluster/bmNodeImage", "value": ' " ${ OS_VERSION } " '}, {"op": "replace", "path": "/spec/systemCluster/vmNodeImage", "value": ' " ${ OS_VERSION } " '}]'
找出目標 ReleaseMetadata 的對應 UserclusterMetadata 清單：
UCMS = $( kubectl --kubeconfig= KUBECONFIG get releasemetadata " ${ TARGET_RELEASE } " -o json | jq -r '.spec.userClusters[].name' )
更新目標 UserclusterMetadata，在每個機構的根管理員叢集和機構管理員叢集中使用 Ubuntu OS_VERSION。對每個叢集執行下列指令：
for UCM in ${ UCMS } ; do
echo "Updating UserclusterMetadata $UCM "
kubectl --kubeconfig= KUBECONFIG patch userclustermetadata.upgrade.private.gdc.goog " ${ UCM } " --type= 'json' -p= '[{"op": "replace", "path": "/spec/vmNodeImage", "value": ' " ${ OS_VERSION } " '}]'
done
虛擬機器
1.12.1
症狀：
使用 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 為 minimumDiskSize X Gi，請建立新的 VirtualMachineImageImport，大小為 X+1 Gi。這項值會根據匯入圖片的大小而定。如果是 qcow2，則為虛擬大小，例如 20Gi 應替換為 21Gi。
根據呼叫 CLI 的方式，替換預留位置值。
找出 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 以供參考，建立新的映像檔。
使用較大的 minimumDiskSize 建立新的 VirtualMachineImageImport：
minimumDiskSize：
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.12.0
症狀：
系統叢集專案命名空間中的 importer-image-import-$VMII Pod 發生當機，並出現以下錯誤：Unable to process data: Unable to transfer source data to target file: unable to write to file: stream error: stream ID 1; NO_ERROR; received from peer`)。匯入作業開始 2 小時後，VirtualMachineImageImport VMII 物件的條件「類型」為 Ready，狀態為 False，原因為 TranslationInProgress。
解決方法：
如要提升速度，請按照下列步驟將映像檔的最小磁碟大小修改為 200Gi：
kubectl get validatingwebhookconfiguration vmm-image-controller-v1-webhook -oyaml > /tmp/vmm-image-controller-v1-webhook.yaml
kubectl delete validatingwebhookconfiguration vmm-image-controller-v1-webhook
kubectl patch virtualmachineimageimport $VMII -n $PROJECT -p '{"spec": {"imageMetadata": {"minimumDiskSize": "200Gi"}}}'
kubectl apply -f /tmp/vmm-image-controller-v1-webhook.yaml 請注意，如要刪除及套用 ValidatingWebhookConfiguration，您需要機構管理員叢集的叢集管理員 kubeconfig。您可以取得下列 Runbook IAM-R0004 。
如果您使用 gdcloud 啟動匯入作業，請注意，您無法提供 minimumDiskSize 參數。您必須建立 VMII 物件，並修改 VMII，如上一個指令所示。
VirtualMachineImageImport程序會繼續進行，但在後續步驟中再次卡住。在系統叢集的專案命名空間中，您會看到 image-import-$VMII 工作持續失敗，並顯示 error: stream error: stream ID x; NO_ERROR; received from peer 錯誤。此時圖片匯入作業就會完成。最終圖片會上傳至物件儲存空間，但缺少 VirtualMachineImage。您可以按照下列方式手動建立 VirtualMachineImage：
kubectl apply -f - <<EOF
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineImage
metadata:
name: $NAME
namespace: $PROJECT
spec:
minimumDiskSize: 200Gi
operatingSystem:
name: $OS_NAME
EOF `$NAME` 應與 `VMII.ImageMetadata.Name` 相符，`$OS_NAME` 可以是 [`ubuntu-2004`、`ubuntu-2204`、`windows-2019`、`rhel-8`] 其中之一，且應與匯入的映像檔類型相符。
Istio
1.12.4
症狀：
istio-system 命名空間中的 istio-eastwestgateway 部署作業停滯，Pod 事件顯示來自 kubelet 的 Back-off pulling image "auto" 錯誤。
如要診斷問題，請檢查 mutatingwebhookconfiguration 名為 istio-revision-tag-default 的物件是否與停滯的閘道部署作業位於同一叢集。
kubectl --kubeconfig= KUBECONFIG get mutatingwebhookconfiguration istio-revision-tag-default 解決方法：
如果設定存在，請在 istio-system 命名空間中重新啟動部署作業 istio-eastwestgateway。
kubectl --kubeconfig= KUBECONFIG rollout restart deployment/istio-eastwestgateway -n istio-system
如果設定不存在，請等待 Webhook 存在，這應該很快就會發生，因為它位於協調迴圈中。
監控
1.12.2
症狀：
cortex-store-gateway Pod 會重新啟動，記錄檔中會顯示下列錯誤訊息：
panic: runtime error: slice bounds out of range 解決方法：
暫停系統叢集中的 mon-cortex 子元件。
kubectl --kubeconfig $ORG_ADMIN_CONFIG annotate subcomponent mon-cortex -n $SYSTEM_CLUSTER_NAMESPACE lcm.private.gdc.goog/paused= true
修改系統叢集中的 cortex-config configMap，並將 index_cache 中的 memcached 超時時間設為兩秒，使 index_cache 設定如下所示：
index_cache:
backend: memcached
memcached:
addresses: dnssrvnoa+_memcached._tcp.cortex-index-memcached.mon-system.svc.cluster.local
timeout: 2s
重新啟動系統叢集中的 cortex-store-gateway pod，以便使用更新後的設定。
升級
1.12.4
症狀：
裸機節點會顯示為 NotReady，且伺服器停留在開機畫面，最後一則訊息顯示為 Retrieving encryption keys。
解決方法：
重新啟動 iLO。
iLO 恢復運作後，請重新啟動伺服器。
升級
1.12.4
症狀：
升級後，StorageCluster CR 的 StorageVersion 狀態欄位不會顯示任何值。查看版本：
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get StorageCluster -n gpc-system
解決方法：
重新啟動 file-storage-backend-controller 部署作業：
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG rollout restart deployment -n file-system file-storage-backend-controller
作業套件基礎架構 (OI)
1.12.4
症狀：
fluent-bit 安裝程式位置已變更為 operations_center\bin\fluent-bit-win64.msi。
Copy-ConfigHostFiles.ps1 預期 fluent-bit 用戶端安裝程式符合 fluent-bit-*-win64.* 模式。安裝程式找不到安裝程式，因為該模式不再相符。
解決方法：
開啟 Copy-ConfigHostFiles.ps1 檔案。
找出下列程式碼行：
$( Get-Item -Path 'H:\operations_center\bin\fluent-bit-*-win64.*' ) .FullName
編輯前一行，加入正確的安裝程式位置：
$( Get-Item -Path 'H:\operations_center\bin\fluent-bit-win64.*' ) .Name
作業套件基礎架構 (OI)
1.12.4
症狀：
Nessus 安裝程式位置已變更為 operations_center\bin\NessusAgent-x64.msi。
Copy-ConfigHostFiles.ps1 會預期用戶端安裝程式與 /NessusAgent-10.4.1-x64.msi 檔案名稱相符。安裝程式找不到安裝程式，因為該模式不再相符。
解決方法：
開啟 Copy-ConfigHostFiles.ps1 檔案。
找出下列幾行：
[ pscustomobject] @{ source = "H:\operations_center\bin\Nessus-10.4.1-x64.msi" ; destination = "C:\config\nessus_mgr\Nessus-10.4.1-x64.msi" }
[ pscustomobject] @{ source = "H:\operations_center\bin\Nessus-10.4.1-x64.msi" ; destination = "C:\config\nessus_oob\Nessus-10.4.1-x64.msi" }
編輯上述幾行，加入正確的安裝程式位置，將 Nessus-10.4.1-x64.msi 變更為 NessusAgent-x64.msi：
[ pscustomobject] @{ source = "H:\operations_center\bin\NessusAgent-x64.msi" ; destination = "C:\config\nessus_mgr\NessusAgent-x64.msi" }
[ pscustomobject] @{ source = "H:\operations_center\bin\NessusAgent-x64.msi" ; destination = "C:\config\nessus_oob\NessusAgent-x64.msi" }
物件儲存空間
1.12.4
症狀：
您可能會看到類似以下的訊息：
Reason: NamespaceCreated
Status: True
Type: ObjectNamespaceReady
Last Transition Time: 2024 -07-12T00:49:29Z
Message: awaiting images distribution to be finished
Observed Generation: 1
Reason: VMImageDistributing
Status: Unknown
Type: Ready 這是因為新機構缺少 S3 端點設定。
解決方法：
為新機構手動建立高可用性群組。
透過緊急情況程序，取得根管理員叢集的 kubeconfig，該叢集具有下列資源的讀取權限：
機構
ObjectStorageAdminNode
SubnetClaim
ObjectStorageSite
密鑰
記下機構名稱：
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG_ABSOLUTE_PATH get Organization -A
請記下根管理員叢集中 ObjectStorageAdminNode CR 的用戶端 IP 位址。
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG_ABSOLUTE_PATH get ObjectStorageAdminNode 針對每個 AdminNode CR：
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG_ABSOLUTE_PATH get ObjectStorageAdminNode NODE_NAME -o jsonpath = '{.spec.network.clientIP}'
請記下該範圍內的可用 IP 位址範圍和預留 IP：
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG_ABSOLUTE_PATH get SubnetClaim -n root external-objectstorage-client-lif-subnet -o jsonpath = '{.status.ipv4SubnetStatus}'
從根管理員叢集中的 gpc-system/objectstorage-breakglass-root-level1 密鑰，擷取 StorageGRID 管理 UI 登入憑證。
使用上一步的憑證登入 StorageGRID 管理 UI。網址處於「ObjectStorageSite」狀態：
kubectl --kubeconfig /root/release/root-admin/root-admin-kubeconfig get ObjectStorageSite -n gpc-system mb-obj-site-1 -o jsonpath = '{.status.managementAPIEndpointURL}'
前往「設定」
開啟每個高可用性群組的詳細資料檢視畫面，並記下虛擬 IP 位址 (VIP)。
建立新的高可用性群組：
群組名稱 ：名稱模式為 ORGANIZATION_NAME -haorg-2-ha。群組說明 ：使用現有的 HA 群組做為說明模式。介面 ：選取所有 eth2。優先順序 ：主要介面應為最高優先順序。SubnetCIDR ：StorageGRID 會自動填寫這個欄位。
確認子網路與 SubnetClaim external-objectstorage-client-lif-cidr 中的 status.ipv4SubnetStatus.cidrBlock 相符。虛擬 IP ：可用 IP 範圍中的下一個 IP。IP 不得與預留 IP、管理員節點的用戶端 IP，以及現有高可用性群組的 VIP 衝突。
輪替 StorageGRID 緊急存取憑證。
升級
1.12.4
症狀：
將根機構從 1.12.2 升級至 1.12.4 時，iac-gitlab 子元件會處於持續協調狀態。如要診斷問題，請檢查 Prometheus 記錄，例如：
kubectl logs gitlab-prometheus-server-5d6d9599f-l2l7s -n gitlab-system -c prometheus-server 記錄可能包含類似以下的錯誤：
unexpected fault address 0x7f217cf26000
fatal error: fault
[ signal SIGBUS: bus error code = 0x2 addr = 0x7f217cf26000 pc = 0x46c302]
goroutine 1 [ running] :
runtime.throw({ 0x3018bed?, 0x0?})
/usr/local/go/src/runtime/panic.go:992 +0x71 fp = 0xc000a3b098 sp = 0xc000a3b068 pc = 0x438431 解決方法：
執行 sleep 3600，在執行中的容器中取得殼層，例如：
kubectl exec --stdin --tty POD_NAME -n gitlab-system -c prometheus-server -- /bin/sh
/prometheus $ df -h 將 POD_NAME 替換為 Pod 名稱，例如 gitlab-prometheus-server-d7969c968-hppsl。
檢查輸出內容，確認 /data 資料夾是否已滿：
Filesystem Size Used Available Use% Mounted on
overlay 866 .4G 147 .1G 719 .3G 17 % /
tmpfs 64 .0M 0 64 .0M 0 % /dev
tmpfs 94 .3G 0 94 .3G 0 % /sys/fs/cgroup/dev/mapper/luks-trident_pvc_6fb4dc48_72df_4bf1_825f_267818e3fefd
7 .8G 7 .3G 0 100 % /data
如果在升級期間發生這個問題，請刪除遷移作業 (因為遷移作業的逾時時間為 3600 秒)，然後繼續升級：
kubectl delete job gitlab-migrations-1-fe7-2 -n gitlab-system
升級
1.12.4
症狀：
如要診斷問題，請檢查 IAM 升級記錄，例如：。
kubectl logs -n gpc-system upgrade-managed-check-iamupgrade-qbdm5-tl264 輸出內容可能如下所示：
I0724 21 :57:20.456782 1 upgrade_check.go:39] IAM preflight check failed after 60000000000 : Org iam-system deployments not ready: Deployment iam-authzpdp-backend-server is not ready; ready replicas 2 ,replicas 3 解決方法：
請參閱先前的錯誤訊息，並記下部署作業的命名空間和名稱。在本例中，NAME 為 iam-authzpdp-backend-server，NAMESPACE 則為 iam-system。
取得 Pod 清單：
kubectl get pods -n NAMESPACE | grep NAME
請注意結果的格式如下：
iam-authzpdp-backend-server-6875654c4b-64h4t 2 /2 Running 0 29h
iam-authzpdp-backend-server-6875654c4b-pvscg 1 /2 Running 0 29h
iam-authzpdp-backend-server-6875654c4b-v7jnl 2 /2 Running 0 29h 請注意，並非所有容器都已準備就緒的 Pod。在本例中，POD_NAME 為 iam-authzpdp-backend-server-6875654c4b-pvscg，其中一個或兩個容器尚未準備就緒，因此顯示 1/2 狀態。如果有多個這類 Pod，請對每個受影響的 Pod 重複執行下一個步驟。
刪除健康狀態不佳的 Pod：
kubectl delete pod -n NAMESPACE POD_NAME>
再次執行步驟 2 中的指令。請注意，所有 Pod 現在都應該正常運作。這個步驟可能需要幾分鐘才能完成。
如果刪除的 Pod 未由健全的 Pod 取代，請開啟支援單。
升級
1.12.1
症狀：
升級完成後，OrganizationUpgrade 狀態會變成 Unknown。
解決方法：
如果 Organization 上的版本欄位與 targetVersion 欄位相符，可以放心忽略「Unknown」狀態。
升級
1.12.4
症狀：
將租戶機構從 1.12.2 升級至 1.12.4 時，opa gatekeeper 子元件升級會失敗，並顯示 ReconciliationError。
解決方法：
編輯受影響使用者叢集的 mutatingwebhookconfiguration 物件 edr-sidecar-injector-webhook-cfg。如果有多個受影響的使用者叢集，請針對每個受影響的使用者叢集重複執行下列步驟：
kubectl edit mutatingwebhookconfiguration edr-sidecar-injector-webhook-cfg
編輯 webhooks > (edr-sidecar-injector.gpc-system.internal) > namespaceSelector > matchExpressions > (key: kubernetes.io/metadata.name) > values 區段，並新增下列兩個值：
更新後的物件應如下所示：
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
...
webhooks:
- admissionReviewVersions:
name: edr-sidecar-injector.gpc-system.internal
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values:
- kube-system
- opa-system
- cert-manager
...
變更最多可能需要一小時才會生效。
升級
1.12.4
症狀：
從 1.12.2 升級至 1.12.4 時，ansibleplaybook 不會隨著叢集升級。ansibleplaybook中更新的修正程式不會套用，且會封鎖執行舊版 ansibleplaybook 的 OS 政策。
解決方法：
刪除 create-ansible-playbooks Kubernetes 工作：
JOB_NAME = create-ansible-playbooks-xxx
JOB_NAMESPACE = xxx
kubectl delete job $JOB_NAME -n JOB_NAMESPACE --kubeconfig= /path/to/admin-cluster-config
重新啟動 os-core-controller 部署作業。
這項操作會重新觸發工作，並更新劇本。
DNS
1.12.4
症狀：
建立新機構時，您可能會在記錄中看到 core-dns 子元件逾時：
[ INFO] 192 .0.2.0:60741 - 40400 "A IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232" - - 0 2 .000828817s
[ ERROR] plugin/errors: 2 objectstorage-tenant-mgmt.gdch.example.com. A: read udp 10 .244.4.184:59927->192.0.2.1:53: i/o timeout
[ INFO] 192 .0.2.0:51401 - 5813 "AAAA IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232" - - 0 2 .000585231s
[ ERROR] plugin/errors: 2 objectstorage-tenant-mgmt.gdch.example.com. AAAA: read udp 10 .244.4.184:48542->192.0.2.1:53: i/o timeout解決方法：
更新根管理員叢集的 gpc-coredns-forwarder-udp服務和 gpc-coredns-forwarder-tcp 服務，並在負載平衡器來源範圍中新增 IP 範圍。
如果覆寫 CR 變更，請使用註解 lcm.private.gdc.goog/paused="true" 暫停 dns-core 子元件。
檔案和區塊儲存空間
1.12.4
症狀：
從 1.12.2 升級至 1.12.4 時，file-netapp-trident 子元件會卡在 StorageClasses 的刪除作業。顯示的狀態如下：
status:
backendStatus:
conditions:
- lastTransitionTime: "2024-05-02T06:04:14Z"
message: 'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks"
found'
observedGeneration: 2
reason: ReconciliationError
status: "True"
type: Reconciling
- lastTransitionTime: "2024-04-08T00:12:53Z"
message: Successfully pulled chart
observedGeneration: 2
reason: ChartPullDone
status: "True"
type: ChartPull
- lastTransitionTime: "2024-05-01T10:10:08Z"
message: Fetched parameters from default, runtime
observedGeneration: 2
reason: ParametersDone
status: "True"
type: Parameters
- lastTransitionTime: "2024-05-02T06:04:04Z"
message: 'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks"
found'
observedGeneration: 2
reason: DeployError
status: "False"
type: Deployed
- lastTransitionTime: "2024-04-23T06:50:12Z"
message: Readiness check job passed
observedGeneration: 1
reason: ReadinessCheckDone
status: "True"
type: Ready
deploymentFinished: false
lastDeployTimestamp: "2024-05-02T06:03:16Z"
readyAfterDeploy: true
version: ""
conditions:
- lastTransitionTime: "2024-05-02T06:04:14Z"
message: 'Reconciliation error: E0121 - rollback chart: no StorageClass with the
name "standard-rwo-non-luks" found'
observedGeneration: 2
reason: ReconciliationError
status: "True"
type: Reconciling
crdsStatus:
conditions:
- lastTransitionTime: "2024-04-07T08:02:33Z"
message: Successfully pulled chart
observedGeneration: 2
reason: ChartPullDone
status: "True"
type: ChartPull
- lastTransitionTime: "2024-04-07T08:02:33Z"
message: No parameters to fetch
observedGeneration: 2
reason: ParametersDone
status: "True"
type: Parameters
- lastTransitionTime: "2024-04-07T08:02:34Z"
message: Readiness source is empty
observedGeneration: 2
reason: ReadinessCheckSkipped
status: "True"
type: Ready
- lastTransitionTime: "2024-05-01T18:37:52Z"
message: Ready
observedGeneration: 2
reason: ReconciliationCompleted
status: "False"
type: Reconciling
deploymentFinished: true
lastDeployTimestamp: "2024-05-02T06:04:03Z"
readyAfterDeploy: true
version: 1 .12.3-gdch.312
解決方法：
暫停 file-netapp-trident 子元件：
## Set KUBECONFIG to root-admin KUBECONFIG
export KUBECONFIG = ROOT_ADMIN_KUBECONFIG
kubectl annotate subcomponent file-netapp-trident -n $cluster_namespace lcm.private.gdc.goog/paused= true
刪除工作無法建立的 StorageClasses，例如 standard-rwo、standard-block、standard-rwo-non-luks 和 standard-block-non-luks：
kubectl delete storageclass $( kubectl get storageclasses -o jsonpath = ' { .items[ ?( @.provisioner== "csi.trident.netapp.io" ) ] .metadata.name}
重新啟動叢集的 oclcm-backend-controller，即可觸發 StorageClasses 的重新建立作業 (根叢集和機構管理員叢集的根管理員控制器，以及系統和使用者叢集的機構管理員控制器)：
kubectl rollout restart deployment oclcm-cm-backend-controller -n oclcm-system
在叢集中重新啟動 netapp-trident 部署作業和 netapp-trident DaemonSet：
kubectl rollout restart deployment netapp-trident-controller -n netapp-trident
kubectl rollout restart daemonset netapp-trident-node-linux -n netapp-trident
確認已為 PersistentVolumeClaim (PVC) 資源建立 LUKS 密鑰。每個 PVC 都必須有 g-luks-$pvc_name 格式的密鑰。
kubectl get secret -n $pvc_namespace g-luks-$pvc_name
確認 file-netapp-trident 子元件的狀態沒有錯誤：
kubectl get subcomponent -n $cluster_namespace file-netapp-trident -o jsonpath = '{.status}' | jq
取消暫停子元件，覆寫才會生效。
實體伺服器
1.12.4
症狀：
啟動伺服器時，您可能會在裸機記錄中看到類似下列內容的訊息：
Conditions:
Last Transition Time: 2024 -08-12T17:10:23Z
Message: Introspection timeout
Observed Generation: 2
Reason: FailedProvision
Status: True
Type: BaremetalFailure
Last Transition Time: 2024 -08-10T12:23:30Z
Message:
Observed Generation: 2
Reason: KeyManagerConfigurationSucceeded
Status: True
Type: KeyManagerConfigured
Last Transition Time: 2024 -08-10T12:11:17Z
Message: The server is powered off or unknown
Observed Generation: 2
Reason: NotPoweredOn
Status: False
Type: Ready 解決方法：
針對每個停滯的階段，請按照下列執行手冊中的說明操作：
SERV-R0006 SERV-R0007 SERV-R0008
如果問題仍未解決，請按照 SERV-R0001 執行手冊中的步驟。
如果問題仍未解決，請開啟支援單。
升級
1.12.0
症狀：
primary-prometheus-shardX-replicaX Pod 會顯示在 obs-system 命名空間和 mon-system 命名空間中。如果升級至 1.12 版後，primary-prometheus-shardX-replicaX 只存在於 obs-system 命名空間中，則表示這是其他不明問題，不應執行解決方法。
預期行為是 primary-prometheus-shardX-replicaX 只會在 1.12 升級完成後存在於 mon-system 命名空間。
解決方法：
手動刪除 obs-system 命名空間中的 primary-prometheus-shardX-replicaX StatefulSet。
請勿刪除 mon-system 命名空間中的 primary-prometheus-shardX-replicaX StatefulSet。
網路
1.12.4
症狀：
ClusterCIDRConfig 是指派 PodCIDRs 時的必要物件。雖然已建立 ClusterCIDRConfig，但系統未指派 PodCIDRs。如果 ClusterCIDRConfig 是在 ipam-controller Pod 啟動時建立，就會發生這個問題。叢集建立作業卡在協調狀態：
檢查叢集上是否已建立 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: ""
針對卡在調解狀態的叢集，對其中一個節點物件執行說明，並檢查節點物件上是否有 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
解決方法：
重新啟動 ipam-controller-manager Pod：
kubectl --kubeconfig= CLUSTER_KUBECONFIG -n kube-system rollout restart ds ipam-controller-manager
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:
Vertex AI
1.12.0
建立使用者叢集時，MonitoringTarget 會顯示 Not Ready 狀態，導致預先訓練的 API 持續在使用者介面中顯示 Enabling 狀態。
解決方法：
開啟 Chrome 瀏覽器的選單 (三點圖示)。
依序點選「更多工具」
按一下控制台的「網路」
找出 ai-service-status 要求。
在 ai-service-status 要求中按一下「Response」
確認除了 MonitoringTarget 和 LoggingTarget 元件以外，一切都準備就緒。
物件儲存空間
1.12.4
症狀：
升級物件儲存空間時，您可能會看到類似下方的警告：
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 解決方法：
確認每個節點在祕密中都儲存了對應的 SSH 憑證。
檢查管理員節點：
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
檢查儲存空間節點：
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
如果指令未傳回任何錯誤，您可以放心忽略協調器回報的錯誤。
Vertex AI
1.11.x
症狀：
升級期間，系統會重新建立 Translation DB 叢集，導致 ODS 系統叢集 secret-store 密鑰過時且不同步。因此，翻譯前端 Pod 和服務無法初始化。
解決方法：
刪除系統叢集中的密鑰：
kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n ai-translation-system 將 SYSTEM_CLUSTER_KUBECONFIG
控制器會自動重新建立密鑰，並與資料庫叢集重新同步。
實體伺服器
1.12.4
症狀：
伺服器無法連線至金鑰管理員，因此伺服器狀態無法使用。這個問題會導致 server-encrypt-and-create-logical-drive 工作失敗，且管理員叢集無法就緒。您可能會在工作記錄中看到類似以下的錯誤：
Error: Error during command execution: ansible-playbook error: one or more host failed
Command executed: /usr/local/bin/ansible-playbook --extra-vars { "server_generation" :"gen10" ,"ssa_crypto_pwd" :"vf{kXgbL?VFcV]%0" ,"ssa_master_key" :"ten-admin-org-2" } --inventory 192 .0.2.0, --private-key /etc/ssh-key/id_rsa --become serve
r/encrypt_and_create_logical_drive.yaml
exit status 2 解決方法：
執行 AuxCycle，並確認 iLO 可以連線至金鑰管理員。
記錄
1.12.4
症狀：
Loki 只有一個永久磁碟區 (PV)，用於預先寫入記錄 (WAL) 和索引。如果 Loki Pod 無法連線至儲存空間儲存值達數小時，WAL 即可填入 PV。如果 PV 空間不足，除非刪除 PV 並重新啟動 StatefulSet，否則 Loki 無法復原。
解決方法：
如要從這個狀態復原 Loki Pod，您必須縮減對應的 StatefulSet，並刪除空間不足的 PV。
注意： 這項動作的直接後果是，任何目前位於 WAL 中但未轉移至儲存空間 bucket 的記錄都會永久遺失。
請按照下列步驟復原 Loki Pod：
確認工作站已安裝 IO 工具容器。詳情請參閱 OOPS-P0065 作業手冊。
如要取得編輯資源所需的權限，請要求安全管理員授予下列角色：
observability-viewerobservability-admin
使用根管理員叢集中的 kubeconfig 檔案路徑，設定 KUBECONFIG 環境變數。詳情請參閱 IAM-R0004 執行手冊。
使用受影響的機構名稱設定 ORG_NAME 環境變數。
將下列內容儲存到名為 log-admin-overrides.yaml 的 YAML 檔案：
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
name: log-admin-overrides
spec:
subComponentRef: log-admin
backend:
operableParameters:
controller:
disableReconcilers: "LoggingPipelineReconciler"
停用 LoggingPipelineReconciler：
kubectl apply -f log-admin-overrides.yaml -n ${ ORG_NAME }
使用路徑設定 KUBECONFIG 環境變數，指向執行受影響 Loki Pod 的叢集中的 kubeconfig 檔案。詳情請參閱 IAM-R0004 執行手冊。
使用受影響的 Loki Pod 名稱設定 LOKI_POD_NAME 環境變數。
取得 Loki StatefulSet 名稱：
export LOKI_STATEFULSET_NAME = $( kubectl get pod $LOKI_POD_NAME -n obs-system -o json | jq -r '.metadata.labels.app' )
取得 Loki PVC 名稱：
export LOKI_PVC_NAME = $( kubectl get pod $LOKI_POD_NAME -n obs-system -o json | jq -r '.spec.volumes[] | select(.persistentVolumeClaim != null) | .persistentVolumeClaim.claimName' )
取得 Loki StatefulSet 副本：
export LOKI_STATEFULSET_REPLICAS = $( kubectl get statefulset $LOKI_STATEFULSET_NAME -n obs-system -o json | jq -r '.status.replicas' )
縮減 Loki StatefulSet：
kubectl scale statefulset $LOKI_STATEFULSET_NAME -n obs-system --replicas= 0
確認沒有任何 StatefulSet Pod 正在執行：
kubectl get statefulset $LOKI_STATEFULSET_NAME -n obs-system 輸出內容必須如下列範例所示：
NAME READY AGE
audit-logs-loki-io 0 /0 4d3h
刪除受影響的 PVC：
kubectl delete pvc $LOKI_PVC_NAME -n obs-system
擴充 Loki StatefulSet：
kubectl scale statefulset $LOKI_STATEFULSET_NAME -n obs-system --replicas= ${ LOKI_STATEFULSET_REPLICAS }
設定 KUBECONFIG 環境變數，並提供受影響機構管理員叢集中的 kubeconfig 檔案路徑。詳情請參閱 IAM-R0004 執行手冊。
按照下列方式編輯 log-admin-overrides.yaml YAML 檔案中的內容：
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
name: log-admin-overrides
namespace: root
spec:
subComponentRef: log-admin
backend:
operableParameters:
controller:
disableReconcilers: ""
啟用 LoggingPipelineReconciler：
kubectl apply -f log-admin-overrides.yaml -n ${ ORG_NAME }
確認所有 StatefulSet Pod 都在執行中，且健康狀態良好：
kubectl get statefulset $LOKI_STATEFULSET_NAME -n obs-system 輸出內容必須如下列範例所示：
NAME READY AGE
audit-logs-loki-io 5 /5 2d5h 在本例中，StatefulSet 有五個備用資源 (5/5)。
升級
1.12.4
症狀：
系統會持續排定工作。工作終止後，系統會立即排定新的工作。持續排定的工作包括：
unet-networkpolicy-assets-parameterunet-nodenetworkpolicy-assets-parameterunet-nodenetworkpolicy-assets-readinessunet-userclusterpolicy-assets-parameterunet-clustermesh-backend-parameterunet-clustermesh-backend-readiness
解決方法：
暫停下列子元件：
unet-networkpolicyunet-nodenetworkpolicyunet-nodenetworkpolicyunet-userclusterpolicyunet-clustermesh
每當根管理員叢集中的 fleet-info 密鑰有變更時，請取消暫停子元件。如果執行個體的管理交換器發生變更 (例如 kr get managementswitches -A)，或是機構命名空間中的任何 cidrclaim 發生變更，就會發生這個問題。
每當機構管理員叢集中的任何 NodePool 資源發生變更，請取消暫停子元件。開始前請先解除暫停子元件。
升級
1.12.4
症狀：
從 1.12.2 升級至 1.12.4 時，ServiceNow 的上游健康狀態無法使用。您可能會看到以下訊息：failed to stage volume: LUKS passphrase cannot be empty。
「system-performance-rwo」儲存空間類別未啟用 LUKS。磁碟區附件表示 PVC 已啟用 LUKS。
調解器會搜尋含有 LUKS 密碼的密鑰。由於磁碟區附件表示已啟用 LUKS，但儲存空間類別未啟用 LUKS，因此系統不會建立密碼片語。
解決方法：
取得發生問題的根叢集或機構管理員叢集的 Kubeconfig：
export KUBECONFIG = ${ ROOT_OR_ORG_ADMIN_KUBECONFIG }
刪除 system-performance-rwo 儲存空間類別並重新建立：
kubectl delete storageclass system-performance-rwo
kubectl apply -f system-performance-rwo.yaml
為 system-performance-rwo 儲存空間類別建立新的 YAML，並啟用 LUKS：
# kubectl get sc system-performance-rwo -o yaml
allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
disk.gdc.goog/luks-encrypted: "true"
helm.sh/resource-policy: keep
lcm.private.gdc.goog/claim-by-force: "true"
meta.helm.sh/release-name: file-netapp-trident-backend
meta.helm.sh/release-namespace: netapp-trident
storageclass.kubernetes.io/is-default-class: "false"
labels:
app.kubernetes.io/managed-by: Helm
name: system-performance-rwo
parameters:
backendType: ontap-san
csi.storage.k8s.io/node-expand-secret-name: g-luks-${ pvc .name }
csi.storage.k8s.io/node-expand-secret-namespace: ${ pvc .namespace }
csi.storage.k8s.io/node-publish-secret-name: g-luks-${ pvc .name }
csi.storage.k8s.io/node-publish-secret-namespace: ${ pvc .namespace }
csi.storage.k8s.io/node-stage-secret-name: g-luks-${ pvc .name }
csi.storage.k8s.io/node-stage-secret-namespace: ${ pvc .namespace }
fsType: ext4
selector: tier = performance
provisioner: csi.trident.netapp.io
reclaimPolicy: Delete
volumeBindingMode: Immediate
升級
1.12.4
症狀：
您可能會看到 file-netapp-trident 子元件的狀態在 Reconciling 和 ReconciliationCompleted 之間來回切換。
解決方法：
如果符合下列條件，可以放心忽略正在進行的對帳作業：
TridentBackend為 online。TridentBackend 設定為 bound。netapp-trident-controller 部署作業的健康狀態良好。netapp-trident-node-linux DaemonSet 的健康狀態良好。
升級
1.12.4
症狀：
從 1.12.2 升級至 1.12.4 時，機構升級作業會停留在 NodeUpgrade 階段，節點升級工作則會顯示下列錯誤：
Message: failed to generate delta between manifest and snapshot: failed to create or update delta configmap: failed to calculate delta between snapshot and manifest: failed to get valid OS distribution for delta comparison, distribution:
如要確認問題，請執行下列步驟：
取得節點升級失敗的根叢集或機構管理員叢集的 Kubeconfig，並檢查 nodeupgradetask 是否失敗：
export KUBECONFIG = ${ ROOT_OR_ORG_ADMIN_KUBECONFIG }
kubectl get nodeupgradetask -A -ojsonpath= '{.items[*].status.conditions[?(@.status != "True")]}' | jq
確認訊息與先前的錯誤訊息相符：
Message: failed to generate delta between manifest and snapshot: failed to create or update delta configmap: failed to calculate delta between snapshot and manifest: failed to get valid OS distribution for delta comparison, distribution:
確認 osartifactsnapshot 是否缺少發布資訊：
kubectl get osartifactsnapshots.system.private.gdc.goog -A -o json | jq '.items[] | select(.status.distribution == "") | .metadata.name'
確認至少有一張已列印的快照未設定發布狀態。
解決方法：
取得節點所屬叢集的 Kubeconfig：
export KUBECONFIG = ${ CLUSTER_KUBECONFIG }
kubectl rollout restart -n os-system os-core-controller
確認快照現在有發布版本。(這個指令可能需要幾分鐘的時間)：
kubectl get osartifactsnapshots.system.private.gdc.goog -A -o json | jq '.items[] | select(.status.distribution == "") | .metadata.name'
這項指令應不會傳回任何結果。如果仍未看到發行內容，請提出支援要求。
升級
1.12.4
症狀：
kubelet 會持續列印下列垃圾記錄：
May 22 23 :08:00 control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthos kubelet[ 3751 ] : time = "2024-05-22T23:08:00Z" level = warning msg = "Failed to remove cgroup (will retry)" error = "rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
……
May 22 23 :09:04 control-1 kubelet[ 3751 ] : time = "2024-05-22T23:09:04Z" level = warning msg = "Failed to remove cgroup (will retry)" error = "rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy" runc init 程序已凍結，導致 kubelet 無法刪除 cgroup Pod。
解決方法：
請使用下列指令碼找出阻礙刪除 cgroup 的程序：
# Find matching cgroup directories
MATCHING_CGROUPS = $( find /sys/fs/cgroup -type d -name "*74353c*" )
if [ -z " $MATCHING_CGROUPS " ] ; then
echo "No cgroups found containing 'd06aac'."
exit 0
fi
echo "Matching cgroups:"
for cgroup in $MATCHING_CGROUPS ; do
echo "- $cgroup " # Print cgroup path
# Check if cgroup.procs exists
if [ -f " $cgroup /cgroup.procs" ] ; then
echo " Processes:"
# List PIDs in cgroup.procs
for pid in $( cat " $cgroup /cgroup.procs" ) ; do
# Get process details
ps -o pid,comm,cmd --no-headers $pid 2 >/dev/null # Suppress errors if process doesn't exist
done
else
echo " No cgroup.procs file found." # Handle cases where cgroup.procs is missing
fi
echo # Add a newline for better readability
done
使用 cat freezer.state 檢查凍結狀態。狀態應為 FROZEN。
Echo "THAWED" > freezer.state
已成功刪除「cgroup」。Kubelet 停止記錄垃圾內容。
成效
1.12.4
症狀：
perf-ptaas 子元件會顯示下列錯誤代碼，導致 PTaaS 無法部署：
Reconciliation error: E0100 - deploy: failed to transfer ownership of conflicting resources for install: these resources need to be force claimed, but they are not annotated: [ Resource: "resourcemanager.gdc.goog/v1, Resource=projects" , GroupVersionKind: "resourcemanager.gdc.goog/v1, Kind=Project"
解決方法：
PTaaS 部署在 gdchservices 機構中。
檢查 perftest 命名空間 gdch-perftest 中 PTaaS 專案 gdch-perftest 和 bucket perftest-bucket-reports 的註解和標籤。值區可能缺少標籤：app.kubernetes.io/managed-by=Helm 和註解：meta.helm.sh/release-name=perf-ptaas-assets 和 meta.helm.sh/release-namespace=gdch-perftest。
手動新增下列標籤和註解：
kubectl --kubeconfig gdchservices-admin-kubeconfig label buckets -n gdch-perftest perftest-bucket-reports app.kubernetes.io/managed-by= Helm
kubectl --kubeconfig gdchservices-admin-kubeconfig annotate buckets -n gdch-perftest perftest-bucket-reports meta.helm.sh/release-name= perf-ptaas-assets
kubectl --kubeconfig gdchservices-admin-kubeconfig annotate buckets -n gdch-perftest perftest-bucket-reports meta.helm.sh/release-namespace= gdch-perftest
kubectl --kubeconfig gdchservices-admin-kubeconfig annotate buckets -n gdch-perftest perftest-bucket-reports lcm.private.gdc.goog/claim-by-force= true
檢查 PTaaS 專案的註解 gdch-perftest。專案的註解設定可能錯誤：meta.helm.sh/release-name=perf-ptaas-assets。
將這個註解變更為 meta.helm.sh/release-name=perf-ptaas-backend：
kubectl --kubeconfig gdchservices-admin-kubeconfig annotate projects -n gpc-system gdch-perftest meta.helm.sh/release-name= perf-ptaas-backend --overwrite= true
kubectl --kubeconfig gdchservices-admin-kubeconfig annotate projects -n gpc-system gdch-perftest lcm.private.gdc.goog/claim-by-force= true
確認子元件在根管理員叢集中完成協調：
kubectl get subcomponent -n gdchservices perf-ptaas
