Esta página se ha traducido con Cloud Translation API.

Actualizar Apigee Hybrid a la versión 1.12

En este procedimiento se explica cómo actualizar de Apigee hybrid versión 1.11.x a Apigee hybrid versión 1.12.4 y de versiones anteriores de hybrid 1.12.x a la versión 1.12.4.

Sigue los mismos procedimientos para actualizar versiones secundarias (por ejemplo, de la versión 1.11 a la 1.12) y para actualizar versiones de parche (por ejemplo, de la 1.12.0 a la 1.12.4).

Si vas a actualizar desde la versión 1.10 o una anterior de Apigee hybrid, primero debes actualizar a la versión 1.11 antes de actualizar a la versión 1.12.4. Consulta las instrucciones para actualizar Apigee Hybrid a la versión 1.11.

Cambios de Apigee hybrid v1.11

La versión 1.12 de Apigee Hybrid introduce los siguientes cambios que afectan al proceso de actualización. Para ver la lista completa de funciones de la versión 1.12, consulta las notas de la versión 1.12.0 híbrida.

Cassandra 4.x: a partir de la versión 1.12, Apigee hybrid usa Cassandra 4 o una versión posterior.
Importante: Debido al cambio en la base de datos, no puedes revertir el componente apigee-datastore actualizado. Por lo tanto, es fundamental que hagas una copia de seguridad de tu base de datos de Cassandra y de tu instalación híbrida antes de actualizar. Si necesitas revertir la actualización, ten en cuenta los siguientes casos:
- Cassandra aún no se ha actualizado: puedes revertir todos los cambios.
- Cassandra se ha actualizado y todos los pods de Cassandra están en buen estado: puedes revertir los cambios en todos los componentes, excepto en apigee-datastore. Tu instalación de la versión 1.11.x seguirá funcionando con una instancia de la versión 1.12 de tu apigee-datastore que ejecute Cassandra 4.
- Cassandra se ha actualizado y los pods de Cassandra no están en buen estado: debes desinstalar la versión 1.12 híbrida y restaurar la instalación de la versión 1.11 a partir de una copia de seguridad.
Obsoleto en la versión 1.12: a partir de la versión 1.12, Apigee hybrid solo admite Helm para instalar y gestionar tu instalación híbrida.apigeectl
Precaución: apigeectl está obsoleto desde el 17 de abril del 2024. La herramienta apigeectl no es compatible con Apigee hybrid v1.12. La asistencia para apigeectl de Apigee hybrid v1.10 y v1.11 finalizará el 17 de abril del 2025. Para obtener más información, consulta el artículo sobre la obsolescencia de apigeectl.

Importante: Si gestionas la versión 1.11 con apigeectl, primero debes migrar tu instalación de la versión 1.11 para usar Helm antes de actualizar a la versión 1.12. Sigue las instrucciones que se indican en el artículo sobre cómo migrar Apigee hybrid a gráficos de Helm desde apigeectl.
Ya está disponible un nuevo conjunto de métricas para monitorizar los proxies de Apigee y los endpoints de destino. En el caso de la versión híbrida 1.12, los recursos monitorizados ProxyV2 y TargetV2 dejarán de usarse de forma predeterminada. Todas las métricas de proxy y de destino se publicarán en los recursos monitorizados Proxy y Target.

Para seguir emitiendo métricas a los recursos monitorizados de ProxyV2 y TargetV2, asigna el valor true a metrics.disablePrometheusPipeline en overrides.yaml.
Si ha configurado alertas basadas en métricas, confirme que está usando las métricas correctas para su instalación híbrida. Para obtener más información, consulta Alertas basadas en métricas.
Comprobaciones de instanciación de clases más estrictas: a partir de la versión 1.12.4 de Apigee Hybrid, la política JavaCallout ahora incluye seguridad adicional durante la instanciación de clases de Java. Esta medida de seguridad mejorada impide que se implementen políticas que intenten realizar acciones directa o indirectamente que requieran permisos no permitidos.
En la mayoría de los casos, las políticas actuales seguirán funcionando como de costumbre sin ningún problema. Sin embargo, es posible que se vean afectadas las políticas que dependen de bibliotecas de terceros o las que tienen código personalizado que activa indirectamente operaciones que requieren permisos elevados.

Importante: Para probar la instalación, sigue el procedimiento descrito en Validar políticas después de actualizar a la versión 1.12.4 para validar el comportamiento de las políticas.

Consideraciones antes de empezar una actualización a la versión 1.12

Consideraciones sobre Cassandra

Al actualizar de la versión 1.11 a la 1.12 de Apigee hybrid, se actualiza la base de datos de Cassandra de la versión 3.11.x a la 4.x. Aunque la actualización de Cassandra se gestiona como parte del procedimiento de actualización de Apigee hybrid, ten en cuenta lo siguiente:

La actualización de la versión de Cassandra se realizará en segundo plano y se llevará a cabo en un pod (o nodo de Cassandra) cada vez, por lo que debes prever una capacidad de base de datos reducida durante la actualización.
Escala la capacidad de Cassandra y asegúrate de que el uso del disco sea cercano o inferior al 50% antes de empezar la actualización.
Valida y prueba tus procedimientos de copia de seguridad y restauración de Cassandra.
Crea una copia de seguridad de los datos de Cassandra en tu instalación híbrida de la versión 1.11 antes de empezar a actualizar y valida las copias de seguridad.
Al actualizar apigee-datastore, se producirá un aumento temporal del consumo de CPU debido a las tareas posteriores a la actualización que realiza Cassandra.
Una vez que hayas actualizado el componente apigee-datastore (Cassandra), no podrás restaurar la versión anterior de ese componente. Hay dos situaciones en las que se puede revertir una actualización a la versión híbrida 1.12 después de actualizar el componente apigee-datastore:
- Si el componente apigee-datastore está en buen estado, pero otros componentes requieren una reversión, puedes revertir esos otros componentes individualmente.
  Nota: No podrás añadir regiones ni escalar nodos de Cassandra mientras ejecutes componentes de diferentes versiones híbridas.
- Si el componente apigee-datastore está en mal estado, debes restaurar una copia de seguridad de la versión 1.11 en una instalación de la versión 1.11.
  Nota: No puedes mezclar versiones al restaurar. Debes restaurar una copia de seguridad creada en una instalación de la versión 1.11 en una instalación de la versión 1.11.

Consideraciones antes de actualizar una instalación de una sola región

Si necesitas restaurar una versión anterior de Apigee hybrid, es posible que el proceso requiera un tiempo de inactividad. Por lo tanto, si vas a actualizar una instalación de una sola región, te recomendamos que crees una segunda región y que actualices solo una región a la vez siguiendo esta secuencia:

Añade una segunda región a tu instalación con la misma versión híbrida. Consulta la sección Despliegue multirregional de la documentación de la versión 1.11.
Crea una copia de seguridad y valida los datos de la primera región antes de iniciar una actualización. Consulta la descripción general de las copias de seguridad de Cassandra en la documentación de la versión 1.11.
Actualiza la región recién añadida a la versión híbrida 1.12.
Cambia el tráfico a la nueva región y valida el tráfico.
Una vez validada, actualiza la región anterior a la versión 1.12 híbrida.
Vuelve a dirigir todo el tráfico a la región anterior y valida el tráfico.
Retira la nueva región.

Consideraciones antes de actualizar una instalación multirregional

Apigee recomienda seguir esta secuencia para actualizar una instalación multirregión:

