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éé. |
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 -n apigee describe pods apigee-cassandra-default-0
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 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.
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
Défaillance de nœud
Symptôme
Au démarrage, les pods Cassandra restent à l'état "En attente". Ce problème peut indiquer une défaillance de nœud sous-jacente.
Diagnostic
- Déterminez quels pods Cassandra ne sont pas en cours d'exécution :
$ kubectl get pods -n your_namespace NAME READY STATUS RESTARTS AGE cassandra-default-0 0/1 Pending 0 13s cassandra-default-1 1/1 Running 0 8d cassandra-default-2 1/1 Running 0 8d
- Vérifiez les nœuds de calcul. Si l'un est à l'état NotReady (non prêt), cela signifie que le nœud a échoué :
kubectl get nodes -n your_namespace NAME STATUS ROLES AGE VERSION ip-10-30-1-190.ec2.internal Ready <none> 8d v1.13.2 ip-10-30-1-22.ec2.internal Ready master 8d v1.13.2 ip-10-30-1-36.ec2.internal NotReady <none> 8d v1.13.2 ip-10-30-2-214.ec2.internal Ready <none> 8d v1.13.2 ip-10-30-2-252.ec2.internal Ready <none> 8d v1.13.2 ip-10-30-2-47.ec2.internal Ready <none> 8d v1.13.2 ip-10-30-3-11.ec2.internal Ready <none> 8d v1.13.2 ip-10-30-3-152.ec2.internal Ready <none> 8d v1.13.2 ip-10-30-3-5.ec2.internal Ready <none> 8d v1.13.2
Solution
- Supprimez le pod Cassandra inactif du cluster.
$ kubectl exec -it apigee-cassandra-default-0 -- nodetool status
$ kubectl exec -it apigee-cassandra-default-0 -- nodetool removenode deadnode_hostID - Retirez la VolumClaim du nœud inactif pour éviter que le pod Cassandra n'essaie d'aller sur ce nœud en raison de l'affinité :
kubectl get pvc -n your_namespace
kubectl delete pvc volumeClaim_name -n your_namespace - Mettez à jour le modèle de volume et créez un volume persistant pour le nœud nouvellement ajouté. Voici un exemple de modèle de volume :
apiVersion: v1 kind: PersistentVolume metadata: name: cassandra-data-3 spec: capacity: storage: 100Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: local-storage local: path: /apigee/data nodeAffinity: "required": "nodeSelectorTerms": - "matchExpressions": - "key": "kubernetes.io/hostname" "operator": "In" "values": ["ip-10-30-1-36.ec2.internal"]
- Remplacez les valeurs par le nouveau nom d'hôte/adresse IP et appliquez le modèle :
kubectl apply -f volume-template.yaml