Verbindungsprobleme bei Apigee mit Southbound-PSC-Zielen

Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Für dieses Thema gibt es keine entsprechende Apigee Edge-Dokumentation.

Symptom

Netzwerkverbindungsprobleme zwischen Apigee und einem Southbound-Zieldienst, der über Private Service Connect (PSC) verbunden ist.

Fehlermeldung

Ein Netzwerkverbindungsproblem oder ein TCP-Zeitlimit zwischen Apigee und dem Zieldienst wird als Fehlerantwort 503 und mit einem Fehler wie dem folgenden angezeigt, wenn Sie eine Fehlerbehebungssitzung erstellen.

{"fault":{"faultstring":"The Service is temporarily unavailable","detail":{"errorcode":"messaging.adaptors.http.flow.ServiceUnavailable","reason":"TARGET_CONNECT_TIMEOUT"}}}

Mögliche Ursachen

Ursache	Beschreibung
Unterschiedliche Regionen zwischen Dienstanhang und Apigee-Instanz	Die Region Apigee-Instanz und der Dienstanhang unterscheiden sich.
Fehlende Firewallregel für eingehenden Traffic für PSC-Subnetz im Zielprojekt	Achten Sie darauf, dass im Zielprojekt eine Firewallregel für eingehenden Traffic vorhanden ist, die die IP-Adresse und den Port des PSC-Subnetzbereichs zulässt.
Falsche Konfiguration des Dienstanhangs im Zielprojekt	Prüfen Sie den Dienstanhang im Zielprojekt.
Falscher Zustand des Endpunktanhangs in Apigee	Prüfen Sie den Endpunktanhang in Apigee.
Nichtübereinstimmung zwischen dem in TargetEndpoint konfigurierten Port und dem ILB	Achten Sie darauf, dass der TargetEndpoint im API-Proxy denselben Port verwendet, der vom internen Load Balancer (ILB) im Zielprojekt bereitgestellt wird.

Ursache: Unterschiedliche Regionen zwischen Dienstanhang und Apigee-Instanz

Hinweis:Apigee-Instanzen unterstützen standardmäßig den globalen Zugriff auf Southbound-PSC-Endpunkte. Der verwendete Load Balancer-Typ des Produzenten bestimmt jedoch, wann der globale Zugriff aktiviert werden kann. Wenn Sie einen regionalen internen Application Load Balancer oder einen regionalen internen Proxy Network Load Balancer als Ersteller-Load-Balancer verwenden, muss der globale Zugriff aktiviert sein, bevor Sie PSC-Endpunkte für Ihre Apigee-Instanz erstellen. Wenn der globale Zugriff vor dem Erstellen dieser Endpunkte nicht aktiviert war, müssen vorhandene PSC-Endpunkte gelöscht und für die Apigee-Instanz neu erstellt werden, damit der globale Zugriff aktiviert werden kann.
Weitere Informationen finden Sie unter Konfiguration des PSC-Nutzers.

Diagnose

