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

Actualiza Apigee Hybrid a la versión 1.15

Este procedimiento abarca la actualización de la versión 1.14.x de Apigee Hybrid a la versión 1.15.0 de Apigee Hybrid.

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 la versión de parche 1.14.2, Apigee ahora admite cargas útiles de mensajes de hasta 30 MB. Para obtener más información, consulta los siguientes vínculos:
- Configura 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.
Verificaciones más estrictas de la creación de instancias de clases: En Apigee hybrid, la política JavaCallout ahora incluye seguridad adicional durante la creación de instancias de clases de Java. Esta medida de seguridad mejorada evita la implementación de políticas que intentan realizar, de forma directa o indirecta, acciones que requieren permisos no permitidos.
En la mayoría de los casos, las políticas existentes seguirán funcionando como se espera sin problemas. Sin embargo, es posible que se vean afectadas las políticas que dependen de bibliotecas externas o las que tienen código personalizado que activa de forma indirecta operaciones que requieren permisos elevados.

Importante: Este cambio se introdujo en la versión 1.14.1. Si actualizas desde la versión 1.14.0 o una anterior, sigue el procedimiento que se describe en Valida las 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 1.15 de hybrid, asegúrate de que la instalación cumpla con los siguientes requisitos:

Si tu instalación de Hybrid ejecuta una versión anterior a la v1.14, debes actualizar a la versión 1.14 antes de actualizar a la v1.15. Consulta cómo actualizar Apigee híbrido a la versión 1.14.
Versión de Helm v3.14.2+.
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, actualizarás cert-manager en la sección Prepárate para actualizar a la versión 1.15 que aparece a continuación.

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

Apigee Hybrid 1.15.0 presenta un nuevo límite de proxy mejorado por entorno que te permite implementar más proxies y flujos compartidos en un solo entorno. Consulta Límites: Proxies de API para comprender los límites en la cantidad de proxies y flujos compartidos que puedes implementar por entorno. Esta función solo está disponible en las organizaciones híbridas creadas recientemente y no se puede aplicar a las organizaciones actualizadas. Para usar esta función, realiza una instalación nueva de hybrid 1.15.0 y crea una organización nueva.

Esta función está disponible exclusivamente como parte del plan de suscripción de 2024 y está sujeta a los derechos otorgados en virtud de esa suscripción. Consulta Límites de proxy mejorados por entorno para obtener más información sobre esta función.
La actualización a Apigee Hybrid 1.15 puede requerir tiempo de inactividad.

Cuando se actualiza el controlador de Apigee a la versión 1.15.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 que, una vez que comiences la actualización, actualices todos los clústeres lo antes posible para reducir las posibilidades de impacto en la 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, la copia de seguridad y restablecimiento de Cassandra no podrá funcionar con versiones mixtas. Por ejemplo, no se puede usar una copia de seguridad de Hybrid 1.14 para restablecer una instancia de Hybrid 1.15.
No es necesario suspender por completo los cambios del plano de administración durante una actualización. Cualquier suspensión temporal necesaria para los cambios en el plano de administración se indica en las instrucciones de actualización que se incluyen a continuación.

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 la actualización.
Instala la versión 1.15.0 del entorno de ejecución híbrido.

Prepárate para actualizar a la versión 1.15

Haz una copia de seguridad de tu instalación híbrida

En estas instrucciones, se usa la variable de entorno APIGEE_HELM_CHARTS_HOME para el directorio en tu sistema de archivos en el que instalaste los charts de Helm. Si es necesario, cambia el directorio a este directorio y define la variable con el siguiente comando:
Linux
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
macOS
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
Windows
```
set APIGEE_HELM_CHARTS_HOME=%CD%
echo %APIGEE_HELM_CHARTS_HOME%
```
Realiza una copia de seguridad de tu directorio $APIGEE_HELM_CHARTS_HOME/ versión 1.14. 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.14-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
Realiza una copia de seguridad de tu base de datos de Cassandra según las instrucciones que se indican en Copia de seguridad y recuperación de Cassandra.
Importante: A partir de la versión 1.14, las barreras de seguridad incluyen las siguientes verificaciones relacionadas con copias de seguridad que se aplican durante la actualización de Apigee Hybrid.
1. La copia de seguridad debe estar habilitada para admitir la restauración a la versión anterior si es necesario.
2. Si la copia de seguridad de CSI está habilitada, se debe crear una copia de seguridad en las últimas 24 horas previas a la actualización. Esto minimizará la posible pérdida de datos si es necesario restablecer la versión anterior.
Para obtener más información sobre las verificaciones de los parámetros de seguridad, consulta Parámetros de seguridad.

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 la federación de Workload Identity para GKE para autenticar cuentas de servicio.

