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

Actualizar Apigee Hybrid a la versión 1.15

En este procedimiento se explica cómo actualizar de Apigee hybrid versión 1.14.x a Apigee hybrid versión 1.15.0.

Cambios de Apigee hybrid v1.14

Ten en cuenta el siguiente cambio:

Compatibilidad con cargas útiles de mensajes grandes: a partir de la versión 1.15 y también en el parche 1.14.2, Apigee ahora admite cargas útiles de mensajes de hasta 30 MB. Para obtener información, consulta:
- Configurar la compatibilidad con cargas útiles de mensajes grandes en Apigee Hybrid
- runtime.resources.limits.memory en la referencia de la propiedad de configuración.
- runtime.resources.requests.memory en la referencia de la propiedad de configuración.
Comprobaciones de instanciación de clases más estrictas: Apigee Hybrid la política JavaCallout ahora incluye seguridad adicional durante la instanciación de clases de Java. Esta medida de seguridad mejorada impide que se implementen políticas que intenten realizar acciones directa o indirectamente que requieran permisos no permitidos.
En la mayoría de los casos, las políticas actuales seguirán funcionando como de costumbre sin ningún problema. Sin embargo, es posible que se vean afectadas las políticas que dependen de bibliotecas de terceros o las que tienen código personalizado que activa indirectamente operaciones que requieren permisos elevados.

Importante: Este cambio se introdujo en la versión 1.14.1. Si vas a actualizar desde la versión 1.14.0 o una anterior, sigue el procedimiento descrito en Validar políticas después de actualizar desde la versión 1.14.0 o una anterior para validar el comportamiento de las políticas.

Para obtener más información sobre las funciones de la versión 1.14 de Hybrid, consulta las notas de la versión 1.14.0 de Apigee Hybrid.

Requisitos previos

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

Si tu instalación híbrida ejecuta una versión anterior a la 1.14, debes actualizar a la versión 1.14 antes de actualizar a la 1.15. Consulta Actualizar Apigee Hybrid a la versión 1.14.
Versión v3.14.2 o posterior de Helm.
kubectl: una versión compatible de kubectl adecuada para la versión de tu plataforma de Kubernetes. Consulta Plataformas y versiones compatibles: kubectl.
cert-manager: una versión compatible de cert-manager. Consulta Plataformas y versiones compatibles: cert-manager. Si es necesario, actualiza cert-manager en la sección Preparar la actualización a la versión 1.15 que aparece más abajo.

Antes de actualizar a la versión 1.15.0: limitaciones y notas importantes

Apigee hybrid 1.15.0 incluye un nuevo límite de proxy por entorno mejorado que te permite implementar más proxies y flujos compartidos en un solo entorno. Consulta Límites: proxies de API para conocer los límites del número de proxies y flujos compartidos que puedes desplegar por entorno. Esta función solo está disponible en las organizaciones híbridas recién creadas y no se puede aplicar a las organizaciones actualizadas. Para usar esta función, realiza una instalación limpia de la versión híbrida 1.15.0 y crea una organización.

Esta función está disponible exclusivamente como parte del plan de suscripción del 2024 y está sujeta a los derechos concedidos en esa suscripción. Consulta Límites de proxy por entorno mejorados para obtener más información sobre esta función.
Es posible que se produzca un tiempo de inactividad al actualizar a la versión 1.15 de Apigee hybrid.

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

Apigee recomienda que, una vez que empiece la actualización, actualice todos los clústeres lo antes posible para reducir las probabilidades de que se produzcan problemas en producción. No hay un límite de tiempo para actualizar todos los clústeres restantes después de que se haya actualizado el primero. Sin embargo, hasta que se actualicen todos los clústeres restantes, la copia de seguridad y la restauración de Cassandra no funcionarán con versiones mixtas. Por ejemplo, una copia de seguridad de Hybrid 1.14 no se puede usar para restaurar una instancia de Hybrid 1.15.
No es necesario suspender por completo los cambios en el plano de gestión durante una actualización. Las suspensiones temporales necesarias para los cambios en el plano de gestión se indican en las instrucciones de actualización que se incluyen más abajo.

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

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

