Google Distributed Cloud Air-gapped 1.13.x 已知问题

Artifact Registry

子组件 sar-failoverregistry 对账错误

版本：1.13.1、1.13.3、1.13.4

症状：使用 gdcloud system admin-cluster install 命令创建根管理员集群时，如果引导时服务器列表过长，操作可能会失败。错误输出消息如下：

Secret "sar-failoveregistry-backend-parameter" is invalid: data: Too long: must have at most 1048576 bytes

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

  1. 在与子组件相同的 Kubernetes 集群中，列出服务器并确认每个服务器自定义资源都有一个标签，其键为 cluster.private.gdc.goog/inventory-machine：

    kubectl get servers -n gpc-system

  2. 找到如下所示的组件自定义资源：

      apiVersion: lcm.private.gdc.goog/v1
  kind: Component
  metadata:
    creationTimestamp: "2025-01-06T12:00:41Z"
    generation: 1
    name: sar-v1.14.2-sar-acbf97caf6
    resourceVersion: "3199"
    uid: 681ec5cb-9eb3-423b-ac1d-f6aa27abfd75
  spec:
    name: sar

  3. 在系统制品注册表 (SAR) 组件自定义资源中，为 sar-failover-registry 的 runtimeParameterSources 服务器添加标签选择器：

    1. 查看现有的 server 资源：

      servers:
  targetCluster: Local
  object:
    apiVersion: system.private.gdc.goog/v1alpha1
    kind: ServerList
    namespace: gpc-system

    2. 更新组件自定义资源中的服务器字段：

      servers:
  targetCluster: Local
  object:
    apiVersion: system.private.gdc.goog/v1alpha1
    kind: ServerList
    namespace: gpc-system
    labelSelector:
      - key: cluster.private.gdc.goog/inventory-machine
        operator: "in"
        strValues:
          - "bm-1"
          - "bm-2"
          - "bm-3"

  4. 验证上一步中 SAR 组件的更改是否已传播到子组件 sar-failverregistry：

    1. 获取 SAR 组件的详细信息：

      kubectl get component | grep sar

    2. 获取 sar-failoverregistry 组件的详细信息：

      kubectl get subcomponent sar-failoverregistry -n root

      使用 -n 标志指定命名空间。

备份和恢复

由于卷空间不足，快照失败

版本：1.13.x 的所有版本

症状：永久性卷备份存在间歇性问题，可能会影响定期备份作业的工作流。对于某些变更率较高的卷，为正在进行的备份拍摄的卷快照可能会导致卷空间不足，进而使卷进入只读模式。

解决方法：为避免对生产工作负载造成潜在影响，请按照 BACK-R0104 运行手册中的步骤操作。您还可以选择按照 BACK-R0106 运行手册移除累积的快照。

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

版本：1.13.x 的所有版本

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

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

PVC 快照的备份失败

版本：1.13.x 的所有版本

症状：由于每个 PersistentVolumeClaim (PVC) 资源的 ONTAP 快照限制为 1023，因此备份失败。

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

  1. 更新备份方案，使备份永远不会达到限额。配置备份方案，以每小时进行一次备份，或将 deleteLockDays 减少到 3，这样快照数量就不会超过 1023：

    apiVersion: backup.gdc.goog/v1
kind: BackupPlan
metadata:
  name: test-backup-plan
spec:
  clusterName: system-cluster
  backupSchedule:
    cronSchedule: "*/10 * * * *"
    paused: false
  backupConfig:
    backupScope:
      selectedApplications:
        namespacedNames:
        - name: test-protected-application
          namespace: release-namespace
    backupRepository: gdchservices-backup-repository
    includeVolumeData: true
    volumeStrategy: LocalSnapshotOnly
  retentionPolicy:
    backupDeleteLockDays: LOCK_DAYS
    backupRetainDays: RETENTION_DAYS

    替换以下内容：

    • LOCK_DAYS：锁定备份删除操作，锁定天数为备份创建后指定的天数。使用以下值：

      • 如果 volumeStrategy 字段设置为值 LocalSnapshotOnly，请使用值 2。
      • 如果 volumeStrategy 字段设置为值 ProvisionerSpecific，请使用值 7。

    • RETENTION_DAYS：在备份创建后经过指定天数后删除备份。如果 volumeStrategy 字段设置为值 LocalSnapshotOnly，请使用小于 3 的值。

  2. 如需使用卷快照删除命令手动删除环境中的过多快照，请按以下步骤操作：

    1. 初始化变量：

      export RKCNF=/root/release/root-admin/root-admin-kubeconfig
export KCNF=/root/release/org-admin/gdchservices-admin-kubeconfig

export ORG_NAME=ORG_NAME
export PVC=PVC_NAME

      替换以下内容：

      • ORG_NAME：组织的名称。
      • PVC_NAME：与备份方案相关的 PVC 资源的名称。

    2. NetApp ONTAP 是一种用于管理 GDC 存储的操作系统。获取 ONTAP 访问权限：

      export USERNAME="$(kubectl --kubeconfig ${RKCNF?} -n gpc-system get
secret storage-root-level1 -o jsonpath='{.data.username}' | base64 -d)"

export MGMT_IP="$(kubectl --kubeconfig ${RKCNF?} get storagecluster -A
-o jsonpath='{.items[0].spec.network.clusterManagement.ip}')"

export PASSWORD="$(kubectl --kubeconfig ${RKCNF?} -n gpc-system get
secret storage-root-level1 -o jsonpath='{.data.password}' | base64 -d)"

echo $PASSWORD

    3. 列出所选 PVC 资源的所有快照：

      ssh ${USERNAME?}@${MGMT_IP?} "volume snapshot show -vserver ${ORG_NAME?}
-fields volume,snapshot,size,create-time" | grep "snapshot-" >
/tmp/snapshot_unsort.list

      使用上一步中的密码登录由 MGMT_IP 变量定义的 IP 地址处的机器。

    4. 找到快照数量最多的 PVC：

      grep ${ORG_NAME?} /tmp/snapshot_unsort.list | grep snapshot | awk
'{print $2}' | sort | uniq -c

    5. 将 PVC 资源名称设置为具有大量快照的资源名称：

      export PV_NAME=

    6. 删除包含大量快照的 PVC 资源的快照。PVC 资源的快照数量上限为 1023：

      for snap_name in `grep ${ORG_NAME?} /tmp/snapshot_unsort.list | grep
snapshot | grep ${PV_NAME?} | awk '{print $3}'` do
    echo "volume snapshot delete -vserver ${ORG_NAME} -volume ${PV_NAME} -snapshot $snap_name"
    echo "Y"
done

    7. 登录到 ONTAP 并运行以下命令以删除快照：

      echo $PASSWORD

#Use this password to login to ontap
ssh ${username?}@${mgmt_ip?}

    8. 运行上一步中列出的命令以删除快照。完成后，退出 SSH 会话

  3. 重复执行删除步骤，直到所有违规的 PVC 快照都被清理完毕。

从与 SVM 配额不兼容的备份中恢复

版本：1.13.1

症状：此问题是 NetApp 功能之间的不兼容问题。这种不兼容性会阻止租户配额的交付，并导致无法成功实现恢复。只有在将备份恢复到受配额限制的用户集群时，才会出现此问题。

解决方法：如果出现此问题，恢复操作会失败并显示错误消息 DP volumes are not supported on storage-limit enabled Vserver，基础设施运维人员 (IO) 必须停用相应用户集群的配额，然后重新启动恢复流程。恢复完成后，IO 必须重新启用租户配额，并且系统应继续按预期运行。如需了解详情，请参阅 runbook FILE A0030。

结算

结算指标未正确显示在结算信息中心内

版本：1.13.1

症状：由于缺少 MetricsProxySidecar，结算指标无法正确发送到 Cortex。

解决方法：创建 billing-monetizer MetricsProxySidecar 资源。然后，运行脚本以更新 metricExpression。

  1. 导出以下 kubeconfig 变量：

    export KUBECONFIG=KUBECONFIG_PATH

    将 KUBECONFIG_PATH 变量替换为组织管理员集群的 kubeconfig 文件的路径。按照服务手册 IAM-R0101 中的步骤生成此解决方法所需的 kubeconfig 文件。

  2. 为 billing-system 和 partner-billing-system 命名空间创建 billing-monetizer MetricsProxySidecar资源：

    对于 billing-system：

    cat <<EOF | kubectl --kubeconfig=$KUBECONFIG apply -n billing-system -f -
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: billing-monetizer
  namespace: billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8080
    scrapeInterval: 60s
  destinations:
  - certificate:
      secretName: billing-monetizer-monitoring-target-infra-obs-cert
    port: 9090
  - certificate:
      secretName: billing-monetizer-monitoring-target-platform-obs-cert
    port: 9091
---
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: usagemetering
  namespace: billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8099
    scrapeInterval: 60s
  destinations:
  - port: 9090
    certificate:
      secretName: bil-usagemetering-monitoring-target-cert
EOF

    对于 partner-billing-system：

    cat <<EOF | kubectl --kubeconfig=$KUBECONFIG apply -n partner-billing-system -f -
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: billing-monetizer
  namespace: partner-billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8080
    scrapeInterval: 60s
  destinations:
  - certificate:
      secretName: billing-monetizer-monitoring-target-infra-obs-cert
    port: 9090
EOF

  3. 运行以下脚本以更新 metricExpression。此操作会从 skuconfig 中移除 container_name="monetizer"，包括 billing_total_cost{container_name="monetizer"：

    cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bc73-b150-e0ea --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"BC4D-B784-EA3C|BC73-B150-E0EA|BD0C-C8CF-658B|BD1A-9464-9DF9|BD5A-044C-4860|BDB4-6C62-00BE|BDB4-BBA6-3EEE|3034-EE51-7404|3160-1596-5D9B|54AD-8EBC-8BB1\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bd1a-9464-9df9 --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"BC4D-B784-EA3C|BC73-B150-E0EA|BD0C-C8CF-658B|BD1A-9464-9DF9|BD5A-044C-4860|BDB4-6C62-00BE|BDB4-BBA6-3EEE|3034-EE51-7404|3160-1596-5D9B|54AD-8EBC-8BB1\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig b93c-effb-6d6b --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig b871-c5e5-bac1 --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig ba38-e4be-ba5d --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bbe8-7b7a-03de --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF

由于验证 webhook 中存在 bug，用户无法创建 BillingAccountBinding

版本：1.13.0、1.13.1、1.13.3

症状：此 bug 位于 BillingAccountBinding 验证网络钩子逻辑中。如果用户尝试创建 BillingAccountBinding 资源，Webhook 会返回错误 permission denied。

解决方法：如需创建 BillingAccountBinding 资源，请通知基础架构运维人员，并通过 IAC 创建相应资源。

块存储

由于卷装载错误，Grafana pod 卡在 Init 状态。

版本：1.13.3

症状：

由于卷装载错误，anthos-identity-service-obs-system 和 platform-obs-obs-system 命名空间中的 Grafana pod 卡在 Init 状态。kubelet 日志中的错误消息表明存在多重连接问题。此问题源于 Trident 中的一个 bug，该 bug 导致 Trident 无法正确识别和验证 LUKS 映射的底层设备，从而导致多重附加 bug。

解决方法：

检查 PVC 是否具有 deletionTimestamp。如果不存在 deletionTimestamp（Pod 迁移），请按以下步骤操作：

  1. 检查 PVC 的 VolumeAttachment，以确定卷当前挂接到何处。
  2. 隔离集群中与此值不匹配的 Nodes。
  3. 删除失败的 Pod，这应该会导致它迁移回原始的 Node。

检查后，如果存在 deletionTimestamp（卷删除），请按以下步骤操作：

  1. 检查 PVC 的 VolumeAttachment，以确定卷当前挂接到何处。

  2. 在 Node 上，输出其跟踪文件的内容：

    cat /var/lib/trident/tracking/PVC_NAME.json

  3. 验证在跟踪文件输出的 devicePath 字段中找到的 LUKS 设备是否已实际关闭。此路径此时不应存在：

    stat DEVICE_PATH

  4. 验证序列号是否已映射到任何多路径设备。

    1. 复制跟踪文件 iscsiLunSerial 字段中的值。

    2. 将此值转换为预期十六进制值：

      echo 'iISCSILUNSERIAL' | xxd -l 12 -ps

    3. 使用此新值查找多路径条目是否仍然存在：

      multipath -ll | grep SERIAL_HEX

    4. 如果不存在，请删除跟踪文件。

    5. 如果存在，您会看到一个比搜索到的序列十六进制值稍长的值，我们称之为 multipathSerial。运行以下命令，找到块存储设备：

      multipath -ll MULTIPATH_SERIAL

    6. 然后，运行以下命令，其中最后一个命令针对每个块设备单独运行：

      systemctl restart iscsid
systemctl restart multipathd
multipath -f MULTIPATH_SERIAL
echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete

虚拟机启动器 pod 无法映射卷

版本：1.13.1

症状：

您可能会看到如下所示的警告：

 Warning  FailedMapVolume  2m50s (x206 over 13h)  kubelet  MapVolume.SetUpDevice failed for volume "pvc-2a68356a-47da-422b-8781-15e3a6fe7ec9" : rpc error: code = DeadlineExceeded desc = context deadline exceeded

如需诊断此问题，请按以下步骤操作：

  1. 确保卷和 pod 位于同一节点上。
  2. 找到 Pod 所在的节点并检查其健康状况。
  3. 检查节点连接。
  4. 检查 IPSEC。
  5. 检查多路径，看看是否存在僵尸。

  6. 检查 Trident 日志，找出 CSI 流程中可能引入此僵尸的步骤：

    kubectl --kubeconfig /root/release/system/org-1-system-cluster logs -n netapp-trident -c trident-main

解决方法：如需解决此问题，请按照以下运行手册中的步骤操作：

  1. 如需了解与节点相关的问题，请参阅 FILE-R0010 runbook。
  2. 如需了解 IPSEC 相关问题，请参阅 FILE-R0007 Runbook。
  3. 如需了解有关僵尸 LUN 的问题，请参阅 FILE-R0020 Runbook。
  4. 如需了解有关超级僵尸 LUN 的问题，请参阅 FILE-R0021 Runbook。

存储空间相关故障

版本：1.13.1

症状：存储相关故障可通过 file_block_zombie_luns_present 警报触发或 pod 因 MountVolume 调用中的问题而无法启动（持续时间超过一个协调循环）来识别。超时时间可能约为两分钟。 如果同一故障重复出现，则表示 NodeStage 或 NodePublish CSI 路径中存在故障，需要采取解决方法。唯一例外情况是超时失败的指示。您可能会看到一些类似以下的失败情况：

NMountVolume.SetUp failed for volume "pvc-a63313b2-3e30-4c92-b074-f9fffe0500a4" : rpc error: code = Internal desc = unable to mount device; exit status 32

MapVolume.SetUpDevice failed for volume "pvc-f594b0c7-a5b5-4a5b-8a53-bf13e95c4bb0" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: multipath device not found when it is expected

MapVolume.SetUpDevice failed for volume "pvc-f594b0c7-a5b5-4a5b-8a53-bf13e95c4bb0" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: failure when reconfiguring multipath

解决方法：

  1. 如需查看具有 Pod 的 Node 是否可以针对发生故障的 PVC 进行更正，请隔离当前调度了 pod 的节点并删除 Pod：

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl cordon node TARGET_NODE

    Pod 应调度到完全不同的 Node，这会导致 Trident 被迫完全运行 NodeStage、NodePublish、NodeUnpublish 和 NodeUnstage。这可能不会立即修复卷，因为原始 Node 上可能仍有针对此卷的会话处于打开状态。

  2. 完成上一步后，取消隔离相关节点：

    KUBECONFIG=CLUSTER_KUBECONFIG kubectl uncordon node TARGET_NODE

  3. 如果仍然存在故障，则隔离除最初调度 Pod 的 Nodes 之外的所有其他 Nodes，并删除 Pod。这应会导致 Pod 从原始 Node 开始，现有设备可能仍停留在该位置。

  4. 完成上一步后，取消隔离相关节点。

  5. 作为保存 PV 及其数据的最后手段，可以重新启动 Node，以清除 Node 上的多路径、udev 和 devmapper 故障。虽然这一步相当艰巨，但最有可能成功。

  6. 如果之前的缓解措施未能解决卷的问题，则表明数据已损坏，无法有效使用。若要继续实现预期的容器行为，唯一剩下的选项是删除 PV、PVC 和 Pod 失败，然后重启托管 PV 的节点。此操作会导致已写入卷中的所有数据完全丢失。

创建的永久性卷的大小不正确

版本：1.13.1

症状：具有永久性卷的工作负载创建得过小，大约小了 16MiB。如果工作负载完全依赖于永久性卷所宣传的大小，那么在扩充或预配时，这种细微的差异会导致工作负载失败。对于使用 standard-block 存储类预配的持久卷，此问题比使用 standard-rwo 存储类预配的持久卷更可能发生。此问题可能会发生在具有 standard-rwo 存储类别且使用 volumemode:block 模式的永久性卷上。

解决方法：分配的永久性卷至少要比实际需要的容量大 16MiB。

无法删除存储虚拟机

版本：1.13.1

症状：StorageVirtualMachine 可能会显示如下错误：

 Warning  SVMDeletion  27m (x32 over 4h9m)   StorageVirtualMachine  Reconcile error for svm deletion: failed to delete svm: failed to delete svm volumes: failed to call VolumeCollectionGet: error message: "SVM \"org-2-user\" does not exist. "; error target: "svm.name"

解决方法：从组织命名空间中的 StorageVirtualMachines 中删除终结器。

组织停用不会清理资源

版本：1.13.1

症状：停用组织时，会遗留一些 StorageVirtualMachines 资源，例如：

  • gpc-system secret/org-2-admin-backup-agent-cert-secret
  • gpc-system secret/org-2-admin-client-cert-secret
  • gpc-system secret/org-2-admin-server-cert-secret
  • gpc-system secret/org-2-admin-svm-credential
  • gpc-system secret/org-2-admin-backup-agent-cert-secret
  • gpc-system secret/org-2-admin-client-cert-secret
  • gpc-system secret/org-2-admin-server-cert-secret
  • gpc-system secret/org-2-admin-svm-credential

解决方法：删除这些资源。

删除协调失败

版本：1.13.1

症状：如果在清理依赖于 StorageVirtualMachine 的集群之前删除 StorageVirtualMachine，则可能会在清理某些集群的持久卷 (PV) 时遇到问题。具体而言，当未清理 LUKS 加密的 PV 时，其密钥会阻止删除它们所在的命名空间。您可能会在日志中看到如下警告：

Warning  ReconcileBackoff  5m35s (x6 over 88m)  ClusterLifecycleReconciler  cluster namespace deletion is not completed: deletion is still ongoing for namespace: /g-org-2-shared-service-cluster

解决方法：从服务集群命名空间中的 g-luks-gdc-vm-disk-* Secret 中删除终结器。

裸金属升级卡住

版本：1.13.1、1.13.5、1.13.6

症状：当存在僵尸 LUN 时，Ansible 作业在收集事实时会卡住。运行 multipath -ll 命令可能会显示以下问题：

3600a098038314955593f574669785635 dm-11 NETAPP,LUN C-Mode
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
| |- 5:0:0:10 sdaf 65:240 failed faulty running
| `- 6:0:0:10 sdau 66:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
  |- 7:0:0:10 sdad 65:208 failed faulty running
  `- 8:0:0:10 sdar 66:176 failed faulty running

您可能还会看到以下错误消息：

 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [Check inventory] *********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [set_fact] ****************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.018)       0:00:00.018 ********
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv ok: [10.252.151.3]
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [Verify inventory]********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [assert]******************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.031)       0:00:00.050 ********
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv ok: [localhost]
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [all] *********************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [Gathering Facts] *********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.064)       0:00:00.114 ********

解决方法：检查与目标节点的 SSH 连接，然后使用以下 Runbook：FILE-R0020。

Trident 多重附加错误

版本：1.13.3

症状：Pod 和 PVC 可能滞留在不同的节点上，Pod 卡在初始化阶段，等待 PVC。

临时解决方法：

  1. 检查 PVC 是否有 deletionTimestamp：

    kubectl --kubeconfig KUBECONFIGget pvc -n <namespace> | grep deletionTimestamp

  2. 如果没有 deletionTimestamp（Pod 迁移）：

    1. 检查 PVC 的 VolumeAttachment，以确定卷的挂接位置。
    2. 隔离集群中与此值不匹配的节点。
    3. 删除失败的 Pod。此操作会将 Pod 迁移回原始节点。

  3. 如果存在 deletionTimestamp（卷删除）：

    1. 检查 PVC 的 VolumeAttachment，以确定卷的挂接位置。
    2. 在节点上，输出其跟踪文件 /var/lib/trident/tracking/PVC_NAME.json 的内容。
    3. 验证在跟踪文件输出的 devicePath 字段中找到的 LUKS 设备是否已实际关闭。此路径不应存在于此点：stat DEVICE_PATH。如果该路径仍然存在，则表示出现了其他问题。
    4. 验证序列号是否已映射到任何多路径设备。
    5. 复制跟踪文件 iscsiLunSerial 字段中的值。
    6. 将此值转换为预期十六进制值：echo ISCSI_LUN_SERIAL | xxd -l 12 -ps
    7. 使用此新值查找多路径条目是否仍然存在：multipath -ll | grep SERIAL_HEX。
    8. 如果不存在，请删除跟踪文件。

    9. 如果存在，您会看到比您搜索的序列十六进制值稍长的值。将此值记录为 MULTIPATH_SERIAL。运行 multipath -ll MULTIPATH_SERIAL，您会看到类似如下的消息：

      3600a09803831486f2d24575445314678 dm-32 NETAPP,LUN C-Mode
size=8.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 1:0:0:12 sde  8:64   active ready running
| `- 2:0:0:12 sdt  65:48  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 3:0:0:12 sdbc 67:96  active ready running
  `- 4:0:0:12 sdbe 67:128 active ready running

    10. 运行以下命令：

      1. systemctl restart iscsid
      2. systemctl restart multipathd
      3. multipath -f MULTIPATH_SERIAL
      4. echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete

    11. 针对每个块设备单独运行最后一个命令。

IPsec 配置错误

版本：1.13.4

症状：由于包含 0X 的预共享密钥 (PSK) 无效（该密钥被解读为十六进制字符串），ONTAP IPsec 配置遇到错误。

您可能会看到如下警告：

Warning  ONTAPIPSecConfiguration  3m47s (x22 over 75m)  StorageEncryptionConnection  Reconcile error on ONTAP IPSec configuration: failed to call IpsecPolicyCreateDefault: error message: "The specified pre-shared key \"0XxBDkG8iHoAlOc
nCUfHl0AKYzClgGCH\" is not valid because it is not a valid hexadecimal string."; error target: ""

临时解决方法：

  1. 获取存储加密连接：

    kubectl get  Storageencryptionconnections --kubeconfig ROOT_ADMIN_KUBECONFIG

    查找包含 Ready=False 的条目，并记下 PRESHAREKEY 的名称。输出可能如下例所示：

    NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR        PRESHAREDKEY                 READY   AGE
vm-5a77b2a2   vm-5a77b2a2        gpu-org-user            192.0.2.0/27   vm-5a77b2a2-pre-shared-key   False   26h

  2. 此机器正在运行 GPU 组织，因此请删除 gpu-org-admin 中的 secrets gpc-system/vm-5a77b2a2-pre-shared-key。

  3. 等待系统重新创建 secret/vm-5a77b2a2-pre-shared-key。

  4. 查找具有类似 gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2 模式的作业。 请注意，最后 8 个字符是随机生成的。当密钥再次可用后，删除作业，例如 gpu-org-admin 中的 jobs gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2m8xdl。

未创建存储虚拟机

版本：1.13.5

症状：gpu-org 上的 Harbor 服务因配置卷时出现问题而无法启动。此问题是由 file-storage-backend-controller pod 引用不存在的清单机器引起的。

您可能会看到如下所示的存储控制器错误，表明找不到 InventoryMachine：

