排查 Distributed Cloud connected 问题

Google 会远程监控和维护 Google Distributed Cloud 联网配置硬件。为此，Google 工程师拥有对 Distributed Cloud connected 硬件的 Secure Shell (SSH) 访问权限。如果 Google 检测到问题，Google 工程师会与您联系，以便排查和解决问题。如果您自行发现了问题，请立即与 Google 支持团队联系，以便诊断和解决问题。

Distributed Cloud connected 软件升级

本部分介绍如何使用 Metrics Explorer 检查连接到 Distributed Cloud 的集群是否正在进行软件升级。

此过程使用以下 Monitoring 指标：

  • 当前集群版本 (/edge_cluster/current_cluster_version)：表示集群上运行的已连接的 Distributed Cloud 软件的当前版本。

  • 目标集群版本 (/edge_cluster/target_cluster_version)：表示集群正在升级到的互联 Distributed Cloud 的目标版本。

如需完成本部分中的步骤，您必须满足以下前提条件：

  1. 对 Google Cloud 控制台和已连接的 Distributed Cloud Google Cloud 项目具有访问权限。
  2. Monitoring Viewer IAM 角色，可让您查看 Monitoring 指标。
  3. （可选）目标 Distributed Cloud Connected 机器的 machine_id 值，用于过滤返回的结果。

使用 Metrics Explorer 检查集群的当前和目标软件版本

  1. 前往 Metrics Explorer：

    1. 在 Google Cloud 控制台中，前往 Monitoring 部分。

    2. 在左侧导航树中，点击 Metrics Explorer。

  2. 选择目标资源类型：

    1. 在“Metrics Explorer”页面中，前往配置页面。

    2. 点击选择指标。

    3. 使用搜索栏搜索集群资源类型。您还可以使用完整的资源标识符 edgecontainer.googleapis.com/Cluster。

    4. 在返回的结果中，点击集群资源类型。

  3. 获取集群的当前软件版本：

    1. 在指标部分中，搜索 current_cluster_version 值。

    2. 选择机器正常运行时间指标。其完整路径为 edgecontainer.googleapis.com/edge_cluster/current_cluster_version。

    3. （可选）使用过滤条件部分按目标 machine_id 值进行过滤。

  4. 获取集群的目标软件版本：

    1. 点击添加查询。

    2. 在指标部分中，搜索 target_cluster_version 值。

    3. 选择目标集群版本指标。其完整路径为 edgecontainer.googleapis.com/edge_cluster/target_cluster_version。

    4. （可选）使用过滤条件部分按目标 machine_id 值进行过滤。

  5. 在显示的图表中查看集群的软件升级状态。

    • 如果当前集群版本和目标集群版本行分别显示不同的值，则表示集群正在进行软件升级。

    • 如果当前集群版本和目标集群版本行显示的值相同，则表示集群未进行软件升级。

  6. 使用以下命令验证上一步的结果：

    gcloud edge-cloud container clusters describe CLUSTER_ID --location=REGION

    替换以下内容：

    • CLUSTER_ID：目标集群的 ID。
    • REGION：已创建集群的 Google Cloud 区域。

    在命令的输出中，记下以下字段的值：

    • 如果 status 字段的值为 UPDATING，则表示集群正在进行软件升级。
    • 如果 clusterVersion 和 targetVersion 字段的值不同，请对照 Metrics Explorer 返回的值检查这两个字段的值。

解读结果

下表说明了 Metrics Explorer 和 gcloud 命令返回的结果。

集群状态 诊断 解决方法
正常
currentVersion 和 targetVersion 值匹配
`status` 值为 RUNNING
 集群正在运行目标版本的 Distributed Cloud Connected 软件。 无。
升级
currentVersion 值低于 targetVersion
`status` 值为 UPDATING
 集群正在升级到 Distributed Cloud Connected 软件的目标版本。 在 Metrics Explorer 中监控集群，直到当前集群版本值与目标集群版本值一致。
卡住
currentVersion 值低于 targetVersion 无限期
`status` 值为 UPDATING 无限期
 集群中至少有一个节点未能成功升级到目标版本的 Distributed Cloud Connected 软件。 检查机器连接和系统日志；联系 Google 以寻求帮助。