Prepárate para cambiar a un plan superior.
Instala la versión 1.15.0 del entorno de ejecución híbrido.

Prepararse para actualizar a la versión 1.15

Crear una copia de seguridad de la instalación híbrida

En estas instrucciones se usa la variable de entorno APIGEE_HELM_CHARTS_HOME para el directorio del sistema de archivos en el que has instalado los gráficos de Helm. Si es necesario, cambia al directorio y define la variable con el siguiente comando:
Linux
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
macOS
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
Windows
```
set APIGEE_HELM_CHARTS_HOME=%CD%
echo %APIGEE_HELM_CHARTS_HOME%
```
Crea una copia de seguridad del directorio 1.14 $APIGEE_HELM_CHARTS_HOME/. Puedes usar cualquier proceso de copia de seguridad. Por ejemplo, puedes crear un archivo tar de todo tu directorio con el siguiente comando:
```
tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.14-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
Crea una copia de seguridad de tu base de datos de Cassandra siguiendo las instrucciones de Copia de seguridad y recuperación de Cassandra.
Importante: A partir de la versión 1.14, las medidas de protección incluyen las siguientes comprobaciones relacionadas con las copias de seguridad que se aplican durante la actualización de Apigee hybrid.
1. La copia de seguridad debe estar habilitada para poder restaurar la versión anterior si es necesario.
2. Si la copia de seguridad de CSI está habilitada, debe crearse una copia de seguridad en las 24 horas anteriores a la actualización. De esta forma, se minimizará la posible pérdida de datos si es necesario restaurar la versión anterior.
Para obtener más información sobre las comprobaciones de las protecciones, consulta el artículo Protecciones.

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

Este paso no es necesario si utilizas secretos de Kubernetes o la federación de Workload Identity para GKE con el fin de autenticar cuentas de servicio.

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

Producción

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

No producción

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

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

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

Actualizar la versión de Kubernetes

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

Haz clic para desplegar una lista de plataformas compatibles

Versiones compatibles

	1.13	1,14	1,15
GKE en Google Cloud	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x 1.33.x
GKE en AWS	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x	1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x	1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x 1.32.x
GKE en Azure	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x	1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x	1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x 1.32.x
Google Distributed Cloud (solo software) en VMware ⁽⁵⁾	1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x 1.30.x	1.28.x⁽⁴⁾ 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x
Google Distributed Cloud (solo software) en bare metal	1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x 1.30.x	1.28.x⁽⁴⁾ 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x
EKS	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x 1.32.x	1.29.x 1.30.x 1.31.x 1.32.x
AKS	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x
OpenShift⁽⁹⁾	4.12 4.13 4.14 4.15 4.16	4.13 4.14 4.15 4.16 4.17	4.16 4.17 4.18
Rancher Kubernetes Engine (RKE)	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x 1.30.x	v1.27.x 1.28.x 1.29.x 1.30.x 1.31.x	v1.28.x 1.29.x 1.30.x 1.31.x 1.32.x
VMware Tanzu	v1.26.x	v1.26.x	v1.26.x
Componentes	1.13	1,14	1,15
Cloud Service Mesh	1.19.x⁽³⁾	1.22.x⁽³⁾	1.22.x⁽³⁾
JDK	JDK 11	JDK 11	JDK 11
cert-manager	1.15.x⁽¹⁰⁾ 1.16.x⁽¹⁰⁾ 1.17.x⁽¹⁰⁾	1.15.x⁽¹⁰⁾ 1.16.x⁽¹⁰⁾ 1.17.x⁽¹⁰⁾	1.16.x⁽¹⁰⁾ 1.17.x⁽¹⁰⁾
Cassandra	4.0	4.0	4.0
Kubernetes	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x 1.32.x	1.29.x 1.30.x 1.31.x 1.32.x
kubectl	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x 1.32.x	1.29.x 1.30.x 1.31.x 1.32.x
Helm	3.14.2+	3.14.2+	3.14.2+
Controlador de CSI de Secret Store	1.4.6+	1.4.6+	1.4.6+
Vault	1.15.2	1.17.2	1.17.2
^1. En la versión 1.13 de Anthos on-premises (Google Distributed Cloud), sigue estas instrucciones para evitar conflictos con `cert-manager`: Conflicting cert-manager installation ⁽²⁾ Se han alcanzado las fechas oficiales de fin de vida útil de las versiones 1.12 y anteriores de Apigee Hybrid. Los parches mensuales periódicos ya no están disponibles. Estas versiones ya no se admiten oficialmente, excepto para los clientes que tengan excepciones explícitas y oficiales para seguir recibiendo asistencia. Otros clientes deben actualizarse. ⁽³⁾ Cloud Service Mesh se instala automáticamente con Apigee hybrid 1.9 y versiones posteriores. ⁽⁴⁾ Los números de versión de GKE en AWS ahora reflejan las versiones de Kubernetes. Consulta la compatibilidad con versiones y actualizaciones de GKE Enterprise para obtener información sobre las versiones y los parches recomendados. ⁽⁵⁾ Vault no está certificado en Google Distributed Cloud para VMware. ⁽⁶⁾ La asistencia está disponible en la versión 1.10.5 de Apigee Hybrid y en versiones posteriores. ⁽⁷⁾ La asistencia está disponible en la versión 1.11.2 de Apigee Hybrid y en versiones posteriores. ⁽⁸⁾ La asistencia está disponible en la versión 1.12.1 de Apigee Hybrid y en versiones posteriores. ⁽⁹⁾ Apigee Hybrid se prueba y certifica en OpenShift con la versión de Kubernetes incluida en cada versión específica de OCP. ⁽¹⁰⁾ Algunas versiones de cert-manager tienen un problema por el que el servidor TLS del webhook no puede renovar automáticamente su certificado de CA. Para evitarlo, Apigee recomienda usar lo siguiente: Hybrid v1.13: usa la versión 1.15.5+ de cert-manager. Híbrido v1.14: usa versiones de cert-manager 1.15.5 o 1.16.3. Híbrido v1.15: usa las versiones 1.16.3 o 1.17.2 de cert-manager (o posteriores).

Versiones no compatibles

	1,6 ⁽²⁾	1.7 ⁽²⁾	1,8 ⁽²⁾	1.9 ⁽²⁾	1,10 ⁽²⁾	1.11 ⁽²⁾	1.12 ⁽²⁾
GKE en Google Cloud	1.19.x 1.20.x 1.21.x	1.20.x 1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.21.x ^{(≤ 1.8.3)} 1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	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.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
GKE en AWS	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x (K8s v1.23.x) 1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x)	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⁽⁴⁾ 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x (K8s v1.25.x) 1.26.x⁽⁴⁾ 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
GKE en Azure	1.8.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x	1.12.x 1.13.x 1.14.x	1.13.x 1.14.x 1.26.x⁽⁴⁾ 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x 1.26.x⁽⁴⁾ 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
Google Distributed Cloud (solo software) en VMware ⁽⁵⁾	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x 1.10.x 1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x 1.15.x (K8s v1.26.x)	1.12.x 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.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)(8)}
Google Distributed Cloud (solo software) en bare metal	1.7.x 1.8.2+ 1.9.3+ 1.10.x	1.9.x 1.10.x 1.11.x ^{(≥ 1.7.2)} 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x 1.15.x	1.12.x 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.27.x⁽⁴⁾^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)(8)}
EKS	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
AKS	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	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.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
OpenShift⁽⁹⁾	4,6 4,7 4,8	4.7 4.8	4,8 4,9 4,10	4.10 4.11	4.11 4.12 4.14^{(≥ 1.10.5)(6)} 4.15^{(≥ 1.10.5)(6)}	4.12 4.13 4.14 4.15^{(≥ 1.11.2)(7)} 4.16^{(≥ 1.11.2)(7)}	4.12 4.13 4.14 4.15 4.16^{(≥ 1.12.1)(8)}
Rancher Kubernetes Engine (RKE)	N/A	N/A	N/A	1.3.8	v1.26.2+rke2r1 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	v1.26.2+rke2r1 v1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
VMware Tanzu	N/A	N/A	N/A	N/A	N/A	N/A	v1.26.x
Componentes	1,6 ⁽²⁾	1.7 ⁽²⁾	1,8 ⁽²⁾	1.9 ⁽²⁾	1,10 ⁽²⁾	1.11 ⁽²⁾	1,12 ⁽²⁾
Cloud Service Mesh	1.9.x 1.10.x 1.12.x 1.13.x	1.10.x 1.11.x 1.12.x 1.13.x ^{(≥ 1.7.2)} 1.14.x 1.15.x ^{(≥ 1.7.6)}	1.11.x 1.12.x 1.13.x 1.14.x 1.15.x	1.17.x⁽³⁾	1.17.x⁽³⁾	1.17.x^{(v1.11.0 - v1.11.1)}⁽³⁾ 1.18.x^{(≥ 1.11.2)(7)}⁽³⁾	1.18.x⁽³⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.5.4	1.7.x	1.7.x 1.8.x 1.9.x 1.10.x 1.11.x	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	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 1.29.x
kubectl					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 1.29.x
Helm					3.10+	3.10+	3.14.2+
Controlador de CSI de Secret Store						1.3.4+	1.4.1+
Vault						1.13.x	1.15.2
^1. En la versión 1.13 de Anthos on-premises (Google Distributed Cloud), sigue estas instrucciones para evitar conflictos con `cert-manager`: Conflicting cert-manager installation ⁽²⁾ Se han alcanzado las fechas oficiales de fin de vida útil de las versiones 1.12 y anteriores de Apigee Hybrid. Los parches mensuales periódicos ya no están disponibles. Estas versiones ya no se admiten oficialmente, excepto para los clientes que tengan excepciones explícitas y oficiales para seguir recibiendo asistencia. Otros clientes deben actualizarse. ⁽³⁾ Cloud Service Mesh se instala automáticamente con Apigee hybrid 1.9 y versiones posteriores. ⁽⁴⁾ Los números de versión de GKE en AWS ahora reflejan las versiones de Kubernetes. Consulta la compatibilidad con versiones y actualizaciones de GKE Enterprise para obtener información sobre las versiones y los parches recomendados. ⁽⁵⁾ Vault no está certificado en Google Distributed Cloud para VMware. ⁽⁶⁾ La asistencia está disponible en la versión 1.10.5 de Apigee Hybrid y en versiones posteriores. ⁽⁷⁾ La asistencia está disponible en la versión 1.11.2 de Apigee Hybrid y en versiones posteriores. ⁽⁸⁾ La asistencia está disponible en la versión 1.12.1 de Apigee Hybrid y en versiones posteriores. ⁽⁹⁾ Apigee Hybrid se prueba y certifica en OpenShift con la versión de Kubernetes incluida en cada versión específica de OCP. ⁽¹⁰⁾ Algunas versiones de cert-manager tienen un problema por el que el servidor TLS del webhook no puede renovar automáticamente su certificado de CA. Para evitarlo, Apigee recomienda usar lo siguiente: Hybrid v1.13: usa la versión 1.15.5+ de cert-manager. Híbrido v1.14: usa versiones de cert-manager 1.15.5 o 1.16.3. Híbrido v1.15: usa las versiones 1.16.3 o 1.17.2 de cert-manager (o posteriores).

Quitar o actualizar CRDs de Istio

Durante la actualización de versiones de Apigee hybrid 1.14.1 o anteriores, la presencia de istio.io definiciones de recursos personalizados (CRDs) en un clúster de Apigee hybrid puede provocar que las sondas de disponibilidad de los contenedores discovery de los pods apigee-ingressgateway-manager fallen.

Si gateway.networking.k8s.io/v1 está instalado en tu clúster,es posible que apigee-ingressgateway-manager no se pueda actualizar. Por ejemplo, gateway.networking.k8s.io/v1 suele instalarse en clústeres que se ejecutan en Google Distributed Cloud (solo software) en bare metal v1.32 o versiones posteriores.

Hay dos opciones para solucionar estos problemas:

Elimina los istio.io CRDs si no usas Istio para ningún otro propósito que no sea Apigee en tu clúster.
Actualiza el valor de apigee-ingressgateway-manager clusterrole para añadir permisos a istio.io.

Después de cada una de las opciones anteriores, tendrás que reiniciar tus pods apigee-ingressgateway-manager.

Consulta los problemas conocidos 416634326 y 419856132 para obtener más información sobre los CRDs istio.io y gateway.networking.k8s.io/v1 en Apigee Hybrid.

Determina si tienes CRDs istio.io en tu clúster con el siguiente comando:

kubectl get crd -o custom-columns=NAME:metadata.name | grep istio.io

Si tu clúster tiene istio.io CRDs, la salida tendrá un aspecto similar al siguiente:

kubectl get crd -o custom-columns=NAME:metadata.name | grep istio.io
  authorizationpolicies.security.istio.io
  destinationrules.networking.istio.io
  envoyfilters.networking.istio.io
  gateways.networking.istio.io
  peerauthentications.security.istio.io
  proxyconfigs.networking.istio.io
  requestauthentications.security.istio.io
  serviceentries.networking.istio.io
  sidecars.networking.istio.io
  telemetries.telemetry.istio.io
  virtualservices.networking.istio.io
  wasmplugins.extensions.istio.io
  workloadentries.networking.istio.io
  workloadgroups.networking.istio.io

Opcional: Guarda los CRDs de forma local por si necesitas volver a crearlos:
```
kubectl get crd $(cat istio-crd.csv) -o yaml > istio-crd.yaml
```

Eliminar CRDs

Lista los istio.ioCRDs de tu clúster en un archivo CSV:

kubectl get crd -o custom-columns=NAME:metadata.name | grep istio.io > istio-crd.csv

Opcional: Guarda los CRDs de forma local por si necesitas volver a crearlos:
```
kubectl get crd $(cat istio-crd.csv) -o yaml > istio-crd.yaml
```
Elimina los CRDs de istio.io:
Prueba de funcionamiento:
```
kubectl delete crd $(cat istio-crd.csv) --dry-run=client
```
Nota: Puedes usar --dry-run=client o --dry-run=server. Consulta las opciones de kubectl delete para obtener más información.

Ejecutar:
```
kubectl delete crd $(cat istio-crd.csv)
```

Actualizar clusterrole

Obtén el clusterrole apigee-ingressgateway-manager actual:

kubectl get clusterrole apigee-ingressgateway-manager-apigee -o yaml > apigee-ingressgateway-manager-apigee-clusterrole.yaml

Copia el rol de clúster en una nueva ubicación:

cp apigee-ingressgateway-manager-apigee-clusterrole.yaml apigee-ingressgateway-manager-apigee-clusterrole-added-istio-permissions.yaml

Añade los siguientes permisos adicionales al final del archivo:

- apiGroups:
  - gateway.networking.k8s.io
  resources:
  - gatewayclasses
  - gateways
  - grpcroutes
  - httproutes
  - referencegrants
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.istio.io
  resources:
  - sidecars
  - destinationrules
  - gateways
  - virtualservices
  - envoyfilters
  - workloadentries
  - serviceentries
  - workloadgroups
  - proxyconfigs
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - security.istio.io
  resources:
  - peerauthentications
  - authorizationpolicies
  - requestauthentications
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - telemetry.istio.io
  resources:
  - telemetries
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - extensions.istio.io
  resources:
  - wasmplugins
  verbs:
  - get
  - list
  - watch

Aplica el rol:

kubectl -n APIGEE_NAMESPACE apply -f apigee-ingressgateway-manager-apigee-clusterrole-added-istio-permissions.yaml

Una vez que hayas completado las opciones anteriores, tendrás que reiniciar tus pods apigee-ingressgateway-manager.

Lista los pods ingress-manager que quieras reinstalar o volver a crear:

kubectl get deployments -n APIGEE_NAMESPACE

Ejemplo:

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

Reinicia los pods del ingress-manager:

kubectl rollout restart deployment -n APIGEE_NAMESPACE apigee-ingressgateway-manager

Después de unos minutos, monitoriza los apigee-ingressgateway-manager pods:

watch -n 10 kubectl -n APIGEE_NAMESPACE get pods -l app=apigee-ingressgateway-manager

Ejemplo:

NAME                                             READY   STATUS    RESTARTS   AGE
apigee-ingressgateway-manager-12345abcde-678wx   3/3     Running   0          10m
apigee-ingressgateway-manager-12345abcde-901yz   3/3     Running   0          10m

Instalar el entorno de ejecución híbrido 1.15.0

Configura la canalización de recogida de datos.

A partir de la versión híbrida 1.14, la nueva canalización de datos de analíticas y depuración está habilitada de forma predeterminada en todas las organizaciones híbridas de Apigee. Debe seguir los pasos que se indican en Habilitar el acceso de editores a Analytics para configurar el flujo de autorización.

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

Extrae los gráficos de Helm de Apigee.

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

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

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

export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
export CHART_VERSION=1.15.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

Actualiza cert-manager si es necesario.
Si necesitas actualizar la versión de cert-manager, instala la nueva con el siguiente comando:
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.17.2/cert-manager.yaml
```
Consulta la lista de versiones admitidas en Plataformas y versiones compatibles: cert-manager.

