Versionsinformationen finden Sie in den Versionshinweisen zu Distributed Cloud Connected.

Probleme mit Distributed Cloud Connected beheben

Google überwacht und wartet die Google Distributed Cloud Connected-Hardware per Fernzugriff. Zu diesem Zweck haben Google-Techniker Secure Shell-Zugriff (SSH) auf die Hardware von Distributed Cloud Connect. Wenn Google ein Problem erkennt, wendet sich ein Google-Techniker an Sie, um es zu beheben. Wenn Sie selbst ein Problem festgestellt haben, wenden Sie sich sofort an den Google-Support, damit es diagnostiziert und behoben werden kann.

Konnektivität von Distributed Cloud Connected-Maschinen

In diesem Abschnitt wird beschrieben, wie Sie die Internet- und Google Cloud Verbindung Ihrer mit Distributed Cloud verbundenen Maschinen mit dem Metrics Explorer von Cloud Monitoring prüfen.

Bei diesem Verfahren werden die folgenden Monitoring-Messwerte verwendet:

Machine Connected (/machine/connected): Gibt an, ob die Maschine mit Google Cloudverbunden ist.
Netzwerkverbindung (/machine/network/connectivity): Gibt an, ob die primäre Netzwerkschnittstelle des Geräts eine Internetverbindung hat.

Für die Schritte in diesem Abschnitt müssen die folgenden Voraussetzungen erfüllt sein:

Zugriff auf die Google Cloud Console und Ihr mit Distributed Cloud verbundenes Google Cloud Projekt.
Die IAM-Rolle Monitoring Viewer, mit der Sie Monitoring-Messwerte ansehen können.
Optional: Der machine_id-Wert des Zielcomputers für Distributed Cloud Connected zum Filtern der zurückgegebenen Ergebnisse.

Mit dem Metrics Explorer die Verbindung von Maschinen prüfen

Rufen Sie den Metrics Explorer auf:
1. Rufen Sie in der Google Cloud Console den Bereich Monitoring auf.
2. Klicken Sie im linken Navigationsbaum auf Metrics Explorer.
Wählen Sie den Zielressourcentyp aus:
1. Rufen Sie auf der Seite „Metrics Explorer“ die Seite Abfragen auf.
2. Suchen Sie über die Suchleiste nach dem Ressourcentyp Machine. Sie können auch den vollständigen Ressourcen-Identifier edgecontainer.googleapis.com/Machine verwenden.
3. Klicken Sie in den zurückgegebenen Ergebnissen auf den Ressourcentyp Machine (Maschine).
Prüfen Sie die Verbindung des Geräts zu Google Cloud:
1. Suchen Sie im Abschnitt Messwert nach dem Wert connected.
2. Wählen Sie den Messwert Machine Connected (Maschine verbunden) aus. Der vollständige Pfad ist edgecontainer.googleapis.com/machine/connected.
3. Optional: Filtern Sie im Bereich Filter nach dem Zielwert machine_id.
4. Prüfen Sie im angezeigten Zeitdiagramm, ob die Linie Fehlerfrei durchgehend bei 100 % bleibt. Wenn dieser Wert zu einem beliebigen Zeitpunkt 0% oder Unhealthy ist, hat die Maschine zu diesem Zeitpunkt die Verbindung zu Google Cloud verloren.
Internetverbindung des Geräts prüfen:
1. Suchen Sie im Abschnitt Messwert nach dem Wert connectivity.
2. Wählen Sie den Messwert Network Connectivity (Netzwerkverbindung) aus. Der vollständige Pfad ist edgecontainer.googleapis.com/machine/network/connectivity.
3. Optional: Filtern Sie im Bereich Filter nach dem Zielwert machine_id.
4. Prüfen Sie im angezeigten Zeitdiagramm, ob die Linie Fehlerfrei durchgehend bei 100 % bleibt. Wenn dieser Wert zu einem beliebigen Zeitpunkt 0% Unhealthy beträgt, hat die Maschine zum angegebenen Zeitpunkt die Internetverbindung verloren.

