Google Distributed Cloud air-gapped 1.14.x 已知问题

备份和恢复

修改集群备份恢复方案时出现问题

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

症状：

无法使用 GDC 控制台修改 RestorePlan 自定义资源。

临时解决方法：

您可以创建新的恢复方案并删除旧的恢复方案，也可以使用 kubectl CLI 修改恢复方案。

来源磁盘大小无效

版本：1.14.4、1.14.5

症状：由于迁移到 v2 组织架构后后端数据模型发生变化，界面错误地将磁盘大小显示为 0 MB，并将创建时间显示为“未知”。

解决方法：目前没有其他方法可通过界面查看此信息。

由于内存不足，代理和控制平面 pod 会重启

版本：1.14.3、1.14.4

症状：如果代理和控制平面 Pod 耗尽内存，可能会重新启动。

解决方法：按照 BACK-R0005 运行手册中的说明，增加控制平面和代理 Pod 的内存。将 pod 的内存增加到 2 GiB。

未应用备份和恢复 SLO

版本：1.14.3、1.14.4

症状：默认情况下，GDC 服务等级目标 (SLO) 指标和提醒未配置，因为未安装必要的自定义资源定义。这些提醒在 Grafana 中使用。

解决方法：如需在 GDC 中为备份和恢复启用 SLO，请按照 BACK-T0001 运行手册操作。

保留政策不适用于导入的备份

版本：所有版本的 Google Distributed Cloud (GDC) 网闸隔离版都可能受到影响。

症状：将备份代码库附加到集群会同步所有备份和恢复元数据，并将代码库视为导入的备份。在协调期间，系统会错误地跳过这些导入的备份，这意味着系统会忽略保留政策，并无限期地保留备份。

解决方法：导入的备份会标记为 backup.gdc.goog/imported-repository:BACKUP_REPOSITORY_NAME。如需允许正常协调并应用保留政策，请使用以下 kubectl 命令从备份中移除标签：

  1. 设置所需的环境变量：

    export KUBECONFIG=KUBECONFIG
export BACKUP_REPOSITORY_NAME=BACKUP_REPOSITORY_NAME
export NAMESPACE=BACKUP_PLAN_NAMESPACE

    替换以下内容：

    • KUBECONFIG：kubeconfig 文件的路径。
    • BACKUP_REPOSITORY_NAME：备份代码库的名称。
    • NAMESPACE：包含备份方案的命名空间。

  2. 列出所有已导入的备份：

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

  3. 根据需要移除标签：

    • 从所有备份中移除标签：

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

    • 移除单个备份的标签：

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

部分虚拟机备份失败

版本：1.14.3、1.14.4

症状：如果多个虚拟机中的一个备份失败，则整个虚拟机备份会被标记为失败。

解决方法：限制每个备份方案的虚拟机数量。

在用户或服务集群删除后清理孤立的备份资源

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

症状：当用户或服务集群被删除时，在组织基础架构和管理集群中创建的相关联的备份代理资源（例如 StatefulSet、Pod、Secret 等）不会自动清理。这可能会导致资源孤立，如果使用相同的名称再次创建集群，备份代理 pod 将无法正常运行。

解决方法：孤立资源位于组织基础架构集群中的专用命名空间中。如需清理这些内容，您需要删除此命名空间。

  1. 设置组织基础架构集群和管理集群的 kubeconfig 文件。

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

  2. 确定孤立资源的命名空间。命名空间遵循 gpc-backup-<cluster-name>-system 模式。例如：

    • gpc-backup-user-vm-1-cluster-system
    • gpc-backup-user-vm-2-cluster-system
    • gpc-backup-g-org-1-shared-service-cluster-system

  3. 删除命名空间。此命令将删除其中的所有资源，包括备份代理的 StatefulSet 和 Pod（位于基础架构中）以及管理集群中的 Secret。

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

  4. 如需确认清理是否成功，请再次运行 get all 命令。

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

    该命令现在应该会失败，因为命名空间已不存在。您应该会看到类似 Error from server (NotFound): namespaces "<namespace-name>" not found 的错误。

不支持通过 CLI 或界面删除 VirtualMachineRestore

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

症状：删除 VirtualMachineRestore 资源后，VirtualMachineRestore 控制器不会自动清理底层资源（VolumeRestore、Restore）。这需要执行手动清理。 无论您是使用 kubectl delete 还是通过界面删除，都需要遵循此要求。

解决方法：解决方法是手动按正确的顺序删除依赖资源，然后从 VirtualMachineRestore 资源中移除终结器。

  1. 将 kubeconfig 文件设置为指向管理集群。

    export MGMT_KUBECONFIG=<path_to_management_kubeconfig>

  2. 确定要删除的 VirtualMachineRestore 及其命名空间。

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

  3. 找到并删除关联的 VolumeRestore 资源。这些变量是通过一个标签创建的，该标签将它们与 VirtualMachineRestore 相关联。

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

  4. 找到并删除关联的 Restore 资源。这些变量是通过一个标签创建的，该标签将它们与 VirtualMachineRestore 相关联。

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

  5. 现在，如果尚未执行 kubectl delete，请执行该操作，并从 VirtualMachineRestore 资源中移除 finalizer。这是最后一步，可让 Kubernetes 垃圾收集器删除资源。

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

  6. 验证删除操作。

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

    该命令应返回 NotFound 错误，以确认资源已被删除。

备份控制平面 pod 因内存不足而崩溃

版本：1.14.4 及更高版本

症状：组织的基础设施集群的 gpc-backup 系统命名空间中的 gpcbackup-controlplane-controller pod 显示的状态为 CrashLoopBackOff。发生此错误时，备份和恢复操作将失败、停止响应或无法按预期运行。

解决方法：按照 BACK-R0005 中的说明，提高 gpcbackup-controlplane-controller deployment 的内存限制。此方法会应用 SubcomponentOverride 来调整 CPU、内存请求和限制。

用户集群删除停滞

版本：1.14.7 及更高版本

症状：由于终结器问题，集群卡在删除状态。

解决方法：在删除集群之前，检查存储卷是否具有 SnapMirror 关系。如需了解详情，请参阅 BACK-R0109。

由于永久性卷声明处于待处理状态，恢复操作卡住了

版本：1.14.3 及更高版本

症状：永久性卷声明 (PVC) 控制器有时无法与组织基础架构集群中的备份代理通信。虽然此问题不会影响备份功能，但可能会导致卷恢复操作卡在 Pending 状态，并最终超时。此问题会影响涉及卷恢复的恢复操作，例如用于克隆的数据库服务恢复功能和用户工作负载恢复。

如果出现此问题，在您手动重启相应备份代理之前，受影响集群中的后续恢复操作将会失败。

如需确认您的恢复问题是否与此特定问题相关，您必须调查备份代理日志：

  1. 按照 IAM-R0005 的说明，通过应用 ExpirationClusterRoleBinding 资源获取必要的 BACK Debugger 角色 (back-cluster-debugger)。

  2. 按照 IAM-R0004 生成组织基础架构集群的 kubeconfig 文件。所有备份代理都在组织基础架构集群中运行。

  3. 确定正在协助执行恢复的备份代理：

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

    将 ORG_INFRA_KUBECONFIG 替换为组织基础架构集群的 kubeconfig 文件的路径。

    输出类似于以下内容：

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

    阅读输出内容，确定与您的恢复操作对应的备份代理。例如，如果输出中受影响的有状态集命名空间为 gpc-backup-user-vm-1-cluster-system，则备份代理为 gpcbackup-agent-user-vm-1。

  4. 在有状态集日志中搜索错误消息，以确认问题：

    kubectl --kubeconfig=ORG_INFRA_KUBECONFIG logs statefulsets/BACKUP_AGENT \
    -n NAMESPACE | grep "Failed to watch \*v1.PersistentVolumeClaim"

    替换以下内容：

    • ORG_INFRA_KUBECONFIG：组织基础架构集群的 kubeconfig 文件的路径。

    • BACKUP_AGENT：您在上一步中确定的备份代理。

    • NAMESPACE：您在上一步中确定的命名空间。

    如果存在匹配的日志，则表示您遇到了这一已知问题。

解决方法：如需解决此问题，请按以下步骤操作：

  1. 重启备份代理：

    kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart \
   statefulsets/BACKUP_AGENT -n NAMESPACE

    替换以下内容：

    • ORG_INFRA_KUBECONFIG：组织基础架构集群的 kubeconfig 文件的路径。

    • BACKUP_AGENT：您在确认问题时确定的备份代理。

    • NAMESPACE：您在确认问题时确定的命名空间。

    输出类似于以下内容：

    statefulset.apps/gpcbackup-agent-g-org-1-shared-service restarted

  2. 等待最多 20 分钟，让待处理的操作自动恢复。

备份代理重启完成后，您可以针对同一目标集群执行另一次恢复操作。完成此解决方法后，不会产生任何副作用。每个受影响的集群只需完成一次此问题解决办法。

集群管理

子组件 kub-gpu-controller 未协调

版本：1.14.3

症状：gdchservices 组织中的子组件 g-gdchservices-shared-service-cluster/kub-gpu-controller 不会进行协调。系统会返回以下输出：

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

此故障会阻止 GPU 机器在 gdchservices 组织中启动。

解决方法：升级到版本 1.14.4+ 以缓解此问题。

Standard 集群无法移除节点池

版本：1.14.3、1.14.4、1.14.5

已修复：1.14.6

症状：从标准集群中移除过时的节点池失败，并且节点池未在预期的时间范围内删除。标准集群目前处于非公开预览阶段，可能不适用于所有客户。

解决方法：手动移除过时的节点池。

集群卡在删除状态

版本：1.14.6 及更高版本

症状：删除 Kubernetes 集群时，集群可能会卡在 Deleting 状态。运行以下命令，检查集群的状态：

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

输出类似于以下内容：

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

您还可以通过检查集群命名空间的状态来验证问题：

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

输出类似于以下内容：

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

集群命名空间卡在 Terminating 状态，并且 NamespaceContentRemaining 和 NamespaceFinalizersRemaining 条件设置为 True。

解决方法：如需解决此问题，请完成以下步骤：

  1. 修补了转发规则 API：

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

  2. 修补后端服务 API：

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

数据库服务

本部分包含数据库服务的已知问题。

AlloyDB Omni 数据库克隆卡住

版本：1.14.6 及更低版本

已修复：1.14.7

症状：当用户从某个时间点克隆 AlloyDB Omni 集群时，克隆的数据库集群会卡在 DBSE0005 错误上，无法变为就绪状态。相应的 restore.alloydb 资源停留在“ProvisionInProgress”阶段。

解决方法：如需解决此问题，请根据成功备份的 COMPLETETIME 仔细选择时间点。

列出管理 API 服务器上可用于克隆的 AlloyDB Omni 备份。

kubectl get backups.alloydb -n source-dbcluster-namespace

示例输出：

NAMESPACE   NAME                         PHASE       COMPLETETIME
db1         backupplan1-20240908215001   Succeeded   2024-09-08T21:37:38Z
db1         backupplan1-20240909215001   Succeeded   2024-09-09T21:16:18Z
db1         backupplan1-20240910215001   Succeeded   2024-09-10T21:09:38Z
db1         backupplan1-20240911215001   Succeeded   2024-09-11T21:50:47Z

