Fehlerbehebung, wenn Apigee Hybrid im Zustand „creating“ oder „releasing“ festhängt

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

Hinweis: Dieses Dokument gilt nur für Nutzer von Apigee Hybrid.

In diesem Dokument wird beschrieben, wie Sie Apigee-Komponenten zurücksetzen, wenn sie sich im Zustand creating oder releasing befinden.

Führen Sie den folgenden Befehl aus, um die Hauptkomponenten der Apigee Hybrid-Installation aufzulisten:

kubectl get crd | grep apigee

apigeeorganization (apigeeorganizations.apigee.cloud.google.com)
apigeeenvironment (apigeeenvironments.apigee.cloud.google.com)
apigeedatastore (apigeedatastores.apigee.cloud.google.com)
apigeetelemetries (apigeetelemetries.apigee.cloud.google.com)
apigeeredis (apigeeredis.apigee.cloud.google.com)

Führen Sie den folgenden Befehl aus, um den aktuellen Zustand aufzurufen:

kubectl get apigeedatastore -n NAMESPACE

Wenn sie voll funktionsfähig ist, befinden sich jede dieser Komponenten im Zustand running. Beispiele:

NAME      STATE     AGE
default   running   5d6h

Wenn die Installation nicht erfolgreich ist, können die Komponenten den Zustand creating (oder releasing) beibehalten. Beispiele:

NAME      STATE     AGE
default   creating   5d6h

Problem identifizieren

Zur Ermittlung der Ursache des Problems beschreiben Sie zuerst jede Komponente. Die Komponenten sind so strukturiert:

Jede benutzerdefinierte ApigeeOrganization-Ressource wird durch die folgende Hierarchie dargestellt:

ApigeeOrganization/HASHED_VALUE
├─ApigeeDeployment/apigee-connect-agent-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-connect-agent-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-connect-agent-HASHED_VALUE
│ ├─ReplicaSet/apigee-connect-agent-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-connect-agent-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-mart-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-mart-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-mart-HASHED_VALUE
│ ├─ReplicaSet/apigee-mart-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-mart-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-watcher-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-watcher-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-watcher-HASHED_VALUE
│ ├─ReplicaSet/apigee-watcher-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-watcher-HASHED_VALUE-VER-xxxx

Jede benutzerdefinierte ApigeeEnvironment-Ressource wird durch die folgende Hierarchie dargestellt:

ApigeeEnvironment/HASHED_VALUE
├─ApigeeDeployment/apigee-runtime-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-runtime-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-runtime-HASHED_VALUE
│ ├─ReplicaSet/apigee-runtime-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-runtime-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-synchronizer-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-synchronizer-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-synchronizer-HASHED_VALUE
│ ├─ReplicaSet/apigee-synchronizer-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-synchronizer-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-udca-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-udca-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-udca-HASHED_VALUE
│ ├─ReplicaSet/apigee-udca-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-udca-HASHED_VALUE-VER-xxxx

Beginnen Sie mit der Problemermittlung durch Beschreibung der Stammkomponente. Beispiele:

kubectl describe apigeeorganization -n NAMESPACE COMPONENT_NAME

Prüfen Sie, ob State der Komponente running ist:

      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  State:            running
Events:             <none>

Wenn auf dieser Ebene keine Ereignisse geloggt werden, wiederholen Sie den Vorgang mit apigeedeployments gefolgt von ReplicaSet. Beispiele:

kubectl get apigeedeployment -n NAMESPACE AD_NAME>

Wenn apigeedeployments und ReplicaSet keine Fehler enthalten, konzentrieren Sie sich auf die Pods, die nicht bereit sind:

kubectl get pods -n NAMESPACE

NAME                                                              READY   STATUS
apigee-cassandra-default-0                                        1/1     Running
apigee-connect-agent-apigee-b56a362-150rc2-42gax-dbrrn            1/1     Running
apigee-logger-apigee-telemetry-s48kb                              1/1     Running
apigee-mart-apigee-b56a362-150rc2-bcizm-7jv6w                     0/2     Running
apigee-runtime-apigee-test-0d59273-150rc2-a5mov-dfb29             0/1     Running

