Actualiza Apigee Hybrid a la versión 1.12

Version 1.12 (latest)

   Versiones compatibles:

• v1.12 (más reciente)                        
• v1.11                         
• v1.10                                        
• Lista de versiones compatibles

   Versiones no compatibles

• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

Este procedimiento abarca la actualización de la versión 1.11.x de Apigee Hybrid a la versión 1.12.0 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 características en v1.12, consulta las notas de la versión híbrida v1.12.0.

• 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 hagas una copia de seguridad de tu base de datos de Cassandra y de tu instalación híbrida antes de la actualización. Si necesitas revertir la actualización, considera 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 apigee-datastore. La instalación v1.11.x seguirá funcionando con una instancia v1.12 de tu apigee-datastore que ejecuta 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 esobsoleto a partir del 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 Baja de Apigeectl.
  Importante: Si administras v1.11 con apigeectl, primero debes migrar tu instalación 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.

• Ahora está disponible un nuevo conjunto de métricas para supervisar los proxies de Apigee y los extremos de destino. 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, configura metrics.disablePrometheusPipeline como true en overrides.yaml.

  Si tienes configuradas alertas basadas en métricas, confirma el uso de 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 tu capacidad de Cassandra y asegúrate de que el uso del disco sea cercano o inferior al 50% antes de comenzar la actualización.
• Valida y prueba los procedimientos de copia de seguridad y restablecimiento de Cassandra.
• Crea una copia de seguridad de los datos de Cassandra en tu instalación de versión híbrida 1.11 antes de comenzar a actualizar y validar tus copias de seguridad.
• La actualización de apigee-datastore generará 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 puedes revertirlo a la versión anterior. 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 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 restablecerlo desde una copia de seguridad v1.11 a una instalación v1.11.
    Nota: No puedes mezclar versiones durante el restablecimiento. 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 deseas actualizar una instalación de una sola región, te recomendamos crear una segunda región y, luego, actualizar solo una región a la vez en la siguiente secuencia:

1. 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.
2. Crea una copia de seguridad y valida los datos de la primera región antes de comenzar una actualización. Consulta la descripción general de la copia de seguridad de Cassandra en la documentación de la versión 1.11.
3. Actualiza la región recién agregada a Hybrid 1.12.
4. Cambia el tráfico a la región nueva y valida el tráfico.
5. Una vez validada, actualiza la región anterior con la versión Hybrid 1.12.
6. Vuelve a cambiar todo el tráfico a la región anterior y valida el tráfico.
7. Quita la región nueva.

Consideraciones antes de actualizar una instalación multirregional

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

1. Crea una copia de seguridad y valida los datos de cada región antes de comenzar la actualización.
2. 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.
3. Valida el tráfico en la región recién actualizada.
4. Actualiza cada región posterior solo después de validar el tráfico en la región anterior.
5. En caso de posible necesidad de revertir una actualización en una implementación multirregional, prepárate para cambiar el tráfico de las regiones con errores, considera agregar suficiente capacidad en la región donde se desviará el tráfico para manejar el tráfico en 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 de Hybrid 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 versión 1.11, debes actualizar a la versión 1.11 antes de actualizar a la versión 1.12. Consulta cómo actualizar Apigee híbrido a la versión 1.11.
• Versión de Helm v3.10+.
• Versión de kubectl 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 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 contenido después de la actualización.