选择一个 COMPLETETIME 值作为克隆的时间点。请注意，时间采用的是世界协调时间 (UTC)。

DNS

GlobalCustomerRootDNSServerNotReachable 触发了错误提醒

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

症状：系统触发了 DNS 提醒 DNS-A0021，表明存在 GlobalCustomerRootDNSServerNotReachable。 org-mp 中 global-customer-root-dns 的探测 CR 在规范中没有 egress: true。

临时解决方法：

  1. 为 org-mgmt 设置 KUBECONFIG 路径：

    export MGMT_KUBECONFIG=MANAGEMENT_KUBECONFIG

  2. 暂停管理探测 CR 的 core-mz 子组件：

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

  3. 修改来自 org-mp 的当前探测 CR：

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

  4. 更新规范以包含 egress: True 并应用更改。请注意，CLUSTER_NAME 和 GLOBAL_CUSTOMER_ROOT_IP 保持不变。

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

此解决方法可修复探测器，任何误报都会在 15 分钟内消退。

文件/块存储

无法在虚拟机中装载文件共享卷

版本：1.14.6、1.14.7

症状：向集群添加新节点时，无法更新网络存储权限，这可能会导致 NFS 装载请求被拒绝。装载 NFS 文件共享时，您可能会看到 access denied by server 错误。

解决方法：重启 file-share 或 proxy-group 协调器，或修改 FileShare 资源以触发更新。

防火墙

子网 CR 中缺少相应地址的安全政策规则

版本：1.14.3

症状：由于客户在组织全局 API 服务器中创建的全局子网自定义资源中缺少防火墙地址组，导致组织无法访问。

解决方法：按照服务手册 FW-G0002 中的步骤手动添加安全政策规则，以允许相应流量。

GDC 防火墙拒绝了管理平面和数据平面上流向 OIR 的流量

版本：1.14.3、1.14.4

症状：部署 OCITTopology 自定义资源后，OIR 与 GDC 管理平面和数据平面之间的连接中断。

解决方法：按照服务手册 FW-G0002 中的步骤在根管理员集群中手动添加安全政策规则，以允许流量通过。

必须遵循以下安全政策规则：

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

替换以下内容：

  • OCIT_CIDR：客户输入问卷 (CIQ) 的 ocitCIDR 字段中的 IP 地址范围。
  • MGMT_CIDR：客户输入问卷 (CIQ) 的 oobManagementCIDRs 字段中的 IP 地址范围。
  • ZONE_INFRA_CIDR：客户输入问卷 (CIQ) 的 zoneInfraCIDRs 字段中的 IP 地址范围。

GDC 防火墙拒绝跨可用区跨组织的流量

版本：1.14.3、1.14.4、1.14.5

症状：防火墙默认会阻止跨可用区和跨组织的流量。

解决方法：按照操作手册中的步骤手动添加安全政策规则，以允许流量通过。

防火墙不支持标识符与组织名称相同的 AttachmentGroup

版本：1.14.3 及更高版本

症状：部署 AttachmentGroup 后，如果相应 AttachmentGroup 对象中的 identifier 字段与 orgName 相同，防火墙将无法解析此对象，并且防火墙配置更新会卡住。以下是一个有问题的 AttachmentGroup 示例：

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

解决方法：避免使用组织名称作为标识符。您可以通过以下几种方式修复不良 AttachmentGroup。

选择以下任一选项来修复存在问题的 AttachmentGroup。

  • 在原始标识符的末尾附加一个带有短划线符号的字符串：

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

  • 在原始标识符的开头附加一个带有短划线符号的字符串：

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

  • 将原始标识符替换为其他字符串：

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

港口

在备份和恢复后，Harbor CLI Secret 会失效

版本：1.14.3

症状：在 Harbor 备份和恢复后，CLI 密钥会失效，需要重新创建。

解决方法：如需缓解此问题，请按以下步骤操作：

  1. 使用 IAP 用户账号登录 Harbor。
  2. 点击您的用户名，然后选择用户个人资料。
  3. 点击 更多。
  4. 自动或手动创建另一个 CLI 密文。

如需详细了解 GDC 中的 Harbor，请参阅 Harbor 概览。

Harbor 备份和恢复作业竞争权限

版本：1.14.3、1.14.4

症状：当不同用户项目中有多个 Harbor 实例时，备份和恢复操作会争夺基于角色的访问权限控制，导致失败率很高。

解决方法：如需缓解此问题，请按照以下步骤为创建 Harbor 实例的每个命名空间手动创建角色绑定：

  1. 设置所需的环境变量：

    INSTANCE_NAMESPACE=INSTANCE_NAMESPACE
INFRA_CLUSTER_KUBECONFIG=INFRA_CLUSTER_KUBECONFIG

    替换以下内容：

    • INFRA_CLUSTER_KUBECONFIG：基础架构集群 kubeconfig 文件的路径。
    • INSTANCE_NAMESPACE：用于创建受管 Harbor 服务 (MHS) Harbor 实例的命名空间。

  2. 为解决方法创建角色绑定：

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

Harbor 备份大小显示 0 值

版本：1.14.3、1.14.4

症状：目前尚未实现对 Harbor 备份的备份大小的衡量。在 GDC 控制台中，“SizeBytes”字段显示的值为 0，而“大小”列显示的值为 0 MB。此配置目前属于预期行为。

Harbor 注册表控制台页面中备份资源的权限错误

版本：1.14.3、1.14.4

症状：如果您没有 Harbor 实例管理员角色，则在 GDC 控制台中查看 Harbor Container Registry 页面时，会看到备份资源的权限错误。之所以显示此错误，是因为备份信息是新近添加到 Harbor Container Registry 页面的，但除了 Harbor 实例管理员之外，尚未向其他 IAM 角色授予备份资源的读取权限。

Harbor Container Registry 页面上的其他 GDC 控制台元素仍可正常运行。如需详细了解 GDC 中的角色，请参阅角色定义。

数据库密码轮换卡在某个页面

版本：1.14.3、1.14.4、1.14.5、1.14.6

症状：针对数据库请求抛出与身份验证相关的错误，例如 failed SASL auth (FATAL: password authentication failed for user "dbsadmin" (SQLSTATE 28P01))，并且单个可轮换的密钥存在许多自动生成的轮换请求。

解决方法：删除可轮替 Secret 的其他未就绪轮替请求。

  1. 将 KUBECONFIG 设置为 mp API 服务器。

  2. 导出命名空间：

    NAMESPACE=haas-system

  3. 查找 haas-system 中是否有任何可轮替的密文未就绪：

    kubectl get rotatablesecrets -n ${NAMESPACE?}

    输出可能如下例所示：

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

  4. 导出可轮换 Secret 的名称，例如：

    ROTATABLE_SECRET=haasdb-pw-haas-alice

  5. 删除未就绪的额外轮换请求：

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

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

硬件安全模块

仍可检测到已停用的 HSM 试用许可

版本：1.14.3、1.14.4、1.14.5

症状：由于 CipherTrust Manager 中存在已知问题，已停用的试用许可仍可被检测到，并可能会触发错误的过期警告。

解决方法：请参阅 HSM-R0003，验证有效的常规许可并删除已停用的试用许可。

HSM 主机-守护程序文件描述符泄漏

版本：1.14.x

症状：如果 HSM 运行时间超过 30 天，文件描述符泄漏可能会导致宿主守护程序服务停止响应，从而导致 ServicesNotStarted 错误。

解决方法：重启宿主守护程序服务。为此，请让您的基础设施运维人员 (IO) 以 ksadmin 用户身份通过 SSH 连接到 HSM，然后运行以下命令：

sudo systemctl restart host-daemon

如果这样无法解决问题，您的 IO 可以重启不健康的 HSM。

HSM 在启动后出现 ValidateNetworkConfig 错误

版本：1.14.x

症状：HSM 自定义资源未进入 Ready 状态，并因 ValidateNetworkConfig 错误而失败。此错误会显示以下消息：data0 interface MAC address {} is not active。如果系统重新启动，并且设置了其他主数据接口，则会发生此错误。

解决方法：按照运行手册 HSM-R0059 的说明重新应用数据网络的 HSM 网络配置。即使多个 HSM 出现此错误，也可以安全地按照此操作手册操作。

健康

虚假警报 SLO 提醒

版本：1.14.3

症状：successRange SLO 错误地触发。

解决方法：请求基础设施运维人员 (IO) 验证相应提醒是真实问题还是误报。

为此，当提醒触发时，请按照相应的 Runbook 解决服务等级目标 (SLO) 提醒的根本原因。

  1. 情形 1：如果 runbook 成功解决了问题，并且提醒停止触发，则 IO 可以关闭关联的突发事件。

  2. 情况 2：如果 runbook 已完成，但提醒仍持续触发，则表明可能存在误报。检查 SLO 是否中断：

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

  3. 根据输出结果：如果确认相应提醒是误报，IO 应在 GDC 气隙实例中将该提醒静音；否则，应向 Cloud 支持团队上报。

  4. 在任一情况下，IO 都应升级到 Cloud 支持团队，以验证可操作的组件是否正常运行。

基于计量的 SLO 配置无效

版本：1.14.3、1.14.4

症状：由于配置错误，部分服务等级目标 (SLO) 不会填充良好事件、不良事件或总事件。相关 SLO 基于 Prometheus 计量器，必须进行相应配置。

解决方法：

版本 1.14.3：没有解决方法。因此，系统不会针对受影响的 SLO 触发 SLO 提醒。

版本 1.14.4：提供了一种解决方法来修正 SLO。如需解决此问题，必须将设置 isGauge: true 应用于 SLO 规范。

SLO 的指标配置示例：

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

通过此设置修复的已知 SLO 包括：

  • 防火墙 SLO：
    • fw-packet-discard-errors-slo
    • fw-packet-discard-no-error-slo
    • fw-packet-discard-unknown-protocol-slo
    • fw-uptime-slo
  • 文件 SLO：
    • file-ontap-appliance-availability-slo
    • file-ipsec-networking-availability-slo
    • file-ontap-networking-availability-slo
    • file-iscsi-client-availability-slo
    • file-multipath-client-availability-slo
    • file-trident-client-availability-slo

身份和访问权限管理

IAM 角色绑定创建失败

版本：1.14.3

症状：IAM 角色绑定名称由系统生成。这些名称的长度不得超过 63 个字符，格式为 user-idp-prefix-rolename。如果生成的名称超过 63 个字符的限制，则无法创建角色绑定。因此，使用预定义角色或自定义角色定义的权限不会分配给用户。

解决方法：如果预定义或自定义的角色名称非常短（例如 4-5 个字符），则角色绑定创建可能会成功。

未能为项目服务账号创建 IAM 角色绑定

版本：1.14.3、1.14.4、1.14.5、1.14.6

症状：具有 organization-iam-admin 角色的项目服务账号 (PSA) 无法使用 gdcloud projects add-iam-policy-binding 命令为自己分配其他角色，例如 project-iam-admin 角色。此缺陷会阻止 PSA 管理自己的权限。

解决方法：确认您拥有 organization-iam-admin 角色。然后，在目标 PSA 的项目命名空间中为自己分配 project-iam-admin 角色，并为 PSA 分配 project-iam-admin 角色。借助此权限设置，PSA 可以为自己或其他 PSA 分配其他权限。

