| 安装 |
1.9.0
1.9.1
1.9.2 |
iLO 有时无法从 HSM 中检索密钥
症状：
`server.status.conditions` 包含一个类型为 `KeyManagerConfigured` 且状态为 `True` 的条目，但不包含类型为 `DiskEncryptionEnabled` 的条目。 存在名为“server-encrypt-and-create-logical-drive-$SERVER-xxxxx”的失败 pod，并显示错误“ERROR: (3065) Error changing the Controller Encryption Mode UNABLE TO RETRIEVE KEY\tController: HPE Smart Array P408i-a SR Gen10, SLOT 0”。 由于密钥无效，无法通过 SSH 登录 pod。
临时解决方法：
如需解决此问题，请按以下步骤操作：
前往 iLO 界面 > 信息 > 诊断 > 重置，以重置 iLO。 如果在重置期间，iLO 显示服务器处于开机自检 (POST) 状态，请重新启动配置流程：
如果管理员集群安装已通过：
export KUBECONFIG=<root-admin-kubeconfig path>
更新 SSH 密钥：
获取当前的 SSH 公钥（请注意，该公钥可能已轮换，因此与 /root/.ssh/id_rsa.pub 不同）
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -d
将公钥放入 ironic-vars configmap 中：
kubectl -n gpc-system edit cm/ironic-vars
添加 IRONIC_RAMDISK_SSH_KEY：\ 重启 ironic：
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic
重新配置机器以重新安装 IPA：
备份 bmc-credential-$SERVER，因为删除 bmh 也会删除相应密钥
kubectl -n gpc-system get secret bmc-credentials-$SERVER -oyaml > $SERVER
从文件中移除不适用的属性，例如：last-applied、creationtimestamp、finalizer、ownerreference、resourceversion、uid。
删除 BareMetalHost：
kubectl -n gpc-system delete bmh/$SERVER
从 cellcfg 中获取 Secret bmc-credentials-$SERVER 或之前的备份，然后应用它。
告知服务器执行其他操作。
如需移除缓存的 BMH 状态，请执行以下操作：
kubectl -n gpc-system annotate server/$SERVER baremetalhost.metal3.io/status-
等待服务器完成配置。 观看 BMH 对象的创建过程。 您可能需要删除加密作业才能重新触发。
|
| 运维 |
1.9.0
1.9.1
1.9.2 |
症状：
当 storageClassName 为 standard-block 时，虚拟机的状态会保留为 Provisioning 或 Starting 的 STATUS。
临时解决方法：
如需解决此问题，请按以下步骤操作：
验证虚拟机 STATUS 是否显示 Provisioning 或 Starting：
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm -n PROJECT
SYSTEM_KUBECONFIG 是系统集群 kubeconfig 文件路径。
PROJECT 是虚拟机所在的 GDC 项目。
可选：获取其他状态详细信息：
kubectl get gvm VM_NAME -n PROJECT -o \
jsonpath='{"State:"}{.status.state}{"\n"}{"Reason:"}{.status.reason}{"\n"}{"Message:"}{.status.message}{"\n"}'
VM_NAME 是无响应虚拟机的名称。
删除虚拟机：
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gvm VM_NAME -n NAMESPACE_NAME
NAMESPACE_NAME 是您的命名空间的名称。
验证删除操作是否成功：
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm VM_NAME -n PROJECT
如果结果类似于以下内容，则表示成功：
Error from server (NotFound): virtualmachines.vm.cluster.gke.io "VM_NAME" not found
删除相应虚拟机的全部磁盘：
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n NAMESPACE_NAME 将 DISK_NAME_1 和 DISK_NAME_2 至 DISK_NAME_N 替换为每个磁盘的名称，并确保列出了所有磁盘。 验证删除操作是否成功：
kubectl --kubeconfig SYSTEM_KUBECONFIG get gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n $PROJECT
如果结果类似于以下内容，则表示成功：
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_1" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_2" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_N" not found
重新创建虚拟机和磁盘。
重启虚拟机。
|
| 运维 |
1.9.2 |
症状：
gdcloud system container-registry load-oci 失败并显示错误。如果您重新运行该命令，它会运行不同的时间段，并在流程中的不同点（例如推送或重新标记）失败，但会显示类似的错误。
临时解决方法：
如需解决此问题，请按以下步骤操作：
将 KUBECONFIG 导出到根管理员 kubeconfig：
export KUBECONFIG=~/release/root-admin/root-admin-kubeconfig
- 运行以下命令，将
deployment/root-admin-tftp-manager-controller 缩减回 0 个副本：
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
- 执行失败的操作。
- 将
deployment/root-admin-tftp-manager-controller 扩容到 1 个副本：
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
|
| 运维 |
1.9.1
1.9.2
1.9.3 |
症状：
gdcloud system container-registry load-oci 失败并显示错误。如果您重新运行该命令，它会运行不同的时间段，并在流程中的不同点（例如推送或重新标记）失败，但会显示类似的错误。
临时解决方法：
您可以放心地忽略此消息。该面板稍后会消失。
|
| 运维 |
1.9.2 |
临时解决方法：
如需解决此问题，请重启出现问题的 pod。
|
| 运维 |
1.9.0
1.9.1
1.9.2 |
症状：
服务器的“就绪”状态为“False”，消息包含“job server-encrypt-and-create-logical-drive-... failed with reason ... and message ...”。失败作业的日志包含“Failed to connect to the host via ssh ... Permission denied (publickey).”。
临时解决方法：
如需解决此问题，请按以下步骤操作：
从根管理员集群中获取当前的 SSH 公钥：
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -d将密钥放入 ironic-vars configmap 中：
kubectl -n gpc-system edit cm/ironic-vars 并添加或替换现有的 IRONIC_RAMDISK_SSH_KEY：
<SSH public key>
重启 ironic 部署：
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic 对于每个受影响的服务器：
kubectl -n gpc-system annotate bmh/$SERVER inspect.metal3.io=""
|
| 运维 |
1.9.2 |
临时解决方法：
为避免遇到 IP 地址短缺问题，请在创建高可用性用户集群时将 Pod CIDR 大小设置为 /21 或更高。
|
| 安装 |
1.9.2 |
临时解决方法：
如需解决此问题，请重启 pod。
如需了解详情，请参阅 MON-R0001 运行手册。
|
| 平台身份验证 |
1.9.13 |
症状：
所有 cplb-init 和 storage-ipsec-config-bm-XXXXX 作业都会显示以下消息：Failed to connect to the host via ssh: ssh: connect to host 10.1.18.X port 22: Connection timed out。
临时解决方法：
1. 检查 aggswitch 上的 BGP VRF 是否处于关闭状态。
2. 检查防火墙上是否有任何未提交的新暂存配置更改。
3. 清理名称中包含已删除组织的全部 securitypolicyrules，然后重启 root-admin-controller。
|
| 升级 |
1.9.1
1.9.2
1.9.11 |
症状：
Server 已卡在 deprovisioning 超过 20 分钟。.status.bareMetalHostStatus.provisionState
待升级服务器的管理 IP 地址包含在以下任一命令的输出中：
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,option:tftp-server
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,tag:ipxe,option:bootfile-name
临时解决方法：
如需解决该问题，请运行以下命令：
kubectl -n gpc-system rollout restart deploy/root-admin-controller
|
| 升级 |
1.9.1
1.9.2
1.9.10
1.9.11
1.9.12
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18 |
症状：
NodeUpgrade 中的一项升级任务已超过 2 小时仍未完成。
相应的 NodeUpgradeTask 在条件 NodeResumeCompleted 处挂起，超过 1 小时仍未完成。
bm-system-x.x.x.x-machine-init 个作业长时间未完成。x.x.x.x 是节点的地址。
临时解决方法：
如需查找运行状况不佳的节点地址，请查看挂起的 bm-system-x.x.x.x-machine-init 作业的 x.x.x.x。
如需为运行状况不佳的节点查找运行状况良好的控制平面节点，请按以下步骤操作：
- 找到运行状况不佳的节点的节点池。
检查该健康状况不佳的节点所在的同一集群中的控制平面节点池，然后从该控制平面节点池的 .spec.address 中选择一个地址。
在引导加载程序或 OC IT 上，运行：
HEALTHY_CP_NODE_IP=Y.Y.Y.Y # Needs to be entered.
alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"
HARBOR=$(ka get harborcluster harbor -n harbor-system -o=jsonpath="{.spec.externalURL}")
REGISTRY=${HARBOR#https://}
# Download `etcdctl`.
docker run --rm -v $(pwd):/workspace --workdir /workspace ${REGISTRY}/library/anthos-baremetal-release/etcd:v3.4.21-0-gke.1 /bin/sh -c "cp /usr/local/bin/etcdctl /workspace/etcdctl"
scp etcdctl "root@$HEALTHY_CP_NODE_IP:/root/etcdctl"
# SSH into the healthy control plane node.
ssh $HEALTHY_CP_NODE_IP
在健康状况良好的控制平面节点中，运行以下命令：
UNHEALTHY_NODE_IP=X.X.X.X # Needs to be entered.
UNHEALTHY_MEMBER=$(ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member list | grep $UNHEALTHY_NODE_IP | cut -d',' -f1)
ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member remove $UNHEALTHY_MEMBER
|
| 升级 |
1.9.1
1.9.2 |
症状：
ODS Fleet Operator pod 处于崩溃循环状态。
如需检查 pod 的状态，请运行以下命令：
ko get pods -n ods-fleet-operator
ODS Fleet Operator 日志中会显示类似于以下内容的领导者选举错误：
E0413 18:06:48.614127 1 leaderelection.go:330] error retrieving resource lock ods-fleet-system/af0cf209.dbadmin.gdc.goog: Get "https://172.20.0.1:443/apis/coordination.k8s.io/v1/namespaces/ods-fleet-system/leases/af0cf209.dbadmin.gdc.goog": context deadline exceeded
I0413 18:06:48.614214 1 leaderelection.go:283] failed to renew lease ods-fleet-system/af0cf209.dbadmin.gdc.goog: timed out waiting for the condition
E0413 18:06:48.614460 1 main.go:473] "setup: problem running manager" err="leader election lost" log_name="l1_controller"
如需检查 ODS Fleet Operator 日志，请运行以下命令：
ko logs deployment/fleet-controller-manager -n ods-fleet-system
系统会显示以下消息：
Message: Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgrade error: post-upgrade hooks failed: timed out waiting for the condition: timed out waiting for the condition。
临时解决方法：
如需修改部署，请运行以下命令：
ko edit deployment -n ods-fleet-system fleet-controller-manager
ku edit deployment oracle-controller-manager -n ods-oracle-system
ku edit deployment pg-controller-manager -n ods-postgres-system
请务必按如下方式修改 manager 容器的 resources 字段：
之前：
resources:
limits:
cpu: 100m
memory: 512Mi
requests:
cpu: 100m
memory: 512Mi
之后：
resources:
limits:
cpu: 1000m
memory: 1024Mi
requests:
cpu: 1000m
memory: 1024Mi
|
| 升级 |
1.9.2
1.9.3 |
症状：
系统会显示以下错误消息：
nvidia-driver-init run the action: init, with options: skip_driver
nvidia-driver-init Find the nvidia card, label this node
nvidia-driver-init node/MACHINE_NAME not labeled
nvidia-driver-init enable nvidia container runtime for ubuntu/debian system
nvidia-driver-init install nvidia container runtime package
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container1_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container1:amd64 (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container1:amd64 (1.12.0-1) ...
nvidia-driver-init Processing triggers for libc-bin (2.31-0ubuntu9.9) ...
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container-tools_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container-tools (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container-tools (1.12.0-1) ...
nvidia-driver-init dpkg: regarding .../nvidia-container-toolkit-base_1.12.0-1_amd64.deb containing nvidia-container-toolkit-base:
nvidia-driver-init nvidia-container-toolkit-base breaks nvidia-container-toolkit (<= 1.10.0-1)
nvidia-driver-init nvidia-container-toolkit (version 1.8.1-1) is present and installed.
nvidia-driver-init dpkg: error processing archive var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb (--install):
nvidia-driver-init installing nvidia-container-toolkit-base would break nvidia-container-toolkit, and
nvidia-driver-init deconfiguration is not permitted (--auto-deconfigure might help)
nvidia-driver-init Errors were encountered while processing:
nvidia-driver-init var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb
临时解决方法：
如需解决此问题，请按以下步骤操作：
登录到所有已预配的 GPU 节点：
# ka get servers -A | grep o1-highgpu1-48-gdc-metal
移除旧软件包：
root@MACHINE_NAME:~# dpkg -r nvidia-container-runtime nvidia-container-toolkit
(Reading database ... 92154 files and directories currently installed.)
Removing nvidia-container-runtime (3.8.1-1) ...
Removing nvidia-container-toolkit (1.8.1-1) ...
删除卡住的 kubevm-gpu-driver-daemonset pod。此操作会重新开始安装：
# kug get pods -A | grep gpu | grep Init
（可选）如果插件安装超时，请重新开始安装插件：
ku delete job vm-runtime-readiness -n gpu-org-system-cluster
|
| 升级 |
1.9.10
1.9.11 |
症状：
gpcbackup-agent-0 显示 failed to stage volume: iSCSI login failed，但无法暂存音量。
检查 pod 是否无法挂接卷。以下示例使用系统集群 kubeconfig：
临时解决方法：
如需解决此问题，请执行以下步骤：
-
获取 InventoryMachine 名称：
export ROOT_ADMIN_KUBECONFIG=[path to the root admin kubeconfig]
export INV_MACH=vm-e2b9792a
-
确认之前的作业是否存在：
export ORG_ADMIN_KUBECONFIG=[path to the org admin kubeconfig]
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-"${INV_MACH}"
您将获得类似于以下内容的输出：
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 17s 19d
-
删除作业：
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
您将获得类似于以下内容的输出：
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
确认 StorageEncryptionConnection 是否存在：
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
您将获得类似于以下内容的输出：
NAME INVENTORYMACHINE STORAGEVIRTUALMACHINE STORAGECIDR PRESHAREDKEY READY AGE
vm-e2b9792a vm-e2b9792a org-1-user 172.20.131.32/27 vm-e2b9792a-pre-shared-key True 19d
-
删除 StorageEncryptionConnection：
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
您将获得类似于以下内容的输出：
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
重启 root-admin-controller pod：
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout restart deploy -n gpc-system root-admin-controller && kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout status deploy -n gpc-system root-admin-controller
-
确认新作业已重新创建并成功运行：
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-${INV_MACH}
您将获得类似于以下内容的输出：
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 19s 95s
|
| 升级 |
1.9.10
1.9.11 |
症状：
Harbor 注册表 pod 显示类似于以下内容的错误消息：
Warning FailedMount 6m52s (x718 over 2d14h) kubelet Unable to attach or mount volumes: unmounted volumes=[storage], unattached volumes=[registry-config authentication-htpasswd internal-certificates sto │
│ age[]: timed out waiting for the condition
临时解决方法：
如需解决此问题，请按以下步骤操作：
-
检查 Harbor 注册表的永久性卷声明 (PVC)，并记下 PVC 卷名称：
kubectl get pvc harbor-registry -n harbor-system
-
如需检查卷附件是否与 Harbor 注册表 pod 位于同一节点中，请列出 volumeattachment 并找到与卷名称关联的那个：
kubectl get volumeattachment | grep [volume-name]
-
如果卷连接位于与 Harbor 注册表 pod 不同的节点中，请移除 volumeattachment：
kubectl delete volumeattachment [volumeattachment-name]
-
重启 Harbor 注册表 pod。
现在，根管理员集群中的 Harbor 注册表必须处于正常运行状态，并且节点升级已成功完成。
|
| 安装 |
1.9.2
1.9.3
1.9.4
1.9.5
|
症状：
系统会显示以下错误消息：
pod "coredns-75bd7c95f7-fd4cr" in namespace "kube-system" is not ready yet.
Pod 日志包含以下内容：
[INFO] plugin/ready: Still waiting on: "kubernetes,kubernetes"
CoreDNS 版本为 1.8.6。
临时解决方法：
如需解决此问题，请重启 coredns 部署。
为正确的集群设置 KUBECONFIG 后，运行以下命令：
kubectl rollout restart deployment coredns -n kube-system
用户集群名称包含在错误消息中。
如需在 /root/release/user/ 中查找 kubeconfig 文件，请找到 kubeconfig：org-1-system-user-kubeconfig user-vm-1-user-kubeconfig user-vm-2-user-kubeconfig
如果 kubeconfig 文件缺失，请按以下方式生成：
export KUBECONFIG=/root/release/org-admin/org-1-admin-kubeconfig
kubectl get secrets -n user-vm-1-cluster user-vm-1-kubeconfig -o jsonpath='{.data.value}' | base64 -d > /tmp/user-vm-1-user-kubeconfig
|
| 升级 |
1.9.2
1.9.3 |
症状：
系统会显示以下错误消息：
Warning ReconcileBackoff 43m (x9 over 61m) OrganizationUpgrade [UPG1402: unable to set AddOn selector labels for root-admin cluster: Operation cannot be fulfilled on clusters.baremetal.cluster.gke.io "root-admin": the object has been modified; please apply your changes to the latest version and try again, UPG9900: unable to update status: OrganizationUpgrade.upgrade.private.gdc.goog "root" is invalid: [status.errorStatus.errors[0]. errorResource.name: Required value, status.errorStatus.errors[0].errorResource.namespace: Required value]]
此问题通常是暂时性的，应该会自行消失。
|
| 安装 |
1.9.3 |
插件安装失败，并显示以下错误：
Error occurred during addon installation: failed to install chart: release netapp-trident failed, and has been uninstalled due to atomic being set: failed post-install: timed out waiting for the condition。
临时解决方法：
由于节点处于 NotReady 状态，插件安装可能会失败。使用以下命令检查节点是否处于 NotReady 状态：
kubectl get nodes
获取处于 NotReady 状态的节点的详细信息：
$ kubectl describe node | grep PodCIDRs
对于存在此问题的集群，没有为节点分配 PodCIDR，例如：
PodCIDRs:
For a healthy cluster, all the nodes should have PodCIDRs assigned to it(CIDR shown here is for example purposes only and might vary on the actual cluster based in the Configured ClusterCIDR): eg.
PodCIDRs: 192.168.6.0/24
如需解决此问题，请重启受影响集群中的 ipam-controller 部署：
kubectl --kubeconfig KUBECONFIG_PATH -n kube-system rollout restart ds/ipam-controller-manager
|
| 升级 |
1.9.3 |
升级失败，并显示以下错误：
Rollback "netapp-trident" failed: cannot patch "netapp-trident-csi-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": dial tcp 172.20.5.144:443: i/o timeout && cannot patch "netapp-trident-server-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-client-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-selfsigned-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded。
临时解决方法：
手动将 AddOnSet abm-overrides 的 <code.spec.addonsettemplateref< code="" dir="ltr" translate="no"> 字段更新为要升级的集群所在命名空间中所需版本的 AddOnSetTemplate 的名称。</code.spec.addonsettemplateref<>
|
| 安装 |
1.9.3 |
症状：
舰队管理员控制器无法就绪，导致 TestCreateFleetAdminCluster 或 TestSimOverlayCreateFleetAdminCluster 测试失败。 Fleet 管理员控制器卡在崩溃循环中。 舰队管理员控制器的日志中出现以下错误：Fleet admin controller manager stopped: failed to wait for auditloggingtarget caches to sync: timed out waiting for cache to be synced。
临时解决方法：
将 Logmon CRD 部署到组织管理员集群中。 重启舰队管理员控制器。
|
| 安装 |
1.9.3 |
症状：
系统会显示以下错误消息：
k8s_mt_system_cluster_healthcheck_test.go:147: system cluster did not become ready in time: cluster "org-1-system-cluster/org-1-system" did not become healthy in time: [waitingForClusterHealth] WaitForSuccess gave up [...] unable to retrieve logs for pod "anthos-prometheus-k8s-0" [...] pod "anthos-prometheus-k8s-0" in namespace "obs-system" is not ready yet. [...] Message:containers with unready status: [config-reload prometheus-server] [...]
临时解决方法：
如需解决此问题，请重启集群中的部署和 DaemonSet：
kubectl rollout restart deploy/netapp-trident-csi -n netapp-trident
kubectl rollout restart daemonset/netapp-trident-csi -n netapp-trident
注意：在重启 Deployment 和 DaemonSet 之前，请先运行以下命令，以指向正确的集群：
export KUBECONFIG=/root/release/system/org-1-system-kubeconfig
|
| 升级 |
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8 |
症状：
由于 CPU 不足，无法调度 pod。
临时解决方法：
对于使用 n2-standard-4 工作器节点创建的现有用户集群，请先向该集群添加一个包含三个节点的新 n2-standard-8 NodePool，然后再升级。 对于新的用户集群，请创建一个包含至少三个节点的 n2-standard-8 NodePool。如需了解详情，请参阅为容器工作负载创建用户集群。
|
| 运维 |
1.9.0
1.9.2
1.9.3
1.9.4 |
症状：
虚拟机实例 PHASE 显示 Scheduling 和 READY，但始终处于 False 状态，永远无法达到 True 状态。这会影响两种机器类型，如问题解决方法中所列。其他机器类型不受影响，无需应用解决方法。
临时解决方法：
- 创建使用 A100 40G GPU 的用户集群时，请务必从界面中选择 a2-highgpu-1g-gdc 机器类型。
- 创建使用 A100 80G GPU 的用户集群时，请务必从界面中选择 a2-ultragpu-1g-gdc 机器类型。
|
| 运维 |
1.9.0
1.9.2
1.9.3
1.9.4 |
症状：
对于内存大小超过 32 GB 的虚拟机实例所在的节点池，虚拟机实例可能会先运行，然后停止，再运行；此序列可能会重复。最终，系统会抛出内存不足 OOMKilled 错误，实例也会失败。
以下是受影响的三种虚拟机类型：
- n2-highmem-8-gdc：64 GB 内存
- a2-highgpu-1g-gdc：85 GB 内存
- a2-ultragpu-1g-gdc：170 GB 内存
临时解决方法：
- 验证机器类型：
kubectl --kubeconfig= get gvm vm-8c440bc4 -n gdch-vm-infra
- 在以下位置查找虚拟机类型
spec.compute.virtualMachineTypeName 。
- 如果虚拟机类型是列出的三种类型中的任何一种，请修改
configmap 以包含内存替换项：
kubectl --kubeconfig=SYSTEM_CLUSTER_KUBECONFIG \
edit configmap NAME -n NAMESPACE
- 添加
memory.guest 和 resources.overcommitGuestOverhead 部分，如下例所示：
apiVersion: v1
kind: ConfigMap
metadata:
name: vm-8c440bc4
namespace: gdch-vm-infra
data:
virtSpec: |
template:
spec:
domain:
...
...
memory:
guest: "MEMORY_SIZE"
resources:
overcommitGuestOverhead: true
...
...
- 在
memory 中，将 guest 更改为以下值：
- 对于 n2-highmem-8-gdc，请将 MEMORY_SIZE 设置为
63.6G。
- 对于 a2-highgpu-1g-gdc，请将 MEMORY_SIZE 设置为
84G。
- 对于 a2-ultragpu-1g-gdc，请将 MEMORY_SIZE 设置为
168G。
- 对所有受影响的虚拟机重复此操作。
|
| 升级 |
1.9.4 |
症状：
bm-system-* 作业在 Gathering Facts 步骤挂起。尝试手动通过 SSH 连接到服务器时，系统会显示 PTY allocation request failed on channel 0。
临时解决方法：
使用以下任一方法重新启动服务器：
curl -X POST -H "content-type: application/json" -k -u $ILO_USER:$ILO_PWD https://$ILO_IP/redfish/v1/Systems/1/Actions/ComputerSystem.Reset
iLO 界面 kubectl --kubeconfig=$ROOT_ADMIN_KUBECONFIG annotate -n gpc-system bmh/$SERVER "reboot.metal3.io"=""
|
| 升级 |
1.9.4
1.9.10 |
症状：
升级因 backup-ipsec-* 作业失败而失败。
临时解决方法：
请按以下步骤操作：
在组织管理员集群的 gpc-system 命名空间中查找预共享密钥。这些键的名称为 <node-name>-pre-shared-key。
如需从工作节点的预共享密钥 YAML 中获取密钥哈希，请使用 kubectl get --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig -n gpc-system secret <not-failed-node-name>-pre-shared-key -o=jsonpath='{.data.pre-shared-key}' | awk '{ print $1 }'。
请注意，您必须从 IPsec 升级失败的节点以外的节点获取密钥哈希。 将此预共享密钥的哈希应用于组织管理员集群中 gpc-system 内的失败节点的预共享密钥 Secret。 删除根管理员集群中与故障节点同名的 storageencryptionconnection 对象。 删除组织管理员集群中的关联 storage-ipsec-config-<node-name> 作业。 删除关联的 backup-ipsec-for-upgrade-<node-name> 升级作业。
|
| 升级 |
1.9.4 |
症状：
升级组织集群需要很长时间。
临时解决方法：
等待 clamav 自然关闭。
|
| 升级 |
1.9.5 |
症状：
系统会显示不同的证书：
echo $(kubectl get secret harbor-cert-secret -n istio-system -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBqjCCAS+gAwIBAgIQSve6hYhac9nZr/u/l/hPzjAKBggqhkjOPQQDAzAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTcwMzQ3MjhaFw0yODA3MTUwMzQ3
MjhaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MHYwEAYHKoZIzj0CAQYFK4EEACID
YgAEsGCynvjnSNNIdz3PxpEqvogHAITWyB3jJbA6jxQhics5MYuq2biaqLg38Ly1
3mF6CRh9Tzroxg2Wtu339McKTAC/7v61ZsbGXbj3eQiTECJut/a55BekG7FcwVG/
btbAo0IwQDAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E
FgQUUh1ZUS9CUIHgQmJZTj8m3MIINS8wCgYIKoZIzj0EAwMDaQAwZgIxALDea5fh
IeafRNzR3pjYRgW++TCYZU3XVSJ04K8eIBy1wz1XRDR5SWFgJ/ejWZGUagIxAIQP
9A42lzd7gyqaAAlRB+TQ0sMJMOOyNl0gFg5ZVyhGdJfsZpv1XrcLcqX3tejydw==
-----END CERTIFICATE-----
echo $(kubectl get secret ca-cert-10.2.2.101.10443 -n anthos-creds -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBazCCARKgAwIBAgIQKkDVSpMZf9CQEHxx7UFPmDAKBggqhkjOPQQDAjAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTYwOTQzMTlaFw0yNDA3MTUwOTQz
MTlaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MFkwEwYHKoZIzj0CAQYIKoZIzj0D
AQcDQgAEI4hXIh65Zc8sWaPQL9gqz3lrq22A1XJsRrMwl/pk3vZiNLGS3+Tt9tXc
WDP74IbinOxZ1Auw08e3s4sxCahfyqNCMEAwDgYDVR0PAQH/BAQDAgKkMA8GA1Ud
EwEB/wQFMAMBAf8wHQYDVR0OBBYEFN8ob6e8WeFELnVKPSdtMfyvRP95MAoGCCqG
SM49BAMCA0cAMEQCIF8P5THYBHcOdcn1u7zi+Y4jwDTdLAeaDZbVxUDEK2EaAiBW
zilvR3YvW7h5OdSUsgFkSQ42FcSIoNHWYNSZx16CeQ==
-----END CERTIFICATE-----
临时解决方法：
注意：请在执行以下步骤之前轮替 harbor-harbor-https 证书。
请按以下步骤操作：
集群中的 Secret 中存储了证书数据的副本。轮替 harbor-harbor-https 证书后，您还必须更新密钥副本。
- 检索 Artifact Registry 网址。
export registry_url=$(kubectl get harborcluster/harbor -n harbor-system -o json | jq -r '.spec.externalURL')
- 更新每个命名空间中的 Artifact Registry 证书 Secret 副本。
获取存储 Artifact Registry 证书 Secret 副本的所有命名空间。
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
更新每个命名空间中的 Artifact Registry 证书 Secret 副本。
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done
- 对于根管理员集群，您还需要更新
anthos-creds 命名空间中名为 ca-cert-in-cluster-registry 的证书 Secret 副本。
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n anthos-creds patch secret/ca-cert-in-cluster-registry -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"
- 更新存储在
kube-system 命名空间中的 registry-cert。
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n kube-system patch secret/registry-cert -p "{\"data\":{\"registry-cert\":\"${cert_data}\"}}"
- 如果您要轮替组织管理员集群的证书，还需要更新根管理员集群中存在的证书 Secret 副本。
获取存储 Artifact Registry 证书 Secret 副本的所有命名空间。
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
更新每个命名空间中的 Artifact Registry 证书 Secret 副本。
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done 。
|
| 升级 |
1.10.0
1.10.1 |
症状：
启动 OrganizationUpgrade 后，kube-apiserver pod 未在一个或多个节点上运行。
- 确定升级受阻的节点：
kubectl get po -n kube-system -l component=kube-apiserver
输出类似于以下内容：
NAME READY STATUS RESTARTS AGE
kube-apiserver-ah-aa-bm01 1/1 Running 0 12h
kube-apiserver-ah-ab-bm01 1/1 Running 0 11h
kube-apiserver-ah-ac-bm01 1/1 Error 0 12h
- 建立与刚刚更新的节点的 SSH 连接：
root@ah-ac-bm01:~# crictl ps -a | grep kube-api
您会看到容器状态为 Exited：
f1771b8aad929 bd6ed897ecfe2 17 seconds ago Exited kube-apiserver 2 8ceebaf342eb8 kube-apiserver-ah-ac-bm01
bd14d51b01c09 d0bac8239ee3a 5 minutes ago Exited
- 查看
Exited Pod 的日志：
crictl logs f1771b8aad929
输出类似于以下内容：
Error: invalid argument "JobTrackingWithFinalizers=false" for "--feature-gates" flag: cannot set feature gate JobTrackingWithFinalizers to false, feature is locked to true
该标志在 /etc/kubernetes/manifests/kube-apiserver.yaml 文件中配置：
root@ah-ac-bm01:~# grep JobTrackingWithFinalizers /etc/kubernetes/manifests/kube-apiserver.yaml
- --feature-gates=JobTrackingWithFinalizers=false
临时解决方法：
从 /etc/kubernetes/manifests/kube-apiserver.yaml 文件中移除了相应标志。
- 备份文件：
root@ah-ac-bm01:~# cp /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
- 移除以下行：
root@ah-ac-bm01:~# sed -i '/--feature-gates=JobTrackingWithFinalizers=false/d' /etc/kubernetes/manifests/kube-apiserver.yaml
- 确认相应行已移除：
root@ah-ac-bm01:~# diff /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
35a36
> - --feature-gates=JobTrackingWithFinalizers=false
- 列出
kube-apiserver 容器：
root@ah-ac-bm01:~# crictl ps --name kube-apiserver
kubelet 会自动检测到更改并启动 kube-apiserver pod：
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
e1344008dfed9 bd6ed897ecfe2 12 hours ago Running
- 针对所有受影响的节点重复这些步骤。
|
| 升级 |
1.9.2
1.9.3
1.9.3
1.9.4
1.9.5
1.9.6 |
症状：
组织中的 kube-state-metrics 部署在证书轮替后进入崩溃循环。此问题可能会导致监控数据丢失。
|
| 升级 |
1.9.6 |
症状：
升级后，工作器节点处于不平衡状态。
临时解决方法：
手动平衡工作器节点：
- 对于 pod 工作负载，请删除部署中的 pod。
- 对于虚拟机工作负载，请删除 virt-launcher，而无需修改控制平面 GVM 对象。
|
| 升级 |
1.9.6 |
从 1.9.5 升级到 1.9.6 时，GPU 设备插件可能无法启动。
症状：
您可能会看到以下错误，该错误会阻止虚拟机运行时就绪状态和升级过程：
Failed to initialize NVML: could not load NVML library
临时解决方法：
- 检查节点上是否已正确配置
nvidia-container-runtime：
- 建立与您怀疑存在问题的节点的 SSH 连接。
- 获取 Pod 列表：
crictl pods
- 检查 pod：
crictl inspectp $pod_hash | grep runtimeOption -A1
如果输出类似于上述内容，则表示节点已正确配置。如果输出不如下所示，则表示节点上未配置 nvidia-container-runtime：
binary_name": "/usr/bin/nvidia-container-runtime"
- 如果
nvidia-container-runtime 未正确配置，请重启 containerd 以解决问题：
systemctl restart containerd
|
| 升级 |
1.9.7 |
升级到 1.9.7 时，根管理员集群节点池固件仍处于 in process 状态。
症状：
- 对于
NodeUpgrade 方面，请参阅制品服务器超时问题解决方法：
NodeUpgrade 卡在 in process 状态，且 Nodeupgradetask 状态下 NodeROMFirmwareUpgradeCompleted 的条件始终未完成。- 当
NodeUpgrade 对象中的 spec.firmware.firmwarePackages.url 内的网址连接到以下网址时，可能会挂起：
curl -k https://10.248.2.71:30938/artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU= -o /tmp/file.cow2
- 对于
Harbor 方面，请参阅制品服务器未经授权的解决方法：
- 在制品服务器日志中，可能会显示与未经授权访问仓库相关的错误：
gdch-hpe-firmware/ilo，例如：
root@bootstrapper:~# kubectl --kubeconfig ${KUBECONFIG} logs -n gpc-system -l name=artifact-registry-services-artifact-server -f
artifact-server I1108 05:20:28.084320 1 artifact_server.go:171] Pulling artifact at path /artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU=
artifact-server E1108 05:20:28.159685 1 artifact_server.go:194] Error fetching image 10.249.23.11:10443/gdch-hpe-firmware/ilo:ilo5: GET https://10.249.23.11:10443/v2/gdch-hpe-firmware/ilo/manifests/ilo5: UNAUTHORIZED: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull
- 在 Harbor 项目中，
gdch-hpe-firmware 必须具有 Spec.harborProjectConfig.accessLevel 作为 private：
kubectl get --kubeconfig ${KUBECONFIG} HarborProject -n gpc-system gdch-hpe-firmware -o yaml
临时解决方法：
|
| 较低的网络 |
1.9.0 - 1.9.6 |
症状：
组织内部网络中的 BGP 会话已关闭。仅将组织的一个内部 BGP 对等互连端点添加到 TORSwitchInternal 对象。
临时解决方法：
明确更改 {organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim 中使用的子网，使其不与任何其他组织的类似 AddressPoolClaim 资源重叠。
- 调查症状：
- 对于每个组织系统集群，运行：
kubectl get bgpsessions -A --kubeconfig ORG_SYSTEM_KUBECONFIG
- 检查每个
BGPSession 对象的 State 字段是否包含 NotEstablished 的 State。记下每个关联 NotEstablished BGPSession 的 LocalIP 以供稍后使用。
- 确定
"System cluster BGP Sessions cannot be established due to overlapping ClusterIPs" 是否为根本原因：
- 对于每个有效组织，运行以下命令：
kubectl get clusterbgppeers -A --kubeconfig ORG_ADMIN_KUBECONFIG_FILE -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CLUSTERIP:.spec.clusterIP | grep flat-ip
- 在输出的
ClusterIP 字段（第 3 列）中搜索在步骤 1.b 中记下的 LocalIPs。记下与输出中第 3 列的条目相匹配的 LocalIP，以供日后使用。如果有多个不同的组织管理员集群，且 2.a 的输出包含 1.b 中提到的 LocalIP，则继续执行第 3 步。
- 解决组织系统集群使用的重叠 IP。
- 运行：
kubectl get subnetclaims -A --kubeconfig ROOT_ADMIN_KUBECONFIG -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CIDRBLOCK:.status.ipv4SubnetStatus.cidrBlock | grep worker-node
- 记下步骤 3.a 中的查询返回的
SubnetClaim 对象数量。此值必须等于有效组织的数量。
- 对于每一行，记下命名空间（第 1 列）和 CIDR 块（第 3 列）。每行的 CIDR 地址块应与其他行的 CIDR 地址块相同。
- 对于每个组织，请执行以下步骤：
- 导航到相应组织的组织管理员集群中的
{organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim 对象。
- 计算相应组织的工作器节点地址池声明的
Start IP。为此，请从 3.c 中获取 CIDR 地址块，并从 3.d.i 中获取 AddressPoolClaim 的 Size 字段。从 CIDR 地址块中的倒数第二个 IP 开始，向下数 Size IP 个。这是第一个组织的新 Start IP（在步骤 3.d.iii 中使用）。对于每个额外的组织，从上一个组织的新 Start IP 开始，倒计时 Size IP 秒。
例如：
CIDR block: 10.0.0.0/24
org-1, org-2, & org-3 AddressPoolClaim Size: 2
- New org-1 startIPAddress: 10.0.0.252
- New org-2 startIPAddress: 10.0.0.250
- New org-3 startIPAddress: 10.0.0.248
- 在步骤 3.c.i 中的
AddressPoolClaim 中，在 Spec 字段中添加以下字段：
staticIPRanges:
- startIPAddress: {Start IP from step 3.d.ii}
size: {Size from step 3.d.ii}
使用以下命令：
`kubectl edit addresspoolclaim ADDRESS_POOL_CLAIM_NAME -n ORGANIZATION_NAME-system-cluster --kubeconfig ORGANIZATION_ADMIN_KUBECONFIG
如果您使用 3.d.ii 中的 org-1，结果必须如下所示：apiVersion: system.private.gdc.goog/v1alpha1
kind: AddressPoolClaim
metadata:
name: org-1-system-bgp-flat-ip-ipv4-apc
namespace: org-1-system-cluster
...
spec:
category: InternalOverlayNetwork
...
parentReference:
name: worker-node-network-subnet
type: SubnetClaim
size: 2
staticIPRanges:
- startIPAddress: 10.0.0.252
size: 2
status:
allocatedIPRanges: ...
...
- 清理以避免 TORSwitch 硬件上出现不必要的 BGP 会话。
- 如需列出所有需要更新的
TORSwitchInternal 资源，请运行以下命令：
kubectl get torswitchinternals --kubeconfig ROOT_ADMIN_KUBECONFIG -A
- 对于上一个命令的输出中列出的每个
TORSwitchInternals，请运行以下命令：
kubectl edit torswitchinternal TOR_SWITCH_INTERNAL_NAME --kubeconfig ROOT_ADMIN_KUBECONFIG -n gpc-system
- 对于所有
TORSwitchInternal 对象，从 .spec.ebgpNeighbors 列表中移除所有具有 NeighborIP 的条目，这些 NeighborIP 等于第 2 步中的任何 LocalIP。例如，从第 2.b 步中可以看出，2.2.2.2 的 LocalIP 为 1。以下是清理步骤前后的示例 TORSwitchInternal。
清理之前：
apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
- md5SecretReference: {}
neighborIP: 2.2.2.2
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
清理后。请注意已移除的 ebgpNeighbor 条目：
apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
- 通过执行第 1 步并确认所有
BGPSession 对象 States 都已恢复为 Established 来进行验证。所有修改可能需要大约 10 分钟才能传播到物理 GDC TORSwitch 配置。
|
| 升级 |
1.9.7 - 1.9.21 |
在升级期间，节点和操作系统升级可能会停滞不前。
症状：
您可能会看到某个节点在几个小时内处于 Ready, SchedulingDisabled 状态。
kubectl --kubeconfig $ROOT_ADMIN_KUBECONFIG get no
NAME STATUS ROLES AGE VERSION
aa-bm01 Ready, SchedulingDisabled control-plane 52d v1.27.4-gke.500
ab-bm01 Ready control-plane 52d v1.27.4-gke.500
ac-bm01 Ready control-plane 52d v1.27.4-gke.500
临时解决方法：
- 按照 runbook PLATAUTH-SSH 0001 获取相关节点的 SSH 密钥。使用 SSH 连接到节点后，运行以下命令：
multipath -ll | grep fail
- 仅当输出类似于以下内容时，才继续执行下一步：
size=1.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 7:0:0:7 sdad 65:208 failed faulty running
| `- 8:0:0:7 sdae 65:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
|- 6:0:0:7 sdac 65:192 failed faulty running
`- 5:0:0:7 sdab 65:176 failed faulty running
- 运行以下命令以解决此问题：
systemctl stop multipathd
iscsiadm -m session -R
systemctl start multipathd
|
| 升级 |
1.9.8-1.9.21 |
症状：
如果 ABM 集群升级停滞超过 2 小时，则节点耗尽可能被阻止。
临时解决方法：
以下操作以根管理员集群为例。${TARGET_KUBECONFIG} 是指节点排空受阻的目标 ABM 集群的 `kubeconfig`，${KUBECONFIG} 是指管理目标 ABM 集群的集群的 kubeconfig。对于根管理员集群，它们都指向根管理员 kubeconfig。
完成以下步骤，查看 ABM 集群升级是否卡住：
- 检查卡在排空状态的节点：
kubectl --kubeconfig=${KUBECONFIG} get cluster -n root root-admin -ojsonpath={.status.controlPlaneNodePoolStatus.nodesDraining}; echo
结果如下所示：
{"10.200.0.2": 2}
这意味着，对于节点“10.200.0.2”，有两个 pod 正在排空。
- 检查是否仍在从节点（以下称为
${NODE_BEING_DRAINED}）排空 pod：
kubectl --kubeconfig=${KUBECONFIG} get baremetalmachine -n root ${NODE_BEING_DRAINED:?} -ojsonpath='{range .status.bareMetalMachineDrainingStatus.podsYetToDrain[?(@.kind=="Pod")]}{@.namespace}{", "}{@.name}{"\n"}{end}'
输出 Pod 的数量必须与上一步中报告的正在排空的 Pod 数量相同。
对于第 1 步中列出的每个 pod yetToDrain，检查该 pod 的状态：
kubectl --kubeconfig=${TARGET_KUBECONFIG} get pods -n ${POD_NAMESPACE} ${POD_NAME} -o wide
如果 pod 处于 Running 状态，或者 pod 在 obs-system 命名空间中处于 audit-logs-loki-0 或 loki-0 状态，且 pod 没有关于 unable to unmount volume 的任何事件，请使用 grace-period 显式删除 pod。
kubectl --kubeconfig=${TARGET_KUBECONFIG} delete pods --grace-period=30 -n ${POD_NAMESPACE} ${POD_NAME}
- 对于 pod 停滞在排空状态的所有其他情况，请上报给随叫随到的服务。
- 监控节点的排空是否已完成。
- 如果其他节点卡在排空状态，请重复执行第 1 步。
|
| 升级 |
1.9.6
1.9.7
1.9.8
|
由于 DistributionPolicy 中的 Override 标志设置为 false，因此无法分发具有已签名制品的 1.9 版本，这会阻止在目标注册表中存在同名制品时分发该版本。
症状：
您可能会遇到以下问题：
- 已推送带有签名的制品。日志可能如下所示：
pushing the manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- 未能推送制品。日志可能如下所示：
failed to push manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- 找不到 404 制品。日志可能如下所示：
http status code: 404, body: {"errors":[{"code":"NOT_FOUND","message":"artifact library/private-cloud-staging/goharbor/harbor-core@sha256:755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a not found"}]}
- 制品分发失败。
临时解决方法：
如需解决此问题，请按以下步骤操作：
- 更新
DistributionPolicy 自定义资源 (CR)，将 Spec.Override 设置为 true。
- 按照 SAR-1005 Runbook 重新触发复制。
- 新的复制运行成功后，使用成功执行 ID 更新
Annotation 中的 ManualDistribution CR execution-ids。
|
| 硬件安全模块 (HSM) |
1.9.9 |
HSM 可能会间歇性地报告 ServicesNotStarted，这可能会导致裸机服务器无法恢复正常，并报告以下消息：
"message": "failed to get master key name"
症状：
您可能会遇到以下问题：
临时解决方法：
如需解决此问题，请按以下步骤操作，以重新启动卡住的 HSM：
- 通过运行以下命令，从第一个 HSM 安装
kstl 工具：
export HSM_NAME=`kubectl get hsm \
-n gpc-system -o jsonpath={.items[0].metadata.name} | tr -d '"'`
export HSM_MGMT_IP=$(kubectl get hsm $HSM_NAME \
--namespace gpc-system \
--output jsonpath="{.spec.managementNetwork.ip}")
curl --insecure \
https://$HSM_MGMT_IP/downloads/ksctl_images.zip \
--output ksctl_images.zip
mkdir -p ~/bin
unzip ksctl_images.zip -d ~/bin
cp ~/bin/ksctl-linux-amd64 ~/bin/ksctl
export PATH=$PATH:~/bin
mkdir -p $HOME/.ksctl
export ADMIN_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "admin" | grep -v "luna-admin" | grep -v "ksadmin"`
export ADMIN_PW=$(kubectl get secrets $ADMIN_SECRET_NAME -n hsm-system -o jsonpath="{.data.password}" | base64 -d)
export ADMIN_SSH_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "ssh"`
kubectl get secret $ADMIN_SSH_SECRET_NAME \
--namespace=hsm-system \
--output jsonpath='{.data.ssh-privatekey}' \
| base64 --decode > $HOME/.ksctl/ssh-privatekey
chmod 0600 $HOME/.ksctl/ssh-privatekey
cat << EOF > $HOME/.ksctl/config.yaml
KSCTL_URL: https://$HSM_MGMT_IP:443
KSCTL_USERNAME: admin
KSCTL_PASSWORD: '$ADMIN_PW'
KSCTL_NOSSLVERIFY: true
EOF
- 确认是否有任何 HSM 无法正常重启。对于每个卡在
ServicesNotStarted 的 HSM，获取 $HSM_MGMT_IP 并验证服务是否已停止：
ksctl services status --url=https://$HSM_MGMT_IP
- 暂停所有 HSM、HSM 集群和 HSM 租户：
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
- 在服务关闭的情况下，建立与 HSM 的 SSH 连接：
ssh -i $HOME/.ksctl/ssh-privatekey ksadmin@$HSM_MGMT_IP
- 确保您位于正确的 HSM 中。检查您是否已使用正确的
$HSM_MGMT_IP 建立 SSH 连接。
- 从 HSM 内部重新启动第一个 HSM：
ksadmin@ciphertrust:~ sudo reboot
- 等待第一个 HSM 从 HSM 外部变为健康状态：
watch -c ksctl services status --url=https://$HSM_MGMT_IP
此步骤可能需要大约 5 分钟才能完成，因为 HSM 需要重新启动。
- 针对服务中断的其他 HSM 重复执行上述步骤。
- 取消暂停 HSM、HSM 集群和 HSM 租户：
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
- 验证所有内容是否均已对账。HSM 可能需要 5 到 10 分钟才能完成协调。
|
| 监控 |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9 |
症状：
对于 1.11.3 之前的 GDC 版本，alertmanager-servicenow-webhook 提醒不会到达组织系统集群中的 ServiceNow。日志包含错误消息 read: connection reset by peer。此问题是由于缺少用于启用出站流量的标签而导致的。如果 webhook 需要在组织之间进行通信，则必须使用出站 NAT。
临时解决方法：
您必须在组织系统集群中为 alertmanager-servicenow-webhook 启用出站流量。如需解决此问题，请按以下步骤操作：
- 设置所需的前提条件：
- 安装 gdcloud 命令行界面 (CLI)。
- 获取根管理员集群和组织管理员集群的 kubeconfig 文件的路径。将路径分别保存在
ROOT_KUBECONFIG 和 ORG_SYSTEM_KUBECONFIG 环境变量中。
- 请让您的 Security Admin 在
obs-system 命名空间中为根管理员集群和组织管理员集群授予您可观测性管理员 (observability-admin) 角色。
- 确认您的环境中存在该问题：
- 获取
alertmanager-servicenow-webhook 部署：
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -n obs-system
- 查看
alertmanager-servicenow-webhook 部署的日志：
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" logs deployment/alertmanager-servicenow-webhook -n obs-system
如果日志包含错误消息 read: connection reset by peer，则表示存在此问题，您必须继续执行此解决方法中的步骤。
- 添加出站流量标签：
- 获取当前的
alertmanager-servicenow-webhook 部署 YAML 文件：
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-existing-deployment.yaml && \
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
- 将出站流量标签添加到
alertmanager-servicenow-webhook 部署 YAML 文件：
yq e -i '.spec.template.metadata.labels += {"egress.networking.gke.io/enabled": "true"}' $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
- 将
alertmanager-servicenow-webhook 部署 YAML 文件替换为更新后的文件：
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-new-deployment.yaml -n obs-system
部署必须自动重启。
- 再次运行确认您的环境中存在问题步骤，验证问题是否已解决。不得显示日志的错误消息。否则，请上报给工程团队。
回滚策略：
如果解决方法步骤失败或您发现任何指标出现损失，请将 alertmanager-servicenow-webhook 部署 YAML 文件恢复到原始状态：
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-existing-deployment.yaml -n obs-system
|
| 升级 |
1.9.10 |
症状：
升级卡在 NodeMaintain 这一步。
gpc-system org-1-admin-control-plane-node-poolphdzg 1 in-progress 3h58m
Status: Tasks:
Name: zp-aa-bm06 Task Status: finished
Name: zp-aa-bm04
Task Status: finished
Name: zp-aa-bm05
Task Status: in-progress
Upgrade Status: in-progress
Events: none
正在进行中的节点池的 nodeupgradetask 显示：
Status: Conditions: Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: Succeeded
Status: True
Type: PreUpgradeValidationCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: InProgress
Status: False
Type: NodeMaintainCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message: Observed Generation:1
Reason: Reconciling
Status: Unknown
Type: Succeeded
│ Data IP:10.249.20.4 bm-5f3d1782
│ Start Time: 2023-11-09T18:26:31Z
│ Events: none
临时解决方法：
请按以下步骤操作：
- 获取 cap-controller-manager 部署的名称。
kubectl --kubeconfig ${KUBECONFIG} get deployment -n kube-system | grep cap-controller-manager
cap-controller-manager-1.28.0-gke.435 1/1 1 1 30h
- 指定 cap-controller-manager 的名称（例如：cap-controller-manager-1.28.0-gke.435）：
export CAP_DEPLOYMENT_NAME=
- 重启 cap-controller-manager。
kubectl --kubeconfig ${KUBECONFIG} rollout restart deployment ${CAP_DEPLOYMENT_NAME} -n kube-system
deployment.apps/cap-controller-manager-1.28.0-gke.435 restarted
|
| 升级 |
1.9.10 |
症状：
升级卡在 AdminClusterHealth 后续检查步骤。 Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileBackoff 70s (x33 over 4h16m) OrganizationUpgrade admin cluster is not ready for org root
组织对象显示：
NAMESPACE NAME READY
gpc-system org-1 True
gpc-system root False
临时解决方法：
请按以下步骤操作：
使用以下命令可跳过预检：
kubectl delete organizationupgrade name -n gpc-system && kubectl annotate -n gpc-system organization name upgrade.private.gdc.goog/skip-preflight-check=ok
|
| 升级 |
1.9.9 |
症状：
NodeUpgradeTask 可能具有阻止任务完成的 failed to monitor failover registry recreation: failed to monitor job: job not complete 条件。
临时解决方法：
如需解决此问题，请重启作业：
- 删除名为
create-failover-registry-*** 且完成度为“0/1”的作业。
- 从正在升级的服务器对象中删除注解
failover-registry-creation-job-name。
控制器会自动重新创建作业。
|
| 升级 |
1.9.20 |
症状：
节点在 backup-ipsec-for-upgrade-bm 作业中失败。
I0512 01:05:55.949814 7 main.go:24] BuildDate: 2023-04-01T15:48:57Z
I0512 01:05:55.949920 7 main.go:25] Version: 1.9.2-gdch.135.dirty
"
临时解决方法：
删除 `backup-ipsec-for-upgrade-bm` 作业，并等待系统重新创建该作业。
|
| Google Distributed Cloud |
1.9.9 |
症状：
由于 etcd 集群启动失败，控制平面节点池未就绪。您可能会遇到以下问题：
--- FAIL: TestPlan (27563.26s)
--- FAIL: TestPlan/TestMTSystemClusterHealth (3445.24s)
k8s_mt_system_cluster_healthcheck_test.go:149: FATAL FLAKE: TestMTSystemClusterHealth: system cluster did not become ready in time: NodePool org-1-system-cluster/control-plane-node-pool didn't get ready: NodePool "control-plane-node-pool" is not ready
Error Routing:
{
"Name": "NODEPOOL_NOT_READY_ERR",
"Description": "NodePool is not ready",
"OwnerTeam": "Cluster Management",
"OwnerLDAP": "",
"TrackingBug""
}
FAIL
临时解决方法：
如需解决此问题，请按以下步骤操作：
- 检查集群创建是否卡在机器初始化作业上。
kubeadm join 任务失败，原因是：
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members
kubeadm reset 任务失败，原因是：
panic: runtime error: invalid memory address or nil pointer dereference
- 使用 SSH 连接到正常运行的控制面板节点。
- 运行
etcdctl 命令以清理过时的数据。
- 检查
etcd 会员资格：
# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member list
5feb7ac839625038, started, vm-72fed95a, https://10.252.164.11:2380, https://10.252.164.11:2379, false
99f09f145a74cb15, started, vm-8a5bc966, https://10.252.164.12:2380, https://10.252.164.12:2379, false
bd1949bcb70e2cb5, unstarted, , https://10.252.164.10:2380, , false
- 移除过时的会员资格：
# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member remove bd1949bcb70e2cb5
Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
|
| 虚拟机备份和恢复 |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9
1.9.10
1.9.11 |
症状：
由于虚拟机管理器中基于角色的访问权限控制 (RBAC) 和架构设置不当，用户无法启动虚拟机备份和恢复流程。
虚拟机备份方案名称不能超过 63 个字符。
例如，您可能会看到以下错误消息：
Internal error occurred: failed calling webhook
"vvirtualmachinebackupplantemplates.virtualmachine.gdc.goog":
failed to call webhook: Post "https://vmm-vm-controller-webhooks.vm-system.svc:443/validate-virtualmachine-gdc-goog-v1-virtualmachinebackupplantemplate?timeout=10s":
context deadline exceeded
临时解决方法：
虚拟机备份方案名称是 VirtualMachineBackupPlanTemplate 名称、资源类型（vm 或 vm-disk）以及相应资源的名称的串联。此串联字符串的长度必须少于 63 个字符。
为此，请在创建这些资源时保持其名称简短。如需详细了解如何创建这些资源，请参阅创建和启动虚拟机实例和为虚拟机创建备份计划。
|
| 升级 |
1.9.9 |
症状：
升级失败，并显示以下模板错误，导致备份 ipsec 作业失败：
"msg": "An unhandled exception occurred while templating '{'changed': True, 'stdout': 'connections {\\n # A connection id defined for this specific connection\\n pol_client {\\n children {\\n pol_cli
临时解决方法：
请按以下步骤操作：
登录到升级任务失败的节点。 保存 swanctl.conf 以进行备份。 移除 /etc/swanctl/swanctl.conf 文件中包含大括号的行。 删除失败的 backup-ipsec-for-upgrade 作业并等待系统重新创建该作业，然后后续作业成功完成。 将第 3 步中移除的行重新添加到 /etc/swanctl/swanctl.conf。
|
| 节点平台 |
1.9.6
1.9.7
1.9.8
1.9.9 |
当根管理员集群开始固件升级时，其中一个节点完成节点升级后，似乎卡住了。
症状：
nodeupgradetask 卡在 NodeResumeCompleted 阶段。machine-init 作业失败，日志显示 kubeadm join 失败。- 您无法使用数据平面 IP 地址建立与节点的 SSH 连接。
此问题是由升级后的节点不再接受入站网络流量引起的。
临时解决方法：
- 检查所有失败的
job/nodeupgradetask 日志，记下 IP 地址，并找出哪个节点存在问题。
- 重启受影响节点的
anetd-client pod。
- 验证数据平面 IP 上与受影响节点的 SSH 连接。
可选的进一步调查步骤：
- 通过 shell 进入任何正在运行的 anetd pod 的 cilium 代理容器。
- 运行 cilium-bugtool 并等待大约 10 秒。该工具会将日志保存在
/var/log/network/policy_action.log 目录中。
- 查找
deny 以查看流量是否被拒绝：
grep -r "deny" /var/log/network/ to
请注意哪些服务器被拒绝，可能是根管理员裸机节点。
|
| 升级 |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
症状：
|
| 升级 |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
症状：
- 从 1.9.12 升级到 1.9.13 时，租户组织裸金属上的节点操作系统升级失败。系统会显示以下消息：
Reason: Succeeded
Status: True
Type: NodeMaintainCompleted
Last Transition Time: 2024-05-06T18:25:20Z
Message: the ssh cert rotation job is still in progress
Observed Generation: 1
Reason: ReconcileBackoff
Status: Unknown
Type: Succeeded
Last Transition Time: 2024-05-06T18:27:42Z
-
SSH generation fails. The following message appears:
"tasks": [
{
"hosts": {
"10.248.4.72": {
"action": "gather_facts",
"changed": false,
"msg": "Failed to connect to the host via ssh: Certificate invalid: name is not a listed principal\r\nHost key verification failed
.",
"unreachable": true
}
},
"task": {
"duration": {
"end": "2024-05-06T19:47:11.284055Z",
"start": "2024-05-06T19:47:11.146536Z"
},
"id": "98f2b32d-e15c-fe27-2225-00000000001c",
"name": "Gathering Facts"
}
} ]
临时解决方法：
- 移除根管理员和组织管理员服务器 CR 中的
cluster.private.gdc.goog/ssh-trusted-ca-versions 注解。
- 删除失败的 Ansible 作业。由于服务器 CR 中
cluster.private.gdc.goog/host-key-rotation-in-progress 注解标记为 true，因此系统会自动创建新作业。
- 轮换后，将
cluster.private.gdc.goog/ssh-trusted-ca-versions 注解重新添加到服务器 CR 中。
|
| 节点、升级 |
1.9.* |
症状：
升级后，某些裸金属节点上的 pod 卡在 CrashLoopBackOff 状态，并且节点上的 iptables -L -v -n | grep CILIUM 返回空结果。
临时解决方法：
如需解决此问题，请完成以下步骤：
- 运行以下命令：
crictl pods --name anetd -o json | jq --raw-output '.items[].id' | xargs crictl rmp --force。
- 再次运行
iptables -L -v -n | grep CILIUM，并验证是否有输出。
|
| 日志记录 |
1.9.14
1.9.15 |
症状：
audit-logs-loki-0 pod 处于 CrashLoopBackOff 状态。
验证 pod 状态：
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
其中，SYSTEM_KUBECONFIG 是 kubeconfig 文件的路径。
Loki 错误显示在以下输出中，其中 CrashLoopBackOff 是状态：
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 1/2 CrashLoopBackOff 9 (4m6s ago) 25m
临时解决方法：
如需解决此问题，请完成以下步骤：
- 将 kubeconfig 文件的路径导出到名为
SYSTEM_KUBECONFIG 的环境变量。
- 缩减 Logmon operator：
kubectl scale deployment -n obs-system logmon-operator --replicas 0
- 缩减 Loki 资源：
kubectl scale loki -n obs-system --replicas 0
kubectl scale statefulset audit-logs-loki -n obs-system --replicas 0
- 删除
audit-logs-loki-storage-audit-logs-loki-0 和 loki-storage-loki-0 永久性卷声明 (PVC)。
- 删除
obs-system/loki-storage-loki-0 和 obs-system/audit-logs-loki-storage-audit-logs-loki-0 永久性卷 (PV)。
- 对 Logmon 运算符进行扩容：
kubectl scale deployment -n obs-system logmon-operator --replicas 1
- 按照步骤更新日志记录配置（从版本 1.9 开始）。
- 检查
audit-logs-loki-0 pod 是否正在运行：
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
输出中必须显示 Running 状态，如以下示例所示：
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 2/2 Running 0 15h
|
| 基础架构即代码 |
1.9.16 |
症状：
升级到 1.9.16 时，Gitlab 插件安装失败。您可能会看到如下错误：
Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgr │
│ ade error: timed out waiting for the condition: deployments/gitlab-sidekiq-all-in-1-v2: release gitlab failed: client rate limiter Wait returned an error: ra │
│ te: Wait(n=1) would exceed context deadline
Postgres pod（例如 gpc-system/gitlab-postgresql-0）处于终止状态。
临时解决方法：
- 强制删除卡在终止状态的 postgres pod：
kubectl delete pod POD_NAME --grace-period=0 --force --namespace NAMESPACE
- 确保在删除后重新创建 postgres pod。
|
| 身份和访问权限管理 |
1.9.19
1.9.20 |
症状：
从 1.9.18 版升级并尝试访问 GDC 控制台时，您可能会看到以下消息：
Authentication failed, please contact your system administrator
临时解决方法：
- 获取所需的 CA：
export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get secret fakeoidcprovider-https -n istio-system -o jsonpath='{.data.ca\.crt}'
- 打开客户端配置文件进行修改：
kubectl edit clientconfig -n kube-public default
- 在客户端配置中找到
certificateAuthorityData，并使用以下路径更新所需的 CA：spec > authentication > (fake-oidc-provider) > oidc > certificateAuthorityData
|
