Google 会远程监控和维护 Google Distributed Cloud Connected 硬件。为此，Google 工程师拥有对 Distributed Cloud Connected 硬件的 Secure Shell (SSH) 访问权限。如果 Google 检测到问题，Google 工程师会与您联系，以便排查和解决问题。如果您自行发现了问题，请立即与 Google 支持团队联系，以便诊断和解决问题。
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 控制台中，前往 Monitoring 部分。
在左侧导航树中，点击 Metrics Explorer。
选择目标资源类型：
在“Metrics Explorer”页面中，前往查询页面。
使用搜索栏搜索 Machine 资源类型。您还可以使用完整的资源标识符
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。 | 检查您的 [防火墙规则](distributed-cloud/connected/1.11.0/docs/requirements#connected_management_and_monitoring_traffic)，确保其适用于 Google 服务和 API 端点。验证 Distributed Cloud Connected 代理是否正在机器上运行。 |
| 已隔离 “设备已连接”指标值为 0“Network Connectivity”指标值为 0 |
设备未连接到互联网。 | 检查电源和网线、本地网络配置、机器 LED 状态。验证 VLAN 和路由配置。 |
| 间歇性 “机器已连接”指标值在 0 和 1 之间交替“Network Connectivity”指标值在 0 和 1 之间交替 |
网络连接不稳定、丟包或延迟时间过长。 | 检查本地网络是否存在拥塞和硬件故障。 |
如果您发现任一指标的值持续为 0，请按照表格中所述的问题排查步骤解决相应问题。如果问题仍然存在，请与 Google 支持团队联系，并提供受影响机器的 machine_id 值和中断时间戳。
VPN 连接使用的 Cloud Router 资源中的 BGP 会话损坏
分布式 Cloud VPN 连接依赖于由其对应的 Cloud Router 资源建立和管理的 BGP 会话，以在分布式 Cloud 连接的集群与 Google Cloud之间通告路由。如果您修改与分布式 Cloud VPN 连接关联的 Cloud Router 资源配置，该连接可能会停止运行。
如需恢复受影响的 Cloud Router 中的损坏 BGP 会话配置，请完成以下步骤：
在 Google Cloud 控制台中，获取损坏的 BGP 会话的名称。例如：
INTERFACE=anthos-mcc-34987234获取损坏的 BGP 会话的对等 BGP 和 Cloud Router BGP IP 地址，以及受影响的 Distributed Cloud VPN 连接使用的对等 ASN。例如：
GDCE_BGP_IP=168.254.208.74 CLOUD_ROUTER_BGP_IP=168.254.208.73 PEER_ASN=65506如果您删除了 BGP 会话，请改为从分布式云连接集群获取此信息：
获取集群凭据：
gcloud edge-cloud container clusters get-credentials CLUSTER_ID \ --location REGION \ --project PROJECT_ID
替换以下内容：
CLUSTER_ID：目标集群的名称。REGION：目标集群所在的 Google Cloud 区域。PROJECT_ID：目标 Google Cloud 项目的 ID。
获取
MultiClusterConnectivityConfig资源的配置：kubectl get multiclusterconnectivityconfig -A
该命令会返回类似于以下内容的输出：
NAMESPACE NAME LOCAL ASN PEER ASN kube-system MultiClusterConfig1 65505 65506 ```获取对等 BGP IP 地址、Cloud Router IP 地址和 BGP 会话 ASN：
kubectl describe multiclusterconnectivityconfig -n kube-system MCC_CONFIG_NAME
将
MCC_CONFIG_NAME替换为您在上一步中获得的MultiClusterConfigResource的名称。该命令会返回类似于以下内容的输出：
Spec: Asns: Peer: 65505 Self: 65506 # GDCE ASN Tunnels: Ike Key: Name: MCC_CONFIG_NAME-0 Namespace: kube-system Peer: Bgp IP: 169.254.208.73 # Cloud Router BGP IP Private IP: 34.157.98.148 Public IP: 34.157.98.148 Self: Bgp IP: 169.254.208.74 # GDCE BGP IP Private IP: 10.100.29.49 Public IP: 208.117.254.68 ```
在 Google Cloud 控制台中，获取损坏的 VPN 隧道的名称、区域和Google Cloud 项目名称。例如：
VPN_TUNNEL=VPNTunnel1 REGION=US-East1 VPC_PROJECT_ID=VPC-Project-1从 Cloud Router 配置中删除损坏的 BGP 会话。
创建新的 Cloud Router 接口：
gcloud compute routers add-interface --interface-name=INTERFACE_NAME \ --vpn-tunnel=TUNNEL_NAME \ --ip-address=ROUTER_BGP_IP \ --project=VPC_PROJECT_ID \ --region=REGION \ --mask-length=30
替换以下内容：
INTERFACE_NAME：唯一标识此接口的描述性名称。TUNNEL_NAME：您在上一步中获得的 VPN 隧道的名称。ROUTER_BGP_IP：您在本流程中之前获得的 Cloud Router 路由器的 BGP IP 地址。VPC_PROJECT_ID：目标 VPCGoogle Cloud 项目的 ID。REGION：已创建目标 VPC Google Cloud 项目的 Google Cloud 区域。
创建 BGP 对等端：
gcloud compute routers add-bgp-peer --interface=INTERFACE_NAME \ --peer-name=TUNNEL_NAME \ --region REGION \ --project=VPC_PROJECT_ID \ --peer-ip-address=GDCE_BGP_IP \ --peer-asn=GDCE_BGP_ASN \ --advertised-route-priority=100 \ --advertisement-mode=DEFAULT
替换以下内容：
INTERFACE_NAME：您在上一步中创建的接口的名称。TUNNEL_NAME：您在上一步中用于创建接口的 VPN 隧道的名称。REGION：创建目标 VPC Google Cloud 项目的 Google Cloud 区域。VPC_PROJECT_ID：目标 VPCGoogle Cloud 项目的 ID。GDCE_BGP_IP：您在此过程前面部分中获得的 Distributed Cloud 对等方 BGP IP 地址。GDCE_BGP_ASN：您在此过程前面部分中获得的 Distributed Cloud 对等 BGP ASN。
此时，BGP 会话已恢复并正常运行。
虚拟机卡滞在 Pending 状态
如果发生以下情况之一，虚拟机工作负载可能会卡在 Pending 状态，并且无法在节点上进行调度：
- Distributed Cloud Connected 无法为虚拟机分配所请求的资源，例如 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。