En la siguiente tabla, se muestra el destino de cada archivo de cuenta de servicio, según el tipo de instalación:

Producción

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

No producción

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

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

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

Actualiza tu versión de Kubernetes

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

Haz clic para expandir 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
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 equipos físicos	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.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.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.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
⁽¹⁾ En la versión 1.13 de Anthos local (Google Distributed Cloud), sigue estas instrucciones para evitar conflictos con `cert-manager`: Instalación de cert-manager en conflicto ⁽²⁾ Se alcanzaron las fechas oficiales de EOL para las versiones 1.12 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. ⁽³⁾ Cloud Service Mesh se instala automáticamente con Apigee Hybrid 1.9 y versiones posteriores. ⁽⁴⁾ Los números de versiones de GKE en AWS ahora reflejan las versiones de Kubernetes. Consulta la compatibilidad con versiones y actualizaciones de GKE Enterprise para obtener detalles de las versiones y parches recomendados. ⁽⁵⁾ Vault no está certificado en Google Distributed Cloud para VMware. ⁽⁶⁾ Compatibilidad disponible con la versión 1.10.5 de Apigee Hybrid y posteriores. ⁽⁷⁾ Compatibilidad disponible con la versión 1.11.2 de Apigee Hybrid y posteriores. ⁽⁸⁾ Compatibilidad disponible con la versión 1.12.1 de Apigee Hybrid y posteriores. ⁽⁹⁾ 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 de webhook no puede renovar automáticamente su certificado de CA. Para evitar esto, Apigee recomienda usar lo siguiente: Hybrid v1.13: Usa la versión 1.15.5 o posterior de cert-manager. Hybrid v1.14: Usa las versiones de cert-manager 1.15.5 o 1.16.3. Hybrid v1.15: Usa las versiones de cert-manager 1.16.3 o 1.17.2 o versiones 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 equipos físicos	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
⁽¹⁾ En la versión 1.13 de Anthos local (Google Distributed Cloud), sigue estas instrucciones para evitar conflictos con `cert-manager`: Instalación de cert-manager en conflicto ⁽²⁾ Se alcanzaron las fechas oficiales de EOL para las versiones 1.12 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. ⁽³⁾ Cloud Service Mesh se instala automáticamente con Apigee Hybrid 1.9 y versiones posteriores. ⁽⁴⁾ Los números de versiones de GKE en AWS ahora reflejan las versiones de Kubernetes. Consulta la compatibilidad con versiones y actualizaciones de GKE Enterprise para obtener detalles de las versiones y parches recomendados. ⁽⁵⁾ Vault no está certificado en Google Distributed Cloud para VMware. ⁽⁶⁾ Compatibilidad disponible con la versión 1.10.5 de Apigee Hybrid y posteriores. ⁽⁷⁾ Compatibilidad disponible con la versión 1.11.2 de Apigee Hybrid y posteriores. ⁽⁸⁾ Compatibilidad disponible con la versión 1.12.1 de Apigee Hybrid y posteriores. ⁽⁹⁾ 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 de webhook no puede renovar automáticamente su certificado de CA. Para evitar esto, Apigee recomienda usar lo siguiente: Hybrid v1.13: Usa la versión 1.15.5 o posterior de cert-manager. Hybrid v1.14: Usa las versiones de cert-manager 1.15.5 o 1.16.3. Hybrid v1.15: Usa las versiones de cert-manager 1.16.3 o 1.17.2 o versiones posteriores.

Cómo quitar los CRD de Istio

La presencia de definiciones de recursos personalizados (CRD) de istio.io en un clúster híbrido de Apigee puede provocar errores en los Pods de apigee-ingressgateway-manager.

Consulta el problema conocido 416634326 para obtener más información sobre las CRD de istio.io en Apigee Hybrid.

Ejecuta el siguiente comando para determinar si tienes CRDs de istio.io en tu clúster:

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