• Las copias de seguridad de Hybrid 1.12 no se pueden restablecer en Hybrid 1.11 y 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. Satisface 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 del almacén de datos una vez que haya finalizado el proceso de actualización del almacén de datos. No puedes revertir un almacén de datos de Cassandra 4.x a un almacén de datos de Cassandra 3.x. Esto requerirá el restablecimiento de tu copia de seguridad más reciente de los datos de Cassandra 3.x (de tu 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.0

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.0, 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.

Nota: No es necesario suspender los cambios del plano de administración durante una actualización. Cualquier suspensión necesaria para los cambios en el plano de administración se incluyen en las instrucciones de actualización.

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

1. Prepárate para la actualización.
   • Copia de seguridad de Cassandra
   • Crea una copia de seguridad de los directorios de instalación híbridos.
2. Instala la versión 1.12.0 del entorno de ejecución híbrido.

Prepárate para actualizar a la versión 1.12

Copia de seguridad de Cassandra

• Realiza 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 comenzar la actualización. Consulta Supervisa 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 comenzar el proceso de actualización, de modo que puedan aparecer los problemas persistentes.

  Para reiniciar y probar los Pods de Cassandra, borra cada Pod de forma individual, uno a la vez y, luego, valida que vuelva a estar en estado de ejecución y que el sondeo de preparación se apruebe:

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

  2. Borra un Pod

     kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME

     :

     Por ejemplo:

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

  3. Para verificar 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 a fin de asegurarte de que no se realicen cambios para que puedas usar la misma configuración a fin de actualizar a la versión 1.12 de Hybrid.
• 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, resuélvelo primero antes de iniciar la actualización.

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

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

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

1. 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%

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

3. 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.
4. 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/

5. 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.9 ^(3)	1.10	1.11	1.12
Anthos (Google Cloud - GKE)	1.23.x 1.24.x 1.25.x 1.26.x ^(≥ 1.9.2)	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
Anthos (AWS)	1.12.x 1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x)	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1.26.x^(13)	1.14.x (K8s v1.25.x) 1.26.x^(13) 1.27.x	1.26.x^(13) 1.27.x 1.28.x
Anthos (Azure)	1.12.x 1.13.x 1.14.x	1.13.x 1.14.x 1.26.x^(13)	1.14.x 1.26.x^(13) 1.27.x	1.26.x^(13) 1.27.x 1.28.x
Anthos (local - VMware) ^(1) ^(14)	1.12.x ^(4) 1.13.x 1.14.x 1.15.x (K8s v1.26.x)	1.13.x 1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x)	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x)	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^(13)
Anthos (Bare Metal)^(1)	1.12.x ^(4) 1.13.x 1.14.x 1.15.x	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.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x)	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^(13)
EKS^(7)	1.23.x 1.24.x 1.25.x 1.26.x	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
AKS^(7)	1.23.x 1.24.x 1.25.x 1.26.x^(≥ 1.9.2)	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
OpenShift^(7)	4.10 4.11	4.11 4.12	4.12 4.13 4.14	4.12 4.13 4.14 4.15
Rancher Kubernetes Engine (RKE)^(7)	1.3.8	v1.26.2+rke2r1	v1.26.2+rke2r1 v1.27.x	v1.26.2+rke2r1 v1.27.x v1.28.x
Componentes	1.9 ^(3)	1.10	1.11	1.12
Anthos Service Mesh (ASM)	1.17.x^(11)	1.17.x^(11)	1.18.x^(11)	1.19.x^(11)
JDK	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.10.x 1.11.x	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	3.11	4.0
Kubernetes	1.23.x 1.24.x 1.25.x	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 las versiones 1.8, 1.9 y 1.10 de Anthos, sigue las instrucciones de estos documentos para evitar conflictos con cert-manager: Anthos 1.8.2+: Conflicto con cert-manager cuando se actualiza a la versión 1.8.2 o superior. Anthos 1.9: Conflicto con cert-manager cuando se actualiza a la versión 1.9.0 o 1.9.1. Anthos 1.10+: Instalación de cert-manager en conflicto. ^(2) Compatibilidad disponible con la versión 1.7.2 de Apigee Hybrid y posteriores.. ^(3) Se alcanzaron las fechas oficiales de EOL para las versiones 1.8 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. ^(4) Las versiones 1.12 y anteriores de Anthos en Bare Metal y VMWare no son compatibles. Consulta la política de asistencia Anthos en Bare Metal y las versiones de clústeres de Anthos en VMware. ^(5)Anthos alojado en Bare Metal y VMWare requiere ASM 1.14 o posterior. Te recomendamos que actualices a la versión híbrida 1.8 y cambies a la puerta de enlace de entrada de Apigee, que ya no requiere que instales ASM en tu clúster híbrido. ^(6) Compatibilidad disponible con la versión 1.8.4 de Apigee Hybrid y posteriores.. ^(7) No se requieren clústeres adjuntos para Apigee Hybrid v1.8 y versiones posteriores con Apigee ingressgateway. ^(8) No es compatible con la versión híbrida 1.8.4 de Apigee y las versiones posteriores. ^(9) Compatibilidad disponible con la versión 1.7.6 de Apigee Hybrid y posteriores.. ^(10) No es compatible con la versión híbrida 1.8.5 de Apigee y las versiones posteriores. ^(11) ASM se instala automáticamente con Apigee Hybrid 1.9 y versiones posteriores. ^(12) Compatibilidad disponible con la versión 1.9.2 de Apigee Hybrid y posteriores.. ^(13) Los números de versiones de clústeres de Anthos en AWS (múltiples nubes) ahora reflejan las versiones de Kubernetes. Consulta la compatibilidad de las versiones y las actualizaciones de Anthos para obtener detalles de las versiones y parches recomendados. ^(14) Vault no está certificado en Anthos (local - VMware).