In diesem Beispiel sind mart und runtime nicht bereit. Prüfen Sie die Pod-Logs auf Fehler:

kubectl logs -n NAMESPACE POD_NAME

Komponenten löschen

Wenn Sie bei einer dieser Komponenten einen Fehler entdeckt haben, löschen Sie die Komponente einfach und wenden Sie apigeectl für diese Komponente an. So löschen Sie beispielsweise eine Umgebung:

kubectl delete -n apigee apigeeenv HASHED_ENV_NAME

Nachdem Sie die erforderlichen Korrekturen vorgenommen haben, erstellen Sie die Umgebung:

apigeectl apply -f overrides.yaml –env=$ENV

Controller prüfen

Wenn der Pod keine offensichtlichen Fehlermeldungen enthält, die Komponente aber nicht in den Status running gewechselt ist, prüfen Sie apigee-controller auf Fehlermeldungen. apigee-controller wird im Namespace apigee-system ausgeführt.

kubectl logs -n apigee-system $(k get pods -n apigee-system | sed -n '2p' | awk '{print $1}') | grep -i error

So kann der Nutzer sehen, warum der Controller die Anfrage nicht verarbeiten konnte (create/delete/update usw.).

Apigee-Datenspeicher

Apache Cassandra ist als StatefulSet implementiert. Eine Cassandra-Instanz umfasst Folgendes:

ApigeeDatastore/default
├─Certificate/apigee-cassandra-default
│ └─CertificateRequest/apigee-cassandra-default-wnd7s
├─Secret/config-cassandra-default
├─Service/apigee-cassandra-default
│ ├─EndpointSlice/apigee-cassandra-default-7m9kx
│ └─EndpointSlice/apigee-cassandra-default-gzqpr
└─StatefulSet/apigee-cassandra-default
  ├─ControllerRevision/apigee-cassandra-default-6976b77bd
  ├─ControllerRevision/apigee-cassandra-default-7fc76588cb
  └─Pod/apigee-cassandra-default-0
  

Dieses Beispiel zeigt einen Pod. Typische Produktionsinstallationen enthalten aber drei oder mehr Pods.

Wenn der Status für Cassandra creating oder releasing ist, MUSS der Status zurückgesetzt werden. Bestimmte Probleme (wie Cassandra-Passwortänderungen) und Probleme, die sich nicht auf das Netzwerk beziehen, erfordern möglicherweise, dass Komponenten gelöscht werden. In solchen Fällen kann die Instanz eventuell nicht gelöscht werden (d. h. kubectl delete apigeedatastore -n NAMESPACE default). Die Verwendung von --force oder --grace-period=0 bietet auch keine Lösung.

reset soll den Status der Komponente (apigeedatastore) von creating oder releasing zurück in running zu ändern. Wenn Sie den Status auf diese Weise ändern, wird das zugrunde liegende Problem in der Regel nicht gelöst. In den meisten Fällen sollte die Komponente nach einem Zurücksetzen gelöscht werden.

Warnung: Wenn Sie apigeedatastore löschen, werden auch die nichtflüchtigen Volumes gelöscht. Alle Daten in Cassandra gehen dann verloren. Es wird deshalb empfohlen, die Cassandra-Daten zu sichern.

1. Versuchen Sie eine Löschung (dies wird nicht erfolgreich sein):

   kubectl delete -n NAMESPACE apigeedatastore default
   

   Dieser Befehl wird in der Regel nicht abgeschlossen. Drücken Sie Strg + C und beenden Sie den Aufruf.

2. Setzen Sie den Zustand zurück:

   Bei Fenster 1:

   kubectl proxy
   

   Bei Fenster 2:

   curl -X PATCH -H "Accept: application/json" -H "Content-Type: application/json-patch+json" --data '[{"op": "replace", "path": "/status/nestedState", "value": ""},{"op": "replace", "path": "/status/state", "value": "running"}]' 'http://127.0.0.1:8001/apis/apigee.cloud.google.com/v1alpha1/namespaces/apigee/apigeedatastores/default/status'
   

   Entfernen Sie den Finalizer (Fenster 2):

   kubectl edit -n NAMESPACE apigeedatastore default
   

   Suchen Sie die beiden folgenden Zeilen und löschen Sie sie:

   finalizers:
   - apigeedatastore.apigee.cloud.google.com

