备份和恢复
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 网关执行 curl 操作失败。
临时解决方法：
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
症状 ：
如果永久性卷处于 SnapMirror 关系中，则无法将其删除。
临时解决方法：
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 中的一个 bug，该 bug 会导致 Trident 无法正确识别和验证 LUKS 映射的底层设备，从而导致多重附加 bug。
临时解决方法：
检查 PVC 是否具有 deletionTimestamp。如果不存在 deletionTimestamp（Pod 迁移），请按以下步骤操作：
检查 PVC 的 VolumeAttachment，以确定卷当前连接到的位置。
隔离集群中与此值不匹配的 Nodes。
删除失败的 Pod，这应该会导致它迁移回原始的 Node。
检查后，如果存在 deletionTimestamp（卷删除），请按以下步骤操作：
检查 PVC 的 VolumeAttachment，以确定卷当前连接到的位置。
在 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 会将权限覆盖回 root。
重启第二个节点中的 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 地址。
从 NodePool 自定义资源中的 spec.nodes 中移除 IP 地址。
等待节点从 NodePool 中完全移除。
如果节点未被移除，请执行 force-remove：
向 Machine 自定义资源添加 baremetal.cluster.gke.io/force-remove=true 注解：
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 处理流水线中，并且此 SIEM 中没有 Kubernetes API 服务器日志。
网络
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（具体来说是 .status.ipv4AllocationStatus.allocatedCidrBlocks 字段）获取 CIDR。在根管理员集群中运行以下命令：
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）来自 CIDRClaim/org-external-cidr -n org-1（具体来说是 .status.ipv4AllocationStatus.allocatedCidrBlocks 字段）。此命令针对根管理员集群运行，以获取“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。
临时解决方法：
执行以下缓解措施可防止出现此节点状态：
请勿在单个节点上同时调度超过 10 个 PVC。等待它们装载完毕，然后再安排更多。在尝试创建虚拟机时，此问题最为明显。
更新每个节点上的 /etc/lvm/lvm.conf 文件，在 devices{} 块中添加以下代码行：filter = [ "r|/dev/dm.|", "r|/dev/sg.|" ]
如果节点进入某种状态，导致卷连接和装载超时，或者无法删除卷，请检查节点上挂起的 vg 进程数量，以确定节点是否处于这种特别糟糕的状态。修复处于此状态的节点的最可靠方法是重启该节点。
您可能还会遇到另一种故障模式。该故障模式在装载尝试中具有以下签名：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) 空气隔离在分布式云的初始引导期间未能创建必要的交换机 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 状态超过 3 小时。
临时解决方法：
按照 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您在交换机的 bootflash 目录中找不到 nxos.10.3.1.bin，但找到了类似的文件，例如 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 打开操作系统 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. 对于未保持时间同步的服务器，这是一个问题。 配置未正确应用，必须更改为其他命名空间才能正确应用。
临时解决方法：
对所有集群执行以下步骤：
列出现有操作系统政策：
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
等待几分钟，让控制器应用操作系统政策。
建立与 OSPolicy 应用到的其中一个节点的 SSH 连接，然后运行 cat /etc/chrony.conf。输出显示了文件开头的一条消息，表明该文件由 Ansible 管理，并且已从配置中移除 nist.time.gov 或 ntp.pool 服务器。
虚拟机备份和恢复
1.12.0
症状 ：
由于虚拟机管理器中基于角色的访问权限控制 (RBAC) 和架构设置不当，用户无法启动虚拟机备份和恢复流程。
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 临时解决方法：
虚拟机备份方案名称是 VirtualMachineBackupPlanTemplate 名称、资源类型（vm 或 vm-disk）以及相应资源的名称的串联。此串联字符串的长度不得超过 63 个字符。
创建和启动虚拟机实例 和为虚拟机创建备份计划 。
数据库服务
1.12.0
症状 ：
数据库服务工作负载在分布式云系统集群上的单独项目中进行预配和配置。虽然项目用于在 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. 通过 shell 进入数据库 pod
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.yaml 文件管理员用户名必须为 admin。相反，该文件在首次创建后包含 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 创建组织会失败，因为自定义 IP 无法连接到根管理员中的 Harbor。
临时解决方法：
如需解除流量屏蔽，请手动为组织自定义 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 中创建入站 SecurityPolicyRule，以允许 root 访问组织 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
提取 Web（端口 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`，Secret 仍然存在：
$ 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 临时解决方法：
暂停生命周期管理器，使其不再重新创建证书和删除证书：
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
症状 ：
未收集用户集群中的某些指标。此问题会影响用户虚拟机集群，但不会影响系统集群。
您可以从 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 环境变量中。
在用户虚拟机集群中部署桩服务：
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"
节点操作系统
1.11.3
症状 ：
在针对 os-policy pod 采取手动解决方法后，虚拟机重启任务失败。系统会显示以下消息：
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
临时解决方法：
停止并启动虚拟机可解决此问题。按照启动和停止虚拟机 中的说明操作。
上层网络
1.12.0
症状 ：
用户虚拟机集群卡住，描述处于 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 pull 错误：
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 更改网络钩子。如果未恢复，请等待大约 10 分钟，看看系统是否会自动恢复。如果未解决，请上报问题。
如果存在变更网络钩子，请删除有问题的 pod 并验证它是否恢复正常。.spec.containers[].image 不得为 auto，必须看起来像实际图片，类似于以下内容：gcr.io/gke-release/asm/proxyv2:<image version>。
日志记录
1.12.1
症状 ：
从 1.11.1 升级到 1.12.1 时，由日志组件部署的 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. 组织升级卡在 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. 组织升级卡在 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
虚拟机管理器
1.12.1
症状 ：
从 1.11.x 升级到 1.12.x 时，虚拟机可能会因 Pod 过多而无法就绪，从而阻止 Bare Metal 节点耗尽。
临时解决方法：
重启虚拟机。
物理服务器
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 存储桶删除可能会失败，并显示以下错误：
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 界面的访问权限。
在界面中前往 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 的所有请求。不过，清单文件未包含在 build 文件中。
临时解决方法：
按照以下步骤在组织管理员集群中部署 Istio Telemetry 对象：
在组织管理员集群的 mon-system 命名空间中创建一个 YAML 文件，用于定义 Istio Telemetry 自定义资源 (CR)：
# 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 会随之填充。
按照操作手册 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-平面-node-poolORG_ADMIN_NODEPOOL_NAMESPACE：org-1ROOT_ADMIN_NODEPOOL_NAME：root-admin-control-平面ROOT_ADMIN_NODEPOOL_NAMESPACE：根
在根管理员集群和组织管理员集群中创建以下对象，以将节点上的 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 并更新操作系统政策：
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。
通过为集群（根管理员集群和组织管理员集群的根管理员控制器，系统集群和用户集群的组织管理员控制器）重启 oclcm-backend-controller，触发 StorageClasses 的重新创建。
对于版本 1.12.4，请确认已安装的存储类是否已将注解 disk.gdc.goog/luks-encrypted: 设置为 true（非 LUKS 存储类除外）。如果注解未设置为 true，请重复执行第 1 步和第 2 步。
重启集群中的 netapp-trident 部署和 netapp-trident DaemonSet。
验证是否已为您的 PersistentVolumeClaim (PVC) 资源创建 LUKS Secret。每个 PVC 都必须有一个格式为 g-luks-$pvc_name 的 Secret。
验证 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
临时解决方法：
在开始升级之前，手动添加 Finalizer。
集群管理
1.12.1、1.12.2
症状 ：
在 Kubernetes 1.27.x 版上运行的用户集群中的节点池可能无法初始化，导致用户集群无法处理容器工作负载。
临时解决方法：
请勿创建 Kubernetes 版本为 1.27.x 的用户集群。
虚拟机
1.12.0
症状 ：
如果 Ubuntu 源映像在 sources.list 中包含默认 APT 源，则虚拟机映像导入会在映像转换步骤中失败。
临时解决方法：
确保源映像中的 /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 具有 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
症状 ：
虚拟机导入器 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> 所有磁盘导入最终都会在 3 小时内完成。
升级
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
通过向子组件添加以下注释，暂停 file-observability 子组件，直到 mon-admin 子组件启动：
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 无法访问，尤其是在交换机操作系统升级后。
在 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 （新建）。
在名称 字段中，输入 glide.rest.max_content_length。
在类型 字段中，选择 string。
在值 字段中，输入 15。
点击提交 。
再次同步知识库。
工单系统
1.12.2
症状 ：
手动部署 gdchservices 组织时，工单系统没有正常的上游，没有创建虚拟机，并且 support 命名空间中 gdchservices-system 集群中的 midserver pod 处于不健康状态。
临时解决方法：
在 gdchservices-admin 集群中创建具有正确虚拟机映像的新 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 的虚拟机。您可能会在 anetd pod 日志中看到如下所示的错误：
Unable to create endpoint:[ PUT /endpoint/{ id}][ 400 ] putEndpointIdInvalid failed setting up layer2 interface
临时解决方法：
删除虚拟机的 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
新子组件必须具有以下规范，并且 chat网址 必须显示集群已升级到的版本：
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例如，如果错误发生在组织 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
例如，如果错误发生在组织 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 Portfolio
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 Config 代理未运行。
OS Config 代理无法与 OS Config 服务通信。
OS Config 服务存在问题。
临时解决方法：
检查节点的 `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”部分中填充一个集群的节点。
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 工具删除政策：
前往操作系统政策，例如 :ospolicies。
找到并选择 lvm-conf-device-filter-node-update 政策。
按 Ctrl + d 。
确认删除。
如需上报此问题，请使用 SUPP-G0008 运行手册提交支持服务工单。
工单应包含以下信息：
执行的命令及其输出消息
详细信息，例如 InventoryMachineName 和集群
日志消息
操作系统
1.12.0
症状 ：
如果环境之前部署的是 1.11，然后升级到 1.12，就会出现此问题。在 1.12.x 版本中创建新集群或组织时，由于 ReleaseMetadata 和 Userclustermetadata CR 中指定的 Rocky OS 版本，系统会选择 Rocky OS 而不是 Ubuntu OS 来预配裸机和虚拟机节点。
临时解决方法：
在创建新组织之前，请应用以下解决方法：
检查是否存在未处于 Succeeded: true 状态的 OrganizationUpgrade CR：
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，以避免意外的节点操作系统升级：
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确保该变量使用与 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 导入本地虚拟机映像时，导入状态停留在 WaitingForTranslationVM 或 ImportJobNotCreated。这是因为为转换或导入创建的临时磁盘使用与 qcow2 或原始映像完全相同的尺寸，但 LUKS 会增加几 MiB 的开销，从而导致磁盘配置失败。
临时解决方法：
手动创建一个新的 VirtualMachineImageImport，该 VirtualMachineImageImport 具有相同的映像名称，但 spec.minimumDiskSize 更大。例如，如果用于导入映像的命令如下：
gdcloud compute images import $IMPORT_NAME --project $PROJECT --source-file= $LOCAL_FILENAME --os= $OS 如果 CLI 自动创建的原始 VirtualMachineImageImport 具有 minimumDiskSize（以 Gi 为单位）的容量，请创建一个容量为 X+1 Gi 的新 VirtualMachineImageImport。该值取决于要导入的图片的大小。对于 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 以供参考，从而创建新的 VirtualMachineImageImport。
创建具有更大 minimumDiskSize 的新 VirtualMachineImageImport：
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineImageImport
metadata:
name: $IMPORT_NAME_NEW
namespace: $NAMESPACE
spec:
imageMetadata:
minimumDiskSize: $NEW_SIZE
name: $IMAGE_NAME
operatingSystem: $OS
source:
objectStorage:
bucketRef:
name: vm-images-bucket
objectName: $LOCAL_FILENAME
虚拟机
1.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。您可以获取以下操作手册 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 存在，这应该很快就会发生，因为 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 的超时时间设置为 2 秒，以便 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
Operations Suite Infrastructure (OI)
1.12.4
症状 ：
fluent-bit 安装程序位置已更改为 operations_center\bin\fluent-bit-win64.msi。
Copy-ConfigHostFiles.ps1 要求客户端安装程序与 fluent-bit-*-win64.* 模式匹配。
fluent-bit安装程序无法找到安装程序，因为该模式不再匹配。
临时解决方法：
打开 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
Operations Suite Infrastructure (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
Secret
记下组织名称：
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 secret 中提取 StorageGRID 管理界面登录凭据。
使用上一步中的凭据登录 StorageGRID 管理界面。网址处于 ObjectStorageSite 状态：
kubectl --kubeconfig /root/release/root-admin/root-admin-kubeconfig get ObjectStorageSite -n gpc-system mb-obj-site-1 -o jsonpath = '{.status.managementAPIEndpointURL}'
前往配置 标签页，然后点击高可用性群组 。
打开每个 HA 组的详细视图，并记下其虚拟 IP 地址 (VIP)。
创建新的 HA 群组：
群组名称 ：名称格式为 ORGANIZATION_NAME -haorg-2-ha。群组说明 ：使用现有的 HA 群组作为说明模式。接口 ：选择所有 eth2。优先级顺序 ：主接口应具有最高优先级。SubnetCIDR ：此字段由 StorageGRID 自动填充。
验证子网是否与 SubnetClaim external-objectstorage-client-lif-cidr 中的 status.ipv4SubnetStatus.cidrBlock 相匹配。虚拟 IP ：可用 IP 范围中的下一个 IP。该 IP 不能与预留 IP、管理员节点的客户端 IP 和现有 HA 组的 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 以在运行中的容器中获取 shell，例如。
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 字段匹配，则可以放心地忽略“未知”状态。
升级
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 小时才能解决问题。
升级
1.12.4
症状 ：
从 1.12.2 升级到 1.12.4 时，ansibleplaybook 不会作为集群升级的一部分进行升级。ansibleplaybook 中更新的修复程序未应用，并阻止运行旧版 ansibleplaybook 的操作系统政策。
临时解决方法：
删除 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 部署。
此操作会重新触发作业并更新 playbook。
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 Secret。每个 PVC 都必须有一个格式为 g-luks-$pvc_name 的 Secret。
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 命名空间中，则表示存在其他未知问题，不应执行此解决方法。
预期行为是，在 1.12 升级完成后，primary-prometheus-shardX-replicaX 仅存在于 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: ""
针对卡在调和状态的集群运行其中一个节点对象的 describe 命令，并检查节点对象上是否存在 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 请求中的响应 标签页，以显示相应请求的内容。
验证除 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 临时解决方法：
检查每个节点是否都有存储在 Secret 中的相应 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 如果未找到 Secret，则会显示如下所示的错误：
Error from server ( NotFound) : secrets "gpcstgeadm02-gce-gpcstgesite01-ssh-creds" not found
如果该命令未返回任何错误，您可以放心地忽略协调器报告的错误。
Vertex AI
1.11.x
症状 ：
在升级期间，系统会重新创建 Translation DB 集群，这会导致 ODS 系统集群 secret-store Secret 过时并处于不同步状态。因此，翻译前端 pod 和服务无法完成初始化。
临时解决方法：
删除系统集群中的 Secret：
kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n ai-translation-system 将 SYSTEM_CLUSTER_KUBECONFIG
控制器会自动重新创建 Secret，并将其与数据库集群重新同步。
物理服务器
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 中但尚未转移到存储桶的所有日志都会永久丢失。
请按照以下步骤恢复 Loki pod：
确保工作站上已安装 IO 工具容器。如需了解详情，请参阅 OOPS-P0065 操作手册。
如需获得修改资源所需的权限，请让 Security Admin 为您授予以下角色：
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 }
使用受影响的 Loki pod 运行所在的集群中 kubeconfig 文件的路径设置 KUBECONFIG 环境变量。如需了解详情，请参阅 IAM-R0004 运行手册。
将 LOKI_POD_NAME 环境变量设置为受影响的 Loki pod 的名称。
获取 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 个 (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 Secret 发生更改时，取消暂停子组件。当实例的管理交换机发生更改（例如 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。
未为 LUKS 启用 system-performance-rwo 存储类别。卷附件表明 PVC 已启用 LUKS。
协调器会搜索包含 LUKS 口令的 Secret。由于卷附件表明已启用 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 和存储桶 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
