Actualiza Apigee Hybrid a la versión 1.16

Version 1.16 (latest)

   Versiones compatibles:

• v1.16 (más reciente)                        
• v1.15                         
• v1.14                        
• Lista de versiones compatibles

   Versiones no compatibles

• v1.13                         
• v1.12                         
• v1.11                         
• v1.10                                      
• 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.15.x de Apigee Hybrid a la versión 1.16.0 de Apigee Hybrid.

Cambios de Apigee Hybrid v1.15

Ten en cuenta los siguientes cambios:

• Perfiles de Seccomp: A partir de la versión 1.16, Apigee hybrid ahora ofrece la capacidad de aplicar perfiles de Seccomp a tus componentes del entorno de ejecución, lo que mejora significativamente la postura de seguridad de tu implementación. Esta función permite que los administradores y los equipos de seguridad de Apigee restrinjan las llamadas al sistema que un proceso en contenedores puede realizar al kernel del host. Si limitas un contenedor solo a las llamadas al sistema necesarias, puedes hacer lo siguiente:
  • Mejora la seguridad: Mitiga el riesgo de escape del contenedor y elevación de privilegios.
  • Aplica el principio de privilegio mínimo: Asegúrate de que los componentes solo tengan acceso a las llamadas al sistema exactas que se requieren para su funcionamiento.
  • Cumplimiento: Proporciona un control fundamental para cumplir con los requisitos estrictos de cumplimiento de la seguridad.
  Para obtener más información, consulta Configura perfiles de Seccomp para la seguridad de pods.
• Eliminación de UDCA en Apigee Hybrid: En la versión 1.16 de Apigee Hybrid, se quitó el componente de Unified Data Collection Agent (UDCA). Las responsabilidades de enviar datos de análisis, seguimiento y estado de implementación al plano de control de Apigee ahora se manejan con una canalización de datos basada en Google Cloud Pub/Sub. El uso de la canalización de datos basada en Pub/Sub ha sido el mecanismo de recopilación de datos predeterminado desde la versión 1.14.0 de Apigee Hybrid.
• Cuenta de servicio de apigee-guardrails: En la versión 1.16.0, Apigee Hybrid introduce una cuenta de servicio de apigee-guardrails de Google IAM. El gráfico apigee-operator lo usa durante la instalación para verificar que todas las APIs necesarias estén habilitadas en tu proyecto.

  Consulta los siguientes vínculos:

  • Diagnostica problemas con las barreras de seguridad
  • Acerca de las cuentas de servicio: apigee-guardrails
  • create-service-account
  • Instalación, Parte 2: Paso 4: Crea cuentas de servicio
  • Instalación, Parte 2, Paso 5: Configura la autenticación de la cuenta de servicio
• Compatibilidad con las versiones 1.18 y 1.19 de cert-manager: Apigee Hybrid v1.16 admite las versiones 1.18 y 1.19 de cert-manager. En la versión 1.18 de cert-manager, se modificó el valor predeterminado de Certificate.Spec.PrivateKey.rotationPolicy, lo que puede afectar el tráfico. Si estás actualizando desde una versión anterior de Apigee Hybrid a la versión 1.18 o posterior de cert-manager, sigue el procedimiento para actualizar cert-manager que se describe en esta guía.
  Nota: Esto no afecta las instalaciones nuevas de Apigee hybrid v1.6.

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

Requisitos previos

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

• Si tu instalación de Hybrid ejecuta una versión anterior a la v1.15, debes actualizar a la versión 1.15 antes de actualizar a la v1.16. Consulta cómo actualizar Apigee híbrido a la versión 1.15.
• 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.16 que aparece a continuación.

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

• Apigee Hybrid 1.16.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.16.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.16 puede requerir tiempo de inactividad.

  Cuando se actualiza el controlador de Apigee a la versión 1.16.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.15 para restablecer una instancia de Hybrid 1.16.

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

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

1. Prepárate para la actualización.
2. Instala la versión 1.16.0 del entorno de ejecución híbrido.

