Pods Cassandra à l'état CrashLoopBackOff

Problème constaté

Les pods Cassandra peuvent passer à l'état CrashLoopBackOff lors de l'installation ou de la mise à niveau d'Apigee hybrid.

Messages d'erreur

La sortie kubectl get pods exécutée dans l'espace de noms apigee affiche un ou plusieurs pods Cassandra à l'état CrashLoopBackOff : 

kubectl get pods -n apigee

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

Causes possibles

Les pods Cassandra peuvent passer à l'état CrashLoopBackOff pour diverses raisons.

Cause Description
Échec de la résolution du nom d'hôte UnknownHostException générée pour la résolution DNS
Image incorrecte URL d'image incorrecte utilisée dans overrides.yaml
Problème d'expansion Problème de connectivité à l'hôte source Cassandra
Conflit de ports Les ports 7000 ou 7001 sont déjà utilisés
Même adresse IP Un nœud avec l'adresse /10.10.x.x existe déjà

Cause 1 : Échec de la résolution du nom d'hôte

La résolution du nom d'hôte pour les nœuds Cassandra échoue en raison de problèmes de configuration DNS dans le cluster. Les journaux de pod Cassandra peuvent afficher une entrée de journal semblable à celle-ci : 

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

Solution

Le nœud de calcul sur lequel le pod Cassandra doit être lancé doit pouvoir résoudre le nom d'hôte en une adresse IP valide via le service DNS du cluster. Pour contourner ce problème, vous pouvez exécuter la commande suivante sur tous les nœuds de calcul : 

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

Cause 2 : Image incorrecte

Image Cassandra incorrecte utilisée.

Diagnostic

Vérifiez le fichier overrides.yaml pour vous assurer que la bonne image est configurée pour Cassandra. Voici un exemple de strophe dans overrides.yaml avec l'image Cassandra correcte. 

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

Solution

Assurez-vous que la version et le nom de l'image Cassandra sont corrects dans le fichier overrides.yaml, puis réessayez d'exécuter la commande d'installation ou de mise à niveau. Vous pouvez utiliser l'option "List" (Lister) dans le script apigee-pull-push pour lister toutes les images de votre dépôt. Vous pouvez ensuite examiner ces images pour vous assurer qu'elles proviennent toutes de la version souhaitée d'Hybrid.

Cause 3 : Problème d'expansion

Il est possible que le pod Cassandra ne puisse pas se connecter au nœud Seed lors de l'expansion vers une nouvelle région.

Diagnostic

  1. Les journaux de pod Cassandra peuvent afficher des entrées de journal semblables à l'exemple suivant : 
    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. Vérifiez la connectivité entre le nœud défaillant actuel et le nœud de seed.
  3. Identifiez le nœud source configuré dans overrides.yaml pour la nouvelle région. Le nœud de seed est configuré dans overrides.yaml au moment de l'expansion de la région sous le nom de champ : multiRegionSeedHost.

    Exemple de section Cassandra de votre overrides.yaml montrant le multiRegionSeedHost. 

    cassandra:
  multiRegionSeedHost: "1.2.X.X"
  datacenter: "dc-1"
  rack: "rc-1"
  hostNetwork: false
  clusterName: QA
  4. Créez un conteneur client pour vérifier la connectivité entre le pod Cassandra défaillant et le nœud de seed en suivant les instructions de la section Créer un conteneur client pour le débogage.
  5. Une fois que vous avez exécuté ssh dans le conteneur client et que vous disposez d'un shell Bash, utilisez telnet pour vérifier la connectivité du nœud actuel au nœud de seed via les ports 7001 et 7199.

    Exemple de commande telnet et de résultat montrant l'échec de la connexion 

    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

Solution

  1. Collaborez avec votre équipe d'administrateurs de cluster pour vous assurer qu'il existe une connectivité réseau entre les nœuds Cassandra de tous les clusters appartenant à la même organisation.
  2. Assurez-vous qu'aucune règle de pare-feu ne bloque le trafic du nœud défaillant vers le nœud de seed.

Cause 4 : Conflit de port

Conflit de port

Cassandra a essayé de se lancer pour écouter sur les ports 7000 et 7001, mais un autre service, tel que ssh, écoutait déjà sur ce port.

Diagnostic

Les journaux de pod Cassandra peuvent afficher des entrées semblables à l'exemple suivant : 

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)

Cela suggère que le port est déjà utilisé.

Solution

Arrêtez et supprimez tout service autre que Cassandra qui écoute sur les ports 7000 et 7001. Cela devrait permettre aux applications Cassandra de démarrer.

Cause 5 : Même adresse IP

Un ancien pod Cassandra avec la même adresse IP existe dans le cluster. Cette situation peut se produire après la désinstallation ou la réinstallation de Hybrid.

Diagnostic

  1. Recherchez l'erreur suivante dans le fichier system.log de Cassandra : 
    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. Examinez le résultat de la commande nodetool status à partir de l'un des centres de données encore actifs pour voir si un nœud Cassandra est affiché avec la même adresse IP que dans le message d'erreur (10.10.1.1).

    Exemple de résultat de la commande 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

Solution

  1. Supprimez l'ancien nœud Cassandra à l'aide de la commande nodetool remove : 
    nodetool removenode HOST_ID

    L'ID de l'hôte se trouve dans la sortie de l'état nodetool. Par exemple, 4d96eaf5-7e75-4aeb-bc47-9e45fdb4b533 dans l'exemple de résultat de l'état nodetool précédent.

  2. Une fois l'ancien nœud Cassandra supprimé, réessayez d'installer Hybrid.

Vous devez collecter des informations de diagnostic

Si le problème persiste, même après avoir suivi les instructions ci-dessus, rassemblez les informations de diagnostic suivantes, puis contactez le service clientGoogle Cloud  :

  1. ID du projet Google Cloud .
  2. Organisation Apigee hybrid.
  3. Les fichiers overrides.yaml des régions sources et nouvelles, qui masquent les informations sensibles.
  4. Les résultats des commandes dans Apigee hybrid must-gather.