回滚
currentVersion 值高于 targetVersion
`status` 值为 UPDATING
 luster 正在回滚到之前版本的 Distributed Cloud connected 软件。 请与 Google 联系，以确定回滚的原因。

如果集群上的软件升级失败或集群已回滚到之前的软件版本，请检查以下内容：

  • 节点健康状况。验证每个已连接的 Distributed Cloud 实体机器是否具有网络连接，以及是否按下一部分所述报告正常运行时间。
  • 维护期。验证软件升级是否因维护排除窗口而暂停。
  • 系统日志。检查系统日志，找出可能导致软件升级失败的原因，例如 Pod 驱逐超时。

如果表格中列出的解决方法未能解决问题，请与 Google 支持团队联系，并提供受影响机器的 machine_id 值和中断时间戳。

Distributed Cloud connected 机器重启

本部分介绍了如何使用 Metrics Explorer 检查连接到 Distributed Cloud 的实体机是否已重启，并确定重启原因。监控重启有助于确定重启是计划内维护的一部分，还是硬件故障或电源中断的结果。

此过程使用以下 Monitoring 指标：

  • 机器正常运行时间 (/machine/uptime)：表示自上次重新启动以来的时间（以秒为单位）。

  • 机器重启次数 (/machine/restart_count)：表示目标机器自部署以来的总重启次数。

如需完成本部分中的步骤，您必须满足以下前提条件：

  1. 对 Google Cloud 控制台和已连接的 Distributed Cloud Google Cloud 项目具有访问权限。
  2. Monitoring Viewer IAM 角色，可让您查看 Monitoring 指标。
  3. （可选）目标 Distributed Cloud Connected 机器的 machine_id 值，用于过滤返回的结果。

使用 Metrics Explorer 检查机器正常运行时间和重启次数

  1. 前往 Metrics Explorer：

    1. 在 Google Cloud 控制台中，前往 Monitoring 部分。

    2. 在左侧导航树中，点击 Metrics Explorer。

  2. 选择目标资源类型：

    1. 在“Metrics Explorer”页面中，前往配置页面。

    2. 点击选择指标。

    3. 使用搜索栏搜索 Machine 资源类型。您还可以使用完整的资源标识符 edgecontainer.googleapis.com/Machine。

    4. 在返回的结果中，点击机器资源类型。

  3. 检查机器的正常运行时间：

    1. 在指标部分中，搜索 uptime 值。

    2. 选择机器正常运行时间指标。其完整路径为 edgecontainer.googleapis.com/machine/uptime。

    3. （可选）使用过滤条件部分按目标 machine_id 值进行过滤。

    4. 在显示的时间图表中，验证正常运行时间图表是否持续上升。如果正常运行时间值在任何时间点降至零并重新开始，则表示机器已重启。

  4. 检查机器的重启次数：

    1. 在指标部分中，搜索 restart_count 值。

    2. 选择机器重启次数指标。其完整路径为 edgecontainer.googleapis.com/machine/restart_count。

    3. （可选）使用过滤条件部分按目标 machine_id 值进行过滤。

    4. 在显示的时间图表中，验证图表线是否保持在 0，这表示未发生任何重新启动。如果此线条在任何时间点突然升至 1，则表示机器已重启；请记下重启的确切时间戳，以便进一步排查问题。

    5. （可选）如需查看各个事件而非图表，请前往页面的汇总部分，将对齐周期字段设置为 1 minute，并将序列对齐器字段设置为增量。

解读结果

下表介绍了 Metrics Explorer 返回的结果。

机器状态 诊断 解决方法
稳定
“机器正常运行时间”指标稳步上升
“机器重启次数”指标的增量为 0
 机器尚未重新启动。 无。
干净重启
“机器正常运行时间”指标降至 0
“机器重启次数”指标飙升至 1
 机器已成功重启并重新连接到 Google Cloud。 检查系统日志，确定重启原因。
电源故障
“机器正常运行时间”指标图表出现中断，没有数据
在机器正常运行时间中断期间，“机器重启次数”指标未发生变化
 机器在重新启动之前断电或网络连接中断。 检查电源和网络布线、本地网络配置、LED 指示灯状态。
间歇性
“机器已连接”指标值在 0 和 1 之间交替变化
“Network Connectivity”指标值在 0 和 1 之间交替变化
 网络连接不稳定、丟包或延迟时间过长。 检查本地网络是否存在拥塞和硬件故障。