Prepárate para actualizar a la versión 1.16

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

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.15. 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.15-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. 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.15 y Hybrid 1.16. Si necesitas ayuda, sigue la documentación de la plataforma.

Haz clic para expandir una lista de plataformas compatibles.

Versiones compatibles

	1.14	1.15	1.16
GKE en Google Cloud	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	1.31.x 1.32.x 1.33.x
GKE en AWS	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	1.31.x 1.32.x 1.33.x
GKE en Azure	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	1.31.x 1.32.x 1.33.x
Google Distributed Cloud (software only) on VMware ^(3)	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	1.31.x 1.32.x 1.33.x
Google Distributed Cloud (solo software) en equipos físicos	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	1.31.x 1.32.x 1.33.x
EKS	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 1.33.x	1.31.x 1.32.x 1.33.x
AKS	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	1.31.x 1.32.x 1.33.x
OpenShift^(7)	4.13 4.14 4.15 4.16 4.17	4.16 4.17 4.18	4.18 4.19 4.20
Rancher Kubernetes Engine (RKE)	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 1.33.x	1.31.x 1.32.x 1.33.x
VMware Tanzu	v1.26.x	v1.26.x	v1.26.x
Componentes	1.14	1.15	1.16
Cloud Service Mesh	1.22.x^(2)	1.22.x^(2)	1.22.x^(2)
JDK	JDK 11	JDK 11	JDK 11
cert-manager	1.15.x^(8) 1.16.x^(8) 1.17.x^(8)	1.16.x^(8) 1.17.x^(8)	1.16.x^(8) 1.17.x^(8) 1.18.x^(9) 1.19.x^(9)
Cassandra	4.0	4.0	4.0
Kubernetes	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 1.33.x	1.30.x 1.31.x 1.32.x 1.33.x
kubectl	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 1.33.x	1.30.x 1.31.x 1.32.x 1.33.x
Helm	3.14.2 a 3.x.x	3.14.2 a 3.x.x	3.17.0 a 3.x.x
Controlador de CSI de Secret Store	1.4.6+	1.4.6+	1.4.6+
Vault	1.17.2	1.17.2	1.17.2
^(1) Se alcanzaron las fechas oficiales de EOL para las versiones 1.13 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. ^(2) Cloud Service Mesh se instala automáticamente con Apigee Hybrid 1.9 y versiones posteriores. ^(3) Vault no está certificado en Google Distributed Cloud para VMware. ^(4) Compatibilidad disponible con la versión 1.10.5 de Apigee Hybrid y posteriores. ^(5) Compatibilidad disponible con la versión 1.11.2 de Apigee Hybrid y posteriores. ^(6) Compatibilidad disponible con la versión 1.12.1 de Apigee Hybrid y posteriores. ^(7) Apigee Hybrid se prueba y certifica en OpenShift con la versión de Kubernetes incluida en cada versión específica de OCP. ^(8) 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 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 o versiones posteriores. Hybrid v1.15: Usa las versiones de cert-manager 1.16.3 o 1.17.2 o versiones posteriores. Híbrido v1.16: Usa las versiones de cert-manager 1.16.3+, 1.17.2+, 1.18.0+ o 1.19.0+. Consulta el problema conocido 465834046 para las versiones 1.18 y 1.19 de cert-manager. ^(9) La versión 1.18 de cert-manager introduce un cambio en la política predeterminada de rotación de claves privadas que puede causar interrupciones del tráfico. Consulta el problema conocido 465834046 para obtener una solución alternativa.

Nota: En este momento, las instalaciones híbridas no son compatibles con los clústeres de Autopilot.

