Estás viendo la documentación de Apigee y Apigee hybrid.
No hay documentación de Apigee Edge equivalente para este tema.
En este tema, se analizan los pasos que puedes seguir para solucionar problemas con el almacén de datos Cassandra. Cassandra es un almacén de datos persistente que se ejecuta en el componente cassandra
de la arquitectura del entorno de ejecución híbrida.
Consulta también Descripción general de la configuración del servicio del entorno de ejecución.
Los pods de Cassandra están atascados en el estado pendiente
Síntoma
Cuando se inician, los pods de Cassandra permanecen en el estado Pending.
Mensaje de error
Cuando usas kubectl
para ver los estados de los pods, verás que uno o más pods de Cassandra están atascados en el estado Pending
. El estado Pending
indica que Kubernetes no puede programar el pod en un nodo: el pod no se puede crear. Por ejemplo:
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 posibles
Un pod atascado en el estado Pending puede producirse por varias causas. Por ejemplo:
Causa | Descripción |
---|---|
Recursos insuficientes | No hay CPU ni memoria disponibles para crear el pod. |
No se creó el volumen. | El pod está esperando a que se cree el volumen persistente. |
Falta el controlador CSI de Amazon EBS | Para las instalaciones de EKS, el controlador CSI de Amazon EBS que se requiere no está instalado. |
Diagnóstico
Usa kubectl
para describir el pod a fin de determinar el origen del error. Por ejemplo:
kubectl -n NAMESPACE describe pods POD_NAME
Por ejemplo:
kubectl describe pods apigee-cassandra-default-0 -n apigee
Puede que la salida muestre uno de estos problemas posibles:
- Si el problema es que no hay recursos suficiente, verás un mensaje de advertencia que indica que la CPU o la memoria son insuficientes.
- Si el mensaje de error indica que el pod tiene PersistentVolumeClaims (PVC) inmediatos desvinculados, significa que el pod no puede crear su volumen persistente.
Solución
Recursos insuficientes
Modifica el grupo de nodos de Cassandra para que tenga recursos suficientes de CPU y memoria. Consulta Cambia el tamaño de un grupo de nodos para obtener más detalles.
No se creó el volumen persistente.
Si determinas que hay un problema con el volumen persistente, describe el PersistentVolumeClaim (PVC) para determinar por qué no se está creando:
- Obtén una lista de los PVC en el clúster:
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 ...
- Describe el PVC para el pod que falla. Por ejemplo, el siguiente comando describe el PVC vinculado al 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
Ten en cuenta que, en este ejemplo, no existe la StorageClass llamada
apigee-sc
. Para resolver este problema, crea la StorageClass faltante en el clúster, como se explica en Cambia la StorageClass predeterminada.
Consulta también Depura pods.
Falta el controlador CSI de Amazon EBS
Si la instancia híbrida se ejecuta en un clúster de EKS, asegúrate de que el clúster de EKS use el controlador de la interfaz de almacenamiento de contenedores (CSI) de Amazon EBS. Consulta las Preguntas frecuentes sobre la migración de Amazon EBS a la CSI para obtener más detalles.
Los pods de Cassandra están atascados en el estado CrashLoopBackoff
Síntoma
Cuando se inician, los pods de Cassandra permanecen en el estado CrashLoopBackoff.
Mensaje de error
Cuando usas kubectl
para ver los estados de los Pods, verás que uno o más pods de Cassandra tienen el estado CrashLoopBackoff
.
Este estado indica que Kubernetes no puede crear el pod. Por ejemplo:
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 posibles
Un pod atascado en el estado CrashLoopBackoff
puede producirse por varias causas. Por ejemplo:
Causa | Descripción |
---|---|
El centro de datos difiere del centro de datos anterior | Este error indica que el pod de Cassandra tiene un volumen persistente que contiene datos de un clúster anterior, y los pods nuevos no pueden unirse al clúster anterior. Esto suele ocurrir cuando los volúmenes persistentes inactivos persisten desde el clúster anterior de Cassandra en el mismo nodo de Kubernetes. Este problema puede ocurrir si borras y vuelves a crear Cassandra en el clúster. |
Actualización de Kubernetes | Una actualización de Kubernetes puede afectar el clúster de Cassandra. Esto puede suceder cuando los nodos trabajadores de Anthos que alojan los Pods de Cassandra se actualizan a una versión nueva del SO. |
Diagnóstico
Revisa el registro de errores de Cassandra para determinar la causa del problema.
- Enumera los pods para obtener el ID del pod de Cassandra que está fallando:
kubectl get pods -n NAMESPACE
- Verifica el registro del Pod que falla:
kubectl logs POD_ID -n NAMESPACE
Solución
Busca las siguientes pistas en el registro del Pod:
El centro de datos difiere del centro de datos anterior
Si ves este mensaje de registro, haz lo siguiente:
Cannot start node if snitch's data center (us-east1) differs from previous data center
- Verifica si hay algún PVC obsoleto o antiguo en el clúster y bórralo.
- Si se trata de una instalación nueva, borra todos los PVC y vuelve a intentar la configuración. Por ejemplo:
kubectl -n NAMESPACE get pvc
kubectl -n NAMESPACE delete pvc cassandra-data-apigee-cassandra-default-0
La actualización de Anthos cambia la configuración de seguridad
Revisa los registros de Cassandra en busca de este mensaje de error:
/opt/apigee/run.sh: line 68: ulimit: max locked memory: cannot modify limit: Operation not permitted
- Si la instancia híbrida es multirregional, retira la instancia híbrida afectada y vuelve a expandirla a la región afectada.
- Si la instancia de Hybrid es una sola región, realiza un reinicio progresivo en cada Pod de Cassandra en la instancia de Hybrid.
Crea un contenedor del cliente para depurar
En esta sección, se explica cómo crear un contenedor de cliente desde el que puedes acceder a las utilidades de depuración de Cassandra, como cqlsh
. Estas utilidades te permiten consultar tablas de Cassandra y pueden ser útiles para fines de depuración.
Crea el contenedor del cliente
Para crear el contenedor del cliente, sigue estos pasos:
- El contenedor debe usar el certificado TLS del pod
apigee-cassandra-user-setup
. Esto se almacena como un secret de Kubernetes. Recupera el nombre del secret que almacena este certificado:kubectl get secrets -n apigee --field-selector type=kubernetes.io/tls | grep apigee-cassandra-user-setup | awk '{print $1}'
Este comando muestra el nombre del secret. Por ejemplo:
apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls
. La usarás a continuación en el camposecretName
del archivo YAML. - Abre un archivo nuevo y pega en él las siguientes especificaciones del pod:
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
- Guarda el archivo con una extensión
.yaml
. Por ejemplo:my-spec.yaml
. - Aplica las especificaciones a tu clúster:
kubectl apply -f YOUR_SPEC_FILE.yaml -n apigee
- Accede al contenedor:
kubectl exec -n apigee CASSANDRA_CLIENT_NAME -it -- bash
- Conéctate a la interfaz
cqlsh
de Cassandra con el siguiente comando. Ingresa el comando exactamente como se muestra:cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl
Borra el pod del cliente
Usa este comando para borrar el Pod de cliente de Cassandra:
kubectl delete pods -n apigee cassandra-client
Expansión de región mal configurada: todos los nodos de Cassandra en un centro de datos
Esta situación se produce en una expansión multirregional en las plataformas de GKE y GKE On-Prem (Anthos). Evita intentar crear todos los nodos de Cassandra en el mismo centro de datos.
Síntoma
Los nodos de Cassandra no pueden crearse en el centro de datos para la segunda región.
Mensaje de error
failed to rebuild from dc-1: java.lang.RuntimeException : Error while rebuilding node: Stream failed
Solución
Repara la expansión de región mal configurada con los siguientes pasos:
- Actualiza la
replicaCount
de Cassandra a1
en el archivooverrides.yaml
para el segundo centro de datos. Por ejemplo:cassandra: . . . replicaCount: 1
Aplica la configuración con
apigeectl apply
:$APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml
- Usa
kubectl exec
para acceder al Pod de Cassandra restante con el siguiente comando:kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
- Inhabilita el Pod de Cassandra restante con el siguiente comando:
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD decommission
- Borra los Pods de Cassandra del segundo centro de datos mediante
apigeectl delete
con el argumento--datastore
. Por ejemplo:$APIGEECTL_HOME/apigeectl delete -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
- Cambia tu contexto de Kubernetes al clúster de tu primer centro de datos:
kubectl config use-context FIRST_DATACENTER_CLUSTER
- Verifica que no haya nodos de Cassandra en un estado de inactividad en el primer centro de datos.
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status
- Verifica que los nodos de Cassandra mal configurados (que están destinados al segundo centro de datos) se hayan quitado del primer centro de datos. Asegúrate de que las direcciones IP que se muestran en el resultado del estado de nodetool sean solo las direcciones IP para los Pods de Cassandra destinados a tu primer centro de datos. Por ejemplo, en el siguiente resultado, la dirección IP
10.100.0.39
debe ser para un Pod en tu primer centro de datos.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 - Verifica el archivo
overrides.yaml
para el segundo centro de datos contiene la configuración del nombre del centro de datos en la sección Cassandra. Por ejemplo:cassandra: datacenter: DATA_CENTER_2 rack: "RACK_NAME" # "ra-1" is the default value. . . .
- Actualiza la configuración
cassandra:replicaCount
en el archivooverrides.yaml
del segundo centro de datos al número deseado. Por ejemplo:cassandra: datacenter: DATA_CENTER_2 . . . replicaCount: 3
- Aplica el archivo
overrides.yaml
para el segundo centro de datos con el argumento--datastore
. Por ejemplo:$APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
- Usa
kubectl exec
para acceder a uno de los Pods de Cassandra nuevos en el segundo centro de datos y verifica que haya dos centros de datos:"nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status"
Recursos adicionales
Consulta Introducción a las guías de Apigee X y Apigee Hybrid.