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.9 de Apigee Hybrid y de las versiones anteriores de Hybrid 1.15.x a la versión 1.15.9.

Usa los mismos procedimientos para las actualizaciones de versiones secundarias (por ejemplo, de la versión 1.14 a la 1.15) y las actualizaciones de versiones de parches (por ejemplo, de la 1.15.0 a la 1.15.9).

Si actualizas desde Apigee Hybrid 1.13 o desde una versión anterior, primero debes actualizar a la versión 1.14 antes de actualizar a la versión 1.15.9. Consulta las instrucciones para actualizar Apigee Hybrid a la versión 1.14.

Cambios de Apigee Hybrid v1.14

Ten en cuenta los siguientes cambios:

  • Monetización de Apigee Hybrid: A partir de la versión 1.15.1, Apigee Hybrid ahora admite tarifas recurrentes, de recarga y de configuración para la monetización. Para obtener información, consulta Habilita la monetización para Apigee Hybrid.
  • Comodines (*) en las rutas de acceso base del proxy: A partir de la versión 1.15.1, ahora se admite el uso de comodines en las rutas de acceso base del proxy de Apigee. Para implementar este cambio, sigue el procedimiento que se indica en Problema conocido 378686709.
  • 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:
  • Verificaciones de creación de instancias de clase más estrictas: Apigee Hybrid, la política JavaCallout ahora incluye seguridad adicional durante la creación de instancias de clase de Java. La medida de seguridad mejorada impide la implementación de políticas que intenten, de forma directa o indirecta, realizar acciones que requieran 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 de terceros o aquellas con código personalizado que activan de forma indirecta operaciones que requieren permisos elevados.

Para obtener información adicional 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:

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

  • En Apigee Hybrid 1.15.9, se presenta un nuevo límite mejorado de proxies 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 de la cantidad de proxies y flujos compartidos que puedes implementar por entorno. Esta función solo está disponible en las organizaciones de Hybrid recién creadas y no se puede aplicar a las organizaciones actualizadas. Para usar esta función, realiza una instalación nueva de la versión 1.15.9 de Hybrid 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.9, 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 el restablecimiento de Cassandra no podrán 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 muestran a continuación.

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

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.15.9 del entorno de ejecución de Hybrid.

Prepárate para actualizar a la versión 1.15

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.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
  3. Realiza una copia de seguridad de tu base de datos de Cassandra según las instrucciones que se indican en Copia de seguridad y recuperación de Cassandra.
  4. Si usas archivos de certificado de servicio (.json) en tus anulaciones para autenticar cuentas de servicio, asegúrate de que tus archivos de certificado de cuenta de servicio residan en el directorio del chart de Helm correcto. Los charts de Helm no pueden leer archivos fuera de cada directorio del chart.

    Este paso no es necesario si usas Secrets de Kubernetes o Workload Identity Federation for GKE con el objetivo de autenticar cuentas de servicio.

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

    Producción

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

    No producción

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

    Cuenta de servicio Nombre de archivo predeterminado Directorios de charts de Helm
    apigee-non-prod PROJECT_ID-apigee-non-prod.json $APIGEE_HELM_CHARTS_HOME/apigee-datastore/
    $APIGEE_HELM_CHARTS_HOME/apigee-telemetry/
    $APIGEE_HELM_CHARTS_HOME/apigee-org/
    $APIGEE_HELM_CHARTS_HOME/apigee-env/
  5. Asegúrate de que el certificado TLS y los archivos de claves (.crt, .key o .pem) residan en el directorio $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/.

Actualiza tu versión de Kubernetes

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

Quita o actualiza las CRD de Istio

Durante la actualización desde las versiones 1.14.1 o anteriores de Apigee Hybrid, la presencia de definiciones de recursos personalizados (CRD) de istio.io en un clúster de Apigee Hybrid puede causar fallas en los sondeos de preparación en los contenedores de discovery de los Pods de apigee-ingressgateway-manager.

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

Existen dos opciones para corregir estos problemas:

  • Borra las CRD de istio.io si no usas Istio para ningún otro propósito que no sea Apigee en tu clúster.
  • Actualiza el apigee-ingressgateway-manager clusterrole para agregar permisos para istio.io.

Después de cada una de las opciones anteriores, deberás reiniciar tus Pods de apigee-ingressgateway-manager.

Consulta el problema conocido 416634326 y el problema conocido 419856132 para obtener más información sobre los CRD de istio.io y gateway.networking.k8s.io/v1 en Apigee Hybrid.

  1. Determina si tienes CRD de istio.io en tu clúster con el siguiente comando: 
    kubectl get crd -o custom-columns=NAME:metadata.name | grep istio.io

    El resultado se verá similar al siguiente si tu clúster tiene CRD de istio.io: 

    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
  2. Opcional: Guarda las CRD de forma local en caso de que necesites volver a crearlas: 
    kubectl get crd $(cat istio-crd.csv) -o yaml > istio-crd.yaml

Borra las CRD

  1. Enumera los CRD de istio.io en tu clúster en un archivo CSV: 
    kubectl get crd -o custom-columns=NAME:metadata.name | grep istio.io > istio-crd.csv
  2. Opcional: Guarda las CRD de forma local en caso de que necesites volver a crearlas: 
    kubectl get crd $(cat istio-crd.csv) -o yaml > istio-crd.yaml
  3. Borra las CRD de istio.io:

    Prueba de validación:

    kubectl delete crd $(cat istio-crd.csv) --dry-run=client

    Ejecución:

    kubectl delete crd $(cat istio-crd.csv)

