Google 会远程监控和维护 Google Distributed Cloud 联网配置。为此，Google 工程师拥有对 Distributed Cloud connected 硬件的 Secure Shell (SSH) 访问权限。如果 Google 检测到问题，Google 工程师会与您联系，以排查和解决问题。如果您自行发现了问题，请立即与 Google 支持团队联系，以便诊断和解决问题。
Distributed Cloud 联网配置软件升级
本部分介绍了如何使用 Metrics Explorer 检查 Distributed Cloud 连接的集群是否正在进行软件升级。
此过程使用以下 Monitoring 指标：
当前集群版本 (
/edge_cluster/current_cluster_version)：指示集群上运行的 Distributed Cloud 互联软件的当前版本。目标集群版本 (
/edge_cluster/target_cluster_version)：表示集群要升级到的互联 Distributed Cloud 的目标版本。
如需完成本部分中的步骤，您必须满足以下前提条件：
- 有权访问 Google Cloud 控制台和您的 Distributed Cloud 连接的 Google Cloud 项目。
- Monitoring Viewer IAM 角色，可让您查看 Monitoring 指标。
- （可选）目标 Distributed Cloud Connected 机器的
machine_id值，用于过滤返回的结果。
使用 Metrics Explorer 查看集群的当前软件版本和目标软件版本
前往 Metrics Explorer：
在 Google Cloud 控制台中，前往监控部分。
在左侧导航树中，点击 Metrics Explorer。
选择目标资源类型：
在 Metrics Explorer 页面中，前往配置页面。
点击选择指标。
使用搜索栏搜索集群资源类型。您也可以使用完整的资源标识符
edgecontainer.googleapis.com/Cluster。在返回的结果中，点击集群资源类型。
获取集群的当前软件版本：
在指标部分中，搜索
current_cluster_version值。选择机器正常运行时间指标。其完整路径为
edgecontainer.googleapis.com/edge_cluster/current_cluster_version。（可选）使用过滤条件部分按目标
machine_id值进行过滤。
获取集群的目标软件版本：
点击添加查询。
在指标部分中，搜索
target_cluster_version值。选择目标集群版本指标。其完整路径为
edgecontainer.googleapis.com/edge_cluster/target_cluster_version。（可选）使用过滤条件部分按目标
machine_id值进行过滤。
在显示的图表中查看集群的软件升级状态。
如果当前集群版本和目标集群版本行分别指示不同的值，则表示集群正在进行软件升级。
如果当前集群版本和目标集群版本行指示相同的值，则集群未进行软件升级。
使用以下命令验证上一步的结果：
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 |
集群正在回滚到 Distributed Cloud connected 软件的先前版本。 | 请与 Google 联系，确定回滚的原因。 |
如果集群上的软件升级失败或集群已回滚到之前的软件版本，请检查以下内容：
- 节点健康状况。验证每台物理 Distributed Cloud Connected 机器是否都具有网络连接，并报告正常运行时间（如下一部分所述）。
- 维护窗口。验证软件升级是否因维护排除窗口而暂停。
- 系统日志。检查系统日志，找出软件升级失败的可能原因，例如 Pod 逐出超时。
如果表中列出的解决步骤无法解决问题，请与 Google 支持团队联系，并提供受影响机器的 machine_id 值和中断时间戳。
Distributed Cloud connected 机器重启
本部分介绍了如何使用 Metrics Explorer 检查 Distributed Cloud 连接的物理机器是否已重启，并确定重启的原因。监控重启有助于确定重启是计划内维护的一部分，还是硬件故障或电源中断的结果。
此过程使用以下 Monitoring 指标：
机器正常运行时间 (
/machine/uptime)：表示自上次重启以来的时间（以秒为单位）。机器重启次数 (
/machine/restart_count)：表示目标机器自部署以来的总重启次数。
如需完成本部分中的步骤，您必须满足以下前提条件：
- 有权访问 Google Cloud 控制台和您的 Distributed Cloud 连接的 Google Cloud 项目。
- Monitoring Viewer IAM 角色，可让您查看 Monitoring 指标。
- （可选）目标 Distributed Cloud Connected 机器的
machine_id值，用于过滤返回的结果。
使用 Metrics Explorer 查看机器正常运行时间和重启次数
前往 Metrics Explorer：
在 Google Cloud 控制台中，前往监控部分。
在左侧导航树中，点击 Metrics Explorer。
选择目标资源类型：
在 Metrics Explorer 页面中，前往配置页面。
点击选择指标。
使用搜索栏搜索机器资源类型。您也可以使用完整资源标识符
edgecontainer.googleapis.com/Machine。在返回的结果中，点击机器资源类型。
检查机器的正常运行时间：
在指标部分中，搜索
uptime值。选择机器正常运行时间指标。其完整路径为
edgecontainer.googleapis.com/machine/uptime。（可选）使用过滤条件部分按目标
machine_id值进行过滤。在显示的时间图表中，验证正常运行时间图表是否持续上升。如果在任何时间点，正常运行时间值降至零并重新开始，则表示机器已重启。
检查机器的重启次数：
在指标部分中，搜索
restart_count值。选择机器重启指标。其完整路径为
edgecontainer.googleapis.com/machine/restart_count。（可选）使用过滤条件部分按目标
machine_id值进行过滤。在显示的时间图表中，验证图表线是否保持在
0，这表示未发生重启。如果该线条在任何时间点飙升至1，则表示机器已重启；请记下重启的确切时间戳，以便进一步排查问题。（可选）如需查看单个事件而不是图表，请前往页面的聚合部分，将对齐时间段字段设置为
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)：指示机器的主网络接口是否具有互联网连接。
如需完成本部分中的步骤，您必须满足以下前提条件：
- 有权访问 Google Cloud 控制台和您的 Distributed Cloud 连接的 Google Cloud 项目。
- Monitoring Viewer IAM 角色，可让您查看 Monitoring 指标。
- （可选）目标 Distributed Cloud Connected 机器的
machine_id值，用于过滤返回的结果。
使用 Metrics Explorer 检查机器连接情况
前往 Metrics Explorer：
在 Google Cloud 控制台中，前往监控部分。
在左侧导航树中，点击 Metrics Explorer。
选择目标资源类型：
在 Metrics Explorer 页面中，前往查询页面。
使用搜索栏搜索机器资源类型。您也可以使用完整资源标识符
edgecontainer.googleapis.com/Machine。在返回的结果中，点击机器资源类型。
检查机器与 Google Cloud的连接：
在指标部分中，搜索
connected值。选择机器已连接指标。其完整路径为
edgecontainer.googleapis.com/machine/connected。（可选）使用过滤条件部分按目标
machine_id值进行过滤。在显示的时间图表中，验证健康行是否持续保持在 100%。如果此值在任何时间点为 0% 或运行状况不佳，则表示机器在指定时间与 Google Cloud 失去了连接性。
检查机器的互联网连接：
在指标部分中，搜索
connectivity值。选择网络连接指标。其完整路径为
edgecontainer.googleapis.com/machine/network/connectivity。（可选）使用过滤条件部分按目标
machine_id值进行过滤。在显示的时间图表中，验证健康行是否持续保持在 100%。如果此值在任何时间点为 0% 不正常，则表示机器在指定时间失去了互联网连接。
解读结果
下表介绍了 Metrics Explorer 返回的结果。
| 机器状态 | 诊断 | 解决方法 |
|---|---|---|
| 正常 “机器已连接”指标值为 1“Network Connectivity”指标值为 1 |
正常运行。 | 无。 |
| 已断开连接 “机器已连接”指标值为 0“Network Connectivity”指标值为 1 |
机器已连接到互联网，但无法连接到 Google Cloud。 | 检查 Google 服务和 API 端点的防火墙规则。验证 Distributed Cloud 连接的代理是否正在机器上运行。 |
| 隔离 “机器已连接”指标值为 0“Network Connectivity”指标值为 0 |
机器未连接到互联网。 | 检查电源和网络布线、本地网络配置、LED 指示灯状态。验证您的 VLAN 和路由配置。 |
| 间歇性 “机器已连接”指标值在 0 和 1 之间交替“Network Connectivity”指标值在 0 和 1 之间交替 |
网络连接不稳定、丟包或延迟时间过长。 | 检查本地网络是否存在拥塞和硬件故障。 |
如果您发现任一指标的值持续为 0，请按照表中说明的问题排查步骤进行解决。如果问题仍然存在，请与 Google 支持团队联系，并提供受影响机器的 machine_id 值和中断的时间戳。
虚拟机卡在 Pending 状态
如果发生以下任一情况，虚拟机工作负载可能会卡在 Pending 状态，并且无法在节点上调度：
- Distributed Cloud 联网版无法为虚拟机分配请求的资源，例如 CPU 时间、内存或磁盘可用空间。
- 虚拟机的配置存在故障。
- 虚拟机的存储空间出现故障。
- 目标节点已被污点标记。
如需解决此问题，请执行以下操作：
按照获取集群的凭证中的说明获取集群凭证。
获取有关受影响虚拟机的信息：
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该命令的输出包含可能指示资源限制、调度失败、存储故障和其他问题的消息。
检查输出以确定调度失败的原因，如下文所述。
资源不足
您可能会看到一条消息，指出资源（例如 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.
如需解决此问题，请执行以下操作：
使用以下命令检查节点上的污点：
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>执行下列其中一项操作：
存储故障
您可能会看到一条消息，提示虚拟机的存储空间存在故障。例如：
5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.
此消息可能表示相应的永久性卷无法装载到目标节点上。
如需解决此问题，请执行以下操作：
使用以下命令获取受影响虚拟机命名空间中的永久性卷声明 (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验证相应 PVC 的状态是否为
Bound；如果状态为Pending，则表示存储子系统未能预配卷。在这种情况下，您必须排查存储子系统配置问题，并确保有适当的StorageClass可用。
准入网络钩子失败导致调度锁定
准入 webhook 可让您在对象持久化之前拦截对 Kubernetes API 服务器的请求。虽然 Webhook 有助于强制执行自定义安全政策，但配置不当的 Webhook 可能会导致集群范围内的服务中断，尤其是在软件升级和证书刷新等关键操作期间。具体而言，如果准入 webhook 被屏蔽或不可用，可能会导致 Kubernetes 控制平面停滞，从而阻止在集群上进一步调度工作负载。
控制平面死锁
当准入 webhook 负责验证 webhook 自身恢复所需的资源时，可能会发生循环依赖项死锁。例如，如果准入 webhook 配置为验证 Pod，并且该 webhook Pod 需要在节点软件升级期间重新调度，则 Kubernetes API 服务器可能会尝试联系 webhook 以授权创建新 Pod。如果无法访问该网络钩子，请求会失败，Pod 不会创建，并且集群会进入死锁状态，无法调度新的工作负载。
如果使用 failurePolicy: Fail 配置了网络钩子，则 API 服务器与网络钩子之间的任何通信错误或超时都会导致 API 请求被拒绝。这会导致以下问题：
- 软件升级失败：在节点软件升级期间和之后，无法调度系统组件和虚拟机。
- 系统服务无法启动：基础设施 Pod（例如 Symcloud Storage 和 VM Runtime on GDC）无法启动。
- 节点卡在维护模式：由于控制器被准入逻辑阻止，处于维护模式的节点无法协调或退出。
Webhook 配置最佳实践
请遵循本部分中所述的最佳实践，以防止出现前面所述的控制平面死锁。
这些最佳实践适用于所有 ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 对象。
使用 failurePolicy: Ignore
除非您的业务要求规定，如果 API 请求无法验证，则必须失败，否则请始终将 failurePolicy 字段设置为 Ignore。这样可确保即使受影响的 Webhook 服务关闭，Kubernetes API 服务器也能继续运行，从而使系统关键 Pod 能够调度和恢复。
排除预留命名空间
您的网络钩子绝不能拦截对预留命名空间中资源的请求。您必须使用 namespaceSelector 字段从网络钩子配置中排除这些命名空间。如需查看预留命名空间的完整列表，请参阅管理命名空间限制。例如：
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。
找出失败的 webhook：
列出集群上部署的验证 webhook：
kubectl get validatingwebhookconfigurations
列出集群上部署的更改网络钩子：
kubectl get mutatingwebhookconfigurations
验证支持这些网络钩子的 Pod 是否正在运行：
kubectl get pods -A | grep WEBHOOK_SERVICE
将
WEBHOOK_SERVICE替换为目标 webhook 服务的名称。将失败的 webhook 的
failurePolicy设置为Ignore：kubectl patch validatingwebhookconfiguration WEBHOOK_CONFIG \ --type='json' \ -p='[{"op": "replace", "path": "/webhooks/0/failurePolicy", "value":"Ignore"}]'将
WEBHOOK_SERVICE替换为目标 webhook 服务的名称。（可选）如果上一步失败，请强制删除受影响的 webhook 的配置：
kubectl delete validatingwebhookconfiguration WEBHOOK_CONFIG --timeout=10s
将
WEBHOOK_CONFIG替换为目标 webhook 的配置名称。
修改或强制删除 Webhook 的配置后，Kubernetes API 服务器会恢复处理请求，从而解决死锁问题并让被阻止的进程完成。