如果表格中列出的解决方法未能解决问题，请与 Google 支持团队联系，并提供受影响机器的 machine_id 值和中断时间戳。

Distributed Cloud connected 机器连接

本部分介绍了如何使用 Cloud Monitoring 的 Metrics Explorer 功能检查 Distributed Cloud 连接的机器的互联网和 Google Cloud 连接情况。

此过程使用以下 Monitoring 指标：

  • 设备已连接 (/machine/connected)：表示设备是否已连接到 Google Cloud。

  • 网络连接 (/machine/network/connectivity)：表示机器的主网络接口是否已连接到互联网。

如需完成本部分中的步骤，您必须满足以下前提条件：

  1. 对 Google Cloud 控制台和已连接的 Distributed Cloud Google Cloud 项目具有访问权限。
  2. Monitoring Viewer IAM 角色，可让您查看 Monitoring 指标。
  3. （可选）目标 Distributed Cloud Connected 机器的 machine_id 值，用于过滤返回的结果。

使用 Metrics Explorer 检查机器连接

  1. 前往 Metrics Explorer：

    1. 在 Google Cloud 控制台中，前往 Monitoring 部分。

    2. 在左侧导航树中，点击 Metrics Explorer。

  2. 选择目标资源类型：

    1. 在“Metrics Explorer”页面中，前往查询页面。

    2. 使用搜索栏搜索 Machine 资源类型。您还可以使用完整的资源标识符 edgecontainer.googleapis.com/Machine。

    3. 在返回的结果中，点击机器资源类型。

  3. 检查设备与 Google Cloud的连接：

    1. 在指标部分中，搜索 connected 值。

    2. 选择机器已连接指标。其完整路径为 edgecontainer.googleapis.com/machine/connected。

    3. （可选）使用过滤条件部分按目标 machine_id 值进行过滤。

    4. 在显示的时间图表中，验证运行状况良好线是否持续保持在 100%。如果此值在任何时间点为 0% 或不健康，则表示相应时间点 Google Cloud 与机器断开连接。

  4. 检查机器的互联网连接：

    1. 在指标部分中，搜索 connectivity 值。

    2. 选择网络连接指标。其完整路径为 edgecontainer.googleapis.com/machine/network/connectivity。

    3. （可选）使用过滤条件部分按目标 machine_id 值进行过滤。

    4. 在显示的时间图表中，验证运行状况良好线是否持续保持在 100%。如果此值在任何时间点为 0% 不健康，则表示机器在指示的时间失去了互联网连接。

解读结果

下表介绍了 Metrics Explorer 返回的结果。

机器状态 诊断 解决方法
正常
“设备已连接”指标值为 1
“Network Connectivity”指标值为 1
 正常操作。 无。
已断开连接
“机器已连接”指标值为 0
“Network Connectivity”指标值为 1
 设备已连接到互联网，但无法连接到 Google Cloud。 检查 Google 服务和 API 端点的防火墙规则。验证 Distributed Cloud Connected 代理是否正在机器上运行。
已隔离
“机器已连接”指标值为 0
“Network Connectivity”指标值为 0
 设备未连接到互联网。 检查电源和网络布线、本地网络配置、LED 指示灯状态。验证 VLAN 和路由配置。
间歇性
“机器已连接”指标值在 0 和 1 之间交替变化
“Network Connectivity”指标值在 0 和 1 之间交替变化
 网络连接不稳定、丟包或延迟时间过长。 检查本地网络是否存在拥塞和硬件故障。

如果您发现任一指标的值持续为 0，请按照表格中所述的问题排查步骤解决相应问题。如果问题仍然存在，请与 Google 支持团队联系，并提供受影响机器的 machine_id 值和中断时间戳。

虚拟机卡滞在 Pending 状态

如果发生以下情况之一，虚拟机工作负载可能会卡在 Pending 状态，并且无法在节点上进行调度：

  • Distributed Cloud Connected 无法为虚拟机分配所请求的资源，例如 CPU 时间、内存或磁盘空间。
  • 虚拟机的配置存在故障。
  • 虚拟机的存储空间存在故障。
  • 目标节点已被污染。

