Solucionar problemas de Apigee hybrid que se queda en estado de creación o lanzamiento

Estás consultando la documentación de Apigee y Apigee Hybrid.
No hay documentación equivalente de Apigee Edge sobre este tema.

En este documento se describe cómo restablecer los componentes de Apigee hybrid cuando se quedan bloqueados en el estado creating o releasing.

Ejecuta el siguiente comando para enumerar los componentes principales de la instalación de 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 ver el estado actual:

kubectl get apigeedatastore -n NAMESPACE

Cuando funcionen correctamente, cada uno de estos componentes estará en estado running. Por ejemplo: 

NAME      STATE     AGE
default   running   5d6h

Si la instalación no se realiza correctamente, es posible que los componentes se queden en el estado creating (o releasing). Por ejemplo: 

NAME      STATE     AGE
default   creating   5d6h

Identificar el problema

Para identificar la causa del problema, empieza por describir cada componente. Los componentes se estructuran de la siguiente manera:

Cada recurso personalizado ApigeeOrganization se representa mediante la siguiente jerarquía: 

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

Cada recurso personalizado ApigeeEnvironment se representa mediante la siguiente jerarquía: 

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

Empieza a identificar el problema describiendo el 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 se registra ningún evento en este nivel, repita 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, céntrate 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-7jv6w                     0/2     Running
apigee-runtime-apigee-test-0d59273-150rc2-a5mov-dfb29             0/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

Eliminar componentes

Si te has equivocado con alguno de estos componentes, elimina el componente y vuelve a crear el entorno con Helm: 

kubectl delete -n apigee apigeeenv HASHED_ENV_NAME

A continuación, crea el entorno (después de hacer las correcciones necesarias): 

helm upgrade ENV_NAME apigee-env/ \
--install \
--namespace APIGEE_NAMESPACE \
--set env=ENV_NAME \
--atomic \
-f OVERRIDES_FILE \
--dry-run=server

Asegúrate de incluir todos los ajustes que se muestran, incluido --atomic para que la acción se revierta si falla.

Instala el gráfico:

helm upgrade ENV_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  --atomic \
  -f OVERRIDES_FILE

Inspeccionar el mando

Si no hay mensajes de error evidentes en el pod, pero el componente no ha pasado al estado running, inspecciona el apigee-controller para ver si hay mensajes de error. 

kubectl logs -n NAMESPACE $(k get pods -n NAMESPACE | sed -n '2p' | awk '{print $1}') | grep -i error

De esta forma, el usuario puede ver por qué el controlador no ha podido procesar la solicitud (de create/delete/update, etc.).

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, pero las instalaciones de producción suelen contener tres o más pods.

Si el estado de Cassandra es creating o releasing, el estado DEBE restablecerse. Para solucionar algunos problemas (como los cambios de contraseña de Cassandra) y otros que no estén relacionados con la red, puede que tengas que eliminar componentes. Es muy posible que, en estos casos, no pueda eliminar la instancia (es decir, kubectl delete apigeedatastore -n NAMESPACE default). Tampoco sirve de nada usar --force o --grace-period=0.

El objetivo de reset es cambiar el estado del componente (apigeedatastore) de creating o releasing a running. Si cambias el estado de esta forma, no se solucionará el problema subyacente. En la mayoría de los casos, el componente se debe eliminar después de un restablecimiento.

  1. Intenta eliminarlo (no se completará):

    kubectl delete -n NAMESPACE apigeedatastore default

    Es habitual que este comando no se complete. Usa Ctrl+C para finalizar la llamada.

  2. Restablecer 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'

    Elimina el finalizador (ventana 2):

    kubectl edit -n NAMESPACE apigeedatastore default

    Busque las dos líneas siguientes y elimínelas:

    finalizers:
- apigeedatastore.apigee.cloud.google.com

Situaciones de error habituales

La configuración del proxy no está disponible con el tiempo de ejecución

Este error puede manifestarse de dos formas:

  • El runtime no está en el estado ready.
  • El runtime no ha recibido la última versión de la API.

  1. Empieza con los synchronizer pods.

    Inspecciona los registros de synchronizer. Estos son algunos de los errores más habituales:

    • Falta de conectividad de red (a *.googleapi.com)
    • Acceso de gestión de identidades y accesos incorrecto (la cuenta de servicio no está disponible o no se ha proporcionado con el permiso de Synchronizer Manager)
    • No se ha invocado la API setSyncAuthorization

  2. Inspecciona los pods runtime.

    Si inspeccionas los registros de los pods runtime, verás por qué runtime no ha cargado la configuración. El plano de control intenta evitar que la mayoría de los errores de configuración lleguen al plano de datos. En los casos en los que una validación sea imposible o no se haya implementado correctamente, el runtime no podrá cargarla.

"No runtime pods" in the control plane

  1. Empieza con los synchronizer pods.

    Consulta los registros de la synchronizer. Estos son algunos de los errores más habituales:

    • Falta de conectividad de red (a *.googleapi.com)
    • Acceso de gestión de identidades y accesos incorrecto (la cuenta de servicio no está disponible o no se ha proporcionado con el permiso de Synchronizer Manager)
    • No se ha invocado la API setSyncAuthorization. Es posible que la configuración nunca haya llegado al plano de datos.

  2. Inspecciona los pods runtime.

    Si inspeccionas los registros de los pods runtime, verás por qué runtime no ha cargado la configuración.

  3. Inspecciona los pods watcher.

    Es el componente watcher el que configura el acceso (enrutamiento) y comunica el estado de implementación del proxy y del acceso al plano de control. Inspecciona estos registros para averiguar por qué watcher no informa del estado. Entre los motivos habituales se incluye una discrepancia entre los nombres del archivo overrides.yaml y el plano de control del nombre del entorno o del nombre del grupo de entornos.

La sesión de depuración no aparece en el plano de control

  1. Empieza con los synchronizer pods.

    Inspecciona los registros de synchronizer. Estos son algunos de los errores más habituales:

    • Falta de conectividad de red (a *.googleapi.com)
    • Acceso de gestión de identidades y accesos incorrecto (la cuenta de servicio no está disponible o no se ha proporcionado con el permiso de Synchronizer Manager)
    • No se ha invocado la API setSyncAuthorization.
  2. Inspecciona los pods runtime.
    Si inspeccionas los registros de los pods runtime podrás ver por qué runtime no envía registros de depuración a UDCA.
  3. Inspecciona los pods de UDCA.
    Al inspeccionar los registros de UDCA, se mostrará por qué UDCA no envía información de la sesión de depuración al plano de control.

Cassandra devuelve respuestas de caché grandes

El siguiente mensaje de advertencia indica que Cassandra está recibiendo solicitudes de lectura o escritura con una carga útil mayor y se puede ignorar sin problemas, ya que este umbral de advertencia se ha definido con un valor inferior para indicar los tamaños de la carga útil de la 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