Crea una copia de seguridad y valida los datos de cada región antes de iniciar la actualización.
Actualiza la versión híbrida en una región y asegúrate de que todos los pods estén en estado de ejecución para validar la actualización.
Valida el tráfico en la región recién actualizada.
Actualiza cada región posterior solo después de validar el tráfico de la región anterior.
En caso de que sea necesario revertir una actualización en una implementación multirregional, prepárate para desviar el tráfico de las regiones que hayan fallado. Considera la posibilidad de añadir capacidad suficiente en la región a la que se desviará el tráfico para gestionar el tráfico de ambas regiones.

Requisitos previos

Antes de actualizar a la versión híbrida 1.12, asegúrate de que tu instalación cumpla los siguientes requisitos:

Una instalación de Apigee hybrid versión 1.11 gestionada con Helm.
- Si gestionas tu instalación híbrida con apigeectl, primero debes migrar tus clústeres a la gestión de Helm. Consulta el artículo Migrar Apigee hybrid a Helm desde apigeectl en la documentación de hybrid v1.11.
- Si tu instalación híbrida ejecuta una versión anterior a la 1.11, debes actualizar a la versión 1.11 antes de actualizar a la 1.12. Consulta Actualizar Apigee Hybrid a la versión 1.11.
Versión v3.14.2 o posterior de Helm.
kubectl versión 1.27, 1.28 o 1.29 (recomendada).
Versión v1.13.0 de cert-manager. Si es necesario, actualice cert-manager en la sección Preparar la actualización a la versión que aparece más abajo.

Limitaciones

Tenga en cuenta las siguientes limitaciones al planificar la actualización de Apigee hybrid de la versión 1.11 a la 1.12. La planificación puede ayudar a reducir la necesidad de tiempo de inactividad si tienes que revertir o restaurar el sistema después de la actualización.

Las copias de seguridad de Hybrid 1.12 no se pueden restaurar en Hybrid 1.11 y viceversa debido a la incompatibilidad entre las dos versiones.
No puedes escalar pods de Datastore durante la actualización a la versión 1.12. Ajusta la escala en todas las regiones antes de empezar a actualizar tu instalación híbrida.
En una instalación híbrida de una sola región, no puedes revertir el componente de almacén de datos una vez que haya finalizado el proceso de actualización del almacén de datos. No puedes restaurar un almacén de datos de Cassandra 4.x a un almacén de datos de Cassandra 3.x. Para ello, tendrás que restaurar la copia de seguridad más reciente de los datos de Cassandra 3.x (de tu instalación híbrida de la versión 1.11).
No se pueden eliminar ni añadir regiones durante la actualización. En una actualización multirregional, debes completar la actualización de todas las regiones antes de poder añadir o eliminar regiones.

Información general sobre la actualización a la versión 1.12.4

Para actualizar a la versión 1.12 de Apigee Hybrid, es posible que se produzca un tiempo de inactividad.

Al actualizar el controlador de Apigee a la versión 1.12.4, todas las implementaciones de Apigee se reinician de forma gradual. Para minimizar el tiempo de inactividad en entornos híbridos de producción durante un reinicio gradual, asegúrate de que tienes al menos dos clústeres (en la misma región o centro de datos, o en regiones o centros de datos diferentes). Desvía todo el tráfico de producción a un solo clúster y desconecta el clúster que vas a actualizar. A continuación, continúa con el proceso de actualización. Repite el proceso con cada clúster.

Apigee recomienda actualizar todos los clústeres lo antes posible para reducir las probabilidades de que se produzcan problemas en producción. No hay un límite de tiempo para actualizar todos los clústeres restantes después de que se haya actualizado el primero. Sin embargo, hasta que se actualicen todos los clústeres restantes, se verán afectadas las siguientes operaciones:

La copia de seguridad y la restauración de Cassandra no funcionan con versiones mixtas. Por ejemplo, una copia de seguridad de Hybrid 1.11 no se puede usar para restaurar una instancia de Hybrid 1.12.
La transmisión de datos de Cassandra no funcionará entre versiones híbridas mixtas. Por lo tanto, tus clústeres de Cassandra no se pueden escalar horizontalmente.
La ampliación y la retirada de regiones se verán afectadas, ya que estas operaciones dependen del streaming de datos de Cassandra.

Los procedimientos para actualizar Apigee hybrid se organizan en las siguientes secciones:

Prepárate para cambiar a un plan superior.
- Crea una copia de seguridad de Cassandra.
- Crea una copia de seguridad de los directorios de instalación híbrida.
Instala la versión 1.12.4 del entorno de ejecución híbrido.

Prepararse para actualizar a la versión 1.12

Copia de seguridad de Cassandra

Crea una copia de seguridad de tu base de datos de Cassandra en todas las regiones aplicables y valida los datos de tu instalación de la versión híbrida 1.11 antes de iniciar la actualización. Consulta Monitorizar copias de seguridad en la documentación de la versión 1.11.

Reinicia todos los pods de Cassandra del clúster antes de iniciar el proceso de actualización para que puedan surgir problemas persistentes.

Para reiniciar y probar los pods de Cassandra, elimina cada pod de forma individual, uno a la vez, y comprueba que vuelve a estar en estado de ejecución y que la sonda de disponibilidad se supera:

Enumera los pods de Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

Por ejemplo:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

. . .

Eliminar un pod:

kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME

Por ejemplo:

kubectl delete pod -n apigee apigee-cassandra-default-0

Para comprobar el estado, vuelve a enumerar los pods de Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

Por ejemplo:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          16s
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

. . .

Vuelve a aplicar el último archivo de anulación conocido para asegurarte de que no se ha modificado y, así, puedas usar la misma configuración para actualizar a la versión híbrida 1.12.

Asegúrate de que todos los nodos de Cassandra de todas las regiones estén en el estado UN (Activo/Normal). Si algún nodo de Cassandra tiene un estado diferente, resuélvelo primero antes de iniciar la actualización.

Puedes validar el estado de tus nodos de Cassandra con los siguientes comandos:

Enumera los pods de Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

Por ejemplo:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h
apigee-cassandra-default-3   1/1     Running   0          16m
apigee-cassandra-default-4   1/1     Running   0          14m
apigee-cassandra-default-5   1/1     Running   0          13m
apigee-cassandra-default-6   1/1     Running   0          9m
apigee-cassandra-default-7   1/1     Running   0          9m
apigee-cassandra-default-8   1/1     Running   0          8m

Comprueba el estado de los nodos de cada pod de Cassandra con el comando kubectl nodetool status:

kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME -- nodetool status

Por ejemplo:

kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool status
Datacenter: us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
UN  10.16.2.6    690.17 KiB  256          48.8%             b02089d1-0521-42e1-bbed-900656a58b68  ra-1
UN  10.16.4.6    705.55 KiB  256          51.6%             dc6b7faf-6866-4044-9ac9-1269ebd85dab  ra-1
UN  10.16.11.11  674.36 KiB  256          48.3%             c7906366-6c98-4ff6-a4fd-17c596c33cf7  ra-1
UN  10.16.1.11   697.03 KiB  256          49.8%             ddf221aa-80aa-497d-b73f-67e576ff1a23  ra-1
UN  10.16.5.13   703.64 KiB  256          50.9%             2f01ac42-4b6a-4f9e-a4eb-4734c24def95  ra-1
UN  10.16.8.15   700.42 KiB  256          50.6%             a27f93af-f8a0-4c88-839f-2d653596efc2  ra-1
UN  10.16.11.3   697.03 KiB  256          49.8%             dad221ff-dad1-de33-2cd3-f1.672367e6f  ra-1
UN  10.16.14.16  704.04 KiB  256          50.9%             1feed042-a4b6-24ab-49a1-24d4cef95473  ra-1
UN  10.16.16.1   699.82 KiB  256          50.6%             beef93af-fee0-8e9d-8bbf-efc22d653596  ra-1

