Diese Seite wurde von der Cloud Translation API übersetzt.

Cassandra-Pods im CrashLoopBackOff-Status

Symptom

Cassandra-Pods können während der Installation oder des Upgrades von Apigee Hybrid in den Status CrashLoopBackOff wechseln.

Fehlermeldungen

Die kubectl get pods-Ausgabe, wenn sie im Namespace apigee ausgeführt wird, zeigt einen oder mehrere Cassandra-Pods im Status CrashLoopBackOff an:

kubectl get pods -n apigee

NAME                          READY   STATUS            RESTARTS   AGE
apigee-cassandra-default-0    0/1     CrashLoopBackoff  0          9m

Mögliche Ursachen

Cassandra-Pods können aus verschiedenen Gründen den Status CrashLoopBackOff annehmen.

Ursache	Beschreibung
Fehler bei der Hostnamensauflösung	`UnknownHostException` für die DNS-Auflösung ausgelöst
Falsches Bild	Falsche Bild-URL in `overrides.yaml` verwendet
Problem mit der Erweiterung	Verbindungsproblem mit dem Cassandra-Seed-Host
Portkonflikt	Port 7000 oder 7001 wird bereits verwendet
Dieselbe IP-Adresse	Ein Knoten mit der Adresse /10.10.x.x ist bereits vorhanden

Ursache 1: Hostname konnte nicht aufgelöst werden

Die Hostnamensauflösung für Cassandra-Knoten schlägt aufgrund von Problemen mit der DNS-Konfiguration im Cluster fehl. In den Pod-Logs von Cassandra wird möglicherweise ein ähnlicher Logeintrag angezeigt:

ERROR [main] 2025-01-12 13:23:34,569 CassandraDaemon.java:803 -
Local host name unknown: java.net.UnknownHostException: ip-xx-xx-xx-xx.example.com:
ip-xx-xx-xx-xx.example.com: Name or service not known

Lösung

Der Worker-Knoten, auf dem der Cassandra-Pod gestartet werden soll, muss den Hostnamen über den Cluster-DNS-Dienst in eine gültige IP-Adresse auflösen können. Als Workaround können Sie den folgenden Befehl auf allen Worker-Knoten ausführen:

echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

Hinweis:Dieses Problem kann auftreten, wenn der Hostname nicht in Ihrer etc/hosts-Datei enthalten ist. Empfehlungen für Ihre Plattform finden Sie unter Multiregionale Bereitstellung: Voraussetzungen.

Ursache 2: Falsches Bild

Falsches Cassandra-Image verwendet.

Diagnose

Prüfen Sie die Datei overrides.yaml, um sicherzustellen, dass das richtige Image für Cassandra konfiguriert ist. Hier ist ein Beispiel für einen Abschnitt in overrides.yaml mit dem richtigen Cassandra-Image.

cassandra:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-hybrid-cassandra"
    tag: "1.15.0"
    pullPolicy: IfNotPresent

Lösung

Prüfen Sie, ob die Version und der Name des Cassandra-Images in der Datei overrides.yaml korrekt sind, und versuchen Sie es noch einmal mit dem Installations- oder Upgradebefehl. Mit der Option „List“ im apigee-pull-push-Script können Sie alle Bilder in Ihrem Repository auflisten. Anschließend können Sie diese Bilder überprüfen, um sicherzustellen, dass es sich um alle Bilder der gewünschten Version von Hybrid handelt.

Ursache 3: Problem mit der Erweiterung

Der Cassandra-Pod kann möglicherweise keine Verbindung zum Seed-Knoten herstellen, wenn er auf eine neue Region erweitert wird.

Diagnose

In den Cassandra-Pod-Logs werden möglicherweise ähnliche Logeinträge wie im folgenden Beispiel angezeigt:

