Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Für dieses Thema gibt es keine entsprechende Apigee Edge-Dokumentation.
In diesem Thema werden Schritte erläutert, mit denen Sie Probleme mit dem Cassandra-Datenspeicher beheben können. Cassandra ist ein nichtflüchtiger Datenspeicher, der in der Komponente cassandra
der Hybridlaufzeitarchitektur ausgeführt wird.
Weitere Informationen finden Sie unter Laufzeitdienst-Konfiguration – Übersicht.
Cassandra-Pods verbleiben im Status "Ausstehend"
Symptom
Nach dem Start verbleiben die Cassandra-Pods im Status Ausstehend.
Fehlermeldung
Wenn Sie den Pod-Status mit kubectl
aufrufen, sehen Sie, dass ein oder mehrere Cassandra-Pods im Status Pending
verbleiben. Der Status Pending
gibt an, dass Kubernetes den Pod auf einem Knoten nicht planen kann: Der Pod kann nicht erstellt werden. Beispiel:
kubectl get pods -n NAMESPACE
NAME READY STATUS RESTARTS AGE
adah-resources-install-4762w 0/4 Completed 0 10m
apigee-cassandra-default-0 0/1 Pending 0 10m
...
Mögliche Ursachen
Ein Pod, der im Status "Ausstehend" verbleibt, kann mehrere Ursachen haben. Beispiel:
Ursache | Beschreibung |
---|---|
Unzureichende Ressourcen | Es ist nicht genügend CPU oder Arbeitsspeicher zum Erstellen des Pods verfügbar. |
Volume nicht erstellt | Der Pod wartet auf die Erstellung des nichtflüchtigen Volumes. |
Amazon EBS CSI-Treiber fehlt | Bei EKS-Installationen ist der erforderliche Amazon EBS CSI-Treiber nicht installiert. |
Diagnose
Verwenden Sie kubectl
, um den Pod zu beschreiben und die Ursache des Fehlers zu ermitteln. Beispiel:
kubectl -n NAMESPACE describe pods POD_NAME
Beispiel:
kubectl describe pods apigee-cassandra-default-0 -n apigee
Die Ausgabe kann eines der folgenden möglichen Probleme anzeigen:
- Wenn unzureichende Ressourcen das Problem sind, wird eine Warnmeldung angezeigt, dass die CPU oder der Arbeitsspeicher nicht ausreicht.
- Wenn in der Fehlermeldung darauf hingewiesen wird, dass der Pod ungebundene sofortige PersistentVolumeClaims (PVC) hat, kann der Pod kein nichtflüchtiges Volume erstellen.
Lösung
Unzureichende Ressourcen
Ändern Sie den Cassandra-Knotenpool so, dass er über ausreichende CPU- und Speicherressourcen verfügt. Weitere Informationen finden Sie unter Größe eines Knotenpools anpassen.
Kein nichtflüchtiges Volume erstellt
Wird ein Problem mit einem nichtflüchtigen Volume festgestellt, so beschreiben Sie den PVC (PersistentVolumeClaim), um festzustellen, warum er nicht erstellt wird:
- Listen Sie die PVCs im Cluster auf:
kubectl -n NAMESPACE get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE cassandra-data-apigee-cassandra-default-0 Bound pvc-b247faae-0a2b-11ea-867b-42010a80006e 10Gi RWO standard 15m ...
- Beschreiben Sie den PVC für den Pod, der fehlschlägt. Mit dem folgenden Befehl wird beispielsweise der PVC beschrieben, der an den Pod
apigee-cassandra-default-0
gebunden ist:kubectl apigee describe pvc cassandra-data-apigee-cassandra-default-0 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ProvisioningFailed 3m (x143 over 5h) persistentvolume-controller storageclass.storage.k8s.io "apigee-sc" not found
Beachten Sie, dass in diesem Beispiel die StorageClass namens
apigee-sc
nicht vorhanden ist. Erstellen Sie zum Beheben dieses Problems die fehlende StorageClass im Cluster, wie unter Standard-StorageClass ändern beschrieben.
Weitere Informationen finden Sie unter Pods debuggen.
Amazon EBS CSI-Treiber fehlt
Wenn die Hybridinstanz auf einem EKS-Cluster ausgeführt wird, achten Sie darauf, dass der EKS-Cluster den CSI-Treiber (Container Storage Interface) von Amazon EBS verwendet. Weitere Informationen finden Sie in den häufig gestellten Fragen zur Amazon EBS CSI-Migration.
Cassandra-Pods verbleiben im CrashLoopBackoff-Status
Symptom
Während des Starts verbleiben die Cassandra-Pods im Status CrashLoopBackoff.
Fehlermeldung
Wenn Sie den Pod-Status mit kubectl
aufrufen, sehen Sie, dass sich ein oder mehrere Cassandra-Pods im Status CrashLoopBackoff
befinden.
Dieser Status gibt an, dass Kubernetes den Pod nicht erstellen kann. Beispiel:
kubectl get pods -n NAMESPACE
NAME READY STATUS RESTARTS AGE
adah-resources-install-4762w 0/4 Completed 0 10m
apigee-cassandra-default-0 0/1 CrashLoopBackoff 0 10m
...
Mögliche Ursachen
Ein Pod, der im Status CrashLoopBackoff
verbleibt, kann mehrere Ursachen haben. Beispiel:
Ursache | Beschreibung |
---|---|
Rechenzentrum unterscheidet sich vom vorherigen Rechenzentrum | Dieser Fehler weist darauf hin, dass der Cassandra-Pod ein nichtflüchtiges Volume mit Daten aus einem vorherigen Cluster hat und die neuen Pods dem alten Cluster nicht mehr beitreten können. Dies geschieht in der Regel, wenn veraltete nichtflüchtige Volumes vom vorherigen Cassandra-Cluster auf demselben Kubernetes-Knoten erhalten bleiben. Dieses Problem kann auftreten, wenn Sie Cassandra im Cluster löschen und neu erstellen. |
Kubernetes-Upgrade | Ein Kubernetes-Upgrade kann sich auf den Cassandra-Cluster auswirken. Dies kann auftreten, wenn die Anthos-Worker-Knoten, auf denen die Cassandra-Pods gehostet werden, auf eine neue Betriebssystemversion aktualisiert werden. |
Diagnose
Prüfen Sie das Cassandra-Fehlerlog, um die Ursache des Problems zu ermitteln.
- Listen Sie die Pods auf, um die ID des Cassandra-Pods zu erhalten, der fehlschlägt:
kubectl get pods -n NAMESPACE
- Prüfen Sie das Log des fehlerhaften Pods:
kubectl logs POD_ID -n NAMESPACE
Lösung
Suchen Sie die folgenden Hinweise im Log des Pods:
Rechenzentrum unterscheidet sich vom vorherigen Rechenzentrum
Wenn dieser Logeintrag angezeigt wird:
Cannot start node if snitch's data center (us-east1) differs from previous data center
- Prüfen Sie, ob der Cluster veraltete oder alte PVCs enthält und löschen Sie diese.
- Wenn es sich um eine Neuinstallation handelt, löschen Sie alle PVCs und wiederholen die Einrichtung. Beispiel:
kubectl -n NAMESPACE get pvc
kubectl -n NAMESPACE delete pvc cassandra-data-apigee-cassandra-default-0
Anthos-Upgrade ändert Sicherheitseinstellungen
Prüfen Sie die Cassandra-Logs auf diese Fehlermeldung:
/opt/apigee/run.sh: line 68: ulimit: max locked memory: cannot modify limit: Operation not permitted
- Wenn die Hybrid-Instanz multiregional ist, deaktivieren Sie die betroffene Hybrid-Instanz und erweitern Sie die betroffene Region noch einmal.
- Wenn die Hybrid-Instanz eine einzelne Region ist, führen Sie auf jedem Cassandra-Pod in der Hybrid-Instanz einen rollierenden Neustart durch.
Client-Container zur Fehlerbehebung erstellen
In diesem Abschnitt wird erläutert, wie Sie einen Client-Container erstellen, über den Sie auf Cassandra-Debugging-Dienstprogramme wie cqlsh
zugreifen können. Diese Dienstprogramme können zum Abfragen von Cassandra-Tabellen und für Fehlerbehebungszwecke nützlich sein.
Client-Container erstellen
So erstellen Sie den Client-Container:
- Der Container muss das TLS-Zertifikat aus dem Pod
apigee-cassandra-user-setup
verwenden. Dies wird als Kubernetes-Secret gespeichert. Rufen Sie den Namen des Secrets ab, in dem dieses Zertifikat gespeichert ist:kubectl get secrets -n apigee --field-selector type=kubernetes.io/tls | grep apigee-cassandra-user-setup | awk '{print $1}'
Dieser Befehl gibt den Namen des Secrets zurück. Beispiel:
apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls
. Sie benötigen ihn in der YAML-Datei im FeldsecretName
. - Öffnen Sie eine neue Datei und fügen Sie folgende Pod-Spezifikation in diese ein:
apiVersion: v1 kind: Pod metadata: labels: name: CASSANDRA_CLIENT_NAME # For example: my-cassandra-client namespace: apigee spec: containers: - name: CASSANDRA_CLIENT_NAME image: "gcr.io/apigee-release/hybrid/apigee-hybrid-cassandra-client:YOUR_APIGEE_HYBRID_VERSION" # For example, 1.10.4. imagePullPolicy: Always command: - sleep - "3600" env: - name: CASSANDRA_SEEDS value: apigee-cassandra-default.apigee.svc.cluster.local - name: APIGEE_DML_USER valueFrom: secretKeyRef: key: dml.user name: apigee-datastore-default-creds - name: APIGEE_DML_PASSWORD valueFrom: secretKeyRef: key: dml.password name: apigee-datastore-default-creds volumeMounts: - mountPath: /opt/apigee/ssl name: tls-volume readOnly: true volumes: - name: tls-volume secret: defaultMode: 420 secretName: YOUR_SECRET_NAME # For example: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls restartPolicy: Never
- Speichern Sie die Datei mit der Erweiterung
.yaml
. Beispiel:my-spec.yaml
- Wenden Sie die Spezifikation auf Ihren Cluster an:
kubectl apply -f YOUR_SPEC_FILE.yaml -n apigee
- Melden Sie sich beim Container an:
kubectl exec -n apigee CASSANDRA_CLIENT_NAME -it -- bash
- Stellen Sie mit dem folgenden Befehl eine Verbindung zur Cassandra-Schnittstelle
cqlsh
her. Geben Sie den Befehl genau so ein:cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl
Client-Pod löschen
Verwenden Sie diesen Befehl, um den Cassandra-Client-Pod zu löschen:
kubectl delete pods -n apigee cassandra-client
Falsch konfigurierte Regionserweiterung: alle Cassandra-Knoten unter einem Rechenzentrum
Diese Situation tritt bei einer multiregionalen Erweiterung auf GKE- und GKE On-Prem-Plattformen (Anthos) auf. Versuchen Sie nicht, alle Ihre Cassandra-Knoten im selben Rechenzentrum zu erstellen.
Symptom
Cassandra-Knoten werden im Rechenzentrum für die zweite Region nicht erstellt.
Fehlermeldung
failed to rebuild from dc-1: java.lang.RuntimeException : Error while rebuilding node: Stream failed
Lösung
Reparieren Sie die falsch konfigurierte Regionserweiterung mit den folgenden Schritten:
- Aktualisieren Sie den Cassandra-
replicaCount
in der Dateioverrides.yaml
für das zweite Rechenzentrum auf1
. Beispiel:cassandra: . . . replicaCount: 1
Wenden Sie die Einstellung mit
apigeectl apply
an:$APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml
- Verwenden Sie
kubectl exec
, um mit dem folgenden Befehl auf den verbleibenden Cassandra-Pod zuzugreifen:kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
- Nehmen Sie den verbleibenden Cassandra-Pod mit dem folgenden Befehl außer Betrieb:
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD decommission
- Löschen Sie die Cassandra-Pods aus dem zweiten Rechenzentrum mit
apigeectl delete
mit dem Argument--datastore
. Beispiel:$APIGEECTL_HOME/apigeectl delete -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
- Wechseln Sie mit dem Kubernetes-Kontext zum Cluster für Ihr erstes Rechenzentrum:
kubectl config use-context FIRST_DATACENTER_CLUSTER
- Achten Sie darauf, dass sich im ersten Rechenzentrum keine Cassandra-Knoten in einem inaktiven Zustand befinden.
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status
- Prüfen Sie, ob die falsch konfigurierten Cassandra-Knoten (für das zweite Rechenzentrum) aus dem ersten Rechenzentrum entfernt wurden. Achten Sie darauf, dass die in der nodetool-Statusausgabe angezeigten IP-Adressen nur die IP-Adressen für die Cassandra-Pods sind, die für Ihr erstes Rechenzentrum vorgesehen sind. In der folgenden Ausgabe sollte beispielsweise die IP-Adresse
10.100.0.39
für einen Pod in Ihrem ersten Rechenzentrum vorgesehen sein.kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status
Datacenter: dc-1 ================ Status=U/D (Up/Down) | State=N/L/J/M (Normal/Leaving/Joining/Moving) -- Address Load Tokens Owns (effective) Host ID Rack UN 10.100.0.39 4.21 MiB 256 100.0% a0b1c2d3-e4f5-6a7b-8c9d-0e1f2a3b4c5d ra-1 - Prüfen Sie, ob die Datei
overrides.yaml
für das zweite Rechenzentrum die Einstellung für den Rechenzentrumsnamen im Abschnitt „cassandra“ enthält. Beispiel:cassandra: datacenter: DATA_CENTER_2 rack: "RACK_NAME" # "ra-1" is the default value. . . .
- Aktualisieren Sie die Einstellung
cassandra:replicaCount
in der Dateioverrides.yaml
für das zweite Rechenzentrum auf die gewünschte Zahl. Beispiel:cassandra: datacenter: DATA_CENTER_2 . . . replicaCount: 3
- Wenden Sie die Datei
overrides.yaml
für das zweite Rechenzentrum mit dem Argument--datastore
an. Beispiel:$APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
- Verwenden Sie
kubectl exec
, um auf einen der neuen Cassandra-Pods im zweiten Rechenzentrum zuzugreifen und zu prüfen, ob zwei Rechenzentren vorhanden sind:"nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status"
Weitere Ressourcen
Einführung in Playbooks für Apigee X und Apigee Hybrid