Pods do Cassandra no status CrashLoopBackOff

Sintoma

Os pods do Cassandra podem entrar em um estado CrashLoopBackOff durante a instalação ou o upgrade da Apigee híbrida.

Mensagens de erro

A saída de kubectl get pods quando executada no namespace apigee mostra um ou mais pods do Cassandra no status CrashLoopBackOff: 

kubectl get pods -n apigee

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

Causas possíveis

Os pods do Cassandra podem entrar no status CrashLoopBackOff por vários motivos.

Causa Descrição
Falha na resolução do nome do host UnknownHostException gerado para resolução de DNS
Imagem incorreta URL da imagem incorreto usado em overrides.yaml
Problema de expansão Problema de conectividade com o host de seed do Cassandra
Conflito de porta A porta 7000 ou 7001 já está em uso
Mesmo endereço IP Já existe um nó com o endereço /10.10.x.x

Causa 1: falha na resolução do nome do host

A resolução de nome de host para nós do Cassandra falha devido a problemas de configuração de DNS no cluster. Os registros do pod do Cassandra podem mostrar uma entrada de registro semelhante: 

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

Resolução

O nó de trabalho em que o pod do Cassandra está programado para ser iniciado precisa resolver o nome de host para um endereço IP válido usando o serviço DNS do cluster. Como solução alternativa, execute o seguinte comando em todos os nós de trabalho: 

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

Causa 2: imagem incorreta

A imagem do Cassandra usada está incorreta.

Diagnóstico

Verifique o arquivo overrides.yaml para garantir que a imagem correta esteja configurada para o Cassandra. Confira um exemplo de estrofe em overrides.yaml com a imagem correta do Cassandra. 

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

Resolução

Verifique se a versão e o nome da imagem do Cassandra estão corretos no arquivo overrides.yaml e tente executar o comando de instalação ou upgrade novamente. Use a opção "List" no script apigee-pull-push para listar todas as imagens no seu repositório. Em seguida, revise essas imagens para garantir que sejam todas da versão pretendida do Hybrid.

Causa 3: problema de expansão

O pod do Cassandra talvez não consiga se conectar ao nó de seed ao expandir para uma nova região.

Diagnóstico

  1. Os registros do pod do Cassandra podem mostrar entradas de registro semelhantes ao exemplo a seguir: 
    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. Verifique a conectividade entre o nó com falha atual e o nó de seed.
  3. Identifique o nó de propagação configurado em overrides.yaml para a nova região. O nó de seed é configurado em overrides.yaml no momento da expansão da região no nome do campo: multiRegionSeedHost.

    Exemplo de estrofe do Cassandra do seu overrides.yaml mostrando o multiRegionSeedHost. 

    cassandra:
  multiRegionSeedHost: "1.2.X.X"
  datacenter: "dc-1"
  rack: "rc-1"
  hostNetwork: false
  clusterName: QA
  4. Crie um contêiner de cliente para verificar a conectividade entre o pod do Cassandra com falha e o nó de seed seguindo as instruções em Criar um contêiner de cliente para depuração.
  5. Depois de ssh no contêiner do cliente e ter um shell bash, use o telnet para verificar a conectividade do nó atual ao nó de seed pelas portas 7001 e 7199.

    Exemplo de comando telnet e saída mostrando falha na conexão 

    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

Resolução

  1. Trabalhe com sua equipe de administração de cluster para garantir que haja conectividade de rede entre os nós do Cassandra em todos os clusters que fazem parte da mesma organização.
  2. Verifique se não há regras de firewall bloqueando o tráfego do nó com falha para o nó de seed.

Causa 4: conflito de porta

Conflito de porta

O Cassandra estava tentando ficar disponível para escutar nas portas 7000 e 7001, mas outro serviço, como o ssh, já estava escutando nessa porta.

Diagnóstico

Os registros do pod do Cassandra podem mostrar entradas semelhantes, como no exemplo a seguir: 

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)

Isso sugere que a porta já está em uso.

Resolução

Pare e remova qualquer serviço que não seja o Cassandra e que esteja detectando as portas 7000 e 7001. Isso vai permitir que os aplicativos do Cassandra sejam iniciados.

Causa 5: mesmo endereço IP

Um pod do Cassandra mais antigo com o mesmo IP existe no cluster. Essa situação pode surgir após a desinstalação ou reinstalação do Hybrid.

Diagnóstico

  1. Revise o arquivo system.log do Cassandra para encontrar o seguinte erro: 
    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. Analise a saída do comando nodetool status de qualquer um dos DCs ainda ativos para ver se um nó do Cassandra aparece com o mesmo IP da mensagem de erro: 10.10.1.1.

    Exemplo resposta ao comando de status do nodetool 

    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

Resolução

  1. Remova o nó antigo do Cassandra usando o comando nodetool remove: 
    nodetool removenode HOST_ID

    O ID do host pode ser encontrado na saída do status do nodetool. Por exemplo: 4d96eaf5-7e75-4aeb-bc47-9e45fdb4b533 na saída de status do nodetool de exemplo anterior.

  2. Depois que o nó antigo do Cassandra for removido, tente instalar o Hybrid novamente.

É necessário coletar informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, reúna as seguintes informações de diagnóstico e entre em contato com o Google Cloud Customer Care:

  1. O Google Cloud ID do projeto.
  2. A organização da Apigee híbrida.
  3. Os arquivos overrides.yaml da origem e das novas regiões, mascarando qualquer informação sensível.
  4. As saídas dos comandos em Apigee híbrida must-gather.