INFO  [main] 2024-07-28 05:25:15,662 GossipingPropertyFileSnitch.java:68 - Unable to load cassandra-topology.properties; compatibility mode disabled
The seed provider lists no seeds.
WARN  [main] 2024-07-28 05:25:15,703 SimpleSeedProvider.java:60 - Seed provider couldn't lookup host apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local
Exception (org.apache.cassandra.exceptions.ConfigurationException) encountered during startup: The seed provider lists no seeds.
ERROR [main] 2024-07-28 05:25:15,703 CassandraDaemon.java:803 - Exception encountered during startup: The seed provider lists no seeds.
INFO  [ScheduledTasks:1] 2024-07-28 05:25:15,833 StorageService.java:136 - Overriding RING_DELAY to 30000ms

Prüfen Sie die Verbindung zwischen dem aktuellen fehlerhaften Knoten und dem Seed-Knoten.
Ermitteln Sie den in overrides.yaml konfigurierten Seed-Knoten für die neue Region. Der Seed-Knoten wird bei der Erweiterung der Region in overrides.yaml unter dem Feldnamen multiRegionSeedHost konfiguriert.
Beispiel für einen Cassandra-Abschnitt aus Ihrer overrides.yaml, der die multiRegionSeedHost zeigt.
```
cassandra:
  multiRegionSeedHost: "1.2.X.X"
  datacenter: "dc-1"
  rack: "rc-1"
  hostNetwork: false
  clusterName: QA
```
Erstellen Sie einen Client-Container, um die Verbindung zwischen dem fehlerhaften Cassandra-Pod und dem Seed-Knoten zu prüfen. Folgen Sie dazu der Anleitung unter Client-Container zur Fehlerbehebung erstellen.
Nachdem Sie ssh in den Clientcontainer und eine Bash-Shell haben, prüfen Sie mit Telnet die Verbindung vom aktuellen Knoten zum Seed-Knoten über die Ports 7001 und 7199.
Beispiel für einen Telnet-Befehl und eine Ausgabe, die einen Verbindungsfehler zeigt
```
telnet 10.0.0.0 7001
Trying 10.0.0.0...
telnet: Unable to connect to remote host: Connection timed out
telnet 10.0.0.0 7199
Trying 10.0.0.0...
telnet: Unable to connect to remote host: Connection timed out
```

Lösung

Sorgen Sie gemeinsam mit Ihrem Clusteradministrator dafür, dass eine Netzwerkverbindung zwischen Cassandra-Knoten in allen Clustern besteht, die zur selben Organisation gehören.
Achten Sie darauf, dass keine Firewallregeln den Traffic vom fehlerhaften Knoten zum Seed-Knoten blockieren.

Ursache 4: Portkonflikt

Portkonflikt

Cassandra hat versucht, die Ports 7000 und 7001 zu überwachen, aber ein anderer Dienst wie SSH hat diesen Port bereits überwacht.

Diagnose

In den Pod-Logs von Cassandra werden möglicherweise ähnliche Einträge wie im folgenden Beispiel angezeigt:

Unable to create ssl socket
Fatal configuration error; unable to start server.  See log for stacktrace.
ERROR [main] 2023-02-27 13:01:54,239 CassandraDaemon.java:803 - Fatal configuration error
org.apache.cassandra.exceptions.ConfigurationException: Unable to create ssl socket
       at org.apache.cassandra.net.MessagingService.getServerSockets(MessagingService.java:701) ~[apache-cassandra-3.11.9.jar:3.11.9]
       at org.apache.cassandra.net.MessagingService.listen(MessagingService.java:681) ~[apache-cassandra-3.11.9.jar:3.11.9]
       at org.apache.cassandra.net.MessagingService.listen(MessagingService.java:665) ~[apache-cassandra-3.11.9.jar:3.11.9]
       at org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:831) ~[apache-cassandra-3.11.9.jar:3.11.9]
       at org.apache.cassandra.service.StorageService.initServer(StorageService.java:717) ~[apache-cassandra-3.11.9.jar:3.11.9]
       at org.apache.cassandra.service.StorageService.initServer(StorageService.java:666) ~[apache-cassandra-3.11.9.jar:3.11.9]
       at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395) [apache-cassandra-3.11.9.jar:3.11.9]
       at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633) [apache-cassandra-3.11.9.jar:3.11.9]
       at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786) [apache-cassandra-3.11.9.jar:3.11.9]