Nota: Algunas versiones de cert-manager tienen un problema por el que el servidor TLS del webhook no puede renovar automáticamente su certificado de AC. Para evitarlo, Apigee recomienda usar las versiones 1.16.3 o 1.17.2 de cert-manager o versiones posteriores.
Si tu espacio de nombres de Apigee no es apigee, edita el archivo apigee-operator/etc/crds/default/kustomization.yaml y sustituye el valor namespace por tu espacio de nombres de Apigee.
```
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: APIGEE_NAMESPACE
```
Si usas apigee como espacio de nombres, no tienes que editar el archivo.

Instala los CRDs de Apigee actualizados:

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

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

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

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

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

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

kubectl get crds | grep apigee

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

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

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

Para obtener más información, consulta Configurar grupos de nodos dedicados.

Instalar los gráficos de Helm de Apigee Hybrid

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

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

Actualiza el operador o el controlador de Apigee:

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

Prueba de funcionamiento:

helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Actualiza el gráfico:

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

Verifica la instalación del operador de Apigee:

helm ls -n APIGEE_NAMESPACE

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee   3          2024-08-21 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.15.0   1.15.0

Para comprobar que funciona correctamente, consulta su disponibilidad:

kubectl -n APIGEE_NAMESPACE get deploy apigee-controller-manager

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