新项目在创建预定义角色时遇到延迟

版本：1.14.3

症状：创建新项目时，缺少默认角色，例如 project-bucket-object-admin。

解决方法：等待 15-60 分钟，或在组织基础架构集群上手动重启 iam-system 命名空间中的 iam-org-admin-cm-backend-controller 控制器。

GDC 控制台无法创建第一个角色绑定

版本：1.14.4

症状：使用 GDC 控制台为新的服务身份创建第一个角色绑定时，系统会报告角色绑定创建成功，但实际上并未成功。对服务身份执行的任何进一步操作都会失败且无效，包括添加其他角色绑定或删除角色绑定。

解决方法：使用 gdcloud CLI 为服务身份创建第一个角色绑定。在附加第一个角色绑定后，使用 GDC 控制台通过服务身份执行的所有未来操作都能正常运行。如需了解详情，请参阅为服务身份分配角色绑定。

AO 无法自行授予对基础架构集群中角色的访问权限

版本：1.14.3。1.14.4

已修复：1.14.3 热修复 21

症状：AO 无法向自己或任何其他用户授予对基础架构集群中任何角色的访问权限。

解决方法：AO 用户必须与 IO 联系，以获取所需的访问权限。IO 可以使用 IAC 为 AO 用户提供所需的访问权限。

现有服务账号令牌失效

版本：1.14.3

已修复：1.14.3 热修复 21

症状：用户集群在完成初始启动后，由于 service-account-issuer apiserver 实参发生更改，导致用户集群签发的现有服务账号令牌失效。此问题会导致用户集群上的 pod（例如具有 istio-proxy Sidecar 容器的 pod）无法使用服务账号令牌进行身份验证，并且服务账号令牌需要数小时才能使用新配置进行刷新。

权宜解决方法：手动重启用户集群上的 pod，以使服务账号令牌根据新配置进行续订。

基础设施即代码 (IAC)

由于缺少命名空间，子组件协调失败

版本：1.14.3

症状：子组件无法协调。这是因为必需的 config-management-monitoring 命名空间不会在 gdchservices-mp 集群中自动创建。

解决方法：使用以下清单在 gdchservices-mp 集群中创建 config-management-monitoring 命名空间：

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

IAC ConfigSync 指标收集失败

版本：1.14.3、1.14.4

症状：IAC 的 ConfigSync 监控子系统中的问题阻止了 otel-collector 部署的启动。系统不会收集 ConfigSync 指标以进行监控和提醒。

解决方法：在 root-admin 集群中完成以下步骤：

  1. 暂停 iac-configsync-mon 子组件。
  2. 修改 config-management-monitoring 命名空间中的 MetricsProxySidecar/iac-configsync-metrics 对象。

  3. 在 MetricsProxySidecar/iac-configsync-metrics YAML 中，找到以下内容：

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

    将此部分更改为以下内容：

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

  4. 重启 config-management-monitoring 命名空间中的 otel-collector 部署。

IAC RootSync 失败

版本：1.14.3

症状：由于缺少 iac-creds Secret，ConfigSync 在将资源从 Gitlab 同步到集群时出现问题。由于 iacmanager 问题，iac-creds 未轮换。

解决方法：在集群中完成以下步骤：

  1. 按照 IAC-R0015 运行手册解决缺少密钥 iac-creds 的问题。它会轮换 IaC 管理器和 Configsync 的凭据。

库存

商品目录审核无法协调一致

版本：1.14.3

症状：inv-audit 子组件无法协调，因为 HarborRobotAccount 仅在管理平面中可用。

解决方法：在 AlertManager 中创建静音，以将 component_reconciliation_errors 提醒设为静音，持续时间为 component: inv。

密钥管理系统

配置为使用 CTM 根密钥的 KMS 在 HSM 不可用时不会进行故障切换

版本：1.14.x

症状：当某个 HSM 不可用时，如果还有其他可用的 HSM 可以使用，但对 KMS 的某些请求却失败了。此问题仅在 KMS 配置为使用 CTM 根密钥时适用。

解决方法：按照 HSM-P0006 运行手册中的说明，从 HSMCluster 中移除不可用的 HSM。然后，重启 kms-backend 部署：

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

此命令会重新启动 kms-backend pod，并重新建立与 HSMCluster 中 HSM 的连接。

负载均衡器

由于子网 CIDR 耗尽，全球负载均衡器创建失败

版本：1.14.3

症状：由于全局子网中的 IP 地址不足，全局外部或内部负载均衡器创建失败。由于控制器使用了不正确的代码路径，系统无法为全球负载平衡器动态分配 IP 地址。负载均衡器仅引用一个子网，如果该子网没有更多可用的 IP 地址，则无法切换到其他子网。此限制会导致显示错误。

解决方法：您必须创建自己的子网，并为 ForwardingRule 资源创建静态 IP 地址。如需详细了解如何创建子网，请参阅为工作负载网络配置子网。创建 ForwardingRule 资源时，您可以在 cidrRef 字段中指定子网。

版本：1.14.3

症状：负载平衡器对象未进入 Ready 状态。

解决方法：您必须创建 Backend 资源，其中 spec 字段具有值。Backend 资源用于标识负载均衡器的端点。如果未能为 spec 字段提供值，可能会导致错误状态。

修改负载均衡器资源不会协调服务

版本：1.14.3

症状：修改负载均衡器自定义资源不会协调负载均衡器服务。

解决方法：如需缓解此问题，请删除并重新创建负载均衡器，方法是删除相应负载均衡器的 BackendService 和 ForwardingRule 资源。

系统不会拒绝错误的区域名称

版本：1.14.3

症状：全局 BackendService 资源不会拒绝错误的可用区名称。如果可用区名称不正确，负载均衡器会失败，而不是验证并拒绝配置。

解决方法：您必须提供所用可用区的正确名称。如果负载均衡器配置有误，则必须删除并重新创建负载均衡器自定义资源。

全球和可用区级负载均衡器 webhook 错误

版本：1.14.3

症状：系统会返回以下错误：

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

解决方法：如需缓解此问题，请重启并删除 unet-global-cm pod：

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

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

日志记录

Loki pod 在 WAL 重放期间崩溃或因内存不足而终止

版本：1.14.3、1.14.4、1.14.5

症状：

obs-system 命名空间中的 audit-logs-loki-io pod 进入 CrashLoopBackOff 状态。这是由于在预写式日志 (WAL) 重放期间，过早的活性探测失败或内存不足 (OOM) 终止所致，原因是 wal_replay_ceiling 值超过了 pod 的内存限制。

解决方法：

请按照以下步骤调整 Loki 的配置，以允许成功重放 WAL。更改将应用于受影响的集群（例如 root-admin 或 org-infra）

  1. 将 KUBECONFIG=/path/to/affected-cluster.kubeconfig 设置为环境变量。

  2. 暂停 LoggingPipelineReconciler 以防止控制器还原手动更改。应用此清单：

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

    确认替换处于有效状态。输出应包含 "disable-reconcilers=LoggingPipelineReconciler"。

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

  3. 将 audit-logs-loki-io-cm ConfigMap 中的 replay_memory_ceiling 降低为 8GB。

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

    修改 wal 部分：

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

  4. 可选：调整对象代理的规模。如果 obj-proxy pod 即将达到其资源限制，请扩缩部署以应对恢复期间增加的负载。

    a. 检查资源使用情况：

    kubectl top po -n gpc-system -l name=obj-proxy-manager --kubeconfig=${KUBECONFIG}

    b. 如果用量较高，请扩缩部署：

    kubectl scale deployment obj-proxy -n gpc-system --replicas=7 --kubeconfig=${KUBECONFIG}

    c. 您还可以根据需要增加 pod 的内存上限（例如，从 12000Mi 增加到 16000Mi）。

  5. 增加受影响 pod 的 PVC 大小（例如，loki-storage-audit-logs-loki-io-0 从 70Gi 更改为 75Gi，以防止磁盘压力过大。按照内部流程 SUPP-R001 调整 PVC 的大小。在下一步中重启后，系统会应用新的大小。

  6. 向 audit-logs-loki-io StatefulSet 添加了 startupProbe，以便在开始进行活跃度检查之前留出时间进行 WAL 重放。保存更改会触发 Pod 的滚动重启（5-10 分钟）。

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

    将此 startupProbe 添加到 audit-logs-loki-io 容器规范：

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

验证解决方法

  1. 检查 Pod 和 StatefulSet 状态：验证所有 audit-logs-loki-io Pod 是否都处于 Running 状态，以及 StatefulSet 是否显示所有副本都已准备就绪。

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

  2. 确认 PVC 已调整大小。预期输出为 75Gi。

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

  3. 通过检查 Pod 日志中是否有 errors=false 消息来确认 WAL 恢复是否成功。

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

  4. 检查 pod 内 /wal 目录的用量是否较低。

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

  5. 检查 Loki 戒指状态：

    a. 转发 Loki 服务的端口：

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

    b. 验证所有实例在 http://<DATA_IP>:43100/ring 时是否运行正常。

清理替换和对象代理

成功验证后，请执行以下清理步骤。

  1. 移除子组件替换：

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

  2. 如果您扩缩了 obj-proxy 部署，请将其缩减回原始大小。

监控

AlertManager Webhook 无法针对某些集群发送提醒

版本：1.14.3

症状：AlertManager webhook 无法从根管理员集群或 ServiceNow 实例所在的集群以外的任何集群向 ServiceNow 发送请求和提醒通知。因此，系统不会在 ServiceNow 中为组织创建提醒。

如果您反复收到错误日志消息，则可以确定 webhook 未能发送提醒。请按照以下步骤查找重复出现的错误：

  1. 导出环境变量：

    export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG

    将 MGMT_API_KUBECONFIG 替换为管理 API 服务器的 kubeconfig 文件的路径。

  2. 查找 pod：

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

  3. 获取日志：

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

    将 POD_NAME 替换为 pod 的名称。

  4. 查找类似于以下内容的重复错误：

    Errorsendingtherequest ... read: connection reset by peer

解决方法：建议的解决方法是暂停两个子组件，一个用于元监控提醒，另一个用于常规提醒。然后，在受影响集群的 mon-alertmanager-servicenow-webhook-backend 部署中，将标签 egress.networking.gke.io/enabled: "true" 替换为 networking.private.gdc.goog/infra-access: enabled。借助此标签，Pod 可以与其他基础设施集群通信，而无需依赖出站流量网关。

请按照以下步骤应用推荐的临时解决方法：

  1. 导出环境变量：

    export ROOT_KUBECONFIG=ROOT_KUBECONFIG
export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
export ORG=ORG

    替换以下内容：

    • ROOT_KUBECONFIG：根管理员集群的 kubeconfig 文件的路径。
    • MGMT_API_KUBECONFIG：管理 API 服务器的 kubeconfig 文件的路径。
    • ORG：组织的命名空间。

  2. 暂停子组件：

    • 暂停 mon-alertmanager-servicenow-webhook 子组件：
    kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-alertmanager-servicenow-webhook" \
  -n "${ORG}" lcm.private.gdc.goog/paused=true
    • 暂停 mon-meta-monitoring 子组件：
    kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-meta-monitoring" \
  -n "${ORG}" lcm.private.gdc.goog/paused=true

  3. 更新涵盖大多数提醒的 mon-alertmanager-servicenow-webhook-backend 部署：

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

  4. 将 spec.template.metadata.labels 中的标签从 egress.networking.gke.io/enabled: "true" 替换为 networking.private.gdc.goog/infra-access: "enabled"。

  5. 更新涵盖与监控堆栈相关的提醒的 meta-alertmanager-servicenow-webhook 部署：

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

  6. 将 spec.template.metadata.labels 中的标签从 egress.networking.gke.io/enabled: "true" 替换为 networking.private.gdc.goog/infra-access: "enabled"。