Acerca de los clústeres adjuntos

Para las versiones de Apigee Hybrid 1.7.x y anteriores, debes usar clústeres adjuntos de Anthos 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 Anthos Service Mesh (ASM). Registrar el clúster de terceros es opcional. Regístrate solo si deseas ver el clúster adjunto en la consola de Google Cloud. Para obtener más información, consulta Conecta clústeres de Kubernetes de terceros a Google Cloud.

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

Nota: En este momento, las instalaciones híbridas no son compatibles con GKE Autopilot.

Instala el entorno de ejecución de Hybrid 1.12.0

Precaución: No crees entornos nuevos durante el proceso de actualización.

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

En este procedimiento de actualización, se supone que usas el mismo espacio de nombres y las mismas cuentas de servicio para la instalación actualizada. Si realizas algún cambio de configuración, asegúrate de reflejar esos cambios en tu archivo de anulaciones antes de instalar los charts de Helm.

1. 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.0
   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
   

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

3. Instala las CRD de Apigee actualizadas:
   Nota: A partir de este paso, todos los comandos se deben ejecutar en el directorio raíz del repositorio del chart.
   Nota: Este es el único método compatible para instalar las CRD de Apigee. No uses kubectl apply sin -k, no omitas --server-side.
   Nota: En este paso, se requieren permisos elevados de clúster.

   1. 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=server
      

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

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

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

1. Si no lo hiciste, navega a tu directorio APIGEE_HELM_CHARTS_HOME. Ejecuta los siguientes comandos desde ese directorio.
2. 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
   

   Nota: Para las instalaciones migradas, 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.0   1.12.0
   

   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
   

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

   Nota: Para las instalaciones migradas, usa lo siguiente:

   helm upgrade datastore apigee-datastore/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --force \
     -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
   

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

   Nota: Para las instalaciones migradas, usa lo siguiente:

   helm upgrade telemetry apigee-telemetry/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --force \
     -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
   

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

   Nota: Para las instalaciones migradas, usa lo siguiente:

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

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

   kubectl -n apigee get apigeeredis default
   

   NAME      STATE     AGE
   default   running   2d
   

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

   Nota: Para las instalaciones migradas, usa lo siguiente:

   helm upgrade ingress-manager apigee-ingress-manager/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --force \
     -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
   

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

   Nota: Para las instalaciones migradas, usa lo siguiente:

   helm upgrade ORG_NAME apigee-org/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --force \
     -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
   

8. 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.0.

   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
   

9. 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:

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --set envgroup=ENV_GROUP_NAME \
        --force \
        -f OVERRIDES_FILE
      

      Nota: ENV_GROUP_NAME debe ser único dentro del espacio de nombres apigee. Por ejemplo, si tienes un entorno y un grupo de entornos prod, debes establecer este nombre en prod-envgroup. El nombre del grupo de entornos posterior debe ser prod.
   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
      