Crear una copia de seguridad de los directorios de instalación híbrida

En estas instrucciones se usa la variable de entorno APIGEE_HELM_CHARTS_HOME para el directorio del sistema de archivos en el que has instalado los gráficos de Helm. Si es necesario, cambia al directorio y define la variable con el siguiente comando:
Linux
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
macOS
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
Windows
```
set APIGEE_HELM_CHARTS_HOME=%CD%
echo %APIGEE_HELM_CHARTS_HOME%
```
Crea una copia de seguridad de tu directorio 1.11 $APIGEE_HELM_CHARTS_HOME/. Puedes usar cualquier proceso de copia de seguridad. Por ejemplo, puedes crear un archivo tar de todo tu directorio con el siguiente comando:
```
tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.11-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
Crea una copia de seguridad de tu base de datos de Cassandra siguiendo las instrucciones de Copia de seguridad y recuperación de Cassandra.

Si utilizas archivos de certificado de servicio (.json) en tus sustituciones para autenticar cuentas de servicio, asegúrate de que los archivos de certificado de tu cuenta de servicio se encuentren en el directorio correcto del gráfico de Helm. Los gráficos de Helm no pueden leer archivos fuera del directorio de cada gráfico.

Este paso no es necesario si usas secretos de Kubernetes o Workload Identity para autenticar cuentas de servicio.

En la siguiente tabla se muestra el destino de cada archivo de cuenta de servicio, en función del tipo de instalación:

Producción

Cuenta de servicio	Nombre de archivo predeterminado	Directorio de gráficos de Helm
`apigee-cassandra`	`PROJECT_ID-apigee-cassandra.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/`
`apigee-logger`	`PROJECT_ID-apigee-logger.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-mart`	`PROJECT_ID-apigee-mart.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-metrics`	`PROJECT_ID-apigee-metrics.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-runtime`	`PROJECT_ID-apigee-runtime.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env`
`apigee-synchronizer`	`PROJECT_ID-apigee-synchronizer.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env/`
`apigee-udca`	`PROJECT_ID-apigee-udca.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-watcher`	`PROJECT_ID-apigee-watcher.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`

No producción

Crea una copia del archivo de cuenta de servicio apigee-non-prod en cada uno de los siguientes directorios:

Cuenta de servicio	Nombre de archivo predeterminado	Directorios de gráficos de Helm
`apigee-non-prod`	`PROJECT_ID-apigee-non-prod.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/` `$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/` `$APIGEE_HELM_CHARTS_HOME/apigee-org/` `$APIGEE_HELM_CHARTS_HOME/apigee-env/`

Asegúrate de que los archivos de certificado y clave TLS (.crt, .key o .pem) se encuentren en el directorio $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/.

Actualizar la versión de Kubernetes

Comprueba la versión de tu plataforma Kubernetes y, si es necesario, actualízala a una versión compatible con las versiones híbridas 1.11 y 1.12. Si necesitas ayuda, consulta la documentación de tu plataforma.

Haz clic para desplegar una lista de plataformas compatibles

	1,10 ⁽³⁾	1.11	1.12
GKE en Google Cloud	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
GKE en AWS	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1.26.x⁽¹²⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x (K8s v1.25.x) 1.26.x⁽¹²⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x⁽¹²⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
GKE en Azure	1.13.x 1.14.x 1.26.x⁽¹²⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.26.x⁽¹²⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x⁽¹²⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
Google Distributed Cloud (solo software) en VMware ⁽¹⁾ ⁽¹³⁾	1.13.x 1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽¹²⁾ 1.29.x^{(≥ 1.12.1)}
Google Distributed Cloud (solo software) en bare metal ⁽¹⁾	1.13.x 1.14.x (K8s v1.25.x) 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x⁽¹²⁾^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽¹²⁾^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽¹²⁾ 1.29.x^{(≥ 1.12.1)}
EKS⁽⁷⁾	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
AKS⁽⁷⁾	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
OpenShift⁽⁷⁾	4.11 4.12 4.14^{(≥ 1.10.5)} 4.15^{(≥ 1.10.5)}	4.12 4.13 4.14 4.15^{(≥ 1.11.2)} 4.16^{(≥ 1.11.2)}	4.12 4.13 4.14 4.15 4.16^{(≥ 1.12.1)}
Rancher Kubernetes Engine (RKE)	v1.26.2+rke2r1 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	v1.26.2+rke2r1 v1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
VMware Tanzu	N/A	N/A	v1.26.x
Componentes	1.10	1.11	1.12
Cloud Service Mesh	1.17.x⁽¹⁰⁾	1.18.x⁽¹⁰⁾	1.19.x⁽¹⁰⁾
JDK	JDK 11	JDK 11	JDK 11
cert-manager	1.10.x 1.11.x 1.12.x	1.11.x 1.12.x 1.13.x	1.11.x 1.12.x 1.13.x
Cassandra	3.11	3.11	4.0
Kubernetes	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x
kubectl			1.27.x 1.28.x 1.29.x
Helm	3.10+	3.10+	3.14.2+
Controlador de CSI de Secret Store		1.3.4	1.4.1
Vault		1.13.x	1.15.2
^1. En la versión 1.13 de Anthos on-premises (Google Distributed Cloud), sigue estas instrucciones para evitar conflictos con `cert-manager`: Conflicting cert-manager installation ⁽²⁾ La asistencia está disponible en la versión 1.7.2 de Apigee hybrid y en versiones posteriores. ⁽³⁾ Se han alcanzado las fechas oficiales de finalización del ciclo de vida de las versiones 1.10 y anteriores de Apigee Hybrid. Los parches mensuales periódicos ya no están disponibles. Estas versiones ya no se admiten oficialmente, excepto para los clientes que tengan excepciones explícitas y oficiales para seguir recibiendo asistencia. Otros clientes deben actualizarse. ⁽⁴⁾Las versiones 1.12 y anteriores de Anthos on-premise (Google Distributed Cloud) ya no se admiten. Consulta la política de compatibilidad de versiones de Distributed Cloud en bare metal y la lista de versiones compatibles de Distributed Cloud en VMware. ⁽⁵⁾Google Distributed Cloud en hardware desnudo o VMware requiere Cloud Service Mesh 1.14 o una versión posterior. Te recomendamos que actualices a la versión 1.8 de Hybrid y que cambies a la puerta de enlace de entrada de Apigee, que ya no requiere que instales Cloud Service Mesh en tu clúster híbrido. ⁽⁶⁾ La asistencia está disponible en la versión 1.8.4 de Apigee Hybrid y en versiones posteriores. ⁽⁷⁾ No se admite en Apigee Hybrid versión 1.8.4 y posteriores. ⁽⁸⁾ La asistencia está disponible con Apigee Hybrid versión 1.7.6 y posteriores. ⁽⁹⁾ No se admite en Apigee Hybrid versión 1.8.5 y posteriores. ⁽¹⁰⁾ Cloud Service Mesh se instala automáticamente con Apigee hybrid 1.9 y versiones posteriores. ⁽¹¹⁾ La asistencia está disponible en Apigee hybrid versión 1.9.2 y posteriores. ⁽¹²⁾ Los números de versión de GKE en AWS ahora reflejan las versiones de Kubernetes. Consulta la compatibilidad con versiones y actualizaciones de GKE Enterprise para obtener información sobre las versiones y los parches recomendados. ⁽¹³⁾ Vault no está certificado en Google Distributed Cloud para VMware. ⁽¹⁴⁾ La asistencia está disponible en la versión 1.10.5 de Apigee Hybrid y en versiones posteriores. ⁽¹⁵⁾ La asistencia está disponible en la versión 1.11.2 de Apigee Hybrid y en versiones posteriores. ⁽¹⁶⁾ La asistencia está disponible en la versión 1.12.1 de Apigee hybrid y versiones posteriores.

Acerca de los clústeres vinculados

En las versiones 1.7.x y anteriores de Apigee hybrid, debes usar clústeres adjuntos de GKE si quieres ejecutar Apigee hybrid en un contexto multicloud en Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) u otro proveedor de servicios de Kubernetes de terceros compatible. La asociación de clústeres permite a Google medir el uso de Cloud Service Mesh.

En la versión híbrida 1.8.x de Apigee, se necesitan clústeres de GKE adjuntos si usas Cloud Service Mesh para tu pasarela de entrada. Si usas la puerta de enlace de entrada de Apigee, los clústeres adjuntos son opcionales.

Instalar el entorno de ejecución híbrido 1.12.4

Prepararse para la actualización de los gráficos de Helm

Extrae los gráficos de Helm de Apigee.

Los gráficos de Apigee Hybrid se alojan en Google Artifact Registry:

oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts

Con el comando pull, copia todos los gráficos de Helm de Apigee hybrid en tu almacenamiento local con el siguiente comando:

export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
export CHART_VERSION=1.12.4
helm pull $CHART_REPO/apigee-operator --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-datastore --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-env --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-ingress-manager --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-org --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-redis --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-telemetry --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-virtualhost --version $CHART_VERSION --untar

Actualiza cert-manager si es necesario.
Si necesitas actualizar la versión de cert-manager, instala la nueva con el siguiente comando:
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml
```