或者，您也可以使用 Grafana 查看相同的提醒。

ServiceNow 突发事件偶尔会重复

版本：1.14.3

症状：您可能会看到针对同一 Pod 的重复 ServiceNow 突发事件。

解决方法：您可以通过匹配突发事件说明中的指纹来识别重复的工单。

基础架构指标可能过于敏感

版本：1.14.3

症状：您可能会看到有关提醒 oclcm-reconciler-success-rate 的闹钟。

解决方法：您可以放心地将提醒设为静音。此提醒过于频繁，我们正在努力改进信号。

对账指标可能过于敏感

版本：1.14.3、1.14.4、1.14.5

症状：您可能会看到有关提醒 component_reconciliation_errors 的闹钟。

解决方法：您可以按照 Runbook MON-R2009 的说明放心地将提醒设为静音。此提醒过于嘈杂。

根管理员集群中存在两个误报

版本：1.14.3

症状：根管理员集群中的 MON-A0001_slow 和 MON-A0001_fast 提醒处于触发状态。

ServiceNow 中的突发事件类似于以下示例：

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

相应事件的说明如下：

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

解决方法：请按以下步骤操作，仅在根管理员集群中解决此问题：

  1. 删除 mon-a0001-blackbox-monitoring-obs-system MonitoringRule 中的 monitoring.gdc.goog/metamonitoring-project=mon-system 标签。

  2. 从 mon-a0001-blackbox-monitoring-obs-system MonitoringRule 中删除名称为 mon_metrics_pipeline_absent 且集群标签值为 ORG_NAME-admin 的所有记录规则。

    以下示例展示了要删除的 mon_metrics_pipeline_absent 录制规则：

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

几分钟后（大约 40 分钟），MON_A0001_slow 和 MON_A0001_fast 提醒都会恢复为 Normal 状态。

根管理员控制器管理器显示高错误率

版本：1.14.3

症状：您可能会看到有关提醒 ControllerReconciliationErrorRateHigh 的闹钟。控制器管理器将显示以下日志：ApplianceStorage.ceph.storage.private.gdc.goog \"appliance-storage\" not found

解决方法：您可以放心地停用出现错误的控制器。

  1. 导出环境变量：

    export ROOT_KUBECONFIG=ROOT_KUBECONFIG

  2. 修改根管理员控制器管理器部署：

    kubectl --kubeconfig ${ROOT_KUBECONFIG} edit deployment \
  -n gpc-system root-admin-controller

    在 manager 容器中，如果尚无实参 --disable-reconcilers，请添加一个，并将其值设为 --disable-reconcilers=ApplianceStorageTunnelReconciler。如果有，请用英文逗号添加 ApplianceStorageTunnelReconciler reconciler。例如 --disable-reconcilers=ManagementSwitch,ManagementAggSwitch,TORSwitch,AggSwitch,ApplianceTORSwitch,ApplianceStorageTunnelReconciler。

错误日志应清除。

KUB 信息中心在所有 PA 面板中均未显示数据

版本：1.14.3

症状：对于平台管理员，KUB 信息中心在 Grafana 的所有面板中均不显示数据。

解决方法：暂停 KSM 子组件并更新 monitoringtarget 和 metricsproxysidecar：

  1. 暂停子组件：

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

    替换以下内容：

    • ORG_NAME：组织的名称
    • ROOT_ADMIN_KUBECONFIG：root-admin kubeconfig 的路径

  2. 在 .spec.destinations 部分中，向 mon-kube-state-metrics-metrics-proxy metricsproxysidecar 添加以下内容：

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

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

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

  3. 从 mon-pa-kube-state-metrics monitoringtarget spec 中移除 matchClusters: 部分。更新后的 mon-pa-kube-state-metrics monitoringtarget spec 可能如下所示：

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

针对 observability-admin-debugger 角色的权限配置错误

版本：1.14.3、1.14.4

症状：IO 无法重启 mon-system 命名空间中的 Cortex 或 Prometheus pod。

解决方法：

对于组织：

  1. 暂停 iam-common 子组件。

  2. 将 observability-admin-debugger/iam-system roleTemplate 更新为以下内容：

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

对于根管理员：

  1. 暂停 iam-common 子组件。

  2. 将 observability-admin-debugger-root/iam-system roleTemplate 更新为以下内容：

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

缺少 Grafana 调试器角色

版本：1.14.3、1.14.4

症状：可观测性影子项目命名空间 (*-obs-system) 中不存在 grafana-debugger-cp 角色。无法向用户授予调试 Grafana 相关问题所需的正确权限集。

解决方法：在 infra-cp 中创建以下 ClusterRoleTemplate 自定义资源，并使用创建的相应 ClusterRole 来获取 grafana-debugger 权限。

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

添加新可用区后，无法查看跨可用区的指标和日志

版本：1.14.*

症状：Grafana 信息中心不显示新添加的可用区的日志和指标。

解决方法 1：重启 datasource-proxy 部署：

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

这将重启 datasource-proxy pod，并更新新添加的可用区的跨可用区端点配置。

MonitoringTarget 终结器会阻止命名空间删除

版本：1.14.3、1.14.4

症状：命名空间未被删除，相应组织中存在不健康的集群。

临时解决方法：从阻止命名空间删除的 MonitoringTarget 自定义资源中手动移除终结器。

由于信息中心和数据源的终结器处于待处理状态，项目删除操作卡住

版本：1.14.3、1.14.4

修复版本：1.14.3 hotfix 22

症状：项目未被删除，终止命名空间出现类似于以下示例的错误：

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

解决方法：手动删除信息中心和数据源最终确定器。

来自 KSM 的指标不可见

版本：1.14.3

修复版本：1.14.3 hotfix 22

症状：KUB 信息中心在所有面板中显示 No Data。

解决方法：暂停 KSM 子组件，并更新 monitoringtarget 和 metricsproxysidecar。

  1. 暂停子组件：

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

    替换以下内容：

    • ORG_NAME：组织的名称。
    • ROOT_ADMIN_KUBECONFIG：根管理员 kubeconfig 的路径。

  2. 将以下内容添加到 .spec.destinations 中 mon-kube-state-metrics-metrics-proxy metricsproxysidecar：

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

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

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

  3. 从 mon-pa-kube-state-metrics monitoringtarget 规范中移除 matchClusters: 部分。更新后的 mon-pa-kube-state-metrics monitoringtarget 规范如下所示：

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

系统指标流水线已停止运行

版本：1.14.3

症状：即使按照 MON-R0001 运行手册操作，MON-A0001 提醒仍处于有效状态。

临时解决方法：

  1. 如果管理员集群中出现此问题，请使用 IAC-R0004 运行手册在 root-admin 中创建以下 SubcomponentOverride。对于其他集群（例如用户集群、外围集群或共享集群），请在 ${ORG}-mp 中创建 SubcomponentOverride。

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

  2. 找到正确的 NAMESPACE：

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

    输出如下所示：

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

    如果流水线因 root-admin 而停用，则命名空间为根；如果流水线因 org-1 admin 而停用，则命名空间为 org-1：

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

    输出如下所示：

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

    在此示例中，正确的命名空间可能是 g-org-1-perimeter-cluster、g-org-1-shared-service-cluster、user-vm-1-cluster 或 user-vm-2-cluster，具体取决于哪个集群的系统指标流水线出现故障。

  3. 应用 SubcomponentOverride 后，在相应集群中重启 cortex-tenant 部署。 检查相应集群中的值是否已更新：

    kubectl --kubeconfig ${KUBECONFIG:?} get configmap cortex-tenant-config -n mon-system -o yaml

  4. 更新了并发字段。

  5. 重启 cortex-tenant 部署：

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

多租户

控制台未显示节点池创建失败

版本：1.14.4、1.14.5、1.14.6

已修复：1.14.7

症状：在 GDC 控制台中，当创建节点池失败时，界面会错误地显示 creation in progress 消息，表明节点池已成功创建。

解决方法：使用 gdcloud CLI 验证节点池创建。

多可用区

无法访问的区域重定向到身份验证页面

版本：1.14.x

症状：当某个可用区无法访问时，GDC 控制台会重定向到显示身份验证错误的页面。不过，可用区无法访问可能不是身份验证问题造成的，而是可用区中断造成的。

解决方法：使用地区性网址来解决此问题。如果区域网址也无法正常运行，请让您的基础设施运营商 (IO) 诊断您遇到身份验证问题的区域是否已关闭。

使用 gdcloud CLI 查看可用区的角色未应用

版本：1.14.x

症状：使用 gdcloud zones list 命令所需的 IAM 角色默认情况下不会应用于 GDC universe。缺少的角色（无法作为预定义角色提供）会阻止使用 gcloud CLI 列出可用区。

解决方法：将 IAM 角色 global-zone-viewer 和角色绑定资源应用于全局 API 服务器：

  1. 创建一个角色 YAML 文件（例如 global-zone-viewer.yaml），其中包含以下内容：

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

  2. 将 YAML 文件应用于组织的全局 API 服务器：

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

此角色绑定会验证系统中的所有用户，以使用 gdcloud zones list 查看区域。

间歇性全局控制台网址登录错误

版本：1.14.x

症状：使用全局网址登录 GDC 控制台时，您可能会收到错误消息，指出您的会话不再有效。此错误可能是由底层网络 bug 引起的，并不能准确反映您的会话状态。

解决方法：使用地区级网址登录 GDC 控制台，以便在每个地区内管理全球资源。如需详细了解如何从 GDC 控制台切换地区上下文，请参阅跨地区管理资源。

网络

调整 MultiZoneNetworkConfig 地区顺序会导致配置替换失败

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

症状：

  1. 架顶式 (ToR) 交换机的 READY 状态为 False。您可以通过运行以下命令来确认这一点：

    kubectl get torswitches -A

  2. 交换机配置替换失败，并显示一条错误消息，指出相应条目已存在。这可在交换机配置替换日志中看到。错误消息类似于以下内容：

    % Insertion failed - entry already exists

此问题是由调整 MultiZoneNetworkConfig 内的区域顺序引起的。系统会根据配置列表中每个区域的位置为 BGP 访问控制列表规则生成序列号。如果更改了区域的顺序，系统会生成具有不同序列号的新规则，这些规则会与交换机上已有的规则发生冲突。

解决方法：

如需解决此问题，请从每个受影响的 ToR 交换机中手动移除冲突的 BGP AS-path 访问控制列表配置。这样一来，系统就可以协调并应用正确的配置。

  1. 与每个不处于 Ready 状态的 ToR 交换机建立 SSH 连接。

  2. 进入全局配置模式：

    config t

  3. 移除冲突的访问权限列表配置：

    no ip as-path access-list other-zones

  4. 退出配置模式。