Si tu clúster tiene CRD de istio.io, el resultado se verá 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 CRD de forma local en caso de que necesites volver a crearlos:
```
kubectl get crd $(cat istio-crd.csv) -o yaml > istio-crd.yaml
```
Nota: Si usas Istio en tu clúster para fines ajenos a Apigee, deberás usar la versión 1.22.7-asm.4-distroless.
Borra los CRD de istio.io:
Prueba de validación:
```
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.

Ejecución:
```
kubectl delete crd $(cat istio-crd.csv)
```

Enumera los Pods de ingress-manager que se reinstalarán o volverán a crear:

kubectl get deployments -n apigee

Resultado de 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 ingress-manager:

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

Instala el entorno de ejecución de Hybrid 1.15.0

Configura la canalización de recopilación de datos.

A partir de la versión 1.14 de Hybrid, la nueva canalización de datos de Analytics y depuración está habilitada de forma predeterminada para todas las organizaciones de Apigee Hybrid. Debes seguir los pasos que se indican en cómo habilitar el acceso del publicador a Analytics para configurar el flujo de autorización.

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

Extrae los charts de Helm para Apigee.

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

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

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

export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
export CHART_VERSION=1.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 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.17.2/cert-manager.yaml
```
Consulta Plataformas y versiones compatibles: cert-manager para obtener una lista de las versiones compatibles.

Nota: Algunas versiones de cert-manager tienen un problema por el que el servidor TLS de webhook puede no renovar automáticamente su certificado de CA. Para evitar esto, Apigee recomienda usar las versiones de cert-manager 1.16.3 o 1.17.2 y versiones posteriores.
Si tu espacio de nombres de Apigee no es apigee, edita el archivo apigee-operator/etc/crds/default/kustomization.yaml y reemplaza 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 es necesario que edites el archivo.

Instala las CRD de Apigee actualizadas:

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

Usa la función de ejecución de prueba kubectl mediante la ejecución del siguiente comando:

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

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

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

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

kubectl get crds | grep apigee

La respuesta debería ser similar a la siguiente:

apigeedatastores.apigee.cloud.google.com                    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

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

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

Instala los gráficos de Helm de Apigee Hybrid

Nota: Antes de ejecutar cualquiera de los comandos de actualización o instalación de Helm, usa la función de prueba de validación de Helm; para ello, agrega --dry-run al final del comando. Consulta helm -h para enumerar los comandos, las opciones y el uso compatibles.

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

Actualiza el operador o controlador de Apigee:

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

Prueba de validación:

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

Actualiza el chart:

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

Ejecución de prueba:

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

Actualiza el chart:

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

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

kubectl -n APIGEE_NAMESPACE get apigeedatastore default

NAME      STATE       AGE
default   running    2d

Actualiza la telemetría de Apigee:

Ejecución de prueba:

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

Actualiza el chart:

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

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

kubectl -n APIGEE_NAMESPACE get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Actualiza Apigee Redis:

Ejecución de prueba:

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

Actualiza el chart:

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

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

kubectl -n APIGEE_NAMESPACE get apigeeredis default

NAME      STATE     AGE
default   running   2d

Actualiza el administrador de entrada de Apigee:

Ejecución de prueba:

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

Actualiza el chart:

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

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

kubectl -n APIGEE_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:
Ejecución de prueba:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server
```
Actualiza el chart:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE
```
Para verificar que esté en funcionamiento, comprueba el estado de la organización correspondiente:
```
kubectl -n APIGEE_NAMESPACE get apigeeorg
```
```
NAME                      STATE     AGE
apigee-org1-xxxxx          running   2d
```
Nota: Si el comando de actualización falla con el error Forbidden: state: releasing, los componentes existentes aún están en estado de lanzamiento. Puedes esperar a que se complete la actualización actual y volver a intentarlo. Verifica el estado de la versión con el siguiente comando:
```
kubectl get org -n APIGEE_NAMESPACE
```
Actualiza el entorno.
Debes instalar un entorno a la vez. Especifica el entorno con --set env=ENV_NAME.