Instala los CRDs de Apigee actualizados:

Nota: Este es el único método admitido para instalar CRDs de Apigee. No uses kubectl apply sin -k ni omitas --server-side.

Usa la función de prueba kubectl ejecutando el siguiente comando:

kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false --dry-run

Después de validar con el comando de prueba, ejecuta el siguiente comando:

kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false

Valida la instalación con el comando kubectl get crds:

kubectl get crds | grep apigee

La salida debería tener un aspecto similar al siguiente:

apigeedatastores.apigee.cloud.google.com                    2023-10-09T14:48:30Z
apigeedeployments.apigee.cloud.google.com                   2023-10-09T14:48:30Z
apigeeenvironments.apigee.cloud.google.com                  2023-10-09T14:48:31Z
apigeeissues.apigee.cloud.google.com                        2023-10-09T14:48:31Z
apigeeorganizations.apigee.cloud.google.com                 2023-10-09T14:48:32Z
apigeeredis.apigee.cloud.google.com                         2023-10-09T14:48:33Z
apigeerouteconfigs.apigee.cloud.google.com                  2023-10-09T14:48:33Z
apigeeroutes.apigee.cloud.google.com                        2023-10-09T14:48:33Z
apigeetelemetries.apigee.cloud.google.com                   2023-10-09T14:48:34Z
cassandradatareplications.apigee.cloud.google.com           2023-10-09T14:48:35Z

Comprueba las etiquetas de los nodos del clúster. De forma predeterminada, Apigee programa los pods de datos en nodos con la etiqueta cloud.google.com/gke-nodepool=apigee-data y los pods de tiempo de ejecución en nodos con la etiqueta cloud.google.com/gke-nodepool=apigee-runtime. Puedes personalizar las etiquetas de tu grupo de nodos en el archivo overrides.yaml.

Para obtener más información, consulta el artículo sobre cómo configurar grupos de nodos dedicados.

Instalar los gráficos de Helm de Apigee Hybrid

Nota: Antes de ejecutar cualquiera de los comandos de actualización o instalación de Helm, usa la función de prueba de Helm añadiendo --dry-run al final del comando. Consulta helm -h para ver una lista de los comandos, las opciones y el uso admitidos.

Si no lo has hecho, ve al directorio APIGEE_HELM_CHARTS_HOME. Ejecuta los siguientes comandos desde ese directorio.

Actualiza el operador o el controlador de Apigee:

Nota: Este paso requiere permisos de clúster elevados. Ejecuta helm -h o helm upgrade -h para obtener más información.

Prueba de funcionamiento:

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  -f OVERRIDES_FILE \
  --dry-run

Actualiza el gráfico:

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  -f OVERRIDES_FILE

Nota: En las instalaciones migradas de apigeectl a Helm, usa lo siguiente:

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  --force \
  -f OVERRIDES_FILE

Verifica la instalación del operador de Apigee:

helm ls -n apigee-system

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.4   1.12.4

Para comprobar que funciona correctamente, consulta su disponibilidad:

kubectl -n apigee-system get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

Actualiza el almacén de datos de Apigee:

Prueba de funcionamiento:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

Actualiza el gráfico:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

Nota: En las instalaciones migradas de apigeectl a Helm, usa lo siguiente:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

Verifica que apigeedatastore esté en funcionamiento comprobando su estado:

kubectl -n apigee get apigeedatastore default

NAME      STATE       AGE
default   running    2d

Actualiza la telemetría de Apigee:

Prueba de funcionamiento:

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

Actualiza el gráfico:

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

Nota: En las instalaciones migradas de apigeectl a Helm, usa lo siguiente:

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

Para comprobar que funciona correctamente, consulta su estado:

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Actualiza Apigee Redis:

Prueba de funcionamiento:

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

Actualiza el gráfico:

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

Nota: En las instalaciones migradas de apigeectl a Helm, usa lo siguiente:

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

Para comprobar que funciona correctamente, consulta su estado:

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Actualiza el gestor de entrada de Apigee:

Prueba de funcionamiento:

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

Actualiza el gráfico:

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

Nota: En las instalaciones migradas de apigeectl a Helm, usa lo siguiente:

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

Para comprobar que funciona correctamente, consulta su disponibilidad:

kubectl -n apigee get deployment apigee-ingressgateway-manager

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d

Actualiza la organización de Apigee:

Prueba de funcionamiento:

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

Actualiza el gráfico:

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

Nota: En las instalaciones migradas de apigeectl a Helm, usa lo siguiente:

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

Comprueba que está en funcionamiento consultando el estado de la organización correspondiente:

kubectl -n apigee get apigeeorg

NAME                      STATE     AGE
apigee-org1-xxxxx          running   2d

Actualiza el entorno.
Debes instalar un entorno cada vez. Especifica el entorno con --set env=ENV_NAME:

Prueba de funcionamiento:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run
```
- ENV_RELEASE_NAME es el nombre con el que instalaste el gráfico apigee-env. En la versión híbrida 1.10, suele ser apigee-env-ENV_NAME. En Hybrid 1.11 y versiones posteriores, suele ser ENV_NAME.
- ENV_NAME es el nombre del entorno que vas a actualizar.
- OVERRIDES_FILE es tu nuevo archivo de anulaciones para la versión 1.12.4.
Actualiza el gráfico:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Nota: En las instalaciones migradas de apigeectl a Helm, usa lo siguiente:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  --force \
  -f OVERRIDES_FILE
```
Para comprobar que está en funcionamiento, consulta el estado del entorno correspondiente:
```
kubectl -n apigee get apigeeenv
```
```
NAME                          STATE       AGE   GATEWAYTYPE
apigee-org1-dev-xxx            running     2d
```
Actualiza los grupos de entornos (virtualhosts).
1. Debes actualizar los grupos de entornos (hosts virtuales) de uno en uno. Especifica el grupo de entornos con --set envgroup=ENV_GROUP_NAME. Repite los siguientes comandos para cada grupo de entorno mencionado en el archivo overrides.yaml:
  Prueba de funcionamiento:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE \
  --dry-run