在所有受影响的交换机上执行此命令后，协调器将应用正确的配置，并且交换机将转换为 READY 状态。

配置替换提交过期时间

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

症状：

配置网络交换机时，如果访问控制列表 (ACL) 数量过多，会导致超时。BorderLeafSwitch 自定义资源未处于 Ready 状态，并且在与未就绪的交换机建立 SSH 连接时，会看到 Commit expiry 状态。

例如，以下命令会显示状态：

sh config-replace log verify

输出类似于以下内容：

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

解决方法：

在 1.14.3 或 1.14.7 及更高版本中，修改 root 命名空间中名为 pnet-core-override 的 SubcomponentOverride 自定义资源，并向 .spec.operableParameters.netDevGW 添加 httpTimeout 字段。

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

等待 15 分钟，以便自动化基础架构将新配置推送到交换机。根据需要配置 httpTimeout，直到 Commit expiry 消息消失。

在 1.14.4、1.14.5 和 1.14.6 版本中，手动执行 config-replace 并提交更改。

  1. 暂停切换：

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

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

  2. 按照 PNET-P0001 运行手册获取交换机访问权限。

  3. 找到要替换的配置：

    switch-cli# dir | grep new_config

  4. 完成 config-replace：

    switch-cli# configure replace <new_config_file>

    此过程可能需要 5 分钟以上。

  5. 配置替换成功后，提交更改：

    switch-cli# configure replace commit

  6. 取消暂停切换：

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

使用 4 字节 BGP ASN 进行部署时失败

版本：1.14.3、1.14.4

症状：在网络交换机上配置具有 4 字节自治系统编号 (ASN) 的边界网关协议 (BGP) 会导致配置失败。如果未正确应用 BGP 配置，相应 GDC 区域内的网络可能无法建立适当的路由，从而导致连接问题、无法通告路由或一般网络不稳定。目前没有解决方法。

全球任播流量被屏蔽

版本：1.14.3

症状：访问控制列表 (ACL) 阻止了流向全局任播端点的流量。

临时解决方法：

如需解决访问控制列表 (ACL) 阻止全局任播流量的问题，您需要在根管理员集群中创建 SubcomponentOverride 自定义资源，以明确允许流量流向全局 DNS 服务器的任播 CIDR 块。请按照以下步骤操作：

  1. 查找所有全局任播 CIDR 地址块。如需查找要更新的全局任播 CIDR 地址块，请按以下步骤操作：

    1. 连接到根全局 API 服务器。

    2. 使用以下命令列出所有命名空间中的所有子网自定义资源：

      kubectl get subnet -A

    3. 过滤输出，以查找 metadata.name 过滤条件包含关键字 anycast 的子网资源。

    4. 对于名称中包含 anycast 的每个子网资源，请记下 spec.subnet 的值。此值表示全球任播 CIDR 块。

  2. 在根管理员集群中，在根命名空间中创建一个名为 pnet-trafficpolicy-dc-override 的 SubcomponentOverride 自定义资源。对于您在上一步中确定的每个任播子网，请添加规则，如 YAML 文件中所示：

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

    替换以下内容：

    • INTERCONNECT_RULE_DESCRIPTION：互连网络规则的描述性文本。
    • GLOBAL_ANYCAST_CIDR：全局任播 CIDR 地址块，例如 136.125.38.128/28。针对您在上一步中找到的每个任播，使用此 YAML 文件创建规则。
    • HAIRPIN_RULE_DESCRIPTION：发夹网络规则的描述性文本。

部分 DCI 故障会导致流量丢失

版本：1.14.3

症状：当连接某个可用区的边界 leaf 交换机与运营商交换机的两个数据中心互联 (DCI) 链路都出现故障，或者当某个可用区的边界 leaf 交换机发生硬件故障时，大约 50% 的跨可用区网络流量会丢失。

VRF 名称过长

版本：1.14.2

症状：运行此命令时，您可能会看到类似以下示例的消息，表明交换机不正常：

sh config-replace log verify

输出可能如下例所示：

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

解决方法：组织 CR 的名称最多可以包含 19 个字符。

StatefulSet pod 通信失败

版本：1.14.3、1.14.4

已修复：1.14.3 热修复 23、1.14.5

症状：由于在 StatefulSet pod 重新启动后，未正确处理 Cilium 端点 (CEP) 对象的删除，导致连接问题或中断。这可能会导致非受管端点身份，从而导致网络政策错误地丢弃合法流量。您可以通过检查相应 CEP 对象是否缺失来验证受影响的 pod：

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

解决方法：重启受影响的 StatefulSet pod 以更新其 UID 并刷新关联的元数据：

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

节点在数据网络上无法访问

这是一个罕见的问题，如果 anetd pod 陷入崩溃循环，可能会发生此问题。

对节点连接至关重要的内核资源可能会卡在损坏状态。

本指南概述了此问题的症状，以及可用于解决此问题的步骤。

版本：

所有版本的 Google Distributed Cloud (GDC) 网闸隔离版都可能会受到影响。

症状：

如果出现此问题，您可能会看到以下症状：

  • 节点卡在 NotReady 状态
  • 描述节点时显示消息 kubelet:kubelet was found unhealthy; repair flag : true
  • 无法在数据网络上通过 SSH 访问节点

临时解决方法：

请按照以下说明修复每个健康状况不佳的节点：

  1. 获取受影响节点的管理 IP 地址：

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

  2. 获取对受影响节点的 SSH 访问权限。

  3. 使用节点的管理 IP 地址通过 SSH 连接到该节点。

  4. 在节点上，运行以下命令，然后关闭 SSH 连接：

    tc filter del dev bond0 egress

  5. 重启受影响节点所在集群的 anetd daemonset：

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

创建允许所有出站流量的 PNP 会拒绝意外流量

版本：

所有版本的 Google Distributed Cloud (GDC) 网闸隔离版都可能会受到影响。

症状：allow-all-egress 项目网络政策 (PNP) 允许流量流向项目内的端点和集群外的外部端点，但不允许流量流向系统端点。此问题可能会导致系统和第一方服务访问权限被阻止，例如 DNS 解析和对象存储。

allow-all-egress PNP 可能如下所示：

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-all-egress
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - {}

解决方法：删除 allow-all-egress PNP。默认情况下，一旦停用数据渗漏防护，流量便可流向集群和系统端点之外的项目和外部端点。

kubectl delete pnp  [*ALLOW_ALL_EGRESS_PNP_NAME*] -n [*NAMESPACE*]

多可用区跨可用区可用性 SLO Grafana 信息中心问题

版本：1.14.3

症状：在 Grafana 中，pnet-cross-zone-availability SLO 信息中心不显示任何指标。

解决方法：按照 PNET-P0001 运行手册获取交换机访问权限，并手动检查多区域 BGP 会话和连接状态。

数据平面和管理入站网关无法协调一致

版本：1.14.3

症状：子组件 asm-dataplane-ingress 或 asm-management-ingress 无法协调，并显示以下错误：

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

错误字符串中可能出现的值（而非 BackendService）包括 ForwardingRuleInternal 和 ForwardingRuleExternal。同样，资源名称可能是 dataplane-ingress-gateway、dataplane-ingress-gateway-global 或 management-ingress-gateway-global，而不是 management-ingress-gateway。

解决方法：确定资源是否存在于管理 API 服务器或全局 API 服务器中。可以从错误字符串中的资源类型的 API 版本推断出来。例如，带有后缀 networking.gdc.goog 的资源存在于管理 API 服务器中，而带有后缀 networking.global.gdc.goog 的资源存在于全局 API 服务器中。

确定 API 服务器后，使用相应的 kubeconfig 文件删除资源。例如：

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

项目网络政策页面不支持 ProjectNetworkPolicy API 中的项目选择器字段

版本：1.14.3、1.14.4

症状：当您创建包含 projectSelector 字段的项目网络政策并在 GDC 控制台中查看该政策时，界面会显示为该政策选择的所有项目，而不是 projectSelector 字段中的项目。

解决方法：使用 API 创建和读取包含 projectSelector 字段的项目网络政策。

操作系统

服务器配置失败

版本：1.14.3

症状：在服务器预配期间，从 Harbor 注册表中下载操作系统映像时，相应的 BaremetalHost 自定义资源上可能会显示以下 401 错误，并且服务器会陷入取消预配和重新预配的循环中。

如需检查是否存在这些错误，请描述 BaremetalHost 自定义资源：

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

输出可能如下例所示：

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

解决方法：

  1. 获取服务器所属的 nodePoolClaim 的名称和命名空间：

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

    输出可能如下例所示：

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

  2. 从 NodePoolClaim 获取操作系统映像名称：

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

  3. 从 OSImageMetadata 获取操作系统映像网址：

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

  4. 使用最新的操作系统映像网址更新 Server 自定义资源：

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

OS NodeUpgrade 可能会卡在 NodeOSInPlaceUpgradePostProcessingCompleted 步骤

版本：1.14.3、1.14.4

症状：

在节点升级期间，NodeUpgradeTask 卡在 NodeOSInPlaceUpgradePostProcessingCompleted 步骤，出现 Reconciler 错误，消息为 failed verifying delta after upgrade，无法完成升级。 此错误表示升级验证流程在节点上发现了意外的软件包差异。具体而言，它会识别仍处于“需要升级”状态的软件包，或在升级尝试后显示为“仅在新版本中”的软件包。

错误消息会列出未能通过验证的具体软件包。代码段示例：

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

此症状可能是由以下两个问题引起的。首先检测哪个问题是原因：

  1. Cause-A：机器无法访问，导致 OSArtifactSnapShot 过时。

    检查正在升级的节点是否仍处于健康状态，以及相应的 OSArtifactSnapShot 作业是否失败。

    如果 OSArtifactSnapShot 过期，且设备无法访问的时间超过 20 分钟，请继续执行 Mitigation-A。否则，继续检查 Cause-B。

  2. Cause-B：静默 RPM 升级失败

    在极少数情况下，机器上的 RPM 升级可能会在部分升级后静默失败。应该有两个 ConfigMap，分别包含升级前后的软件包差异：

    in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-before-upgrade
in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-after-upgrade

    如果“升级后”的软件包数量少于“升级前”的 configmap，则表示升级已静默中止，并非所有软件包都已升级。前往 Mitigation-B。

解决方法：

Mitigation-A：修复无法访问的机器

尝试通过重启机器来修复问题。如果尝试重启后，机器仍无法访问，请与 SERV 团队联系以获取进一步的帮助。 在机器恢复可访问状态后，删除 OSArtifactSnapShot 以强制协调。OSArtifactSnapShot 协调一致后，NodeUpgradeTask 应继续执行下一步。

Mitigation-B：重试 NodeUpgradeTask

  1. 通过 SSH 连接到正在升级的机器，并收集以下日志以供日后排查问题。 应收集以下文件：

    • /var/log/dnf.log
    • /var/log/dnf.rpm.log
    • dnf 历史记录 > dnf_history.log
    • rpm -qa --last > rpm_last.log

  2. 删除失败的 NodeUpgradeTask。这将触发对特定节点上的 NodeUpgradeTask 进行重试。新的 NodeUpgradeTask 应该完成 RPM 升级并继续执行下一步。