Versiones no compatibles

	1.6 ^(1)	1.7 ^(1)	1.8 ^(1)	1.9 ^(1)	1.10 ^(1)	1.11 ^(1)	1.12 ^(1)	1.13 ^(1)
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)	1.27.x 1.28.x 1.29.x 1.30.x
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^(3) 1.27.x^(≥ 1.10.5)(6) 1.28.x^(≥ 1.10.5)(6)	1.14.x (K8s v1.25.x) 1.26.x^(3) 1.27.x 1.28.x^(≥ 1.11.2)(7) 1.29.x^(≥ 1.11.2)(7)	1.26.x^(3) 1.27.x 1.28.x 1.29.x^(≥ 1.12.1)(8)	1.27.x 1.28.x 1.29.x^(≥ 1.12.1)(8) 1.30.x
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^(3) 1.27.x^(≥ 1.10.5)(6) 1.28.x^(≥ 1.10.5)(6)	1.14.x 1.26.x^(3) 1.27.x 1.28.x^(≥ 1.11.2)(7) 1.29.x^(≥ 1.11.2)(7)	1.26.x^(3) 1.27.x 1.28.x 1.29.x^(≥ 1.12.1)(8)	1.27.x 1.28.x 1.29.x^(≥ 1.12.1)(8) 1.30.x
Google Distributed Cloud (software only) on VMware ^(3)	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x 1.10.x 1.11.x ^(3) ^(≥ 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)	1.16.x (K8s v1.27.x) 1.28.x 1.29.x 1.30.x
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)	1.16.x (K8s v1.27.x) 1.28.x 1.29.x 1.30.x
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)	1.27.x 1.28.x 1.29.x 1.30.x
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)	1.27.x 1.28.x 1.29.x 1.30.x
OpenShift^(7)	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)	4.12 4.13 4.14 4.15 4.16
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)	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x 1.30.x
VMware Tanzu	N/A	N/A	N/A	N/A	N/A	N/A	v1.26.x	v1.26.x
Componentes	1.6 ^(1)	1.7 ^(1)	1.8 ^(1)	1.9 ^(1)	1.10 ^(1)	1.11 ^(1)	1.12 ^(1)	1.13 ^(1)
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^(2)	1.17.x^(2)	1.17.x^(v1.11.0 - v1.11.1)^(2) 1.18.x^(≥ 1.11.2)(7)^(2)	1.18.x^(2)	1.19.x^(2)
JDK	JDK 11	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	1.15.x^(8) 1.16.x^(8) 1.17.x^(8)
Cassandra	3.11	3.11	3.11	3.11	3.11	3.11	4.0	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	1.27.x 1.28.x 1.29.x 1.30.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	1.27.x 1.28.x 1.29.x 1.30.x
Helm					3.10+	3.10+	3.14.2 a 3.x.x	3.14.2 a 3.x.x
Controlador de CSI de Secret Store						1.3.4+	1.4.1+	1.4.6+
Vault						1.13.x	1.15.2	1.15.2
^(1) Se alcanzaron las fechas oficiales de EOL para las versiones 1.13 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. ^(2) Cloud Service Mesh se instala automáticamente con Apigee Hybrid 1.9 y versiones posteriores. ^(3) Vault no está certificado en Google Distributed Cloud para VMware. ^(4) Compatibilidad disponible con la versión 1.10.5 de Apigee Hybrid y posteriores. ^(5) Compatibilidad disponible con la versión 1.11.2 de Apigee Hybrid y posteriores. ^(6) Compatibilidad disponible con la versión 1.12.1 de Apigee Hybrid y posteriores. ^(7) Apigee Hybrid se prueba y certifica en OpenShift con la versión de Kubernetes incluida en cada versión específica de OCP. ^(8) 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 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 o versiones posteriores. Hybrid v1.15: Usa las versiones de cert-manager 1.16.3 o 1.17.2 o versiones posteriores. Híbrido v1.16: Usa las versiones de cert-manager 1.16.3+, 1.17.2+, 1.18.0+ o 1.19.0+. Consulta el problema conocido 465834046 para las versiones 1.18 y 1.19 de cert-manager. ^(9) La versión 1.18 de cert-manager introduce un cambio en la política predeterminada de rotación de claves privadas que puede causar interrupciones del tráfico. Consulta el problema conocido 465834046 para obtener una solución alternativa.

Nota: En este momento, las instalaciones híbridas no son compatibles con los clústeres de Autopilot.

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

Edita kustomization.yaml para un espacio de nombres de Apigee personalizado

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

Configura la cuenta de servicio apigee-guardrails