```
  ENV_GROUP_RELEASE_NAME es el nombre con el que instalaste el gráfico apigee-virtualhost. En la versión híbrida 1.10, suele ser apigee-virtualhost-ENV_GROUP_NAME. En Hybrid 1.11 y versiones posteriores, suele ser ENV_GROUP_NAME.
  
  Actualiza el gráfico:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE
```
  Nota: En las instalaciones migradas de apigeectl a Helm, usa lo siguiente:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  --force \
  -f OVERRIDES_FILE
```
  Nota: ENV_GROUP_RELEASE_NAME debe ser único en el espacio de nombres apigee.
  Por ejemplo, si tiene un entorno llamado prod y un grupo de entornos llamado prod, asigne a ENV_GROUP_RELEASE_NAME un valor único, como prod-envgroup.
2. Comprueba el estado de ApigeeRoute (AR).
  Al instalar virtualhosts se crea ApigeeRouteConfig (ARC), que a su vez crea ApigeeRoute (AR) una vez que el watcher de Apigee extrae los detalles relacionados con el grupo de entornos del plano de control. Por lo tanto, comprueba que el estado de la AR correspondiente sea "running":
```
kubectl -n apigee get arc
```
```
NAME                                STATE   AGE
apigee-org1-dev-egroup                       2d
```
```
kubectl -n apigee get ar
```
```
NAME                                        STATE     AGE
apigee-org1-dev-egroup-xxxxxx                running   2d
```

Validar las políticas después de actualizar a la versión 1.12.4

Sigue este procedimiento para validar el comportamiento de la política JavaCallout después de actualizar de la versión 1.12.3 o anterior a la 1.12.4 o posterior.

Comprueba si los archivos JAR de Java solicitan permisos innecesarios.
Una vez que se haya implementado la política, comprueba los registros de tiempo de ejecución para ver si aparece el siguiente mensaje de registro: "Failed to load and initialize class ...". Si ves este mensaje, significa que el archivo JAR implementado ha solicitado permisos innecesarios. Para solucionar este problema, investiga el código Java y actualiza el archivo JAR.
Investiga y actualiza el código Java.
Revisa el código Java (incluidas las dependencias) para identificar la causa de las operaciones que pueden no estar permitidas. Cuando lo encuentre, modifique el código fuente según sea necesario.
Prueba las políticas con la comprobación de seguridad habilitada.
En un entorno de no producción, habilita la marca de verificación de seguridad y vuelve a implementar tus políticas con un archivo JAR actualizado. Para definir la marca, sigue estos pasos:
- En el archivo apigee-env/values.yaml, asigna el valor true a conf_security-secure.constructor.only en runtime:cwcAppend:. Por ejemplo:
```
# Apigee Runtime
runtime:
  cwcAppend:
    conf_security-secure.constructor.only: true