{"ts":1730135301218.1772,"caller":"controller/controller.go:329","msg":"Reconciler error","controller":"StorageEncryptionConnectionGenerator","controllerGroup":"baremetal.cluster.gke.io","controllerKind":"InventoryMachine","InventoryMachine":{"n
ame":"vm-26c89d33","namespace":"@org-1/org-1-admin"},"namespace":"@org-1/org-1-admin","name":"vm-26c89d33","reconcileID":"48ab38a8-385d-4fdb-bd7e-1212f287379c","err":"InventoryMachine.baremetal.cluster.gke.io \"vm-26c89d33\" not found"}

临时解决方法：

  1. 删除 file-storage-backend-controller pod。
  2. 让存储控制器重新提取当前存在的库存机器。

存储集群间网络无法协调

版本：1.13.5、1.13.6

症状：升级后，根管理员集群中的 StorageCluster 自定义资源由于规范中集群间子网的配置错误而无法就绪。存储集群报告 Not Ready 并包含一个包含以下错误的事件：

Reconciler error: failed to configure additional networks: failed to configure intercluster LIF: the \"\" Kind is not currently supported

如果发生此错误，则存储集群使用的集群间子网声明不包含引用中的 kind 字段。检查 StorageCluster 自定义资源后，您会发现一个仅包含名称和命名空间的集群间子网声明引用，如下所示：

spec:
  additionalNetworks:
  - destinationSubnets:
    - 10.252.112.0/20
    name: backup-agent-storage-network
    port: a0a
    subnetConfig:
      subnetClaimRef:
        name: file-block-storage-intercluster-lif-subnet
        namespace: root
    types:
    - BackupAgent

解决方法：更新 StorageCluster 规范，以在子网声明引用中包含 kind: SubnetClaim 字段：

spec:
  additionalNetworks:
  - destinationSubnets:
    - 10.252.112.0/20
    name: backup-agent-storage-network
    port: a0a
    subnetConfig:
      subnetClaimRef:
        kind: SubnetClaim
        name: file-block-storage-intercluster-lif-subnet
        namespace: root
    types:
    - BackupAgent

更新 StorageCluster 规范后，重启 file-storage-backend-controller Deployment 并验证存储集群是否已就绪。

集群管理

machine-init 作业在集群配置期间失败

版本：1.13.1

症状：

  1. 在集群配置期间，第二个控制平面节点的 machine-init 作业失败，并显示以下消息：

    FAILED! => {"changed": true, "cmd": "/usr/bin/kubeadm join phase control-plane-prepare certs --config /dev/stdin --v 5".

  2. 查看日志：

    kubectl --kubeconfig=ADMIN_KUBECONFIG logs -p kube-apiserver-{first_node_name} -n kube-system | grep "etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied"

    输出显示了非空结果。

临时解决方法：

  1. 切换 /etc/kubernetes/pki/etcd/ca.crt 的权限。这是一项对时间要求非常高的操作。权限切换必须在上次运行 machine-init 作业之后，但在下次运行 machine-init 作业之前进行，因为 machine-init 会将权限覆盖回根。

  2. 重启第二个节点中的 etcd，以从崩溃循环中恢复第一个节点中的 etcd。

完成这两个步骤后，第一个节点中的 kube-apiserver 开始运行，下一个 machine-init 作业成功完成。

服务集群与对象存储桶之间没有连接

版本：1.13.1

症状：在服务集群中运行的数据库 pod 与组织管理员集群中的对象存储桶之间的连接失败。

解决方法：请按照 KUB-R0305 运行手册中的说明操作。

预检检查失败

版本：1.13.1

症状：您可能会在集群对象状态中看到以下消息：

conditions:
    message: Preflight check <cluster> failed
    reason: PreflightCheckFailed
    status: "False"
    type: PreflightCheckSuccessful

您还应看到一个 PreflightCheck 对象，该对象与集群对象具有相同的名称和命名空间，并且已存在数小时，而 PreflightCheck 对象中指示的错误或故障已知不再是问题。

解决方法：删除 PreflightCheck 对象。

用户集群工作器节点池创建失败

版本：1.13.5

症状：用户集群工作器节点池创建可能会停止响应，原因可能是使用了以下某种机器类型：

  • n2-standard-16-gdc
  • n2-standard-32-gdc
  • n2-highmem-16-gdc
  • n2-highmem-32-gdc

解决方法：删除该节点池，然后从用户集群创建界面下拉菜单中选择其他可用的机器类型，重新创建该节点池。

重新创建用户集群时，可能会因清理不当而卡在协调状态

版本：1.13.x

症状：如果创建的用户集群与之前删除的集群同名，则这些用户集群可能会无限期地卡在 Reconciling 状态，并且状态会提及插件安装阶段 ONE。

解决方法：卸载 helm 插件 CLUSTER_NAME-abm-overrides 并重启 managed-adm-controller 部署。如需了解详细步骤，请参阅 MKS-R0004。

数据库服务

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

AlloyDB Omni 数据库克隆卡住

版本：1.13.x 的所有版本

症状：当用户从某个时间点克隆 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)。

IOPS 强制执行会影响存储性能

版本：1.13.1

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

  • 增加存储空间大小。
  • 替换 IOPS 配额。

升级 dbs-fleet 子组件时出现协调错误

版本：1.13.3

症状：将根组织从 1.13.1 升级到 1.13.3 时，您可能会看到调解错误。检查对账错误：

kubectl get subcomponent -n ${CLUSTER} -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "ReconciliationError") |  "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'

错误可能如下所示：

Sub-Component: dbs-fleet - Reconciliation error: E0121 - rollback chart: no ControlPlaneAgentsVersion with the name "alloydbomni-v0.12.46" found

解决方法：按照 OCLCM-R0122 运行手册中的步骤操作。

DBCluster 创建失败

版本：1.13.3

症状：升级到 1.13.3 后，新的数据库集群无法协调，状态中显示以下错误：

status:
  criticalIncidents:
  - code: DBSE0001
    createTime: ""
    message: Internal. General Controller Error.
    resource:
      component: controller-default
      location: {}
    stackTrace:
    - component: controller-default
      message: 'DBSE0001: Internal. General Controller Error. Failed to reconcile
        Postgres DBCluster [<name>] DBSE0001: Internal.
        General Controller Error. target release is empty in ModuleInstance <name>'

临时解决方法

验证组织管理员集群中是否存在以 cpa-v0.12.46 和 cpa-v0.12.51 结尾的 localrollout CR。例如：

kubectl get localrollouts -A

dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.46         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.46         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.51         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.51         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.51--cpa-v0.12.51   true

查找并删除以 cpa-v0.12.46 结尾的 localrollout CR，确保其他 localrollout CR 不受影响。

kubectl get localrollouts -A | grep cpa-v0.12.46

这应该会返回如下列表：

dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.46         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.46         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.46--cpa-v0.12.46   true

删除每个密钥：

kubectl delete -n dbs-fleet-system localrollout/dp-alloydbomni-15-5.2--cpa-v0.12.46
...
...

验证以 cpa-v0.12.51 结尾的 localrollout CR 是否仍然存在：

NAMESPACE          NAME                                        PAUSED   IN PROGRESS   FINISHED
dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.51         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.51         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.51--cpa-v0.12.51   true

DNS

必须在 resolved.conf 中明确关闭 DNSSEC

版本：1.13.1、1.13.3、1.13.4

症状：裸机或虚拟机节点上的 DNS 解析失败。如需确认 DNS 解析是否失败，请与受影响的节点建立 SSH 连接，然后运行 systemctl status systemd-resolved。输出包含类似于 DNSSEC validation failed for question . IN SOA: no-signature 的行。

解决方法：

  1. 将以下代码行添加到受影响节点上的 /etc/systemd/resolved.conf 中。

    DNSSEC=false

  2. 重启 systemd-resolved 服务：

    systemctl restart systemd-resolved.service

Harbor 服务

Harbor 服务创建失败

版本：1.13.6

症状：由于 ServiceIsolationEnvironment 名称的长度限制导致命名空间不匹配，创建 Harbor 实例失败。您可能会看到类似如下内容的消息：

Failed to reconcile ODSDatabase: failed to create or update ODS ProjectNetworkPolicy: namespaces "g-dbs-PROJECT_NAME-HARBOR_INSTANCE_NAME" not found

解决方法：缩短 Harbor 实例名称，以解决当前问题。 确保 PROJECT_NAME 和 HARBOR_INSTANCE_NAME 的总长度不超过 27 个字符。

删除 Harbor 实例不会删除关联的注册表镜像

版本：1.13.1、1.13.3、1.13.4、1.13.5、1.13.6、1.13.7、1.13.8

症状：删除 Harbor 实例不会删除关联的注册表镜像。节点池可能卡在 Provisioning 状态。这是由 MHS 控制器创建的注册表镜像在 Harbor 实例被删除时未被删除所致。

解决方法：您必须手动移除注册表镜像。如需缓解此问题，请按以下步骤操作：

  1. 连接到组织管理员集群。如需了解详情，请参阅 GDC 集群架构。

  2. 运行此脚本可从具有标签 lcm.private.gdc.goog/cluster-type=user 的所有 Kubernetes 集群中移除与 HARBOR_INSTANCE_URL 环境变量的值匹配的所有注册表镜像：

    LABEL="lcm.private.gdc.goog/cluster-type=user"
ENDPOINT=HARBOR_INSTANCE_URL