Actualiza el clusterrole

  1. Obtén el clusterrole apigee-ingressgateway-manager actual: 
    kubectl get clusterrole apigee-ingressgateway-manager-apigee -o yaml > apigee-ingressgateway-manager-apigee-clusterrole.yaml
  2. Copia el clusterrole en una ubicación nueva: 
    cp apigee-ingressgateway-manager-apigee-clusterrole.yaml apigee-ingressgateway-manager-apigee-clusterrole-added-istio-permissions.yaml
  3. Agrega los siguientes permisos adicionales al final del archivo: 
    - apiGroups:
  - gateway.networking.k8s.io
  resources:
  - gatewayclasses
  - gateways
  - grpcroutes
  - httproutes
  - referencegrants
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.istio.io
  resources:
  - sidecars
  - destinationrules
  - gateways
  - virtualservices
  - envoyfilters
  - workloadentries
  - serviceentries
  - workloadgroups
  - proxyconfigs
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - security.istio.io
  resources:
  - peerauthentications
  - authorizationpolicies
  - requestauthentications
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - telemetry.istio.io
  resources:
  - telemetries
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - extensions.istio.io
  resources:
  - wasmplugins
  verbs:
  - get
  - list
  - watch
  4. Aplica el rol: 
    kubectl -n APIGEE_NAMESPACE apply -f apigee-ingressgateway-manager-apigee-clusterrole-added-istio-permissions.yaml

Después de completar las opciones anteriores, deberás reiniciar tus pods de apigee-ingressgateway-manager.

  1. Enumera los Pods de ingress-manager que se reinstalarán o volverán a crear: 
    kubectl get deployments -n APIGEE_NAMESPACE

    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
  2. Reinicia los Pods ingress-manager: 
    kubectl rollout restart deployment -n APIGEE_NAMESPACE apigee-ingressgateway-manager
  3. Después de unos minutos, supervisa los Pods de apigee-ingressgateway-manager: 
    watch -n 10 kubectl -n APIGEE_NAMESPACE get pods -l app=apigee-ingressgateway-manager

    Resultado de ejemplo:

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

Instala el entorno de ejecución de Hybrid 1.15.9

Configurar 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 estadísticas y depuración está habilitada de forma predeterminada para todas las organizaciones de Apigee Hybrid. Debes seguir los pasos que se indican en Habilita el acceso de publicador de estadísticas para configurar el flujo de autorización.

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

  1. Extrae los charts de Helm para Apigee.

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

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

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

    export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
export CHART_VERSION=1.15.9
helm pull $CHART_REPO/apigee-operator --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-datastore --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-env --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-ingress-manager --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-org --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-redis --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-telemetry --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-virtualhost --version $CHART_VERSION --untar
  2. Actualiza cert-manager si es necesario.

    Si necesitas actualizar tu versión de cert-manager, instala la versión nueva con el siguiente comando:

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

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

  3. 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 tu espacio de nombres, no necesitas editar el archivo.

  4. Instala las CRD de Apigee actualizadas:

    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

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

  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:

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

    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-org1-xxxxx          running   2d
  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 chart 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 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.15.9.

    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
  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
    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
  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 con alcance de clúster borrados: 
    helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml

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

  1. Verifica si los archivos JAR de Java solicitan permisos innecesarios.

    Después de implementar la política, verifica los registros del entorno 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 JAR implementado solicitó permisos innecesarios. Para resolver este problema, investiga el código Java y actualiza el archivo JAR.

  2. Investiga y actualiza el código Java.

    Revisa cualquier código de 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.

  3. Prueba las políticas con la verificación de seguridad habilitada.

    En un entorno que no sea de producción, habilita la marca de verificación de seguridad y vuelve a implementar tus políticas con un JAR actualizado. Para configurar la marca, usa este comando:

    • En el archivo apigee-env/values.yaml, configura conf_security-secure.constructor.only como true en runtime:cwcAppend:. Por ejemplo: 
      # Apigee Runtime
runtime:
  cwcAppend:
    conf_security-secure.constructor.only: true
    • Actualiza el gráfico de 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

        ENV_RELEASE_NAME es un nombre que se usa para hacer un seguimiento de la instalación y las actualizaciones del chart 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 Tres conceptos importantes en la documentación de Helm.

    Si el mensaje de registro "Failed to load and initialize class ..." sigue presente, continúa modificando y probando el JAR hasta que el mensaje de registro ya no aparezca.

  4. 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 configurando la marca conf_security-secure.constructor.only en true y actualizando el gráfico de 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 del gráfico anterior para revertir el proceso de actualización en el orden inverso. Comienza con apigee-virtualhost y vuelve a apigee-operator. Luego, revierte las CRD.

  1. Revierte los gráficos. 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_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f 1.14_OVERRIDES_FILE

    1. Ejecuta el siguiente comando para cada entorno:

      helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_NAME \
  -f 1.14_OVERRIDES_FILE
      2. apigee-org: 
      helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f 1.14_OVERRIDES_FILE
    2. apigee-ingress-manager: 
      helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f 1.14_OVERRIDES_FILE
    3. apigee-redis: 
      helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f 1.14_OVERRIDES_FILE
    4. apigee-telemetry: 
      helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f 1.14_OVERRIDES_FILE
    5. apigee-datastore: 
      helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f 1.14_OVERRIDES_FILE
    6. apigee-operator: 
      helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f 1.14_OVERRIDES_FILE
  2. Para revertir las CRD, vuelve a instalar las anteriores. 
    kubectl apply -k apigee-operator/etc/crds/default/ \
  --server-side \
  --force-conflicts \
  --validate=false