OS NodeUpgrade 可能会卡在软件包服务器创建步骤

版本：1.14.3、1.14.4

症状：

当 NodeUpgrade CR 被创建并取消暂停，且在 in-progress 状态下停留超过 30 分钟时，它可能会在软件包服务器创建阶段静默失败。症状是 NodeUpgrade 停留在 .status.upgradeStatus=in-progress 状态，但没有加载 .status.tasks：

status:
  duration: 0s
  upgradeStatus: in-progress

如需进一步确认此问题在软件包服务器创建时失败，请读取操作系统升级控制器日志：

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

如果控制器日志显示 failed to create package server 和 failed to create package repo server DNS registration 以及详细原因（以下任一原因）

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

然后，它会建议其他 NodeUpgrade 使用的某些其他软件包服务器资源仍然处于活动状态，并与当前挂起的 NodeUpgrade 的待创建资源发生冲突。

解决方法：

如需进一步确认，您可以检查实际的软件包服务器资源（例如管理 NodeUpgrade CR 的集群的管理 API 服务器中的 dnsregistration.network.private.gdc.goog 等特定 API），并找到拥有这些资源的 NodeUpgrade。如果拥有 DNSRegistration 的 NodeUpgrade 已完成，但 DNSRegistration 资源仍未被删除，那么您可以删除 DNSRegistration 对象，前提是其所有引用的 NodeUpgrade 对象都已完成。

  1. 列出 NodeUpgrade 软件包服务器的所有 DNSRegistration CR：

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

  2. 查询特定 DNSRegistration 的所有者 NodeUpgrade CR：

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

节点操作系统升级可能会遇到问题，并在流程的任何阶段停止

版本：1.14.4、1.14.5、1.14.6

症状：

NodeUpgradeTask CR 仍低于 in-progress 超过 2 小时，但如果时间足够长，可能能够自动完成。

NodeUpgradeTask CR 正在进行中，已超过两小时。虽然它最终可能会自动完成，但根本问题在于 os-policy-reconciler 无法高效管理大量 OSPolicy CR。此问题发生在 NodeOSInPlaceUpgradeCompleted 步骤中。

如需进一步确认软件包服务器创建期间的此失败，请参阅操作系统升级控制器日志。

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

如果控制器日志中缺少来自 NodeUpgradeTask 的 OSPolicy 条目，则表明控制器过载。

解决方法：

在升级过程中，暂停所有非必需的 OSPolicy CR。

大型文件的“storage cp”导致组织管理 kube-api 崩溃

版本：1.14.3 及更高版本

症状：在 OIC 工作站执行 gdcloud storage cp 操作或 gdcloud system container-registry load-oci 操作期间，可能会丢失对组织基础架构的访问权限，随后 org-mgmt 的 kube-api 出现故障。这是一个罕见的问题，收集数据有助于工程团队解决问题。

解决方法：如果出现此问题，请尝试以下步骤：

  1. 对于每个控制平面 (CP) 节点，运行 uptime 以查看节点是否在过去 24 小时内重启过。
  2. 记下重新启动的时间。
  3. 运行 dmesg | grep -i 'kernel panic'，检查每个 CP 节点在重新启动之前是否发生了内核崩溃。
  4. 在每个 CP 节点上，运行以下命令检查是否安装了 Mellanox 网卡：lspci | grep -i eth | grep -i mellanox。如果没有 Mellanox 网卡，请停止阅读此已知问题。

  5. 在每个 CP 节点上，检查 data0 上的以下网络设置：

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

    如果所有节点上的 rx-gro-hw（见上文）均设置为“off”，则无需再阅读此已知问题。

  6. 收集一些信息，以便 Google 帮助诊断问题：

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

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

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

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

  7. 在每个 CP 节点上，运行以下命令：

    dmesg | grep -i 'kernel panic'

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

systemctl status disable-rx-gro-hw

modinfo mlx5_core | grep ^version:

  8. 为了缓解网络设置问题，必须通过在所有 CP 节点上运行以下命令将 rx-gro-hw 设置为 off：

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

  9. 再次检查设置：

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

  10. 重试原始操作，例如 gdcloud storage cp 或 gdcloud system container-registry load-oci。如果仍出现故障，请联系工程团队。

Operations Suite Infrastructure Core Services (OIC)

跳转主机性能不佳

版本：所有版本的 Google Distributed Cloud (GDC) 网闸隔离版都可能受到影响。

症状：浏览器或系统操作需要过长的时间才能完成。

解决方法：

通过 BM03 和 BM04 上的 Hyper-V 管理器增加跳转主机上的 vCPU 数量：

  1. 选择跳转主机虚拟机，然后点击操作窗格中的设置。
  2. 选择处理器，然后根据工作负载将虚拟处理器数量增加到 4 个或更多。
  3. 对剩余的跳转主机重复上述操作。

资源管理器

无法在 GDC 控制台中删除项目

版本：1.14.3、1.14.4

症状：GDC 控制台在项目详情页面中为现有项目提供了删除 删除按钮，但该按钮无法正常使用。

解决方法：如需删除现有项目，您必须使用 gdcloud CLI。如需了解详情，请参阅删除项目。

缺少组织 Ansible playbook

版本：1.14.3

症状：创建组织时，创建必需的 Ansible playbook 的作业 create-ansible-playbooks 会静默失败。缺少 Ansible playbook 会导致一些问题，例如缺少外围虚拟机以及无法创建全球组织。

解决方法：按照 OS-R0009 runbook 手动创建缺少的组织 Ansible playbook。

非对称全局组织显示不存在的区域配置

版本：1.14.4

症状：创建仅包含部分可用区组织配置的 v1 全球组织时，所有可用区仍会显示组织副本状态。例如，如果您有一个包含三个可用区的 GDC 宇宙，但仅为两个可用区创建了可用区级组织配置，则第三个可用区仍会针对不存在的第三个可用区级组织显示错误的副本状态。

如需确认错误状态，请打印全局组织的状态：

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

YAML 输出类似于以下内容：

...

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

...

请注意，这种情况仅适用于 v1 组织，因为 v2 组织不支持非对称的可用区配置。

解决方法：您可以忽略错误的副本状态，因为除非您专门创建了可用区组织，否则它不会存在。

集群

基础架构集群工作器节点池未被删除

版本：1.14.3、1.14.4

症状：从 Organization CR 规范中移除工作器节点池时，该节点池不会自动删除，也就是说，kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} 命令仍会输出要删除的节点池。

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

解决方法：从 Organization CR 规范中移除工作器节点池后，通过运行以下命令，从根管理员集群中手动删除相应节点池的 NodePoolClaim CR：sh kubectl delete nodepoolclaim data-plane-pool-{machine-class} -n {org-name}

等待 NodePoolClaim 及其关联的 NodePool CR 完全删除，即 kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} 命令不再输出工作器节点池。

存储

使用 gdcloud config set zone 命令创建的存储分区无法删除

版本：1.14.7 及更高版本

症状：使用 gdcloud config set zone 命令创建的存储分区因权限问题而无法删除，因为该命令尝试在错误的区域中运行。

解决方法：使用控制台为存储桶设置特定可用区，或者在 gcloud 命令中将 --zone 标志替换为 --location。

正在触发 OBJ SLO 提醒

版本：1.14.3、1.14.4

症状：由于 OBJ 代理中的 ErrFailedStreamingDecryptRequest 错误，OBJ 的 SLO 提醒正在触发：obj-list-object-ops-availability-slo、obj-rw-object-ops-error-rate-slo。

解决方法：将提醒设为静音。当错误是由用户终止连接（不计入 SLO）引起的时，系统会错误地将其识别为系统错误。

S3 UploadPart 空 ETag

版本：1.14.3

症状：发送 UploadPart 请求后，您会在响应消息中获得 200 Success 状态代码，但 ETag 字段为空。发生此错误的原因是，网络中断导致出现 InternalServerError，但状态代码未更新为 500 InternalServerError。

解决方法：重试请求，就像之前失败一样。

由于 Trident mkfs.ext4 错误，Pod 无法装载

版本：1.14.3

症状：尝试装载 Pod 后，您发现正在向特定节点转换或从特定节点转换的所有 Pod 均失败。系统会显示 rpc 错误消息：DeadlineExceeded desc = context deadline exceeded，表明节点卡住了。出现此消息时，您将无法对相关节点执行其他 Trident 操作。提供数据的卷不受影响，但移入和移出节点的数据卷可能会发生中断。

解决方法：

  1. 检查 pod 尝试挂载的节点上的 Trident 日志，并验证队列是否在增加。日志可能如下所示：

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

  2. 登录节点并查看 dmesg 输出。日志可能如下所示：

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

  3. 确认您遇到的是 Trident mkfs.ext4 错误后，请重新启动节点。

Trident 因已存在的错误而无法创建卷

版本：1.14.3

症状：

PVC 未预配，并显示类似如下的事件：

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

发生此事件时，在您执行解决方法之前，系统不会预配 PVC。

解决方法：

请按以下步骤操作以解决此问题：

  1. 记下事件中的内部音量名称。例如，症状部分中显示的示例事件显示了内部卷名称 trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a。
  2. 按照 FILE-R0105 运行手册访问 ONTAP。

  3. 删除卷：

    volume delete trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a

file_block_iscsi_sessions_unhealthy alert 报告假正例

版本：1.14.3

症状：在某些环境中，系统会触发 file_block_iscsi_sessions_unhealthy 提醒，表明一个或多个节点正在经历 iSCSI 故障。file-observability 控制器使用自定义指标收集器来跟踪每个 Kubernetes 节点上 iSCSI 会话的健康状况，但在某些情况下，指标收集器无法解析 iscsiadm 命令的输出，即使 iSCSI 具有健康的会话，也会报告零个正在运行的 iSCSI 会话。

解决方法：

请按照以下步骤验证 iSCSI 是否未遇到问题，如果提醒实际上是误报，请将提醒静音：

  1. 在 Grafana 的探索页面中，运行查询 fb_sessions_running_count{job="file-observability-backend-target.file-system"}。该查询会针对集群中的每个节点返回一个指标。如果有任何节点报告 0 的 fb_sessions_running_count 指标，请记下该节点的名称。

  2. 对于每个 fb_sessions_running_count 指标返回 0 的节点，请执行以下命令：

    1. 与受影响的节点建立 SSH 连接。

    2. 运行 iscsiadm -m session 命令。您必须看到返回了多行。每行都代表一个正在运行的 iSCSI 会话。如果该命令未返回任何内容或输出中存在错误，请将问题上报给文件屏蔽工程团队。

    3. 如果上一个命令成功返回 iSCSI 会话，则表示您已确认相应节点的提醒为假正例。

  3. 当您确认所有受影响的节点都具有正常的 iSCSI 会话，并且导致系统错误地触发了提醒时，请在 AlertManager 中创建静默规则，以使 file_block_iscsi_sessions_unhealthy 提醒静默。

针对备用磁盘触发 file_block_storage_disk_failure 提醒

版本：1.14.3

症状：在某些环境中，系统会触发 file_block_storage_disk_failure 提醒，表明 ONTAP 中的一个或多个磁盘处于不健康状态。file-observability 控制器使用自定义指标收集器来跟踪 ONTAP 中每个磁盘的健康状况，但在较早版本的 GDC 中，该收集器不会将备用磁盘视为健康磁盘，并且会针对备用磁盘触发提醒。