A partir de la versión 1.16 híbrida, se requiere la cuenta de servicio apigee-guardrails para actualizar el gráfico apigee-operator.

En el siguiente procedimiento, selecciona el tipo de autenticación de cuenta de servicio que usas.

1. Verifica que puedas ejecutar create-service-account. Si acabas de descargar los gráficos, es posible que el archivo create-service-account no esté en un modo ejecutable. En tu directorio APIGEE_HELM_CHARTS_HOME, ejecuta el siguiente comando:

   ./apigee-operator/etc/tools/create-service-account --help

   Si el resultado indica permission denied, debes hacer que el archivo sea ejecutable, por ejemplo, con chmod en Linux, MacOS o UNIX, o en Windows Explorer o con el comando icacls en Windows. Por ejemplo:

   chmod +x ./apigee-operator/etc/tools/create-service-account

2. Crea la cuenta de servicio apigee-guardrails:

   Secretos de Kubernetes

   ./apigee-operator/etc/tools/create-service-account \
     --env prod \
     --profile apigee-guardrails \
     --dir service-accounts

   Con este comando, se crea la cuenta de servicio apigee-guardrails y se descarga la clave en el directorio service-accounts/.

   Archivos JSON

   ./apigee-operator/etc/tools/create-service-account \
     --env prod \
     --profile apigee-guardrails \
     --dir ./apigee-operator/

   Con este comando, se crea la cuenta de servicio apigee-guardrails y se descarga la clave en el directorio del gráfico apigee-operator/.

   Vault

   ./apigee-operator/etc/tools/create-service-account \
     --env prod \
     --profile apigee-guardrails \
     --dir service-accounts

   Con este comando, se crea la cuenta de servicio apigee-guardrails y se descarga la clave en el directorio service-accounts/.

   WIF para GKE

   ./apigee-operator/etc/tools/create-service-account \
     --env prod \
     --profile apigee-guardrails \
     --dir service-accounts

   Con este comando, se crea la cuenta de servicio apigee-guardrails y se descarga la clave en el directorio apigee-operator/etc/tools/service-accounts/. No necesitas el archivo de claves descargado y puedes borrarlo.

   WIF en otras plataformas

   ./apigee-operator/etc/tools/create-service-account \
     --env prod \
     --profile apigee-guardrails \
     --dir service-accounts

   Con este comando, se crea la cuenta de servicio apigee-guardrails y se descarga la clave en el directorio service-accounts/.