while read -r out; do
    info=${out% *}
    ns_name=${info%:*}
    name=${ns_name##*/}
    ns=${ns_name%%/*}
    INDEX=$(kubectl get cluster user-vm-1 -n user-vm-1-cluster -ojson | jq '.spec.nodeConfig.registryMirrors | map(.endpoint=='\"$ENDPOINT\"') | index(true)')
    kubectl patch clusters "${name}" -n "${ns}" --type=json -p="[{'op': 'remove', 'path': '/spec/nodeConfig/registryMirrors/$INDEX'}]"
done <<< $(kubectl get clusters -l "$LABEL" -o jsonpath="$JSONPATH" -A)

    将 HARBOR_INSTANCE_URL 替换为您的 Harbor 实例的网址。

硬件安全模块

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

版本：1.13.1、1.13.3-1.13.11

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

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

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

版本：1.13.x

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

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

sudo systemctl restart host-daemon

如果上述操作无法解决问题，您的 IO 可以重新启动不健康的 HSM。

HSM 证书已过期

版本：1.13.11

症状：升级组织时，您可能会看到如下警告：

Warning  Unsuccessful  50m   OrganizationUpgrade  1 error occurred:
          * UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn't after 13h45m23.442682119s, last message was: Cluster upgrade for system cluster: in-progress

由于 HSM（硬件安全模块）证书过期，org-1-system-cluster 停留在 ABM 版本升级中。

您还可能会在 HPE 服务器 iLO、StorageGRID 或 ONTAP 中看到如下所示的错误：

Not able to connect SSL to Key Manager server at IP_ADDRESS

解决方法：

使用 ksctl 手动轮替根 CA 和网页界面证书：

  1. 暂停所有 HSM、HSMCluster 和 HSMTenant 预设回复。

  2. 创建一个新根 CA，其属性从旧根 CA 复制而来。使用 ksctl ca locals list 查找旧 CA ID。一个示例可能如下所示：

    ksctl ca locals create --cn example.com --copy-from-ca 6d7f7fa7-df81-44b7-b181-0d3e6f525d46
{
    "id": "b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "uri": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2025-06-04T18:46:25.728332Z",
    "updatedAt": "2025-06-04T18:46:25.728332Z",
    "state": "pending",
    "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIHQMHgCAQAwFjEUMBIGA1UEAxMLZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggq\nhkjOPQMBBwNCAAR5pwW1UC1JNg79gkjK2rvnmgaZpGNwb4VxYN3dQCieHtHlYJUu\nQWk56RB9oPw4SKkf/Y1ZwEI4m2mx3d9XFHU7oAAwCgYIKoZIzj0EAwIDSAAwRQIh\nANWTPjkJNcY56lSARN714EBa1gLuvxJlMENVHKEbanooAiA1BQ3sz7mxykL/1t7v\nqRlIpxKGrhw56XC67vz4NvZ4Kg==\n-----END CERTIFICATE REQUEST-----\n",
    "subject": "/CN=example.com",
    "notBefore": "0001-01-01T00:00:00Z",
    "notAfter": "0001-01-01T00:00:00Z",
    "sha1Fingerprint": "21F033940A65657CC6C2C1EA0BB775F14FD5D193",
    "sha256Fingerprint": "31EF6E1316DF039F77DDDB051890CDEBBF67BBE8A14AEE04E01716D30DC90937",
    "sha512Fingerprint": "F200817829A23F30239C33DC2CED8C889954A252EBA2CC12A3977FD5F91239ED7A2A4CCF0EA3D90D50CEF7A779E5C487798AAC75617DB2F29AF7F4794AD66F17",
    "purpose": {}
}

  3. 自签名有效期为一年的新 CA。例如，可以像下面这样：

    ksctl ca locals self-sign --id b0516120-6b4c-40ed-93f4-35e9fdc690e7 -x 365
{
    "id": "b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "uri": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2025-06-04T18:46:25.728332Z",
    "updatedAt": "2025-06-04T18:52:51.976847092Z",
    "state": "active",
    "csr": "",
    "cert": "-----BEGIN CERTIFICATE-----\nMIIBbTCCAROgAwIBAgIRAMyQJHhs4i2uwj4ghilVFJQwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTg1MjUxWhcNMjYwNjA0MTg1\nMjUxWjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABHmnBbVQLUk2Dv2CSMrau+eaBpmkY3BvhXFg3d1AKJ4e0eVglS5BaTnp\nEH2g/DhIqR/9jVnAQjibabHd31cUdTujQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV\nHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQ9uCnTZ+lHhiLx3f1xEn0+JC5J+TAKBggq\nhkjOPQQDAgNIADBFAiBsSiB5BRBJ8TZQ6O5TzMBgDoWzTZVMVXNLdZUiqHtcDwIh\nAOnqKNq5ytWLvMsBQKhulGgqqw1dccpkJJz01n3Smzyp\n-----END CERTIFICATE-----\n",
    "serialNumber": "271910941595574900448900837122680099988",
    "subject": "/CN=example.com",
    "issuer": "/CN=example.com",
    "notBefore": "2025-06-03T18:52:51Z",
    "notAfter": "2026-06-04T18:52:51Z",
    "sha1Fingerprint": "1114AF5ED6DF7D4A9F83A0F8DF5DFEF041A81622",
    "sha256Fingerprint": "93BAD9D44B320EFB446F65FE2A4F3A341147D15AF5315C000ADF644A3C1347A7",
    "sha512Fingerprint": "07386D7461B4013304CF0E0830517EA433E09EAB146A9F106F1B0DED4BBEC78BB4C89EAFAEC37178FE98AC4ACA234B98290D240607D5EA896F03DABF3DB56D5C",
    "purpose": {
            "client_authentication": "Enabled",
            "user_authentication": "Enabled"
    }
}

  4. 更新了网页界面，以使用此新 CA 进行证书自动生成。一个示例可能如下所示：

    ksctl interfaces modify --name web --auto-gen-ca-id kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7                 
{                                                                                                                                                                      
    "id": "61aab814-2821-43ac-b652-41784b7b06bf",                                                                                                                  
    "name": "web",                                                                                                                                                 
    "mode": "tls-cert-opt-pw-opt",                                                                                                                                 
    "cert_user_field": "CN",                                                                                                                                       
    "auto_gen_ca_id": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",                                                                              
    "trusted_cas": {                                                                                                                                               
            "local": [                                                                                                                                             
                    "kylo:kylo:naboo:localca:6d7f7fa7-df81-44b7-b181-0d3e6f525d46"                                                                                 
            ]                                                                                                                                                      
    },                                                                                                                                                             
    "createdAt": "2023-11-13T22:46:56.251881Z",                                                                                                                    
    "updatedAt": "2025-06-04T19:02:12.710563Z",                                                                                                                    
    "port": 443,                                                                                                                                                   
    "network_interface": "all",                                                                                                                                    
    "interface_type": "web",                                                                                                                                       
    "minimum_tls_version": "tls_1_2",                                                                                                                              
    "maximum_tls_version": "tls_1_3",                                                                                                                              
    "local_auto_gen_attributes": {                                                                                                                                 
            "cn": "web.ciphertrustmanager.local",                                                                                                                  
            "dns_names": [                                                                                                                                         
                    "web.ciphertrustmanager.local"                                                                                                                 
            ],      
...

  5. 生成由新 CA 签名的新网页界面证书。--url 标志是 HSM 的管理 IP（来自 kubectl get hsm -n gpc-system）。一个示例可能如下所示：

    ksctl interfaces auto-gen-server-cert --name "web" --url=https://10.128.52.18
{
    "certificates": "-----BEGIN CERTIFICATE-----\nMIICljCCAjygAwIBAgIRANPuw/42oHZAb9nzAYnrf9MwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTkwOTU5WhcNMjYwNjA0MTg1\nMjUxWjBjMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVFgxDzANBgNVBAcTBkF1c3Rp\nbjEPMA0GA1UEChMGVGhhbGVzMSUwIwYDVQQDExx3ZWIuY2lwaGVydHJ1c3RtYW5h\nZ2VyLmxvY2FsMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEy9T8uGa/N9ruRJMy\nxy4an+G/OyZjB/8nth1BPxpw5orljbTuOh9toS9c9FiOuMQQ13mGJSImadLP33PR\ngdXcHaOCARwwggEYMA4GA1UdDwEB/wQEAwIDiDATBgNVHSUEDDAKBggrBgEFBQcD\nATAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFD24KdNn6UeGIvHd/XESfT4kLkn5\nMGIGA1UdEQRbMFmCHHdlYi5jaXBoZXJ0cnVzdG1hbmFnZXIubG9jYWyBIXRlY2hu\naWNhbC5zdXBwb3J0QHRoYWxlc2dyb3VwLmNvbYcECoA0EocECgADAocErBMjAocE\nrBMLAjBeBgNVHR8EVzBVMFOgUaBPhk1odHRwOi8vY2lwaGVydHJ1c3RtYW5hZ2Vy\nLmxvY2FsL2NybHMvYjA1MTYxMjAtNmI0Yy00MGVkLTkzZjQtMzVlOWZkYzY5MGU3\nLmNybDAKBggqhkjOPQQDAgNIADBFAiEAusSKWMoFeTsK+OrbURch7XtMR31XD45E\n+w+wjf2VAk4CIAsHytphizTFQks4qqOMaHm6Ap58uU0HMNGSm0WW6mQY\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIIBbTCCAROgAwIBAgIRAMyQJHhs4i2uwj4ghilVFJQwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTg1MjUxWhcNMjYwNjA0MTg1\nMjUxWjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABHmnBbVQLUk2Dv2CSMrau+eaBpmkY3BvhXFg3d1AKJ4e0eVglS5BaTnp\nEH2g/DhIqR/9jVnAQjibabHd31cUdTujQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV\nHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQ9uCnTZ+lHhiLx3f1xEn0+JC5J+TAKBggq\nhkjOPQQDAgNIADBFAiBsSiB5BRBJ8TZQ6O5TzMBgDoWzTZVMVXNLdZUiqHtcDwIh\nAOnqKNq5ytWLvMsBQKhulGgqqw1dccpkJJz01n3Smzyp\n-----END CERTIFICATE-----\n"
}

  6. 此时，openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text 仍会显示旧证书。您必须重启 HSM 才能选取新证书。

    ssh -i ~/.ksctl/ssh-privatekey ksadmin@10.128.52.18

sudo reboot

    现在，openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text 会显示新证书。

  7. 从 HSM CR 中删除旧 CA：

    kubectl edit hsm zv-aa-hsm01 -n gpc-system and delete hsm.Spec.RootCACertificates

  8. 取消暂停 HSM：

    kubectl annotate hsm zv-aa-hsm01 -n gpc-system hsm.security.private.gdc.goog/paused-

    确保 HSM 恢复正常。

  9. 针对其他两个 HSM 重复上述步骤。它们已经拥有新的自签名根 CA，因为 CA 在集群中的 HSM 之间共享。跳过第 2 步和第 3 步，但重复第 4 步至第 8 步。

  10. 按照 HSM T0008 CA 轮换操作任务自动轮换所有证书，但跳过通过向添加了 hsmcluster 的 ca-rotation-finalizing annotation 步骤添加新的轮换注解来完成轮换这一步。

将新 CA 名称上传到 iLO：

  1. 在 iLO 界面中，打开“管理 - 密钥管理器”页面，然后点击密钥管理器标签页。
  2. 轮替证书名称。
  3. 执行冷重启。
  4. 验证 SSL 握手是否重新开始正常工作。

身份和访问权限管理

opa-system 命名空间中的 gatekeeper-audit pod 频繁重启

版本：1.13.3

症状：检查 opa-system 命名空间中 gatekeeper-audit-*** pod 的状态：

kubectl get pods/gatekeeper-audit-POD_ID -n opa-system-NAMESPACE_ID -n opa-system

输出可能如下例所示：

NAME                                READY   STATUS    RESTARTS        AGE
gatekeeper-audit-58d8c4c777-7hzvm   2/2     Running   987 (12h ago)   12d

此问题是由资源限制过低引起的。

基础设施即代码 (IAC)

过度创建 Gitlab 令牌可能会导致 Gitlab 数据库填满

版本：1.13.1

症状：iac-manager 子组件会反复为 configsync-ro 用户创建新令牌，即使没有必要也是如此。这可能会导致 Gitlab 数据库填满，从而使 IAC 无法访问。gitlab-system 命名空间中的 pg-gitlab-database-0 pod 可能无法启动，并显示如下事件：

  Warning  Unhealthy  84s (x18 over 4m14s)   kubelet  Startup probe failed: /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  could not write init file

临时解决方法：

与您的 Google 联系人合作，获取 1.13.1 版本的 hotfix_3 并应用。

密钥管理系统 (KMS)

更改根密钥类型会导致所有现有密钥失效

版本：1.13.x

症状：创建组织后，KMS 会自动预配软件根密钥。如需从软件根密钥迁移到 CTM 密钥，用户需要执行子组件替换。这会更改根密钥类型，导致 KMS 中的所有现有软件密钥失效。

解决方法：尽可能避免更新根密钥类型。如果您更新了根密钥类型，所有现有密钥都将失效。

kms-rootkey-controller CrashLoopBackOff，原因：OOMKILL

版本：1.13.1

症状：当 kms-rootkey-controller 内存用量超出 600Mi 限制时，控制器会因 OOMKilled 状态而进入 CrashLoopBackOff。

解决方法：创建 SubcomponentOverride 以将内存限制更新为 1500Mi。如需查看相关说明，请参阅 KMS Runbook 0007。完成运行手册中的前提条件步骤后，运行以下命令：

  1. 创建 SubcomponentOverride 自定义资源：

    cat << EOF > ~/kms-rootkey-subcomponentoverride.yaml

    在以下示例中，您可以看到一个完整的 SubcomponentOverride 自定义资源：

    apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: kms-rootkey-subcomponentoverride
  namespace: root
spec:
  subComponentRef: kms-rootkey-cm
  backend:
    operableParameters:
      resourcesLimit:
        memory: 1500Mi
EOF

  2. 应用 SubcomponentOverride 资源：

    kubectl --kubeconfig ${KUBECONFIG:?} apply -f ~/kms-rootkey-subcomponentoverride.yaml

kubectl --kubeconfig ${KUBECONFIG:?} describe subcomponentoverride kms-rootkey-subcomponentoverride -n root

日志记录

对象存储审核记录器无法解析 DNS 主机

版本：1.13.x

症状：

在根管理员集群中，obs-system/log-remote-logger 部署包含多个如下错误：

E1220 17:00:25.247258       1 manager.go:183] Failed to fetch obj audit logs for gce-gpcstgesite01: failed to get authorization token for Grid Management  API: Post "https://objectstorage-grid-mgmt.gpc-system.svc.cluster.local/api/v3/authorize": dial tcp: lookup objectstorage-grid-mgmt.gpc-system.svc.cluster.local: no such host

解决方法：使用以下命令修补 obs-system/log-remote-logger 部署：

kubectl --kubeconfig ${KUBECONFIG:?} patch deployment log-remote-logger -n obs-system -p '{"spec":{"template":{"spec":{"dnsPolicy":"ClusterFirstWithHostNet"}}}}'

HaaS Logger 显示根管理员集群中的错误

版本：1.13.x

症状：

在根管理员集群中，obs-system/log-remote-logger 部署包含多个如下错误：

E0109 17:33:08.917876       1 manager.go:156] Failed to run logger haas: Failed to get log targets: failed to list harborinstances in the cluster: failed to get API group resources: unable to retrieve the complete list of server APIs: artifactregistry.gdc.goog/v1: the server could not find the requested resource

解决方法：升级到 1.13.8 以修复此错误。或者，按如下方式修改 obs-system/log-remote-logger 部署：

在 remote-logger 容器实参中，更新 --disabled-loggers 标志以包含 santricity 和 HaaS：

YAML

args:
  - --disabled-loggers=santricity,haas

Santricity Logger 失败

版本：1.13.x

症状：

在根管理员集群中，obs-system/log-remote-logger 部署包含多个如下错误：

E0109 17:33:10.931737       1 manager.go:183] Failed to fetch santricity audit logs for lb-aa-objs01: failed to get CA cert: failed to get ClusterIssuer internal-root-ca-issuer: no kind is registered for the type v1.ClusterIssuer in scheme "pkg/logging/manager.go:32"

解决方法：升级到 1.13.8 以修复此错误。

日志记录目标日志发送到错误的项目

版本：1.13.x

症状：obs-system/oplogs-forwarder DaemonSet 日志记录了类似于以下内容的警告：

oplogs-forwarder-2xrfw [2025/01/16 21:02:09] [ warn] [output:loki:log_output_loki_dbs_fleet_system_dbs_fleet] Tenant ID is overwritten platform-obs -> infra-obs
oplogs-forwarder-kxf8p [2025/01/16 21:05:23] [ warn] [output:loki:log_output_loki_workbench_system_nws_lt] Tenant ID is overwritten infra-obs -> platform-obs

这些警告会导致日志路由到错误的项目（租户 ID）。此问题源于 Fluent Bit 中的一个已知 bug。如需了解详情，请参阅 Fluent Bit GitHub 问题。

解决方法：升级到 1.13.8 以修复此错误。

平台命名空间的审核日志对 PA 不可见

版本：1.13.x

症状：平台命名空间的审核日志对基础架构运营者 (IO) 可见，但对平台管理员 (PA) 不可见。

解决方法：手动将 observability.gdc.goog/auditlog-destination=pa 标签添加到所有组织集群中的 platform 命名空间。请按照以下步骤操作，实现此手动解决方法：

  1. 将 KUBECONFIG 设置为目标集群。

  2. 向命名空间添加必需的标签：

    KUBECONFIG=${KUBECONFIG:?} kubectl label namespace platform observability.gdc.goog/auditlog-destination=pa --overwrite

  3. 确认标签已成功添加：

    KUBECONFIG=${KUBECONFIG:?} kubectl label namespace platform --list

Pod 无法初始化容器

版本：1.13.x

症状：无法创建 pod，并显示类似如下的错误：

Events:
│   Type     Reason                  Age                     From     Message                                                                                                                                                 │
│   ----     ------                  ----                    ----     -------                                                                                                                                                 │
│   Warning  FailedCreatePodSandBox  10m (x2080 over 7h40m)  kubelet  Failed to create pod sandbox: mkdir /var/log/pods/org-1_managed-asm-local-readiness-xq75d_9a3275d7-5f16-4d67-8f4a-38fe0993be4a: no space left on device │

这些错误会导致 pod 无法在特定节点上启动。观察到的行为是由一个已知极端情况引起的，即 logrotate-daemon 状态文件被锁定，导致守护程序无法执行预期的文件轮换。如需确认此错误，请按以下步骤操作：

  1. 将 KUBECONFIG 设置为目标集群。

  2. 确定在节点上调度的 anthos-audit-logs-forwarder-xxxx 实例。

    KUBECONFIG=${KUBECONFIG:?} kubectl get po -n obs-system -o wide | grep anthos-audit-logs-forwarder

  3. 从节点上调度的 anthos-audit-logs-forwarder-xxxx 实例中提取日志以进行验证。

    KUBECONFIG=${KUBECONFIG:?} kubectl logs -n obs-system anthos-audit-logs-forwarder-xxxx -c logrotate-daemon | grep "state file /var/lib/logrotate/status is already locked"

解决方法：

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

  1. 对节点的 /var/log 目录执行手动磁盘空间回收。

  2. 将 KUBECONFIG 设置为目标集群。

  3. 确定集群中的目标节点。

    KUBECONFIG=${KUBECONFIG:?} kubectl get no -o wide

  4. 使用 SSH 连接到节点，然后手动释放节点上 /var/log 目录中的空间。logrotate 管理这些目录下的文件。

    /var/log/audit/*/*/*/audit.log
/var/log/audit*/*/*.log
/var/log/auditproxy-*/*.log
/var/log/global-api-*/audit.log
/var/log/ceph/ceph.audit.log
/var/log/fanout/audit/*.log
/var/log/fanout/audit/*/*.log
/var/log/netflow/*.log
/var/log/fanout/operational/*.log
/var/log/fanout/operational/*/*.log

  5. 检查是否存在异常大的日志文件（大小超过 100 MB）或超过几天的文件。获得目标文件后，您可以按如下方式截断日志：

    truncate -s 1G <target_file>

  6. 确定在节点上调度的 anthos-audit-logs-forwarder-xxxx 实例。

    KUBECONFIG=${KUBECONFIG:?} kubectl get po -n obs-system -o wide | grep anthos-audit-logs-forwarder

  7. 重启节点上已调度的 anthos-audit-logs-forwarder-xxxx 实例。

    KUBECONFIG=${KUBECONFIG:?} kubectl delete po -n obs-system anthos-audit-logs-forwarder-xxxx

Marketplace

Prisma Cloud 映像拉取失败

版本：1.13.7

症状：从 Marketplace 创建 Prisma Cloud 服务实例失败。此问题是由图片标记不正确引起的。

解决方法：

  1. 修改 twistlock-console 部署以修改映像标记：

    KUBECONFIG=${KUBECONFIG:?} kubectl edit deployment twistlock-console -n ${PROJECT:?}

  2. 找到以下行：

    image: HARBOR_IP/library/twistlock/console:console_33_01_137

  3. 将 console_33_01_137 替换为 console_33.01.137：

    image: HARBOR_IP/library/twistlock/console:console_33.01.137

  4. 验证 pod 是否正常运行：

    KUBECONFIG=${KUBECONFIG:?} kubectl get pods -n ${PROJECT:?}

    输出可能如下例所示：

    NAME                                 READY   STATUS    RESTARTS   AGE
twistlock-console-58b578cbf4-5nvbk   1/1     Running   0          2m45s

监控

在 ServiceNow 中创建了大量提醒

版本：1.13.x

症状：

在配置 Monitoring 以使用 MON-T0016 和 MON-T1016 任务将提醒发送到 ServiceNow 后，ServiceNow 中会自动创建大量突发事件。

该问题具有以下特征：

  • 所有突发事件均为空。
  • 只有根管理员集群和 gdchservices 组织能够向 ServiceNow 发送提醒。

解决方法：在运行 MON-T0016 和 MON-T1016 toil 任务后，立即运行 MON-T0018 toil 任务。

在 ServiceNow 中创建了多个重复的提醒

版本：1.13.x

症状：

在配置 Monitoring 以使用 MON-T0016、MON-T1016 和 MON-T0018 任务将提醒发送到 ServiceNow 后，ServiceNow 中会创建多个重复的提醒。

该问题具有以下特征：

  • 即使应用了 MON-T0018 运维任务，某些提醒仍会创建多个重复的突发事件。

解决方法：在运行 MON-T0016、MON-T1016 和 MON-T0018 toil 任务后，立即运行 MON-T0019 toil 任务。

无法查看 Vertex AI 指标

版本：1.13.1

症状：dvs-frontend-server pod 未发出指标。

解决方法：版本 1.13.1 不支持 Vertex AI 服务的加密指标。如果 Vertex AI 服务在超过一小时的时间内未启用，请重启 mon-admin 控制器 pod。

mon-cortex 中的对账错误

版本：1.13.1、1.13.9

症状：mon-cortex pod 出现协调错误。获取 mon-cortex pod 的状态：

kubectl get subcomponent mon-cortex -n gpu-org-1-system-cluster

输出可能如下所示：

NAME         AGE   STATUS
mon-cortex   15h   ReconciliationError

系统可能会记录类似如下的消息：

message: 'E0100 - deploy: failed to install chart: release mon-cortex-backend
        failed, and has been uninstalled due to atomic being set: context deadline
        exceeded'

解决方法：

  1. 检查哪个 Cortex pod 发出了类似以下内容的消息：

    Warning  FailedMount             11s   kubelet                  MountVolume.MountDevice failed for volume "pvc-0ad24fdc-52ec-4080-8ac0-5784989d1da3" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: could not open LUKS device; could not open LUKS device; could not open LUKS device; exit status 1

  2. 删除与该 pod 关联的 PVC 并重新启动该 pod。

metrics-server-exporter 系统集群中的 pod 处于崩溃循环状态

版本：1.13.1

症状：系统集群中的 metrics-server-exporter pod 因 OOMKilled 而陷入崩溃循环，但似乎并未达到其限制。诊断错误：

kubectl --kubeconfig $KUBECONFIG describe pod -n mon-system metrics-server-exporter-<id>

输出可能如下所示：

[...]
Containers:
  [...]
  otel-collector:
    Container ID:  containerd://3a1373de4880cde9e09aa9cacc109a8059ec29d9355aef1f03735fdcdcd45596
    Image:         gcr.io/private-cloud-staging/opentelemetry-collector:v0.93.0-gke.2
    Image ID:      gcr.io/private-cloud-staging/opentelemetry-collector@sha256:2b14f8fe936e725efca24dace1abcc26449d996b1480eab1b25d469a16aac221
    Port:          3113/TCP
    Host Port:     0/TCP
    Command:
      /otelcol
      --config=/conf/otel-collector-config.yaml
      --feature-gates=pkg.translator.prometheus.PermissiveLabelSanitization
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Thu, 20 Jun 2024 15:55:35 +0000
      Finished:     Thu, 20 Jun 2024 15:56:57 +0000
    Ready:          False
    Restart Count:  570
    Limits:
      cpu:     200m
      memory:  200Mi
    Requests:
      cpu:        100m
      memory:     100Mi
    Environment:  <none>

解决方法：通过删除 pod 并让其重启来减少指标端点上提供的数据量。执行此操作时，系统会清除内存中保留的旧 time-series，从而减少所需的内存。

忽略 ObservabilityPipeline 对账错误消息

版本：1.13

症状：

ObservabilityPipeline 对象在 root-admin-controller pod 中显示如下所示的 Reconciler error 日志：

{"msg":"Reconciler error","controller":"observabilitypipeline","ObservabilityPipeline":{"name":"default","namespace":"infra-obs"},"namespace":"infra-obs","name":"default","err":"unable to reconcile project level ObservabilityPipeline: 1 error occurred:\n\t* failed to get system cluster client to install per project overrides: root admin cluster has no system cluster\n\n"}

解决方法：

忽略满足以下所有条件的日志：

  • "controller":"observabilitypipeline"
  • "namespace":"infra-obs"
  • "name":"default"
  • “"err"”包含“failed to get system cluster client to install per project overrides: root admin cluster has no system cluster”

如果您因对账错误率过高而调试提醒，请忽略这些日志，因为它们是假负例。

mon-prober-backend-prometheus-config ConfigMap 会重置

版本：1.13.0 和 1.13.1

症状：

  • 提醒“MON-A0001”已触发。

  • mon-prober-backend-prometheus-config ConfigMap 会重置为不包含任何探测作业，例如：

    apiVersion: v1
data:
  prometheus.yaml: |
    remote_write:
    - url: http://cortex-tenant.mon-system.svc:9009/push
      name: cortex-tenant
kind: ConfigMap
metadata:
  creationTimestamp: "2024-06-26T14:55:07Z"
  name: mon-prober-backend-prometheus-config
  namespace: mon-system
  resourceVersion: "6606787"
  uid: 1a495af0-1fdc-40b8-845b-4976e3b0f899

解决方法：

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

  1. 设置以下环境变量：

    • KUBECONFIG：集群中 kubeconfig 文件的路径。
    • TARGET_CLUSTER：您要解决问题的集群的名称。

  2. 暂停所有集群上的 mon-prober 子组件：

    kubectl --kubeconfig $KUBECONFIG annotate subcomponent mon-prober -n $TARGET_CLUSTER lcm.private.gdc.goog/paused=true

    例如：

    kubectl --kubeconfig ~/root-admin-kubeconfig annotate subcomponent mon-prober -n my-org lcm.private.gdc.goog/paused=true

  3. 在每个管理员集群上重启 MON 管理员控制器：

    kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n obs-system mon-admin-backend-controller

    随着每个探测器的注册，Prober ConfigMap 会随之填充。

  4. 按照操作手册 MON-R2009 将 MON-A0001 提醒 Blackbox monitoring metrics pipeline down 设为静音，因为此提醒会一直触发。

Cortex 存储网关组件 OOMKilled 崩溃循环

版本：1.13.3

症状：如果您在 Grafana 上加载指标时看到错误，或者指标根本无法加载，则 cortex-store-gateway pod 可能处于崩溃循环状态。

如需诊断 cortex-store-gateway Pod 并检查它是否处于崩溃循环状态，请查看其状态：

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG describe pod \
  -l app=cortex-store-gateway -n mon-system

将 SYSTEM_CLUSTER_KUBECONFIG 替换为系统集群中 kubeconfig 文件的路径。

如果 pod 处于崩溃循环状态，则输出类似于以下示例：

State:          Waiting
Reason:       CrashLoopBackOff
Last State:     Terminated
Reason:       OOMKilled
Exit Code:    137

解决方法：使用 SubcomponentOverride 暂时提高 cortex-store-gateway 内存限制。如需详细了解如何实现 SubComponentOverride，请参阅 MON-R2008 Runbook。

以下是指定了内存限制的 SubcomponentOverride 的示例：

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: mon-cortex-memory-bump
  namespace: org-1-system-cluster
spec:
  subComponentRef: 'mon-cortex'
  backend:
    operableParameters:
      storeGateway:
          resourcesLimit:
              memory: 16Gi

保持替换处于有效状态，直到所有 cortex-store-gateway pod 都处于 Ready 状态，并确保 mon-cortex 子组件未暂停：

  • 检查 cortex-store-gateway pod 是否处于 Ready 状态：

    kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG get statefulset \
  -n mon-system cortex-store-gateway

    如果所有 pod 的状态均为 Ready，则输出类似于以下示例：

    NAME                   READY   AGE
cortex-store-gateway   3/3     70d

    READY 列必须显示 N/N 值，所有 pod 才能就绪。 否则，系统会显示 1/3 或 2/3 等值。

  • 确保指定组织中的 mon-cortex 子组件未暂停：

    kubectl --kubeconfig ORG_ADMIN_KUBECONFIG describe subcomponent \
  -n SYSTEM_CLUSTER mon-cortex | grep paused

    替换以下内容：

    • ORG_ADMIN_KUBECONFIG：组织管理员集群的 kubeconfig 文件的路径。
    • SYSTEM_CLUSTER：系统集群的名称。

    如果子组件处于暂停状态，输出会显示以下行：

    lcm.private.gdc.goog/paused: true

    否则，输出为空。

用户集群中 kube 控制平面指标代理映像拉取退避

版本：1.13.3

症状：当 Grafana 中未显示与 kube-scheduler 或 kube-controller-manager 相关的指标（例如 scheduler_pending_pods 和 workqueue_depth 指标）时，kube-control-plane-metrics-proxy pod 可能存在映像拉取退避问题。

如需诊断 kube-control-plane-metrics-proxy pod 并检查它是否存在映像拉取退避问题，请查看其状态：

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe pod \
  -l k8s-app=kube-control-plane-metrics-proxy -n obs-system

将 USER_CLUSTER_KUBECONFIG 替换为用户集群中 kubeconfig 文件的路径。

如果 pod 存在映像拉取退避问题，则输出类似于以下示例：

State:          Waiting
Reason:       ImagePullBackOff
Ready:          False
Restart Count:  0

解决方法：请按以下步骤解决此问题：

  1. 从 gpc-system-container-images Harbor 项目中拉取 gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 映像。如需查看拉取映像所需的说明和权限，请参阅使用 Docker 拉取映像。

  2. 将 gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 映像推送到 library Harbor 项目。如需查看推送映像的相关说明和所需权限，请参阅推送映像。

    library 项目用于将工件部署到用户集群。

WAL 的增长会导致 Prometheus 使用大量内存

版本：1.13.3

症状：系统控制平面虚拟机节点报告 NodeHasInsufficientMemory 和 EvictionThresholdMet 事件：

kubectl describe node NODE_NAME | grep Events -A100

输出可能如下例所示：

Events:
  Type     Reason                     Age                   From                   Message
  ----     ------                     ----                  ----                   -------
  Normal   NodeNotReady               12m (x8 over 10d)     node-controller        Node vm-e792c63a status is now: NodeNotReady
  Normal   NodeHasNoDiskPressure      12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeHasNoDiskPressure
  Normal   NodeHasSufficientPID       12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeHasSufficientPID
  Normal   NodeReady                  12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeReady
  Normal   NodeHasInsufficientMemory  12m (x34 over 13h)    kubelet                Node vm-e792c63a status is now: NodeHasInsufficientMemory
  Warning  EvictionThresholdMet       12m (x64 over 13h)    kubelet                Attempting to reclaim memory
  Normal   TridentServiceDiscovery    11m (x21 over 13h)    csi.trident.netapp.io  [iSCSI] detected on host.
  Normal   NodeHasSufficientMemory    6m52s (x31 over 24d)  kubelet                Node vm-e792c63a status is now: NodeHasSufficientMemory

由于预写日志 (WAL) 的增长，Prometheus 会使用大量内存，从而影响节点的内存。WAL 增长可能是因为 Cortex 未部署，因此此问题可能是 Cortex 停机造成的。Prometheus 实例长时间与 Cortex 断开连接，在此期间，它会在内存和持久卷 (PV) 中缓冲数据。当 Prometheus 终止时，它会在启动时将其 WAL 中的所有数据加载到内存中。

另一个根本原因可能是网络连接问题（服务网格、物理网络和上层网络）。

权宜解决方法：如需从此状态中恢复，建议采取的措施是解决根本原因，使 Cortex 恢复正常运行，或解决网络连接问题。然后，等待 Prometheus 的 WAL 排空。您不会丢失数据，但如果 Cortex 出现故障，在 Cortex 恢复之前，节点将无法使用。

或者，您也可以将 Prometheus STS 缩减为零，然后删除 PV。此操作可缩短节点不可用的总时间，但会导致数据丢失。此外，只要 Cortex 仍处于停机状态或您遇到网络连接问题，就必须定期重复此操作。只要 Prometheus 和 Cortex 之间存在连接问题，PV 就会再次填满。

请按照以下步骤将 Prometheus STS 缩减为零并删除 PV：

  1. 缩减 logmon-operator 组件：

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale deployment -n obs-system logmon-operator --replicas 0

    将 ORG_SYSTEM_KUBECONFIG 替换为组织系统集群中 kubeconfig 文件的路径。

  2. 对 anthos-prometheus-k8s 组件进行纵向缩容：

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale statefulset -n obs-system anthos-prometheus-k8s --replicas 0

  3. 删除永久性卷声明：

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG delete pvc -n obs-system anthos-prometheus-k8s-data-anthos-prometheus-k8s-0

  4. 将 logmon-operator 重新扩容：

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale deployment -n obs-system logmon-operator --replicas 1

  5. 等待 anthos-prometheus-k8s 准备就绪。

多可用区启动

缺少集群角色

版本：1.13.1

症状：没有可用于添加必需的角色的引导多可用区功能的特定角色。

解决方法：使用关联说明中指定的 cluster-admin 集群角色。这会向用户授予超出执行后续任务所需的最低访问权限。

不兼容的 Bootstrap 资源

版本：1.13.1

症状：在创建引导文件的第 3 步中创建的 Bootstrap 资源与处理该资源的逻辑不兼容。

解决方法：按照第 4 步中的说明修改生成的 YAML 文件。

未在全局 API 中创建 GlobalAPIZone 资源

版本：1.13.1

症状：控制平面未在全局 API 中为相应可用区创建 GlobalAPIZone 资源，导致依赖于此资源的组件无法正常运行。

解决方法：按照创建 GlobalAPIZone 资源中的说明创建资源。

网络

对象存储节点网格网络中断

版本：1.13.1、1.13.3、1.13.4

症状：

  1. 在对象存储启动阶段，从 OBJ 管理员节点安装程序界面来看，网格网络处于关闭状态。
  2. cables.csv 和 Cell CR 显示，cables.csv 中对象存储 objsadmin 节点与 TOR 交换机之间的连接的 MPN 值为 QSFP-100G-CU2.5M。

说明 在 1.13 中，cables.csv 中的 MPN 字段用于确定在 Tor 交换机上设置的速度。 如果未在这些端口上设置速度，则 tor 交换机到 objsadmin 节点的连接将失败。用于将 MPN 映射到速度的列表未考虑系统集成商提供的值，导致对象存储启动失败。 在大多数 1.13 设置中，所用供应商为：QSFP-100G-CU2.5M。

解决方法：

  1. 在根管理员集群上使用 kubectl get -A cell -oyaml 查找与对象存储设备和 TOR 交换机相关的连接。
  2. 将 objsadm -> torsw 连接的所有 mpn 更改为“QSFP-100G-CU3M”。

示例如下：

    - endA: "ap-aa-torsw01:Eth1/10"
      endB: "ap-aa-objsadm01:e3a"
      cableType: "DAC"
      mpn: "QSFP-100G-CU3M"
      length: "2m"
      color: "Black"

节点无法访问

版本：1.13.1、1.13.3、1.13.4

症状：

  1. 在网络引导阶段，某些交换机无法访问。
  2. 在 DHCP 安装阶段，某些服务器无法通过其 iLO IP 地址访问。

解决方法：

  1. 重新加载受影响的管理交换机。如需了解详情，请参阅 PNET-R0018 运行手册。

即使已创建 ClusterCIDRConfig，PodCIDR 也未分配给节点

版本：1.13.1

症状：ClusterCIDRConfig 是分配 PodCIDRs 所需的对象。 尽管已创建 ClusterCIDRConfig，但未分配 PodCIDRs。如果 ClusterCIDRConfig 是在 ipam-controller Pod 启动时创建的，就会出现此问题。集群创建卡在协调状态。

  1. 检查集群上是否已创建 ClusterCIDRConfig 对象：

    kubectl --kubeconfig=CLUSTER_KUBECONFIG get clustercidrconfigs -oyaml

    输出可能如下所示：

    apiVersion: v1
items:
- apiVersion: networking.gke.io/v1alpha1
  kind: ClusterCIDRConfig
  metadata:
    annotations:
      baremetal.cluster.gke.io/managed: "true"
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"networking.gke.io/v1alpha1","kind":"ClusterCIDRConfig","metadata":{"annotations":{"baremetal.cluster.gke.io/managed":"true"},"creationTimestamp":null,"name":"root-admin-control-plane"},"spec":{"ipv4":{"cidr":"172.24.0.0/21","perNodeMaskSize":23},"ipv6":{"cidr":"fd00:1::2:0/112","perNodeMaskSize":119}},"status":{}}
    creationTimestamp: "2024-06-17T05:27:55Z"
    finalizers:
    - networking.kubernetes.io/cluster-cidr-config-finalizer
    generation: 1
    name: root-admin-control-plane
    resourceVersion: "2172"
    uid: d1216fe3-04ed-4356-a105-170d72d56c90
  spec:
    ipv4:
      cidr: 172.24.0.0/21
      perNodeMaskSize: 23
    ipv6:
      cidr: fd00:1::2:0/112
      perNodeMaskSize: 119
kind: List
metadata:
  resourceVersion: ""

  2. 针对卡在协调状态的集群中的某个节点对象运行 describe，并检查该节点对象上是否存在 CIDRNotAvailable 事件：

    kubectl --kubeconfig=CLUSTER_KUBECONFIG describe node NODE_NAME

    输出事件可能如下所示：

      Type     Reason            Age                   From             Message
  ----     ------            ----                  ----             -------
  Normal   CIDRNotAvailable  3m22s (x96 over 21h)  cidrAllocator    Node gpc-adhoc-4f533d50vm-worker-node2-zone1 status is now: CIDRNotAvailable
  Warning  ReconcileError    3m22s (x96 over 21h)  ipam-controller  CIDRAssignmentFailed, retrying: failed to get cidrs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, unable to get clusterCIDRs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, no available CIDRs

解决方法：

  1. 重启 ipam-controller-manager pod：

    kubectl --kubeconfig=CLUSTER_KUBECONFIG -n kube-system rollout restart ds ipam-controller-manager

  2. 当 ipam-controller-manager pod 处于运行状态后，检查 podCIDR 是否已分配给节点：

    kubectl --kubeconfig=CLUSTER_KUBECONFIG get nodes -oyaml | grep podCIDR

    输出可能如下所示：

    podCIDR: 172.24.4.0/23
podCIDRs:
podCIDR: 172.24.2.0/23
podCIDRs:
podCIDR: 172.24.0.0/23
podCIDRs:

NTP 漂移

版本：1.13.1

症状：虚拟机节点在休眠或运行一段时间后，时间出现漂移或不准确。

解决方法：

  1. 建立与虚拟机节点的 SSH 连接，然后修改 /etc/chrony.conf 文件。
  2. 将 makestep 1.0 3 行替换为 makestep 1.0 -1。

  3. 重启 chronyd 服务：

    systemctl restart chronyd

您只需为每个虚拟机执行一次此更改。相应更改不会被覆盖。

如需立即快速修复时间跳跃问题，请建立与虚拟机节点的 SSH 连接，然后运行 chronyc -a makestep。

未解析 SyncServer 审核日志

版本：1.13.1、1.13.3、1.13.4、1.13.5、1.13.6、1.13.7

症状：SyncServer 中的审核日志无法被 log-remote-logger 正确解析。某些审核日志不会显示在 Grafana 中，您可能会在 root-admin log-remote-logger pod 中看到类似如下的错误消息：

Failed to fetch syncserver audit logs for syncserver-...

解决方法：审核日志仍可在 SyncServer 上查看。按照 NTP-P0002 中的说明访问 SyncServer 界面，并查看 Logs > Events 下的日志。

切换图片失败，无法提取图片

版本：1.13.3

症状：在执行 Switch RMA 或引导启动根管理员集群时，您可能会在 SwitchImageHostRequest 对象上看到类似如下的消息：

failed to pull or extract image "192.0.2.0:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004

如果您拥有 kubectl 访问权限，请使用该权限验证您是否遇到了此问题：

kubectl --kubeconfig=<path/to/root-admin-kubeconfig> -n gpc-system get switchimagehostrequest -o yaml

输出可能如下例所示：

kind: SwitchImageHostRequest
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    meta.helm.sh/release-name: pnet-core-assets
    meta.helm.sh/release-namespace: pnet-system
  creationTimestamp: "2024-08-20T04:16:36Z"
  generation: 1
  labels:
    app.kubernetes.io/managed-by: Helm
  name: v1.13.0-pnet-aa505d9004
  namespace: gpc-system
  resourceVersion: "149295"
  uid: f6c5b880-3fdb-4679-acd4-840b52998946
spec:
  fromVersion: v1.13.0-pnet-aa505d9004
  toVersion: v1.13.0-pnet-aa505d9004
status:
  conditions:
  - lastTransitionTime: "2024-08-20T05:10:17Z"
    message: ""
    observedGeneration: 1
    reason: TFTPRunning
    status: "True"
    type: TFTPReady
  - lastTransitionTime: "2024-08-20T04:16:36Z"
    message: 'exception: failed to pull images with config images: [{10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004
      /shared/tftpboot/switch/images}]: failed to pull or extract image "10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004":
      failed to pull image from source "10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004":
      GET https://10.249.48.5:10443/v2/gdch-switch/os/manifests/v1.13.0-pnet-aa505d9004:
      NOT_FOUND: artifact gdch-switch/os:v1.13.0-pnet-aa505d9004 not found'
    observedGeneration: 1
    reason: ReconcileBackoff
    status: Unknown
    type: Ready