解决方法：

请按照以下步骤验证磁盘是否为备用磁盘，并针对该磁盘停用提醒：

  1. 在 Grafana 的探索页面中，运行查询 disks_labels_healthy{job="file-observability-backend-target.file-system"}。该查询将返回 ONTAP 中每个磁盘的指标。如果任何磁盘报告的指标为 0（不健康），请记下该磁盘的名称。

  2. 对于每个 disks_labels_healthy 指标返回 0 的磁盘，请执行以下命令：

    1. 通过 SSH 连接到 ONTAP 集群，然后使用从指标查询中收集的磁盘名称运行命令 disk show -disk <disk-name> -fields state。

    2. 验证命令的输出是否表明磁盘状态为 present 或 spare。如果磁盘处于 present 或 spare 以外的任何其他状态，请将问题上报给文件块工程团队。

    3. 如果相关磁盘报告 present 或 spare，我们可以确认不应针对此磁盘触发提醒。在 AlertManager 中创建一个静音，以使 file_block_storage_disk_failure 提醒静音，并将 disk_name 标签设置为磁盘的名称。

  3. 为所有备用磁盘创建静默后，前往 Grafana 验证提醒是否已停止触发。

连接恢复后，系统会触发 file_block_storage_node_peer_connection_unhealthy 提醒

版本：1.14.3

症状：在某些环境中，系统会触发 file_block_storage_node_peer_connection_unhealthy 提醒，表明 ONTAP 节点之间的一个或多个连接出现故障。file-observability 控制器使用自定义指标收集器来跟踪这些连接的运行状况。存在一个已知问题，即即使在失败的连接恢复后，此提醒仍会继续触发。

解决方法：

请按照以下步骤操作，验证节点之间的连接是否正常，并针对节点关闭提醒：

  1. 在 Grafana 的探索页面中，运行查询 storage_node_peer_connections{job="file-observability-backend-target.file-system"}。该查询会返回集群中存储节点之间每个连接的指标。如果有任何连接报告的 storage_node_peer_connections 指标值为 0，请记下该指标中的 source_node、destination_ip 和 storage_cluster_name 标签。

  2. 对于每个返回 0 的 storage_node_peer_connections 指标，请执行以下命令：

    1. 从 storage_cluster_name 标签页建立与 ONTAP 存储集群的 SSH 连接。

    2. 使用 source_node 和 destination_ip 标签中的值在 ONTAP 集群上运行以下命令：

    ping -node <node-name> -destination <destination-ip> -verbose -show-detail

    如果 ping 命令失败，请将问题上报给文件块工程团队。如果 ping 命令成功，则表明节点连接正常，并且提醒是错误触发的。

    1. 在 AlertManager 中创建静音，以使 file_block_storage_node_peer_connection_unhealthy 提醒静音，并将 source_node 和 destination_ip 标签设置为指标中的源节点和目标 IP。

  3. 为所有运行正常的节点创建静音后，前往 Grafana 验证提醒是否已停止触发。

连接恢复后，触发了 file_block_nodes_not_reachable 提醒

版本：1.14.3

症状：在某些环境中，系统会触发 file_block_nodes_not_reachable 提醒，表明 Kubernetes 节点上 IPsec 服务与 ONTAP 之间的一个或多个连接失败。file-observability 控制器使用自定义指标收集器来跟踪这些连接的运行状况。存在一个已知问题，即即使在失败的连接恢复后，此提醒仍会继续触发。

解决方法：

请按照以下步骤操作，验证节点上的连接是否正常，并针对节点静音提醒：

  1. 在 Grafana 的探索页面中，运行查询 fb_all_nodes_reachable{job="file-observability-backend-target.file-system"}。该查询会针对集群中的每个节点返回一个指标。如果有任何节点报告 0 的 fb_all_nodes_reachable 指标，请记下该节点的名称。

  2. 对于每个 fb_all_nodes_reachable 指标返回 0 的节点，请执行以下命令：

    1. 与受影响的节点建立 SSH 连接。

    2. 运行以下命令：

      journalctl -u strongswan | grep "sending packet" | sed "s/\[/ /g" | sed "s/\]/ /g" | awk '{ print $14 }' | sort -n | uniq | awk '{print "ping -c 5 " $1}' | sh

      该命令将尝试使用所有 IPsec 连接来 ping ontap。如果命令中的任何 ping 失败，请将问题上报给文件屏蔽工程团队。如果 ping 命令成功，则表明节点连接正常，并且提醒是错误触发的。

    3. 如果命令中的所有 ping 都成功，则表明节点上的连接运行正常，并且相应提醒是错误触发的。在 AlertManager 中创建一个静音，以使 file_block_nodes_not_reachable 提醒静音，并将 node_name 标签设置为节点名称。

  3. 为所有运行正常的节点创建静音后，前往 Grafana 验证提醒是否已停止触发。

file_block_storage_high_node_total_latency 警报在工作负载较重时触发

版本：1.14.3

症状：在某些环境中，由于存储节点上的工作负载过重，可能会触发 file_block_storage_high_node_total_latency 提醒。此提醒会一直显示，直到这些工作负载完全处理完毕。即使卷的读取和写入性能很快，存储节点仍可能会报告特定块操作的延迟时间较长。

解决方法：

如需验证卷延迟时间是否正常，并关闭存储节点延迟时间提醒，请按以下步骤操作：

  1. 检查卷延迟时间提醒：

    1. 在 Grafana 中，确认 file_block_storage_high_volume_write_latency 和 file_block_storage_high_volume_read_latency 提醒未触发，并且报告的卷延迟时间为最佳。

  2. 如果卷延迟时间较长，则升级：

    1. 如果卷写入或卷读取提醒触发，则表示整个存储系统的延迟时间较长。将此问题上报给文件屏蔽工程团队。

  3. 将节点延迟时间提醒静音（如果卷健康状况良好）：

    1. 如果卷写入和卷读取提醒均显示正常，则节点延迟时间提醒很可能是误报。

    2. 在 AlertManager 中为 file_block_storage_high_node_total_latency 提醒创建静音。

    3. 创建静音后，前往 Grafana 确认相应提醒已停止触发。

受阻的节点升级

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

症状：当 LUN（逻辑单元号）变为只读时，就会出现此阻塞，这通常是由于快照问题所致。发生这种情况时，节点会被隔离，以便将受影响的 Pod 移至其他节点。由于节点升级过程会进行预检以确保节点未被隔离，因此此状态会阻止升级继续进行。

解决方法：在开始升级流程之前，手动停用 file-read-only-lun-cleanup 子组件：

  1. 确定每个受影响的组织。

  2. 为环境中的每个组织应用 SubcomponentOverride。

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

  3. 验证受影响组织中的所有节点是否都未被隔离：

    1. 列出组织中的节点：

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes

      输出类似于以下内容：

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

      记下状态为 SchedulingDisabled 的节点的名称。 在此示例输出中，被隔离的节点为 admin-node0-zone1。

    2. 取消隔离在上一步中返回状态 SchedulingDisabled 的节点：

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG uncordon NODE_NAME

    3. 验证所有节点是否已准备就绪：

      kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes

      输出类似于以下内容：

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

在多路径错误解决后触发 file_block_zombie_luns_present 提醒

版本：1.14.3 及更高版本

症状：在某些环境中，由于 file-observability 控制器无法解析 multipath -ll 命令的输出，可能会触发 file_block_zombie_luns_present 提醒。在这种情况下，即使多路径服务在所有节点上都处于正常状态，系统也会不断触发僵尸 LUN 提醒。

解决方法：

如需验证相关节点上的多路径服务是否正常运行，请按以下步骤操作：

  1. 在 Grafana 的探索页面中，运行查询 zombie_lun_exists{job="file-observability-backend-target.file-system"}。该查询会针对集群中的每个节点返回一个指标。如果有任何节点报告的 zombie_lun_exists 指标为 1，请记下该节点的名称。

  2. 对于每个 zombie_lun_exists 指标返回 1 的节点，请执行以下命令：

    1. 与受影响的节点建立 SSH 连接。

    2. 运行以下命令：

      multipath -ll

      该命令会返回由多路径服务管理的所有块设备的相关信息。验证所有块设备的状态中都不包含字符串 failed undef unknown 或字符串 failed faulty running。

    3. 如果任何设备包含 failed faulty running 状态，请按照 FILE-R0020 运行手册解决僵尸 LUN 问题。

    4. 如果任何设备包含 failed undef unknown 状态，请按照 FILE-R0021 运行手册解决超级僵尸 LUN 问题。

  3. 如果节点运行正常，请将僵尸 LUN 提醒设为静音：

    1. 如果在任何节点上都未发现无效的块设备，则僵尸 LUN 提醒为误报。

    2. 在 AlertManager 中为 file_block_zombie_luns_present 提醒创建静音。

    3. 创建静默后，前往 ServiceNow 确认相应提醒已停止触发。

无法从控制台中删除空存储桶

版本：1.14.4 及更高版本

症状：在 GDC 控制台中，您无法删除空存储桶。 如果启用了对象版本控制并设置了保留政策，存储桶可能包含删除标记以及对象的其他版本。您可能会看到如下所示的错误：

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

解决方法：使用 gdcloud storage rm -a 命令删除对象（包括删除标记），使存储桶可删除。

系统制品注册表

Harbor 复制作业卡住

版本：1.14.3

症状：Harbor 制品复制作业卡住。此问题会阻止向组织分发制品，并停止创建组织。

解决方法：如需缓解此问题，请按照 SAR-R1010 运行手册中的步骤操作。

在协调 Harbor Robot 账号自定义资源时，未清除临时错误状态

版本：1.14.3

症状：标记为 kind=HarborRobotAccount 和 code=SAR2002 的 CustomResourceErrorStatusAlert 提醒错误地触发。例如，错误提醒的 message 字段设置为“Error getting robot: failed to list robots: 503 Service Unavailable”。

解决方法：请基础设施运营商 (IO) 验证相应提醒是真实问题还是误报，如果是误报，请按照以下说明将相应提醒静音。

当提醒被触发时，请按照运行手册 SAR-E2002 中的步骤操作，以确定并解决提醒的根本原因。

由于此已知问题，即使 Runbook 成功解决了根本原因，提醒也可能会继续错误地触发。持续检查收到提醒的目标 HarborRobotAccount (HRD) 自定义资源 (CR) 对象是否存在错误状态：

  1. 设置所需的环境变量：

    export KUBECONFIG=KUBECONFIG
export HRD_NAME=HRD_NAME
export HRD_NAMESPACE=HRD_NAMESPACE

    替换以下内容：

    • KUBECONFIG：kubeconfig 文件的路径。
    • HRD_NAME：目标 HarborRobotAccount CR 的名称。
    • HRD_NAMESPACE：包含目标 HarborRobotAccount CR 的命名空间。

  2. 检查目标 HarborRobotAccount CR 的错误状态：

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

如果 lastUpdateTime 值表明 errorStatus 字段上次更新时间超过 30 分钟前，则此提醒为误报。如需缓解误报问题，请按照 MON-R2009 运行手册中的说明，在 GDC 经过网闸隔离的实例中禁止提醒。

针对 SAR-R0003 警报的误报