3. Configura la autenticación para la cuenta de servicio apigee-guardrails:

   Secretos de Kubernetes

   Crea el secreto de Kubernetes con el archivo de claves de la cuenta de servicio apigee-guardrails en el directorio service-accounts/:

   kubectl create secret generic apigee-guardrails-svc-account \
       --from-file="client_secret.json=$APIGEE_HELM_CHARTS_HOME/service-accounts/$PROJECT_ID-apigee-guardrails.json" \
       -n $APIGEE_NAMESPACE

   Agrega lo siguiente a tu archivo overrides.yaml:

   guardrails:
     serviceAccountRef: apigee-guardrails-svc-account

   Archivos JSON

   Agrega lo siguiente a tu archivo overrides.yaml, usando la ruta de acceso al archivo de claves de la cuenta de servicio apigee-guardrails en el directorio apigee-operator/:

   guardrails:
     serviceAccountPath: $PROJECT_ID-apigee-guardrails.json

   Vault

   1. Actualiza el secreto de Vault secret/data/apigee/orgsakeys para agregar una entrada guardrails con el contenido del archivo de claves de la cuenta de servicio apigee-guardrails.

      vault kv patch secret/apigee/orgsakeys guardrails="$(cat ./service-accounts/hybrid115-apigee-guardrails.json)"
      

   2. La cuenta de servicio de Kubernetes (KSA) para los rieles de protección se llama apigee-operator-guardrails-sa. Agrega la KSA de Guardrails a las cuentas de servicio específicas de la organización vinculadas al rol apigee-orgsakeys en Vault.
      1. Obtén la lista actual de vinculaciones de KSA:

         vault read auth/kubernetes/role/apigee-orgsakeys
         

         El resultado debería tener el siguiente formato:

         Key                                         Value
         ---                                         -----
         alias_name_source                           serviceaccount_uid
         bound_service_account_names                 BOUND_SERVICE_ACCOUNT_NAMES
         bound_service_account_namespace_selector    n/a
         bound_service_account_namespaces            APIGEE_NAMESPACE

         En el resultado, BOUND_SERVICE_ACCOUNT_NAMES es una lista de nombres de cuentas de servicio separados por comas. Agrega apigee-operator-guardrails-sa a la lista de nombres, por ejemplo (sin los saltos de línea agregados para facilitar la lectura):

         apigee-manager,apigee-cassandra-default,apigee-cassandra-backup-sa,
         apigee-cassandra-restore-sa,apigee-cassandra-schema-setup-myhybrido
         rg-5b044c1,apigee-cassandra-schema-val-myhybridorg-5b044c1,apigee-c
         assandra-user-setup-myhybridorg-5b044c1,apigee-mart-myhybridorg-5b0
         44c1,apigee-mint-task-scheduler-myhybridorg-5b044c1,apigee-connect-
         agent-myhybridorg-5b044c1,apigee-watcher-myhybridorg-5b044c1,apigee
         -metrics-apigee-telemetry,apigee-open-telemetry,apigee-synchronizer
         -myhybridorg-dev-ee52aca,apigee-runtime-telemetry-collector-apigee-
         telemetry,apigee-logger-apigee-e-myhybrridorg-dev-ee52aca,apigee-sy
         nchronizer-myhybridog-prod-2d0221c,apigee-runtime-myhybridorg-prod-
         2d0221c,apigee-operator-guardrails-sa

      2. Actualiza las vinculaciones al rol apigee-orgsakeys con la lista actualizada de nombres de cuentas de servicio:

         vault write auth/kubernetes/role/apigee-orgsakeys \
           bound_service_account_names=UPDATED_BOUND_SERVICE_ACCOUNT_NAMES \
           bound_service_account_namespaces=APIGEE_NAMESPACE \
           policies=apigee-orgsakeys-auth \
           ttl=1m
         

   3. Agregar "protecciones" a SecretProviderClass
      1. Edita tu archivo spc-org.yaml.
         Sugerencia: Si necesitas volver a crearla, usa la plantilla que se encuentra en Almacena claves de cuentas de servicio en Hashicorp Vault: Crea objetos SecretProviderClass.
      2. En spec.parameters.objects, agrega una entrada de limitaciones:

               - objectName: "guardrails"
                 secretPath: ""
                 secretKey: ""

         Sugerencia: Para entornos basados en secuencias de comandos o para automatizar este cambio, puedes usar el procesador de YAML de línea de comandos yq.

         Comando: Para agregar la entrada "protecciones" a spc-org.yaml de forma local, usa el siguiente comando:

         yq -i '.spec.parameters.objects |= (
             from_yaml + [
                 {
                     "objectName": "guardrails",
                     "secretPath": "",
                     "secretKey": ""
                 }
             ] | to_yaml
         )' spc-org.yaml

         Este comando analiza la cadena YAML integrada en el campo objects, agrega el elemento nuevo a la lista y, luego, vuelve a escribir el resultado.

      3. Actualiza tu SecretProviderClass:

         kubectl -n APIGEE_NAMESPACE apply -f spc-org.yaml
         

   WIF para GKE

   La cuenta de servicio de Kubernetes (KSA) para los rieles de protección se llama apigee-operator-guardrails-sa. Crea la vinculación para la cuenta de servicio de Google (GSA) apigee-guardrails con el siguiente comando:

   gcloud iam service-accounts add-iam-policy-binding apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com \
       --role roles/iam.workloadIdentityUser \
       --member "serviceAccount:$PROJECT_ID.svc.id.goog[$APIGEE_NAMESPACE/apigee-operator-guardrails-sa]" \
       --project $PROJECT_ID

   Agrega lo siguiente a tu archivo overrides.yaml:

   guardrails:
     gsa: apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com

   WIF en otras plataformas

   La cuenta de servicio de Kubernetes (KSA) para los rieles de protección se llama apigee-operator-guardrails-sa. Debes otorgar a la KSA de los parámetros de protección acceso para suplantar la identidad de la cuenta de servicio de Google (GSA) apigee-guardrails y configurar tus anulaciones para que usen un archivo de configuración de credenciales.

   1. Otorga acceso a la KSA para que suplante a la GSA con el siguiente comando:

      Plantilla

      gcloud iam service-accounts add-iam-policy-binding \
        apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com \
        --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/system:serviceaccount:APIGEE_NAMESPACE:apigee-operator-guardrails-sa" \
        --role=roles/iam.workloadIdentityUser

      Ejemplo

      gcloud iam service-accounts add-iam-policy-binding \
        [e-mail] \
        --member="principal://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/my-pool/subject/system:serviceaccount:apigee:apigee-operator-guardrails-sa" \
        --role=roles/iam.workloadIdentityUser

      Aquí:

      • PROJECT_ID: Es el ID de tu proyecto de Google Cloud.
      • PROJECT_NUMBER: Es el número del proyecto en el que creaste el grupo de identidades para cargas de trabajo.
      • POOL_ID: El ID del grupo de identidades para cargas de trabajo.
      • APIGEE_NAMESPACE: Es el espacio de nombres en el que se instaló Apigee Hybrid.
   2. Crea un archivo de configuración de credenciales para la cuenta de servicio apigee-guardrails:

      gcloud iam workload-identity-pools create-cred-config \
        projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID \
        --service-account=apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com \
        --credential-source-file=/var/run/service-account/token \
        --credential-source-type=text \
        --output-file=apigee-guardrails-credential-configuration.json
          

      Aquí, WORKLOAD_PROVIDER_ID es el ID de tu proveedor de grupos de identidades para cargas de trabajo.

   3. Configura apigee-guardrails para usar la federación de identidades para cargas de trabajo con uno de los siguientes métodos:

      WIF: secretos

      1. Crea un nuevo secreto de Kubernetes con el archivo fuente de credenciales para cada archivo de configuración de credenciales.

         kubectl create secret -n APIGEE_NAMESPACE generic guardrails-workload-identity-secret --from-file="client_secret.json=./apigee-guardrails-credential-configuration.json"

      2. Reemplaza el valor de serviceAccountRef por el secreto nuevo:

         guardrails:
           serviceAccountRef: guardrails-workload-identity-secret

      WIF: archivos

      Mueve el archivo apigee-guardrails-credential-configuration.json generado al directorio del gráfico apigee-operator/.

      Agrega lo siguiente a tu archivo overrides.yaml:

      guardrails:
        serviceAccountPath: apigee-guardrails-credential-configuration.json

      WIF: Vault

      Actualiza la clave de la cuenta de servicio para guardrails en Vault con el archivo fuente de la credencial correspondiente:

      SAKEY=$(cat .apigee-guardrails-credential-configuration.json); kubectl -n APIGEE_NAMESPACE exec vault-0 -- vault kv patch secret/apigee/orgsakeys guardrails="$SAKEY"

      Consulta Storing service account keys in Hashicorp Vault para obtener más información.

