Guide de dépannage Cassandra

Cette rubrique décrit les étapes à suivre pour résoudre les problèmes liés au datastore Cassandra. Cassandra est un magasin de données persistant qui s'exécute dans le composant cassandra de l 'architecture d'exécution hybride. Consultez également la Présentation de la configuration des services d'exécution.

Les pods Cassandra sont bloqués dans l'état "En attente"

Symptôme

Au démarrage, les pods Cassandra restent à l'état En attente.

Message d'erreur

Lorsque vous utilisez kubectl pour afficher les états des pods, vous constatez qu'un ou plusieurs pods Cassandra sont bloqués dans l'état Pending. L'état Pending indique que Kubernetes ne peut pas planifier le pod sur un nœud : le pod ne peut pas être créé. Exemple :

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
...

Causes possibles

Un pod bloqué dans l'état "Pending" (En attente) peut avoir plusieurs causes. Exemple :

Cause Description
Ressources insuffisantes Le processeur ou la mémoire sont insuffisants pour créer le pod.
Volume non créé Le pod attend que le volume persistant soit créé.
Pilote CSI Amazon EBS manquant Le pilote CSI Amazon EBS requis n'est pas installé.

Diagnostic

Utilisez kubectl pour décrire le pod afin de déterminer la source de l'erreur. Exemple :

kubectl -n namespace describe pods pod_name

Exemple :

kubectl describe pods apigee-cassandra-default-0 -n apigee

Le résultat peut présenter l'un des problèmes suivants :

  • Si le problème est dû à des ressources insuffisantes, un message d'avertissement indique un processeur ou une mémoire insuffisants.
  • Si le message d'erreur indique que le pod a une requête PersistentVolumeClaim (PVC) immédiate non liée, cela signifie qu'il ne peut pas créer son volume persistant.

Solution

Ressources insuffisantes

Modifiez le pool de nœuds Cassandra afin qu'il dispose de suffisamment de ressources processeur et de mémoire. Pour en savoir plus, consultez la section Redimensionner un pool de nœuds.

Volume persistant non créé

Si vous déterminez un problème de volume persistant, décrivez la PersistentVolumeClaim (PVC) pour déterminer la raison de son absence de création :

  1. Répertoriez les PVC du 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
    ...
  2. Décrivez la PVC du pod qui échoue. Par exemple, la commande suivante décrit la PVC liée au pod apigee-cassandra-default-0:
    kubectl -n 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

    Notez que dans cet exemple, la ressource StorageClass nommée apigee-sc n'existe pas. Pour résoudre ce problème, créez la ressource StorageClass manquante dans le cluster, comme expliqué dans la section Modifier la ressource StorageClass par défaut.

Consultez également la section Déboguer des pods.

Pilote CSI Amazon EBS manquant

Si l'instance hybride s'exécute sur un cluster EKS, assurez-vous que le cluster EKS utilise le pilote CSI (Container Storage Interface) Amazon EBS. Pour en savoir plus, consultez les questions fréquentes sur la migration CSI Amazon EBS.

Les pods Cassandra sont bloqués dans l'état CrashLoopBackoff

Symptôme

Lors du démarrage, les pods Cassandra restent à l'état CrashLoopBackoff.

Message d'erreur

Lorsque vous utilisez kubectl pour afficher l'état des pods, vous constatez qu'un ou plusieurs pods Cassandra sont à l'état CrashLoopBackoff. Cet état indique que Kubernetes n'est pas en mesure de créer le pod. Exemple :

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
...

Causes possibles

Un pod bloqué dans l'état CrashLoopBackoff peut avoir plusieurs causes. Exemple :

Cause Description
Le centre de données est différent du centre de données précédent Cette erreur indique que le pod Cassandra possède un volume persistant contenant les données d'un cluster précédent et que les nouveaux pods ne peuvent pas rejoindre l'ancien cluster. Cela se produit généralement lorsque des volumes persistants obsolètes persistent du cluster Cassandra précédent sur le même nœud Kubernetes. Ce problème peut se produire si vous supprimez et recréez l'environnement Cassandra dans le cluster.
Répertoire du truststore introuvable Cette erreur indique que le pod Cassandra n'est pas en mesure de créer une connexion TLS. Cela se produit généralement lorsque les clés et les certificats fournis sont incorrects, manquants ou présentent d'autres problèmes.

Diagnostic

Consultez le journal d'erreurs Cassandra pour déterminer la cause du problème.

  1. Répertoriez les pods pour obtenir l'ID du pod Cassandra qui échoue :
    kubectl get pods -n namespace
  2. Vérifiez le journal du pod défaillant :
    kubectl logs pod_id -n namespace

Solution

Recherchez les indices suivants dans le journal du pod :

Le centre de données est différent du centre de données précédent

Si vous voyez ce message de journal :

Cannot start node if snitch's data center (us-east1) differs from previous data center
  • Vérifiez s'il existe des anciennes versions du PVC dans le cluster et supprimez-les.
  • S'il s'agit d'une nouvelle installation, supprimez toutes les PVC et relancez la configuration. Exemple :
    kubectl -n namespace get pvc
    kubectl -n namespace delete pvc cassandra-data-apigee-cassandra-default-0

Répertoire du truststore introuvable

Si vous voyez ce message de journal :

Caused by: java.io.FileNotFoundException: /apigee/cassandra/ssl/truststore.p12
(No such file or directory)

Vérifiez que la clé et les certificats fournis dans votre fichier de remplacement sont corrects et valides. Exemple :

cassandra:
  sslRootCAPath: path_to_root_ca-file
  sslCertPath: path-to-tls-cert-file
  sslKeyPath: path-to-tls-key-file

Créer un conteneur client pour le débogage

Cette section explique comment créer un conteneur client à partir duquel vous pouvez accéder aux utilitaires de débogage Cassandra tels que cqlsh. Ces utilitaires vous permettent d'interroger les tables Cassandra et peuvent être utiles à des fins de débogage.

Créer le conteneur client

Pour créer le conteneur client, procédez comme suit :

  1. Le conteneur utilise le certificat TLS du pod apigee-cassandra-user-setup. La première étape consiste à extraire ce nom de certificat :
    kubectl get secrets -n apigee --field-selector type=kubernetes.io/tls | grep apigee-cassandra-user-setup | awk '{print $1}'

    Cette commande renvoie le nom du certificat. Exemple : apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls.

  2. Ouvrez un nouveau fichier et collez-y la spécification de pod suivante :
    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:1.8.8"
        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
  3. Enregistrez le fichier avec l'extension .yaml. Exemple : my-spec.yaml.
  4. Appliquez les spécifications à votre cluster comme suit :
    kubectl apply -f your-spec-file.yaml -n apigee
  5. Connectez-vous au conteneur :
    kubectl exec -n apigee cassandra-client -it -- bash
  6. Connectez-vous à l'interface Cassandra cqlsh à l'aide de la commande suivante. Saisissez la commande exactement comme indiqué ci-dessous :
    cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl

Supprimer le pod client

Utilisez la commande suivante pour supprimer le pod client Cassandra :

kubectl delete pods -n apigee cassandra-client

Autres ressources

Consultez la page Présentation des playbooks Apigee et Apigee hybrid