解决方法：

手动创建包含正确图片标记的 SwitchImageHostRequest：

  1. 登录到引导加载程序服务器。

  2. 使用 gdcloud 确定正确的切换映像版本：

    release/gdcloud artifacts tree release/oci/ | grep -i gdch-switch

    输出可能如下例所示：

    │   │   │   │   └── gdch-switch/os:1.13.3-gdch.5385

    从该输出中可以看出，正确的交换机映像版本为 1.13.3-gdch.5385。

  3. 修改报告错误的 SwitchImageHostRequest 对象：

    kubectl --kubeconfig=<path/to/root-admin-kubeconfig> -n gpc-system edit switchimagehostrequest <SWITCH_IMAGE_HOST_REQUEST_NAME>

  4. 修改或替换 name、fromVersion 和 toVersion 字段，使其与预期的交换机映像版本一致。在本例中，该值为 1.13.3-gdch.5385。请参阅以下 diff 输出，其中展示了对 SwitchImageHostRequest 对象所做的更改。

    kind: SwitchImageHostRequest
metadata:
- name: v1.13.0-pnet-aa505d9004
+ name: 1.13.3-gdch.5385
  namespace: gpc-system
spec:
- fromVersion: v1.13.0-pnet-aa505d9004
+ fromVersion: 1.13.3-gdch.5385
- toVersion: v1.13.0-pnet-aa505d9004
+ toVersion: 1.13.3-gdch.5385

StatefulSet pod 通信失败

版本：1.13.1、1.13.3、1.13.4、1.13.5、1.13.6、1.13.7、1.13.8、1.13.9、1.13.10

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

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

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

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

与 DBS 实例的连接问题

版本：1.13.0、1.13.1

症状：数据库服务 (DBS) 实例无法访问，数据库客户端显示连接超时。

此问题可能会通过依赖 DBS 的其他系统组件显现出来。例如，结算可能会报告如下所示的错误消息：

DBSE0301: Healthcheck: DB cluster is not healthy. Cannot connect to DBdaemon
DBSE0005: DBDaemon Client Error. secure dbdaemon connection failed: context
deadline exceeded

解决方法：此故障是由无法在组织的服务集群上进行调度的网络系统组件引起的。

  1. 设置以下环境变量： 

    export KUBECONFIG=KUBECONFIG_PATH
export ORG_NAME=ORG_NAME

    替换以下内容：

    • KUBECONFIG_PATH：组织管理员集群 kubeconfig 文件的路径。
    • ORG_NAME：组织的名称，例如 org-1。

  2. 更新网络组件配置，以允许调度该组件：

    kubectl --kubeconfig=KUBECONFIG_PATH kubectl -n g-ORG_NAME-shared-service-cluster   patch addonconfiguration ang-overrides   --type='json'   -p='[{"op": "replace", "path": "/spec/configs/1/patchContent", "value": "apiVersion: apps/v1\nkind: DaemonSet\nmetadata:\n  name: ang-node\n  namespace: kube-system\nspec:\n  template:\n    spec:\n      containers:\n      - name: angd\n      - name: bgpd\n        env:\n        - name: DISABLE_RECEIVED_ROUTES\n          value: \"true\"\n      tolerations:\n      - operator: \"Exists\"\n        effect: \"NoSchedule\""}]'

网络连接会在几分钟后恢复。

集群网格未配置可用区信息

版本：1.13.5

症状：虚拟机无法连接到同一项目中的数据库集群。与内部负载均衡器的连接受到影响。此问题是由 Clustermesh 无法跨集群交换服务对象引起的，原因是集群名称配置中缺少可用区信息。

解决方法：对于引导启动为多可用区的环境，请执行以下手动解决方法步骤，以使内部负载均衡器正常运行：

  1. 在组织管理员集群上，获取可用区名称：

    ZONENAME="$(kubectl get controlplanes -A -o jsonpath="{.items[0].spec.zone}")"
echo $ZONENAME

    输出可能如下例所示：

    zone1

  2. 在组织管理员集群上，获取区域网站 ID：

    SITEID="$(kubectl -n mz-system get zones $ZONENAME -o jsonpath="{.spec.siteID}")"
echo $SITEID

    输出可能如下例所示：

    1

  3. 列出所有集群：

    ​​kubectl get clusters -A

    输出可能如下例所示：

    NAMESPACE                        NAME                     ABM VERSION        DESIRED ABM VERSION   CLUSTER STATE
g-org-1-shared-service-cluster   g-org-1-shared-service   1.30.0-gke.1592    1.30.0-gke.1592       Running
org-1-system-cluster             org-1-system             1.30.0-gke.1592    1.30.0-gke.1592       Running
user-vm-1-cluster                user-vm-1                1.16.11            1.16.11               Running
user-vm-2-cluster                user-vm-2                1.28.700-gke.150   1.28.700-gke.150      Running

  4. 针对每个集群，构建 CILIUM_CLUSTERNAME：

    CLUSTER_NAME=CLUSTER_NAME
CILIUM_CLUSTERNAME=$CLUSTERNAME-zone$SITEID
echo $CILIUM_CLUSTERNAME

    输出可能如下例所示：

    org-1-system-zone1

  5. 对于每个集群，请按如下方式设置其他参数。以下是针对 org-1-system 的示例：

    CLUSTER_NAMESPACE=org-1-system-cluster
CLUSTER_VERSION=1.30.0-gke.1592

  6. 为每个集群创建一个 AddOnConfiguration 对象，并将其存储在 addonconfig.yaml 文件中。为所有现有集群以及您将来创建的任何新集群创建此文件：

    在此页面上，设置以下变量以更新以下代码示例：

    CLUSTER_NAMESPACE=CLUSTER_NAMESPACE
CLUSTER_VERSION=CLUSTER_VERSION
CILIUM_CLUSTERNAME=CILIUM_CLUSTERNAME

    apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: AddOnConfiguration
metadata:
  name: cilium-addon
  namespace: CLUSTER_NAMESPACE
spec:
  anthosBareMetalVersions:
  - CLUSTER_VERSION
  configs:
  - name: cilium-config
    namespace: kube-system
    apiVersion: v1
    kind: ConfigMap
    patchContent: |
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cilium-config
        namespace: kube-system
      data:
        cluster-name: CILIUM_CLUSTERNAME

  7. 在组织管理员集群上应用 addonconfig.yaml：

    kubectl apply -f addonconfig.yaml

  8. 在系统集群、服务集群和用户集群上，确保 cluster-name 已在集群的 cilium-config 中更新。更新可能需要一些时间，但在重启 clustermesh-apiserver 部署之前，必须完成此步骤。

    kubectl get configmap -n kube-system cilium-config -o jsonpath="{.data.cluster-name}" && echo

  9. 在系统集群、服务集群和用户集群上，重启 clustermesh-apiserver 部署：

    kubectl rollout restart deployment -n kube-system clustermesh-apiserver

生成了错误的 EVPN IP 地址

版本：1.13.1、1.13.3、1.13.4、1.13.5、1.13.6、1.13.7

症状：由硬件资产管理系统 (HAMS) 生成的多区域 (MZ) EVPN 互连会话对等互连 IP 地址未以 .65 或 .66 结尾，这是不正确的，会导致无法建立 MZ EVPN BGP 会话。

解决方法：

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

  1. 列出所有 InterconnectSession 资源：

    kubectl get interconnectsession -n gpc-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig | grep zoneevpnpeering

  2. 查看生成的 EVPN 多区域 InterconnectSession 资源，这些资源具有 ZonePeering 的 interconnectType 值和 EVPN 的 addressFamily：

    apiVersion: system.private.gdc.goog/v1alpha1
kind: InterconnectSession
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
  creationTimestamp: null
  name: interconnect-session-am-aa-blsw01-zoneevpnpeering-3
  namespace: gpc-system
  labels:
    system.private.gdc.goog/ipv4-session-name-1: interconnect-session-am-aa-blsw01-zoneipv4peering-3
spec:
  interconnectLinkRef:
    name: interconnect-am-aa-blsw01-zoneevpnpeering-3
    namespace: gpc-system
  interconnectType: ZonePeering
  peerIP: 192.168.203.67
  md5HashKey: ""
  peerASN: 65402
  addressFamily: EVPN
status: {}

  3. 对于与这些参数匹配的每个 InterconnectSession 资源，应用以下修复：

    1. 检查互连会话自定义资源名称。
    2. 如果名称以奇数结尾，请使用下一步中的命令将对等互连 IP 地址的最后一部分更新为 65。
    3. 如果名称以偶数结尾，请使用下一步中的命令将对等 IP 地址的最后一部分更新为 66。

  4. 修改具有错误对等 IP 地址的 InterconnectSession 资源：

    kubectl edit interconnectsession
interconnect-session-zy-aa-blsw01-zoneevpnpeering-1 -n gpc-system
--kubeconfig=/root/release/root-admin/root-admin-kubeconfig

  5. 将此修复应用于导致错误的所有 InterconnectSession 资源。

上层网络控制平面信息中心不显示任何数据

版本：1.13.7

症状：TestUpperNetworkingMetrics 中的 Prometheus 查询因 org-1-system 集群中缺少指标而失败。IO 组织管理员的上层网络控制平面信息中心内的集群网格面板不显示任何数据。此问题源于 Cilium 和监控系统之间的 source_cluster 标签不一致。

解决方法：从 UNET 控制平面信息中心移除 source_cluster 过滤条件，以显示数据。

网络安装时显示的干扰性错误

版本：1.13.1

症状：在安装网络期间，系统会显示一些布线警告消息。例如：

  W0725 18:01:19.127111   39319 switch_port.go:59] Got error on getting port speed for la-ac-mgmtsw01:Eth1/46<>la-ac-base03:ilo: no speed associated with cable model: 31342 (CAT6 5ft Black)
  W0725 18:01:19.127127   39319 switch_port.go:59] Got error on getting port speed for la-ac-mgmtsw01:Eth1/33<>la-ac-bm21:LOM1: no speed associated with cable model: 03982 (CAT6 4ft Black)

您可以放心地忽略这些错误消息。

创建允许所有出站流量的 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*]

对象存储

无法删除存储组织

版本：1.13.1

症状：由于某个问题导致 SVM 删除无法完成，因此组织删除可能无法成功。您可能会看到如下警告：

Warning StorageOrganizationDeletion 49m (x97
over 23h) StorageOrganization Reconcile error for storage org
deletion: cannot delete storage organization resources, pre-checks failed:
subnet claim "poc2/poc2-admin-svm-mgmt-network-subnet" exists,
cannot continue before it is deleted

可以忽略部分对象存储升级警告

版本：1.13.3

症状：升级对象存储时，您可能会看到如下警告：

