Pod di Cassandra nello stato CrashLoopBackOff

Sintomo

I pod Cassandra possono passare allo stato CrashLoopBackOff durante l'installazione o l'upgrade di Apigee hybrid.

Messaggi di errore

L'output di kubectl get pods quando viene eseguito nello spazio dei nomi apigee mostra uno o più pod Cassandra nello stato CrashLoopBackOff: 

kubectl get pods -n apigee

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

Cause possibili

I pod Cassandra possono entrare nello stato CrashLoopBackOff per vari motivi.

Causa Descrizione
Risoluzione del nome host non riuscita UnknownHostException generato per la risoluzione DNS
Immagine errata URL immagine errato utilizzato in overrides.yaml
Problema di espansione Problema di connettività all'host seed di Cassandra
Conflitto di porte Porta 7000 o 7001 già in uso
Stesso indirizzo IP Esiste già un nodo con l'indirizzo /10.10.x.x

Causa 1: risoluzione del nome host non riuscita

La risoluzione del nome host per i nodi Cassandra non riesce a causa di problemi di configurazione DNS nel cluster. I log dei pod di Cassandra potrebbero mostrare una voce di log simile: 

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

Risoluzione

Il nodo worker in cui è previsto l'avvio del pod Cassandra deve essere in grado di risolvere il nome host in un indirizzo IP valido tramite il servizio DNS del cluster. Per una soluzione alternativa, puoi eseguire il seguente comando su tutti i nodi worker: 

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

Causa 2: immagine errata

È stata utilizzata un'immagine Cassandra errata.

Diagnosi

Controlla il file overrides.yaml per assicurarti che l'immagine corretta sia configurata per Cassandra. Ecco un esempio di stanza in overrides.yaml con l'immagine Cassandra corretta. 

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

Risoluzione

Assicurati che la versione e il nome dell'immagine Cassandra siano corretti nel file overrides.yaml e riprova a eseguire il comando di installazione o upgrade. Puoi utilizzare l'opzione Elenco nello script apigee-pull-push per elencare tutte le immagini nel tuo repository. Puoi quindi esaminare queste immagini per assicurarti che siano tutte quelle della versione di Hybrid che ti interessa.

Causa 3: problema di espansione

Il pod Cassandra potrebbe non essere in grado di connettersi al nodo Seed durante l'espansione a una nuova regione.

Diagnosi

  1. I log dei pod Cassandra potrebbero mostrare voci di log simili a quelle dell'esempio seguente: 
    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
  2. Controlla la connettività tra il nodo con errori corrente e il nodo seed.
  3. Identifica il nodo seed configurato in overrides.yaml per la nuova regione. Il nodo seed è configurato in overrides.yaml al momento dell'espansione della regione nel nome del campo: multiRegionSeedHost.

    Stanza di esempio di Cassandra dal tuo overrides.yaml che mostra multiRegionSeedHost. 

    cassandra:
  multiRegionSeedHost: "1.2.X.X"
  datacenter: "dc-1"
  rack: "rc-1"
  hostNetwork: false
  clusterName: QA
  4. Crea un contenitore client per verificare la connettività tra il pod Cassandra non riuscito e il nodo seed seguendo le istruzioni riportate in Creare un contenitore client per il debug.
  5. Dopo aver eseguito ssh nel container client e aver ottenuto una shell bash, utilizza telnet per verificare la connettività dal nodo corrente al nodo seed tramite le porte 7001 e 7199.

    Esempio di comando telnet e output che mostra l'errore di connessione 

    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

Risoluzione

  1. Collabora con il team di amministrazione del cluster per garantire la connettività di rete tra i nodi Cassandra in tutti i cluster che fanno parte della stessa organizzazione.
  2. Assicurati che non siano presenti regole firewall che bloccano il traffico dal nodo non riuscito al nodo seed.

Causa 4: conflitto di porte

Conflitto di porte

Cassandra stava cercando di connettersi per ascoltare sulle porte 7000 e 7001, ma un altro servizio, ad esempio SSH, era già in ascolto su quella porta.

Diagnosi

I log dei pod di Cassandra potrebbero mostrare voci simili a quelle dell'esempio seguente: 

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)

Ciò suggerisce che la porta è già in uso.

Risoluzione

Arresta e rimuovi qualsiasi servizio diverso da Cassandra in ascolto sulle porte 7000 e 7001. In questo modo, le applicazioni Cassandra dovrebbero essere avviate.

Causa 5: stesso indirizzo IP

Nel cluster esiste un pod Cassandra precedente con lo stesso IP. Questa situazione può verificarsi dopo la disinstallazione o la reinstallazione di Hybrid.

Diagnosi

  1. Controlla il file system.log di Cassandra per verificare che non contenga il seguente errore: 
    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.
  2. Esamina l'output del comando nodetool status da uno qualsiasi dei data center ancora attivi per verificare se viene visualizzato un nodo Cassandra con lo stesso IP del messaggio di errore: 10.10.1.1.

    Esempio di output comando 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

Risoluzione

  1. Rimuovi il vecchio nodo Cassandra utilizzando il comando nodetool remove: 
    nodetool removenode HOST_ID

    L'ID host si trova nell'output di nodetool status. Ad esempio, 4d96eaf5-7e75-4aeb-bc47-9e45fdb4b533 nell'output di nodetool status dell'esempio precedente.

  2. Una volta rimosso il nodo Cassandra precedente, riprova l'installazione ibrida.

Deve raccogliere informazioni diagnostiche

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche e contatta l'assistenza clientiGoogle Cloud :

  1. L'ID progetto Google Cloud .
  2. L'organizzazione Apigee hybrid.
  3. I file overrides.yaml delle regioni di origine e di quelle nuove, mascherando eventuali informazioni sensibili.
  4. Gli output dei comandi in Apigee hybrid must-gather.