Actualiza cert-manager

Nota: Este procedimiento es opcional si usas cert-manager 1.16.3 o una versión posterior.

Apigee Hybrid v1.16 admite las versiones de cert-manager de la 1.16 a la 1.19. Hay un cambio en cert-manager 1.18 que puede causar un problema con tu tráfico. En la versión 1.18 de cert-manager, el valor predeterminado de Certificate.Spec.PrivateKey.rotationPolicy se cambió de Never a Always. En el caso de las instalaciones actualizadas de Apigee Hybrid, esto puede causar un problema con tu tráfico. Cuando actualices a la versión 1.16 de hybrid desde una versión anterior, debes editar tu certificado apigee-ca para compensar este cambio o mantener tu versión de cert-manager en la versión 1.17.x o inferior.

Nota: Este cambio solo afecta las actualizaciones desde versiones anteriores de Apigee hybrid y no afecta las instalaciones nuevas de Apigee hybrid v1.16.

Antes de actualizar cert-manager a la versión 1.18 o 1.19, sigue el procedimiento que se indica a continuación para editar tu certificado apigee-ca y establecer el valor de Certificate.Spec.PrivateKey.rotationPolicy en Never.

Advertencia: Realiza estos pasos antes de actualizar cert-manager. De lo contrario, es posible que se active una rotación de certificado.