```
- Actualiza el gráfico apigee-env del entorno para aplicar el cambio. Por ejemplo:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Si el mensaje de registro "Failed to load and initialize class ..." sigue presente, sigue modificando y probando el archivo JAR hasta que el mensaje de registro deje de aparecer.
Habilita la comprobación de seguridad en el entorno de producción.
Después de haber probado y verificado a fondo el archivo JAR en el entorno de no producción, habilite la comprobación de seguridad en su entorno de producción configurando la marca conf_security-secure.constructor.only en true y actualizando el gráfico apigee-env del entorno de producción para aplicar el cambio.

Restaurar una versión anterior

Esta sección se divide en partes en función del estado de tu componente apigee-datastore después de actualizar a la versión 1.12 de Apigee hybrid. Hay procedimientos para revertir los cambios en una o varias regiones con el componente apigee-datastore en buen estado, así como procedimientos para recuperar o restaurar una copia de seguridad cuando apigee-datastore está en mal estado.

Restauración y recuperación de una sola región

Restauración cuando `apigee-datastore` está en buen estado

En este procedimiento se explica cómo revertir todos los componentes de Apigee hybrid de la versión 1.12 a la 1.11 excepto apigee-datastore. El componente apigee-datastore de la versión 1.12 es retrocompatible con los componentes híbridos de la versión 1.11.

Advertencia: No se puede revertir la versión de apigee-datastore. La incompatibilidad de los datos entre las diferentes versiones de la base de datos de Cassandra impide volver a la versión anterior.

Para restaurar la versión 1.11 de la instalación de una sola región, sigue estos pasos:

Antes de iniciar la reversión, comprueba que todos los pods estén en estado de ejecución:
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

Valida el lanzamiento de componentes con Helm:

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

por ejemplo:

helm -n apigee list
NAME              NAMESPACE   REVISION   UPDATED                                   STATUS     CHART                           APP VERSION
datastore         apigee      2          2024-03-29 17:08:07.917848253 +0000 UTC   deployed   apigee-datastore-1.12.0         1.12.0
ingress-manager   apigee      2          2024-03-29 17:21:02.917333616 +0000 UTC   deployed   apigee-ingress-manager-1.12.0   1.12.0
redis             apigee      2          2024-03-29 17:19:51.143728084 +0000 UTC   deployed   apigee-redis-1.12.0             1.12.0
telemetry         apigee      2          2024-03-29 17:16:09.883885403 +0000 UTC   deployed   apigee-telemetry-1.12.0         1.12.0
myhybridorg       apigee      2          2024-03-29 17:21:50.899855344 +0000 UTC   deployed   apigee-org-1.12.0               1.12.0

Revierta cada componente excepto apigee-datastore con los siguientes comandos:

Crea la siguiente variable de entorno:
- PREVIOUS_HELM_CHARTS_HOME: directorio en el que se instalan los gráficos de Helm de Apigee Hybrid anteriores. Esta es la versión a la que vas a volver.
Restablece los virtualhosts. Repite el siguiente comando para cada grupo de entornos mencionado en el archivo de anulaciones.
```
helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
ENV_GROUP_RELEASE_NAME es el nombre con el que instalaste el gráfico apigee-virtualhost. En la versión híbrida 1.10, suele ser apigee-virtualhost-ENV_GROUP_NAME. En Hybrid 1.11 y versiones posteriores, suele ser ENV_GROUP_NAME.
Restaurar entornos. Repite el siguiente comando para cada entorno mencionado en el archivo de anulaciones.
```
helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
ENV_RELEASE_NAME es el nombre con el que instalaste el gráfico apigee-env. En la versión híbrida 1.10, suele ser apigee-env-ENV_NAME. En Hybrid 1.11 y versiones posteriores, suele ser ENV_NAME.

Para comprobar que está en funcionamiento, consulta el estado del entorno correspondiente:
```
kubectl -n apigee get apigeeenv
```
```
NAME                  STATE     AGE   GATEWAYTYPE
apigee-org1-dev-xxx   running   2d
```

Restaurar organización:

helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Comprueba que está en funcionamiento consultando el estado de la organización correspondiente:

kubectl -n apigee get apigeeorg

NAME                STATE     AGE
apigee-org1-xxxxx   running   2d

Retira Ingress Manager:

helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Para comprobar que funciona correctamente, consulta su disponibilidad:

kubectl -n apigee get deployment apigee-ingressgateway-manager

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d

Retira Redis:

helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Para comprobar que funciona correctamente, consulta su estado:

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Restaurar la telemetría de Apigee:

helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Para comprobar que funciona correctamente, consulta su estado:

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Retira el controlador de Apigee:

helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Verifica la instalación del operador de Apigee:

helm ls -n apigee-system

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.4   1.12.4

Para comprobar que funciona correctamente, consulta su disponibilidad:

kubectl -n apigee-system get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

Revertir los CRDs de Apigee Hybrid:

kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false

Valida que todos los pods estén en estado de ejecución o completado:

kubectl get pods -n APIGEE_NAMESPACE

kubectl get pods -n apigee-system

Valida el lanzamiento de todos los componentes. Todos los componentes deben estar en la versión anterior, excepto el almacén de datos:

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

por ejemplo:

helm -n apigee  list
NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0

Restaurar cuando `apigee-datastore` no está en buen estado

Si la actualización del componente apigee-datastore no se ha completado correctamente, no podrás volver de la versión 1.12 a la 1.11 de apigee-datastore. En su lugar, debes restaurar una copia de seguridad de una instalación de la versión 1.11. Sigue esta secuencia para restaurar la versión anterior.

Si no tienes una instalación activa de la versión 1.11 de Apigee hybrid (por ejemplo, en otra región), crea una nueva instalación de la versión 1.11 con los gráficos y los archivos de anulaciones de tu copia de seguridad. Consulta las instrucciones de instalación de la versión 1.11 de Apigee Hybrid.
Restaura la región de la versión 1.11 (o la nueva instalación) desde tu copia de seguridad siguiendo las instrucciones de:
- Copias de seguridad de la interfaz de almacenamiento en la nube (CSI): copia de seguridad y restauración de Cassandra con CSI.
- Copias de seguridad que no son de CSI: restauración en una sola región.
Verificar el tráfico de la instalación restaurada
Opcional: Elimina la instalación de la versión 1.12 siguiendo las instrucciones de Desinstalar entornos de ejecución híbridos.

Restauración y recuperación multirregionales

Restauración cuando `apigee-datastore` está en buen estado

Antes de iniciar la reversión, comprueba que todos los pods estén en estado de ejecución:
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

Asegúrate de que todos los nodos de Cassandra de todas las regiones estén en el estado UN (Activo o Normal). Si algún nodo de Cassandra tiene un estado diferente, soluciona ese problema primero antes de iniciar el proceso de actualización.

Puedes validar el estado de tus nodos de Cassandra con los siguientes comandos:

Enumera los pods de Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

Por ejemplo:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h
apigee-cassandra-default-3   1/1     Running   0          16m
apigee-cassandra-default-4   1/1     Running   0          14m
apigee-cassandra-default-5   1/1     Running   0          13m
apigee-cassandra-default-6   1/1     Running   0          9m
apigee-cassandra-default-7   1/1     Running   0          9m
apigee-cassandra-default-8   1/1     Running   0          8m

Comprueba el estado de los nodos de cada pod de Cassandra con el comando kubectl nodetool status:

kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME -- nodetool -u JMX_USER -pw JMX_PASSWORD

Por ejemplo:

kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u jmxuser -pw JMX_PASSWORD status
Datacenter: us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens   Owns (effective)   Host ID                                Rack
UN  10.16.2.6    690.17 KiB  256      48.8%              b02089d1-0521-42e1-bbed-900656a58b68   ra-1
UN  10.16.4.6    705.55 KiB  256      51.6%              dc6b7faf-6866-4044-9ac9-1269ebd85dab   ra-1
UN  10.16.11.11  674.36 KiB  256      48.3%              c7906366-6c98-4ff6-a4fd-17c596c33cf7   ra-1
UN  10.16.1.11   697.03 KiB  256      49.8%              ddf221aa-80aa-497d-b73f-67e576ff1a23   ra-1
UN  10.16.5.13   703.64 KiB  256      50.9%              2f01ac42-4b6a-4f9e-a4eb-4734c24def95   ra-1
UN  10.16.8.15   700.42 KiB  256      50.6%              a27f93af-f8a0-4c88-839f-2d653596efc2   ra-1
UN  10.16.11.3   697.03 KiB  256      49.8%              dad221ff-dad1-de33-2cd3-f1.672367e6f   ra-1
UN  10.16.14.16  704.04 KiB  256      50.9%              1feed042-a4b6-24ab-49a1-24d4cef95473   ra-1
UN  10.16.16.1   699.82 KiB  256      50.6%              beef93af-fee0-8e9d-8bbf-efc22d653596   ra-1

Si no todos los pods de Cassandra están en estado UN, sigue las instrucciones de la sección Eliminar nodos DOWN del clúster de Cassandra.

Ve al directorio donde estén instalados los gráficos de Helm de Apigee hybrid anteriores.

Cambia el contexto a la región que se ha actualizado

kubectl config use-context UPGRADED_REGION_CONTEXT

Valida que todos los pods estén en estado de ejecución:

kubectl get pods -n APIGEE_NAMESPACE

kubectl get pods -n apigee-system

Usa el comando helm para asegurarte de que todas las versiones se han actualizado a Hybrid 1.12:

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

por ejemplo:

helm -n apigee list
NAME             NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore        apigee     2         2024-03-29 17:08:07.917848253 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager  apigee     2         2024-03-29 17:21:02.917333616 +0000 UTC  deployed  apigee-ingress-manager-1.12.0  1.12.0
redis            apigee     2         2024-03-29 17:19:51.143728084 +0000 UTC  deployed  apigee-redis-1.12.0            1.12.0
telemetry        apigee     2         2024-03-29 17:16:09.883885403 +0000 UTC  deployed  apigee-telemetry-1.12.0        1.12.0
myhybridorg      apigee     2         2024-03-29 17:21:50.899855344 +0000 UTC  deployed  apigee-org-1.12.0              1.12.0

Revierta cada componente excepto apigee-datastore con los siguientes comandos:

Crea la siguiente variable de entorno:
- PREVIOUS_HELM_CHARTS_HOME: directorio en el que se instalan los gráficos de Helm de Apigee Hybrid anteriores. Esta es la versión a la que vas a volver.
Restablece los virtualhosts. Repite el siguiente comando para cada grupo de entornos mencionado en el archivo de anulaciones.
```
helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
ENV_GROUP_RELEASE_NAME es el nombre con el que instalaste el gráfico apigee-virtualhost. En la versión híbrida 1.10, suele ser apigee-virtualhost-ENV_GROUP_NAME. En Hybrid 1.11 y versiones posteriores, suele ser ENV_GROUP_NAME.
Restaurar entornos. Repite el siguiente comando para cada entorno mencionado en el archivo de anulaciones.
```
helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
ENV_RELEASE_NAME es el nombre con el que instalaste el gráfico apigee-env. En la versión híbrida 1.10, suele ser apigee-env-ENV_NAME. En Hybrid 1.11 y versiones posteriores, suele ser ENV_NAME.

Verifica que cada entorno esté activo comprobando el estado del entorno correspondiente:
```
kubectl -n apigee get apigeeenv
```
```
NAME                  STATE     AGE   GATEWAYTYPE
apigee-org1-dev-xxx   running   2d
```

Restaurar organización:

helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Comprueba que está en funcionamiento consultando el estado de la organización correspondiente:

kubectl -n apigee get apigeeorg

NAME                STATE     AGE
apigee-org1-xxxxx   running   2d

Retira Ingress Manager:

helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Para comprobar que funciona correctamente, consulta su disponibilidad:

kubectl -n apigee get deployment apigee-ingressgateway-manager

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d

Retira Redis:

helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Para comprobar que funciona correctamente, consulta su estado:

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Restaurar la telemetría de Apigee:

helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Para comprobar que funciona correctamente, consulta su estado:

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Retira el controlador de Apigee:

helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Verifica la instalación del operador de Apigee:

helm ls -n apigee-system

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.4   1.12.4

Para comprobar que funciona correctamente, consulta su disponibilidad:

kubectl -n apigee-system get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

Revertir los CRDs de Apigee Hybrid:

kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false

Valida el lanzamiento de todos los componentes. Todos los componentes deben estar en la versión anterior, excepto datastore:

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

por ejemplo:

helm -n apigee  list
NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0

En este punto, todas las versiones publicadas, excepto datastore, se han revertido a la versión anterior.

Recuperar una instalación multirregional a una versión anterior

Recupera la región en la que ha fallado la actualización en una actualización multirregión eliminando las referencias a ella de las instalaciones multirregión. Este método solo es posible si hay al menos una región activa en Hybrid 1.11. El almacén de datos de la versión 1.12 es compatible con los componentes de la versión 1.11.

Para recuperar las regiones fallidas de una región correcta, sigue estos pasos:

Redirige el tráfico de la API de las regiones afectadas a la región que funciona correctamente. Planifica la capacidad en consecuencia para admitir el tráfico desviado de las regiones con errores.
Retira la región afectada. Sigue los pasos que se indican en Retirar una región híbrida para cada región afectada. Espera a que se complete la retirada antes de continuar con el siguiente paso.
Limpia la región fallida siguiendo las instrucciones del artículo Recuperar una región tras una actualización fallida.
Recupera la región afectada. Para recuperarlo, crea una región como se describe en Despliegues para varias regiones en GKE, GKE On‐Prem y AKS.

Restaurar una instalación multirregional a partir de una copia de seguridad con `apigee-datastore` en mal estado

Si la actualización del componente apigee-datastore no se ha completado correctamente, no podrás volver de la versión 1.12 a la 1.11. En su lugar, debes restaurar una copia de seguridad de una instalación de la versión 1.11. Sigue esta secuencia para restaurar la versión anterior.

Si no tienes una instalación activa de la versión 1.11 de Apigee hybrid (por ejemplo, en otra región), crea una nueva instalación de la versión 1.11 con los gráficos y los archivos de anulaciones de tu copia de seguridad. Consulta las instrucciones de instalación de la versión 1.11 de Apigee Hybrid.
Restaura la región de la versión 1.11 (o la nueva instalación) desde tu copia de seguridad siguiendo las instrucciones de:
- Copias de seguridad de la interfaz de almacenamiento en la nube (CSI): copia de seguridad y restauración de Cassandra con CSI.
- Copias de seguridad que no son de CSI: restauración en varias regiones.
Verificar el tráfico de la instalación restaurada
En las instalaciones multirregionales, vuelve a crear y restaurar la siguiente región. Consulta las instrucciones de la sección Restaurar a partir de una copia de seguridad en Restaurar en varias regiones.
Elimina la instalación de la versión 1.12 siguiendo las instrucciones de Desinstalar entornos de ejecución híbridos.

APÉNDICE: Recuperar una región tras una actualización fallida

Elimina un centro de datos si la actualización de la versión 1.11 a la 1.12 falla.

Valida el estado del clúster de Cassandra desde una región activa:

Cambia el contexto de kubectl a la región que quieras quitar:
```
kubectl config use-context CONTEXT_OF_LIVE_REGION
```

Enumera los pods de Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

Por ejemplo:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                 READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

Ejecuta el comando en uno de los pods de Cassandra:

kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash

Comprueba el estado del clúster de Cassandra:

nodetool -u JMX_USER -pw JMX_PASSWORD status

La salida debería tener un aspecto similar al siguiente:

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
UN  10.48.12.16  813.84 KiB  256          100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.14.16  859.89 KiB  256          100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
UN  10.48.0.18   888.95 KiB  256          100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1

Describe el clúster para verificar que solo ves las IPs de los pods de Cassandra de la región activa y que todos tienen la misma versión de esquema:

nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

La salida debería tener un aspecto similar al siguiente:

nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

Schema versions:
    4bebf2de-0582-31b4-9c5f-e36f60127e1b: [10.48.14.16, 10.48.12.16, 10.48.0.18]

Limpiar la replicación del espacio de claves de Cassandra:

Obtiene el trabajo user-setup y lo elimina. Se creará una nueva tarea de user-setup inmediatamente.

kubectl get jobs -n APIGEE_NAMESPACE

Por ejemplo:

kubectl get jobs -n apigee
  NAME                                                           COMPLETIONS   DURATION   AGE
  apigee-cassandra-schema-setup-myhybridorg-8b3e61d          1/1           6m35s      3h5m
  apigee-cassandra-schema-val-myhybridorg-8b3e61d-28499150   1/1           10s        9m22s
 apigee-cassandra-user-setup-myhybridorg-8b3e61d            0/1           21s        21s

kubectl delete jobs USER_SETUP_JOB_NAME -n APIGEE_NAMESPACE

La salida debería mostrar que se ha iniciado el nuevo trabajo:

kubectl delete jobs apigee-cassandra-user-setup-myhybridorg-8b3e61d -n apigee

  apigee-cassandra-user-setup-myhybridorg-8b3e61d-wl92b         0/1     Init:0/1    0               1s

Valida la configuración de replicación del espacio de claves de Cassandra creando un contenedor de cliente siguiendo las instrucciones de Crear el contenedor de cliente.

Obtiene todos los espacios de claves. Ejecuta el pod cassandra-client y, a continuación, inicia un cliente cqlsh:

kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

Conéctate al servidor de Cassandra con ddl user, ya que tiene los permisos necesarios para ejecutar los siguientes comandos:

cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

Obtén los espacios de claves:

select * from system_schema.keyspaces;

La salida debería tener este aspecto, donde dc-1 es el centro de datos activo:

select * from system_schema.keyspaces;

 keyspace_name            | durable_writes | replication
--------------------------+----------------+--------------------------------------------------------------------------------
   kvm_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
              system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
            system_schema |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
 quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
 cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   rtc_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
       system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                   system |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                   perses |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
            system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   kms_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}

(11 rows)

Si, por algún motivo, el trabajo user-setup sigue dando errores y la validación falla, usa los siguientes comandos para corregir la replicación en los espacios de claves.

kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

Conéctate al servidor de Cassandra con ddl user, ya que tiene los permisos necesarios para ejecutar los siguientes comandos:

cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

Obtén los espacios de claves:

select * from system_schema.keyspaces;

Usa los nombres de espacio de claves del comando anterior y sustitúyelos en los siguientes ejemplos.

alter keyspace quota_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace kms_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace kvm_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace cache_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace perses_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace rtc_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_distributed WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_traces WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};

Valida que todos los espacios de claves se repliquen en la región correcta con el siguiente comando cqlsh:

select * from system_schema.keyspaces;

Por ejemplo:

select * from system_schema.keyspaces;

 keyspace_name           | durable_writes | replication
-------------------------+----------------+--------------------------------------------------------------------------------
kvm_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
          system_auth    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
        system_schema    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
rtc_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   system_distributed    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
               system    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
               perses    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
        system_traces    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
kms_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}

(11 rows)

En este punto, ya has eliminado por completo todas las referencias del centro de datos inactivo del clúster de Cassandra.

APÉNDICE: Eliminar nodos DOWN de un clúster de Cassandra

Sigue este procedimiento cuando reviertas una instalación multirregión y no todos los pods de Cassandra estén en estado Activo o Normal (UN).

Ejecuta el comando en uno de los pods de Cassandra:

kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash

Comprueba el estado del clúster de Cassandra:

nodetool -u JMX_USER -pw JMX_PASSWORD status

Valida que el nodo esté inactivo (DN). Accede al pod de Cassandra en una región en la que el pod de Cassandra no pueda iniciarse.

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.48.12.16  1.15 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.0.18   1.21 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
UN  10.48.14.16  1.18 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1

Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
DN  10.8.4.4     432.42 KiB  256     100.0%            cd672398-5c45-4c88-a424-86d757951e53  rc-1
UN  10.8.19.6    5.8 MiB     256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
UN  10.8.21.5    5.74 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

Quita la referencia al nodo hacia abajo (DN). En el ejemplo anterior, vamos a quitar la referencia al host 10.8.4.4.

kubectl exec -it -n apigee apigee-cassandra-default-2 -- /bin/bash
 nodetool -u JMX_USER -pw JMX_PASSWORD removenode HOST_ID

Una vez que se haya quitado la referencia, finaliza el pod. El nuevo pod de Cassandra debería iniciarse y unirse al clúster.
```
kubectl delete pod -n POD_NAME
```

Valida que el nuevo pod de Cassandra se ha unido al clúster.

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.48.12.16  1.16 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.0.18   1.22 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
UN  10.48.14.16  1.19 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1

Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.8.19.6    5.77 MiB    256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
UN  10.8.4.5     246.99 KiB  256     100.0%            0182e675-eec8-4d68-a465-69211b621601  rc-1
UN  10.8.21.5    5.69 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

En este punto, puede continuar con la actualización o revertir los cambios en las regiones restantes del clúster.

APÉNDICE: Solución de problemas: `apigee-datastore` se queda bloqueado después de revertir

Sigue este procedimiento cuando hayas revertido apigee-datastore a la versión híbrida 1.11 después de una actualización y se haya quedado bloqueada.

Antes de volver a corregir el estado del controlador del almacén de datos, valida que esté en estado releasing y que los pods no se estén activando junto con el estado del clúster de Cassandra.

Valida con el comando de Helm que se ha restaurado la versión de Datastore:

helm -n APIGEE_NAMESPACE list

Por ejemplo:

helm -n apigee list
NAME              NAMESPACE  REVISION  UPDATED                                   STATUS    CHART                              APP VERSION
datastore         apigee     3         2024-04-04 22:15:08.792539892 +0000 UTC   deployed   apigee-datastore-1.11.0           1.11.0
ingress-manager   apigee     1         2024-04-02 22:24:27.564184968 +0000 UTC   deployed   apigee-ingress-manager-1.12.0     1.12.0
redis             apigee     1         2024-04-02 22:23:59.938637491 +0000 UTC   deployed   apigee-redis-1.12.0               1.12.0
telemetry         apigee     1         2024-04-02 22:23:39.458134303 +0000 UTC   deployed   apigee-telemetry-1.12             1.12.0
myhybridorg       apigee     1         2024-04-02 23:36:32.614927914 +0000 UTC   deployed   apigee-org-1.12.0                 1.12.0

Obtén el estado de los pods de Cassandra:

kubectl get pods -n APIGEE_NAMESPACE

Por ejemplo:

kubectl get pods -n apigee
NAME                         READY   STATUS             RESTARTS      AGE
apigee-cassandra-default-0   1/1     Running            0             2h
apigee-cassandra-default-1   1/1     Running            0             2h
apigee-cassandra-default-2   0/1     CrashLoopBackOff   4 (13s ago)   2m13s

Valida que el controlador apigeeds esté bloqueado en el estado de liberación:

kubectl get apigeeds -n APIGEE_NAMESPACE

Por ejemplo:

kubectl get apigeeds -n apigee
NAME      STATE       AGE
default   releasing   46h

Valida el estado de los nodos de Cassandra (observa que un nodo está en estado DN, que es el nodo atascado en el estado CrashLoopBackOff):

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

Por ejemplo:

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
Defaulted container "apigee-cassandra" out of: apigee-cassandra, apigee-cassandra-ulimit-init (init)
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--   Address       Load       Tokens   Owns (effective)   Host ID                               Rack
UN   10.68.7.28    2.12 MiB   256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3  rc-1
UN   10.68.10.29   2.14 MiB   256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452  rc-1
DN   10.68.6.26    5.77 MiB   256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1

Actualiza el almacén de datos con los gráficos de la versión 1.12.
Nota: El controlador volverá al estado releasing, pero esta vez creará pods con las imágenes de Hybrid 1.12, que se activarán, y Cassandra se unirá al clúster y pasará al estado UN (UP/NORMAL).
```
helm upgrade datastore APIGEE_HELM_1.12.0_HOME/apigee-datastore/   --install   --namespace APIGEE_NAMESPACE   -f overrides.yaml
```

Valida que todos los pods estén Running y que el clúster de Cassandra vuelva a estar en buen estado.

Valida que todos los pods estén READY de nuevo:

kubectl get pods -n APIGEE_NAMESPACE

Por ejemplo:

kubectl get pods -n apigee
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          29h
apigee-cassandra-default-1   1/1     Running   0          29h
apigee-cassandra-default-2   1/1     Running   0          60m

Valida el estado del clúster de Cassandra:

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

Por ejemplo:

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--   Address       Load      Tokens   Owns (effective)   Host ID                                Rack
UN   10.68.4.15    2.05 MiB  256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1
UN   10.68.7.28    3.84 MiB  256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3   rc-1
UN   10.68.10.29   3.91 MiB  256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452   rc-1

Valida el estado del controlador de apigeeds:

kubectl get apigeeds -n APIGEE_NAMESPACE

Por ejemplo:

kubectl get apigeeds -n apigee
NAME      STATE     AGE
default   running   2d1h

En este punto, ya habrá corregido el almacén de datos y debería estar en estado running.

Actualizar Apigee Hybrid a la versión 1.12 Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Cambios de Apigee hybrid v1.11

Consideraciones antes de empezar una actualización a la versión 1.12

Consideraciones sobre Cassandra

Consideraciones antes de actualizar una instalación de una sola región

Consideraciones antes de actualizar una instalación multirregional

Requisitos previos

Limitaciones

Información general sobre la actualización a la versión 1.12.4

Prepararse para actualizar a la versión 1.12

Copia de seguridad de Cassandra

Crear una copia de seguridad de los directorios de instalación híbrida

Linux

macOS

Windows

Producción

No producción

Actualizar la versión de Kubernetes

Haz clic para desplegar una lista de plataformas compatibles

Componentes

Acerca de los clústeres vinculados

Instalar el entorno de ejecución híbrido 1.12.4

Prepararse para la actualización de los gráficos de Helm

Instalar los gráficos de Helm de Apigee Hybrid

Validar las políticas después de actualizar a la versión 1.12.4

Restaurar una versión anterior

Restauración y recuperación de una sola región

Restauración cuando apigee-datastore está en buen estado

Restaurar cuando apigee-datastore no está en buen estado

Restauración y recuperación multirregionales

Restauración cuando apigee-datastore está en buen estado

Recuperar una instalación multirregional a una versión anterior

Restaurar una instalación multirregional a partir de una copia de seguridad con apigee-datastore en mal estado

APÉNDICE: Recuperar una región tras una actualización fallida

APÉNDICE: Eliminar nodos DOWN de un clúster de Cassandra

APÉNDICE: Solución de problemas: apigee-datastore se queda bloqueado después de revertir

Actualizar Apigee Hybrid a la versión 1.12

Restauración cuando `apigee-datastore` está en buen estado

Restaurar cuando `apigee-datastore` no está en buen estado

Restauración cuando `apigee-datastore` está en buen estado

Restaurar una instalación multirregional a partir de una copia de seguridad con `apigee-datastore` en mal estado

APÉNDICE: Solución de problemas: `apigee-datastore` se queda bloqueado después de revertir