Se usó la API de Cloud Translation para traducir esta página.

Actualiza Apigee Hybrid a la versión 1.12

Este procedimiento abarca la actualización de la versión 1.11.x de Apigee Hybrid a la versión 1.12.3 de Apigee Hybrid.

Cambios de Apigee Hybrid v1.11

La versión 1.12 de Apigee Hybrid presenta los siguientes cambios que afectan el proceso de actualización. Para obtener una lista completa de las funciones de la versión 1.12, consulta las notas de la versión 1.12.0 de híbrido.

Cassandra 4.x: A partir de la versión 1.12, Apigee Hybrid usa Cassandra versión 4+.
Importante: Debido al cambio en la base de datos, no puedes revertir el componente apigee-datastore actualizado. Por lo tanto, es fundamental que crees una copia de seguridad de tu base de datos de Cassandra y tu instalación híbrida antes de actualizar. Si necesitas revertir la actualización, ten en cuenta las siguientes situaciones:
- Cassandra aún no se actualizó: Puedes revertir todos los cambios.
- Se actualizó Cassandra 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 v1.11.x seguirá funcionando con una instancia de v1.12 de tu apigee-datastore que ejecute Cassandra v4.
- Se actualizó Cassandra y los Pods de Cassandra están en mal estado: Debes desinstalar la versión híbrida 1.12 y restablecer tu instalación v.11 desde una copia de seguridad.
Baja de apigeectl: A partir de la versión 1.12, Apigee Hybrid solo admite Helm para instalar y administrar la instalación híbrida.
Precaución: apigeectl dejó de estar disponible el 17 de abril de 2024. La herramienta apigeectl no es compatible con Apigee Hybrid v1.12. La compatibilidad con apigeectl para Apigee Hybrid v1.10 y v1.11 finalizará el 17 de abril de 2025. Para obtener más información, consulta la baja de apigeectl.

Importante: Si administras la versión 1.11 con apigeectl, primero debes migrar tu instalación de v1.11 para usar Helm antes de actualizar a la versión 1.12. Sigue las instrucciones en Migra los charts de Apigee Hybrid a Helm desde apigeectl.
Ya está disponible un nuevo paquete de métricas para supervisar los proxies y los extremos de destino de Apigee. En la versión híbrida 1.12, los recursos supervisados ProxyV2 y TargetV2 ya no se usarán de forma predeterminada. Todas las métricas de proxy y de destino se publicarán en los recursos supervisados Proxy y Target.

Para seguir emitiendo métricas a los recursos supervisados ProxyV2 y TargetV2, establece metrics.disablePrometheusPipeline en true en overrides.yaml.
Si tienes configuradas alertas basadas en métricas, confirma que se usen las métricas correctas para tu instalación híbrida. Para obtener más información, consulta Alertas basadas en métricas.

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

La actualización de la versión 1.11 de Apigee Hybrid a la versión 1.12 incluye una actualización de la base de datos de Cassandra de la versión 3.11.x a la versión 4.x. Si bien la actualización de Cassandra se maneja como parte del procedimiento de actualización de Apigee Hybrid, planifica las siguientes consideraciones:

La actualización de la versión de Cassandra se realizará en segundo plano y se realizará en 1 Pod (o nodo de Cassandra) a la vez, por lo que debes planificar 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 esté cerca o por debajo del 50% antes de comenzar la actualización.
Valida y prueba tus procedimientos de copia de seguridad y restablecimiento de Cassandra.
Crea una copia de seguridad de los datos de Cassandra en tu instalación de la versión híbrida 1.11 antes de comenzar a actualizar y validar tus copias de seguridad.
La actualización de apigee-datastore provocará un aumento temporal en el 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 revertirlo a la versión anterior. Existen dos situaciones para 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 revertirlos de forma individual.
  Nota: No podrás agregar regiones ni escalar nodos de Cassandra mientras ejecutas componentes de diferentes versiones híbridas.
- Si el componente apigee-datastore está en mal estado, debes restablecer desde 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 cuando restableces. Debes restablecer una copia de seguridad tomada en una instalación de v1.11 en una instalación de v1.11.

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

Si necesitas revertir a una versión anterior de Apigee Hybrid, el proceso puede requerir tiempo de inactividad. Por lo tanto, si actualizas una instalación de una sola región, te recomendamos que crees una segunda región y, luego, actualices solo una región a la vez en la siguiente secuencia:

Agrega una segunda región a tu instalación existente con la misma versión híbrida. Consulta Implementación multirregional en la documentación de la versión 1.11.
Crea una copia de seguridad de los datos de la primera región y valida los datos antes de iniciar una actualización. Consulta Descripción general de la copia de seguridad de Cassandra en la documentación de la versión 1.11.
Actualiza la región recién agregada a la versión híbrida 1.12.
Cambia el tráfico a la región nueva y valida el tráfico.
Una vez validada, actualiza la región anterior con la versión Hybrid 1.12.
Vuelve a cambiar todo el tráfico a la región anterior y valida el tráfico.
Quita la región nueva.

Consideraciones antes de actualizar una instalación multirregional

Apigee recomienda la siguiente secuencia para actualizar una instalación multirregional:

Crea una copia de seguridad de los datos de cada región y valida los datos 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 en la región anterior.
En caso de que sea necesario revertir una actualización en una implementación multirregión, prepárate para cambiar el tráfico de las regiones con errores y considera agregar suficiente capacidad en la región a la que se desviará el tráfico para manejar el tráfico de ambas regiones.

Requisitos previos

Antes de actualizar a la versión Hybrid 1.12, asegúrate de que la instalación cumpla con los siguientes requisitos:

Una instalación de Apigee Hybrid versión 1.11 administrada con Helm.
- Si administras tu instalación híbrida con apigeectl, primero debes migrar tus clústeres a la administración de Helm. Consulta Migra 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 1.11 antes de actualizar a la 1.12. Consulta cómo actualizar Apigee híbrido a la versión 1.11.
Versión de Helm v3.14.2+.
kubectl versión 1.27, 1.28 o 1.29 (recomendado).
Versión v1.13.0 de cert-manager. Si es necesario, actualizarás cert-manager en la sección Prepárate para actualizar a la versión que aparece a continuación.

Limitaciones

Ten en cuenta las siguientes limitaciones cuando planifiques tu actualización de la versión 1.11 de Apigee Hybrid a la versión 1.12. La planificación puede ayudar a reducir la necesidad de tiempo de inactividad si necesitas revertir o restablecer después de la actualización.

Las copias de seguridad de Hybrid 1.12 no se pueden restablecer en Hybrid 1.11 ni viceversa, debido a la incompatibilidad entre las dos versiones.
No puedes escalar los Pods del almacén de datos durante la actualización a la versión 1.12. Soluciona tus necesidades de escalamiento en todas las regiones antes de comenzar a actualizar tu instalación híbrida.
En una instalación híbrida de una sola región, no puedes revertir el componente de Datastore una vez que finalice el proceso de actualización de Datastore. No puedes revertir un almacén de datos de Cassandra 4.x a un almacén de datos de Cassandra 3.x. Esto requerirá que restablezcas desde la copia de seguridad más reciente de los datos de Cassandra 3.x (de la instalación de la versión híbrida 1.11).
No se puede borrar ni agregar una región durante la actualización. En una actualización multirregional, debes completar la actualización de todas las regiones antes de poder agregar o borrar regiones.

Descripción general de la actualización a la versión 1.12.3

La actualización a Apigee Hybrid 1.12 puede requerir tiempo de inactividad.

Cuando se actualiza el controlador de Apigee a la versión 1.12.3, todas las implementaciones de Apigee se someten a un reinicio progresivo. Para minimizar el tiempo de inactividad en entornos híbridos de producción durante un reinicio progresivo, asegúrate de ejecutar al menos dos clústeres (en el mismo centro de datos o en uno diferente, o en la misma región o en una diferente). Divide todo el tráfico de producción en un solo clúster, toma el clúster que estás a punto de actualizar sin conexión y, luego, continúa con el proceso de actualización. Repite el proceso para cada clúster.

Apigee recomienda actualizar todos los clústeres lo antes posible para reducir las posibilidades de impacto de producción. No hay límite para que se actualicen todos los clústeres restantes después de que se actualice 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 restablecimiento de Cassandra no puede funcionar con versiones mixtas. Por ejemplo, no se puede usar una copia de seguridad de Hybrid 1.11 para restablecer una instancia de Hybrid 1.12.
La transmisión de datos de Cassandra no funcionará entre versiones híbridas. Por lo tanto, los clústeres de Cassandra no pueden escalar de manera horizontal.
La expansión de la región y el retiro de servicio se verán afectados, ya que estas operaciones dependen de la transmisión de datos de Cassandra.

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