Type     Reason          Age                From                              Message
  ----     ------          ----               ----                              -------
  Warning  ReconcileError  55m (x2 over 55m)  ObjectStorageAdminNodeReconciler  Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: {"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked

解决方法：

  1. 检查每个节点是否都有存储在 Secret 中的相应 SSH 凭据。

    1. 检查管理员节点：

      kubectl get objectstorageadminnodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done

    2. 检查存储节点：

      kubectl get objectstoragestoragenodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done

      成功输出如下所示（以存储节点为例）：

      NAME                                      TYPE     DATA   AGE
gpcstgecn01-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h
NAME                                      TYPE     DATA   AGE
gpcstgecn02-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h
NAME                                      TYPE     DATA   AGE
gpcstgecn03-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h

      如果未找到 Secret，则会显示如下所示的错误：

      Error from server (NotFound): secrets "gpcstgeadm02-gce-gpcstgesite01-ssh-creds" not found

  2. 如果该命令未返回任何错误，您可以放心地忽略协调器报告的错误。

ObjectStorageStorageNodeReconciler 报告 maintenance.gdu.gdu_server_locked

版本：1.13.3

症状：显示 objectstoragestoragenode 的详细信息：

kubectl describe objectstoragestoragenode zv-aa-objs02

输出可能如下例所示：

Events:
  Type     Reason          Age                    From                                Message
  ----     ------          ----                   ----                                -------
  Warning  ReconcileError  54m (x2 over 54m)      ObjectStorageStorageNodeReconciler  Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: {"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked"}

解决方法：您可以忽略此问题。当 GDU 服务收到过多的请求时，可能会暂时锁定，但会在几分钟后解锁。

升级后从 1.12.x 到 1.13.x 的飞行前检查对象存储失败

版本：1.13.x

症状：ObjectStorageUpgrade CR 失败，并显示以下错误

Message:               check "ObjectStorageUpgrade" of operable component "OBJ" failed with reason "BackoffLimitExceeded", please check logs in pods: [gpc-system/upgrade-managed-check-objectstorageupgrade] 
Observed Generation:   2
Reason:                PostflightCheckFailed

Pod gpc-system/upgrade-managed-check-objectstorageupgrade 失败并显示错误

Error: check "ObjectStorageUpgrade" preflight check failed: ObjectStorageSite gce-gpcstgesite01 not ready                                                                      │
  Usage:                                                                                                                                                                         │
    managed [flags]                                                                                                                                                              │
  Flags:                                                                                                                                                                         │
        --component_name string              preflight check name                                                                                                                │
        --current_version string             current version of the Organization                                                                                                 │
    -h, --help                               help for managed                                                                                                                    │
        --organization-upgrade-name string   the name of current OrganizationUpgrade                                                                                             │
        --target_version string              target version of the Organization                                                                                                  │
  F1023 06:18:01.122723       1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: ObjectStorageSite gce-gpcstgesite01 not ready                                   │
  goroutine 1 [running]:

根本原因：如果引导加载程序 KIND 集群未停用或删除，则将对象存储操作组件从 1.12.x 升级到 1.13.x 会失败。 即使升级成功，由于 TLS 证书验证错误，常见对象存储服务（例如通过 Kubernetes RBAC 创建新存储分区或 S3 凭据）也可能会失败。这是因为 KIND 集群中的特定对象存储 pod 会持续尝试安装 StorageGRID 管理端点的 TLS 服务器证书，该证书在 1.12.x 中有效，但在 1.13.x 中可能无法识别。 在升级期间，StorageGRID 会安装新的可验证 TLS 服务器证书，但 KIND 集群 pod 会将其替换为旧的无效证书，从而导致 TLS 证书错误。

解决方法：必须满足以下要求：

  • 将对象存储从 1.12.x 升级到 1.13.x
  • 引导集群（KIND 集群）仍然存在

请按以下步骤操作：

  1. 获取对引导集群（即 KIND 集群）中的 ObjectStorageSite 资源具有查看和修改权限的 kubeconfig。

  2. 为连接到引导集群（KIND 集群）的 kubectl 设置别名：

    alias kubectlkind="kubectl --kubeconfig <Full path to the kubeconfig of the bootstrapping cluster>

  3. 从引导加载程序集群获取 ObjectStorageSite 自定义资源实例。应有一个 ObjectStorageSite 资源实例：

    SITENAME=$(kubectlkind get ObjectStorageSite -A -o jsonpath='{.items[0].metadata.name}')

  4. 向 ObjectStorageSite 资源实例添加对象存储暂停注解：

    kubectlkind annotate ObjectStorageSite "${SITENAME:?}" storagegrid.netapp.storage.private.gdc.goog/paused=true

  5. 验证对象存储暂停注解是否已添加到 ObjectStorageSite 实例：

    kubectlkind get ObjectStorageSite "${SITENAME:?}" -o jsonpath='{.metadata.annotations}' | jq

  6. 获取对根管理员集群中的 ObjectStorageCluster 资源具有查看访问权限和状态补丁权限的 kubeconfig。

  7. 为连接到根管理员集群的 kubectl 设置别名：

    alias kubectlrootadmin="kubectl --kubeconfig <Full path to the kubeconfig of the root admin >"

  8. 检查根管理员集群中是否存在任何 ObjectStorageCluster 资源实例：

    kubectlrootadmin get ObjectStorageCluster

    如果没有 ObjectStorageCluster 资源实例，则表示问题已解决。您可能需要再次执行对象存储升级程序。

  9. 从引导集群中 ObjectStorageSite 资源的状态获取管理端点网址：

    MGMT_ENDPOINT=$(kubectlkind get ObjectStorageSite -o jsonpath='{.items[0].status.managementAPIEndpointURL}')

  10. 验证是否已设置环境变量 $MGMT_ENDPOINT。端点应以 https:// 开头：

    echo ${MGMT_ENDPOINT:?}

  11. 仅当根管理员集群中只有一个 ObjectStorageCluster 资源实例时，才执行剩余步骤。否则，请再次执行对象存储升级程序：

    kubectlrootadmin patch ObjectStorageCluster <the name of ObjectStorageCluster> --type=merge --subresource status --patch "status: {managementAPIEndpointURL: '${MGMT_ENDPOINT:?}'}"

  12. 重启 gpc-system/obj-infra-cluster-cm pod：

    kubectlrootadmin rollout restart deployment -n gpc-system obj-infra-cluster-cm-backend-controller

  13. 验证管理端点是否已添加到 ObjectStorageCluster 资源的状态中：

    kubectlrootadmin get ObjectStorageCluster -o jsonpath='{.items[0].status}' | jq

  14. 通过删除飞行后检查 Kubernetes 作业 gpc-system/upgrade-managed-check-objectstorageupgrade-<random suffix> 来重启飞行后检查。 系统很快就会重新创建该作业。

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

这是一个罕见的问题，如果 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

操作系统

Pod 卡在 init 状态

版本：1.13.1

症状：节点报告为就绪状态，但对节点的 SSH 访问速度缓慢，且 top -n 1 显示有 100 多个僵尸进程。

解决方法：

  1. 按照 OS-P0001 中的步骤排空服务器。放电过程可能需要 20 分钟以上。如果耗尽操作在一小时后仍未成功，请继续执行下一步。

  2. 通过建立与服务器的 SSH 连接并发出以下命令来重启服务器：

    systemctl reboot

  3. 可能需要第二次重新启动才能完全恢复服务器。

  4. 验证 SSH 访问不再缓慢，并且僵尸进程的数量已大大减少，最好少于 30 个。

  5. 通过在服务器上将 maintenance 设置为 false 来取消排空服务器。

bm-system-machine-preflight-check 裸机或虚拟机节点的 Ansible 作业失败

版本：1.13.1

症状：重新启动后，内核模块 nf_tables 未加载，导致集群 Ansible 作业失败并显示 Either ip_tables or nf_tables kernel module must be loaded 错误。当裸机或虚拟机节点在完全配置之前重新启动时，就会出现此问题。Ansible 作业可能会抛出如下错误：

fatal: [172.20.128.23]: FAILED! => {"changed": false, "msg": "following are the error messages for each failed preflight check {'check_netw
orking_kernel_module_pass': 'Either ip_tables or nf_tables kernel module must be loaded. Use the command \"modprobe <ip_tables OR nf_tables
>\" to load the module.'}"}

临时解决方法：

建立与节点的 SSH 连接，然后运行以下命令：

modprobe nf_tables

设备上已没有剩余空间的虚拟机

版本：1.13.1、1.13.3、1.13.4、1.13.5

症状：当日志目录 /var/log 已满时，Node 可能会卡在 NotReady 状态，并且 Pod 可能会因错误 no space left on device 而无法启动。如需检查这一点，请在节点上运行以下命令，并检查使用率是否接近 100%。

df -h /var/log
Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/rocky-rl--var_log   15G   15G   20K 100% /var/log

解决方法：

  1. 登录遇到问题的节点，并清理 /var/log/messages 的旧日志归档。

    find /var/log -name "messages*" -mtime +4 -delete

    我们还建议您继续应用以下解决方法，以防止此问题再次发生。解决方法是创建 AnsiblePlaybook 并通过负责安全配置目标操作系统（裸机 + 虚拟机）的自定义 OSPolicy CR 应用更改。如需了解详情，请参阅流程 OS-P0005。

  2. 设置以下环境变量： 

    export KUBECONFIG=<the path to the kubeconfig file>

  3. 为解决方法创建 Ansible playbook：

    kubectl --kubeconfig=${KUBECONFIG:?must be set} apply -f - <<EOF
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
  name: update-logrotate
  namespace: gpc-system
spec:
  playbook: |
    - name: Set the default context for the /etc/kubernetes path to etc_t
      hosts: all
      gather_facts: no
      tasks:
        - name: Change log rotation for /var/log/messages
          block:
            - name: Check if /etc/logrotate.d/syslog exists
              check_mode: false
              ansible.builtin.stat:
                path: '/etc/logrotate.d/syslog'
              register: syslog_exists
            - name: Comment out /var/log/messages lines in syslog
              ansible.builtin.replace:
                path: '/etc/logrotate.d/syslog'
                regexp: '^/var/log/messages'
                replace: '# /var/log/messages'
              when: syslog_exists.stat.exists
            - name: Change logrotate config for /var/log/messages
              ansible.builtin.blockinfile:
                path: '/etc/logrotate.d/syslog'
                block: |
                  /var/log/messages
                  {
                      daily
                      rotate 4
                      missingok
                      notifempty
                      sharedscripts
                      postrotate
                          /usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
                      endscript
                  }
              when: syslog_exists.stat.exists
EOF

  4. 确定需要应用更改的目标广告资源，目标可以是单个 InventoryMachine 或 NodePool。请参阅流程 OS-P0005（第 2 步）。如需了解详情，请参阅“确定运行时配置的目标库存”。

    以下 OSPolicy 示例在 spec.inventory 下添加了两个目标广告资源，您可以根据需要添加更多广告资源。

    kubectl --kubeconfig=${KUBECONFIG:?must be set} apply -f - <<EOF
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
  name: manual-update-logrotate
  namespace: gpc-system
spec:
  inventory:
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    name: control-plane-node-pool
    namespace: org-1-system-cluster
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    name: control-plane-node-pool
    namespace: user-vm-1-cluster
  policy:
    installPlaybook:
      name: update-logrotate
EOF

  5. 验证

    请参阅流程 OS-P0005（验证）以跟踪政策执行状态。

Pod 卡在 ContainerCreating 状态

版本：1.13.3、1.13.5、1.13.6

症状：节点显示为正常，但有许多 Pod 处于 ContainerCreating 状态，并且您无法与服务器建立 SSH 连接。

解决方法：重新启动服务器，并确认服务器恢复运行后，您可以与节点建立 SSH 连接。

无法通过 SSH 连接到已配置的节点

版本：1.13.5

症状：节点已预配，但 SSH 在管理 IP 和数据 IP 上均超时。

解决方法：通过 iLO 重启节点。启动后，通过 SSH 登录并使用 systemctl stop clamonacc; systemctl disable clamonacc 停用 clamonacc。

Operations Suite Infrastructure (OI)

硬件 3.0 不需要 SSA

硬件 3.0 的 RAID 适配器配置有所不同。硬件 3.0 OIC 服务器使用自加密驱动器，因此不再需要启动智能存储管理 (SSA)。您需要执行其他步骤，才能确定每个服务器上的磁盘标识符。请参阅 OI 服务器引导。

边界安全

组织系统集群在组织引导期间卡住

版本：1.13.1

症状：在组织启动期间，组织系统集群可能会卡住。edr-sidecar-injector pod 处于待处理状态。当您尝试删除这些 pod 时，可能会看到类似如下的错误消息：

Delete failed with `Internal error occurred: failed calling webhook "validation.gatekeeper.sh": failed to call webhook: Post "https://gatekeeper-webhook-service.opa-system.svc:443/v1/"

与此同时，其他一些处于待处理状态的 pod 可能会显示如下错误消息：

Error creating: Internal error occurred: failed calling webhook "edr-sidecar-injector.gpc-system.internal": failed to call webhook: Post "https://edr-sidecar-injector.gpc-system.svc:443/mutate?timeout=10s": dial tcp 172.20.3.222:443: connect: connection refused

系统需要人工干预才能自行解锁。

解决方法：

  1. 在系统集群上复制 MutatingWebhookConfiguration CR edr-sidecar-injector-webhook-cfg。
  2. 在系统集群上复制 ValidatingWebhookConfiguration CR gatekeeper-validating-webhook-configuration。
  3. 从系统集群中删除 edr-sidecar-injector-webhook-cfg CR 和 gatekeeper-validating-webhook-configuration CR。
  4. 等待 edr-sidecar-injector Pod 重新启动，并等待 gatekeeper-controller-manager 重新启动。
  5. 使用 kubectl apply 命令恢复 webhook CR。

PANW 防火墙地址组不会随 CIDR 声明更改而更新

版本：1.13.1

症状：在启动过程中，OCIT cidr-claim 会更新为正确的值，但防火墙 AddressGroups 不会。一对 AddressGroups，具体而言是 vsys1-root-ocit-network-cidr-group 和 ocvsys1-root-ocit-network-cidr-group，使用与 OIR 中实际使用的网络块不重叠的网络块。OIR 无法解析 GDC 区域记录，并且查询超时，没有响应。

解决方法：在 cidr-claim 更改后，通过在根管理员集群中重启 fw-system 命名空间中的 fw-core-backend-controller 部署，确保 AddressGroup 已更新为最新的 cidr-claim。

物理服务器

由于 HPE 服务器上的 POST 问题，服务器引导失败

版本：1.13.1

症状：当服务器无法通过 POST 启动过程时，服务器引导会失败。登录 ILO 并检查服务器的控制台时，会看到以下错误：

Symptom: An Invalid Opcode Exception has occurred indicating
that the processor tried to execute an invalid, undefined opcode,
or an instruction with invalid prefixes.

Causes: This issue is typically a software or firmware issue and
not indicative of a hardware problem

Causes: This issue is typically a software or firmware issue and
not indicative of a hardware problem.

ACTION : Reboot the server.

临时解决方法：

在 iLO 中，点击电源按钮，然后选择 Cold Boot。

服务器卡在预配状态

版本：1.13.1、1.13.3、1.13.5

症状：服务器在服务器启动期间卡在配置状态。检查服务器的状态：

k get servers -A | grep -v availabl

输出可能如下所示：

NAMESPACE    NAME         AGE   RACK    MACHINE-CLASS               MANAGEMENT-IP   DATA-IP    DATA-IP   BMC-IP           CLUSTER   NODEPOOL   STATE          PROVISION-READY
gpc-system   ag-aa-bm01   21h   ag-aa   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.0         203.0.113.0                         provisioning
gpc-system   ag-ab-bm01   21h   ag-ab   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.1         203.0.113.0                         provisioned    true
gpc-system   ag-ac-bm01   21h   ag-ac   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.2         203.0.113.0                         provisioning

解决方法：

  1. 使用从 KIND 集群下载的配置手动启动 DHCP。在此示例中，/tmp/dhcp.conf 是来自 KIND 集群的 DHCP 配置：

    docker run  -d -it --network host --name dnsmasq -v /tmp/dhcp.conf:/etc/dnsmasq.conf --cap-add=NET_ADMIN --restart always 198.51.100.255/gpc-system-container-images/private-cloud-staging/dnsmasq:VERSION

    将 VERSION 替换为版本，如针对根集群和组织管理员集群的手动文件组件升级中的升级说明中所述，例如 1.13.1-gdch.525。

  2. 检查服务器上的 BIOS 配置，并验证是否未为数据平面网卡（命名模式为 Slot{i}Nic{i}）启用 NetworkBoot。

  3. 通过 API 调用检查 BIOS：

    curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios -u $bmcUser:$bmcPassword

    其中，$bmcUser 和 $bmcPassword 是 ILO 的密码，可在名为 bmc-credentials-<server-name> 的 Secret 中的 cellcfg 文件或目录中找到，例如 bmc-credentials-ai-aa-bm01。验证此命令的输出是否显示 Slot1Nic1: Disabled。

  4. 如果任何 Slot{i}Nic{i} 具有 NetworkBoot，请使用 BIOS 设置 API 将其停用。

    curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios/settings -u $bmcUser:$bmcPassword -X PATCH -d '{"Attributes": {"Slot{i}Nic{i}":"Disabled"}}' -H 'content-type: application/json'

    将 Slot{i}Nic{i} 替换为载荷中存在问题的 slot 名称。

  5. 重新启动服务器。

DL380a 服务器无法预配

版本：1.13.3、1.13.4、1.13.5

症状：HPE DL380a 型号的服务器在加密作业中预配失败。 服务器 CR 的状态在服务器引导期间卡在 available：

# server name
export SERVER_NAME=

kubectl --kubeconfig "${KUBECONFIG:?must be set}" get servers ${SERVER_NAME} -n gpc-system

临时解决方法：

  1. 按照 IAM-R0004 为 root-admin-cluster 生成 KUBECONFIG。

  2. 按照 PLATAUTH-G0001 生成 SSH 密钥 root-id_rsa（适用于 CLUSTER_NS=root）。

  3. 通过向服务器自定义资源添加注解 server.system.private.gdc.goog/paused 来暂停服务器：

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" annotate server ${SERVER_NAME:?} -n gpc-system --overwrite server.system.private.gdc.goog/paused=''

  4. 通过管理 IP 登录服务器：

    export MGMT_IP=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -o=jsonpath='{.spec.managementNetwork.ips[0]}')

ssh $MGMT_IP -i ~/.ssh/root-id_rsa

  5. 手动启用加密：

    /opt/MegaRAID/storcli/storcli64 /call/eall/sall secureerase force

/opt/MegaRAID/storcli/storcli64 /c0 delete securitykey

/opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j

    您应该会看到类似于以下内容的命令输出：

    root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /call/eall/sall secureerase force
CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = Drive Secure Erase Succeeded.

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 delete securitykey
CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = None

Controller Properties :
=====================

------------------------
Ctrl Method     Result
------------------------
  0 delete Key Success
------------------------

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j
{
"Controllers":[
{
        "Command Status" : {
                "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
                "Operating system" : "Linux 5.4.0-1072-fips",
                "Controller" : 0,
                "Status" : "Success",
                "Description" : "None"
        },
        "Response Data" : {
                "Controller Properties" : [
                        {
                                "Ctrl" : 0,
                                "Method" : "Set Security using EKMS",
                                "Result" : "Please reboot the system for the changes to take effect"
                        }
                ]
        }
}
]
}

    如果您发现上一个命令未成功执行，或者看到“Invalid BIOS EKM status”等错误，请尝试重新启动服务器和 iLO，然后重新运行此步骤。

    root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j
{
"Controllers":[
{
        "Command Status" : {
                "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
                "Operating system" : "Linux 5.4.0-1072-fips",
                "Controller" : 0,
                "Status" : "Failure",
                "Description" : "None",
                "Detailed Status" : [
                        {
                                "Ctrl" : 0,
                                "Method" : "Set Security using EKMS",
                                "Result" : "-",
                                "ErrMsg" : "Invalid BIOS EKM status",
                                "ErrCd" : 255
                        }
                ]
        }
}
]
}

    如果上一个命令成功执行，请按照说明重启服务器。

  6. 手动创建逻辑驱动器：

    服务器完成重新启动后，再次通过管理 IP 登录服务器，并列出所有可用驱动器：

    ssh $MGMT_IP -i ~/.ssh/root-id_rsa

/opt/MegaRAID/storcli/storcli64 /c0 show j

    最后一个命令的输出可能如下所示：

    {
  "Controllers":[
  {
    "Command Status" : {
      "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
      "Operating system" : "Linux 5.4.0-1072-fips",
      "Controller" : 0,
      "Status" : "Success",
      "Description" : "None"
    },
    "Response Data" : {
      "Product Name" : "HPE MR416i-o Gen11",
      "Serial Number" : "******",
      "PCI Slot Number" : 17,
      "SAS Address" : "******",
      "PCI Address" : "00:12:00:00",
      "System Time" : "09/12/2024 23:32:48",
      "Mfg. Date" : "09/15/23",
      "Controller Time" : "09/12/2024 23:32:47",
      "FW Package Build" : "52.26.3-5379",
      "BIOS Version" : "7.26.00.0_0x071A0000",
      "FW Version" : "5.260.03-3985",
      "Driver Name" : "megaraid_sas",
      "Driver Version" : "07.713.01.00-rc1",
      "Current Personality" : "RAID-Mode ",
      "Vendor Id" : 4096,
      "Device Id" : 4322,
      "SubVendor Id" : 5520,
      "SubDevice Id" : 808,
      "Host Interface" : "PCI-E",
      "Device Interface" : "SAS-12G",
      "Bus Number" : 18,
      "Device Number" : 0,
      "Function Number" : 0,
      "Domain ID" : 0,
      "Security Protocol" : "SPDM-1.0.0",
      "Physical Drives" : 8,
      "Drive LIST" : [
        {
          "EID:Slt" : "252:1",
          "DID" : 0,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "1.60 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "MO001600PXVRU   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:2",
          "DID" : 1,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "1.60 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "MO001600PXVRU   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:3",
          "DID" : 2,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:4",
          "DID" : 3,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:5",
          "DID" : 4,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:6",
          "DID" : 5,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:7",
          "DID" : 6,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:8",
          "DID" : 7,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        }
      ],
      "Enclosures" : 1,
      "Enclosure LIST" : [
        {
          "EID" : 252,
          "State" : "OK",
          "Slots" : 8,
          "PD" : 8,
          "PS" : 0,
          "Fans" : 0,
          "TSs" : 0,
          "Alms" : 0,
          "SIM" : 0,
          "Port#" : "2I"
        }
      ]
    }
  }
  ]
}

    您应保存 2 个 EID:Slt ID，其中 Size 等于 1.60 TB，在本例中：

    252:1,252:2

    然后，使用 EID:Slt ID 创建逻辑驱动器：

    /opt/MegaRAID/storcli/storcli64 /c0 add vd type=raid1 drives=252:1,252:2 SED

    最后一个命令的输出类似于以下示例：

    /opt/MegaRAID/storcli/storcli64 /c0 add vd type=raid1 drives=252:1,252:2 SED

CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = Add LD Succeeded.

  7. 服务器 CR 中的模拟磁盘加密状态。

    修改服务器 CR 的状态：

    kubectl edit-status --kubeconfig "${KUBECONFIG:?must be set}" server ${SERVER_NAME:?} -n gpc-system

    添加或修改 DiskEncryptionEnabled 状态，将其设为 true：

      - lastTransitionTime: "<time>"
    message: ""
    observedGeneration: 1
    reason: DiskEncryptionJobSucceeded
    status: "True"
    type: DiskEncryptionEnabled

  8. 删除服务器加密作业（如果有）：

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" delete job server-encrypt-and-create-logical-drive-${SERVER_NAME:?} -n gpc-system

  9. 取消暂停服务器，以便继续进行配置：

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" annotate server ${SERVER_NAME:?} -n gpc-system --overwrite server.system.private.gdc.goog/paused-

在没有许可的情况下，安全擦除失败

版本：1.13.5

症状：如果服务器在安装过程中卡住，您可能会在服务器 CR 上看到如下状态：

- lastTransitionTime: "2024-09-10T20:28:33Z"
   message: 'unable to trigger secure erase: unable to complete secure erase
     for server "zx-ad-bm07": failed to post payload to /redfish/v1/Systems/1/Actions/Oem/Hpe/HpeComputerSystemExt.SecureSystemErase:
     400: {"error":{"code":"iLO.0.10.ExtendedInfo","message":"See @Message.ExtendedInfo
     for more information.","@Message.ExtendedInfo":[{"MessageId":"iLO.2.27.LicenseKeyRequired"}]}}'
   reason: Succeeded
   status: "False"
   type: BMCConfigPreinstallSecureEraseTriggered

解决方法：按照 SERV-R0014 运行手册中的说明操作。

平台安全性

BYO SubCA 协调器未验证证书是否具有匹配的公钥

版本：1.13.1

症状：在 PKI BYO SubCA 模式下，当生成新的证书签名请求 (CSR) 时，如果之前签名的证书已上传到 SubCA，协调器不会检查新的 CSR 是否与旧的签名证书匹配，而是将 cert-manager CertificateRequest 自定义资源 (CR) 标记为 Ready。这种情况发生在 SubCA 证书续订或手动轮替期间。cert-manager 控制器尝试更新 Certificate CR 状态，这会触发以下错误消息：

The certificate request has failed to complete and will be retried: Error signing certificate: error creating x509 │
│  certificate: x509: provided PrivateKey doesn't match parent's PublicKey

临时解决方法：

按照说明为新 CSR 上传新的已签名的自带 SubCA 证书。

cert-manager 问题导致无法成功颁发使用 ACME 的 PKI BYO

版本：1.13.1

症状：在首次签发或续订自带证书时，使用自动证书管理环境 (ACME) 发生故障。当您运行命令来检查证书状态时，会看到证书处于 not ready 状态：

kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert

输出类似于以下内容：

status:
  conditions:
  - lastTransitionTime: "2024-07-23T17:27:02Z"
    message: 'reconciling Certificate status failed: cert-manager Certificate CR "default-wildcard-cert-pki-ct"/"pki-system" is not ready'
    observedGeneration: 1
    reason: ReconcileBackoff
    status: "False"
    type: Ready

临时解决方法：

重启组织管理员集群中的 cert-manager 部署：

export KUBECONFIG=ORG_ADMIN_KUBECONFIG

kubectl rollout restart deployment/cert-manager -n cert-manager

资源管理器

无法从 GDC 控制台获取项目状态

版本：1.13.1 及更高版本

症状：GDC 控制台不显示项目的状态。 处于非Ready状态的项目无法支持新资源或处理对现有资源的新修改。由于无法确认项目状态，因此不清楚何时可以管理项目的资源，这会导致在尝试执行新的项目操作时出现错误。

解决方法：请参阅 RM-R0100 运行手册，了解如何使用 kubectl CLI 打印项目状态。

升级

bm-system 和其他卡住的作业

版本：1.13.1

症状：运行 Ansible playbook 的 bm-system 和其他作业卡在 gathering facts。

解决方法：输入卡住的节点的名称，然后运行 multipath -ll | grep failed 和 multipath -ll | grep #。如果结果不为空，请按照运行手册 FILE R0020 和 FILE R0021 操作。

无法访问的管理 IP

版本：1.13.1、1.13.3、1.13.4、1.13.5

症状：在升级期间，服务器的管理 IP 无法访问，尤其是在交换机之后。

在 Rocky Linux 中，添加静态路由时，用于到达静态路由的目标 IP 必须在添加静态路由之前可访问。如果交换机在操作系统升级后重新启动，则该管理 IP 可能暂时无法访问。

解决方法：使用数据 IP 地址建立与服务器的 SSH 连接，然后重启网络服务以重新创建缺少的静态路由：

systemctl restart NetworkManager.service

storagecluster 的版本号未显示

版本：1.13.3

症状：升级后，StorageCluster CR 的 StorageVersion 状态字段不显示任何值。

检查版本：

kubectl --kubeconfig <var>ROOT_ADMIN_KUBECONFIG</var> get StorageCluster -n gpc-system

如果版本字段为空，请按照相应解决方法中的步骤操作。

解决方法：重启 file-storage-backend-controller deployment：

kubectl --kubeconfig  <var>ROOT_ADMIN_KUBECONFIG</var> rollout restart deployment -n file-system file-storage-backend-controller

裸金属服务器卡在预配状态

版本：1.13.1

症状：

创建组织时，裸金属服务器长时间停留在“正在预配”状态。

解决方法：

服务器的 BIOS 配置可能已更改，导致服务器使用错误的网卡进行 PXE 启动。

请按照以下步骤停用数据平面 NIC 网络启动。

  • 所需权限：
    • 您需要有权访问卡住的服务器的 BMC 管理员凭据。
    • 按照 IAM-R0005 中的说明在 root-admin 集群中获取 ClusterRole hardware-admin 角色 1 小时。
    • 按照 IAM-R0004 为 root-admin 集群生成 KUBECONFIG。

  1. 设置卡住的服务器的名称。

    export SERVER_NAME=

  2. 设置服务器 BMC 的 IP 和凭据。

    export ip=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -ojsonpath='{.spec.bmc.ip}')
export BMC_CREDENTIALS_SECRET=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -ojsonpath='{.spec.bmc.credentialsRef.name}')
export user=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get secret ${BMC_CREDENTIALS_SECRET:?} -n gpc-system -ojsonpath='{.data.username}' | base64 -d)
export pass=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get secret ${BMC_CREDENTIALS_SECRET:?} -n gpc-system -ojsonpath='{.data.password}' | base64 -d)

  3. 确定服务器上数据平面网卡的 PCIe 插槽。

    kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME} -n gpc-system -o jsonpath={.spec.serverHardware.portBond.nicPortNames}

    例如，以下输出表明网卡安装在插槽 3 上。

    ["s3p1","s3p2"]

    设置 PCIEslot 变量：

    export DATA_NIC_SLOT=3

  4. 确认网络启动未被停用。

    curl -ks -u $user:$pass https://$ip/redfish/v1/systems/1/bios/settings  | jq .Attributes | grep "Slot${DATA_NIC_SLOT}NicBoot1"

    如果结果为“NetworkBoot”，则需要明确将其停用。

  5. 使用 BMC 停用数据平面网卡上的网络启动功能。

    将以下命令中的“Slot3”替换为实际的卡槽号。

    curl -k -u "$user":"$pass" -H "Content-Type: application/json" https://$ip/redfish/v1/systems/1/bios/settings/ -X PUT --data '{"Attributes":{"Slot3NicBoot1":"Disabled"}}' | jq

    然后重新启动计算机。

    curl -k -u "$user":"$pass" -H "Content-Type: application/json" https://$ip/redfish/v1/Systems/1/Actions/ComputerSystem.Reset/ -X POST -d '{"ResetType": "ForceRestart"}' | jq

    服务器需要 10 到 15 分钟才能恢复运行，并会自动恢复配置流程。

对象存储升级在飞行后或飞行前检查期间显示错误

版本：1.13.1

症状：预检或后检失败，并显示错误。 查看日志：

kubectl logs -n gpc-system upgrade-managed-check-objectstorageupgrade-87698-rrjhrW0410

错误可能如下所示：

 03:42:05.701163       1 upgrade_check.go:276] 1 error occurred:
      * Group "/rbac.sysstd.role.vm-system.wtwf7txfmbhvujhpxrfampnrkdwqsvzro6i7rmo5tsfst4wbxldq" not ready for RBAC resource {Role vm-system g-vm-image-bucket-reader    }

   Error: check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
      * Bucket "gpc-system/range-read-internal" not ready

  F0410 03:42:05.701901       1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
      * Bucket "gpc-system/range-read-internal" not ready

解决方法：

  1. 如果错误发生在飞行后检查期间，并且所有其他检查均已完成且未出现任何错误，请跳过飞行后检查。当升级重新开始时，您还必须使用根管理员 kubeconfig 跳过预检检查：

    kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

    例如，如果错误发生在组织 1 上，则命令如下所示：

    kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok

  2. 如果错误发生在预检检查期间，并且所有其他预检检查均已完成且未出现任何错误，请跳过预检检查：

    kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

    例如，如果错误发生在组织 1 上，则命令如下所示：

    kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok

如果此解决方法未能成功应用，您可能需要多次应用。

Helm 升级回滚

版本：1.13.3

症状：Helm 升级问题导致一系列回滚，无法找到 Certificate 和 ServiceEntry。您可能会看到类似如下内容的消息：

REVISION        UPDATED                         STATUS          CHART                                   APP VERSION             DESCRIPTION
91              Thu Jul 18 13:26:42 2024        deployed        iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Upgrade complete
9138            Fri Jul 19 22:21:56 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9139            Fri Jul 19 22:22:04 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9140            Fri Jul 19 22:22:16 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9141            Fri Jul 19 22:22:30 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9142            Fri Jul 19 22:22:35 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9143            Fri Jul 19 22:22:42 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9144            Fri Jul 19 22:22:48 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9145            Fri Jul 19 22:22:56 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9146            Fri Jul 19 22:23:04 2024        failed          iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found

解决方法：按照 OCLCM-R0122 运行手册中的步骤操作。

由于 dhcp-tftp-core-server pod 未排空，导致节点升级或 ABM 卡住

版本：1.13.3、1.14.4、1.14.5

症状：节点升级可能会卡住。在裸机状态下，dhcp-tftp-core-server pod 未被排空。您可能会看到类似如下内容的消息：

bareMetalMachineDrainingStatus:
    currentDrainingStage: SystemCriticalPriorityClass
    podsYetToDrain:
    - name: dhcp-tftp-core-server-7ffcfcbb97-6wlg7
      namespace: dhcp-system
      resourceVersion: "5005530"
      uid: f77826ea-1d57-46ff-a699-f42faa36c1d2

解决方法：强制删除 dhcp-tftp-core-server-* pod 以继续操作。该命令如下所示：

kubectl delete pod dhcp-tftp-core-server-7ffcfcbb97-6wlg7 -n dhcp-system --force

OrganizationUpgrade 卡在节点升级阶段

版本：1.13.3

症状：OrganizationUpgrade 卡在节点升级阶段。您可能会看到类似如下内容的消息：

  Last Transition Time: 2024-08-27T12:37:40Z
    Message:             observed the following reason: [JobRunning]
    Observed Generation: 614
    Reason:              Unsuccessful
    Status:              Unknown
    Type:                service/Node

解决方法：

  1. 检查根集群 ka get upgradetaskrequest -n gpc-system 中是否存在 upgradetaskrequest CR。检查节点是否仍处于运行状态。确保它卡在服务任务上。

    spec:
    clusterType: service
Last Transition Time: 024-08-27T12:37:40Z
  Message:            job gpc-system/v1.13.0-os-aa505d9004-upg-task-org-1-os-node-upgra-czwwd is running
  Observed Generation: 1
  Reason:              JobRunning
  Status:              Unknown
  Type:                Succeeded

  2. 手动为每个节点池声明创建 nodeupgrade CR：

    export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get nodepoolclaims -n g-org-1-shared-service-cluster
NAME                                                     AGE
control-plane-node-pool                                  34d
dbs-billing-system-billing-dbcluster-n2-standard-4-gdc   34d
shared-service-default-worker                            34d

  3. 为每个节点池声明创建一个 nodeupgrade CR。注解 upgrade.private.gdc.goog/target-release-version 的详细信息必须从目标的操作系统 CRMD 名称中获取：

    kubectl get crmd  --kubeconfig ${ROOT_ADMIN_KUBECONFIG} | grep "os"
os-1.13.1-gdch.525                     35d
os-v1.13.0-os-4175a6dce6               27d
os-v1.13.0-os-aa505d9004               5d18h

  4. 在注释 upgrade.private.gdc.goog/target-release-version 中使用此处的版本：

    kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get crmd os-v1.13.0-os-aa505d9004 -o json | jq -r '.spec.config.vmNodeImage'
rocky-86-1.13-v20240731-1.13-r191

  5. 为每个 nodepoolclaim 应用以下 yaml：

        apiVersion: upgrade.private.gdc.goog/v1alpha1
    kind: NodeUpgrade
    metadata:
      annotations:
        upgrade.private.gdc.goog/target-release-version: VERSION
      name: NAME
      labels:
        addon.private.gdc.goog/cluster-type: service
      namespace: NAMESPACE
    spec:
      inFlightConf:
        maxConcurrentNodes: 1
      nodePoolClaimRef:
        name: NAME
        namespace: NAMESPACE
      nodeType: Virtual
      software:
        osImage:
          name: NAME
          version: VERSION

  6. 在服务集群节点完成节点升级后，将 UpgradeTaskRequest CR 状态更新为 True，以便组织升级继续进入下一阶段：

        kubectl patch upgradetaskrequest  upg-task-org-1-os-node-upgrade-task-pckxn --type='json' -p='[{"op": "replace", "path": "/status/conditions/0/status", "value": "True"}]' --subresource=status -n gpc-system --kubeconfig /root/release/root-admin/root-admin-kubeconfig

  7. 组织升级现在应进入下一阶段，服务或节点的状态将变为“完成”：

    Last Transition Time: 2024-08-27T22:44:09Z
  Message:             observed the following reason: [JobRunning]
  Observed Generation: 614
  Reason:              Complete
  Status:              True
  Type:                service/Node

内核无法创建容器

版本：1.13.3

症状：内核无法分配 cgroup 内存，导致创建新容器失败。

您可能会看到类似如下内容的消息：

Conditions:
  Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          Message
  ----                          ------    -----------------                 ------------------                ------                          -------
  FrequentContainerdRestart     False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentContainerdRestart     containerd is functioning properly
  KernelDeadlock                False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   KernelHasNoDeadlock             kernel has no deadlock
  ReadonlyFilesystem            False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   FilesystemIsNotReadOnly         Filesystem is not read-only
  ContainerRuntimeUnhealthy     False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 10:52:30 +0000   ContainerRuntimeIsHealthy       Container runtime on the node is functioning properly
  FrequentUnregisterNetDevice   False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentUnregisterNetDevice   node is functioning properly
  KubeletUnhealthy              False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   KubeletIsHealthy                kubelet on the node is functioning properly
  FrequentKubeletRestart        False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentKubeletRestart        kubelet is functioning properly
  FrequentDockerRestart         False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentDockerRestart         docker is functioning properly
  MemoryPressure                Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  DiskPressure                  Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  PIDPressure                   Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  Ready                         Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.

[root@zv-aa-bm01 ~]# journalctl -u kubelet -f | grep cilium-agent
Aug 29 17:29:47 zv-aa-bm01 kubelet[48625]: E0829 17:29:47.941493   48625 pod_workers.go:1298]
"Error syncing pod, skipping" err="failed to \"StartContainer\" for \"cilium-agent\" with CrashLoopBackOff: \"back-off 5m0s restarting failed container=cilium-agent pod=anetd-pvmz4_kube-system(db55cbd2-36e3-4d20-8c6b-edbb5191232d)\"" pod="kube-system/anetd-pvmz4" podUID="db55cbd2-36e3-4d20-8c6b-edbb5191232d"
Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.

并且节点正在使用大量 cgroup：

# cat /proc/cgroups | grep memory
memory  12      380360  1

解决方法：

请完成以下任一操作：

  1. 在节点上运行 echo 3 > /proc/sys/vm/drop_caches，然后重启 kubelet。
  2. 如果上一种方法不起作用，请尝试重启节点。

与外部集群 VIP 的连接间歇性失败

版本：1.13.3

症状：与外部集群虚拟 IP (VIP)（例如控制平面 VIP、istio-gateway VIP 或 Harbor VIP）的连接间歇性失败，导致出现 dial tcp :: connect: no route to host 错误。

如需诊断此问题，请按以下步骤操作：

  1. 连接到根管理员集群。 此问题解决方法假定您正在调试根管理员集群中的 IP 地址。如果您要调试与其他 Kubernetes 集群（例如组织管理员集群或组织系统集群）的连接问题，请将 KUBECONFIG 值更改为正确的集群 kubeconfig 路径。

  2. 已知有两类 IP 会受到影响。 检查边界网关协议 (BGP) 是否将 IP 地址通告到架顶 (ToR) 交换机：

    • 如果 IP 是 Kubernetes 控制平面 IP 地址（例如 192.0.2.100），请使用以下命令获取配置信息：

      KUBECONFIG=KUBECONFIG
kubectl cluster-info
# Kubernetes control plane is running at https://192.0.2.100:443`

      将 KUBECONFIG 替换为根管理员集群中 kubeconfig 文件的路径。

    • 对于某些配置，BGPAdvertisedRoute 自定义资源用于定义 IP 地址中的哪些路由通过 BGP 通告给其他网络或系统。如果 IP 地址由 BGPAdvertisedRoute 自定义资源通告，请使用以下命令获取配置信息：

      TARGET_IP=TARGET_IP_ADDRESS
KUBECONFIG=KUBECONFIG
kubectl get BGPAdvertisedRoute -A --kubeconfig=$KUBECONFIG | grep $TARGET_IP

      将 TARGET_IP_ADDRESS 替换为遇到间歇性连接问题的 IP 地址。

  3. 查看 BGPSession 自定义资源的状态。BGPSession表示在 Kubernetes 集群与外部 BGP 对等方之间建立的单个 BGP 对等互连会话。检查 BGPAdvertiser pod 的日志，并验证所有 BGPSession 资源是否都处于 Established 状态：

    KUBECONFIG=KUBECONFIG
kubectl get pods -l app=bgpadvertiser -n kube-system

# Based on the name of pods, check their logs
kubectl logs pod/bgpadvertiser-gpc-adhoc-6a265a03vm-worker-node0-zone1 -n
kube-system --kubeconfig=$KUBECONFIG`

    运行正常的 BGPAdvertiser pod 的输出包含以下代码段：

    I0904 04:32:19.999906       1 main.go:217] BGP advertiser serving...\
time="2024-09-04T04:32:25Z" level=info msg="Peer Up" Key=10.200.0.1
State=BGP_FSM_OPENCONFIRM Topic=Peer\

  4. 验证连接的稳定性。创建并运行脚本，以检查连接是否时断时续或不稳定：

    1. 创建脚本：

      #!/bin/bash

TARGET=$1
CNT=0
for i in {1..100}; do
    output=$(curl --no-progress-meter -k https://$TARGET 2>&1)
    if echo "$output" | grep -q "No route to host"; then
            CNT=$((CNT+ 1))
            echo "Attempt $i: $output"
    fi
    sleep 0.1
done
echo "$CNT out of 100 runs hit No route to host error"

    2. 运行脚本：

      ./script.sh TARGET_IP_ADDRESS:PORT

      将 PORT 替换为出现问题的端口号。

      如果连接存在问题，您会看到如下输出：

      Attempt 2: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host
Attempt 4: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host
Attempt 7: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host`

  5. 之前的输出确认了问题。检查 TOR 交换机上的路由，看看 TOR 交换机配置是否是问题的根源。

    假设流量因 IP 地址 192.0.2.201（示例）而被丢弃，并且该 IP 地址由 BGPAdvertisedRoute 资源通告，请检查 BGPAdvertisedRoute 资源中的跃点，以确定潜在的故障点：

    apiVersion: networking.gke.io/v1
kind: BGPAdvertisedRoute
metadata:
  annotations:
    bgploadbalancer.networking.gke.io/servicename: istio-ingressgateway
    bgploadbalancer.networking.gke.io/servicens: istio-system
  creationTimestamp: "2024-08-20T19:03:02Z"
  generation: 150
  name: default-istio-system-istio-ingressgateway-rj2fv
  namespace: kube-system
  ownerReferences:
  - apiVersion: networking.gke.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: BGPLoadBalancer
    name: default
    uid: f681f3e5-c66a-45d6-a3ac-9d7ae26f555f
  resourceVersion: "27133500"
  uid: 8ede0c81-3aba-40ce-a441-4aec334b41bd
spec:
  bgpPeerNames:
  - 192.0.2.6-peer-10.0.1.1
  - 192.0.2.5-peer-10.0.1.0
  - 192.0.2.5-peer-10.0.1.1
  - 192.0.2.6-peer-10.0.1.0
  nextHops:
  - 192.0.2.2
  - 192.0.2.3
  - 192.0.2.4
  prefix: 192.0.2.201/32

  6. 查看 nextHops 字段中的 IP 地址。对于每个 IP 地址，找到服务器名称。例如：

    - 192.0.2.2 zt-aa-bm08
- 192.0.2.3 zt-aa-bm09
- 192.0.2.4 zt-ab-bm01

  7. 此输出显示，下一个跃点位于机架 aa 和机架 ab 中的服务器上。登录机架 aa 和 ab 中的 TOR 交换机，并比较这两个机架中的路由：

    show ip route 192.0.2.201 vrf root-external-vrf

  8. 如果两个机架中 TOR 交换机之间的路由不同，则您遇到了此解决方法可缓解的问题。此问题的输出如下所示：

    zt-aa-torsw01# show ip route 192.0.2.201 vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 3/0, all-best
*via 192.0.2.2, [20/0], 1w1d, bgp-65070, external, tag 64513
*via 192.0.2.3, [20/0], 1w1d, bgp-65070, external, tag 64513
*via 192.0.2.4, [20/0], 1w1d, bgp-65070, external, tag 64513

zt-aa-torsw02# sh ip route 192.0.2.201  vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 3/0, all-best
*via 192.0.2.2, [20/0], 1w3d, bgp-65070, external, tag 64513
*via 192.0.2.3, [20/0], 1w3d, bgp-65070, external, tag 64513
*via 192.0.2.4, [20/0], 1w3d, bgp-65070, external, tag 64513

zt-ab-torsw01# show ip route 192.0.2.201 vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 2/0, all-best
*via 10.249.88.2, [200/0], 1w1d, bgp-65070, internal, tag 64513
*via 192.0.2.3, [200/0], 1w1d, bgp-65070, internal, tag 64513

zt-ab-torsw02# sh ip route  192.0.2.201  vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 2/0, all-best
*via 192.0.2.2, [200/0], 1w3d, bgp-65070, internal, tag 64513
*via 192.0.2.3, [200/0], 1w3d, bgp-65070, internal, tag 64513

    在此输出中，机架 aa 中的路由处于预期状态，显示了针对前缀列出的三个下一跳。不过，在机架 ab 中，相应前缀只有两个下一跃点。当以该前缀为目标的流量被哈希到机架 ab 时，与缺失的下一个跃点对应的节点永远不会收到该流量，并且网络会遇到连接问题。

请按照解决方法缓解此问题。

解决方法：

此解决方法有助于解决 Kubernetes 集群中与某些 IP 地址的间歇性连接问题。

为缓解此问题，您必须对聚合交换机之间的 BGP 会话应用多项配置更改。聚合 (AGG) 交换机聚合来自多个 TOR 交换机的流量。请按以下步骤更新所有必要的配置：

  1. 名为 switchstaticconfig 的配置文件表示单个交换机上的静态配置。下载两个 AGG 交换机的 switchstaticconfig 文件：

    export KUBECONFIG=KUBECONFIG
kubectl get switchstaticconfig za-ab-aggsw01-static-config -n gpc-system -oyaml > /tmp/za-ab-aggsw01-static-config.yaml
kubectl get switchstaticconfig za-ac-aggsw01-static-config -n gpc-system -oyaml > /tmp/za-ac-aggsw01-static-config.yaml

  2. 获取环境的自治系统编号 (ASN)：

    root@bootstrapper:/tmp# kubectl get ClusterBGPRouter --kubeconfig KUBECONFIG -A -o yaml | grep networkASN | head -1
    networkASN: 65030

    此输出显示 ASN 值为 65030。您必须在后续步骤中使用此处返回的任何 ASN 值。

  3. AGG 交换机上的环回 IP 地址可作为稳定且始终处于开启状态的地址，用于管理、路由和问题排查，即使其他网络连接中断也是如此。获取每个 AGG 交换机的环回 IP 地址：

    root@bootstrapper:~# kubectl get --kubeconfig KUBECONFIG
aggswitchinternal -n gpc-system -o
jsonpath='{range.items[*]}{.metadata.name}{":\t"}{.spec.loopbackIPs}{"\n"}{end}'

    输出类似于以下内容：

    za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]

  4. 更新了 za-ab-aggsw01 AGG 开关的 staticswitchconfig。 将此代码段添加到 config 部分：

    spec:
  config: |