¡Felicitaciones! Actualizaste a la versión 1.12.0 de Apigee Hybrid. Para probar la actualización, llama a un proxy con la instalación nueva. Para ver un ejemplo, consulta el Paso 10: Implementar un proxy de API en la guía de instalación de Apigee Hybrid 1.12.

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. Hay procedimientos para la reversión de una sola región o multirregión 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 v1.12 es retrocompatible con los componentes híbridos v1.11.

Advertencia: No es posible revertir apigee-datastore. La incompatibilidad de datos entre diferentes versiones de la base de datos de Cassandra evita que se revierta a la versión anterior.

Para revertir la instalación de una sola región a la versión 1.11, haz lo siguiente:

1. Antes de comenzar la reversión, valida que todos los Pods estén en un estado de ejecución:

   kubectl get pods -n APIGEE_NAMESPACE

   kubectl get pods -n apigee-system

2. Valida la actualizació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

3. Revierte cada componente excepto apigee-datastore con los siguientes comandos:
   1. 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.
   2. 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.

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

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

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

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

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

   8. 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.0   1.12.0
      

      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
      

   9. Revierte las CRD de Apigee Hybrid:

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

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

5. Valida la actualizació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ó de forma correcta, no puedes revertir apigee-datastore de la versión 1.12 a la versión 1.11. En su lugar, debes restablecer desde una copia de seguridad realizada de una instalación v1.11. Usa la siguiente secuencia para restablecer tu versión anterior.

1. 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.
2. Restablece la región v1.11 (o la instalación nueva) de tu copia de seguridad mediante las instrucciones que se indican en:
   • Copias de seguridad de Cloud Storage Interface (CSI): copia de seguridad y restablecimiento de CSI de Cassandra.
   • Copias de seguridad que no son de CSI: Restablece en una sola región.
3. Verifica el tráfico a la instalación restablecida
4. Opcional: Quita la instalación de la versión 1.12 según las instrucciones que aparecen en Desinstala el entorno de ejecución híbrido.

Reversión y recuperación multirregionales

Revierte cuando apigee-datastore está en buen estado

Nota:> Usa este método de reversión para revertir de una región híbrida actualizada a la versión híbrida anterior. Este método está diseñado para recuperarse de una actualización con errores cuando no se actualizaron todas las regiones todavía.

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 v1.12 es retrocompatible con los componentes híbridos v1.11.

1. Antes de comenzar la reversión, valida que todos los Pods estén en un estado de ejecución:

   kubectl get pods -n APIGEE_NAMESPACE

   kubectl get pods -n apigee-system

2. 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, resuélvelo primero antes de comenzar el proceso de actualización.

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

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

   2. 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 en Quita nodos DOWN del clúster de Cassandra.

3. Navega al directorio en el que se instalaron los charts anteriores de Helm para Apigee Hybrid
4. Cambia el contexto a la región que se actualizó.

   kubectl config use-context UPGRADED_REGION_CONTEXT
       

5. Valida que todos los Pods estén en estado de ejecución:

   kubectl get pods -n APIGEE_NAMESPACE

   kubectl get pods -n apigee-system

6. Usa el comando de helm para asegurarte de que todas las versiones se hayan actualizado a la versión híbrida 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

7. Revierte cada componente excepto apigee-datastore con los siguientes comandos:
   1. 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.
   2. 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.

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

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

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

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

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

   8. 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.0   1.12.0
      

      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
      

   9. Revierte las CRD de Apigee Hybrid:

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

8. Valida la actualizació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 punto, todas las actualizaciones, excepto datastore, se revertiron a la versión anterior.

Importante: En la actualidad, el almacén de datos de Cassandra se actualiza de forma parcial. Te recomendamos que intentes volver a actualizar; para ello, soluciona los problemas que se encontraron durante la actualización anterior y vuelve a intentar el proceso. Si no es posible intentar otra actualización, se recomienda recuperar el almacén de datos con las instrucciones en Recupera una instalación multirregional a una versión anterior.

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