版本：1.14.3 及更高版本

症状：代码为 SAR-R0003、OC 为 SAR 且严重程度为 critical 的提醒错误地触发。

解决方法：按照 MON-R2009 操作手册将提醒设为静音。

工单系统

ServiceNow MID 服务器无法正常启动

版本：1.14.3

已修复：1.14.4

症状：与 Splunk 集成的 ServiceNow MID 服务器在启动时因版本不匹配而无法向 ServiceNow 注册。

解决方法：

  1. 暂停 ts-mid-server 子组件。
KUBECONFIG=ROOT_ADMIN_KUBECONFIG kubectl annotate subcomponent ts-mid-server -n gdchservices lcm.private.gdc.goog/paused=true
  1. 替换 MID 服务器版本字符串。
KUBECONFIG=GDCHSERVICES_ADMIN_KUBECONFIG kubectl set env statefulset/midserver-set -n support MID_CONFIG_mid__pinned__version=washingtondc-12-20-2023__patch5-06-21_06-26-2024_1335

升级

成功升级集群后，共享服务集群注解未更新

版本：1.14.4

症状：升级后，clusters.baremetal.cluster.gke.io 的安全边界和共享服务集群 CR 会反映正确的 GKE 版本。clusters.cluster.gdc.goog CR 仍显示之前的 GKE 版本。

解决方法：将 clusters.baremetal.cluster.gke.io 中的注解 upgrade.gdc.goog/version 更新为与升级后的 GKE 版本对应的新 UserClusterMetadata 名称。

组织管理员节点升级卡住了

版本：1.14.6

已修复：1.14.7

症状：gdchservices 组织的管理员控制平面的节点升级过程卡住了。由于无法与节点建立 SSH 连接，导致节点升级失败，并出现 Connection timed out 错误。

插件升级卡住

版本：1.14.6

已修复：1.14.7

症状：从任何之前的 1.14.x 版本升级到 1.14.6 时，根管理员集群的插件升级会卡住。状态消息可能会指示升级已超出预期时间限制：

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

解决方法：手动更新根管理员 addonset 资源的 spec.addOnSetTemplateRef，以指向新版本的正确模板。

支持报告失败

版本：1.14.3、1.14.4、1.14.5、1.14.6

已修复：1.14.7

症状：当 gdcloud resource-support get-report 命令因权限问题而针对用户集群运行时，该命令会失败。

在完成操作系统节点升级后，虚拟机启动可能会卡住

版本：1.14.6

症状：在从 1.14.3 升级到 1.14.6 的过程中，外围集群或共享服务集群中的虚拟机在操作系统升级后无法启动，并且变得无法访问。

例如，以下命令可确认问题：

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

虚拟机控制台日志输出显示了类似于以下内容的内核崩溃消息：

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

临时解决方法：如需解决此问题，请完成以下步骤：

  1. 设置以下环境变量： 

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

  2. 停止失败的虚拟机：

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

  3. 打开编辑器，将启动磁盘与失败的虚拟机分离：

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

  4. 将启动磁盘替换为虚拟机规范中的占位名称：

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

  5. 创建启动脚本密文：

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

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

  6. 创建辅助虚拟机：

    1. 获取虚拟机启动磁盘的虚拟机映像。映像不得与问题虚拟机节点启动磁盘的操作系统系列相同，因此请使用 grep 查找 Ubuntu 映像：

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

    2. 创建虚拟机启动磁盘和虚拟机。创建新启动磁盘和新虚拟机，并挂接辅助磁盘和用于控制台访问的启动脚本：

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

    3. 验证辅助虚拟机是否正在运行：

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

  7. 控制台连接到辅助虚拟机并重新生成 initramfs：

    1. 从控制台连接到辅助虚拟机：

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

    2. 使用以下凭据：

      username="newuser"

      password="Lime+blaze8legend"

    3. 装载所挂接磁盘的分区：

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

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

    4. 建立与装载点的 chroot 连接，并重新生成 initramfs：

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

    5. 验证是否已为新内核版本 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 生成新的 initramfs：

      ls /boot/initramfs-* -l

      输出类似于以下内容：

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

  8. 停止辅助虚拟机：

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

  9. 从辅助虚拟机分离磁盘：

    1. 在编辑器中打开辅助虚拟机规范：

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

    2. 从 YAML 文件中移除以下代码：

      - virtualMachineDiskRef:
    name: PROBLEM_VM_BOOT_DISK
  autoDelete: false

  10. 将启动磁盘重新挂接到发生故障的虚拟机：

    1. 在编辑器中打开失败虚拟机的规范：

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

    2. 按如下所示更新规范：

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

  11. 启动失败的虚拟机：

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

  12. 验证升级是否已修复：

    1. 检查此虚拟机的 Node 自定义资源是否显示 Ready 并使用较新的内核版本 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64：

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

      输出类似于以下内容：

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

    2. 在与虚拟机建立 SSH 连接后，检查内核版本：

      uname -a

      输出必须显示新内核版本 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64。

升级后，Ingester 仍处于不健康状态，且不会自动被遗忘

版本：1.14.x

症状：升级后，log-infra 子组件未处于健康状态。如需进行检查，请运行： none kubectl --kubeconfig ${KUBECONFIG:?} get subcomponent -n ${CLUSTER_NAMESPACE:?} log-infra 如需检查子组件的健康状况，您需要使用父集群的 kubeconfig 作为 KUBECONFIG，并使用当前集群的命名空间作为 CLUSTER_NAMESPACE。该命令将返回子组件的 STATUS。如果 STATUS 不是 ReconciliationCompleted，则表示相应子组件在该集群中处于不健康状态。

集群中的某些 Loki pod 健康状况不佳。如需列出所有 Loki pod，请运行以下命令： none kubectl --kubeconfig ${KUBECONFIG:?} get pods -n obs-system | awk 'NR==1 || /loki/' 此命令会显示所有 Loki pod，包括其 STATUS 和 READY 列。如果 pod 的 STATUS 不是 Running，或者其部分容器未就绪，则该 pod 会被视为不健康。格式为 a/b 的 READY 列表示总共 b 个容器中有 a 个容器已就绪。当 a 和 b 相等时，Pod 的健康状况良好。

检查不健康的 Loki pod 的日志： none kubectl --kubeconfig ${KUBECONFIG:?} logs <pod-name> -n obs-system

来自不健康 pod 的示例输出日志如下所示：

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

解决方法：如需从 Loki 环中删除运行状况不佳的 Ingester，请参阅 runbook AL-R0031。

Vertex AI

翻译请求可能会生成 RESOURCE_EXHAUSTED 错误代码

版本：1.14.3

症状：发送翻译请求后，您会在响应消息中收到 RESOURCE_EXHAUSTED 错误代码。当您超出系统频率限制时，会发生此错误。资源已用尽，例如每用户配额不足、每秒查询次数达到上限，或者整个文件系统的存储空间已用完。

解决方法：请您的基础架构运维者 (IO) 重启翻译服务后端分片。然后，再次发送翻译请求，但请求之间的时间间隔要更长，或者发送的请求要更短。

batchTranslateDocument 请求返回错误 503

版本：1.14.3

症状：发送 batchTranslateDocument 请求后，您会在响应消息中收到 503 "Batch Document translation is not implemented" 错误代码。出现此错误的原因是，BatchTranslateDocument 方法需要 Aspose 服务，而该服务仅在集群中将 enableRAG 可操作参数设置为 true 时部署。

解决方法：请您的基础设施运维人员 (IO) 按照以下步骤在组织管理员集群中将 enableRAG 可操作参数设置为 true：

  1. 在名为 vai-translation.yaml 的 YAML 文件中创建一个 SubcomponentOverride 自定义资源，并将 enableRAG 可操作参数设置为 true：

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

    将 SHARED_SERVICE_CLUSTER_NAMESPACE 替换为共享服务集群的命名空间。

  2. 将 SubcomponentOverride 自定义资源应用到组织管理员集群：

    kubectl --kubeconfig ORG_MGMT_KUBECONFIG apply -f vai-translation.yaml

    将 ORG_MGMT_KUBECONFIG 替换为组织管理员集群中管理 kubeconfig 文件的路径。

翻译或 OCR 前端 pod 和服务无法初始化。

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

症状：在升级期间，数据库集群会被重新创建，这会导致共享服务集群上的 ODS 密钥库密钥过时且不同步。因此，翻译或 OCR 前端 pod 和服务无法初始化。

解决方法：

删除共享服务集群中的 Secret：

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

将 SHARED_SERVICE_CLUSTER_KUBECONFIG 替换为共享服务集群中 kubeconfig 文件的路径。

如果问题服务是翻译，请将 VAI_API_NAMESPACE 替换为“g-vai-translation-sie”；如果问题服务是 OCR，请将 VAI_API_NAMESPACE 替换为“g-vai-ocr-sie”。

控制器会自动重新创建 Secret 并将其与数据库集群重新同步。

Vertex AI Search

搜索组件卡滞在协调状态

版本：1.14.6

症状：如果组织中未创建 SearchConfig 自定义资源，vaisearch-conversation 和 vaisearch-frontend 子组件会卡在 Reconciling 状态。

解决方法：您可以忽略此问题。创建 SearchConfig 自定义资源后，子组件应完成其协调。

服务器

BIOS 凭证轮替卡在“重置请求”阶段

版本：1.14.4

症状：BIOS 凭据轮替卡在重置请求状态。您可以通过检查服务器的 bios-credentials Secret 的 gdch.cluster.gke.io/rotation-status 注解来验证这一点：

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

将 SERVER_NAME 替换为服务器的名称。如果轮换卡住，该命令的输出将为“reset-requested”。

解决方法：如需完成 BIOS 凭据轮换，请按照 SERV-R0018 运行手册操作。

之前安装的服务器无法配置

版本：1.14.6

症状：服务器在取消配置并重新配置后无法完成配置，具体与 iLO（集成 Lights-Out）和 HSM（硬件安全模块）密钥管理方面的问题有关。之前属于已停用组织的服务器在映像配置期间遇到错误，表明无法找到合适的设备，这通常是由于旧密钥或已删除密钥导致磁盘锁定。您可能会看到如下错误：

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

解决方法：删除并重新安装受影响的服务器，以帮助服务器进入已配置状态。如需了解详情，请参阅 SERV-R0020 和 SERV-R0021 运行手册。

虚拟机

映像导入失败

版本：1.14.4。1.14.5

已修复：1.14.6

症状：使用 gdcloud compute images import 命令导入映像失败，并显示 Unauthorized 错误，原因是会话超时。

解决方法：使用 KRM API 进行自带映像导入，而不是使用 gdcloud CLI。

KRM 映像导入需要很长时间

版本：1.14.6 及更高版本

症状：使用 KRM API 进行的映像导入需要很长时间才能完成。VirtualMachineImageImport 资源长时间处于 TranslationJobInProgress 状态，表明翻译阶段未按预期完成。image-translation pod 进入 CrashLoopBackOff 状态。

解决方法：

  1. 请尝试创建具有其他名称的新 VirtualMachineImageImport 资源，然后再次尝试导入。
  2. 通过定期检查资源来监控 VirtualMachineImageImport 状态，直到其状态变为 WaitingForTranslationJob。如需了解详情，请参阅 VMM R0007 运行手册。