route-map onlydefault permit 10
match ip address prefix default
router bgp ASN
      neighbor LOOPBACK_ADDRESS
  address-family l2vpn evpn
      route-map onlydefault in

...
    key chain OSPF_AUTH_KEYCHAIN_0
      key 1

    替换以下内容：

    • ASN：上一步中的 ASN 值。在此示例中，该值为 65030。
    • LOOPBACK_ADDRESS：这是 AGG 交换机 za-ac-aggsw01 的环回 IP 地址。在此示例中，该值为 192.0.2.2。

  5. 将相同的更新应用于另一个 AGG 交换机 za-ac-aggsw01。您必须提供正确的环回地址。每个交换机的环回 IP 地址各不相同：

    za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]

  6. 创建并运行与此步骤中用于诊断问题的脚本相同的脚本，以验证修复是否成功。输出结果中未显示任何错误消息。

升级期间出现 Incorrect version of Trident 错误

版本：1.13.3、1.13.4、1.13.5

症状：从低于 1.13.3 的版本升级时，ontap 会显示 Incorrect version of Trident 错误。您可能会看到类似如下内容的消息：

Status:
  Conditions:
  Last Transition Time: 2024-08-27T15:19:07Z
  Message:              Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke5
  Observed Generation:  1
  Reason:               QualificationFailed
  Status:               False
  Type:                 AllComplete
  Events:

解决方法：

  1. 更新您要升级到的版本的 releasemetadata：

    export KUBECONFIG=<point to ROOT Admin Kubeconfig>
To get the list of all releasemetadata:
`kubectl get releasemetadata`

    输出可能如下所示：

    NAME AGE 1.12.2-gdch.785 24d 1.12.4-gdch.96 13d 1.13.3-gdch.5548 11h

  2. 选择要升级到的版本，如下例所示：

    kubectl get releasemetadata 1.13.3-gdch.5548 -o yaml > releasemetadata.yaml

  3. 将 .yaml 的 fileBlockStorage 部分下的 tridentVersion 更新为错误中提到的版本。如果错误消息如下所示：

    Message: Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke.5

    将 releasemetadata.yaml 中的 tridentVersion 更改为 v23.10.0-gke.5。

    例如，如果原始值为：infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.6，

    将其更改为以下值：

    infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.5。

  4. 应用更改：

    kubectl apply -f releasemetadata.yaml

  5. 再次应用ontap存储空间升级。

pod 无法安排

版本：1.13.3。1.13.4、1.13.5

症状：在用户集群配置期间，某些 pod 无法被调度。您可能会看到类似如下内容的消息：

0/6 nodes are available: 1 Insufficient cpu. preemption: 0/6 nodes are available: 6 No preemption victims found for incoming pod

解决方法：

扩大用户集群控制平面节点池的规模：

  kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch addresspoolclaim/control-plane-node-pool -n ${CLUSTER_NAME}-cluster --type=json -p="[{'op': 'replace', 'path': '/spec/size', 'value': 5}]"
  kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch nodepoolclaim/control-plane-node-pool -n ${CLUSTER_NAME}-cluster --type=json -p="[{'op': 'replace', 'path': '/spec/nodeCount', 'value': 5}]"

升级在 iac-zoneselection-global 子组件中失败

版本：1.13.1

症状：在升级到 1.13.3 期间，子组件 iac-zoneselection-global 上出现错误。您可能会看到类似如下内容的消息：

== Subcomponents with failures in root org ===
Sub-Component: iac-zoneselection-global - Reconciliation error: E0100 - deploy: failed to install chart: release iac-zoneselection-global-backend failed, and has been uninstalled due to atomic being set: 1 error occurred:
        * ZoneSelection.location.mz.global.private.gdc.goog "iac" is invalid: spec.resultObjectName: Required value

Events: Type     Reason               Age                   From          Message
----     ------               ----                  ----          -------
Warning  ReconciliationError  119s (x521 over 20h)  Subcomponent  E0100 - deploy: failed to install chart: release iac-zoneselection-global-backend failed, and has been uninstalled due to atomic being set: 1 error occurred:
         * ZoneSelection.location.mz.global.private.gdc.goog "iac" is invalid: spec.resultObjectName: Required value

解决方法：

升级到 1.13.3 可修正此错误。

升级检查作业已超出截止期限

版本：1.12.x、1.13.x

症状：在组织升级期间，升级检查显示状态 False，原因是 DeadlineExceeded。您可能会看到类似如下内容的消息：

  Preflight Check:                                                                                                                                                                                                          
    Conditions:                                                                                                                                                                                                             
      Last Transition Time:  2024-10-29T18:57:47Z                                                                                                                                                                           
      Message:               the result has status: False, reason: PreflightCheckFailed, and err: [check "OPAUpgrade" of operable component "OPA" failed with reason "DeadlineExceeded", no existing pods found, check "Arti
actAvailability" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods found, check "PackageValidation" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods foun
d, check "IAMUpgrade" of operable component "IAM" failed with reason "DeadlineExceeded", no existing pods found, check "NodeHealth" of operable component "OS" failed with reason "DeadlineExceeded", no existing pods found
, check "DNSHealth" of operable component "DNS" failed with reason "DeadlineExceeded", no existing pods found, check "AdminClusterCheck" of operable component "UPORC" failed with reason "DeadlineExceeded", no existing po
ds found[]                                                                                                                                                                                                                  
      Observed Generation:   3                                                                                                                                                                                              
      Reason:                PreflightCheckFailed                                                                                                                                                                           
      Status:                False                                                                                                                                                                                          
      Type:                  Succeeded                                                                                                                                                                                      
    Start Time:              2024-10-29T17:57:47Z

解决方法：

  1. 删除与失败的升级检查对应的失败的升级检查作业。
  2. 等待升级检查作业重新创建。
  3. 查看重新创建的作业的日志，并对问题进行初步诊断。

由于 strongswan 位置位于不同的运行时目录中，meta-monitoring 插件失败

版本：1.12.x、1.13.x

症状：在升级到 1.13.4 或 1.13.5 期间，meta-monitoring 加载项失败：

kubectl --kubeconfig ORG_ADMIN_KUBECONFIGget addons -A | grep meta-monitoring
org-1-system-cluster                                      meta-monitoring                                      false                                        false                                      1.12.4-gdch.96

检查插件：

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG get -n org-1-system-cluster addon meta-monitoring -o yaml

条件消息可能如下所示：

status:
  conditions:
  - lastTransitionTime: "2024-11-19T02:57:30Z"
    message: 'Error occurred during addon installation: failed to rollback chart:
      create: failed to create: Internal error occurred: failed calling webhook "validation.gatekeeper.sh":
      failed to call webhook: Post "https://gatekeeper-webhook-service.opa-system.svc:443/v1/admit?timeout=3s":
      context deadline exceeded'
    observedGeneration: 2
    reason: InstallationError
    status: "False"
    type: Deployed

解决方法：

  1. 确保组织系统集群中的 BGP 会话失败，例如：

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG get bgpsessions -A
NAME                                           LOCAL ASN   PEER ASN   LOCAL IP        PEER IP     STATE   LAST REPORT
10.252.122.10-peer-10.0.1.32-vm-7351eebe       64513       65030      10.252.122.10   10.0.1.32           
10.252.122.10-peer-10.0.1.33-vm-7351eebe       64513       65030      10.252.122.10   10.0.1.33           
10.252.122.11-peer-10.0.1.32-vm-7351eebe       64513       65030      10.252.122.11   10.0.1.32           
10.252.122.11-peer-10.0.1.33-vm-7351eebe       64513       65030      10.252.122.11   10.0.1.33           
172.20.128.3-peer-10.0.1.48-za-aa-bm02-hltg2   64513       65030      172.20.128.3    10.0.1.48           
172.20.128.3-peer-10.0.1.49-za-aa-bm02-hqblq   64513       65030      172.20.128.3    10.0.1.49

  2. 确保 ang-node Pod 停留在 ContainerCreating 状态，例如：

    kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG get pods -n kube-system -l app=ang-node
NAME                                                 READY   STATUS              RESTARTS        AGE
ang-node-5c6c8                                       0/3     ContainerCreating   0               2d21h
ang-node-6skkl                                       0/3     ContainerCreating   0               2d14h
ang-node-7d7dj                                       0/3     ContainerCreating   0               2d20h
ang-node-9l4xc                                       0/3     ContainerCreating   0               2d17h

    系统会显示以下错误：

    Warning  FailedMount  112s (x2056 over 2d21h)  kubelet  MountVolume.SetUp failed for volume "vici" : hostPath type check failed: /var/run/strongswan is not a directory

  3. 对组织管理员集群中的 ang-overrides AddonConfiguration 应用以下更改：

    kubectl --kubeconfig ORG_ADMIN_KUBECONFIG edit addonconfiguration ang-overrides -n org-1-system-cluster

    更改以下内容：

                volumes:
            - hostPath:
                path: /var/run/strongswan
                type: Directory
              name: vici

    更改为以下内容：

                volumes:
            - hostPath:
                path: /var/run
                type: Directory
              name: vici

  4. 大约一分钟后，确认 ang-node Pod 现在处于 Running 状态：

    NAME             READY   STATUS    RESTARTS   AGE
ang-node-7hj5q   3/3     Running   0          15s
ang-node-xps2m   3/3     Running   0          34s
ang-node-krx8p   3/3     Running   0          34s
ang-node-cbm1a   3/3     Running   0          34s

  5. 确保 Org 系统集群中的 BGP 会话现在正在运行。

  6. meta-monitoring 加购项将进入下一阶段。

根组织的升级卡在签名作业失败上

版本：1.13.3、1.13.4

症状：从 1.13.3 升级到 1.13.4 时，您可能会看到类似如下内容的消息：

Message:       [the result has status: False, reason: PreflightCheckFailed, and err: check "PackageValidation" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods found, the result has status: Unknown, reason: UpgradeCheckJobsInProgress

解决方法：

  1. 停用预检检查：

    kubectl annotate -n gpc-system organization root upgrade.private.gdc.goog/skip-preflight-check=ok

  2. 删除失败的 artifact-signature-verification-*** 作业。

  3. 等待根升级完成。

  4. 可选：如果环境升级到 1.13.4 或更高版本，请启用预检检查。

当控制器达到 1.13.4 时，升级不应再出现此问题。

租户组织在预检检查阶段失败，并显示 ErrImagePull

版本：1.13.3

症状：租户组织升级在预检检查阶段失败，并显示软件包验证 pod 的 ErrImagePull。您可能会看到类似如下内容的消息：

export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get po -n package-validation-system  | grep artifact-signature-verification

Pod 显示 ImagePullBackOff 错误：

kubectl describe po -n package-validation-system POD_NAME

系统会显示映像拉取错误，例如：

Name:             artifact-signature-verification-20240823224755-4ppkt
Namespace:        package-validation-system
Priority:         0
Service Account:  package-validation
Node:             ak-ab-base02/203.0.113.250
Start Time:       Fri, 23 Aug 2024 22:47:55 +0000
Labels:           batch.kubernetes.io/controller-uid=bf81d5eb-d597-464e-a907-67c1c8a11c11
                  batch.kubernetes.io/job-name=artifact-signature-verification-20240823224755
                  controller-uid=bf81d5eb-d597-464e-a907-67c1c8a11c11
                  job-name=artifact-signature-verification-20240823224755
Annotations:      <none>
Status:           Pending
IP:               203.0.113.255
IPs:
  IP:           203.0.113.255
Controlled By:  Job/artifact-signature-verification-20240823224755
Containers:
  artifact-signature-verification:
    Container ID:
    Image:          gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004
    Image ID:
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       ImagePullBackOff
    Ready:          False
    Restart Count:  0
...
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                     From               Message
  ----     ------     ----                    ----               -------
  Normal   Scheduled  10m                     default-scheduler  Successfully assigned package-validation-system/artifact-signature-verification-20240823224755-4ppkt to ak-ab-base02
  Normal   Pulling    7m25s (x4 over 9m22s)   kubelet            Pulling image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004"
  Warning  Failed     7m14s (x4 over 9m12s)   kubelet            Failed to pull image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": failed to pull and unpack image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": failed to resolve reference "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": unexpected status from HEAD request to https://203.0.113.255/v2/private-cloud-staging/signature-verifier/manifests/v1.13.0-uporc-aa505d9004?ns=gcr.io: 401 Unauthorized
  Warning  Failed     7m14s (x4 over 9m12s)   kubelet            Error: ErrImagePull
  Warning  Failed     7m3s (x6 over 9m11s)    kubelet            Error: ImagePullBackOff
  Normal   BackOff    4m11s (x17 over 9m11s)  kubelet            Back-off pulling image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004"

解决方法：

跳过预检检查：

kubectl annotate -n gpc-system organization ORG_NAME \
upgrade.private.gdc.goog/skip-preflight-check=ok

在根组织升级期间找不到 serviceaccount

版本：1.13.8、1.13.9

症状：在升级到 1.13.8 期间，如果之前已完成升级并且附加服务已存在，则 RBAC 的 addon 部署会失败。症状可能处于以下任一阶段：

  1. 飞行前或飞行后检查
  2. 涉及升级任务的任何阶段，并且消息表明作业正在运行，即使任务卡住也是如此。status.conditions 消息表示作业已运行很长时间，表明存在问题。

如需检查是否存在升级预检检查失败，请检查升级组织的相应 OrganizationUpgrade 对象的状态：

  kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml

  1. 如果作业在 PreflightCheck 阶段失败，可能会显示如下失败消息或 UpgradeCheckRBACDeploymentInProgress 消息：

      - lastTransitionTime: "2024-09-27T00:28:21Z"
    message: ""
    observedGeneration: 2
    reason: Unknown
    status: "False"
    type: PreflightCheck

  2. 如果作业在运行任务作业的 AnthosBareMetal (ABM) 阶段失败，则会显示以下输出：

    - Last Transition Time:  2024-09-26T19:55:13Z
  message:               observed the following reason: [JobRunning]
  observedGeneration:    3
  reason:                Unsuccessful
  status:                Unknown
  type:                  root-admin/AnthosBareMetal

  3. 如果失败发生在检查中，则 upgradecheckrequest CR 会失败：

    kubectl get upgradecheckrequests -n gpc-system  --kubeconfig /root/release/root-admin/root-admin-kubeconfig

    输出可能如下例所示：

    NAME                                   AGE
upgrade-check-root-postflight-xc7p8    6h32m

  4. 如果故障发生在任务中，upgradetaskrequests CR 会失败：

    kubectl get upgradetaskrequests -n gpc-system  --kubeconfig /root/release/root-admin/root-admin-kubeconfig

    输出可能如下例所示：

    NAME                                          AGE
upg-task-org-1-mz-mz-location-upgrade-5n6wp   2d19h

  5. 如果失败表明在查找服务账号时出现 RBAC 错误，请检查是否已部署之前的插件：

    Type     Reason        Age                   From            Message
----     ------        ----                  ----            -------
Warning  FailedCreate  38s (x11 over 5m41s)  job-controller  Error creating: pods "v1.13.0-mz-2837f80328-upg-task-root-mz-mz-location-jkv69-" is forbidden: error looking up service account gpc-system/upgrade-task-mz-sa-v1.13.0-mz-2837f80328: serviceaccount "upgrade-task-mz-sa-v1.13.0-mz-2837f80328" not found

临时解决方法：

  1. 检查之前是否已部署插件：

      Type     Reason        Age                    From            Message
  ----     ------        ----                   ----            -------
  Warning  FailedCreate  4m30s (x101 over 99m)  job-controller  Error creating: pods "v1.13.0-os-2837f80328-upg-task-root-os-node-upgrad-fdblm-" is forbidden: error looking up service account gpc-system/upgrade-task-os-sa-v1.13.0-os-2837f80328: serviceaccount "upgrade-task-os-sa-v1.13.0-os-2837f80328" not foundcount gpc-system/upgrade-task-mz-sa-v1.13.0-mz-2837f80328: serviceaccount "upgrade-task-mz-sa-v1.13.0-mz-2837f80328" not found

  2. 获取同一组件之前存在的插件，upgrade-task-mz 用于任务：

    kubectl get addons -n gpc-system | grep upgrade-task
upgrade-task-mz-lsqzc            true       true    v1.13.0-mz-7cf810d7a5

  3. 删除此加购项：

    kubectl delete addon -n gpc-system upgrade-task-mz-lsqzc upgrade-task-os-px5wj
addon.addon.private.gdc.goog "upgrade-task-mz-lsqzc" deleted

  4. 删除插件后，还要删除相应的 upgradetaskrequest 或 upgradecheckrequest。系统会重新创建该文件。

    kubectl delete upgradetaskrequest -n gpc-system upgrade-task-mz-lsqzc

  5. 继续监控新创建的 upgradetaskrequest、upgradecheckrequest 或直接监控相应作业。

在 shared-service-cluster upgrade 上升级失败

版本：1.13.3

症状：Anthos Bare Metal 升级卡在了一个或多个裸机上。所有其他裸机都已成功升级或尚未开始升级。一台裸机处于维护模式，但“当前 ABM 版本”和“所需 ABM 版本”字段仍显示较早的版本。

按照 Anthos Bare Metal 中的说明获取集群的 baremetalmachine 状态和详细信息：

kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG}

预期输出：

NAME           CLUSTER                  READY   INSTANCEID                  MACHINE         ABM VERSION        DESIRED ABM VERSION
192.0.2.0      g-org-1-shared-service   true    baremetal://192.0.2.0       192.0.2.0       1.29.300-gke.185   1.29.300-gke.185
192.0.2.18     g-org-1-shared-service   true    baremetal://192.0.2.18      192.0.2.18      1.29.300-gke.185   1.29.300-gke.185
192.0.2.19     g-org-1-shared-service   true    baremetal://192.0.2.19      192.0.2.19      1.29.300-gke.185   1.29.300-gke.185
192.0.2.10     g-org-1-shared-service   true    baremetal://192.0.2.10      192.0.2.10      1.29.300-gke.185   1.29.300-gke.185
192.0.2.22     g-org-1-shared-service   true    baremetal://192.0.2.22      192.0.2.22      1.29.300-gke.185   1.29.300-gke.185
192.0.2.9      g-org-1-shared-service   true    baremetal://192.0.2.9       192.0.2.9       1.29.0-gke.1449    1.29.0-gke.1449 

kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG} ${MACHINE_IP}  -o json | jq '.status.underMaintenance'

