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 :
- 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 ...
- 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-scn'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.
- Répertoriez les pods pour obtenir l'ID du pod Cassandra qui échoue :
kubectl get pods -n namespace
- 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 pvckubectl -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 :
- 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. - 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
- Enregistrez le fichier avec l'extension
.yaml. Exemple :my-spec.yaml. - Appliquez les spécifications à votre cluster comme suit :
kubectl apply -f your-spec-file.yaml -n apigee
- Connectez-vous au conteneur :
kubectl exec -n apigee cassandra-client -it -- bash
- 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