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.

Verlust der Netzwerkverbindung

Wenn die Verbindung der mit Distributed Cloud verbundenen Hardware zuGoogle Cloud unterbrochen wird und 120 Sekunden lang unterbrochen bleibt, markiert die mit Distributed Cloud verbundene Steuerungsebene die betroffenen Pods als „Nicht bereit“ und leitet die Pod-Entfernung ein.

Um dieses Problem zu beheben, müssen Sie Ihre mit Distributed Cloud verbundene Konfiguration planen und Ihre Arbeitslasten für die von Ihnen gewählte Verfügbarkeitsstufe konzipieren. Weitere Informationen finden Sie unter Best Practices für die Verfügbarkeit.

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:

  1. Rufen Sie in der Google Cloud -Konsole den Namen der beschädigten BGP-Sitzung ab. Beispiel:

    INTERFACE=anthos-mcc-34987234

  2. 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:

    1. 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 .

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

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

  3. 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

  4. Löschen Sie die beschädigte BGP-Sitzung aus der Cloud Router-Konfiguration.

  5. 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.

  6. 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.

Knoten hängt im Status Ready,SchedulingDisabled fest

Wenn Sie die NodeSystemConfigUpdate- oder SriovNetworkNodePolicy-Ressource anwenden oder löschen, wird der Zielknoten möglicherweise neu gestartet. Wenn ein Knoten neu gestartet wird, ändert sich sein Status in NotReady oder Scheduling Disabled. Wenn ein Knoten länger als 30 Minuten im Status Ready,SchedulingDisabled verbleibt, gehen Sie so vor:

  1. Prüfen Sie die Konfiguration und den Status der entsprechenden NodeSystemConfigUpdate- oder SriovNetworkNodePolicy-Ressource. Wenn die SriovNetworkNodePolicy-Ressource nicht vorhanden ist, unterstützt der Knoten kein SR-IOV.

  2. Wenn der Ressourcenstatus Succeeded ist, aktivieren Sie die Planung auf dem Knoten mit dem folgenden Befehl:

    kubectl uncordon NODE_NAME.

    Ersetzen Sie NODE_NAME durch den Namen des Zielknotens.

  3. Sollte das Problem weiterhin auftreten, wenden Sie sich an den Google-Support.