预期输出：

true

临时解决方法：

  1. 让库存机器退出维护模式：

    export InventoryMachineName=$(kubectl --kubeconfig=${ADMIN_KUBECONFIG} get inventorymachines -A  -o json | jq '.items[] | select(.spec.address=="${MACHINE_IP}") | .metadata.name')
kubectl --kubeconfig "${ADMIN_KUBECONFIG:?}" patch inventorymachine/${InventoryMachineName:?} --type=merge  -p '{"spec": {"maintenance": false}}'

  2. 等待库存机器退出维护模式。此过程最多可能需要 10 分钟。

    kubectl --kubeconfig "${ADMIN_KUBECONFIG:?}" wait inventorymachine/${InventoryMachineName} --for=jsonpath=.status.maintenance=true --timeout=600s

  3. 监控裸机，以确保机器看到所选 ABM 版本更新。

    kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG}

system-dashboards 插件安装失败

版本：1.13.5

症状：从 1.12.4 升级到 1.13.5 时，system-dashboards 插件的插件升级失败：

│ Status:                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                  │
│     Last Transition Time:  2024-10-22T00:34:54Z                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to rollback chart: no ConfigMap with the name "cluster-etcd-platform-obs" found                    │
│     Observed Generation:   2                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                   │
│     Status:                False

解决方法：按照 OCLCM-R0122 运行手册中的步骤操作。

NodeUpgradeTask CR 卡在 NodeOSInPlaceUpgradePostProcessingCompleted 条件

版本：1.13.5

症状：在升级到 1.13.5 期间，NodeUpgradeTask CR 卡在 NodeOSInPlaceUpgradePostProcessingCompleted 条件。

检查相应的 os-artifact-collector 作业是否已完成。如果作业卡住数小时，系统会显示以下消息：

  root@gpc-adhoc-7e017e71vm-bootstrapper-zone1:~# kag logs  os-artifact-collector-bm-45942837-p8hrk-z56gh 
  I1020 22:06:11.844634       1 main.go:30] BuildDate: 2024-10-19T16:54:08Z
  I1020 22:06:11.844695       1 main.go:31] Version: 0.0.0-gdch.1.v3f2043

临时解决方法：

  1. 删除作业或 pod 以强制重试。

升级期间，映像分发失败

版本：1.13.5

症状：从 1.12.4 升级到 1.13.x 期间，映像分发失败：

Error: error uploading the VM image to object storage: failed to upload to object storage: BadRequest: Bad Request
    status code: 400, request id: , host id: 
F1018 02:04:46.191627       1 main.go:88] VM Image Distributor quit: error uploading the VM image to object storage: failed to upload to object storage: BadRequest: Bad Request
    status code: 400, request id: , host id: 
goroutine 1 [running]:

检查组织中 gpc-system 中的 obj-proxy pod，看看它是否因证书验证失败而出现故障：