Caused by: java.net.BindException: Address already in use (Bind failed)
Caused by: java.net.BindException: Address already in use (Bind failed)

Das deutet darauf hin, dass der Port bereits verwendet wird.

Lösung

Beenden und entfernen Sie alle Dienste außer Cassandra, die auf den Ports 7000 und 7001 lauschen. Dadurch sollten Cassandra-Anwendungen gestartet werden können.

Ursache 5: Gleiche IP-Adresse

Im Cluster ist ein älterer Cassandra-Pod mit derselben IP-Adresse vorhanden. Dies kann nach der Deinstallation oder Neuinstallation von Hybrid passieren.

Diagnose

Prüfen Sie die system.log-Datei von Cassandra auf den folgenden Fehler:

INFO  [HANDSHAKE-/10.106.32.131] 2020-11-30 04:28:51,432 OutboundTcpConnection.java:561 - Handshaking version with /10.10.1.1
Exception (java.lang.RuntimeException) encountered during startup: A node with address /10.10.1.1 already exists, cancelling join. Use cassandra.replace_address if you want to replace this node.
java.lang.RuntimeException: A node with address /10.10.1.1 already exists, cancelling join. Use cassandra.replace_address if you want to replace this node.
   at org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:558)
   at org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:804)
   at org.apache.cassandra.service.StorageService.initServer(StorageService.java:664)
   at org.apache.cassandra.service.StorageService.initServer(StorageService.java:613)
   at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:379)
   at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:602)
   at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:691)
ERROR [main] 2020-11-30 04:28:52,287 CassandraDaemon.java:708 - Exception encountered during startup
java.lang.RuntimeException: A node with address /10.10.1.1 already exists, cancelling join. Use cassandra.replace_address if you want to replace this node.

Prüfen Sie die Ausgabe des Befehls nodetool status von einem der DCs, die noch aktiv sind, um festzustellen, ob ein Cassandra-Knoten mit derselben IP-Adresse wie in der Fehlermeldung angezeigt wird – 10.10.1.1.

Beispielausgabe des Befehls „nodetool status“

kubectl exec apigee-cassandra-default-0 -n  -- nodetool status
Datacenter dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens  Owns (effective)  Host ID                               Rack
UN  10.10.1.1  649.6 KiB  256     100.0%            4d96eaf5-7e75-4aeb-bc47-9e45fdb4b533  ra-1
UN  10.10.1.2  885.2 KiB  256     100.0%            261a15dd-1b51-4918-a63b-551a64e74a5e  ra-1
UN  10.10.1.3  693.74 KiB 256     100.0%            91e22ba4-fa53-4340-adaf-db32430bdda9  ra-1

Lösung

Entfernen Sie den alten Cassandra-Knoten mit dem Befehl nodetool remove:
```
nodetool removenode HOST_ID
```
Die Host-ID finden Sie in der Ausgabe von „nodetool status“. Beispiel: 4d96eaf5-7e75-4aeb-bc47-9e45fdb4b533 in der vorherigen Beispielausgabe des Knotentoolstatus.
Nachdem der ältere Cassandra-Knoten entfernt wurde, versuchen Sie noch einmal, Hybrid zu installieren.

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 -Kundenservice:

Die Google Cloud Projekt-ID.
Die Apigee Hybrid-Organisation.
Die overrides.yaml-Dateien aus Quellregionen und neuen Regionen, mit denen vertrauliche Informationen maskiert werden.
Die Ausgaben der Befehle in Apigee Hybrid Must-Gather.

Cassandra-Pods im CrashLoopBackOff-Status Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Symptom

Fehlermeldungen

Mögliche Ursachen

Ursache 1: Hostname konnte nicht aufgelöst werden

Lösung

Ursache 2: Falsches Bild

Diagnose

Lösung

Ursache 3: Problem mit der Erweiterung

Diagnose

Lösung

Ursache 4: Portkonflikt

Diagnose

Lösung

Ursache 5: Gleiche IP-Adresse

Diagnose

Lösung

Erfassen von Diagnoseinformationen erforderlich

Cassandra-Pods im CrashLoopBackOff-Status