Recupera la región en la que la actualización falló en una actualización multirregional mediante la eliminación de las referencias a ella de las instalaciones de varias regiones. Este método solo es posible cuando hay al menos 1 región publicada en Hybrid 1.11. El almacén de datos v1.12 es compatible con los componentes de v1.11.

Para recuperar regiones con errores a partir de una región en buen estado, sigue estos pasos:

1. 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.
2. 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.

3. Limpia la región con errores según las instrucciones de Recupera una región de una actualización con errores.
4. 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ó de forma correcta, no puedes revertir de la versión 1.12 a la versión 1.11. En su lugar, debes restablecer desde una copia de seguridad realizada de una instalación v1.11. Usa la siguiente secuencia para restablecer tu versión anterior.

Sugerencia: Para minimizar el tiempo de inactividad en las instalaciones multirregionales, Apigee recomienda volver a compilar y restablecer una región a la vez.

1. 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.
2. Restablece la región v1.11 (o la instalación nueva) de tu copia de seguridad mediante las instrucciones que se indican en:
   • Copias de seguridad de Cloud Storage Interface (CSI): copia de seguridad y restablecimiento de CSI de Cassandra.
   • Copias de seguridad que no son de CSI: Restablece en varias regiones.
3. Verifica el tráfico a la instalación restablecida
4. Para las instalaciones multirregionales, vuelve a compilar y restablece la siguiente región. Consulta las instrucciones en Restablece a partir de una copia de seguridad en Restablece en varias regiones.
5. Quita la instalación de la versión 1.12 según las instrucciones en Desinstala el entorno de ejecución híbrido.

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

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

1. Valida el estado del clúster de Cassandra desde una región activa:
   1. Cambia el contexto de kubectl a la región que se quitará:

      kubectl config use-context CONTEXT_OF_LIVE_REGION

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

   3. Ejecuta uno de los Pods de Cassandra:

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

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

   5. Describe el clúster para verificar que solo veas IP de Pods de Cassandra de la región activa y que todos estén en 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]
      

2. Limpia la replicación del espacio de claves de Cassandra:
   1. 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
        

   2. Para validar la configuración de la replicación del espacio de claves de Cassandra, crea un contenedor de cliente mediante las instrucciones que se indican en Crea el contenedor del cliente.
   3. Obtén todos los espacios de claves. Ejecuta el Pod de 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 a lo siguiente, en el que dc-1 es el DC en vivo:

      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)
      

   4. 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.
      Precaución: Usa los siguientes comandos con sumo cuidado.

      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 los espacios 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'};

   5. Valida que todos los espacios de claves se repliquen en la región correcta con el siguiente comando de 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 multirregional y no todos los pods de Cassandra están en un estado Activo / Normal (UN).

1. Ejecuta uno de los Pods de Cassandra:

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

2. Verifica el estado del clúster de Cassandra:

   nodetool -u JMX_USER -pw JMX_PASSWORD status

3. Verifica que el nodo esté inactivo (DN). Ejecuta el Pod de Cassandra en una región en la que el Pod de Cassandra no puede aparecer.

   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
   

4. Quita la referencia al nodo inactivo (DN). En el ejemplo anterior, quitaremos la referencia 10.8.4.4 del host

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

5. Después de quitar la referencia, finaliza el Pod. El nuevo Pod de Cassandra debería aparecer y unirse al clúster

   kubectl delete pod -n POD_NAME

   .
6. 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 Hybrid 1.11 después de la actualización y esté en estado de bloqueo.

1. 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.
   1. Valida con el comando de 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
      

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

   3. Valida que el controlador apigeeds esté atascado en el estado de actualización:

      kubectl get apigeeds -n APIGEE_NAMESPACE

      Por ejemplo:

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

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

2. Actualiza el almacén de datos mediante los gráficos 1.12.
   Nota: El controlador volverá a tener el estado releasing, pero esta vez creará Pods con las imágenes para Hybrid 1.12, que aparecerá 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

3. Valida que todos los Pods sean Running y que el clúster de Cassandra vuelva a estar en buen estado.
   1. Vuelve a validar todos los Pods: 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

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

   3. 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 y debería estar en un estado running.