E1021 19:10:31.710076       1 token_source.go:185] Unable to rotate token: failed to initialize aisClient: failed to initialise AIS client: failed to obtain login config from the provided path "https://console.org-1.zone1.google.gdch.test/.well-known/login-config" with error: unable to parse centralized login config file: unsuccessful get request to config URL (https://console.org-1.zone1.google.gdch.test/.well-known/login-config) with error: Get "https://console.org-1.zone1.google.gdch.test/.well-known/login-config": tls: failed to verify certificate: x509: certificate signed by unknown authority

临时解决方法：

  1. 使用失败组织的 KUBECONFIG 重启 obj-proxy pod：

    export KUBECONFIG=<ORG_KUBECONFIG>
kubectl delete pods -n gpc-system -l name=obj-proxy-manager

  2. 检查 obj-proxy 的日志：

    kubectl get pods -n gpc-system | grep obj-proxy

    预期输出如下所示：

    obj-proxy-gdgzp                                                1/1     Running     0              5d1h
obj-proxy-nhnsm                                                1/1     Running     0              5d1h
obj-proxy-wrxlq                                                1/1     Running     0              5d1h

  3. 检查可用 pod 的日志，例如：

    kubectl logs obj-proxy-gdgzp -n gpc-system

  4. 应用此问题解决方法后，映像分发作业应会完成。

用户集群升级期间节点发生故障

版本：1.13.3

症状：在用户集群升级期间，节点上运行的作业失败，并显示如下所示的错误消息：

 Reason: mkdir: cannot create directory '/root/.ansible/tmp/ansible-tmp-1727810181.4584012-29-114086005628321': No space left on device

  1. 登录节点，然后检查分区是否已满：

    df -h /

    输出可能如下例所示：

    Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/rocky-rl--root   31G   31G  120K 100% /

  2. 检查 /etc/kubernetes/tmp 是否使用了大量空间：du -s /etc/kubernetes/tmp。当 Kubernetes 进行的备份比平时多时，就会出现此问题。

临时解决方法：

  1. 清除 rm -f /etc/kubernetes/tmp/* 上的所有备份：

    df -h /

    输出可能如下例所示：

    Filesystem                  Size  Used Avail Use% Mounted on
/dev/m

正在重新创建根管理员升级，但预检检查失败

版本：1.13.3、1.13.4、1.13.5、1.13.6、1.13.7、1.13.8、1.13.9

症状：根组织升级因预检检查失败而失败，例如：

│   Preflight Check:                                                                                                                                                             │
│     Conditions:                                                                                                                                                                │
│       Last Transition Time:  2024-10-28T14:17:31Z                                                                                                                              │
│       Message:               [the result has status: False, reason: PreflightCheckFailed, and err: check "ASMStable" of operable component "ASM" failed with reason "BackoffLi │
│ mitExceeded", please check logs in pods: [gpc-system/upgrade-managed-check-asmstable-4dw66-cld74, gpc-system/upgrade-managed-check-asmstable-4dw66-k8xk5, gpc-system/upgrade-m │
│ anaged-check-asmstable-4dw66-wtc6q, gpc-system/upgrade-managed-check-asmstable-4dw66-l9b6v, gpc-system/upgrade-managed-check-asmstable-4dw66-nf62h, gpc-system/upgrade-managed │
│ -check-asmstable-4dw66-6m7p2, gpc-system/upgrade-managed-check-asmstable-4dw66-4mqmb], the result has status: Unknown, reason: UpgradeCheckJobsInProgress, and err: upgrade ch │
│ eck jobs in progress for Operable Components: haas,bil]                                                                                                                        │
│       Observed Generation:   2                                                                                                                                                 │
│       Reason:                PreflightCheckFailed                                                                                                                              │
│       Status:                False                                                                                                                                             │
│       Type:                  Succeeded                                                                                                                                         │
│     Start Time:              2024-10-28T14:46:42Z

根管理员集群和根管理员的 kubeapiserver 已升级到所选的 ABM 版本。

示例：

export KUBECONFIG=<path to root admin kubeconfig>
kubectl describe kubeapiserver root-admin -n root
kubectl get cluster root-admin -n root

kubectl describe kubeapiserver root-admin -n root 的输出示例：

Name:         root-admin
Namespace:    root
Labels:       lcm.private.gdc.goog/cluster-type=root-admin
              lcm.private.gdc.goog/cluster-version=1.29.600-gke.108
              lcm.private.gdc.goog/component-version=v1.13.0-oclcm-f4c190e0f2

kubectl get cluster root-admin -n root 的输出示例：

NAME         ABM VERSION        DESIRED ABM VERSION   CLUSTER STATE
root-admin   1.29.600-gke.108   1.29.600-gke.108      Running

临时解决方法

应用预检检查跳过以继续升级：

export KUBECONFIG=<path to root admin kubeconfig>
kubectl delete organizationupgrade root -n gpc-system && kubectl annotate -n gpc-system organization root upgrade.private.gdc.goog/skip-preflight-check=ok 
kubectl delete organizationupgrade root -n gpc-system

命名空间 platform-obs-obs-system 或 platform-obs 卡在终止状态

版本：1.13.5

症状：在升级或引导过程中，插件部署失败，并显示如下错误消息：

 export KUBECONFIG=ROOT_ADMIN
 kubectl get addon -n org-1 system-alerts system-dashboards

输出如下所示：

  NAME                DEPLOYED   READY   VERSION
  system-alerts
  system-dashboards   false      false   1.12.4-gdch.96

如果 DEPLOYED 或 READY 状态显示 false 或为空，请检查相应插件是否存在错误，例如：

  export KUBECONFIG=ROOT_ADMIN
  kubectl describe addon -n org-1 system-alerts

输出如下所示：

  ...
  ... unable to create new content in namespace platform-obs-obs-system because it is being terminated                             
  ...

该插件已被屏蔽，因为它尝试在正在删除的命名空间中创建内容。由于命名空间删除也被阻止，因此这种阻塞会持续存在。

临时解决方法：

  1. 在开始升级之前，请对项目进行注释以防止删除：

    export KUBECONFIG=ORG_ADMIN
kubectl annotate project -n gpc-system platform-obs helm.sh/resource-policy="keep"

    输出如下所示：

    project.resourcemanager.gdc.goog/platform-obs annotated
kubectl annotate project -n gpc-system platform-obs-obs-system helm.sh/resource-policy="keep"
project.resourcemanager.gdc.goog/platform-obs-obs-system annotated

    如果环境已出现上述症状，请尝试以下解决方法：

  2. 由于存在带有终结器的资源，因此命名空间删除操作被阻止。如需继续删除，请使用提供的脚本移除 finalizer：

      export KUBECONFIG=ORG_ADMIN
  function rm_finalizer() {
      export TYPE=$1
      export NS=$2
      RESOURCES=$(kubectl get $TYPE -n $NS --no-headers -o custom-columns=":metadata.name")
      for rc in $RESOURCES; do
          kubectl patch $TYPE $rc -n $NS \
                  --type json \
                  --patch '{"metadata":{"finalizers":[]}}' --type=merge
      done
    }
    rm_finalizer "monitoringrule" "platform-obs-obs-system"
    rm_finalizer "monitoringrule" "platform-obs"
    rm_finalizer "loggingrule" "platform-obs"
```
Note: Use a bash terminal (default on bootstrappers) to run the script.

  3. 等待资源删除。运行脚本后，删除资源和正在终止的命名空间。如果命名空间仍卡在终止状态，您可能需要再次运行脚本。终止后，系统会自动重新创建命名空间。验证命名空间是否已重新创建并处于 ACTIVE 状态：

      export KUBECONFIG=ORG_ADMIN
  kubectl get namespace platform-obs platform-obs-obs-system

    输出如下所示：

      NAME                      STATUS   AGE
  platform-obs              Active   45s
  platform-obs-obs-system   Active   49s

    在命名空间处于活跃状态后，卡住的插件应该会在几分钟内完成部署。验证其 DEPLOYED 和 READY 状态现在是否为 true：

      export KUBECONFIG=ROOT_ADMIN
  kubectl get addon -n org-1 system-alerts system-dashboards

    输出如下所示：

      NAME                DEPLOYED   READY   VERSION
  system-alerts       true       true    1.14.0-gdch.143998
  system-dashboards   true       true    1.14.0-gdch.143998

在引导期间，KIND 集群中出现 UPORC 崩溃循环

版本：1.13.x

症状：命名空间 uporc-system 下的 Deployment uporc-root-backend-controller 在 KIND 集群中进入崩溃循环。

临时解决方法：

  1. 检查 ComponentGroupReleaseMetadata 和 ReleaseMetadata 对象是否匹配：

    export KUBECONFIG=KIND
kubectl get componentgroupreleasemetadata
kubectl get releasemetadata

    如果对象匹配，则无需采取任何解决方法。

  2. 如果对象不匹配，请与 UPORC 团队联系以寻求帮助，因为这可能表明存在其他潜在问题。

节点升级失败

版本：1.13.6

症状：节点升级在 NodeOSInPlaceUpgradeCompleted 失败。

  1. 检查 os-upgrade ospolicy 作业的日志。
  2. 如果日志中包含表明配置文件已损坏的错误，请进入节点机器并手动检查文件内容，看看是否已损坏。日志错误可能会提及 configparser.DuplicateOptionError 错误代码和 /etc/yum.repos.d/gdch.repo 文件。

解决方法：仅当您确认文件已损坏时，才手动删除损坏的节点上的损坏的 /etc/yum.repos.d/gdch.repo 文件。

升级的 Ansible 作业会自动重新生成该文件，这是 Ansible playbook 的一部分。

### NodeUpgradeTask CR 卡在 NodeOSInPlaceUpgradePostProcessingCompleted 条件

版本：1.13.5

症状：在升级到 1.13.5 期间，NodeUpgradeTask CR 卡在 NodeOSInPlaceUpgradePostProcessingCompleted 条件。

检查相应的 os-artifact-collector 作业是否已完成。如果作业卡住数小时，系统会显示以下消息：

  root@gpc-adhoc-7e017e71vm-bootstrapper-zone1:~# kag logs  os-artifact-collector-bm-45942837-p8hrk-z56gh 
  I1020 22:06:11.844634       1 main.go:30] BuildDate: 2024-10-19T16:54:08Z
  I1020 22:06:11.844695       1 main.go:31] Version: 0.0.0-gdch.1.v3f2043

临时解决方法：

  1. 删除作业或 pod 以强制重试。

NodeUpgradeTask CR 卡在 NodeBIOSFirmwareUpgradeCompleted 条件

版本：1.13.5

症状：在升级到 1.13.5 期间，NodeUpgradeTask CR 卡在 NodeBIOSFirmwareUpgradeCompleted 条件。

检查相应的 NodeBIOSFirmwareUpgradeCompleted 条件是否卡住，并显示以下条件：

  {
  "lastTransitionTime": "2024-12-03T04:03:37Z",
  "message": "",
  "observedGeneration": 1,
  "reason": "InProgress",
  "status": "False",
  "type": "NodeBIOSFirmwareUpgradeCompleted"
  }

临时解决方法：

  1. 在 NodeUpgrade CR 中，手动将 "U30 v3.20 (05/29/2024)" 修改为 "U30 v3.20 (05/27/2024)"。

由于节点无法进入维护模式，集群升级被阻止

版本：1.13.5、1.13.6、1.13.7

症状：由于节点无法进入维护模式，集群（组织管理员集群、系统集群或用户集群）升级被阻止。

集群显示 MaintenanceMode 设置为 true，但在运行以下命令时，Status 停留在 false：

kubectl get baremetalmachines -A -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,MaintenanceMode:.spec.maintenanceMode,Status:.status.underMaintenace

输出如下所示：

NAMESPACE           NAME            MaintenanceMode   Status
user-vm-1-cluster   10.8.4.22       true              false
user-vm-1-cluster   10.8.4.23       false             false
user-vm-1-cluster   10.8.4.24       false             false
user-vm-1-cluster   172.20.128.13   false             false
user-vm-1-cluster   172.20.128.14   false             false
user-vm-1-cluster   172.20.128.15   false             false

临时解决方法：

将 KUBECONFIG 设置为包含未排空节点的集群的 kubeconfig 文件。该集群可以是用户集群，也可以是共享服务集群。

for VM in $(kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints --no-headers | grep "baremetal.cluster.gke.io/maintenance" | awk '{print $1}'); do
  for i in {1..50}; do
    kubectl delete po -n kube-system $(kubectl get po -A -o wide  | grep ang | grep -e $VM| awk '{print $2}');
  done
done

初始根 organizationupgrade 期间的持续性超时

版本：1.13.3

症状：如果在组织升级期间存在忽略维护窗口注解，则 organizationupgrade CR 会被反复修补，从而重置进度。

解决方法：

暂停子组件 rm-org 并缩减 rm-org-backend-controller 副本。

  1. 如果未声明别名，请运行：

    alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"

  2. 暂停子组件并缩减 rm-org 的部署规模：

    kubectl --kubeconfigROOT_ADMIN_KUBECONFIG annotate subcomponent -n root rm-org lcm.private.gdc.goog/paused=true
kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=0

  3. 集群升级完成后，缩减部署规模：

    kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=1

子组件 obj-syslog-server 在根组织中无法完成协调

版本：1.13.3、1.13.4、1.13.5、1.13.6

症状：在升级到 1.13.x 版期间，发现子组件 obj-syslog-server 处于 ReconciliationError 状态：

root        obj-syslog-server     ReconciliationError

条件类似于：

Sub-Component: obj-syslog-server - Reconciliation error: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded

Last Transition Time: 2024-09-17T21:49:25Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     ReconciliationError
     Status:True
     Type: Reconciling
     Last Transition Time: 2024-09-17T21:49:23Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     Reason: DeployError
     Status: False
     Type: Deployed

您可能会看到 pod syslog-server-abcdefg-wxyz 处于 CrashLoopBackOff 状态，并显示以下错误：

       containerID: containerd://65d460176a1dcae412af698fa02fa5ffb0c5f0ef9bf0d0e2111ef88845630827
       exitCode: 128
       finishedAt: "2024-09-18T19:14:45Z"
       message: 'failed to create containerd task: failed to create shim task: OCI
         runtime create failed: runc create failed: unable to start container process:
         error during container init: error mounting "/var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2"
         to rootfs at "/etc/ssl/certs/obs-ca-cert.pem": mount /var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2:/etc/ssl/certs/obs-ca-cert.pem
         (via /proc/self/fd/6), flags: 0x5001: not a directory: unknown'
       reason: StartError
       startedAt: "1970-01-01T00:00:00Z"

临时解决方法：

如需使子组件恢复到健康状态，请移除不必要的 volumeMounts。

  1. 修改当前部署：

    export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig

    kubectl edit deployments syslog-server -n istio-system

  2. 移除 spec.containers.volumeMounts 中不需要的 volumeMounts。移除以下挂载路径：

        - mountPath: /etc/ssl/certs/obs-ca-cert.pem
      name: observability-ca
      readOnly: true1.
      subPath: ca.crt
    - mountPath: /etc/ssl/certs/obj-ca-cert.pem
      name: obj-ca
      readOnly: true
      subPath: ca.crt

  3. 应用更改后，子组件将恢复为 ReconciliationCompleted。

ABM 或节点升级卡在 maintenanceMode false

版本：1.13.4

症状：节点在 AnthosBaremetal 集群升级时卡住，并且节点未进入维护模式。

检查服务集群节点上的 baremetalmachine，例如：

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
false

解决方法：

重启 anthos-cluster-operator 以传播 BMM.MaintenanceMode：

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
true

在升级租户组织的 atat-webhooks 加购项时，升级失败

版本：1.13.5

症状：atat-webhooks 插件升级失败，无法恢复：

org-1                                         atat-webhooks                                    false                                        false                                     1.13.4-gdch.5582

您可能会看到类似如下内容的消息：

Status:                                                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                                                  │
│     Last Transition Time:  2024-10-30T17:57:06Z                                                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to generate parameters for AddOn[atat-webhooks]: failed to generate runtime parameters: parameter job not ready yet                │
│     Observed Generation:   4                                                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                                                   │
│     Status:                False                                                                                                                                                                               │
│     Type:                  Deployed                                                                                                                                                                            │
│     Last Transition Time:  2024-10-30T17:56:36Z                                                                                                                                                                │
│     Message:               Reconciliation error

检查 atat-webhooks-parameters-***** 的 pod：

kubectl logs -n org-1 atat-webhooks-parameters-***** --kubeconfig ROOT_ADMIN_KUBECONFIG

您可能会看到如下错误：

E1030 22:04:33.242244       7 main.go:39] failed to generate parameter for AddOn [atat-webhooks], error: ATAT0003: Organization.resourcemanager.private.gdc.goog "org-1" is invalid: metadata.labels[atat.config.google.com/task-order-number]: Invalid value: "TO1234": The current date 2024-10-30 is not within the valid range of this TaskOrder: 2024-06-30 - 2024-10-30.

解决方法：

  1. 复制当前投资组合：

    export KUBECONFIG=ROOT_ADMIN_KUBECONFIG

    kubectl get portfolios -n atat-system portfolio-org-1 -oyaml > portfolio-org-1

  2. 将 portfolio-org-1 Pop End Date 更新为未来的日期：

    kubectl delete portfolios -n atat-system portfolio-org-1

    如果此命令停止响应，请先从有效组合中删除 .Metadata.Finalizers 条件，然后再删除该组合。条件可能如下所示：

    │     portfolio.finalizers.atat.config.google.com

  3. 重新应用复制的 YAML 文件：

    kubectl apply -f portfolio-org-1

  4. 仔细检查日期，确保投资组合和 configmap 均已更新。

  5. 如果作业未恢复，请删除失败的 atat-webhooks-parameters 作业，这样作业就会恢复。等待其完成：

    kubectl delete jobs -n org-1 atat-webhooks-parameters

由于 DeadlineExceeded 或 BackoffLimitExceeded 错误，升级后检查或升级检查失败。

版本：1.13.8

症状：

在将 1.13.7 升级到 1.13.8 时，飞行后检查仍处于待处理状态，并显示 DeadlineExceeded 或 BackoffLimitExceeded 错误。

Message:postflight check result: pending, [NodeHealth (OS) HarborClusterHealth (AR)] still running 
Observed Generation: 3
Reason: ReconcileBackoff
Status: Unknown 
Type: ManagedCheckSucceeded 
Last Transition Time: 2025-02-13T02:11:41Z
Message: observed the following failure reasons: [ReconcileBackoff UpgradeCheckJobsInProgress]

解决方法：

确定作业失败的位置：

  1. 检查作业是否在预检或后检期间失败：

    kubectl get jobs -A -l "upgrade.private.gdc.goog/use" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

  2. 检查作业在升级期间是否失败：

    kubectl get jobs -A -l "upgrade.private.gdc.goog/upgrade-check-owner" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

  3. 删除作业：

    kubectl delete jobs -n gpc-system CHECK_NAME

升级检查包含与检查级别无关的结果

版本：1.13.x

症状：

组织升级检查可能会因错误地包含其他级别的结果而失败。例如，根组织检查可能会显示租户组织结果，而租户组织检查可能会显示用户集群结果。

根组织检查的失败日志示例：

kubectl logs -n gpc-system upgrade-check-postflight-haas-n2rk2-zv9rr --kubeconfig /root/release/root-admin/root-admin-kubeconfig
... {org-1 admin } failure ...

解决方法：

使用以下命令完全跳过预检或后检：

预检：

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

广告投放期之后：

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check=ok

Vertex AI

预训练 API 在界面中显示 Enabling 状态

版本：1.13.1

症状：在创建用户集群时，MonitoringTarget 显示 Not Ready 状态，导致预训练的 API 在界面中持续显示 Enabling 状态。

解决方法：

  1. 打开 Chrome 浏览器中的菜单（三点状图标）。
  2. 依次点击更多工具 > 开发者工具，打开控制台。
  3. 点击控制台中的网络标签页。
  4. 找到 ai-service-status 请求。
  5. 点击 ai-service-status 请求中的响应标签页，以显示相应请求的内容。
  6. 验证除 MonitoringTarget 和 LoggingTarget 组件之外的所有组件是否都已准备就绪。

Speech-to-Text 的 streaming_recognize 预训练 API 函数失败

版本：1.13.3

症状：调用 Speech-to-Text 的 streaming_recognize 预训练 API 函数时，客户端库存在问题，导致出现类似于以下内容的 400 错误消息：

google.api_core.exceptions.InvalidArgument: 400 The header 'x-goog-user-project' should be set

解决方法：使用以下 Python 脚本可使 streaming_recognize 函数正常运行：

import base64

from google.cloud import speech_v1p1beta1
from google.cloud.speech_v1p1beta1.services.speech import client
import google.auth
from google.auth.transport import requests
import requests as reqs
from google.api_core.client_options import ClientOptions
import os

audience= "https://ENDPOINT:443"
api_endpoint="ENDPOINT:443"
os.environ["GOOGLE_APPLICATION_CREDENTIALS"] = "APPLICATION_DEFAULT_CREDENTIALS_FILENAME"
os.environ["GRPC_DEFAULT_SSL_ROOTS_FILE_PATH"] = "CERT_NAME"

def get_client(creds):
  opts = ClientOptions(api_endpoint=api_endpoint)
  return client.SpeechClient(credentials=creds, client_options=opts)

def main():
  creds = None
  try:
    creds, project_id = google.auth.default()
    creds = creds.with_gdch_audience(audience)
    sesh = reqs.Session()
    sesh.verify = False
    req = requests.Request(session=sesh)
    creds.refresh(req)
  except Exception as e:
    print("Caught exception" + str(e))
    raise e
  return creds

def speech_func(creds):
  tc = get_client(creds)
  content="[ENCODED CONTENT STRING HERE]"

  audio = speech_v1p1beta1.RecognitionAudio()
  audio.content = base64.standard_b64decode(content)
  config = speech_v1p1beta1.StreamingRecognitionConfig()
  config.config.encoding= speech_v1p1beta1.RecognitionConfig.AudioEncoding.LINEAR16
  config.config.sample_rate_hertz=16000
  config.config.language_code="en-US"
  config.config.audio_channel_count=1

  request_config = speech_v1p1beta1.StreamingRecognizeRequest(
    streaming_config = config,
  )

  request_audio = speech_v1p1beta1.StreamingRecognizeRequest(
    audio_content = audio.content
  )

  requests = [request_config, request_audio]

  def request_generator():
      for request in requests:
          yield request

  metadata = (("x-goog-user-project", "projects/vtx-pretrained"),)
  resp = tc.streaming_recognize(requests=request_generator(), metadata=metadata)

  for response in resp:
    print(response)

if __name__=="__main__":
  creds = main()
  speech_func(creds)

替换以下内容：

Python 脚本引入了 streaming_recognize 和 recognize 函数之间的以下差异，以便让 streaming_recognize 的解决方法正常运行：

  • 第 4 行：与 recognize 脚本相比，多了一个 import 语句 (from google.cloud.speech_v1p1beta1.services.speech import client)。
  • 第 18 行：客户端由 client.SpeechClient() 返回，而不是 speech_v1p1beta1.SpeechClient()。

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

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

症状：在升级期间，翻译数据库集群会被重新创建，这会导致 ODS 系统集群 secret-store Secret 过时并处于不同步状态。因此，翻译前端 pod 和服务无法完成初始化。

解决方法：

删除系统集群中的 Secret：

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n ai-translation-system

将 SYSTEM_CLUSTER_KUBECONFIG 替换为系统集群中 kubeconfig 文件的路径。

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

batchTranslateDocument API 不支持作业状态轮询

版本：1.13.3

症状：Vertex AI 不支持 Translation 服务 API 中的 GET 和 LIST 操作。调用 Translation BatchTranslateDocument API 会返回一个长时间运行的操作，类似于以下示例：

{
  "name": "projects/PROJECT_ID/operations/OPERATION_ID",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.translation.v3.BatchTranslateDocumentMetadata",
    "state": "RUNNING"
  }
}

此问题是由于 APIP（授权）限制导致您无法直接调用端点。这些端点不支持作业状态轮询，并且由于 APIP 限制，您无法对长时间运行的操作执行 GET 操作。

解决方法：作为应用操作员 (AO)，请定期查看 s3_destination 文件夹，寻找新创建的作业输出文件，以了解作业状态。如果该文件夹包含输出文件，则表示作业已成功完成。

batchTranslateDocument 请求可能会导致性能问题

版本：1.13.3

症状：批量文档翻译服务读取一个或多个用户输入文件，并将临时处理文件和翻译后的输出文件写入 StorageGRID。由于重用客户端会失败，因此系统会为每个读写操作创建一个新的 curl 客户端。

二进制文件中的 S3 curl 客户端是一次性使用的，这意味着每个客户端只能对 StorageGRID 存储分区执行一次读写操作。因此，每次从 batchTranslateDocument 服务器建立与 StorageGRID 客户端的通信以读取和写入存储分区中的文件时，都会创建一个新的 curl 客户端。

不过，这对于 curl 客户端来说并非最佳选择。这可能会导致以下问题：

  • 性能下降：延迟时间增加，吞吐量减少
  • 资源耗尽：内存和 CPU 开销以及套接字耗尽
  • 服务器过载：速率限制或节流

启用预训练的 API 后，GDC 控制台显示的状态不一致

版本：1.13.3

症状：首次启用预训练 API 时，GDC 控制台可能会在几分钟后显示已启用服务的不一致状态。即使服务实际上正在启用，GDC 控制台也会将 Enabling 状态切换回 Disabled，并在界面上再次显示启用按钮。

解决方法：几分钟后，状态会变得一致，服务会反映其正确状态。

如需验证服务的状态，请在浏览器控制台中打开网络标签页，然后检查 ai-service-status 请求状态。载荷必须显示 L2 操作员已启用。

包含超过 250 个字符的翻译请求会导致 translation-prediction-server pod 崩溃

版本：1.13.3

症状：当您发送包含大约 250 个或更多字符（包括文档翻译请求）的翻译请求时，translation-prediction-0 或 translation-prediction-1 pod 可能会崩溃，需要重新加载模型。模型重新加载会自动进行，此过程可能需要大约 30 分钟才能完成。

此问题是由于翻译容器存在限制所致。

解决方法：将翻译请求拆分为长度小于 250 个字符的多个请求。对于所有语言，200 到 250 个字符之间的范围都是安全的。如果长时间的请求导致 pod 崩溃，则无需采取其他措施来缓解问题。

共享服务集群的 GPUAllocation 未正确配置

版本：1.13.3

症状：由于 GPU 资源不足，Vertex AI 工作负载无法调度。例如，如果您无法查看或启用 Vertex AI 服务端点，可能是因为 GPU 资源不足。

此资源配置问题可能是由共享服务集群中的某些 GPUAllocation 资源缺少以下注解引起的：

processed: "true"

解决方法：

  1. 按照 IAM-R0004 为 g-ORG_NAME-shared-service-cluster 生成 kubeconfig 文件。

  2. 列出服务集群中所有没有 processed: "true" 注解的 GPU 分配：

    kubectl get gpuallocations -A -n vm-system \
    --kubeconfig SERVICE_CLUSTER_KUBECONFIG \
    -o json | jq \
    '.items[] | select(.metadata.annotations.processed == null ) | .metadata.name'

    输出类似于以下内容：

    zi-ad-bm08

  3. 对于未分配的 GPUAllocation 资源，请在编辑器中打开它：

    kubectl edit gpuallocation -n vm-system NODE_NAME

  4. 根据服务集群中 GPU 分配的总数修改 GPU 分配：

    • 如果只有一个 GPU 分配自定义资源，请向其添加 processed: "true" 注解，并修改其规范，使其类似于以下内容：

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 4
    profiles:
    - mixed-5
    - uniform-3g.40gb
    - uniform-3g.40gb
    - uniform-7g.80gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

    • 如果存在两个 GPU 分配自定义资源，请找到没有 processed: "true" 注解的那个，向其添加 processed: "true" 注解，并修改其规范，使其与以下内容类似：

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 2
    profiles:
    - mixed-5
    - uniform-3g.40gb
  node: $node_name // unchanged
  pod: 0
  vm: 0

    • 如果存在四个 GPU 分配自定义资源，请找到没有 processed: "true" 注解的资源，向其添加 processed: "true" 注解，并将其规范修改为如下所示：

      annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 1
    profiles:
    - mixed-5
  node: $node_name // unchanged
  pod: 0
  vm: 0

  5. 保存对 GPUAllocation 自定义资源的更改，并确认其分配状态已更新为 true：

    kubectl get gpuallocations -A --kubeconfig SERVICE_CLUSTER_KUBECONFIG

    输出类似于以下内容：

    NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
vm-system   zi-ad-bm08   true        H100L 94GB
vm-system   zi-ad-bm09   true        H100L 94GB

从 1.9.x 版升级到 1.13.3 版时，OCLCM 控制器显示错误

版本：1.13.3

症状：从版本 1.9.x 升级到 1.13.3 时，Vertex AI 子组件的可操作组件生命周期管理 (OCLCM) 控制器可能会显示错误。此问题是由 ai_platform 插件作业中的错误引起的。升级期间收到的错误表明 OCLCM 无法转移这些 Vertex AI 组件的所有权。

以下是组织管理员集群中受影响的 Vertex AI 组件：

名称 命名空间
aip-l1operator-deployment ai-system
aip-l2operator-deployment ai-system
aip-web-plugin-frontend ai-system
aip-web-plugin-backend ai-system
aip-l1operator-sa ai-system
aip-l2operator-sa ai-system
aip-web-plugin-sa ai-system
aip-l1operator-role 不适用
aip-l2operator-role 不适用
aip-web-plugin-role 不适用
aip-l1operator-rolebinding 不适用
aip-l2operator-rolebinding 不适用
aip-web-plugin-rolebinding 不适用
aip-l1operator-log ai-system
aip-l2operator-log ai-system
aip-web-plugin-frontend-log ai-system
aip-web-plugin-backend-log ai-system
log-rule-aipl-a004 platform-obs
mon-rule-aipl-a0001 platform-obs
mon-rule-aipl-a0003 platform-obs
aip-l1operator-mon ai-system
aip-l1operator-mon-cm ai-system
aip-l2operator-mon ai-system
aip-l2operator-mon-cm ai-system
aip-l1operator-webhook-svc ai-system
aip-web-plugin-frontend-svc ai-system
aip-web-plugin-backend-svc ai-system
aip-web-plugin-frontend-virtualsvc ai-system
aip-web-plugin-backend-virtualsvc ai-system
aip-l1operator-selfsigned-issuer ai-system
aip-l1operator-serving-cert ai-system
aip-l1operator-validating-webhook ai-system
aip-l1operator-mutating-webhook ai-system

解决方法：如需解决此问题，您必须手动从组织管理员集群中移除受影响的 Vertex AI 组件。然后，基于 OCLCM 的新版 Vertex AI 会重新安装这些软件包。

在组织管理员集群中手动移除受影响的 Vertex AI 组件：

kubectl --kubeconfig=ORG_ADMIN_CLUSTER_KUBECONFIG delete deployment -n NAMESPACE COMPONENT_NAME

替换以下内容：

  • ORG_ADMIN_CLUSTER_KUBECONFIG：组织管理员集群中 kubeconfig 文件的路径。
  • NAMESPACE：要移除的 Vertex AI 组件的命名空间。如果组件没有命名空间，请从命令中移除 -n NAMESPACE。
  • COMPONENT_NAME：要移除的 Vertex AI 组件的名称。

以下示例展示了如何移除组织管理员集群中 ai-system 命名空间内存在的 aip-l1operator-deployment 组件：

kubectl --kubeconfig=ORG-ADMIN-CLUSTER-KUBECONFIG delete deployment -n ai-system aip-l1operator-deployment

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

版本：1.13.3

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

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

batchTranslateDocument 请求返回错误 503

版本：1.13.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: ORG_ADMIN_NAMESPACE
spec:
  subComponentRef: "vai-translation"
  backend:
    operableParameters:
      enableRAG: true

    将 ORG_ADMIN_NAMESPACE 替换为组织管理员集群的命名空间。

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

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

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

Vertex AI 预训练服务不可用

版本：1.13.7、1.13.9

症状：由于 Kubernetes 调度问题，Vertex AI OCR 和翻译服务无法启动。您可能会在日志中看到如下警告：

 Warning  FailedScheduling  105s (x40 over 3h18m)  default-scheduler  0/9 nodes are available: 1 Insufficient nvidia.com/mig-3g.40gb-NVIDIA_A100_80GB_PCIE, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-billing-
system-billing-dbcluster: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-ocr-sie-g-vai-ocr-sie: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-translation-sie-g-v-1gvg:
 }, 3 Insufficient cpu, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/9 nodes are available: 3 No preemption victims found for incoming pod, 6 Preemption is not helpful for scheduling.

解决方法：向默认池添加更多工作器节点，并逐出 GPU 节点上的 Pod，以便可以调度 AI 工作负载。

虚拟机

BYO 映像导入对于 qcow2 和原始映像失败

版本：1.13.1、1.13.3

症状：使用 gdcloud compute images import CLI 导入本地虚拟机映像时，导入状态停留在 WaitingForTranslationVM 或 ImportJobNotCreated。这是因为为转换或导入创建的临时磁盘使用与 qcow2/raw 映像完全相同的大小，但 LUKS 会增加几 MiB 的开销，从而导致磁盘配置失败。

临时解决方法：

手动创建一个新的 VirtualMachineImageImport，该 VirtualMachineImageImport 具有相同的映像名称，但 spec.minimumDiskSize 更大

例如，如果这是用于导入映像的命令：

gdcloud compute images import $IMPORT_NAME --project $PROJECT --source-file=$LOCAL_FILENAME --os=$OS

如果 CLI 自动创建的原始 VirtualMachineImageImport 的大小为 minimumDiskSize Gi，请创建一个大小为 X+1 Gi 的新 VirtualMachineImageImport。该值取决于要导入的图片的大小。对于 qcow2，它将是虚拟大小，例如 20Gi 应替换为 21Gi。

根据调用 CLI 的方式替换占位值。

  1. 查找 VirtualMachineImageImport：

    kubectl get virtualmachineimageimport $IMPORT_NAME -n $PROJECT -o yaml

    如果该对象不存在，请再次触发 gdcloud compute images import ... 命令。当控制台输出从 Uploading image to .. 变为 Image import has started for ... 时，按 ctrl+c，以便将本地映像上传到对象存储空间，并保留 VirtualMachineImageImport 以供参考，从而创建新的映像。

  2. 创建具有更大 minimumDiskSize 的新 VirtualMachineImageImport：

    apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineImageImport
metadata:
  name: $IMPORT_NAME_NEW
  namespace: $NAMESPACE
spec:
  imageMetadata:
    minimumDiskSize: $NEW_SIZE
    name: $IMAGE_NAME
    operatingSystem: $OS
  source:
    objectStorage:
      bucketRef:
        name: vm-images-bucket
      objectName: $LOCAL_FILENAME

从映像配置磁盘失败

版本：1.13.1、1.13.3

症状：从自定义映像配置磁盘时，minimumDiskSize 可能过于接近虚拟大小，导致磁盘配置失败。 虚拟机磁盘处于待处理状态，但从未预配。

解决方法：手动创建一个具有更大 spec.minimumDiskSize 的新磁盘。

当集群具有 GPU 时，NVIDIA 设备插件 DaemonSet 会失败

版本：1.13.3

症状：在具有 GPU 的集群节点上，NVIDIA 设备插件 DaemonSet 失败，并显示 driver rpc error 消息：

kubectl --kubeconfig KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

将 KUBECONFIG 替换为集群中 kubeconfig 文件的路径。

您将获得类似于以下示例的输出：

Warning  Failed     23m (x4 over 25m)  kubelet            Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running hook #0: error running hook: exit status 1, stdout: , stderr: Auto-detected mode as 'legacy'
nvidia-container-cli: initialization error: driver rpc error: timed out: unknown

此问题会导致 GPU 无法用于虚拟机 (VM) 和 pod。影响取决于以下集群类型：

  • 系统集群：未为该裸金属节点创建 GPUAllocation 自定义资源，并且该节点中的 GPU 未配置为虚拟机模式，无法供服务集群和用户集群使用。如需解决此问题，请参阅系统集群的解决方法。
  • 服务集群或用户集群：系统不会为相应虚拟机节点创建 GPUAllocation 自定义资源，并且该节点中的 GPU 无法供集群中的 pod 使用。如需解决此问题，请参阅服务或用户集群的解决方法。

系统集群的解决方法：

请按以下步骤解决系统集群中的问题：

  1. 使用系统集群中 kubeconfig 文件的路径设置 KUBECONFIG 环境变量。如需了解详情，请参阅 IAM-R0004 运行手册。

  2. 确定出现问题的节点：

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:

    输出必须显示节点名称和 Kubernetes 节点的 IP 地址。

    如果有多个节点，请在所有节点上运行这些步骤。在这种情况下，输出类似于以下示例：

    Node:                 yy-ab-bm04/172.20.128.26

  3. 使用节点名称设置 NODE_NAME 环境变量，例如：

    export NODE_NAME=yy-ab-bm04

  4. 与节点建立 SSH 连接。如需了解详情，请参阅 PLATAUTH-G0001 运行手册。

  5. 验证节点是否具有 GPU：

    nvidia-smi -L

    输出必须按以下示例所示打印节点中的 GPU：

    GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)
GPU 2: NVIDIA H100 NVL (UUID: GPU-5827b65a-3841-d877-fc17-881a2b71d416)
GPU 3: NVIDIA H100 NVL (UUID: GPU-31448904-9ae2-c95a-1986-a56cce004f49)

  6. 在 GPU 上启用持久模式：

    nvidia-smi -pm 1

    此操作可确保 NVIDIA 驱动程序始终加载，从而避免设备插件超时。

    输出必须如下例所示：

    Enabled persistence mode for GPU 00000000:4E:00.0.
Enabled persistence mode for GPU 00000000:62:00.0.
Enabled persistence mode for GPU 00000000:C9:00.0.
Enabled persistence mode for GPU 00000000:DE:00.0.
All done.

  7. 退出 SSH 会话：

    exit

  8. 通过查询 DaemonSet 验证设备插件是否正在运行：

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

  9. 验证 GPUAllocation 自定义资源是否已在虚拟机模式下创建和配置：

    kubectl --kubeconfig $KUEBCONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

    输出必须如下例所示：

    apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: yy-ab-bm04
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: yy-ab-bm04
  pod: 0
  vm: 4
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/0
    vm: 4/4
  deviceModel: H100L 94GB

服务或用户集群的临时解决方法：

请按以下步骤解决服务或集群中的问题：

  1. 使用服务集群或用户集群中 kubeconfig 文件的路径设置 KUBECONFIG 环境变量。如需了解详情，请参阅 IAM-R0004 运行手册。

  2. 确定出现问题的节点：

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:

    输出必须显示节点名称和 Kubernetes 节点的 IP 地址。

    如果有多个节点，请在所有节点上运行这些步骤。在这种情况下，输出类似于以下示例：

    Node:                 vm-948fa7f4/172.20.128.21

  3. 使用节点名称设置 NODE_NAME 环境变量，例如：

    export NODE_NAME=vm-948fa7f4

  4. 与节点建立 SSH 连接。如需了解详情，请参阅 PLATAUTH-G0001 运行手册。

  5. 验证节点是否具有 GPU：

    nvidia-smi -L

    输出必须按以下示例所示打印节点中的 GPU：

    GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)

  6. 在 GPU 上启用持久模式：

    nvidia-smi -pm 1

    此操作可确保 NVIDIA 驱动程序始终加载，从而避免设备插件超时。

    输出必须如下例所示：

    Enabled persistence mode for GPU 00000000:05:00.0.
Enabled persistence mode for GPU 00000000:06:00.0.
All done.

  7. 退出 SSH 会话：

    exit

  8. 通过查询 DaemonSet 验证设备插件是否正在运行：

    kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

  9. 验证 GPUAllocation 自定义资源是否已在虚拟机模式下创建和配置：

    kubectl --kubeconfig $KUBECONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

    输出必须如下例所示：

    apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: vm-948fa7f4
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: vm-948fa7f4
  pod: 2
  vm: 0
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/2
    vm: 0/0
  deviceModel: H100L 94GB

系统集群虚拟机尚未准备就绪

版本：1.13.3

症状：系统集群虚拟机未准备就绪。您可能会看到类似如下内容的消息：

│ Conditions:                                                                                                                                   │
│   Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          │
│  Message                                                                                                                                      │
│   ----                          ------    -----------------                 ------------------                ------                          │
│  -------                                                                                                                                      │
│   KubeletUnhealthy              False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:37 +0000   KubeletIsHealthy                │
│  kubelet on the node is functioning properly                                                                                                  │
│   KernelDeadlock                False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   KernelHasNoDeadlock             │
│  kernel has no deadlock                                                                                                                       │
│   ReadonlyFilesystem            False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   FilesystemIsNotReadOnly         │
│  Filesystem is not read-only                                                                                                                  │
│   FrequentUnregisterNetDevice   False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentUnregisterNetDevice   │
│  node is functioning properly                                                                                                                 │
│   ContainerRuntimeUnhealthy     False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:39 +0000   ContainerRuntimeIsHealthy       │
│  Container runtime on the node is functioning properly                                                                                        │
│   FrequentKubeletRestart        False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:41 +0000   NoFrequentKubeletRestart        │
│  kubelet is functioning properly                                                                                                              │
│   FrequentDockerRestart         False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentDockerRestart         │
│  docker is functioning properly                                                                                                               │
│   FrequentContainerdRestart     False     Tue, 20 Aug 2024 02:10:42 +0000   Thu, 15 Aug 2024 01:44:23 +0000   NoFrequentContainerdRestart     │
│  containerd is functioning properly                                                                                                           │
│   MemoryPressure                Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   DiskPressure                  Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   PIDPressure                   Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   Ready                         Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.

解决方法：

  1. 找到 VirtualMachineInstance 并将其删除。
  2. 重启新虚拟机。

数据量报告显示未找到临时空间

版本：1.13.3、1.13.4

症状：创建虚拟机磁盘时，数据卷报告为成功：

gdch-vm-infra   gdc-vm-disk-vm-ce34b8ea-disk   Succeeded   100.0%     1          18h

不过，导入器 pod（例如 importer-gdc-vm-disk-vm-ce34b8ea-disk）会陷入崩溃循环，并显示如下消息：

E0823 16:14:15.920008       1 data-processor.go:251] scratch space required and none found
E0823 16:14:15.920017       1 importer.go:185] scratch space required and none found

解决方法：确认数据卷状态为 Succeeded 后，删除导入器 pod。

名称超过 45 个字符的项目的虚拟机将保持停止状态

版本：1.13.5

症状：创建虚拟机时，如果项目名称超过 45 个字符，虚拟机将保持 Stopped 状态。

解决方法：创建名称不超过 45 个字符的项目。

服务集群上缺少 GPU 分配

版本：1.13.5

症状：gpu-org 的共享服务集群中缺少 GPUAllocation。在获取 GPU 分配时，您可能会看到以下消息：

KUBECONFIG=/root/release/user/gpu-org-shared-service-kubeconfig kubectl get gpuallocations -A

输出类似于以下内容：

No resources found

解决方法：

  1. 向 GPU 节点添加污点：

    taints:
  - effect: NoExecute
    key: vmm.gdc.goog/gpu-node
    value: a3-highgpu-4g

  2. 移除污点，以允许调度虚拟机 virt-launcher pod。

无法调度共享服务集群工作器虚拟机

版本：1.13.6

症状：尽管有可用的 GPU，但 Kubernetes 工作器虚拟机因指定节点上的 CPU 资源不足而无法调度。您可能会看到如下所示的事件：

Warning  FailedScheduling  33m (x29 over 92m)    default-scheduler  0/9 nodes are available: 1 Insufficient memory, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 5 Insufficient cpu, 5 Insufficient nvidia.com/gpu-vm-H100L_94GB. preemption: 0/
9 nodes are available: 3 Preemption is not helpful for scheduling, 6 No preemption victims found for incoming pod.

解决方法：

  1. 手动停止非 GPU 虚拟机以释放 CPU 资源。
  2. 在安排待处理的虚拟机后，启动非 GPU 虚拟机。