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

Actualizar Apigee hybrid a la versión 1.13

En este procedimiento se explica cómo actualizar de la versión 1.12.x de Apigee hybrid a la versión 1.13.4 de Apigee hybrid y de versiones anteriores de hybrid 1.13.x a la versión 1.13.4.

Sigue los mismos procedimientos para actualizar versiones secundarias (por ejemplo, de la versión 1.12 a la 1.13) y para actualizar versiones de parches (por ejemplo, de la versión 1.13.0 a la 1.13.4).

Si vas a actualizar desde la versión 1.11 o una anterior de Apigee hybrid, primero debes actualizar a la versión 1.12 antes de actualizar a la versión 1.13.4. Consulta las instrucciones para actualizar Apigee Hybrid a la versión 1.12.

Cambios de Apigee Hybrid v1.12

Ten en cuenta los siguientes cambios:

apigee-operator en el espacio de nombres de Apigee: a partir de la versión 1.13, apigee-operator se ejecuta en el mismo espacio de nombres de Kubernetes que los demás componentes de Apigee Hybrid, apigee de forma predeterminada. Puede proporcionar cualquier nombre para el espacio de nombres. En versiones anteriores, era necesario que apigee-operator se ejecutara en su propio espacio de nombres, apigee-system.
Anthos (en bare metal o VMware) ahora es Google Distributed Cloud (para bare metal o VMware): para obtener más información, consulta las descripciones generales de Google Distributed Cloud para bare metal y Google Distributed Cloud para VMware.
Comprobaciones de instanciación de clases más estrictas: a partir de la versión 1.13.3 de 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: Para probar la instalación, sigue el procedimiento descrito en Validar las políticas después de actualizar a la versión 1.13.3 o posterior para validar el comportamiento de las políticas.

Requisitos previos

Antes de actualizar a la versión híbrida 1.13, 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.12, debes actualizar a la versión 1.12 antes de actualizar a la 1.13. Consulta Actualizar Apigee Hybrid a la versión 1.12.
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.13 que se indica más abajo.

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

Para actualizar a la versión 1.13 de Apigee Hybrid, es posible que se produzca un tiempo de inactividad.

Al actualizar el controlador de Apigee a la versión 1.13.4, 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 actualizar 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.12 no se puede usar para restaurar una instancia de Hybrid 1.13.

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.13.4 del entorno de ejecución híbrido.

Prepararse para actualizar a la versión 1.13

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 de tu 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%
```
Haz una copia de seguridad del directorio 1.12 $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.12-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.

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 usas secretos de Kubernetes o Workload Identity para autenticar cuentas de servicio.

En la siguiente tabla se muestra el destino de cada archivo de cuenta de servicio, 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.12 y 1.13 de Hybrid. Si necesitas ayuda, consulta la documentación de tu plataforma.

Haz clic para desplegar la lista de plataformas compatibles.

	1,10 ⁽²⁾	1.11	1.12	1.13
GKE en Google Cloud	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.27.x 1.28.x 1.29.x 1.30.x
GKE en AWS	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1.26.x⁽⁴⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x (K8s v1.25.x) 1.26.x⁽⁴⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)} 1.30.x
GKE en Azure	1.13.x 1.14.x 1.26.x⁽⁴⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.26.x⁽⁴⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)} 1.30.x
Google Distributed Cloud (solo software) en VMware ⁽⁵⁾	1.13.x ⁽¹⁾ 1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)}	1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x 1.30.x
Google Distributed Cloud (solo software) en bare metal	1.13.x ⁽¹⁾ 1.14.x (K8s v1.25.x) 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x⁽⁴⁾^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)}	1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x 1.30.x
EKS	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.26.x 1.27.x 1.28.x 1.29.x
AKS	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.26.x 1.27.x 1.28.x 1.29.x
OpenShift	4.11 4.12 4.14^{(≥ 1.10.5)} 4.15^{(≥ 1.10.5)}	4.12 4.13 4.14 4.15^{(≥ 1.11.2)} 4.16^{(≥ 1.11.2)}	4.12 4.13 4.14 4.15 4.16^{(≥ 1.12.1)}	4.12 4.13 4.14 4.15 4.16
Rancher Kubernetes Engine (RKE)	v1.26.2+rke2r1 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	v1.26.2+rke2r1 v1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x 1.30.x
VMware Tanzu	N/A	N/A	v1.26.x	v1.26.x
Componentes	1.10	1.11	1.12	1.13
Cloud Service Mesh	1.17.x⁽³⁾	1.17.x^{(v1.11.0 - v1.11.1)}⁽³⁾ 1.18.x^{(≥ 1.11.2)}⁽³⁾	1.18.x⁽³⁾	1.19.x⁽³⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.10.x 1.11.x 1.12.x	1.11.x 1.12.x 1.13.x	1.11.x 1.12.x 1.13.x	1.13.x 1.14.x 1.15.x
Cassandra	3.11	3.11	4.0	4.0
Kubernetes	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x 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+	3.14.2+
Controlador de CSI Secret Store		1.3.4	1.4.1	1.4.1
Vault		1.13.x	1.15.2	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`: Instalación de cert-manager en conflicto ⁽²⁾ Se han alcanzado las fechas oficiales de finalización del ciclo de vida de las versiones 1.10 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 versiones posteriores. ⁽⁸⁾ La asistencia está disponible en la versión 1.12.1 de Apigee Hybrid y en versiones posteriores.