如需解决此问题，请执行以下操作：

  1. 按照获取集群的凭据中的说明获取集群凭据。

  2. 获取有关受影响的虚拟机的信息：

    kubectl describe virtualmachine VM_NAME -n NAMESPACE

    替换以下内容：

    • VM_NAME：目标虚拟机的名称。
    • NAMESPACE：目标虚拟机的命名空间。

    该命令会返回类似于以下内容的输出：

    Status:
...
State:                    Pending
...
Events:
Type     Reason                  Age   From                       Message
----     ------                  ----  ----                       -------
Normal   SuccessfulCreate        15m   virtualmachine-controller  Created virtual machine my-stuck-vm
Warning  DiskProvisioningFailed  14m   virtualmachine-controller  Failed to provision disk: DataVolume my-stuck-vm-data-disk not ready
Warning  PVCNotBound             14m   virtualmachine-controller  PersistentVolumeClaim my-stuck-vm-data-disk is in phase Pending
Warning  VMINotCreated           10m   virtualmachine-controller  VirtualMachineInstance cannot be created: dependencies not ready

    该命令的输出包含可能指示资源限制、调度失败、存储故障和其他问题的消息。

  3. 检查输出，以确定调度失败的原因，如后续部分中所述。

资源不足

您可能会看到一条消息，指示资源（例如 CPU、内存或磁盘空间）不足。例如：

5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.

如需解决此问题，请检查分配给受影响的虚拟机和节点上安排的其他工作负载的资源，然后根据您的业务需求执行以下操作：

  • 缩减节点上调度的其他工作负载，
  • 减少分配给受影响虚拟机的资源量，
  • 向受影响的集群添加更多机器。

污点节点

您可能会看到一条消息，指示目标节点已被污染。例如：

5/8 nodes are available: 3 node(s) had taint {<taint-key>:<taint-value>}, that the pod didn't tolerate.

如需解决此问题，请执行以下操作：

  1. 使用以下命令检查节点上是否存在污点：

    kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

    该命令会返回类似于以下内容的输出：

    NAME                           TAINTS
node-name-1   [map[effect:PreferNoSchedule key:node-role.kubernetes.io/master] map[effect:PreferNoSchedule key:node-role.kubernetes.io/control-plane]]
node-name-2   <none>

  2. 执行下列其中一项操作：

    • 对于意外的污点，请按照污点和容忍设置中的说明将其移除。
    • 对于预期污点，请按照污点和容忍中所述，向虚拟机的配置添加相应的容忍。

存储故障

您可能会看到一条消息，指出虚拟机的存储空间存在故障。例如：

5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.

此消息可能表明相应的永久性卷无法装载到目标节点上。

如需解决此问题，请执行以下操作：

  1. 使用以下命令获取受影响的虚拟机的命名空间中永久性卷声明 (PVC) 的状态：

    kubectl get pvc -n NAMESPACE

    将 NAMESPACE 替换为目标命名空间的名称。

    该命令会返回类似于以下内容的输出：

    NAME                                               STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            AGE
windows-robin-disk-0                               Bound     pvc-b1a1d264-84bf-4e58-857d-f37f629d5082   25Gi       RWX            robin-block-immediate   30h
windows-robin-disk-1                               Bound     pvc-0130b9a8-7fed-4df0-8226-d79273792a16   25Gi       RWX            robin-block-immediate   30h
windows-robin-vm-0-restored-windows-robin-disk-0   Pending                                                                        gce-pd-gkebackup-in     26m

  2. 验证相应 PVC 的状态是否为 Bound；如果状态为 Pending，则表示存储子系统未能预配卷。 在这种情况下，您必须对存储子系统配置进行问题排查，并确保相应的 StorageClass 可用。

由准入 Webhook 失败导致的调度锁定

借助准入 webhook，您可以在对象持久保留之前拦截对 Kubernetes API 服务器的请求。虽然 webhook 对于强制执行自定义安全政策很有用，但配置错误的 webhook 可能会导致整个集群中断，尤其是在软件升级和证书刷新等关键操作期间。具体而言，被屏蔽或不可用的准入 webhook 可能会使 Kubernetes 控制平面停滞不前，从而阻止在集群上进一步调度任何工作负载。

控制平面死锁