Prepárate para la actualización.
- Crea una copia de seguridad de Cassandra.
- Crea una copia de seguridad de los directorios de instalación de Hybrid
Instala la versión 1.12.3 del entorno de ejecución híbrido.

Prepárate 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 en tu instalación de la versión híbrida 1.11 antes de iniciar la actualización. Consulta Cómo supervisar las copias de seguridad en la documentación de la versión 1.11.

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

Para reiniciar y probar los pods de Cassandra, borra cada uno de ellos de forma individual, uno a la vez, y, luego, valida que vuelva a aparecer en un estado en ejecución y que se apruebe la prueba de preparación:

Genera una lista de 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

. . .

Borra un Pod:

kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME

Por ejemplo:

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

Vuelve a enumerar los Pods de Cassandra para verificar el estado:

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 hayan realizado cambios en él, de modo que 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 en todas las regiones estén en el estado UN (Up / Normal). Si algún nodo de Cassandra está en un estado diferente, primero solucione ese problema antes de comenzar la actualización.

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

Genera una lista de 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

Verifica 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

Crea una copia de seguridad de los directorios de instalación híbridos

En estas instrucciones, se usa la variable de entorno APIGEE_HELM_CHARTS_HOME para el directorio en tu sistema de archivos en el que instalaste los charts de Helm. Si es necesario, cambia el directorio a este 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%
```
Realiza una copia de seguridad de tu directorio $APIGEE_HELM_CHARTS_HOME/ versión 1.11. Puedes usar cualquier proceso de copia de seguridad. Por ejemplo, puedes crear un archivo tar de todo tu directorio con lo siguiente:
```
tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.11-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
Realiza una copia de seguridad de tu base de datos de Cassandra según las instrucciones que se indican en Copia de seguridad y recuperación de Cassandra.

Si usas archivos de certificado de servicio (.json) en tus anulaciones para autenticar cuentas de servicio, asegúrate de que tus archivos de certificado de cuenta de servicio residan en el directorio del chart de Helm correcto. Los charts de Helm no pueden leer archivos fuera de cada directorio del chart.

Este paso no es necesario si usas Secrets 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, según el tipo de instalación:

Producción

Cuenta de servicio	Nombre de archivo predeterminado	Directorio de charts 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

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

Cuenta de servicio	Nombre de archivo predeterminado	Directorios de charts 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 el certificado TLS y los archivos de claves (.crt, .key o .pem) residan en el directorio $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/.

Actualiza tu versión de Kubernetes

Verifica tu versión de la plataforma de Kubernetes y, si es necesario, actualiza tu plataforma de Kubernetes a una versión compatible con Hybrid 1.11 y Hybrid 1.12. Si necesitas ayuda, sigue la documentación de la plataforma.

Haz clic para expandir 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 equipos físicos ⁽¹⁾	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
⁽¹⁾ En la versión 1.13 de Anthos local (Google Distributed Cloud), sigue estas instrucciones para evitar conflictos con `cert-manager`: Instalación de cert-manager en conflicto ⁽²⁾ Compatibilidad disponible con la versión 1.7.2 de Apigee Hybrid y posteriores. ⁽³⁾ Se alcanzaron las fechas oficiales de EOL para las versiones 1.10 y posteriores de Apigee hybrid. Los parches mensuales regulares ya no están disponibles. Estas versiones ya no son oficialmente compatibles, excepto para los clientes con excepciones explícitas y oficiales para la asistencia continua. Otros clientes deben actualizar. ⁽⁴⁾ Las versiones 1.12 y anteriores de Anthos local (Google Distributed Cloud) no son compatibles. Consulta la política de asistencia de versiones de Distributed Cloud en Bare Metal y la lista de versiones compatibles de Distributed Cloud en VMware. ⁽⁵⁾Google Distributed Cloud en Bare Metal 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 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. ⁽⁶⁾ Compatibilidad disponible con la versión 1.8.4 de Apigee Hybrid y posteriores.. ⁽⁷⁾ No es compatible con la versión 1.8.4 de Apigee Hybrid y las versiones posteriores. ⁽⁸⁾ Compatibilidad disponible con la versión 1.7.6 de Apigee Hybrid y posteriores.. ⁽⁹⁾ No es compatible con la versión híbrida 1.8.5 de Apigee y las versiones posteriores. ⁽¹⁰⁾ Cloud Service Mesh se instala automáticamente con Apigee Hybrid 1.9 y versiones posteriores. ⁽¹¹⁾ Compatibilidad disponible con la versión 1.9.2 de Apigee Hybrid y posteriores.. ⁽¹²⁾ Los números de versiones de GKE en AWS ahora reflejan las versiones de Kubernetes. Consulta la compatibilidad con versiones y actualizaciones de GKE Enterprise para obtener detalles de las versiones y parches recomendados. ⁽¹³⁾ Vault no está certificado en Google Distributed Cloud para VMware. ⁽¹⁴⁾ Compatibilidad disponible con la versión 1.10.5 de Apigee Hybrid y posteriores.. ⁽¹⁵⁾ Compatibilidad disponible con la versión 1.11.2 de Apigee Hybrid y posteriores. ⁽¹⁶⁾ Compatibilidad disponible con la versión 1.12.1 de Apigee Hybrid y posteriores.