Actualiza el almacén de datos de Apigee:

Prueba de funcionamiento:

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

Actualiza el gráfico:

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

Verifica que apigeedatastore esté en funcionamiento comprobando su estado:

kubectl -n APIGEE_NAMESPACE get apigeedatastore default

NAME      STATE       AGE
default   running    2d

Actualiza la telemetría de Apigee:

Prueba de funcionamiento:

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

Actualiza el gráfico:

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

Para comprobar que funciona correctamente, consulta su estado:

kubectl -n APIGEE_NAMESPACE get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Actualiza Apigee Redis:

Prueba de funcionamiento:

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

Actualiza el gráfico:

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

Para comprobar que funciona correctamente, consulta su estado:

kubectl -n APIGEE_NAMESPACE get apigeeredis default

NAME      STATE     AGE
default   running   2d

Actualiza el gestor de entrada de Apigee:

Prueba de funcionamiento:

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

Actualiza el gráfico:

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

Para comprobar que funciona correctamente, consulta su disponibilidad:

kubectl -n APIGEE_NAMESPACE get deployment apigee-ingressgateway-manager

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

Actualiza la organización de Apigee:
Prueba de funcionamiento:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server
```
Actualiza el gráfico:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE
```
Comprueba que está en funcionamiento consultando el estado de la organización correspondiente:
```
kubectl -n APIGEE_NAMESPACE get apigeeorg
```
```
NAME                      STATE     AGE
apigee-org1-xxxxx          running   2d
```
Nota: Si el comando de actualización falla y muestra el error Forbidden: state: releasing, los componentes siguen en estado de lanzamiento. Puedes esperar a que se complete la actualización actual y, después, volver a intentarlo. Consulta el estado de la versión con el siguiente comando:
```
kubectl get org -n APIGEE_NAMESPACE
```
Actualiza el entorno.
Debes instalar un entorno cada vez. Especifica el entorno con --set env=ENV_NAME.

