Estás viendo la documentación de Apigee y Apigee Hybrid.
No hay documentación de
Apigee Edge equivalente para este tema.
En este documento, se describe cómo restablecer los componentes híbridos de Apigee cuando se atascan en un estado creating
o releasing
.
Ejecuta el siguiente comando para mostrar los componentes principales de la instalación Apigee Hybrid:
kubectl get crd | grep apigee
apigeeorganization (apigeeorganizations.apigee.cloud.google.com) apigeeenvironment (apigeeenvironments.apigee.cloud.google.com) apigeedatastore (apigeedatastores.apigee.cloud.google.com) apigeetelemetries (apigeetelemetries.apigee.cloud.google.com) apigeeredis (apigeeredis.apigee.cloud.google.com)
Ejecuta el siguiente comando para mostrar el estado actual:
kubectl get apigeedatastore -n NAMESPACE
Cuando sea completamente funcional, cada uno de estos componentes estará en estado running
.
Por ejemplo:
NAME STATE AGE default running 5d6h
Si la instalación no se realiza de forma correcta, los componentes pueden quedarse en un estado creating
(o releasing
). Por ejemplo:
NAME STATE AGE default creating 5d6h
Identifica el problema
Para identificar la causa del problema, comienza por describir cada componente. Los componentes están estructurados de la siguiente manera:
La siguiente jerarquía representa cada recurso personalizado ApigeeOrganization
:
ApigeeOrganization/HASHED_VALUE ├─ApigeeDeployment/apigee-connect-agent-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-connect-agent-HASHED_VALUE-VER-xxxx │ ├─PodDisruptionBudget/apigee-connect-agent-HASHED_VALUE│ ├─ReplicaSet/apigee-connect-agent-HASHED_VALUE-VER-xxxx │ │ └─Pod/apigee-connect-agent-HASHED_VALUE-VER-xxxx ├─ApigeeDeployment/apigee-mart-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-mart-HASHED_VALUE-VER-xxxx │ ├─PodDisruptionBudget/apigee-mart-HASHED_VALUE│ ├─ReplicaSet/apigee-mart-HASHED_VALUE-VER-xxxx │ │ └─Pod/apigee-mart-HASHED_VALUE-VER-xxxx ├─ApigeeDeployment/apigee-watcher-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-watcher-HASHED_VALUE-VER-xxxx │ ├─PodDisruptionBudget/apigee-watcher-HASHED_VALUE│ ├─ReplicaSet/apigee-watcher-HASHED_VALUE-VER-xxxx │ │ └─Pod/apigee-watcher-HASHED_VALUE-VER-xxxx
La siguiente jerarquía representa cada recurso personalizado ApigeeEnvironment
:
ApigeeEnvironment/HASHED_VALUE ├─ApigeeDeployment/apigee-runtime-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-runtime-HASHED_VALUE-VER-xxxx │ ├─PodDisruptionBudget/apigee-runtime-HASHED_VALUE│ ├─ReplicaSet/apigee-runtime-HASHED_VALUE-VER-xxxx │ │ └─Pod/apigee-runtime-HASHED_VALUE-VER-xxxx ├─ApigeeDeployment/apigee-synchronizer-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-synchronizer-HASHED_VALUE-VER-xxxx │ ├─PodDisruptionBudget/apigee-synchronizer-HASHED_VALUE│ ├─ReplicaSet/apigee-synchronizer-HASHED_VALUE-VER-xxxx │ │ └─Pod/apigee-synchronizer-HASHED_VALUE-VER-xxxx ├─ApigeeDeployment/apigee-udca-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-udca-HASHED_VALUE-VER-xxxx │ ├─PodDisruptionBudget/apigee-udca-HASHED_VALUE│ ├─ReplicaSet/apigee-udca-HASHED_VALUE-VER-xxxx │ │ └─Pod/apigee-udca-HASHED_VALUE-VER-xxxx
Comienza la identificación del problema mediante la descripción del componente raíz. Por ejemplo:
kubectl describe apigeeorganization -n NAMESPACE COMPONENT_NAME
Comprueba si el State
del componente es running
:
Replicas:
Available: 1
Ready: 1
Total: 1
Updated: 1
State: running
State: running
Events: <none>
Si no hay eventos registrados en este nivel, repite el proceso con apigeedeployments
seguido de ReplicaSet
. Por ejemplo:
kubectl get apigeedeployment -n NAMESPACE AD_NAME>
Si apigeedeployments
y ReplicaSet
no muestran ningún error, enfócate en los Pods que no están listos:
kubectl get pods -n NAMESPACE
NAME READY STATUS apigee-cassandra-default-0 1/1 Running apigee-connect-agent-apigee-b56a362-150rc2-42gax-dbrrn 1/1 Running apigee-logger-apigee-telemetry-s48kb 1/1 Running apigee-mart-apigee-b56a362-150rc2-bcizm-7jv6w0
/2 Running apigee-runtime-apigee-test-0d59273-150rc2-a5mov-dfb290
/1 Running
En este ejemplo, mart
y runtime
no están listos. Inspecciona los registros del Pod para determinar los errores:
kubectl logs -n NAMESPACE POD_NAME
Borra componentes
Si cometiste un error con cualquiera de estos componentes, simplemente borra el componente y aplica apigeectl
a ese componente. Por ejemplo, para borrar un entorno, haz lo siguiente:
kubectl delete -n apigee apigeeenv HASHED_ENV_NAME
Para continuar con la creación del entorno (después de realizar las correcciones necesarias), sigue estos pasos:
apigeectl apply -f overrides.yaml –env=$ENV
Inspecciona el controlador
Si no hay mensajes de error evidentes en el Pod, pero el componente no pasó al estado running
, inspecciona el apigee-controller
de los mensajes de error. El apigee-controller
se ejecuta en el espacio de nombres apigee-system
.
kubectl logs -n apigee-system $(k get pods -n apigee-system | sed -n '2p' | awk '{print $1}') | grep -i error
Esto permite al usuario ver por qué el controlador no pudo procesar la solicitud (de create
/delete
/update
, etcétera).
Almacén de datos de Apigee
Apache Cassandra se implementa como un StatefulSet
. Cada instancia de Cassandra contiene lo siguiente:
ApigeeDatastore/default
├─Certificate/apigee-cassandra-default │ └─CertificateRequest/apigee-cassandra-default-wnd7s ├─Secret/config-cassandra-default ├─Service/apigee-cassandra-default │ ├─EndpointSlice/apigee-cassandra-default-7m9kx │ └─EndpointSlice/apigee-cassandra-default-gzqpr└─StatefulSet/apigee-cassandra-default
├─ControllerRevision/apigee-cassandra-default-6976b77bd ├─ControllerRevision/apigee-cassandra-default-7fc76588cb└─Pod/apigee-cassandra-default-0
En este ejemplo, se muestra un Pod; sin embargo, las instalaciones de producción típicas contienen tres o más Pods.
Si el estado de Cassandra es creating
o releasing
, el estado DEBE restablecerse. Ciertos problemas (como los cambios de contraseña de Cassandra) y los problemas no relacionados con las redes pueden requerir que borres componentes. Es posible que, en esos casos, no puedas borrar la instancia (es decir, kubectl delete apigeedatastore -n NAMESPACE default
). El uso de --force
o --grace-period=0
tampoco ayuda.
El objetivo de reset
es cambiar el estado del componente (apigeedatastore
) de creating
o releasing
a running
. Por lo general, cambiar el estado de esta manera no resolverá el problema subyacente. En la mayoría de los casos, el componente debe borrarse después de un restablecimiento.
Intenta borrar (esto no se realizará correctamente):
kubectl delete -n NAMESPACE apigeedatastore default
Es común que este comando no se complete. Use Ctrl+C y finalice la llamada.
Restablece el estado:
En la ventana 1:
kubectl proxy
En la ventana 2:
curl -X PATCH -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'
Quita el finalizador (ventana 2):
kubectl edit -n NAMESPACE apigeedatastore default
Busca las siguientes dos líneas y bórralas:
finalizers: - apigeedatastore.apigee.cloud.google.com
Situaciones de errores comunes
La configuración del proxy no está disponible con el entorno de ejecución
Este error se puede manifestar de dos maneras:
- El
runtime
no está en el estadoready
. - El
runtime
no recibió la versión más reciente de la API.
Comienza con los pods de
synchronizer
.Inspecciona los registros en busca del
synchronizer
. Los errores comunes son los siguientes:- Falta de conectividad de red (a
*.googleapi.com
) - Acceso incorrecto a IAM (la cuenta de servicio no está disponible o no se proporcionó a través del permiso de Synchronizer Manager)
- No se invocó la API de setSyncAuthorization
- Falta de conectividad de red (a
Inspecciona los Pods
runtime
.Cuando inspecciones los registros de los Pods
runtime
, se mostrará por qué elruntime
no cargó la configuración. El plano de control intenta evitar que la mayoría de los errores de configuración vayan al plano de datos. En los casos en los que una validación es imposible o no se implementa de forma correcta, elruntime
no podrá cargarla.
“No hay pods de entorno de ejecución” en el plano de control
Comienza con los pods de
synchronizer
.Inspecciona los registros en busca del
synchronizer
. Los errores comunes son los siguientes:- Falta de conectividad de red (a
*.googleapi.com
) - Acceso incorrecto a IAM (la cuenta de servicio no está disponible o no se proporcionó a través del permiso de Synchronizer Manager)
- No se invocó la API de setSyncAuthorization. Quizás la configuración nunca llegó al plano de datos.
- Falta de conectividad de red (a
Inspecciona los Pods
runtime
.Cuando inspecciones los registros de los Pods
runtime
, se mostrará por quéruntime
no cargó la configuración.Inspecciona los Pods
watcher
.Es el componente
watcher
que configura la entrada (enrutamiento) y, luego, informa el estado de la implementación del proxy y entrada al plano de control. Inspecciona estos registros para averiguar por qué elwatcher
no informa el estado. Los motivos comunes incluyen una discrepancia entre los nombres en el archivooverrides.yaml
y el plano de control para el nombre del entorno o del grupo de entornos.
La sesión de depuración no aparece en el plano de control
Comienza con los pods de
synchronizer
.Inspecciona los registros en busca del
synchronizer
. Los errores comunes son los siguientes:- Falta de conectividad de red (a
*.googleapi.com
) - Acceso incorrecto a IAM (la cuenta de servicio no está disponible o no se proporcionó a través del permiso de Synchronizer Manager)
- No se invocó la API de setSyncAuthorization.
- Falta de conectividad de red (a
- Inspecciona los Pods
runtime
.
Si inspeccionas los registros de los Pods delruntime
, se mostrará por qué elruntime
no envía registros de depuración a UDCA. - Inspeccionar los Pods de UDCA
Si inspeccionas los registros del UDCA, se mostrará el motivo por el que este no envía información de sesiones de depuración al plano de control.
Cassandra muestra respuestas de caché grandes
En el siguiente mensaje de advertencia, se indica que Cassandra recibe solicitudes de lectura o escritura con una carga útil más grande y puede ignorarse de forma segura, ya que este límite de advertencia se establece en un valor más bajo para indicar los tamaños de la carga útil de respuesta.
Batch for [cache_ahg_gap_prod_hybrid.cache_map_keys_descriptor, cache_ahg_gap_prod_hybrid.cache_map_entry] is of size 79.465KiB, exceeding specified threshold of 50.000KiB by 29.465KiB