Acerca de los clústeres adjuntos

Para las versiones de Apigee Hybrid 1.7.x y anteriores, debes usar clústeres adjuntos de GKE si deseas ejecutar Apigee Hybrid en un contexto de múltiples nubes en Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) o algún otro proveedor de servicios de Kubernetes compatible de terceros. El adjunto de clúster permite que Google mida el uso de Cloud Service Mesh.

En la versión 1.8.x de Apigee Hybrid, se requieren clústeres adjuntos de GKE si usas Cloud Service Mesh para la puerta de enlace de entrada. Si usas la puerta de enlace de entrada de Apigee, los clústeres adjuntos son opcionales.

Instala el entorno de ejecución híbrido 1.12.3

Prepárate para la actualización de los charts de Helm

Extrae los charts de Helm para 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.3
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 tu versión de cert-manager, instala la versión nueva con el siguiente comando:
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml
```

Instala las CRD de Apigee actualizadas:

Nota: Este es el único método compatible para instalar las CRD de Apigee. No uses kubectl apply sin -k, no omitas --server-side.

Usa la función de ejecución de prueba kubectl mediante la ejecución del 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 ejecución 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 respuesta debería ser similar a la 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

Verifica las etiquetas en los nodos del clúster. De forma predeterminada, Apigee programa los Pods de datos en los nodos con la etiqueta cloud.google.com/gke-nodepool=apigee-data y los Pods del entorno de ejecución se programan 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 Configura grupos de nodos dedicados.

Instala 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 validación de Helm; para ello, agrega --dry-run al final del comando. Consulta helm -h para enumerar los comandos, las opciones y el uso compatibles.

Si no lo hiciste, navega a tu directorio APIGEE_HELM_CHARTS_HOME. Ejecuta los siguientes comandos desde ese directorio.

Actualiza el operador o controlador de Apigee:

Nota: En este paso, se requieren permisos elevados de clúster. Ejecuta helm -h o helm upgrade -h para obtener más detalles

Ejecución de prueba:

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

Actualiza el chart:

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  -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.3   1.12.3

Para verificar que esté en funcionamiento, comprueba 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:

Ejecución de prueba:

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

Actualiza el chart:

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

Para verificar que apigeedatastore esté en funcionamiento, comprueba su estado:

kubectl -n apigee get apigeedatastore default

NAME      STATE       AGE
default   running    2d

Actualiza la telemetría de Apigee:

Ejecución de prueba:

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

Actualiza el chart:

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

Para verificar que esté en funcionamiento, comprueba su estado:

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Actualiza Apigee Redis:

Ejecución de prueba:

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

Actualiza el chart:

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

Para verificar que esté en funcionamiento, comprueba su estado:

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Actualiza el administrador de entrada de Apigee:

Ejecución de prueba:

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

Actualiza el chart:

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

Para verificar que esté en funcionamiento, comprueba 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:

Ejecución de prueba:

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

Actualiza el chart:

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

Para verificar que esté en funcionamiento, comprueba 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 a la vez. Especifica el entorno con --set env=ENV_NAME:

Ejecución de prueba:
```
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 se instaló el chart apigee-env. En la versión híbrida 1.10, por lo general, es apigee-env-ENV_NAME. En la versión híbrida 1.11 y posteriores, suele ser ENV_NAME.
- ENV_NAME es el nombre del entorno que estás actualizando.
- OVERRIDES_FILE es tu nuevo archivo de anulaciones para v.1.12.3.
Actualiza el chart:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Nota: Para las instalaciones migradas, usa lo siguiente:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  --force \
  -f OVERRIDES_FILE