当准入网络钩子负责验证网络钩子自身恢复所需的资源时，可能会发生循环依赖死锁。例如，如果准入 webhook 配置为验证 Pod，并且该 webhook Pod 在节点软件升级期间需要重新调度，则 Kubernetes API 服务器可能会尝试联系该 webhook 以授权创建新 Pod。如果无法访问 Webhook，请求会失败，Pod 不会被创建，并且集群会进入死锁状态，无法调度任何新工作负载。

如果网络钩子配置为 failurePolicy: Fail，则 API 服务器与网络钩子之间的任何通信错误或超时都会导致 API 请求被拒绝。这会导致以下问题：

  • 软件升级失败：在节点软件升级期间和之后，无法安排系统组件和虚拟机的运行时间。
  • 系统服务无法启动：Symcloud Storage 和 VM Runtime on GDC 等基础架构 Pod 无法启动。
  • 节点卡在维护模式下：处于维护模式下的节点无法进行协调或退出，因为控制器被准入逻辑阻止。

Webhook 配置最佳实践

请遵循本部分中所述的最佳实践，以防止出现上文所述的控制平面死锁。这些最佳实践适用于所有 ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 对象。

使用 failurePolicy: Ignore

除非您的业务要求规定，如果 API 请求无法通过验证，则必须失败，否则请始终将 failurePolicy 字段设置为 Ignore。这样可确保 Kubernetes API 服务器即使在受影响的网络钩子服务停止运行时也能继续运行，从而允许安排和恢复系统关键 Pod。

排除预留的命名空间

您的 webhook 绝不能拦截对预留命名空间中资源的请求。您必须使用 namespaceSelector 字段从 Webhook 配置中排除这些命名空间。如需查看预留命名空间的完整列表，请参阅管理命名空间限制。例如：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "customer-policy-webhook"
webhooks:
- name: "validate-labels.example.com"
  failurePolicy: Ignore
  sideEffects: None
  admissionReviewVersions: ["v1"]
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system
      - kube-node-lease
      - kube-public
      - capi-system
      - capi-kubeadm-bootstrap-system
      - gke-system
      - gke-connect
      - gke-operators
      - gke-managed-metrics-server
      - anthos-identity-service
      - anthos-creds
      - robinio
      - robin-admin
      - vm-system
      - cert-manager
      - cert-manager-cluster-resources
      - dns-system
      - g-istio-system
      - nf-operator
      - prom-monitoring
      - gpu-system
      - oclcm-system
      - saas-system
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["*"]
    apiVersions: ["*"]
    resources: ["pods", "deployments"]

恢复因网络钩子失败而陷入死锁的集群

如果您的集群因 webhook 失败而陷入死锁，并且您用于创建资源的 kubectl 命令超时或返回错误，通常是因为 webhook 的 failurePolicy 设置为 Fail。请按照本部分中的步骤从死锁中恢复集群。如果失败的 webhook 是更改型 webhook，请使用 mutatingwebhookconfiguration 而不是 validatingwebhookconfiguration。

  1. 确定失败的网络钩子：

    1. 列出部署在集群上的验证 webhook：

      kubectl get validatingwebhookconfigurations

    2. 列出部署在集群上的更改网络钩子：

      kubectl get mutatingwebhookconfigurations

  2. 验证支持这些 webhook 的 pod 是否正在运行：

    kubectl get pods -A | grep WEBHOOK_SERVICE

    将 WEBHOOK_SERVICE 替换为目标 Webhook 服务的名称。

  3. 将失败的 webhook 的 failurePolicy 设置为 Ignore：

    kubectl patch validatingwebhookconfiguration WEBHOOK_CONFIG \
  --type='json' \
  -p='[{"op": "replace", "path": "/webhooks/0/failurePolicy", "value":"Ignore"}]'

    将 WEBHOOK_SERVICE 替换为目标 Webhook 服务的名称。

  4. （可选）如果上一步失败，请强制删除受影响的 Webhook 的配置：

    kubectl delete validatingwebhookconfiguration WEBHOOK_CONFIG --timeout=10s

    将 WEBHOOK_CONFIG 替换为目标 webhook 配置的名称。

在修改或强制删除 Webhook 的配置后，Kubernetes API 服务器会恢复处理请求，从而解决死锁并让受阻的进程完成。