Prueba de funcionamiento:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run=server
```
- ENV_RELEASE_NAME es un nombre que se usa para hacer un seguimiento de la instalación y las actualizaciones del gráfico apigee-env. Este nombre debe ser único y diferente de los demás nombres de lanzamientos de Helm de tu instalación. Normalmente, es la misma que ENV_NAME. Sin embargo, si tu entorno tiene el mismo nombre que tu grupo de entornos, debes usar nombres de lanzamiento diferentes para el entorno y el grupo de entornos, como dev-env-release y dev-envgroup-release. Para obtener más información sobre las versiones de Helm, consulta el artículo Tres conceptos importantes class="external" de la documentación de Helm.
- ENV_NAME es el nombre del entorno que vas a actualizar.
- OVERRIDES_FILE es el nuevo archivo de anulaciones para la versión 1.15.0.
Actualiza el gráfico:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Para comprobar que está en funcionamiento, consulta el estado del entorno correspondiente:
```
kubectl -n APIGEE_NAMESPACE get apigeeenv
```
```
NAME                          STATE       AGE   GATEWAYTYPE
apigee-org1-dev-xxx            running     2d
```

Nota: Si el comando de actualización falla y muestra el error Forbidden: state: releasing, los componentes siguen en estado de lanzamiento. Puedes esperar a que se complete la actualización actual y, después, volver a intentarlo. Consulta el estado de la versión con el siguiente comando:

kubectl get env -n APIGEE_NAMESPACE

Actualiza los grupos de entornos (virtualhosts).
1. Debes actualizar los grupos de entornos (hosts virtuales) de uno en uno. Especifica el grupo de entornos con --set envgroup=ENV_GROUP_NAME. Repite los siguientes comandos para cada grupo de entornos mencionado en el archivo overrides.yaml:
  Prueba de funcionamiento:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE \
  --dry-run=server
```
  ENV_GROUP_RELEASE_NAME es el nombre con el que instalaste el gráfico apigee-virtualhost. Suele ser ENV_GROUP_NAME.
  
  Actualiza el gráfico:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE
```
  Nota: ENV_GROUP_RELEASE_NAME debe ser único en el espacio de nombres apigee.
  Por ejemplo, si tiene un entorno llamado prod y un grupo de entornos llamado prod, asigne a ENV_GROUP_RELEASE_NAME un valor único, como prod-envgroup.
2. Comprueba el estado de ApigeeRoute (AR).
  Al instalar virtualhosts se crea ApigeeRouteConfig (ARC), que a su vez crea ApigeeRoute (AR) una vez que el watcher de Apigee extrae los detalles relacionados con el grupo de entornos del plano de control. Por lo tanto, comprueba que el estado de la AR correspondiente sea "running":
```
kubectl -n APIGEE_NAMESPACE get arc
```
```
NAME                                STATE   AGE
apigee-org1-dev-egroup                       2d
```
```
kubectl -n APIGEE_NAMESPACE get ar
```
```
NAME                                        STATE     AGE
apigee-org1-dev-egroup-xxxxxx                running   2d
```
Una vez que hayas verificado que todas las instalaciones se han actualizado correctamente, elimina la versión anterior de apigee-operator del espacio de nombres apigee-system.
1. Desinstala la versión antigua de operator:
```
helm delete operator -n apigee-system
```
2. Elimina el espacio de nombres apigee-system:
```
kubectl delete namespace apigee-system
```
Vuelve a actualizar operator en tu espacio de nombres de Apigee para reinstalar los recursos con permisos de clúster eliminados:
```
helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml
```

Validar las políticas después de actualizar desde la versión 1.14.0 o una anterior

Sigue este procedimiento para validar el comportamiento de la política JavaCallout después de actualizar de la versión 1.14.0.

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

Restaurar una versión anterior

Para volver a la versión anterior, usa la versión anterior del gráfico para revertir el proceso de actualización en orden inverso. Empieza por apigee-virtualhost y vuelve a apigee-operator. Después, revierte los CRDs.

Nota: Si conoces la última versión, puedes usar el comando helm rollback en lugar del comando helm upgrade que se describe más abajo.

Restablece todos los gráficos de apigee-virtualhost a apigee-datastore. En los siguientes comandos se da por hecho que estás usando los gráficos de la versión anterior (v1.14.x).

Ejecuta el siguiente comando para cada grupo de entornos:

helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f 1.14_OVERRIDES_FILE

Ejecuta el siguiente comando en cada entorno:

helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --atomic \
  --set env=ENV_NAME \
  -f 1.14_OVERRIDES_FILE

Revierte el resto de los gráficos, excepto apigee-operator.

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.14_OVERRIDES_FILE

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.14_OVERRIDES_FILE

helm upgrade redis apigee-redis/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.14_OVERRIDES_FILE

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.14_OVERRIDES_FILE

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.14_OVERRIDES_FILE

Crea el espacio de nombres apigee-system.
```
kubectl create namespace apigee-system
```

Aplica un parche a la anotación del recurso para volver al espacio de nombres apigee-system.

kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-namespace='apigee-system'

Si también has cambiado el nombre de lanzamiento, actualiza la anotación con el nombre de lanzamiento operator.
```
kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-name='operator'
```

Instala apigee-operator de nuevo en el espacio de nombres apigee-system.

helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.14_OVERRIDES_FILE

Revierta los CRDs reinstalando los CRDs anteriores.

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

Limpia la versión apigee-operator del espacio de nombres APIGEE_NAMESPACE para completar el proceso de reversión.
```
helm uninstall operator -n APIGEE_NAMESPACE
```
Algunos recursos con ámbito de clúster, como clusterIssuer, se eliminan cuando se desinstala operator. Vuelve a instalarlos con el siguiente comando:
```
helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.14_OVERRIDES_FILE
```

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

Cambios de Apigee hybrid v1.14

Requisitos previos

Antes de actualizar a la versión 1.15.0: limitaciones y notas importantes

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

Prepararse para actualizar a la versión 1.15

Crear una copia de seguridad de la instalación híbrida

Linux

macOS

Windows

Producción

No producción

Actualizar la versión de Kubernetes

Haz clic para desplegar una lista de plataformas compatibles

Versiones compatibles

Componentes

Versiones no compatibles

Componentes

Quitar o actualizar CRDs de Istio

Eliminar CRDs

Actualizar clusterrole

Instalar el entorno de ejecución híbrido 1.15.0

Configura la canalización de recogida de datos.

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

Instalar los gráficos de Helm de Apigee Hybrid

Validar las políticas después de actualizar desde la versión 1.14.0 o una anterior

Restaurar una versión anterior

Actualizar Apigee Hybrid a la versión 1.15