1. Verifica el contenido de tu certificado apigee-ca para ver si rotationPolicy está configurado:
   Nota: Si usas un espacio de nombres de cert-manager personalizado, reemplaza cert-manager por el espacio de nombres correcto en los siguientes comandos.

   kubectl get certificate apigee-ca -n cert-manager -o yaml
   

   Busca los valores en spec.privateKey en el resultado:

   ...
   spec:
     commonName: apigee-hybrid
     duration: 87600h
     isCA: true
     issuerRef:
       group: cert-manager.io
       kind: ClusterIssuer
       name: apigee-root-certificate-issuer
     privateKey:
       algorithm: ECDSA
       # Note: rotationPolicy would appear here if it is set.
       size: 256
     secretName: apigee-ca
   ...

2. Si rotationPolicy no está configurado o si se configura como Always, edita el certificado apigee-ca para establecer el valor de rotationPolicy en Never:
   1. Realiza primero una ejecución de prueba:

      kubectl patch Certificate \
        --dry-run=server \
        -n cert-manager \
        --type=json \
        -p='[{"op": "replace", "path": "/spec/privateKey/rotationPolicy", "value": "Never"}]' \
        -o=yaml \
        apigee-ca
      

   2. Aplica el parche al certificado:

      kubectl patch Certificate \
        -n cert-manager \
        --type=json \
        -p='[{"op": "replace", "path": "/spec/privateKey/rotationPolicy", "value": "Never"}]' \
        -o=yaml \
        apigee-ca
      

3. Verifica que el valor de rotationPolicy ahora esté establecido en Never:

   kubectl get certificate apigee-ca -n cert-manager -o yaml
   

   El resultado debería ser similar al siguiente:

   ...
   spec:
     commonName: apigee-hybrid
     duration: 87600h
     isCA: true
     issuerRef:
       group: cert-manager.io
       kind: ClusterIssuer
       name: apigee-root-certificate-issuer
     privateKey:
       algorithm: ECDSA
       rotationPolicy: Never
       size: 256
     secretName: apigee-ca
   ...

4. Actualiza cert-manager. Con el siguiente comando, se descargará e instalará cert-manager v1.19.2:

   kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.19.2/cert-manager.yaml

   Consulta Plataformas y versiones compatibles: cert-manager para obtener una lista de las versiones compatibles.

Consulta los siguientes vínculos:

• Problema conocido 465834046
• Versión 1.18 de cert-manager: El valor predeterminado de Certificate.Spec.PrivateKey.rotationPolicy ahora es Always

Instala el entorno de ejecución de Hybrid 1.16.0

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

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.

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.

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

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

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

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

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

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=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-my-org-my-env      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

8. 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 y diferente de los demás nombres de versiones de Helm en 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 versión 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 Tres conceptos importantes 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.16.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-my-org-my-env          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

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:

      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-123abc               running   2d

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

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

¡Felicitaciones! Actualizaste a la versión 1.16.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 2 de la Parte 3: Implementa un proxy de API en la guía de instalación de Apigee Hybrid 1.16.

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 avanza hasta apigee-operator. 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.

1. 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.15.x).

   Ejecuta el siguiente comando para cada grupo de entorno:

   helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f 1.15_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.15_OVERRIDES_FILE
   

   Revierte los gráficos restantes, excepto apigee-operator.

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

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

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

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

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

2. Crea el espacio de nombres apigee-system.

   kubectl create namespace apigee-system
   

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

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

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

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

6. Para revertir las CRD, reinstala las CRD anteriores.

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

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

8. 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.15_OVERRIDES_FILE