Instalar el entorno de ejecución híbrido 1.13.4

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.13.4
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.15.5/cert-manager.yaml
```
Consulta la lista de plataformas y versiones compatibles con 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 la versión 1.15.5 o una posterior de cert-manager.
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 utilizas 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

Migra apigee-operator del espacio de nombres apigee-system a APIGEE_NAMESPACE.
Nota: Este paso solo es obligatorio para las actualizaciones desde la versión 1.12.x. Si vas a actualizar desde una versión anterior a la 1.13, puedes saltarte este paso.
1. Anota el clusterIssuer con el nuevo espacio de nombres.
```
kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-namespace='APIGEE_NAMESPACE'
```
2. Si vas a cambiar el nombre de la versión de apigee-operator, anota clusterIssuer con el nuevo nombre de la versión.
```
kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-name='APIGEE_OPERATOR_RELEASE_NAME'
```
3. Actualiza las réplicas de tu implementación de Apigee Operator en el espacio de nombres apigee-system a 0 (cero) para evitar que los dos controladores se reconcilien.
```
kubectl scale deployment apigee-controller-manager -n apigee-system --replicas=0
```
4. Elimina apigee-mutating-webhook-configuration y apigee-validating-webhook-configuration.
```
kubectl delete mutatingwebhookconfiguration apigee-mutating-webhook-configuration
kubectl delete validatingwebhookconfiguration apigee-validating-webhook-configuration
```
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.13.4   1.13.4

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 tu nuevo archivo de anulaciones para la versión 1.13.4.
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.
Nota: Este paso solo es obligatorio para las actualizaciones desde la versión 1.12.x. Si vas a actualizar desde una versión anterior a la 1.13, puedes saltarte este paso.
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 ámbito de clúster eliminados:
Nota: Este paso solo es necesario para las actualizaciones desde la versión 1.12.x. Si vas a actualizar desde una versión anterior a la 1.13, puedes saltarte este paso.
```
helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml
```

Validar las políticas después de actualizar a la versión 1.13.3 o posterior

Sigue este procedimiento para validar el comportamiento de la política JavaCallout después de actualizar de la versión 1.13.2 o anterior a la 1.13.3 o posterior.

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 deje de aparecer.
Habilita la comprobación de seguridad en el entorno de producción.
Después de haber probado y verificado exhaustivamente 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.

Debido al cambio en el espacio de nombres de apigee-operator, debes seguir pasos adicionales para eliminar los hooks de admisión de validación y mutación. De esta forma, cuando vuelvas a instalar el apigee-operator en el espacio de nombres apigee-system, se volverán a crear para que apunten al endpoint correcto del operador de Apigee.

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.

Actualiza a 0 las réplicas de la implementación del operador de Apigee en Apigee para evitar que los dos controladores reconcilien los recursos personalizados y, de este modo, evitar conflictos al restaurar la versión anterior en el espacio de nombres apigee-system.

kubectl scale deployment apigee-controller-manager -n APIGEE_NAMESPACE --replicas=0

kubectl delete mutatingwebhookconfiguration \
  apigee-mutating-webhook-configuration-APIGEE_NAMESPACE

kubectl delete validatingwebhookconfiguration \
  apigee-validating-webhook-configuration-APIGEE_NAMESPACE

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.12.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.12_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.12_OVERRIDES_FILE

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

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

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

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

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

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.12_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.12_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.12_OVERRIDES_FILE
```

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

Cambios de Apigee Hybrid v1.12

Requisitos previos

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

Prepararse para actualizar a la versión 1.13

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 la lista de plataformas compatibles.

Componentes

Instalar el entorno de ejecución híbrido 1.13.4

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 a la versión 1.13.3 o posterior

Restaurar una versión anterior

Actualizar Apigee hybrid a la versión 1.13