Prueba de validación:
```
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 entre los demás nombres de versiones de Helm de tu instalación. Por lo general, es igual a ENV_NAME. Sin embargo, si tu entorno tiene el mismo nombre que tu grupo de entornos, debes usar nombres de versiones diferentes para el entorno y el grupo de entornos, por ejemplo, dev-env-release y dev-envgroup-release. Para obtener más información sobre las versiones en Helm, consulta Three big concepts class="external" en la documentación de Helm.
- ENV_NAME es el nombre del entorno que estás actualizando.
- OVERRIDES_FILE es tu nuevo archivo de anulaciones para v.1.15.0
Actualiza el chart:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Para verificar que esté en funcionamiento, comprueba 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 con el error Forbidden: state: releasing, los componentes existentes aún están en estado de lanzamiento. Puedes esperar a que se complete la actualización actual y volver a intentarlo. Verifica 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 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:
  Prueba de validación:
```
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 se instaló el chart apigee-virtualhost. Por lo general, es 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: ENV_GROUP_RELEASE_NAME debe ser único en el espacio de nombres apigee.
  Por ejemplo, si tienes un entorno llamado prod y un grupo de entornos llamado prod, establece el valor de ENV_GROUP_RELEASE_NAME en algo único, como prod-envgroup.
2. Verifica el estado de ApigeeRouter (AR).
  La instalación de virtualhosts crea ApigeeRouteConfig (ARC), que crea de forma interna ApigeeRoute (AR) una vez que Apigee Watcher extrae detalles relacionados del grupo de entornos desde el plano de control. Por lo tanto, verifica que el estado de AR correspondiente esté en ejecución:
```
kubectl -n APIGEE_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
```
Después de verificar que todas las instalaciones se actualizaron correctamente, borra la versión anterior de apigee-operator del espacio de nombres apigee-system.
1. Desinstala la versión anterior de operator:
```
helm delete operator -n apigee-system
```
2. Borra 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 borrados con alcance de clúster:

helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml

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

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

Verifica si los archivos JAR de Java solicitan permisos innecesarios.
Después de implementar la política, verifica 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 solicitó permisos innecesarios. Para resolver este problema, investiga el código Java y actualiza el archivo JAR.
Investiga y actualiza el código Java.
Revisa cualquier código Java (incluidas las dependencias) para identificar la causa de las operaciones potencialmente no permitidas. Cuando lo encuentres, modifica el código fuente según sea necesario.
Prueba políticas con la verificació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 establecer la marca, haz lo siguiente:
- En el archivo apigee-env/values.yaml, establece conf_security-secure.constructor.only en true en runtime:cwcAppend:. Por ejemplo:
```
# Apigee Runtime
runtime:
  cwcAppend:
    conf_security-secure.constructor.only: true
```
- Actualiza el gráfico apigee-env para el entorno y aplica 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, continúa modificando y probando el archivo JAR hasta que deje de aparecer el mensaje de registro.
Habilita la verificación de seguridad en el entorno de producción.
Después de probar y verificar exhaustivamente el archivo JAR en el entorno que no es de producción, habilita la verificación de seguridad en tu entorno de producción. Para ello, establece la marca conf_security-secure.constructor.only en true y actualiza el gráfico apigee-env para que el entorno de producción aplique el cambio.

Revierte a una versión anterior

Para revertir a la versión anterior, usa la versión anterior del gráfico para revertir el proceso de actualización en orden inverso. Comienza con apigee-virtualhost y vuelve a apigee-operator, y, luego, revierte los CRD.

Nota: Si conoces la última versión de lanzamiento, puedes usar el comando helm rollback en lugar del comando helm upgrade que se describe a continuación.

Revierte todos los gráficos de apigee-virtualhost a apigee-datastore. En los siguientes comandos, se supone que usas 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 para cada entorno:

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

Revierte los gráficos restantes, 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 en el espacio de nombres apigee-system.

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

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

Vuelve a instalar apigee-operator en el espacio de nombres apigee-system.

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

Reinstala las CRD anteriores para revertir las CRD.

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 alcance de clúster, como clusterIssuer, se borran 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
```

Actualiza Apigee Hybrid a la versión 1.15 Organiza tus páginas con colecciones Guarda y categoriza 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

Prepárate para actualizar a la versión 1.15

Haz una copia de seguridad de tu instalación híbrida

Linux

macOS

Windows

Producción

No producción

Actualiza tu versión de Kubernetes

Haz clic para expandir una lista de plataformas compatibles.

Versiones compatibles

Componentes

Versiones no compatibles

Componentes

Cómo quitar los CRD de Istio

Instala el entorno de ejecución de Hybrid 1.15.0

Configura la canalización de recopilación de datos.

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

Instala los gráficos de Helm de Apigee Hybrid

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

Revierte a una versión anterior

Actualiza Apigee Hybrid a la versión 1.15