Esta
é a documentação da Apigee e da Apigee híbrida.
Não há documentação equivalente do
Apigee Edge para esse tópico.
Neste tópico, você verá etapas para resolver e corrigir problemas com o
armazenamento de dados do Cassandra. O Cassandra é um
armazenamento de dados persistente
executado no componente cassandra
da
arquitetura de ambiente de execução híbrida.
Consulte também
Visão geral da configuração do serviço de ambiente de execução.
Os pods do Cassandra estão presos no estado pendente
Sintoma
Ao serem iniciados, os pods do Cassandra permanecem no estado Pendente.
Mensagem de erro
Ao usar kubectl
para visualizar os estados do pod, você verá que um ou mais
pods do Cassandra estão parados no estado Pending
. O
estado Pending
indica que o Kubernetes não pode agendar o pod
em um nó: o pod não pode ser criado. Exemplo:
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
...
Causas possíveis
Um pod preso no estado pendente pode ter várias causas. Exemplo:
Causa | Descrição |
---|---|
Recursos insuficientes | Não há CPU ou memória suficiente disponível para criar o pod. |
Volume não criado | O pod aguarda a criação do volume permanente para ser criado. |
Driver CSI do Amazon EBS ausente | Para instalações do EKS, o driver CSI necessário do Amazon EBS não está instalado. |
Diagnóstico
Use kubectl
para descrever o pod a fim de determinar a origem do erro. Exemplo:
kubectl -n NAMESPACE describe pods POD_NAME
Exemplo:
kubectl describe pods apigee-cassandra-default-0 -n apigee
A saída pode mostrar um dos seguintes problemas:
- Se o problema for recursos insuficientes, você verá uma mensagem de aviso que indica CPU ou memória insuficientes.
- Se a mensagem de erro indicar que o pod tem PersistentVolumeClaims (PVC) imediatos desvinculados, isso significa que o pod não pode criar o volume permanente dele.
Resolução
Recursos insuficientes
Modifique o pool de nós do Cassandra para que tenha recursos de CPU e memória suficientes. Consulte Como redimensionar um pool de nós para detalhes.
Volume permanente não criado
Se você determinar um problema de volume permanente, descreva o PersistentVolumeClaim (PVC) para determinar por que ele não está sendo criado:
- Liste os PVCs no cluster:
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 ...
- Descreva o PVC para o pod que está falhando. Por exemplo, o comando a seguir
descreve o PVC vinculado ao pod
apigee-cassandra-default-0
: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
Neste exemplo, o StorageClass chamado
apigee-sc
não existe. Para resolver esse problema, crie o StorageClass ausente no cluster, conforme explicado em Alterar o StorageClass padrão.
Consulte também Como depurar pods.
Driver CSI do Amazon EBS ausente
Se a instância híbrida estiver em execução em um cluster do EKS, verifique se o cluster do EKS está usando o driver da interface de armazenamento de contêiner (CSI, na sigla em inglês) do Amazon EBS. Consulte as Perguntas frequentes sobre a migração do CSI do Amazon EBS para saber mais detalhes.
Os pods do Cassandra estão presos no estado CrashLoopBackoff
Sintoma
Durante a inicialização, os pods do Cassandra permanecem no estado CrashLoopBackoff.
Mensagem de erro
Ao usar kubectl
para visualizar os estados do pod, você verá que um ou mais
pods do Cassandra estão no estado CrashLoopBackoff
.
Esse estado indica que o Kubernetes não pode criar o pod. Exemplo:
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
...
Causas possíveis
Um pod parado no estado CrashLoopBackoff
pode ter várias causas. Exemplo:
Causa | Descrição |
---|---|
O data center é diferente do data center anterior. | Esse erro indica que o pod do Cassandra tem um volume permanente que tem dados de um cluster anterior e os novos pods não podem unir o cluster antigo. Isso geralmente acontece quando os volumes permanentes desatualizados persistem do cluster do Cassandra anterior no mesmo nó do Kubernetes. Esse problema pode ocorrer se você excluir e recriar o Cassandra no cluster. |
Upgrade do Kubernetes | Um upgrade do Kubernetes pode afetar o cluster do Cassandra. Isso pode acontecer quando os nós de trabalho do Anthos que hospedam os pods do Cassandra são atualizados para uma nova versão do sistema operacional. |
Diagnóstico
Verifique o registro de erros do Cassandra para determinar a causa do problema.
- Liste os pods para conseguir o ID do pod do Cassandra que está apresentando falhas:
kubectl get pods -n NAMESPACE
- Verifique o registro do pod com falha:
kubectl logs POD_ID -n NAMESPACE
Resolução
Procure as seguintes dicas no registro do pod:
O data center é diferente do data center anterior.
Se você vir esta mensagem de registro:
Cannot start node if snitch's data center (us-east1) differs from previous data center
- Verifique se há PVC desatualizado ou antigo no cluster e exclua-os.
- Se for uma nova instalação, exclua todos os PVCs e tente novamente. Exemplo:
kubectl -n NAMESPACE get pvc
kubectl -n NAMESPACE delete pvc cassandra-data-apigee-cassandra-default-0
O upgrade do Anthos altera as configurações de segurança
Verifique se há esta mensagem de erro nos registros do Cassandra:
/opt/apigee/run.sh: line 68: ulimit: max locked memory: cannot modify limit: Operation not permitted
- Se a instância híbrida for multirregional, desative a instância híbrida afetada e expanda novamente para a região afetada.
- Se a instância híbrida for uma única região, execute uma reinicialização contínua em cada pod do Cassandra na instância híbrida.
Criar um contêiner do cliente para depuração
Nesta seção, explicamos como criar um contêiner do cliente em que é possível acessar
utilitários de depuração do Cassandra,
como cqlsh
. Esses utilitários permitem consultar tabelas do Cassandra e
podem ser úteis para fins de depuração.
Criar o contêiner do cliente
Para criar o contêiner do cliente, siga estas etapas:
- O contêiner precisa usar o certificado TLS do pod
apigee-cassandra-user-setup
. Ele é armazenado como um secret do Kubernetes. Busque o nome do secret que armazena esse certificado:kubectl get secrets -n apigee --field-selector type=kubernetes.io/tls | grep apigee-cassandra-user-setup | awk '{print $1}'
Esse comando retorna o nome do secret. Por exemplo,
apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls
. Ele será usado abaixo no camposecretName
do arquivo YAML. - Abra um novo arquivo e cole a seguinte especificação de pod nele:
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
- Salve o arquivo com uma extensão
.yaml
. Por exemplo,my-spec.yaml
. - Aplique a especificação ao cluster:
kubectl apply -f YOUR_SPEC_FILE.yaml -n apigee
- Faça login no contêiner:
kubectl exec -n apigee CASSANDRA_CLIENT_NAME -it -- bash
- Conecte-se à interface
cqlsh
do Cassandra com o comando a seguir. Digite o comando exatamente como mostrado:cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl
Como excluir o pod cliente
Use este comando para excluir o pod de cliente do Cassandra:
kubectl delete pods -n apigee cassandra-client
Expansão de região configurada incorretamente: todos os nós do Cassandra em um data center
Essa situação ocorre em uma expansão multirregional nas plataformas GKE e GKE On-Prem (Anthos). Evite criar todos os nós do Cassandra no mesmo data center.
Sintoma
Os nós do Cassandra não são criados no data center da segunda região.
Mensagem de erro
failed to rebuild from dc-1: java.lang.RuntimeException : Error while rebuilding node: Stream failed
Resolução
Siga estas etapas para corrigir a expansão de região configurada incorretamente:
- Atualize o
replicaCount
do Cassandra para1
no arquivooverrides.yaml
do segundo data center. Exemplo:cassandra: . . . replicaCount: 1
Aplique a configuração com
apigeectl apply
:$APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml
- Use
kubectl exec
para acessar o pod restante do Cassandra com o seguinte comando:kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
- Desative o pod restante do Cassandra com o seguinte comando:
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD decommission
- Exclua os pods do Cassandra do segundo data center usando
apigeectl delete
com o argumento--datastore
. Exemplo:$APIGEECTL_HOME/apigeectl delete -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
- Altere o contexto do Kubernetes para o cluster do seu primeiro data center:
kubectl config use-context FIRST_DATACENTER_CLUSTER
- Verifique se não há nós do Cassandra com estado inativo no primeiro data center.
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status
- Verifique se os nós do Cassandra configurados incorretamente (destinados ao segundo data center) foram
removidos do primeiro. Verifique se os endereços IP exibidos na saída de status do nodetool são apenas os endereços IP dos pods do Cassandra destinados ao primeiro data center. Por exemplo, na saída a seguir, o endereço IP
10.100.0.39
precisa ser de um pod no primeiro data center.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 - Verifique se o arquivo
overrides.yaml
para que o segundo data center contenha a configuração de nome na seção Cassandra. Exemplo:cassandra: datacenter: DATA_CENTER_2 rack: "RACK_NAME" # "ra-1" is the default value. . . .
- Atualize a configuração
cassandra:replicaCount
no arquivooverrides.yaml
do segundo data center para o número desejado. Exemplo:cassandra: datacenter: DATA_CENTER_2 . . . replicaCount: 3
- Aplique o arquivo
overrides.yaml
ao segundo data center com o argumento--datastore
. Exemplo:$APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
- Use
kubectl exec
para acessar um dos novos pods do Cassandra no segundo data center e verifique se há dois data centers:"nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status"
Outros recursos
Consulte Introdução aos manuais da Apigee X e da Apigee híbrida