```
Para verificar que esté en funcionamiento, comprueba 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 un grupo de entornos (virtualhost) a la vez. Especifica el grupo de entornos con --set envgroup=ENV_GROUP_NAME. Repite los siguientes comandos para cada grupo de entornos mencionado en el archivo overrides.yaml:
  Ejecución de prueba:
```
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 se instaló el chart apigee-virtualhost. En la versión híbrida 1.10, por lo general, es apigee-virtualhost-ENV_GROUP_NAME. En la versión híbrida 1.11 y posteriores, suele ser ENV_GROUP_NAME.
  
  Actualiza el chart:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE
```
  Nota: Para las instalaciones migradas, 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 tienes un entorno llamado prod y un grupo de entornos llamado prod, establece el valor de ENV_GROUP_RELEASE_NAME en algo único, como prod-envgroup.
2. Verifica el estado de ApigeeRouter (AR).
  La instalación de virtualhosts crea ApigeeRouteConfig (ARC), que crea de forma interna ApigeeRoute (AR) una vez que Apigee Watcher extrae detalles relacionados del grupo de entornos desde el plano de control. Por lo tanto, verifica que el estado de AR correspondiente esté en ejecución:
```
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
```

Revierte a una versión anterior

Esta sección se divide en secciones según el estado de tu componente apigee-datastore después de actualizar a la versión 1.12 de Apigee Hybrid. Existen procedimientos para la reversión de una sola región o multirregional con el componente apigee-datastore en buen estado y procedimientos para la recuperación o el restablecimiento desde una copia de seguridad cuando apigee-datastore está en mal estado.

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

Revierte cuando `apigee-datastore` esté en buen estado

En este procedimiento, se explica cómo revertir cada componente de Apigee Hybrid de la versión 1.12 a la v1.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 es posible revertir apigee-datastore. La incompatibilidad de datos entre diferentes versiones de la base de datos de Cassandra impide revertir a la versión anterior.

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

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

Valida la versión de los 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

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

Crea la siguiente variable de entorno:
- PREVIOUS_HELM_CHARTS_HOME: El directorio en el que se instalaron los charts anteriores de Helm para Apigee Hybrid. Esta es la versión a la que estás revirtiendo.
Revierte los hosts virtuales. 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 se instaló el chart apigee-virtualhost. En la versión híbrida 1.10, por lo general, es apigee-virtualhost-ENV_GROUP_NAME. En la versión híbrida 1.11 y posteriores, suele ser ENV_GROUP_NAME.
Revierte los 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 se instaló el chart apigee-env. En la versión híbrida 1.10, por lo general, es apigee-env-ENV_NAME. En la versión híbrida 1.11 y posteriores, suele ser ENV_NAME.

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

Revierte la organización:

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

Para verificar que esté en funcionamiento, comprueba el estado de la organización correspondiente:

kubectl -n apigee get apigeeorg

NAME                STATE     AGE
apigee-org1-xxxxx   running   2d

Revierte el administrador de Ingress:

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

Para verificar que esté en funcionamiento, comprueba 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

Revierte Redis:

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

Para verificar que esté en funcionamiento, comprueba su estado:

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Revierte la telemetría de Apigee:

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

Para verificar que esté en funcionamiento, comprueba su estado:

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Revierte 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.3   1.12.3

Para verificar que esté en funcionamiento, comprueba 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

Revierte las CRD 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 completados:
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

Valida la versión 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

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

Si la actualización del componente apigee-datastore no se realizó correctamente, no puedes revertir apigee-datastore de la versión 1.12 a la versión 1.11. En su lugar, debes restablecer a partir de una copia de seguridad realizada a partir de una instalación de la versión v1.11. Usa la siguiente secuencia para restablecer 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 instalación nueva de v1.11 con tus gráficos de copia de seguridad y archivos de anulación. Consulta las instrucciones de instalación de la versión 1.11 de Apigee Hybrid.
Restablece la región de la versión v1.11 (o la instalación nueva) desde tu copia de seguridad siguiendo las instrucciones que se indican en:
- Copias de seguridad de la interfaz de Cloud Storage (CSI): Copia de seguridad y restablecimiento de CSI de Cassandra.
- Copias de seguridad que no son de CSI: Restablece en una sola región.
Verifica el tráfico a la instalación restablecida
Opcional: Quita la instalación de la versión 1.12 siguiendo las instrucciones que se indican en Desinstala el entorno de ejecución de Hybrid.

Reversión y recuperación multirregionales

Revierte cuando `apigee-datastore` esté en buen estado

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

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

Genera una lista de 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

Verifica 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 un estado UN, sigue las instrucciones que se indican en Quita los nodos DOWN del clúster de Cassandra.

Navega al directorio en el que se instalaron los charts anteriores de Helm para Apigee Hybrid

Cambia el contexto a la región que se actualizó

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 hayan actualizado a Hybrid v1.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

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

Crea la siguiente variable de entorno:
- PREVIOUS_HELM_CHARTS_HOME: El directorio en el que se instalaron los charts anteriores de Helm para Apigee Hybrid. Esta es la versión a la que estás revirtiendo.
Revierte los hosts virtuales. 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 se instaló el chart apigee-virtualhost. En la versión híbrida 1.10, por lo general, es apigee-virtualhost-ENV_GROUP_NAME. En la versión híbrida 1.11 y posteriores, suele ser ENV_GROUP_NAME.
Revierte los 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 se instaló el chart apigee-env. En la versión híbrida 1.10, por lo general, es apigee-env-ENV_NAME. En la versión híbrida 1.11 y posteriores, suele ser ENV_NAME.

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

Revierte la organización:

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

Para verificar que esté en funcionamiento, comprueba el estado de la organización correspondiente:

kubectl -n apigee get apigeeorg

NAME                STATE     AGE
apigee-org1-xxxxx   running   2d

Revierte el administrador de Ingress:

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

Para verificar que esté en funcionamiento, comprueba 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

Revierte Redis:

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

Para verificar que esté en funcionamiento, comprueba su estado:

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Revierte la telemetría de Apigee:

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

Para verificar que esté en funcionamiento, comprueba su estado:

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Revierte 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.3   1.12.3

Para verificar que esté en funcionamiento, comprueba 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

Revierte las CRD de Apigee Hybrid:

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

Valida la versión 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 momento, todas las versiones, excepto datastore, se revirtieron a la versión anterior.

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

Para recuperar la región en la que falló la actualización en una actualización multirregional, quita las referencias a ella de las instalaciones de varias regiones. Este método solo es posible cuando hay al menos 1 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 regiones con errores a partir de una región en buen estado, sigue estos pasos:

Redirecciona el tráfico de la API de las regiones afectadas a la región que funciona. Planifica la capacidad según corresponda para admitir el tráfico desviado de las regiones con errores.
Quita la región afectada. Para cada región afectada, sigue los pasos descritos en Retira una región híbrida. Espera a que se complete el retiro de servicio antes de continuar con el siguiente paso.
Limpia la región con errores siguiendo las instrucciones que se indican en Cómo recuperar una región de una actualización con errores.
Recupera la región afectada. Para recuperar, crea una región nueva, como se describe en Implementación multirregional en GKE, GKE On-Prem y AKS.

Restablece 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 realizó correctamente, no puedes revertir de la versión 1.12 a la 1.11. En su lugar, debes restablecer a partir de una copia de seguridad realizada a partir de una instalación de la versión v1.11. Usa la siguiente secuencia para restablecer 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 instalación nueva de v1.11 con tus gráficos de copia de seguridad y archivos de anulación. Consulta las instrucciones de instalación de la versión 1.11 de Apigee Hybrid.
Restablece la región de la versión v1.11 (o la instalación nueva) desde tu copia de seguridad siguiendo las instrucciones que se indican en:
- Copias de seguridad de la interfaz de Cloud Storage (CSI): Copia de seguridad y restablecimiento de CSI de Cassandra.
- Copias de seguridad que no son de CSI: Restablece en varias regiones.
Verifica el tráfico a la instalación restablecida
En el caso de las instalaciones multirregionales, vuelve a compilar y restablece la siguiente región. Consulta las instrucciones en Restablece desde una copia de seguridad en Restablece en varias regiones.
Quita la instalación de la versión 1.12 siguiendo las instrucciones que se indican en Desinstala el entorno de ejecución de Hybrid.

APÉNDICE: Recupera una región de una actualización con errores

Quita un centro de datos si la actualización de 1.11 a 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 se quitará:
```
kubectl config use-context CONTEXT_OF_LIVE_REGION
```

Genera una lista de 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 uno de los Pods de Cassandra:

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

Verifica el estado del clúster de Cassandra:

nodetool -u JMX_USER -pw JMX_PASSWORD status

El resultado debería ser similar a lo 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 veas las IP de los Pods de Cassandra de la región activa y que todas tengan la misma versión de esquema:

nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

El resultado debería ser similar a lo 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]

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

Obtén el trabajo user-setup y bórralo. Se creará un trabajo user-setup nuevo de inmediato.

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

El resultado debería mostrar el inicio del trabajo nuevo:

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

Para validar la configuración de replicación del espacio de claves de Cassandra, crea un contenedor de cliente siguiendo las instrucciones que se indican en Crea el contenedor de cliente.

Obtén todos los espacios de claves. Ejecuta el Pod cassandra-client y, luego, 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;

El resultado debería ser similar al siguiente, en el que dc-1 es el DC 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 generando 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 reemplázalos 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 esta etapa, quitaste por completo todas las referencias del DC inactivo del clúster de Cassandra.

APÉNDICE: Quita los nodos DOWN del clúster de Cassandra

Usa este procedimiento cuando reviertas una instalación multirregión y no todos los Pods de Cassandra estén en un estado Up/Normal (UN).

Ejecuta uno de los Pods de Cassandra:

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

Verifica el estado del clúster de Cassandra:

nodetool -u JMX_USER -pw JMX_PASSWORD status

Valida que el nodo esté inactivo (DN). Ejecuta el Pod de Cassandra en una región en la que no se pueda iniciar.

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 abajo (DN). En el ejemplo anterior, quitaremos la referencia del 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

Después de quitar la referencia, finaliza el Pod. Se debería mostrar el nuevo Pod de Cassandra y unirse al clúster.
```
kubectl delete pod -n POD_NAME
```

Valida que el nuevo Pod de Cassandra se haya 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, puedes continuar con la actualización o revertir las regiones restantes del clúster.

APÉNDICE: Solución de problemas: `apigee-datastore` en estado atascado después de la reversión

Usa este procedimiento cuando hayas revertido apigee-datastore a la versión híbrida 1.11 después de la actualización y esté en un estado bloqueado.

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

Valida con el comando Helm que se revirtió el almacén de datos:

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é atascado en el estado de lanzamiento:

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 un 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á a entrar en el estado releasing, pero esta vez creará pods con las imágenes de Hybrid 1.12 que aparecerán, y Cassandra se unirá al clúster y se convertirá en 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 sean Running y que el clúster de Cassandra vuelva a estar en buen estado.

Vuelve a validar que todos los Pods sean READY:

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

kubectl get apigeeds -n APIGEE_NAMESPACE

Por ejemplo:

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

En este punto, corregiste el almacén de datos, que debería estar en un estado running.

Actualiza Apigee Hybrid a la versión 1.12

Cambios de Apigee Hybrid v1.11

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

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

Consideraciones antes de actualizar una instalación multirregional

Requisitos previos

Limitaciones

Descripción general de la actualización a la versión 1.12.3

Prepárate para actualizar a la versión 1.12

Copia de seguridad de Cassandra

Crea una copia de seguridad de los directorios de instalación híbridos

Linux

macOS

Windows

Producción

No producción

Actualiza tu versión de Kubernetes

Haz clic para expandir una lista de plataformas compatibles

Componentes

Acerca de los clústeres adjuntos

Instala el entorno de ejecución híbrido 1.12.3

Prepárate para la actualización de los charts de Helm

Instala los gráficos de Helm de Apigee Hybrid

Revierte a una versión anterior

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

Revierte cuando apigee-datastore esté en buen estado

Restablece cuando apigee-datastore no está en buen estado

Reversión y recuperación multirregionales

Revierte cuando apigee-datastore esté en buen estado

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

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

APÉNDICE: Recupera una región de una actualización con errores

APÉNDICE: Quita los nodos DOWN del clúster de Cassandra

APÉNDICE: Solución de problemas: apigee-datastore en estado atascado después de la reversión

Revierte cuando `apigee-datastore` esté en buen estado

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

Revierte cuando `apigee-datastore` esté en buen estado

Restablece 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` en estado atascado después de la reversión