Validierungsergebnisse nachvollziehen

In der folgenden Tabelle werden die vom Metrics Explorer zurückgegebenen Ergebnisse erläutert.

Maschinenstatus	Diagnose	Lösung
Gut Der Messwert „Machine Connected“ (Gerät verbunden) ist `1` Der Messwert „Network Connectivity“ (Netzwerkverbindung) ist `1`	Normaler Betrieb	Keine.
Getrennt Der Messwert „Machine Connected“ (Gerät verbunden) ist `0` Der Messwert „Network Connectivity“ (Netzwerkverbindung) ist `1`	Das Gerät hat eine Internetverbindung, kann aber keine Verbindung zu Google Cloudherstellen.	Prüfen Sie Ihre [Firewallregeln](distributed-cloud/connected/1.11.0/docs/requirements#connected_management_and_monitoring_traffic) für Google-Dienste und API-Endpunkte. Prüfen Sie, ob die Distributed Cloud Connected-Agents auf dem Computer ausgeführt werden.
Isoliert Der Messwert „Machine Connected“ (Maschine verbunden) ist `0` Der Messwert „Network Connectivity“ (Netzwerkverbindung) ist `0`	Die Maschine hat keine Internetverbindung.	Prüfen Sie die Strom- und Netzwerkkabel, die Konfiguration des lokalen Netzwerks und den LED-Status des Geräts. Prüfen Sie Ihre VLAN- und Routingkonfiguration.
Zeitweise Der Messwert „Machine Connected“ (Maschine verbunden) wechselt zwischen `0` und `1`. Der Messwert „Network Connectivity“ (Netzwerkverbindung) wechselt zwischen `0` und `1`.	Instabile Netzwerkverbindung, Paketverlust oder übermäßige Latenz.	Prüfe dein lokales Netzwerk auf Überlastung und defekte Hardware.

Wenn Sie für einen der beiden Messwerte dauerhaft den Wert 0 feststellen, folgen Sie der Anleitung zur Fehlerbehebung in der Tabelle, um das Problem zu beheben. Wenn das Problem weiterhin besteht, wenden Sie sich mit dem machine_id-Wert des betroffenen Geräts und dem Zeitstempel des Ausfalls an den Google-Support.

Beschädigte BGP-Sitzungen in Cloud Router-Ressourcen, die von VPN-Verbindungen verwendet werden

Distributed Cloud VPN-Verbindungen basieren auf BGP-Sitzungen, die von den entsprechenden Cloud Router-Ressourcen eingerichtet und verwaltet werden, um Routen zwischen dem mit Distributed Cloud verbundenen Cluster und Google Cloudanzukündigen. Wenn Sie die Konfiguration einer Cloud Router-Ressource ändern, die mit einer Distributed Cloud VPN-Verbindung verknüpft ist, kann diese Verbindung nicht mehr funktionieren.

So stellen Sie die beschädigte BGP-Sitzungskonfiguration im betroffenen Cloud Router wieder her:

Rufen Sie in der Google Cloud -Konsole den Namen der beschädigten BGP-Sitzung ab. Beispiel:
```
INTERFACE=anthos-mcc-34987234
```

Rufen Sie die BGP-IP-Adressen des Peers und des Cloud Routers für die beschädigte BGP-Sitzung sowie die Peer-ASN ab, die von der betroffenen Distributed Cloud VPN-Verbindung verwendet wird. Beispiel:

GDCE_BGP_IP=168.254.208.74
CLOUD_ROUTER_BGP_IP=168.254.208.73
PEER_ASN=65506

Wenn Sie die BGP-Sitzung gelöscht haben, rufen Sie diese Informationen stattdessen aus dem verbundenen Distributed Cloud-Cluster ab:

Rufen Sie die Clusteranmeldedaten ab:
```
gcloud edge-cloud container clusters get-credentials CLUSTER_ID \
  --location REGION \
  --project PROJECT_ID
```
Ersetzen Sie Folgendes:
- CLUSTER_ID gibt den Namen des Zielclusters an.
- REGION: die Google Cloud Region, in der der Zielcluster erstellt wird.
- PROJECT_ID: die ID des Zielprojekts Google Cloud .

Rufen Sie die Konfiguration der MultiClusterConnectivityConfig-Ressource ab:

kubectl get multiclusterconnectivityconfig -A

Die Ausgabe des Befehls sieht in etwa so aus:

 NAMESPACE     NAME                   LOCAL ASN              PEER ASN
 kube-system   MultiClusterConfig1    65505                   65506
 ```

Rufen Sie die BGP-IP-Adresse des Peers, die IP-Adresse des Cloud Routers und die ASN der BGP-Sitzung ab:

kubectl describe multiclusterconnectivityconfig -n kube-system MCC_CONFIG_NAME

Ersetzen Sie MCC_CONFIG_NAME durch den Namen der MultiClusterConfigResource, die Sie im vorherigen Schritt erhalten haben.

Die Ausgabe des Befehls sieht in etwa so aus:

 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
 ```

Rufen Sie in der Google Cloud -Konsole den Namen, die Region und denGoogle Cloud -Projektnamen für den beschädigten VPN-Tunnel ab. Beispiel:
```
VPN_TUNNEL=VPNTunnel1
REGION=US-East1
VPC_PROJECT_ID=VPC-Project-1
```
Löschen Sie die beschädigte BGP-Sitzung aus der Cloud Router-Konfiguration.
Erstellen Sie eine neue Cloud Router-Schnittstelle:
```
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
```
Ersetzen Sie Folgendes:
- INTERFACE_NAME: Ein aussagekräftiger Name, der diese Schnittstelle eindeutig identifiziert.
- TUNNEL_NAME: der Name des VPN-Tunnels, den Sie im vorherigen Schritt erhalten haben.
- ROUTER_BGP_IP: die BGP-IP-Adresse des Cloud Router, die Sie zuvor in diesem Verfahren ermittelt haben.
- VPC_PROJECT_ID: die ID des Ziel-VPC-Google Cloud Projekts.
- REGION: die Google Cloud Region, in der das Ziel-VPC- Google Cloud Projekt erstellt wurde.
Erstellen Sie den BGP-Peer:
```
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
```
Ersetzen Sie Folgendes:
- INTERFACE_NAME: Der Name der Schnittstelle, die Sie im vorherigen Schritt erstellt haben.
- TUNNEL_NAME: Der Name des VPN-Tunnels, den Sie zum Erstellen der Schnittstelle im vorherigen Schritt verwendet haben.
- REGION: die Google Cloud Region, in der das Google Cloud Ziel-VPC-Projekt erstellt wird.
- VPC_PROJECT_ID: die ID des Ziel-VPC-Google Cloud Projekts.
- GDCE_BGP_IP: die BGP-IP-Adresse des Distributed Cloud-Peers, die Sie zuvor in diesem Verfahren abgerufen haben.
- GDCE_BGP_ASN: Die BGP-ASN des Distributed Cloud-Peers, die Sie zuvor in diesem Verfahren abgerufen haben.

Die BGP-Sitzung ist jetzt wieder aktiv und betriebsbereit.

Virtuelle Maschinen hängen im Zustand `Pending` fest

Eine VM-Arbeitslast kann im Status Pending hängen bleiben und nicht auf einem Knoten geplant werden, wenn einer der folgenden Fälle eintritt:

Distributed Cloud Connected kann der virtuellen Maschine die angeforderten Ressourcen wie CPU-Zeit, Arbeitsspeicher oder Speicherplatz nicht zuweisen.
Die Konfiguration der virtuellen Maschine ist fehlerhaft.
Es liegt ein Fehler mit dem Speicher der virtuellen Maschine vor.
Der Zielknoten ist manipuliert.

So beheben Sie das Problem:

Rufen Sie Clusteranmeldedaten ab, wie unter Anmeldedaten für einen Cluster abrufen beschrieben.

Informationen zur betroffenen VM abrufen:

kubectl describe virtualmachine VM_NAME -n NAMESPACE

Ersetzen Sie Folgendes:

VM_NAME: Der Name der Ziel-VM.
NAMESPACE: Der Namespace der Ziel-VM.

Die Ausgabe des Befehls sieht in etwa so aus:

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

Die Ausgabe des Befehls enthält Meldungen, die auf Ressourcenbeschränkungen, Planungsfehler, Speicherfehler und andere Probleme hinweisen können.

Sehen Sie sich die Ausgabe an, um die Ursachen für den Planungsfehler zu ermitteln, wie in den nächsten Abschnitten beschrieben.

Unzureichende Ressourcen

Möglicherweise wird eine Meldung angezeigt, die auf unzureichende Ressourcen wie CPU, Arbeitsspeicher oder Speicherplatz hinweist. Beispiel:

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

Um dieses Problem zu beheben, prüfen Sie die Ressourcen, die den betroffenen virtuellen Maschinen und anderen Arbeitslasten zugewiesen sind, die auf dem Knoten geplant sind. Gehen Sie dann je nach Ihren geschäftlichen Anforderungen so vor:

Andere Arbeitslasten, die auf dem Knoten geplant sind, herunterzuskalieren.
Reduzieren Sie die Menge der Ressourcen, die der betroffenen VM zugewiesen sind.
Fügen Sie dem betroffenen Cluster weitere Maschinen hinzu.

Markierungsknoten

Möglicherweise wird eine Meldung angezeigt, die darauf hinweist, dass der Zielknoten manipuliert wurde. Beispiel:

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

So beheben Sie das Problem:

Verwenden Sie den folgenden Befehl, um nach Markierungen auf dem Knoten zu suchen:

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

Die Ausgabe des Befehls sieht in etwa so aus:

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>

Führen Sie einen der folgenden Schritte aus:
- Entfernen Sie unerwartete Markierungen, wie unter Markierungen und Toleranzen beschrieben.
- Fügen Sie für erwartete Markierungen entsprechende Toleranzen zur Konfiguration der virtuellen Maschine hinzu, wie unter Markierungen und Toleranzen beschrieben.

Speicherfehler

Möglicherweise wird eine Meldung angezeigt, die auf einen Fehler im Speicher der virtuellen Maschine hinweist. Beispiel:

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

Diese Meldung kann darauf hinweisen, dass das entsprechende nichtflüchtige Volume nicht auf dem Zielknoten bereitgestellt werden kann.

So beheben Sie das Problem:

Mit dem folgenden Befehl können Sie den Status der PersistentVolumeClaims (PVCs) im Namespace der betroffenen VM abrufen:

kubectl get pvc -n NAMESPACE

Ersetzen Sie NAMESPACE durch den Namen des Ziel-Namespace.

Die Ausgabe des Befehls sieht in etwa so aus:

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

Prüfen Sie, ob das entsprechende PVC den Status Bound hat. Wenn der Status Pending lautet, konnte das Speichersubsystem das Volume nicht bereitstellen. In solchen Fällen müssen Sie die Konfiguration des Speichersubsystems beheben und dafür sorgen, dass die entsprechende StorageClass verfügbar ist.

Probleme mit Distributed Cloud Connected beheben Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Konnektivität von Distributed Cloud Connected-Maschinen

Mit dem Metrics Explorer die Verbindung von Maschinen prüfen

Validierungsergebnisse nachvollziehen

Beschädigte BGP-Sitzungen in Cloud Router-Ressourcen, die von VPN-Verbindungen verwendet werden

Virtuelle Maschinen hängen im Zustand Pending fest

Unzureichende Ressourcen

Markierungsknoten

Speicherfehler

Probleme mit Distributed Cloud Connected beheben

Virtuelle Maschinen hängen im Zustand `Pending` fest