| 安裝 |
1.9.0
1.9.1
1.9.2 |
iLO 偶爾無法從 HSM 擷取金鑰
症狀：
`server.status.conditions` 有一個類型為 `KeyManagerConfigured` 且狀態為 `True` 的項目，但沒有類型為 `DiskEncryptionEnabled` 的項目。 名為 `server-encrypt-and-create-logical-drive-$SERVER-xxxxx` 的 Pod 失敗，並顯示錯誤 `"ERROR: (3065) Error changing the Controller Encryption Mode UNABLE TO RETRIEVE KEY\tController: HPE Smart Array P408i-a SR Gen10, SLOT 0`。 金鑰無效，因此無法透過 SSH 連線至 Pod。
解決方法：
如要解決這個問題，請按照下列步驟操作：
依序前往 iLO 使用者介面 >「資訊」>「診斷」>「重設」，即可重設 iLO。 如果在重設期間，iLO 顯示伺服器正在進行開機自我測試 (POST)，請重新啟動佈建流程：
如果管理員叢集安裝作業已完成：
export KUBECONFIG=<root-admin-kubeconfig path>
更新安全殼層金鑰：
擷取目前的公開 SSH 金鑰 (請注意，這可能已輪替，因此與 /root/.ssh/id_rsa.pub 不同)
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -d
將公開金鑰放入 ironic-vars configmap：
kubectl -n gpc-system edit cm/ironic-vars
新增 IRONIC_RAMDISK_SSH_KEY：\ 重新啟動 ironic：
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic
重新佈建機器，重新安裝 IPA：
備份 bmc-credential-$SERVER，因為刪除 bmh 時也會刪除密鑰
kubectl -n gpc-system get secret bmc-credentials-$SERVER -oyaml > $SERVER
從檔案中移除不適用的屬性，例如：last-applied、creationtimestamp、finalizer、ownerreference、resourceversion、uid。
刪除 BareMetalHost：
kubectl -n gpc-system delete bmh/$SERVER
從 cellcfg 擷取 Secret bmc-credentials-$SERVER 或先前的備份，然後套用。
要求伺服器執行其他動作。
如要移除快取的 BMH 狀態，請按照下列步驟操作：
kubectl -n gpc-system annotate server/$SERVER baremetalhost.metal3.io/status-
等待伺服器佈建完成。 觀看如何建立 BMH 物件。 您可能需要刪除加密工作才能重新觸發。
|
| 作業 |
1.9.0
1.9.1
1.9.2 |
症狀：
當 storageClassName 為 standard-block 時，VM 狀態會保留 STATUS 的 Provisioning 或 Starting。
解決方法：
如要解決這個問題，請按照下列步驟操作：
確認 VM STATUS 顯示 Provisioning 或 Starting：
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm -n PROJECT
SYSTEM_KUBECONFIG 是系統叢集 kubeconfig 檔案路徑。
PROJECT 是 VM 所在的 GDC 專案。
選用：取得其他狀態詳細資料：
kubectl get gvm VM_NAME -n PROJECT -o \
jsonpath='{"State:"}{.status.state}{"\n"}{"Reason:"}{.status.reason}{"\n"}{"Message:"}{.status.message}{"\n"}'
VM_NAME 是沒有回應的 VM 名稱。
刪除 VM：
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gvm VM_NAME -n NAMESPACE_NAME
NAMESPACE_NAME 是命名空間的名稱。
確認刪除作業是否成功：
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm VM_NAME -n PROJECT
如果結果類似下方，表示成功：
Error from server (NotFound): virtualmachines.vm.cluster.gke.io "VM_NAME" not found
刪除該 VM 的所有磁碟：
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n NAMESPACE_NAME 將 DISK_NAME_1 和 DISK_NAME_2 到 DISK_NAME_N 替換成每個磁碟的名稱，並確認所有磁碟都已列出。 確認刪除作業是否成功：
kubectl --kubeconfig SYSTEM_KUBECONFIG get gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n $PROJECT
如果結果類似下方，表示成功：
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_1" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_2" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_N" not found
重新建立 VM 和磁碟。
重新啟動 VM。
|
| 作業 |
1.9.2 |
症狀：
gdcloud system container-registry load-oci 發生錯誤，如果重新執行指令，指令會以不同時間長度執行，並在程序中的不同時間點失敗 (例如推送或重新標記)，但錯誤類似。
解決方法：
如要解決這個問題，請按照下列步驟操作：
將 KUBECONFIG 匯出至根管理員 kubeconfig：
export KUBECONFIG=~/release/root-admin/root-admin-kubeconfig
- 發出下列指令，將
deployment/root-admin-tftp-manager-controller 縮減為 0 個備用資源：
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
- 執行失敗的作業。
- 將
deployment/root-admin-tftp-manager-controller 調度為 1 個副本：
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
|
| 作業 |
1.9.1
1.9.2
1.9.3 |
症狀：
gdcloud system container-registry load-oci 發生錯誤，如果重新執行指令，指令會以不同時間長度執行，並在程序中的不同時間點失敗 (例如推送或重新標記)，但錯誤類似。
解決方法：
請放心忽略這則訊息。這個面板稍後會消失。
|
| 作業 |
1.9.2 |
解決方法：
如要解決這個問題，請重新啟動發生問題的 Pod。
|
| 作業 |
1.9.0
1.9.1
1.9.2 |
症狀：
伺服器的「準備就緒」條件狀態為「False」，且訊息包含「job server-encrypt-and-create-logical-drive-... failed with reason ... and message ...」。失敗作業的記錄包含「Failed to connect to the host via ssh ... Permission denied (publickey).」。
解決方法：
如要解決這個問題，請按照下列步驟操作：
從根管理員叢集擷取目前的公開安全殼層金鑰：
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -d將金鑰放入 ironic-vars configmap：
kubectl -n gpc-system edit cm/ironic-vars 並新增或取代現有的 IRONIC_RAMDISK_SSH_KEY：
<SSH public key>
重新啟動 ironic 部署作業：
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic 針對每個受影響的伺服器：
kubectl -n gpc-system annotate bmh/$SERVER inspect.metal3.io=""
|
| 作業 |
1.9.2 |
解決方法：
如要避免 IP 位址不足的問題，請在建立高可用性使用者叢集時，將 Pod CIDR 大小設為 /21 以上。
|
| 安裝 |
1.9.2 |
解決方法：
如要解決這個問題，請重新啟動 Pod。
詳情請參閱 MON-R0001 執行手冊。
|
| 平台驗證 |
1.9.13 |
症狀：
所有 cplb-init 和 storage-ipsec-config-bm-XXXXX 工作都會顯示以下訊息：Failed to connect to the host via ssh: ssh: connect to host 10.1.18.X port 22: Connection timed out。
解決方法：
1. 檢查 aggswitch 上的 BGP VRF 是否已關閉。
2. 檢查防火牆上是否有任何未提交的新暫存設定變更。
3. 清除名稱中含有已刪除機構的所有 securitypolicyrules，然後重新啟動根管理員控制器。
|
| 升級 |
1.9.1
1.9.2
1.9.11 |
症狀：
「Server」在「deprovisioning」卡住超過 20 分鐘。.status.bareMetalHostStatus.provisionState
升級伺服器的管理 IP 位址會顯示在下列任一指令的輸出內容中：
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,option:tftp-server
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,tag:ipxe,option:bootfile-name
解決方法：
如要解決這個問題，請執行下列指令：
kubectl -n gpc-system rollout restart deploy/root-admin-controller
|
| 升級 |
1.9.1
1.9.2
1.9.10
1.9.11
1.9.12
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18 |
症狀：
NodeUpgrade 中有一項升級工作已超過 2 小時未完成。
對應的 NodeUpgradeTask 在條件 NodeResumeCompleted 懸而未決超過 1 小時。
bm-system-x.x.x.x-machine-init 工作長期未完成。x.x.x.x 是節點的位址。
解決方法：
如要找出不正常的節點位址，請參閱懸置 bm-system-x.x.x.x-machine-init 作業的 x.x.x.x。
如要為狀態不良的節點尋找狀態良好的控制層節點，請完成下列步驟：
- 找出健康狀態不良節點的節點集區。
檢查該健康狀態不良節點的相同叢集中的控制層節點集區，然後從該控制層節點集區的 .spec.address 中選取位址。
在啟動程式或 OC IT 中執行：
HEALTHY_CP_NODE_IP=Y.Y.Y.Y # Needs to be entered.
alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"
HARBOR=$(ka get harborcluster harbor -n harbor-system -o=jsonpath="{.spec.externalURL}")
REGISTRY=${HARBOR#https://}
# Download `etcdctl`.
docker run --rm -v $(pwd):/workspace --workdir /workspace ${REGISTRY}/library/anthos-baremetal-release/etcd:v3.4.21-0-gke.1 /bin/sh -c "cp /usr/local/bin/etcdctl /workspace/etcdctl"
scp etcdctl "root@$HEALTHY_CP_NODE_IP:/root/etcdctl"
# SSH into the healthy control plane node.
ssh $HEALTHY_CP_NODE_IP
在健康狀態良好的控制層節點中執行下列指令：
UNHEALTHY_NODE_IP=X.X.X.X # Needs to be entered.
UNHEALTHY_MEMBER=$(ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member list | grep $UNHEALTHY_NODE_IP | cut -d',' -f1)
ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member remove $UNHEALTHY_MEMBER
|
| 升級 |
1.9.1
1.9.2 |
症狀：
ODS Fleet Operator Pod 發生當機迴圈。
如要檢查 Pod 的狀態，請執行下列指令：
ko get pods -n ods-fleet-operator
ODS Fleet Operator 記錄中會顯示類似以下的領導者選舉錯誤：
E0413 18:06:48.614127 1 leaderelection.go:330] error retrieving resource lock ods-fleet-system/af0cf209.dbadmin.gdc.goog: Get "https://172.20.0.1:443/apis/coordination.k8s.io/v1/namespaces/ods-fleet-system/leases/af0cf209.dbadmin.gdc.goog": context deadline exceeded
I0413 18:06:48.614214 1 leaderelection.go:283] failed to renew lease ods-fleet-system/af0cf209.dbadmin.gdc.goog: timed out waiting for the condition
E0413 18:06:48.614460 1 main.go:473] "setup: problem running manager" err="leader election lost" log_name="l1_controller"
如要查看 ODS Fleet Operator 記錄，請執行下列指令：
ko logs deployment/fleet-controller-manager -n ods-fleet-system
系統會顯示以下訊息：
Message: Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgrade error: post-upgrade hooks failed: timed out waiting for the condition: timed out waiting for the condition。
解決方法：
如要編輯部署作業，請執行：
ko edit deployment -n ods-fleet-system fleet-controller-manager
ku edit deployment oracle-controller-manager -n ods-oracle-system
ku edit deployment pg-controller-manager -n ods-postgres-system
請務必按照下列方式編輯 manager 容器的 resources 欄位：
更新前：
resources:
limits:
cpu: 100m
memory: 512Mi
requests:
cpu: 100m
memory: 512Mi
更新後：
resources:
limits:
cpu: 1000m
memory: 1024Mi
requests:
cpu: 1000m
memory: 1024Mi
|
| 升級 |
1.9.2
1.9.3 |
症狀：
系統會顯示下列錯誤訊息：
nvidia-driver-init run the action: init, with options: skip_driver
nvidia-driver-init Find the nvidia card, label this node
nvidia-driver-init node/MACHINE_NAME not labeled
nvidia-driver-init enable nvidia container runtime for ubuntu/debian system
nvidia-driver-init install nvidia container runtime package
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container1_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container1:amd64 (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container1:amd64 (1.12.0-1) ...
nvidia-driver-init Processing triggers for libc-bin (2.31-0ubuntu9.9) ...
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container-tools_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container-tools (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container-tools (1.12.0-1) ...
nvidia-driver-init dpkg: regarding .../nvidia-container-toolkit-base_1.12.0-1_amd64.deb containing nvidia-container-toolkit-base:
nvidia-driver-init nvidia-container-toolkit-base breaks nvidia-container-toolkit (<= 1.10.0-1)
nvidia-driver-init nvidia-container-toolkit (version 1.8.1-1) is present and installed.
nvidia-driver-init dpkg: error processing archive var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb (--install):
nvidia-driver-init installing nvidia-container-toolkit-base would break nvidia-container-toolkit, and
nvidia-driver-init deconfiguration is not permitted (--auto-deconfigure might help)
nvidia-driver-init Errors were encountered while processing:
nvidia-driver-init var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb
解決方法：
如要修正這個問題，請按照下列步驟操作：
登入所有佈建的 GPU 節點：
# ka get servers -A | grep o1-highgpu1-48-gdc-metal
移除舊套件：
root@MACHINE_NAME:~# dpkg -r nvidia-container-runtime nvidia-container-toolkit
(Reading database ... 92154 files and directories currently installed.)
Removing nvidia-container-runtime (3.8.1-1) ...
Removing nvidia-container-toolkit (1.8.1-1) ...
刪除卡住的 kubevm-gpu-driver-daemonset Pod。這樣會重新啟動安裝程序：
# kug get pods -A | grep gpu | grep Init
(選用) 如果外掛程式安裝作業逾時，請重新啟動外掛程式安裝作業：
ku delete job vm-runtime-readiness -n gpu-org-system-cluster
|
| 升級 |
1.9.10
1.9.11 |
症狀：
gpcbackup-agent-0 會顯示 failed to stage volume: iSCSI login failed，但無法設定音量。
檢查 Pod 是否無法附加磁碟區。下列範例使用系統叢集 kubeconfig：
-
描述 Pod：
kos describe pod -n gpc-backup-system gpcbackup-agent-0
如果 Pod 發生故障，系統會顯示類似下列範例的輸出內容：
Warning FailedMount 24m (x1064 over 7d17h) kubelet Unable to attach or mount volumes: unmounted volumes=[gpcbackup-agent-vol], unattached volumes=[kube-api-access-cr45d gpcbackup-agent-vol]: timed out waiting for the condition
Warning FailedMount 9m18s (x4109 over 7d17h) kubelet MountVolume.MountDevice failed for volume "pvc-5df41864-63c5-4589-9569-036fa011f64c" : rpc error: code = Internal desc = failed to stage volume: iSCSI login failed
Warning FailedMount 4m32s (x3840 over 7d17h) kubelet Unable to attach or mount volumes: unmounted volumes=[gpcbackup-agent-vol], unattached volumes=[gpcbackup-agent-vol kube-api-access-cr45d]: timed out waiting for the condition
-
檢查 Pod 失敗的節點：
kos get pod -n gpc-backup-system gpcbackup-agent-0 -o wide
您會取得類似下列範例的輸出內容：
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
gpcbackup-agent-0 0/1 ContainerCreating 0 7d17h [none] vm-e2b9792a [none] [none]
-
在 gpcbackup-agent-0 Pod 失敗的同一節點上取得 netapp-trident Pod：
kos get pod -o wide -n netapp-trident
您會取得類似下列範例的輸出內容：
netapp-trident-node-linux-6kgv4 2/2 Running 0 12h 10.249.20.12 vm-e2b9792a [none] [none]
-
檢查 gpcbackup-agent-0 Pod 失敗的同一節點上 netapp-trident Pod 的記錄：
kos logs -n netapp-trident netapp-trident-node-linux-6kgv4 trident-main
您會取得類似下列範例的輸出內容：
time="2024-01-25T17:35:29Z" level=error msg="Failed to discover targets" error="process killed after timeout" output= portal="172.20.131.41:3260" requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI
time="2024-01-25T17:35:29Z" level=error msg="unable to ensure iSCSI target exists: failed to discover targets: process killed after timeout" err="failed to discover targets: process killed after timeout" iface=default requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI targetIqn="iqn.1992-08.com.netapp:sn.944e1654ac1c11ee86b0d039ea524d51:vs.26" tp="172.20.131.41:3260"
time="2024-01-25T17:35:29Z" level=error msg="GRPC error: rpc error: code = Internal desc = failed to stage volume: iSCSI login failed" requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI
解決方法：
如要解決這個問題，請按照下列步驟操作：
-
取得 InventoryMachine 名稱：
export ROOT_ADMIN_KUBECONFIG=[path to the root admin kubeconfig]
export INV_MACH=vm-e2b9792a
-
確認先前的工作是否存在：
export ORG_ADMIN_KUBECONFIG=[path to the org admin kubeconfig]
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-"${INV_MACH}"
您會取得類似下列內容的輸出：
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 17s 19d
-
刪除工作：
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
您會取得類似下列內容的輸出：
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
確認 StorageEncryptionConnection 是否存在：
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
您會取得類似下列內容的輸出：
NAME INVENTORYMACHINE STORAGEVIRTUALMACHINE STORAGECIDR PRESHAREDKEY READY AGE
vm-e2b9792a vm-e2b9792a org-1-user 172.20.131.32/27 vm-e2b9792a-pre-shared-key True 19d
-
刪除 StorageEncryptionConnection：
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
您會取得類似下列內容的輸出：
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
重新啟動 root-admin-controller Pod：
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout restart deploy -n gpc-system root-admin-controller && kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout status deploy -n gpc-system root-admin-controller
-
確認新工作已重新建立並順利執行：
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-${INV_MACH}
您會取得類似下列內容的輸出：
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 19s 95s
|
| 升級 |
1.9.10
1.9.11 |
症狀：
Harbor 登錄檔 Pod 會顯示類似下列內容的錯誤訊息：
Warning FailedMount 6m52s (x718 over 2d14h) kubelet Unable to attach or mount volumes: unmounted volumes=[storage], unattached volumes=[registry-config authentication-htpasswd internal-certificates sto │
│ age[]: timed out waiting for the condition
解決方法：
如要解決這個問題，請按照下列步驟操作：
-
檢查 Harbor 登錄檔的永久磁碟區要求 (PVC)，並記下 PVC 磁碟區名稱：
kubectl get pvc harbor-registry -n harbor-system
-
如要檢查磁碟區是否附加至與 Harbor 登錄檔 Pod 相同的節點，請列出 volumeattachment，並找出與磁碟區名稱相關聯的項目：
kubectl get volumeattachment | grep [volume-name]
-
如果磁碟區附件與 Harbor 登錄檔 Pod 位於不同節點，請移除 volumeattachment：
kubectl delete volumeattachment [volumeattachment-name]
-
重新啟動 Harbor 登錄檔 Pod。
現在，根管理員叢集中的 Harbor 登錄檔必須正常運作，且節點升級作業已順利完成。
|
| 安裝 |
1.9.2
1.9.3
1.9.4
1.9.5
|
症狀：
系統會顯示下列錯誤訊息：
pod "coredns-75bd7c95f7-fd4cr" in namespace "kube-system" is not ready yet.
Pod 記錄檔包含下列資訊：
[INFO] plugin/ready: Still waiting on: "kubernetes,kubernetes"
CoreDNS 版本為 1.8.6。
解決方法：
如要解決這個問題，請重新啟動 coredns 部署作業。
為正確的叢集設定 KUBECONFIG 後，請執行下列指令：
kubectl rollout restart deployment coredns -n kube-system
錯誤訊息會包含使用者叢集名稱。
如要在 /root/release/user/ 中找出 kubeconfig 檔案，請找出 kubeconfig：org-1-system-user-kubeconfig user-vm-1-user-kubeconfig user-vm-2-user-kubeconfig
如果缺少 kubeconfig 檔案，請按照下列步驟產生：
export KUBECONFIG=/root/release/org-admin/org-1-admin-kubeconfig
kubectl get secrets -n user-vm-1-cluster user-vm-1-kubeconfig -o jsonpath='{.data.value}' | base64 -d > /tmp/user-vm-1-user-kubeconfig
|
| 升級 |
1.9.2
1.9.3 |
症狀：
系統會顯示下列錯誤訊息：
Warning ReconcileBackoff 43m (x9 over 61m) OrganizationUpgrade [UPG1402: unable to set AddOn selector labels for root-admin cluster: Operation cannot be fulfilled on clusters.baremetal.cluster.gke.io "root-admin": the object has been modified; please apply your changes to the latest version and try again, UPG9900: unable to update status: OrganizationUpgrade.upgrade.private.gdc.goog "root" is invalid: [status.errorStatus.errors[0]. errorResource.name: Required value, status.errorStatus.errors[0].errorResource.namespace: Required value]]
這個問題通常是暫時性的，應該會自行解決。
|
| 安裝 |
1.9.3 |
外掛程式安裝失敗，並顯示下列錯誤訊息：
Error occurred during addon installation: failed to install chart: release netapp-trident failed, and has been uninstalled due to atomic being set: failed post-install: timed out waiting for the condition。
解決方法：
節點處於 NotReady 狀態時，外掛程式可能無法安裝。使用下列指令檢查節點是否處於 NotReady 狀態：
kubectl get nodes
取得處於 NotReady 狀態的節點詳細資料：
$ kubectl describe node | grep PodCIDRs
如果叢集發生這個問題，節點就不會獲派 PodCIDR，例如：
PodCIDRs:
For a healthy cluster, all the nodes should have PodCIDRs assigned to it(CIDR shown here is for example purposes only and might vary on the actual cluster based in the Configured ClusterCIDR): eg.
PodCIDRs: 192.168.6.0/24
如要修正這個問題，請在受影響的叢集中重新啟動 ipam-controller 部署作業：
kubectl --kubeconfig KUBECONFIG_PATH -n kube-system rollout restart ds/ipam-controller-manager
|
| 升級 |
1.9.3 |
升級失敗，並顯示下列錯誤：
Rollback "netapp-trident" failed: cannot patch "netapp-trident-csi-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": dial tcp 172.20.5.144:443: i/o timeout && cannot patch "netapp-trident-server-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-client-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-selfsigned-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded。
解決方法：
手動更新 AddOnSet abm-overrides 的欄位 <code.spec.addonsettemplateref< code="" dir="ltr" translate="no">，將其設為要升級的叢集所在命名空間中，所需版本的 AddOnSetTemplate 名稱。</code.spec.addonsettemplateref<>
|
| 安裝 |
1.9.3 |
症狀：
車隊管理控制器無法通過 TestCreateFleetAdminCluster 或 TestSimOverlayCreateFleetAdminCluster 測試，因此無法就緒。 車隊管理員控制器陷入當機迴圈。 機群管理控制器記錄中顯示以下錯誤：Fleet admin controller manager stopped: failed to wait for auditloggingtarget caches to sync: timed out waiting for cache to be synced。
解決方法：
將 Logmon CRD 部署至機構管理員叢集。 重新啟動車隊管理控制器。
|
| 安裝 |
1.9.3 |
症狀：
系統會顯示下列錯誤訊息：
k8s_mt_system_cluster_healthcheck_test.go:147: system cluster did not become ready in time: cluster "org-1-system-cluster/org-1-system" did not become healthy in time: [waitingForClusterHealth] WaitForSuccess gave up [...] unable to retrieve logs for pod "anthos-prometheus-k8s-0" [...] pod "anthos-prometheus-k8s-0" in namespace "obs-system" is not ready yet. [...] Message:containers with unready status: [config-reload prometheus-server] [...]
解決方法：
如要解決這個問題，請在叢集中重新啟動部署作業和 DaemonSet：
kubectl rollout restart deploy/netapp-trident-csi -n netapp-trident
kubectl rollout restart daemonset/netapp-trident-csi -n netapp-trident
注意：重新啟動部署作業和 DaemonSet 前，請先執行下列指令，指向正確的叢集：
export KUBECONFIG=/root/release/system/org-1-system-kubeconfig
|
| 升級 |
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8 |
症狀：
CPU 不足，因此無法排定 Pod。
解決方法：
如果是以 n2-standard-4 工作站節點建立的現有使用者叢集，請先在這個叢集中新增具有三個節點的 n2-standard-8 NodePool，再進行升級。 如果是新的使用者叢集，請建立一個 n2-standard-8 NodePool，其中至少要有三個節點。詳情請參閱「為容器工作負載建立使用者叢集」。
|
| 作業 |
1.9.0
1.9.2
1.9.3
1.9.4 |
症狀：
VM 執行個體 PHASE 會顯示 Scheduling 和 READY，
並維持 False 狀態，永遠不會達到 True 狀態。這項異動會影響兩種機器類型，如因應措施中所列。其他機型不受影響，也不需要套用解決方法。
解決方法：
- 建立使用 A100 40G GPU 的使用者叢集時，請務必從 UI 選取 a2-highgpu-1g-gdc 機器類型。
- 建立使用 A100 80G GPU 的使用者叢集時，請務必從 UI 選取 a2-ultragpu-1g-gdc 機器類型。
|
| 作業 |
1.9.0
1.9.2
1.9.3
1.9.4 |
症狀：
如果節點集含有記憶體大小超過 32 GB 的 VM 執行個體，VM 執行個體可能會先執行，然後停止，接著再次執行，並可能重複這個順序。最終，系統會擲回記憶體不足的 OOMKilled 錯誤，導致執行個體失敗。
以下是三種受影響的 VM 類型：
- n2-highmem-8-gdc：64 GB 記憶體
- a2-highgpu-1g-gdc：85 GB 記憶體
- a2-ultragpu-1g-gdc：170 GB 記憶體
解決方法：
- 確認機型：
kubectl --kubeconfig= get gvm vm-8c440bc4 -n gdch-vm-infra
- 在
spec.compute.virtualMachineTypeName 輸出內容。
- 如果 VM 類型是列出的三種類型之一，請編輯
configmap，加入記憶體覆寫：
kubectl --kubeconfig=SYSTEM_CLUSTER_KUBECONFIG \
edit configmap NAME -n NAMESPACE
- 新增
memory.guest 和 resources.overcommitGuestOverhead 區段，如下列範例所示：
apiVersion: v1
kind: ConfigMap
metadata:
name: vm-8c440bc4
namespace: gdch-vm-infra
data:
virtSpec: |
template:
spec:
domain:
...
...
memory:
guest: "MEMORY_SIZE"
resources:
overcommitGuestOverhead: true
...
...
- 在
memory 中，將 guest 變更為下列值：
- 如果是 n2-highmem-8-gdc，請建立 MEMORY_SIZE
63.6G。
- 如果是 a2-highgpu-1g-gdc，請將 MEMORY_SIZE
84G。
- 如果是 a2-ultragpu-1g-gdc，請將 MEMORY_SIZE
168G。
- 對所有受影響的 VM 重複執行這項操作。
|
| 升級 |
1.9.4 |
症狀：
bm-system-* 工作停滯在 Gathering Facts 步驟。嘗試手動 SSH 連線至伺服器時，系統會顯示 PTY allocation request failed on channel 0。
解決方法：
使用下列任一方法重新啟動伺服器：
curl -X POST -H "content-type: application/json" -k -u $ILO_USER:$ILO_PWD https://$ILO_IP/redfish/v1/Systems/1/Actions/ComputerSystem.Reset
iLO UI kubectl --kubeconfig=$ROOT_ADMIN_KUBECONFIG annotate -n gpc-system bmh/$SERVER "reboot.metal3.io"=""
|
| 升級 |
1.9.4
1.9.10 |
症狀：
backup-ipsec-* 工作失敗，導致升級失敗。
解決方法：
請按照下列步驟操作：
在機構管理員叢集的 gpc-system 命名空間中，找出預先共用金鑰。金鑰名稱為 <node-name>-pre-shared-key。
如要從工作節點的預先共用金鑰 YAML 取得金鑰雜湊，請使用 kubectl get --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig -n gpc-system secret <not-failed-node-name>-pre-shared-key -o=jsonpath='{.data.pre-shared-key}' | awk '{ print $1 }'。
請注意，您必須從 ipsec 升級失敗的節點以外的節點取得金鑰雜湊。 將這個預先共用金鑰的雜湊套用至機構管理員叢集 gpc-system 中失敗節點的預先共用金鑰密碼。 刪除根管理叢集中與失敗節點同名的 storageencryptionconnection 物件。 在機構管理員叢集中刪除相關聯的 storage-ipsec-config-<node-name> 工作。 刪除相關聯的 backup-ipsec-for-upgrade-<node-name> 升級工作。
|
| 升級 |
1.9.4 |
症狀：
升級機構叢集需要很長時間。
解決方法：
等待 clamav 自然關機。
|
| 升級 |
1.9.5 |
症狀：
系統會顯示不同的憑證：
echo $(kubectl get secret harbor-cert-secret -n istio-system -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBqjCCAS+gAwIBAgIQSve6hYhac9nZr/u/l/hPzjAKBggqhkjOPQQDAzAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTcwMzQ3MjhaFw0yODA3MTUwMzQ3
MjhaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MHYwEAYHKoZIzj0CAQYFK4EEACID
YgAEsGCynvjnSNNIdz3PxpEqvogHAITWyB3jJbA6jxQhics5MYuq2biaqLg38Ly1
3mF6CRh9Tzroxg2Wtu339McKTAC/7v61ZsbGXbj3eQiTECJut/a55BekG7FcwVG/
btbAo0IwQDAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E
FgQUUh1ZUS9CUIHgQmJZTj8m3MIINS8wCgYIKoZIzj0EAwMDaQAwZgIxALDea5fh
IeafRNzR3pjYRgW++TCYZU3XVSJ04K8eIBy1wz1XRDR5SWFgJ/ejWZGUagIxAIQP
9A42lzd7gyqaAAlRB+TQ0sMJMOOyNl0gFg5ZVyhGdJfsZpv1XrcLcqX3tejydw==
-----END CERTIFICATE-----
echo $(kubectl get secret ca-cert-10.2.2.101.10443 -n anthos-creds -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBazCCARKgAwIBAgIQKkDVSpMZf9CQEHxx7UFPmDAKBggqhkjOPQQDAjAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTYwOTQzMTlaFw0yNDA3MTUwOTQz
MTlaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MFkwEwYHKoZIzj0CAQYIKoZIzj0D
AQcDQgAEI4hXIh65Zc8sWaPQL9gqz3lrq22A1XJsRrMwl/pk3vZiNLGS3+Tt9tXc
WDP74IbinOxZ1Auw08e3s4sxCahfyqNCMEAwDgYDVR0PAQH/BAQDAgKkMA8GA1Ud
EwEB/wQFMAMBAf8wHQYDVR0OBBYEFN8ob6e8WeFELnVKPSdtMfyvRP95MAoGCCqG
SM49BAMCA0cAMEQCIF8P5THYBHcOdcn1u7zi+Y4jwDTdLAeaDZbVxUDEK2EaAiBW
zilvR3YvW7h5OdSUsgFkSQ42FcSIoNHWYNSZx16CeQ==
-----END CERTIFICATE-----
解決方法：
注意：請先旋轉 harbor-harbor-https 認證，再執行下列步驟。
請按照下列步驟操作：
叢集內的密鑰會儲存憑證資料副本。輪替 harbor-harbor-https 憑證後，您也必須更新密鑰副本。
- 擷取 Artifact Registry 網址。
export registry_url=$(kubectl get harborcluster/harbor -n harbor-system -o json | jq -r '.spec.externalURL')
- 更新每個命名空間中的 Artifact Registry 憑證密鑰副本。
取得儲存 Artifact Registry 憑證密鑰副本的所有命名空間。
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
在每個命名空間中，更新 Artifact Registry 憑證密碼副本。
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done
- 如果是根管理員叢集，您也需要在
anthos-creds 命名空間中，更新名為 ca-cert-in-cluster-registry 的修正程式 (即憑證密鑰副本)。
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n anthos-creds patch secret/ca-cert-in-cluster-registry -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"
- 更新
kube-system 命名空間中儲存的 registry-cert。
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n kube-system patch secret/registry-cert -p "{\"data\":{\"registry-cert\":\"${cert_data}\"}}"
- 如果您要輪替機構管理員叢集的憑證，也必須更新根管理員叢集中的憑證密鑰副本。
取得儲存 Artifact Registry 憑證密鑰副本的所有命名空間。
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
在每個命名空間中，更新 Artifact Registry 憑證密碼副本。
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done 。
|
| 升級 |
1.10.0
1.10.1 |
症狀：
啟動 OrganizationUpgrade 後，kube-apiserver Pod 未在一或多個節點上執行。
- 找出升級作業遭到封鎖的節點：
kubectl get po -n kube-system -l component=kube-apiserver
輸出如下所示：
NAME READY STATUS RESTARTS AGE
kube-apiserver-ah-aa-bm01 1/1 Running 0 12h
kube-apiserver-ah-ab-bm01 1/1 Running 0 11h
kube-apiserver-ah-ac-bm01 1/1 Error 0 12h
- 與剛更新的節點建立 SSH 連線：
root@ah-ac-bm01:~# crictl ps -a | grep kube-api
您會看到容器狀態為 Exited：
f1771b8aad929 bd6ed897ecfe2 17 seconds ago Exited kube-apiserver 2 8ceebaf342eb8 kube-apiserver-ah-ac-bm01
bd14d51b01c09 d0bac8239ee3a 5 minutes ago Exited
- 檢查
Exited Pod 的記錄：
crictl logs f1771b8aad929
輸出如下所示：
Error: invalid argument "JobTrackingWithFinalizers=false" for "--feature-gates" flag: cannot set feature gate JobTrackingWithFinalizers to false, feature is locked to true
旗標是在 /etc/kubernetes/manifests/kube-apiserver.yaml 檔案中設定： root@ah-ac-bm01:~# grep JobTrackingWithFinalizers /etc/kubernetes/manifests/kube-apiserver.yaml
- --feature-gates=JobTrackingWithFinalizers=false
解決方法：
從 /etc/kubernetes/manifests/kube-apiserver.yaml 檔案中移除標記。
- 備份檔案：
root@ah-ac-bm01:~# cp /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
- 移除該行：
root@ah-ac-bm01:~# sed -i '/--feature-gates=JobTrackingWithFinalizers=false/d' /etc/kubernetes/manifests/kube-apiserver.yaml
- 確認已移除該行：
root@ah-ac-bm01:~# diff /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
35a36
> - --feature-gates=JobTrackingWithFinalizers=false
- 列出
kube-apiserver 容器：
root@ah-ac-bm01:~# crictl ps --name kube-apiserver
kubelet 會自動擷取變更，並啟動 kube-apiserver Pod：
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
e1344008dfed9 bd6ed897ecfe2 12 hours ago Running
- 針對所有受影響的節點重複這些步驟。
|
| 升級 |
1.9.2
1.9.3
1.9.3
1.9.4
1.9.5
1.9.6 |
症狀：
在憑證輪替後，kube-state-metrics 部署作業會在機構中發生當機迴圈。這個問題可能會導致監控資料遺失。
|
| 升級 |
1.9.6 |
症狀：
升級後，工作節點會失去平衡。
解決方法：
手動平衡工作站節點：
- 如果是 Pod 工作負載，請刪除部署作業中的 Pod。
- 如果是 VM 工作負載，請刪除 virt-launcher，但不要修改控制層 GVM 物件。
|
| 升級 |
1.9.6 |
從 1.9.5 升級至 1.9.6 時，GPU 裝置外掛程式可能無法啟動。 症狀：
您可能會看到下列錯誤，導致 VM 無法執行階段準備作業和升級程序：
Failed to initialize NVML: could not load NVML library
解決方法：
- 檢查節點上的
nvidia-container-runtime 是否已正確設定：
- 建立與懷疑有問題的節點之間的 SSH 連線。
- 取得 Pod 清單：
crictl pods
- 檢查 Pod：
crictl inspectp $pod_hash | grep runtimeOption -A1
如果輸出內容如下所示，表示節點設定正確。如果輸出內容與上述不同，表示節點上未設定 nvidia-container-runtime：binary_name": "/usr/bin/nvidia-container-runtime"
- 如果
nvidia-container-runtime 設定不正確，請重新啟動 containerd 來解決問題：systemctl restart containerd
|
| 升級 |
1.9.7 |
升級至 1.9.7 時，根管理員叢集節點集區韌體會維持 in process 狀態。
症狀：
- 如要瞭解
NodeUpgrade 端的解決方法，請參閱「構件伺服器逾時」一文：
NodeUpgrade 停留在 in process 狀態，且 Nodeupgradetask 狀態的 NodeROMFirmwareUpgradeCompleted 條件一律未完成。- 連線至
NodeUpgrade 物件時，spec.firmware.firmwarePackages.url 中的網址可能會停止回應，例如：
curl -k https://10.248.2.71:30938/artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU= -o /tmp/file.cow2
- 如要瞭解
Harbor 端的解決方法，請參閱「構件伺服器未經授權」：
- 在構件伺服器記錄中，可能會顯示與未經授權存取存放區相關的錯誤：
gdch-hpe-firmware/ilo，例如：
root@bootstrapper:~# kubectl --kubeconfig ${KUBECONFIG} logs -n gpc-system -l name=artifact-registry-services-artifact-server -f
artifact-server I1108 05:20:28.084320 1 artifact_server.go:171] Pulling artifact at path /artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU=
artifact-server E1108 05:20:28.159685 1 artifact_server.go:194] Error fetching image 10.249.23.11:10443/gdch-hpe-firmware/ilo:ilo5: GET https://10.249.23.11:10443/v2/gdch-hpe-firmware/ilo/manifests/ilo5: UNAUTHORIZED: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull
- 在 Harbor 專案中，
gdch-hpe-firmware 必須具有 做為 private：
Spec.harborProjectConfig.accessLevelkubectl get --kubeconfig ${KUBECONFIG} HarborProject -n gpc-system gdch-hpe-firmware -o yaml
解決方法：
|
| 網路效能較低 |
1.9.0 - 1.9.6 |
症狀：
機構內部網路的 BGP 工作階段停止運作。只有一個機構的內部 BGP 對等互連端點會新增至 TORSwitchInternal 物件。
解決方法：
明確變更 {organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim 中使用的子網路，確保不會與其他機構的類似 AddressPoolClaim 資源重疊。
- 調查症狀：
- 針對每個機構系統叢集，執行下列指令：
kubectl get bgpsessions -A --kubeconfig ORG_SYSTEM_KUBECONFIG
- 檢查每個
BGPSession 物件的 State 欄位，確認 NotEstablished 的 State。記下每個相關聯 NotEstablished BGPSession 的 LocalIP，以供日後使用。
- 判斷
"System cluster BGP Sessions cannot be established due to overlapping ClusterIPs" 是否為根本原因：
- 針對每個有效機構，執行下列指令：
kubectl get clusterbgppeers -A --kubeconfig ORG_ADMIN_KUBECONFIG_FILE -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CLUSTERIP:.spec.clusterIP | grep flat-ip
- 在輸出內容的
ClusterIP 欄位 (第 3 欄) 中，搜尋步驟 1.b 中記下的 LocalIPs。記下與輸出內容第 3 欄項目相符的 LocalIP，以供稍後使用。如果有多個不同的機構管理員叢集，且步驟 2.a 的輸出內容包含步驟 1.b 中註明的 LocalIP，請繼續執行步驟 3。
- 解決機構系統叢集使用的 IP 位址重疊問題。
- 執行：
kubectl get subnetclaims -A --kubeconfig ROOT_ADMIN_KUBECONFIG -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CIDRBLOCK:.status.ipv4SubnetStatus.cidrBlock | grep worker-node
- 請記下查詢 3.a 傳回的
SubnetClaim 物件數量。這必須等於有效機構的數量。
- 請記下每一列的命名空間 (第 1 欄) 和 CIDR 區塊 (第 3 欄)。每一列的 CIDR 區塊應與其他列的 CIDR 區塊相同。
- 針對每個機構執行下列步驟：
- 前往該機構的機構管理員叢集中的
{organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim 物件。
- 計算該機構工作站節點位址集區聲明的
Start IP。如要執行這項操作，請從 3.c 取得 CIDR 區塊，並從 3.d.i 取得 AddressPoolClaim 中的 Size 欄位。從 CIDR 區塊中的倒數第二個 IP 開始，向下計算 Size IP 個 IP。這是第一個機構的新 Start IP (用於步驟 3.d.iii)。每增加一個機構，就從前一個機構的新 Start IP 開始倒數 Size IP。
例如：
CIDR block: 10.0.0.0/24
org-1, org-2, & org-3 AddressPoolClaim Size: 2
- New org-1 startIPAddress: 10.0.0.252
- New org-2 startIPAddress: 10.0.0.250
- New org-3 startIPAddress: 10.0.0.248
- 在步驟 3.c.i 的
AddressPoolClaim 中，於 Spec 欄位中新增下列欄位：
staticIPRanges:
- startIPAddress: {Start IP from step 3.d.ii}
size: {Size from step 3.d.ii}
使用下列指令：
`kubectl edit addresspoolclaim ADDRESS_POOL_CLAIM_NAME -n ORGANIZATION_NAME-system-cluster --kubeconfig ORGANIZATION_ADMIN_KUBECONFIG
如果您使用 3.d.ii 中的 org-1，結果應如下所示：
apiVersion: system.private.gdc.goog/v1alpha1
kind: AddressPoolClaim
metadata:
name: org-1-system-bgp-flat-ip-ipv4-apc
namespace: org-1-system-cluster
...
spec:
category: InternalOverlayNetwork
...
parentReference:
name: worker-node-network-subnet
type: SubnetClaim
size: 2
staticIPRanges:
- startIPAddress: 10.0.0.252
size: 2
status:
allocatedIPRanges: ...
...
- 請進行清理，避免 TORSwitch 硬體上出現不必要的 BGP 工作階段。
- 如要列出所有需要更新的
TORSwitchInternal 資源，請執行：
kubectl get torswitchinternals --kubeconfig ROOT_ADMIN_KUBECONFIG -A
- 針對上一個指令輸出中列出的每個
TORSwitchInternals，執行下列指令：
kubectl edit torswitchinternal TOR_SWITCH_INTERNAL_NAME --kubeconfig ROOT_ADMIN_KUBECONFIG -n gpc-system
- 針對所有
TORSwitchInternal 物件，從 .spec.ebgpNeighbors 清單中移除所有 NeighborIP 等於步驟 2.b 中任何 LocalIP 的項目。舉例來說，步驟 2.b 中已記錄 LocalIP 的 2.2.2.2。下方是清理步驟前後的 TORSwitchInternal 範例。
清除前：
apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
- md5SecretReference: {}
neighborIP: 2.2.2.2
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
清除後。請注意已移除的 ebgpNeighbor 項目：
apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
- 執行步驟 1 並確認所有
BGPSession 物件 States 都已返回 Established，即可進行驗證。所有修改內容可能需要約 10 分鐘，才會傳播至實體 GDC TORSwitch 設定。
|
| 升級 |
1.9.7 - 1.9.21 |
升級期間，節點和作業系統升級作業可能會無法順利進行。
症狀：
您可能會看到節點的狀態為 Ready, SchedulingDisabled，並持續數小時。
kubectl --kubeconfig $ROOT_ADMIN_KUBECONFIG get no
NAME STATUS ROLES AGE VERSION
aa-bm01 Ready, SchedulingDisabled control-plane 52d v1.27.4-gke.500
ab-bm01 Ready control-plane 52d v1.27.4-gke.500
ac-bm01 Ready control-plane 52d v1.27.4-gke.500
解決方法：
- 請按照 runbook PLATAUTH-SSH 0001 的指示，取得相關節點的 SSH 金鑰。透過 SSH 連線至節點後，請執行下列指令：
multipath -ll | grep fail
- 只有在輸出內容與下列內容類似時，才繼續執行下一個步驟：
size=1.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 7:0:0:7 sdad 65:208 failed faulty running
| `- 8:0:0:7 sdae 65:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
|- 6:0:0:7 sdac 65:192 failed faulty running
`- 5:0:0:7 sdab 65:176 failed faulty running
- 執行下列指令來修正問題：
systemctl stop multipathd
iscsiadm -m session -R
systemctl start multipathd
|
| 升級 |
1.9.8-1.9.21 |
症狀：
如果 ABM 叢集升級作業停滯超過 2 小時，節點排空作業可能會遭到封鎖。
解決方法：
以下作業以根管理員叢集為例。${TARGET_KUBECONFIG} 是指目標 ABM 叢集的 `kubeconfig`，該叢集的節點排空作業遭到封鎖；${KUBECONFIG} 是指管理目標 ABM 叢集的叢集 kubeconfig。如果是根管理員叢集，兩者都指向根管理員 kubeconfig。
如要查看 ABM 叢集升級是否卡住，請完成下列步驟：
- 檢查節點是否卡在排空狀態：
kubectl --kubeconfig=${KUBECONFIG} get cluster -n root root-admin -ojsonpath={.status.controlPlaneNodePoolStatus.nodesDraining}; echo
結果如下：
{"10.200.0.2": 2}
這表示節點「10.200.0.2」有兩個 Pod 正在排空。
- 檢查節點是否仍會耗用 Pod (稱為
${NODE_BEING_DRAINED})：
kubectl --kubeconfig=${KUBECONFIG} get baremetalmachine -n root ${NODE_BEING_DRAINED:?} -ojsonpath='{range .status.bareMetalMachineDrainingStatus.podsYetToDrain[?(@.kind=="Pod")]}{@.namespace}{", "}{@.name}{"\n"}{end}'
輸出 Pod 數量必須與上一個步驟中回報的排空 Pod 數量相同。
針對步驟 1 列出的每個 Pod yetToDrain，檢查 Pod 的狀態：
kubectl --kubeconfig=${TARGET_KUBECONFIG} get pods -n ${POD_NAMESPACE} ${POD_NAME} -o wide
如果 Pod 處於 Running 狀態，或是 Pod 位於 obs-system 命名空間中，且 Pod 沒有任何抱怨 unable to unmount volume 的事件，請使用 grace-period 明確刪除 Pod。audit-logs-loki-0loki-0 kubectl --kubeconfig=${TARGET_KUBECONFIG} delete pods --grace-period=30 -n ${POD_NAMESPACE} ${POD_NAME}
- 如果廣告連播無法排空，請將案件轉交給隨時待命服務。
- 監控節點的排空作業是否完成。
- 如果其他節點也卡在排空狀態，請重複步驟一。
|
| 升級 |
1.9.6
1.9.7
1.9.8
|
由於 DistributionPolicy 中的 Override 旗標設為 false，因此無法發布含有已簽署構件的 1.9 版本，這會導致目的地登錄檔中出現同名構件時，無法發布該版本。
症狀：
你可能會遇到下列問題：
- 推送含簽章的構件。記錄可能如下所示：
pushing the manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- 無法推送構件。記錄可能如下所示：
failed to push manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- 找不到 404 構件。記錄可能如下所示：
http status code: 404, body: {"errors":[{"code":"NOT_FOUND","message":"artifact library/private-cloud-staging/goharbor/harbor-core@sha256:755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a not found"}]}
- 構件發布失敗。
解決方法：
如要解決這個問題，請按照下列步驟操作：
- 更新
DistributionPolicy 自訂資源 (CR)，將 Spec.Override 設為 true。
- 按照 SAR-1005 Runbook 的指示，重新觸發複製作業。
- 新的複製作業成功執行後，請在
Annotation 中使用成功執行的 ID 更新 ManualDistribution CR execution-ids。
|
| 硬體安全性模組 (HSM) |
1.9.9 |
HSM 可能會間歇性回報 ServicesNotStarted，導致裸機伺服器無法正常運作，並回報下列訊息：
"message": "failed to get master key name"
症狀：
你可能會遇到下列問題：
解決方法：
如要解決這個問題，請按照下列步驟重新啟動卡住的 HSM：
- 從第一個 HSM 執行下列指令，安裝
kstl 工具：
export HSM_NAME=`kubectl get hsm \
-n gpc-system -o jsonpath={.items[0].metadata.name} | tr -d '"'`
export HSM_MGMT_IP=$(kubectl get hsm $HSM_NAME \
--namespace gpc-system \
--output jsonpath="{.spec.managementNetwork.ip}")
curl --insecure \
https://$HSM_MGMT_IP/downloads/ksctl_images.zip \
--output ksctl_images.zip
mkdir -p ~/bin
unzip ksctl_images.zip -d ~/bin
cp ~/bin/ksctl-linux-amd64 ~/bin/ksctl
export PATH=$PATH:~/bin
mkdir -p $HOME/.ksctl
export ADMIN_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "admin" | grep -v "luna-admin" | grep -v "ksadmin"`
export ADMIN_PW=$(kubectl get secrets $ADMIN_SECRET_NAME -n hsm-system -o jsonpath="{.data.password}" | base64 -d)
export ADMIN_SSH_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "ssh"`
kubectl get secret $ADMIN_SSH_SECRET_NAME \
--namespace=hsm-system \
--output jsonpath='{.data.ssh-privatekey}' \
| base64 --decode > $HOME/.ksctl/ssh-privatekey
chmod 0600 $HOME/.ksctl/ssh-privatekey
cat << EOF > $HOME/.ksctl/config.yaml
KSCTL_URL: https://$HSM_MGMT_IP:443
KSCTL_USERNAME: admin
KSCTL_PASSWORD: '$ADMIN_PW'
KSCTL_NOSSLVERIFY: true
EOF
- 確認 HSM 是否無法重新啟動。針對每個停滯在
ServicesNotStarted 的 HSM，取得 $HSM_MGMT_IP 並確認服務已停止運作：
ksctl services status --url=https://$HSM_MGMT_IP
- 暫停所有 HSM、HSM 叢集和 HSM 租戶：
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
- 在服務關閉的情況下，建立與 HSM 的 SSH 連線：
ssh -i $HOME/.ksctl/ssh-privatekey ksadmin@$HSM_MGMT_IP
- 確認您位於正確的 HSM。確認您是否已使用正確的
$HSM_MGMT_IP 建立 SSH 連線。
- 從 HSM 內部重新啟動第一個 HSM：
ksadmin@ciphertrust:~ sudo reboot
- 從 HSM 外部等待第一個 HSM 恢復正常：
watch -c ksctl services status --url=https://$HSM_MGMT_IP
HSM 重新啟動可能需要約五分鐘。
- 針對服務中斷的其他 HSM 重複執行這些步驟。
- 取消暫停 HSM、HSM 叢集和 HSM 租戶：
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
- 確認所有項目都已對帳。HSM 可能需要五到十分鐘才能完成同步。
|
| 監控 |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9 |
症狀：
如果 GDC 版本早於 1.11.3，組織系統叢集的 alertmanager-servicenow-webhook 快訊不會傳送至 ServiceNow。記錄檔含有錯誤訊息 read: connection reset by peer。這是因為缺少啟用輸出流量的標籤。如果 Webhook 需要在機構之間通訊，就必須使用輸出 NAT。
解決方法：
您必須在機構系統叢集中啟用 alertmanager-servicenow-webhook 的輸出流量。如要解決這個問題，請按照下列步驟操作：
- 設定必要條件：
- 安裝 gdcloud 指令列介面 (CLI)。
- 取得根管理員和機構管理員叢集的 kubeconfig 檔案路徑。將路徑分別儲存在
ROOT_KUBECONFIG 和 ORG_SYSTEM_KUBECONFIG 環境變數中。
- 請安全管理員在根管理員和機構管理員叢集的
obs-system 命名空間中，授予您可觀測性管理員 (observability-admin) 角色。
- 確認環境中是否發生問題：
- 取得
alertmanager-servicenow-webhook 部署作業：
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -n obs-system
- 查看
alertmanager-servicenow-webhook 部署作業的記錄：
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" logs deployment/alertmanager-servicenow-webhook -n obs-system
如果記錄檔包含 read: connection reset by peer 錯誤訊息，表示問題存在，您必須繼續執行這項解決方法的步驟。
- 新增出口標籤：
- 取得目前的
alertmanager-servicenow-webhookdeployment YAML 檔案：
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-existing-deployment.yaml && \
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
- 在
alertmanager-servicenow-webhook 部署作業 YAML 檔案中新增輸出標籤：
yq e -i '.spec.template.metadata.labels += {"egress.networking.gke.io/enabled": "true"}' $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
- 使用更新內容取代
alertmanager-servicenow-webhook 部署作業 YAML 檔案：
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-new-deployment.yaml -n obs-system
部署作業必須自動重新啟動。
- 再次執行「確認環境中存在問題」步驟，確認問題是否已修正。記錄檔不得顯示錯誤訊息。否則，請轉交給工程團隊。
復原策略：
如果變通步驟失敗或指標有任何損失，請將 alertmanager-servicenow-webhook 部署 YAML 檔案還原為原始狀態：
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-existing-deployment.yaml -n obs-system
|
| 升級 |
1.9.10 |
症狀：
升級作業停滯在 NodeMaintain 步驟。
gpc-system org-1-admin-control-plane-node-poolphdzg 1 in-progress 3h58m
Status: Tasks:
Name: zp-aa-bm06 Task Status: finished
Name: zp-aa-bm04
Task Status: finished
Name: zp-aa-bm05
Task Status: in-progress
Upgrade Status: in-progress
Events: none
進行中的節點集區會顯示 nodeupgradetask：
Status: Conditions: Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: Succeeded
Status: True
Type: PreUpgradeValidationCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: InProgress
Status: False
Type: NodeMaintainCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message: Observed Generation:1
Reason: Reconciling
Status: Unknown
Type: Succeeded
│ Data IP:10.249.20.4 bm-5f3d1782
│ Start Time: 2023-11-09T18:26:31Z
│ Events: none
解決方法：
請按照下列步驟操作：
- 取得 cap-controller-manager 部署作業的名稱。
kubectl --kubeconfig ${KUBECONFIG} get deployment -n kube-system | grep cap-controller-manager
cap-controller-manager-1.28.0-gke.435 1/1 1 1 30h
- 指定 cap-controller-manager 的名稱 (例如：cap-controller-manager-1.28.0-gke.435)：
export CAP_DEPLOYMENT_NAME=
- 重新啟動 cap-controller-manager。
kubectl --kubeconfig ${KUBECONFIG} rollout restart deployment ${CAP_DEPLOYMENT_NAME} -n kube-system
deployment.apps/cap-controller-manager-1.28.0-gke.435 restarted
|
| 升級 |
1.9.10 |
症狀：
升級作業停滯在AdminClusterHealth後續檢查步驟。 Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileBackoff 70s (x33 over 4h16m) OrganizationUpgrade admin cluster is not ready for org root
機構物件會顯示：
NAMESPACE NAME READY
gpc-system org-1 True
gpc-system root False
解決方法：
請按照下列步驟操作：
使用下列指令略過前置檢查：
kubectl delete organizationupgrade name -n gpc-system && kubectl annotate -n gpc-system organization name upgrade.private.gdc.goog/skip-preflight-check=ok
|
| 升級 |
1.9.9 |
症狀：
NodeUpgradeTask可能具有 failed to monitor failover registry recreation: failed to monitor job: job not complete 條件，導致工作無法完成。
解決方法：
如要解決這個問題，請重新啟動工作：
- 刪除名為
create-failover-registry-*** 的工作，該工作完成度為「0/1」。
- 從要升級的伺服器物件中刪除
failover-registry-creation-job-name 註解。
控制器會自動再次建立工作。
|
| 升級 |
1.9.20 |
症狀：
節點在 backup-ipsec-for-upgrade-bm 工作中失敗。
I0512 01:05:55.949814 7 main.go:24] BuildDate: 2023-04-01T15:48:57Z
I0512 01:05:55.949920 7 main.go:25] Version: 1.9.2-gdch.135.dirty
"
解決方法：
刪除 `backup-ipsec-for-upgrade-bm` 工作，並等待系統重新建立。
|
| Google Distributed Cloud |
1.9.9 |
症狀：
由於 etcd 叢集無法啟動，控制層節點集區無法就緒。你可能會遇到下列問題：
--- FAIL: TestPlan (27563.26s)
--- FAIL: TestPlan/TestMTSystemClusterHealth (3445.24s)
k8s_mt_system_cluster_healthcheck_test.go:149: FATAL FLAKE: TestMTSystemClusterHealth: system cluster did not become ready in time: NodePool org-1-system-cluster/control-plane-node-pool didn't get ready: NodePool "control-plane-node-pool" is not ready
Error Routing:
{
"Name": "NODEPOOL_NOT_READY_ERR",
"Description": "NodePool is not ready",
"OwnerTeam": "Cluster Management",
"OwnerLDAP": "",
"TrackingBug""
}
FAIL
解決方法：
如要解決這個問題，請按照下列步驟操作：
- 檢查叢集建立作業是否停滯在機器初始化工作。
kubeadm join 工作失敗，原因如下：
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members
kubeadm reset 工作失敗，原因如下：
panic: runtime error: invalid memory address or nil pointer dereference
- 使用 SSH 連線至運作中的控制台節點。
- 執行
etcdctl 指令，清除過時資料。
- 檢查
etcd 會員方案：
# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member list
5feb7ac839625038, started, vm-72fed95a, https://10.252.164.11:2380, https://10.252.164.11:2379, false
99f09f145a74cb15, started, vm-8a5bc966, https://10.252.164.12:2380, https://10.252.164.12:2379, false
bd1949bcb70e2cb5, unstarted, , https://10.252.164.10:2380, , false
- 移除過時的成員資格：
# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member remove bd1949bcb70e2cb5
Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
|
| 備份及還原 VM |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9
1.9.10
1.9.11 |
症狀：
由於 VM 管理工具中的角色型存取權控管 (RBAC) 和結構定義設定不正確，使用者無法啟動 VM 備份和還原程序。
虛擬機器備份方案名稱不得超過 63 個字元。
舉例來說，您可能會看到下列錯誤訊息：
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.9.9 |
症狀：
升級作業會導致備份 ipsec 工作失敗，並顯示下列範本錯誤：
"msg": "An unhandled exception occurred while templating '{'changed': True, 'stdout': 'connections {\\n # A connection id defined for this specific connection\\n pol_client {\\n children {\\n pol_cli
解決方法：
請按照下列步驟操作：
登入升級工作失敗的節點。 儲存 swanctl.conf 做為備份。 移除 /etc/swanctl/swanctl.conf 檔案中含有大括號的那一行。 刪除失敗的 backup-ipsec-for-upgrade 工作，等待系統重新建立工作，後續工作就會順利完成。 將步驟 3 中移除的程式碼行加回 /etc/swanctl/swanctl.conf。
|
| 節點平台 |
1.9.6
1.9.7
1.9.8
1.9.9 |
在根管理員叢集上啟動韌體升級時，其中一個節點完成節點升級後，系統會顯示升級作業停滯。 症狀：
nodeupgradetask停滯在「NodeResumeCompleted」階段。machine-init 工作失敗，且記錄顯示 kubeadm join 失敗。- 您無法使用資料平面 IP 位址建立節點的 SSH 連線。
問題原因是升級後的節點不再接受傳入的網路流量。
解決方法：
- 檢查任何失敗的
job/nodeupgradetask 記錄，記下 IP 位址，並找出有問題的節點。
- 重新啟動受影響節點的
anetd-client Pod。
- 在資料平面 IP 上，驗證與受影響節點的 SSH 連線。
選用步驟 (進一步調查)：
- 將殼層放入任一工作 anetd Pod 的 Cilium 代理程式容器。
- 發出 cilium-bugtool，然後等待約 10 秒。這項工具會將記錄檔儲存在
/var/log/network/policy_action.log 目錄中。
- 尋找
deny，查看流量是否遭到拒絕：
grep -r "deny" /var/log/network/ to
請注意遭到拒絕的伺服器，可能是根管理員裸機節點。
|
| 升級 |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
症狀：
|
| 升級 |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
症狀：
- 從 1.9.12 升級至 1.9.13 時，租戶機構的 Bare Metal 節點 OS 升級作業會失敗。畫面上會顯示以下訊息：
Reason: Succeeded
Status: True
Type: NodeMaintainCompleted
Last Transition Time: 2024-05-06T18:25:20Z
Message: the ssh cert rotation job is still in progress
Observed Generation: 1
Reason: ReconcileBackoff
Status: Unknown
Type: Succeeded
Last Transition Time: 2024-05-06T18:27:42Z
-
SSH generation fails. The following message appears:
"tasks": [
{
"hosts": {
"10.248.4.72": {
"action": "gather_facts",
"changed": false,
"msg": "Failed to connect to the host via ssh: Certificate invalid: name is not a listed principal\r\nHost key verification failed
.",
"unreachable": true
}
},
"task": {
"duration": {
"end": "2024-05-06T19:47:11.284055Z",
"start": "2024-05-06T19:47:11.146536Z"
},
"id": "98f2b32d-e15c-fe27-2225-00000000001c",
"name": "Gathering Facts"
}
} ]
解決方法：
- 在根管理員和機構管理員伺服器 CR 中移除
cluster.private.gdc.goog/ssh-trusted-ca-versions 註解。
- 刪除失敗的 Ansible 工作。由於伺服器 CR 中標示
cluster.private.gdc.goog/host-key-rotation-in-progress 註解為 true，因此系統會自動建立新工作。
- 輪替後，
cluster.private.gdc.goog/ssh-trusted-ca-versions 註解會重新新增至伺服器 CR。
|
| 節點、升級 |
1.9.* |
症狀：
升級後，某些裸機節點上的 Pod 會停滯在 CrashLoopBackOff 狀態，且節點上的 iptables -L -v -n | grep CILIUM 會傳回空白結果。
解決方法：
如要解決這個問題，請完成下列步驟：
- 執行下列指令：
crictl pods --name anetd -o json | jq --raw-output '.items[].id' | xargs crictl rmp --force。
- 再次執行
iptables -L -v -n | grep CILIUM，確認有輸出內容。
|
| 記錄 |
1.9.14
1.9.15 |
症狀：
audit-logs-loki-0 Pod 處於 CrashLoopBackOff 狀態。
驗證 Pod 狀態：
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
其中 SYSTEM_KUBECONFIG 是 kubeconfig 檔案的路徑。
Loki 錯誤會顯示在下列輸出內容中，其中 CrashLoopBackOff 是狀態：
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 1/2 CrashLoopBackOff 9 (4m6s ago) 25m
解決方法：
如要解決這個問題，請完成下列步驟：
- 將 kubeconfig 檔案的路徑匯出至名為
SYSTEM_KUBECONFIG 的環境變數。
- 縮減 Logmon 運算子：
kubectl scale deployment -n obs-system logmon-operator --replicas 0
- 縮減 Loki 資源：
kubectl scale loki -n obs-system --replicas 0
kubectl scale statefulset audit-logs-loki -n obs-system --replicas 0
- 刪除
audit-logs-loki-storage-audit-logs-loki-0 和 loki-storage-loki-0 永久磁碟區要求 (PVC)。
- 刪除
obs-system/loki-storage-loki-0 和 obs-system/audit-logs-loki-storage-audit-logs-loki-0 永久磁碟區 (PV)。
- 擴大 Logmon 運算子：
kubectl scale deployment -n obs-system logmon-operator --replicas 1
- 按照步驟從 1.9 版更新記錄設定。
- 確認
audit-logs-loki-0 Pod 正在執行中：
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
輸出內容必須顯示 Running 狀態，如下列範例所示：
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 2/2 Running 0 15h
|
| 基礎架構即程式碼 |
1.9.16 |
症狀：
升級至 1.9.16 時，Gitlab 外掛程式安裝失敗。您可能會看到類似這樣的錯誤訊息：
Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgr │
│ ade error: timed out waiting for the condition: deployments/gitlab-sidekiq-all-in-1-v2: release gitlab failed: client rate limiter Wait returned an error: ra │
│ te: Wait(n=1) would exceed context deadline
postgres Pod (例如 gpc-system/gitlab-postgresql-0) 處於終止狀態。
解決方法：
- 強制刪除處於終止狀態的 postgres Pod：
kubectl delete pod POD_NAME --grace-period=0 --force --namespace NAMESPACE
- 確認 postgres Pod 在刪除後會重新建立。
|
| 身分與存取權管理 |
1.9.19
1.9.20 |
症狀：
從 1.9.18 版升級後，嘗試存取 GDC 控制台時，可能會看到以下訊息：
Authentication failed, please contact your system administrator
解決方法：
- 取得必要 CA：
export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get secret fakeoidcprovider-https -n istio-system -o jsonpath='{.data.ca\.crt}'
- 開啟用戶端設定檔進行編輯：
kubectl edit clientconfig -n kube-public default
- 在用戶端設定中找出
certificateAuthorityData，並使用下列路徑更新必要 CA：spec > authentication > (fake-oidc-provider) > oidc > certificateAuthorityData
|
