Solución de problemas de Apigee Hybrid atascado en la creación o el lanzamiento del estado

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-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

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.

Advertencia: Si borras apigeedatastore, también se borrarán los volúmenes persistentes. Se perderán todos los datos de Cassandra. Se recomienda crear una copia de seguridad de los datos de Cassandra.

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 estado ready.
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
Inspecciona los Pods runtime.

Cuando inspecciones los registros de los Pods runtime, se mostrará por qué el runtime 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, el runtime 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.
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é el watcher no informa el estado. Los motivos comunes incluyen una discrepancia entre los nombres en el archivo overrides.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.
Inspecciona los Pods runtime.
Si inspeccionas los registros de los Pods del runtime, se mostrará por qué el runtime 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