1. Sie haben folgende Möglichkeiten, die Region der Apigee-Instanz zu prüfen:

   

   1. Klassische Apigee-Benutzeroberfläche verwenden:
      1. Melden Sie sich in der Apigee-UI an.
      2. Klicken Sie auf Verwaltung > Instanzen.
      3. Klicken Sie auf eine Instanz.
      4. Prüfen Sie im Bereich Instanzdetails den Speicherort der Laufzeit.
   2. Apigee-Benutzeroberfläche in der Google Cloud Console verwenden:

      1. Rufen Sie in der Google Cloud Console die Seite Apigee-Instanzen auf.

         Zu Apigee-Instanzen

      2. Klicken Sie auf eine Instanz.
      3. Prüfen Sie im Bereich Instanzdetails den Speicherort der Laufzeit.
   3. Mit einem API-Aufruf:

      curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances"
      

      Dabei ist ORG_NAME der Name der Organisation. Beispiel: example-apigee-support.

      Es wird in etwa Folgendes zurückgegeben: Der Standort für das Laufzeit-Hosting ist der Wert, der unten für location angezeigt wird. Beispiel: asia-northeast1.

      "instances": [
        {
          "name": "asia-northeast1",
          "location": "asia-northeast1",
          "host": "10.117.0.2",
          "port": "443",
          "createdAt": "1628150049760",
          "lastModifiedAt": "1682139265367",
          "diskEncryptionKeyName": "projects/apigee-x-support-apac-05/locations/asia-northeast1/keyRings/phanim-disk-key-1/cryptoKeys/phanim-disk-key-ring-1",
          "state": "ACTIVE",
          "peeringCidrRange": "SLASH_20",
          "runtimeVersion": "1-9-0-apigee-25",
          "consumerAcceptList": [
            "example-apigee-support",
            "example-neg-project"
          ],
          "serviceAttachment": "projects/xb363132eb41cb643p-tp/regions/asia-northeast1/serviceAttachments/apigee-asia-northeast1-yp9o"
        }

2. Prüfen Sie die Region des Endpunktanhangs mit einem API-Aufruf:

   curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/ORG_NAME/endpointAttachments/ENDPOINT_ATTACHMENT_NAME"

   Dabei gilt:

   • ORG_NAME ist der Name der Organisation. Beispiel: example-apigee-support.
   • ENDPOINT_ATTACHMENT_NAME ist der Name des Endpunktanhangs. Beispiel: example-ea.

   Es wird in etwa Folgendes zurückgegeben: Die Region der Endpunktanpassung ist der Wert, der unten für location angezeigt wird. Beispiel: asia-northeast1.

   {
     "name": "organizations/example-apigee-support/endpointAttachments/example-ea",
     "location": "asia-northeast1",
     "host": "7.0.4.2",
     "state": "ACTIVE",
     "connectionState": "ACCEPTED",
     "serviceAttachment": "projects/target-project/regions/asia-northeast1/serviceAttachments/gkebackend"
   }

3. Prüfen Sie in der Cloud Console die Region der Dienstanwendung:

   1. Rufen Sie in der Google Cloud Console die Seite Private Service Connect auf.

      Zu Private Service Connect

   2. Suchen Sie in der Spalte Region nach dem Standort.

   

Lösung

Die Regionen der Apigee-Instanz, des Endpunktanhangs und des Dienstanhangs müssen übereinstimmen. Zum Beispiel, asia-northeast1.

Wie unter Einschränkungen beschrieben, wird der globale Zugriff nicht unterstützt. Dies bedeutet, dass sich Dienstanhänge und Endpunktanhänge in derselben Region befinden müssen. Wenn sich Ihre Apigee-Instanz beispielsweise in der Region us-west1 befindet, können Sie keine Dienste mit ihr verbinden, die sich in us-east2 oder einer anderen Region befinden.

Wenn die Regionen unterschiedlich sind, treten Verbindungsprobleme zwischen Apigee und dem Zieldienst auf.

Ursache: Fehlende Firewallregel für den Eingang für das PSC-Subnetz im Zielprojekt

Diagnose

Prüfen Sie im Zielprojekt, ob eine Firewallregel vorhanden ist, die der IP-Adresse des PSC-Subnetzbereichs die Verbindung zum Zieldienst erlaubt:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Prüfen Sie im Bereich VPC-Firewallregeln, ob eine Regel wie im folgenden Beispiel vorhanden ist:
   • Richtung: Eingehender Traffic
   • Aktion bei Übereinstimmung: Zulassen
   • Quellfilter:IPv4-/IPv6-Bereiche
   • IP-Bereiche: IP-Adressbereich des PSC-Subnetzes (ipCidrRange), den Sie mit dem folgenden gcloud-Befehl zur Beschreibung des PSC-Subnetzes abrufen können:

     gcloud compute networks subnets describe PSC_SUBNET_NAME --region=REGION

     Dabei gilt:

     • PSC_SUBNET_NAME ist der Name des PCS-Subnetzes. Beispiel: pscsub.
     • REGION ist der Standort. Zum Beispiel, asia-northeast1.

     Es wird in etwa Folgendes zurückgegeben:

     creationTimestamp: '2023-04-19T03:33:29.371-07:00'
     fingerprint: 1JPKY66teTg=
     gatewayAddress: 10.10.0.1
     id: '5645967773396008342'
     ipCidrRange: 10.10.0.0/24
     kind: compute#subnetwork
     name: pscsub
     network: https://www.googleapis.com/compute/v1/projects/target-project/global/networks/default
     privateIpGoogleAccess: false
     privateIpv6GoogleAccess: DISABLE_GOOGLE_ACCESS
     purpose: PRIVATE_SERVICE_CONNECT
     ....

   • Protokolle und Ports: Diese sollten entsprechend Ihrer Zieldienstkonfiguration aufgelistet werden.

Beispiel:

Lösung

Wenn die Firewallregel nicht vorhanden ist, erstellen Sie ein PSC-Subnetz, wie unter Dienstanhang erstellen beschrieben, Schritt 2.

Ursache: Falsche Konfiguration des Dienstanhangs im Zielprojekt

Diagnose

Sie haben folgende Möglichkeiten, die Region für die Dienstanhänge zu prüfen:

1. Cloud Console verwenden:

   1. Rufen Sie in der Google Cloud Console die Seite Private Service Connect auf.

      Zu Private Service Connect

   2. Klicken Sie auf Veröffentlichte Dienste.
   3. Klicken Sie auf einen Dienst.
   4. Suchen Sie in der Zeile Region nach dem Standort.

   

2. Mit einem gcloud command:

     gcloud compute service-attachments describe SERVICE_ATTACHMENT --region=REGION

   Dabei gilt:

   • SERVICE_ATTACHMENT der Name des Dienstanhangs ist. Beispiel: gkebackend.
   • REGION ist der Standort. Beispiel: asia-northeast1.

   Es wird in etwa Folgendes zurückgegeben:

   connectedEndpoints:
   - endpoint: https://www.googleapis.com/compute/v1/projects/xb363132eb41cb643p-tp/regions/asia-northeast1/forwardingRules/example-ea
     pscConnectionId: '6816512648152066'
     status: ACCEPTED
   connectionPreference: ACCEPT_AUTOMATIC
   creationTimestamp: '2023-04-19T05:09:09.941-07:00'
   description: ''
   enableProxyProtocol: false
   fingerprint: 0BZDAZ3zDCs=
   id: '4503680255626733322'
   kind: compute#serviceAttachment
   name: gkebackend
   natSubnets:
   - https://www.googleapis.com/compute/v1/projects/target-project/regions/asia-northeast1/subnetworks/pscsub
   pscServiceAttachmentId:
     high: '21570167574103266'
     low: '4503680255626733322'
   region: https://www.googleapis.com/compute/v1/projects/target-project/regions/asia-northeast1
   selfLink: https://www.googleapis.com/compute/v1/projects/target-project/regions/asia-northeast1/serviceAttachments/gkebackend
   targetService: https://www.googleapis.com/compute/v1/projects/target-project/regions/asia-northeast1/forwardingRules/k8s2-tcp-b65prv8v-default-ilb-svc-tv2s6klz

Lösung

1. Der Wert connectedEndpoints.endpoint muss auf das Mandantenprojekt von Apigee verweisen und der Status muss ACCEPTED sein. Sie können das Mandantenprojekt mit der Apigee Organizations API finden:

   curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/ORG_NAME"

   Dabei ist ORG_NAME der Name der Organisation. Beispiel: example-apigee-support.

   Es wird in etwa Folgendes zurückgegeben: Die ID befindet sich in einem Feld namens apigeeProjectId. Beispiel: xb363132eb41cb643p-tp.

   {
     "name": "example-apigee-support",
     "createdAt": "1628148440954",
     "lastModifiedAt": "1650563608527",
     "environments": [
     "dev"
     ],
     "properties": {
       "property": [
         {
           "name": "features.mart.connect.enabled",
           "value": "true"
         },
         {
           "name": "features.hybrid.enabled",
           "value": "true"
         }
       ]
     },
       "analyticsRegion": "asia-northeast1",
       "authorizedNetwork": "default",
       "runtimeType": "CLOUD",
       "subscriptionType": "PAID",
       "caCertificate": "CERTIFICATE_NUMBER",
       "runtimeDatabaseEncryptionKeyName": "projects/example-apigee-support/locations/asia-northeast1/keyRings/phanim-key-ring-1/cryptoKeys/phanim-app-key-1",
       "projectId": "example-apigee-support",
       "state": "ACTIVE",
       "billingType": "SUBSCRIPTION",
       "addonsConfig": {
       "advancedApiOpsConfig": {},
       "integrationConfig": {},
       "monetizationConfig": {}
       },
   "apigeeProjectId": "xb363132eb41cb643p-tp"
   }

2. Achten Sie darauf, dass der Service-Anhang eine Verbindung zum Endpunktanhang hat, wie unter Southbound-Netzwerkmuster, Konnektivität von Anhängen prüfen und verwalten beschrieben. Prüfen Sie auf der Benutzeroberfläche aus Schritt 1 , ob Folgendes zutrifft:
   1. Die Zeile Subnetze verweist auf das PSC-Subnetz. Beispiel: pscsub.
   2. Die Zeile Ziel verweist auf den richtigen internen Load Balancer für die Ziel-Back-Ends.

Ursache: Falscher Zustand des Endpunktanhangs in Apigee

Diagnose

Rufen Sie den Endpunktanhang in Apigee mit einem API-Aufruf auf:

  curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/ORG_NAME/endpointAttachments/ENDPOINT_ATTACHMENT_NAME"

Dabei gilt:

• ORG_NAME ist der Name der Organisation. Beispiel: example-apigee-support.
• ENDPOINT_ATTACHMENT_NAME ist der Name des Endpunktanhangs. Beispiel: example-ea.

Es wird in etwa Folgendes zurückgegeben:

  {
    "name": "organizations/example-apigee-support/endpointAttachments/example-ea",
    "location": "asia-northeast1",
    "host": "7.0.4.2",
    "state": "ACTIVE",
    "connectionState": "ACCEPTED",
    "serviceAttachment": "projects/target-project/regions/asia-northeast1/serviceAttachments/gkebackend"
  }

Lösung

Prüfen Sie dabei Folgendes:

• state ist ACTIVE
• connectionState ist ACCEPTED
• serviceAttachment bezieht sich auf das richtige Zielprojekt und den richtigen Dienstanhangsnamen.

Ursache: Nichtübereinstimmung zwischen dem in TargetEndpoint konfigurierten Port und dem ILB

Diagnose

1. Suchen Sie im Zielprojekt in der Cloud Console nach dem Port, den die Weiterleitungsregel freigibt:

   1. Rufen Sie in der Google Cloud Console die Seite Private Service Connect auf.

      Zu Private Service Connect

   2. Klicken Sie auf Veröffentlichte Dienste.
   3. Klicken Sie auf einen Dienst. Wie im folgenden Beispiel gezeigt, ist Port 80 verfügbar.

Lösung

Prüfen Sie, ob derselbe Port 80 der Port in TargetEndpoint des API-Proxys ist.

Rufen Sie dazu den API-Proxy auf und prüfen Sie die TargetEndpoint-URL:

1. Mit der klassischen Apigee-Benutzeroberfläche:
   1. Melden Sie sich in der Apigee-UI an.
   2. Klicken Sie auf Entwickeln > API-Proxys.
   3. Klicken Sie auf einen Proxy.
   4. Klicken Sie auf Entwickeln.
   5. Prüfen Sie im XML-Bereich Folgendes:

      <HTTPTargetConnection>
        <URL>http://7.0.4.2:80</URL>
      </HTTPTargetConnection>

2. Apigee-Benutzeroberfläche in der Google Cloud Console verwenden:

   1. Rufen Sie in der Google Cloud Console die Seite Apigee auf.

      Zu „Apigee“

   2. Klicken Sie im Bereich Proxy-Entwicklung auf API-Proxys.
   3. Klicken Sie auf einen Proxy.
   4. Klicken Sie auf Entwickeln.
   5. Prüfen Sie im XML-Bereich Folgendes:

        <HTTPTargetConnection>
          <URL>http://7.0.4.2:80</URL>
        </HTTPTargetConnection>

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an den Google Cloud-Support:

• Apigee-Organisation
• Umgebung und API-Proxy, wo das Problem auftritt
• Heruntergeladene Debug-Sitzung (enthält alle oben genannten Informationen)
• Verwendeter Endpunktanhang
• Zielprojekt und Dienstanhang