Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Il n'existe pas de documentation Apigee Edge équivalente pour ce sujet.
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 "Publication"
Symptôme
Après avoir tenté d'effectuer une mise à jour des pods Cassandra, le datastore signale qu'il est bloqué à l'état de publication.
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 de publication :
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Ack 57s (x7 over 24h) apigee-datastore release started
Causes possibles
Un pod bloqué dans l'état de publication peut avoir plusieurs causes :
| Cause | Description |
|---|---|
| Modifications de la capacité de stockage |
Les étapes ont été exécutées pour modifier la capacité de stockage dans le fichier override.yaml.
|
| Autres modifications de configuration |
Des mises à jour ont été apportées aux propriétés Cassandra dans le fichier override.yaml. Cependant, les modifications n'ont pas pris effet.
|
Modifications de la capacité de stockage
Diagnostic
-
Utilisez
kubectlpour afficher l'état actuel du pod du datastoreapigee:kubectl get apigeeds -n apigee
NAME STATE AGE default releasing 122d
-
Vérifiez si des modifications ont été apportées au fichier
override.yaml: -
À l'aide de votre système de contrôle des versions, comparez la version précédente du fichier
override.yamlà la version actuelle :diff OVERRIDES_BEFORE.yaml OVERRIDES_AFTER.yaml
-
Le résultat d'une différence dans le fichier
override.yamlpeut indiquer le problème possible avec la taille de la capacité de stockage. Par exemple :# Overrides.yaml before: cassandra: storage: capacity: 500Gi # Overrides.yaml after: cassandra: storage: capacity: 100GiSi une opération a été effectuée pour modifier la capacité de stockage où des étapes ont été ignorées et qu'une nouvelle ressource
override.yamla été appliquée directement, cela peut entraîner l'état de publication du datastore. -
Vérifiez la ressource
statefulsetpour vous assurer qu'elle existe pourapigee-cassandra-default:kubectl describe sts -n apigee
Le résultat ressemble à ceci :
Name: apigee-cassandra-default Namespace: apigee CreationTimestamp: Tue, 18 Jul 2023 00:40:57 +0000 Selector: app=apigee-cassandra,name=default Labels: apigee.cloud.google.com.revision=v1-2cc098050836c6b4 apigee.cloud.google.com.version=v1 apigee.cloud.google.com/platform=apigee app=apigee-cassandra name=default Annotations: <none> Replicas: 3 desired | 3 total Update Strategy: RollingUpdate Partition: 0 Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed Pod Template: Labels: apigee.cloud.google.com/apigee_servicename=production apigee.cloud.google.com/billing_type=subscription apigee.cloud.google.com/platform=apigee app=apigee-cassandra name=default revision=v1 runtime_type=hybrid Annotations: apigee.cloud.google.com/pod-template-spec-hash: 2cc098050836c6b4 prometheus.io/path: /metrics prometheus.io/port: 7070 prometheus.io/scheme: https prometheus.io/scrape: true Containers: apigee-cassandra: Image: gcr.io/apigee-release/hybrid/apigee-hybrid-cassandra:1.10.1 Ports: 7000/TCP, 7001/TCP, 7199/TCP, 9042/TCP, 8778/TCP Host Ports: 7000/TCP, 7001/TCP, 7199/TCP, 9042/TCP, 8778/TCP Requests: cpu: 500m memory: 1Gi Readiness: exec [/bin/bash -c /opt/apigee/ready-probe.sh] delay=0s timeout=5s period=10s #success=1 #failure=2 Environment: POD_NAME: (v1:metadata.name) POD_IP: (v1:status.podIP) MAX_HEAP_SIZE: 512M HEAP_NEWSIZE: 100M CASSANDRA_SEEDS: apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local CASSANDRA_CLUSTER_NAME: apigeecluster CASSANDRA_DC: dc-1 CASSANDRA_RACK: ra-1 CASSANDRA_OPEN_JMX: true CPS_ADMIN_USER: <set to the key 'admin.user' in secret 'apigee-datastore-default-creds'> Optional: false CPS_ADMIN_PASSWORD: <set to the key 'admin.password' in secret 'apigee-datastore-default-creds'> Optional: false APIGEE_JMX_USER: <set to the key 'jmx.user' in secret 'apigee-datastore-default-creds'> Optional: false APIGEE_JMX_PASSWORD: <set to the key 'jmx.password' in secret 'apigee-datastore-default-creds'> Optional: false CASS_PASSWORD: <set to the key 'default.password' in secret 'apigee-datastore-default-creds'> Optional: false APIGEE_JOLOKIA_USER: <set to the key 'jolokia.user' in secret 'apigee-datastore-default-creds'> Optional: false APIGEE_JOLOKIA_PASSWORD: <set to the key 'jolokia.password' in secret 'apigee-datastore-default-creds'> Optional: false Mounts: /opt/apigee/apigee-cassandra/conf from appsfs (rw) /opt/apigee/customer from cwc-volume (ro) /opt/apigee/data from cassandra-data (rw) /opt/apigee/ssl from tls-volume (ro) /var/secrets/google from apigee-cassandra-backup (rw) /var/secrets/keys from apigee-cassandra-backup-key-file (rw) Volumes: cwc-volume: Type: Secret (a volume populated by a Secret) SecretName: config-cassandra-default Optional: false tls-volume: Type: Secret (a volume populated by a Secret) SecretName: apigee-cassandra-default-tls Optional: false appsfs: Type: EmptyDir (a temporary directory that shares a pod's lifetime) Medium: SizeLimit: <unset> apigee-cassandra-backup: Type: Secret (a volume populated by a Secret) SecretName: apigee-cassandra-backup-svc-account Optional: true apigee-cassandra-backup-key-file: Type: Secret (a volume populated by a Secret) SecretName: apigee-cassandra-backup-key-file Optional: true Volume Claims: Name: cassandra-data StorageClass: Labels: <none> Annotations: <none> Capacity: 10Gi Access Modes: [ReadWriteOnce] Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 47m statefulset-controller create Pod apigee-cassandra-default-2 in StatefulSet apigee-cassandra-default successful
-
Recherchez les erreurs dans le contrôleur apigee :
kubectl logs -f apigee-controller-manager-59cf595c77-wtwnr -n apigee-system -c manager | grep apigeedatastore
Résultats :
"error creating apigee-cassandra object: failed to update resource apigee/apigee-cassandra-default: StatefulSet.apps \"apigee-cassandra-default\" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', 'updateStrategy', 'persistentVolumeClaimRetentionPolicy' and 'minReadySeconds' are forbiddenerror creating apigee-cassandra object: failed to update resource apigee/apigee-cassandra-default: StatefulSet.apps \"apigee-cassandra-default\" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', 'updateStrategy', 'persistentVolumeClaimRetentionPolicy' and 'minReadySeconds' are forbidden"
Solution
Pour rétablir l'état d'exécution de Cassandra, procédez comme suit :
-
Désactivez
apigee-controller:kubectl -n apigee-system edit deployments and set --enable-controllers=true to --enable-controllers=false
-
Remettez le datastore en état d'exécution à l'aide de la commande
PATCH:curl -XPATCH \-H "Accept: application/json" -H "Content-Type: application/json-patch+json" --data '[{"op": "replace", "path": "/status/nestedState", "value": ""},{"op": "replace", "path": "/status/state", "value": "running"}]' 'http://127.0.0.1:8001/apis/apigee.cloud.google.com/v1alpha1/namespaces/apigee/apigeedatastores/default/status' -
Appliquez à nouveau le fichier
override.yamld'origine :./apigeectl apply --datastore -f overrides.yaml
- Activez
apigee-controller:kubectl -n apigee-system edit deployments and set --enable-controllers=false to --enable-controllers=true
-
Attendez que le datastore soit de nouveau opérationnel, puis vérifiez les points suivants :
kubectl get apigeeds --namespace apigee
-
Vérifiez que les déploiements et les pods Apigee sont en cours d'exécution et que
apigeedsn'est plus à l'état de publication :kubectl get ad -n apigee
kubectl get pods -n apigee
kubectl get apigeeds -n apigee
NAME STATE AGE default running 24d
Autres modifications de configuration
Les modifications apportées aux propriétés cassandra dans override.yaml n'ont pas pris effet. Il peut s'agir d'une modification du mot de passe ou d'une modification des ressources dans le fichier override.yaml.
Ou le mauvais fichier override.yaml a été appliqué par erreur à un cluster.
Diagnostic
Consultez la procédure décrite dans Diagnostic.
Solution
Consultez la section Résolution.
Vous devez collecter des informations de diagnostic
Si le problème persiste, même après avoir suivi les instructions ci-dessus, rassemblez les informations de diagnostic suivantes, puis contactez Google Cloud Customer Care :
-
Fichier
Overrides.yamlpour chaque cluster de l'installation. -
Un vidage cluster-info Kubernetes provenant de l'installation hybride :
Générez
cluster-info dumpKubernetes :kubectl cluster-info dump -A --output-directory=/tmp/kubectl-cluster-info-dump
Compressez avec zip
cluster-info dumpKubernetes :zip -r kubectl-cluster-info-dump`date +%Y.%m.%d_%H.%M.%S`.zip /tmp/kubectl-cluster-info-dump/*
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 | Pour les installations EKS, 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 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. |
| Mise à niveau de Kubernetes | Une mise à niveau de Kubernetes peut affecter le cluster Cassandra. Cela peut se produire si les nœuds de calcul Anthos hébergeant les pods Cassandra sont mis à niveau vers une nouvelle version d'OS. |
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. Par exemple :
kubectl -n NAMESPACE get pvckubectl -n NAMESPACE delete pvc cassandra-data-apigee-cassandra-default-0
La mise à niveau d'Anthos modifie les paramètres de sécurité
Vérifiez si le message d'erreur suivant figure dans les journaux Cassandra :
/opt/apigee/run.sh: line 68: ulimit: max locked memory: cannot modify limit: Operation not permitted
- Si l'instance Hybrid est multirégionale, mettez hors service l'instance Hybrid concernée et redéveloppez l'installation dans la région concernée.
- Si l'instance Hybrid est associée à une région unique, effectuez un redémarrage progressif sur chaque pod Cassandra de l'instance Hybrid.
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 doit utiliser le certificat TLS du pod
apigee-cassandra-user-setup. Cet identifiant est stocké en tant que secret Kubernetes. Récupérez le nom du secret qui stocke ce 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 secret. Exemple :
apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls. Vous l'utiliserez ci-dessous dans le champsecretNamedu fichier YAML. - 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:YOUR_APIGEE_HYBRID_VERSION" # For example, 1.10.5. 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_NAME -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
Mauvaise configuration de l'extension de région : tous les nœuds Cassandra dans un centre de données
Cette situation se produit dans une expansion multirégionale sur les plates-formes GKE et GKE On-Prem (Anthos). Évitez d'essayer de créer tous vos nœuds Cassandra dans le même centre de données.
Symptôme
Les nœuds Cassandra ne sont pas créés dans le centre de données de la deuxième région.
Message d'erreur
failed to rebuild from dc-1: java.lang.RuntimeException : Error while rebuilding node: Stream failed
Solution
Réparez l'expansion de la région mal configurée en procédant comme suit :
- Mettez à jour la base de données Cassandra de
replicaCountvers1dans le fichieroverrides.yamldu deuxième centre de données. Par exemple :cassandra: . . . replicaCount: 1
Appliquez le paramètre à l'aide de
apigeectl apply:$APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml
- Utilisez
kubectl execpour accéder au pod Cassandra restant à l'aide de la commande suivante :kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
- Mettez hors service le pod Cassandra restant à l'aide de la commande suivante :
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD decommission
- Supprimez les pods Cassandra du deuxième centre de données en utilisant
apigeectl deleteavec l'argument--datastore. Par exemple :$APIGEECTL_HOME/apigeectl delete -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
- Remplacez le contexte Kubernetes par le cluster de votre premier centre de données :
kubectl config use-context FIRST_DATACENTER_CLUSTER
- Vérifiez qu'aucun nœud Cassandra n'est indisponible dans le premier centre de données.
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status
- Vérifiez que les nœuds Cassandra mal configurés (destinés au deuxième centre de données) ont été supprimés du premier centre de données. Assurez-vous que les adresses IP affichées dans le résultat de l'état de nodetool ne sont que les adresses IP des pods Cassandra destinés à votre premier centre de données. Par exemple, dans le résultat suivant, l'adresse IP
10.100.0.39doit correspondre à un pod de votre premier centre de données.kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bashnodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD statusDatacenter: 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 - Vérifiez que le fichier
overrides.yamldu deuxième centre de données contient le paramètre de nom du centre de données dans la section Cassandra. Par exemple :cassandra: datacenter: DATA_CENTER_2 rack: "RACK_NAME" # "ra-1" is the default value. . . .
- Remplacez le paramètre
cassandra:replicaCountdans le fichieroverrides.yamldu deuxième centre de données par le nombre souhaité. Par exemple :cassandra: datacenter: DATA_CENTER_2 . . . replicaCount: 3
- Appliquez le fichier
overrides.yamlpour le deuxième centre de données avec l'argument--datastore. Par exemple :$APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
- Utilisez
kubectl execpour accéder à l'un des nouveaux pods Cassandra du deuxième centre de données et vérifiez qu'il existe deux centres de données :"nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status"
Autres ressources
Consultez la page Présentation des playbooks Apigee X et Apigee hybrides