Häufige Fehlerszenarien

Proxykonfiguration mit Laufzeit nicht verfügbar

Dieser Fehler kann auf zwei Arten auftreten:

• runtime hat nicht den Status ready.
• runtime hat nicht die neueste Version der API erhalten.

1. Starten Sie mit den synchronizer-Pods.

   Prüfen Sie die Logs auf synchronizer. Häufig auftretende Fehler:

   • Fehlende Netzwerkverbindung (zu *.googleapi.com)
   • Falscher IAM-Zugriff (Dienstkonto nicht verfügbar oder mit der Synchronizer Manager-Berechtigung nicht anwendbar)
   • Die setSyncAuthorization API wurde nicht aufgerufen.

2. Prüfen Sie die runtime-Pods.

   In den Logs der runtime-Pods sehen Sie, warum runtime die Konfiguration nicht geladen hat. Von der Steuerungsebene wird versucht, die meisten Konfigurationsfehler zu umgehen, auch wenn zur Datenebene gewechselt wird. Wenn eine Validierung entweder nicht möglich oder nicht korrekt implementiert ist, kann runtime nicht geladen werden.

„Keine Laufzeit-Pods“ in der Steuerungsebene

1. Starten Sie mit den synchronizer-Pods.

   Prüfen Sie die Logs auf synchronizer. Häufig auftretende Fehler:

   • Fehlende Netzwerkverbindung (zu *.googleapi.com)
   • Falscher IAM-Zugriff (Dienstkonto nicht verfügbar oder mit der Synchronizer Manager-Berechtigung nicht anwendbar)
   • Die setSyncAuthorization API wurde nicht aufgerufen. Möglicherweise hat die Konfiguration die Datenebene nicht erreicht.

2. Prüfen Sie die runtime-Pods.

   In den Logs der runtime-Pods sehen Sie, warum runtime die Konfiguration nicht geladen hat.

3. Prüfen Sie die watcher-Pods.

   Die Komponente watcher konfiguriert den Ingress (Routing) und meldet den Proxy- und Ingress-Bereitstellungsstatus an die Steuerungsebene. Prüfen Sie diese Logs, um festzustellen, warum der watcher den Status nicht meldet. Eine häufige Ursache ist eine Abweichung zwischen den Namen in der Datei overrides.yaml und der Steuerungsebene für den Umgebungsnamen und/oder den Umgebungsgruppennamen.

Debug-Sitzung wird in der Steuerungsebene nicht angezeigt

1. Starten Sie mit den synchronizer-Pods.

   Prüfen Sie die Logs auf synchronizer. Häufig auftretende Fehler:

   • Fehlende Netzwerkverbindung (zu *.googleapi.com)
   • Falscher IAM-Zugriff (Dienstkonto nicht verfügbar oder mit der Synchronizer Manager-Berechtigung nicht anwendbar)
   • Die setSyncAuthorization API wurde nicht aufgerufen.
2. Prüfen Sie die runtime-Pods.
   Untersuchen Sie die Logs aus den runtime-Pods, um zu sehen, warum der runtime keine Debug-Logs an UDCA sendet.
3. Prüfen Sie die UDCA-Pods.
   Die Logs von UDCA zeigen, warum UDCA keine Informationen der Debug-Sitzung an die Steuerungsebene sendet.

Cassandra gibt große Cache-Antworten zurück

Die folgende Warnmeldung gibt an, dass Cassandra Lese- oder Schreibanfragen mit einer größeren Nutzlast empfängt. Sie kann ignoriert werden, da dieser Warnschwellenwert auf einen niedrigeren Wert für die Nutzlast der Antwort festgelegt ist.

Batch for [cache_ahg_gap_prod_hybrid.cache_map_keys_descriptor, cache_ahg_gap_prod_hybrid.cache_map_entry] is of size 79.465KiB, exceeding specified threshold of 50.000KiB by 29.465KiB