Actualiza Apigee Hybrid a la versión 1.12

Este procedimiento abarca la actualización de la versión 1.11.x de Apigee Hybrid a la versión 1.12.2 de Apigee Hybrid.

Cambios de Apigee Hybrid v1.11

La versión 1.12 de Apigee Hybrid presenta los siguientes cambios que afectan el proceso de actualización. Para obtener una lista completa de las características en v1.12, consulta las notas de la versión híbrida v1.12.0.

  • Cassandra 4.x: A partir de la versión 1.12, Apigee Hybrid usa Cassandra versión 4+.
  • Baja de apigeectl: A partir de la versión 1.12, Apigee Hybrid solo admite Helm para instalar y administrar la instalación híbrida.
  • Ahora está disponible un nuevo conjunto de métricas para supervisar los proxies de Apigee y los extremos de destino. En la versión híbrida 1.12, los recursos supervisados ProxyV2 y TargetV2 ya no se usarán de forma predeterminada. Todas las métricas de proxy y de destino se publicarán en los recursos supervisados Proxy y Target.

    Para seguir emitiendo métricas a los recursos supervisados ProxyV2 y TargetV2, configura metrics.disablePrometheusPipeline como true en overrides.yaml.

    Si tienes configuradas alertas basadas en métricas, confirma el uso de las métricas correctas para tu instalación híbrida. Para obtener más información, consulta Alertas basadas en métricas.

Consideraciones antes de comenzar una actualización a la versión 1.12

La actualización de la versión 1.11 de Apigee Hybrid a la versión 1.12 incluye una actualización de la base de datos de Cassandra de la versión 3.11.x a la versión 4.x. Si bien la actualización de Cassandra se maneja como parte del procedimiento de actualización de Apigee Hybrid, planifica las siguientes consideraciones:

  • La actualización de la versión de Cassandra se realizará en segundo plano y se realizará en 1 Pod (o nodo de Cassandra) a la vez, por lo que debes planificar una capacidad de base de datos reducida durante la actualización.
  • Escala tu capacidad de Cassandra y asegúrate de que el uso del disco sea cercano o inferior al 50% antes de comenzar la actualización.
  • Valida y prueba los procedimientos de copia de seguridad y restablecimiento de Cassandra.
  • Crea una copia de seguridad de los datos de Cassandra en tu instalación de versión híbrida 1.11 antes de comenzar a actualizar y validar tus copias de seguridad.
  • La actualización de apigee-datastore generará un aumento temporal en el consumo de CPU debido a las tareas posteriores a la actualización que realiza Cassandra.
  • Una vez que hayas actualizado el componente apigee-datastore (Cassandra), no puedes revertirlo a la versión anterior. Hay dos situaciones en las que se puede revertir una actualización a la versión híbrida 1.12 después de actualizar el componente apigee-datastore:
    • Si el componente apigee-datastore está en buen estado, pero otros componentes requieren una reversión, puedes revertirlos de forma individual.
    • Si el componente apigee-datastore está en mal estado, debes restablecerlo desde una copia de seguridad v1.11 a una instalación v1.11.

Consideraciones antes de actualizar una instalación de una sola región

Si necesitas revertir a una versión anterior de Apigee Hybrid, el proceso puede requerir tiempo de inactividad. Por lo tanto, si deseas actualizar una instalación de una sola región, te recomendamos crear una segunda región y, luego, actualizar solo una región a la vez en la siguiente secuencia:

  1. Agrega una segunda región a tu instalación existente con la misma versión híbrida. Consulta Implementación multirregional en la documentación de la versión 1.11.
  2. Crea una copia de seguridad y valida los datos de la primera región antes de comenzar una actualización. Consulta la descripción general de la copia de seguridad de Cassandra en la documentación de la versión 1.11.
  3. Actualiza la región recién agregada a Hybrid 1.12.
  4. Cambia el tráfico a la región nueva y valida el tráfico.
  5. Una vez validada, actualiza la región anterior con la versión Hybrid 1.12.
  6. Vuelve a cambiar todo el tráfico a la región anterior y valida el tráfico.
  7. Quita la región nueva.

Consideraciones antes de actualizar una instalación multirregional

Apigee recomienda la siguiente secuencia para actualizar una instalación multirregional:

  1. Crea una copia de seguridad y valida los datos de cada región antes de comenzar la actualización.
  2. Actualiza la versión híbrida en una región y asegúrate de que todos los Pods estén en estado de ejecución para validar la actualización.
  3. Valida el tráfico en la región recién actualizada.
  4. Actualiza cada región posterior solo después de validar el tráfico en la región anterior.
  5. En caso de posible necesidad de revertir una actualización en una implementación multirregional, prepárate para cambiar el tráfico de las regiones con errores, considera agregar suficiente capacidad en la región donde se desviará el tráfico para manejar el tráfico en ambas regiones.

Requisitos previos

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

  • Una instalación de Apigee Hybrid versión 1.11 administrada con Helm.
  • Versión de Helm v3.10+.
  • Versión de kubectl 1.27, 1.28 o 1.29 (recomendado).
  • Versión v1.13.0 de cert-manager. Si es necesario, actualizarás cert-manager en la sección Prepárate para actualizar a la versión a continuación.

Limitaciones

Ten en cuenta las siguientes limitaciones cuando planifiques tu actualización de la versión 1.11 de Apigee Hybrid a la versión 1.12. La planificación puede ayudar a reducir la necesidad de tiempo de inactividad si necesitas revertir o restablecer contenido después de la actualización.

  • Las copias de seguridad de Hybrid 1.12 no se pueden restablecer en Hybrid 1.11 y viceversa, debido a la incompatibilidad entre las dos versiones.
  • No puedes escalar los Pods del almacén de datos durante la actualización a la versión 1.12. Satisface tus necesidades de escalamiento en todas las regiones antes de comenzar a actualizar tu instalación híbrida.
  • En una instalación híbrida de una sola región, no puedes revertir el componente del almacén de datos una vez que haya finalizado el proceso de actualización del almacén de datos. No puedes revertir un almacén de datos de Cassandra 4.x a un almacén de datos de Cassandra 3.x. Esto requerirá el restablecimiento de tu copia de seguridad más reciente de los datos de Cassandra 3.x (de tu instalación de la versión híbrida 1.11).
  • No se puede borrar ni agregar una región durante la actualización. En una actualización multirregional, debes completar la actualización de todas las regiones antes de poder agregar o borrar regiones.

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

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

  1. Prepárate para la actualización.
    • Copia de seguridad de Cassandra
    • Crea una copia de seguridad de los directorios de instalación de Hybrid
  2. Instala la versión 1.12.2 del entorno de ejecución híbrido.

Prepárate para actualizar a la versión 1.12

Copia de seguridad de Cassandra

  • Realiza una copia de seguridad de tu base de datos de Cassandra en todas las regiones aplicables y valida los datos en tu instalación de la versión híbrida 1.11 antes de comenzar la actualización. Consulta Supervisa las copias de seguridad en la documentación de la versión 1.11.
  • Reinicia todos los Pods de Cassandra en el clúster antes de comenzar el proceso de actualización, de modo que puedan aparecer los problemas persistentes.

    Para reiniciar y probar los pods de Cassandra, borra cada uno de ellos de forma individual, uno a la vez, y, luego, valida que vuelva a aparecer en un estado de ejecución y que se apruebe la prueba de preparación:

    1. Genera una lista de los Pods de Cassandra:
      kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

      Por ejemplo:

      kubectl get pods -n apigee -l app=apigee-cassandra
      NAME                         READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          2h
      apigee-cassandra-default-1   1/1     Running   0          2h
      apigee-cassandra-default-2   1/1     Running   0          2h
      
      . . .
    2. Borra un Pod:
      kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME

      Por ejemplo:

      kubectl delete pod -n apigee apigee-cassandra-default-0
    3. Vuelve a enumerar los Pods de Cassandra para verificar el estado:
      kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

      Por ejemplo:

      kubectl get pods -n apigee -l app=apigee-cassandra
      NAME                         READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          16s
      apigee-cassandra-default-1   1/1     Running   0          2h
      apigee-cassandra-default-2   1/1     Running   0          2h
      
      . . .
  • Vuelve a aplicar el último archivo de anulación conocido a fin de asegurarte de que no se realicen cambios para que puedas usar la misma configuración a fin de actualizar a la versión 1.12 de Hybrid.
  • Asegúrate de que todos los nodos de Cassandra en todas las regiones estén en el estado UN (Up / Normal). Si algún nodo de Cassandra está en un estado diferente, resuélvelo primero antes de iniciar la actualización.

    Puedes validar el estado de tus nodos de Cassandra con los siguientes comandos:

    1. Genera una lista de los Pods de Cassandra:
      kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

      Por ejemplo:

      kubectl get pods -n apigee -l app=apigee-cassandra
      NAME                         READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          2h
      apigee-cassandra-default-1   1/1     Running   0          2h
      apigee-cassandra-default-2   1/1     Running   0          2h
      apigee-cassandra-default-3   1/1     Running   0          16m
      apigee-cassandra-default-4   1/1     Running   0          14m
      apigee-cassandra-default-5   1/1     Running   0          13m
      apigee-cassandra-default-6   1/1     Running   0          9m
      apigee-cassandra-default-7   1/1     Running   0          9m
      apigee-cassandra-default-8   1/1     Running   0          8m
    2. Verifica el estado de los nodos de cada Pod de Cassandra con el comando kubectl nodetool status:
      kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME nodetool status

      Por ejemplo:

      kubectl -n apigee exec -it apigee-cassandra-default-0 nodetool status
      Datacenter: us-east1
      ====================
      Status=Up/Down
      |/ State=Normal/Leaving/Joining/Moving
      --  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
      UN  10.16.2.6    690.17 KiB  256          48.8%             b02089d1-0521-42e1-bbed-900656a58b68  ra-1
      UN  10.16.4.6    705.55 KiB  256          51.6%             dc6b7faf-6866-4044-9ac9-1269ebd85dab  ra-1
      UN  10.16.11.11  674.36 KiB  256          48.3%             c7906366-6c98-4ff6-a4fd-17c596c33cf7  ra-1
      UN  10.16.1.11   697.03 KiB  256          49.8%             ddf221aa-80aa-497d-b73f-67e576ff1a23  ra-1
      UN  10.16.5.13   703.64 KiB  256          50.9%             2f01ac42-4b6a-4f9e-a4eb-4734c24def95  ra-1
      UN  10.16.8.15   700.42 KiB  256          50.6%             a27f93af-f8a0-4c88-839f-2d653596efc2  ra-1
      UN  10.16.11.3   697.03 KiB  256          49.8%             dad221ff-dad1-de33-2cd3-f1.672367e6f  ra-1
      UN  10.16.14.16  704.04 KiB  256          50.9%             1feed042-a4b6-24ab-49a1-24d4cef95473  ra-1
      UN  10.16.16.1   699.82 KiB  256          50.6%             beef93af-fee0-8e9d-8bbf-efc22d653596  ra-1

Crea una copia de seguridad de los directorios de instalación híbridos

  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.11. 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.11-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 para autenticar cuentas de servicio.

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

    Producción

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

    No producción

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

    Cuenta de servicio Nombre de archivo predeterminado Directorios de charts de Helm
    apigee-non-prod PROJECT_ID-apigee-non-prod.json $APIGEE_HELM_CHARTS_HOME/apigee-datastore/
    $APIGEE_HELM_CHARTS_HOME/apigee-telemetry/
    $APIGEE_HELM_CHARTS_HOME/apigee-org/
    $APIGEE_HELM_CHARTS_HOME/apigee-env/
  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.11 y Hybrid 1.12. Si necesitas ayuda, sigue la documentación de la plataforma.

Instala el entorno de ejecución de Hybrid 1.12.2

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.12.2
    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.13.0/cert-manager.yaml
    
  3. 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                    2023-10-09T14:48:30Z
      apigeedeployments.apigee.cloud.google.com                   2023-10-09T14:48:30Z
      apigeeenvironments.apigee.cloud.google.com                  2023-10-09T14:48:31Z
      apigeeissues.apigee.cloud.google.com                        2023-10-09T14:48:31Z
      apigeeorganizations.apigee.cloud.google.com                 2023-10-09T14:48:32Z
      apigeeredis.apigee.cloud.google.com                         2023-10-09T14:48:33Z
      apigeerouteconfigs.apigee.cloud.google.com                  2023-10-09T14:48:33Z
      apigeeroutes.apigee.cloud.google.com                        2023-10-09T14:48:33Z
      apigeetelemetries.apigee.cloud.google.com                   2023-10-09T14:48:34Z
      cassandradatareplications.apigee.cloud.google.com           2023-10-09T14:48:35Z
      
  4. 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:

    Ejecución de prueba:

    helm upgrade operator apigee-operator/ \
      --install \
      --create-namespace \
      --namespace apigee-system \
      -f OVERRIDES_FILE \
      --dry-run
    

    Actualiza el chart:

    helm upgrade operator apigee-operator/ \
      --install \
      --create-namespace \
      --namespace apigee-system \
      -f OVERRIDES_FILE
    

    Verifica la instalación del operador de Apigee:

    helm ls -n apigee-system
    
    NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
    operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.2   1.12.2

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

    kubectl -n apigee-system 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
    

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

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

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

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

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

    Ejecución de prueba:

    helm upgrade ENV_RELEASE_NAME apigee-env/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      --set env=ENV_NAME \
      -f OVERRIDES_FILE \
      --dry-run
    
    • ENV_RELEASE_NAME es el nombre con el que se instaló el chart apigee-env. En la versión híbrida 1.10, por lo general, es apigee-env-ENV_NAME. En la versión híbrida 1.11 y posteriores, suele ser ENV_NAME.
    • ENV_NAME es el nombre del entorno que estás actualizando.
    • OVERRIDES_FILE es tu nuevo archivo de anulaciones para v.1.12.2

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

      Ejecución de prueba:

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --set envgroup=ENV_GROUP_NAME \
        -f OVERRIDES_FILE \
        --dry-run
      

      ENV_GROUP_RELEASE_NAME es el nombre con el que se instaló el chart apigee-virtualhost. En la versión híbrida 1.10, por lo general, es apigee-virtualhost-ENV_GROUP_NAME. En la versión híbrida 1.11 y posteriores, suele ser 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 get arc
      
      NAME                                STATE   AGE
      apigee-org1-dev-egroup                       2d
      kubectl -n apigee get ar
      
      NAME                                        STATE     AGE
      apigee-org1-dev-egroup-xxxxxx                running   2d

Revierte a una versión anterior

Esta sección se divide en secciones según el estado de tu componente apigee-datastore después de actualizar a la versión 1.12 de Apigee Hybrid. Hay procedimientos para la reversión de una sola región o multirregión con el componente apigee-datastore en buen estado y procedimientos para la recuperación o el restablecimiento desde una copia de seguridad cuando apigee-datastore está en mal estado.

Reversión y recuperación de una sola región

Revierte cuando apigee-datastore está en buen estado

En este procedimiento, se explica cómo revertir cada componente de Apigee Hybrid de la versión 1.12 a la v1.11, excepto apigee-datastore. El componente apigee-datastore de la versión 1.12 es retrocompatible con los componentes híbridos de la versión 1.11.

Para revertir la instalación de una sola región a la versión 1.11, sigue estos pasos:

  1. Antes de iniciar la reversión, valida que todos los pods estén en estado de ejecución:
    kubectl get pods -n APIGEE_NAMESPACE
    kubectl get pods -n apigee-system
  2. Valida la versión de los componentes con Helm:
    helm -n APIGEE_NAMESPACE list
    helm -n apigee-system list

    Por ejemplo:

    helm -n apigee list
    NAME              NAMESPACE   REVISION   UPDATED                                   STATUS     CHART                           APP VERSION
    datastore         apigee      2          2024-03-29 17:08:07.917848253 +0000 UTC   deployed   apigee-datastore-1.12.0         1.12.0
    ingress-manager   apigee      2          2024-03-29 17:21:02.917333616 +0000 UTC   deployed   apigee-ingress-manager-1.12.0   1.12.0
    redis             apigee      2          2024-03-29 17:19:51.143728084 +0000 UTC   deployed   apigee-redis-1.12.0             1.12.0
    telemetry         apigee      2          2024-03-29 17:16:09.883885403 +0000 UTC   deployed   apigee-telemetry-1.12.0         1.12.0
    myhybridorg       apigee      2          2024-03-29 17:21:50.899855344 +0000 UTC   deployed   apigee-org-1.12.0               1.12.0
  3. Revierte cada componente excepto apigee-datastore con los siguientes comandos:
    1. Crea la siguiente variable de entorno:
      • PREVIOUS_HELM_CHARTS_HOME: El directorio en el que se instalaron los charts anteriores de Helm para Apigee Hybrid. Esta es la versión a la que estás revirtiendo.
    2. Revierte los hosts virtuales. Repite el siguiente comando para cada grupo de entornos mencionado en el archivo de anulaciones.
      helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set envgroup=ENV_GROUP_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_GROUP_RELEASE_NAME es el nombre con el que se instaló el chart apigee-virtualhost. En la versión híbrida 1.10, por lo general, es apigee-virtualhost-ENV_GROUP_NAME. En la versión híbrida 1.11 y posteriores, suele ser ENV_GROUP_NAME.

    3. Revierte los entornos. Repite el siguiente comando para cada entorno mencionado en el archivo de anulaciones.
      helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set env=ENV_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_RELEASE_NAME es el nombre con el que se instaló el chart apigee-env. En la versión híbrida 1.10, por lo general, es apigee-env-ENV_NAME. En la versión híbrida 1.11 y posteriores, suele ser ENV_NAME.

      Para verificar que esté en funcionamiento, comprueba el estado del entorno correspondiente:

      kubectl -n apigee get apigeeenv
      
      NAME                  STATE     AGE   GATEWAYTYPE
      apigee-org1-dev-xxx   running   2d
    4. Revierte la organización:
      helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Para verificar que esté en funcionamiento, comprueba el estado de la organización correspondiente:

      kubectl -n apigee get apigeeorg
      
      NAME                STATE     AGE
      apigee-org1-xxxxx   running   2d
    5. Revierte el administrador de Ingress:
      helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

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

      kubectl -n apigee get deployment apigee-ingressgateway-manager
      
      NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-ingressgateway-manager   2/2     2            2           2d
    6. Revierte Redis:
      helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

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

      kubectl -n apigee get apigeeredis default
      
      NAME      STATE     AGE
      default   running   2d
    7. Revierte la telemetría de Apigee:
      helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

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

      kubectl -n apigee get apigeetelemetry apigee-telemetry
      
      NAME               STATE     AGE
      apigee-telemetry   running   2d
    8. Revierte el controlador de Apigee:
      helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
        --install \
        --namespace apigee-system \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE

      Verifica la instalación del operador de Apigee:

      helm ls -n apigee-system
      
      NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
      operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.2   1.12.2

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

      kubectl -n apigee-system get deploy apigee-controller-manager
      
      NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-controller-manager   1/1     1            1           7d20h
    9. Revierte las CRD de Apigee Hybrid:
      kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false
      
  4. Valida que todos los pods estén en estado de ejecución o completados:
    kubectl get pods -n APIGEE_NAMESPACE
    kubectl get pods -n apigee-system
  5. Valida la versión de todos los componentes. Todos los componentes deben estar en la versión anterior, excepto el almacén de datos:
    helm -n APIGEE_NAMESPACE list
    helm -n apigee-system list

    Por ejemplo:

    helm -n apigee  list
    NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
    datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
    ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
    redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
    telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
    myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0

Restablece cuando apigee-datastore no está en buen estado

Si la actualización del componente apigee-datastore no se realizó de forma correcta, no puedes revertir apigee-datastore de la versión 1.12 a la versión 1.11. En su lugar, debes restablecer a partir de una copia de seguridad realizada a partir de una instalación de la versión v1.11. Usa la siguiente secuencia para restablecer tu versión anterior.

  1. Si no tienes una instalación activa de la versión 1.11 de Apigee Hybrid (por ejemplo, en otra región), crea una instalación nueva de v1.11 con tus gráficos de copia de seguridad y archivos de anulación. Consulta las instrucciones de instalación de la versión 1.11 de Apigee Hybrid.
  2. Restablece la región v1.11 (o la instalación nueva) de tu copia de seguridad mediante las instrucciones que se indican en:
  3. Verifica el tráfico a la instalación restablecida
  4. Opcional: Quita la instalación de la versión 1.12 según las instrucciones que aparecen en Desinstala el entorno de ejecución híbrido.

Reversión y recuperación multirregionales

Revierte cuando apigee-datastore está en buen estado

En este procedimiento, se explica cómo revertir cada componente de Apigee Hybrid de la versión 1.12 a la v1.11, excepto apigee-datastore. El componente apigee-datastore de la versión 1.12 es retrocompatible con los componentes híbridos de la versión 1.11.

  1. Antes de iniciar la reversión, valida que todos los pods estén en estado de ejecución:
    kubectl get pods -n APIGEE_NAMESPACE
    kubectl get pods -n apigee-system
  2. Asegúrate de que todos los nodos de Cassandra en todas las regiones estén en el estado UN (Up / Normal). Si algún nodo de Cassandra está en un estado diferente, resuélvelo primero antes de comenzar el proceso de actualización.

    Puedes validar el estado de tus nodos de Cassandra con los siguientes comandos:

    1. Genera una lista de los Pods de Cassandra:
      kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

      Por ejemplo:

      kubectl get pods -n apigee -l app=apigee-cassandra
      NAME                         READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          2h
      apigee-cassandra-default-1   1/1     Running   0          2h
      apigee-cassandra-default-2   1/1     Running   0          2h
      apigee-cassandra-default-3   1/1     Running   0          16m
      apigee-cassandra-default-4   1/1     Running   0          14m
      apigee-cassandra-default-5   1/1     Running   0          13m
      apigee-cassandra-default-6   1/1     Running   0          9m
      apigee-cassandra-default-7   1/1     Running   0          9m
      apigee-cassandra-default-8   1/1     Running   0          8m
    2. Verifica el estado de los nodos de cada Pod de Cassandra con el comando kubectl nodetool status:
      kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME -- nodetool -u JMX_USER -pw JMX_PASSWORD

      Por ejemplo:

      kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u jmxuser -pw JMX_PASSWORD status
      Datacenter: us-east1
      ====================
      Status=Up/Down
      |/ State=Normal/Leaving/Joining/Moving
      --  Address      Load        Tokens   Owns (effective)   Host ID                                Rack
      UN  10.16.2.6    690.17 KiB  256      48.8%              b02089d1-0521-42e1-bbed-900656a58b68   ra-1
      UN  10.16.4.6    705.55 KiB  256      51.6%              dc6b7faf-6866-4044-9ac9-1269ebd85dab   ra-1
      UN  10.16.11.11  674.36 KiB  256      48.3%              c7906366-6c98-4ff6-a4fd-17c596c33cf7   ra-1
      UN  10.16.1.11   697.03 KiB  256      49.8%              ddf221aa-80aa-497d-b73f-67e576ff1a23   ra-1
      UN  10.16.5.13   703.64 KiB  256      50.9%              2f01ac42-4b6a-4f9e-a4eb-4734c24def95   ra-1
      UN  10.16.8.15   700.42 KiB  256      50.6%              a27f93af-f8a0-4c88-839f-2d653596efc2   ra-1
      UN  10.16.11.3   697.03 KiB  256      49.8%              dad221ff-dad1-de33-2cd3-f1.672367e6f   ra-1
      UN  10.16.14.16  704.04 KiB  256      50.9%              1feed042-a4b6-24ab-49a1-24d4cef95473   ra-1
      UN  10.16.16.1   699.82 KiB  256      50.6%              beef93af-fee0-8e9d-8bbf-efc22d653596   ra-1

    Si no todos los pods de Cassandra están en un estado UN, sigue las instrucciones en Quita nodos DOWN del clúster de Cassandra.

  3. Navega al directorio en el que se instalaron los charts anteriores de Helm para Apigee Hybrid
  4. Cambia el contexto a la región que se actualizó
    kubectl config use-context UPGRADED_REGION_CONTEXT
        
  5. Valida que todos los Pods estén en estado de ejecución:
    kubectl get pods -n APIGEE_NAMESPACE
    kubectl get pods -n apigee-system
  6. Usa el comando helm para asegurarte de que todas las versiones se hayan actualizado a Hybrid v1.12:
    helm -n APIGEE_NAMESPACE list
    helm -n apigee-system list

    Por ejemplo:

    helm -n apigee list
    NAME             NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
    datastore        apigee     2         2024-03-29 17:08:07.917848253 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
    ingress-manager  apigee     2         2024-03-29 17:21:02.917333616 +0000 UTC  deployed  apigee-ingress-manager-1.12.0  1.12.0
    redis            apigee     2         2024-03-29 17:19:51.143728084 +0000 UTC  deployed  apigee-redis-1.12.0            1.12.0
    telemetry        apigee     2         2024-03-29 17:16:09.883885403 +0000 UTC  deployed  apigee-telemetry-1.12.0        1.12.0
    myhybridorg      apigee     2         2024-03-29 17:21:50.899855344 +0000 UTC  deployed  apigee-org-1.12.0              1.12.0
  7. Revierte cada componente excepto apigee-datastore con los siguientes comandos:
    1. Crea la siguiente variable de entorno:
      • PREVIOUS_HELM_CHARTS_HOME: El directorio en el que se instalaron los charts anteriores de Helm para Apigee Hybrid. Esta es la versión a la que estás revirtiendo.
    2. Revierte los hosts virtuales. Repite el siguiente comando para cada grupo de entornos mencionado en el archivo de anulaciones.
      helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set envgroup=ENV_GROUP_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_GROUP_RELEASE_NAME es el nombre con el que se instaló el chart apigee-virtualhost. En la versión híbrida 1.10, por lo general, es apigee-virtualhost-ENV_GROUP_NAME. En la versión híbrida 1.11 y posteriores, suele ser ENV_GROUP_NAME.

    3. Revierte los entornos. Repite el siguiente comando para cada entorno mencionado en el archivo de anulaciones.
      helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set env=ENV_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_RELEASE_NAME es el nombre con el que se instaló el chart apigee-env. En la versión híbrida 1.10, por lo general, es apigee-env-ENV_NAME. En la versión híbrida 1.11 y posteriores, suele ser ENV_NAME.

      Para verificar que cada entorno esté en funcionamiento, comprueba el estado del entorno correspondiente:

      kubectl -n apigee get apigeeenv
      
      NAME                  STATE     AGE   GATEWAYTYPE
      apigee-org1-dev-xxx   running   2d
    4. Revierte la organización:
      helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Para verificar que esté en funcionamiento, comprueba el estado de la organización correspondiente:

      kubectl -n apigee get apigeeorg
      
      NAME                STATE     AGE
      apigee-org1-xxxxx   running   2d
    5. Revierte el administrador de Ingress:
      helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

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

      kubectl -n apigee get deployment apigee-ingressgateway-manager
      
      NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-ingressgateway-manager   2/2     2            2           2d
    6. Revierte Redis:
      helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

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

      kubectl -n apigee get apigeeredis default
      
      NAME      STATE     AGE
      default   running   2d
    7. Revierte la telemetría de Apigee:
      helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

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

      kubectl -n apigee get apigeetelemetry apigee-telemetry
      
      NAME               STATE     AGE
      apigee-telemetry   running   2d
    8. Revierte el controlador de Apigee:
      helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
        --install \
        --namespace apigee-system \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Verifica la instalación del operador de Apigee:

      helm ls -n apigee-system
      
      NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
      operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.2   1.12.2

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

      kubectl -n apigee-system get deploy apigee-controller-manager
      
      NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-controller-manager   1/1     1            1           7d20h
    9. Revierte las CRD de Apigee Hybrid:
      kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false
      
  8. Valida la versión de todos los componentes. Todos los componentes deben estar en la versión anterior, excepto datastore:
    helm -n APIGEE_NAMESPACE list
    helm -n apigee-system list

    Por ejemplo:

    helm -n apigee  list
    NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
    datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
    ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
    redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
    telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
    myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0
    

    En este punto, todas las actualizaciones, excepto datastore, se revertiron a la versión anterior.

Recupera una instalación multirregional a una versión anterior

Recupera la región en la que la actualización falló en una actualización multirregional mediante la eliminación de las referencias a ella de las instalaciones de varias regiones. Este método solo es posible cuando hay al menos 1 región publicada en Hybrid 1.11. El almacén de datos v1.12 es compatible con los componentes de v1.11.

Para recuperar regiones con errores a partir de una región en buen estado, sigue estos pasos:

  1. Redirecciona el tráfico de la API de las regiones afectadas a la región que funciona. Planifica la capacidad según corresponda para admitir el tráfico desviado de las regiones con errores.
  2. Quita la región afectada. Para cada región afectada, sigue los pasos descritos en Retira una región híbrida. Espera a que se complete el retiro de servicio antes de continuar con el siguiente paso.

  3. Limpia la región con errores según las instrucciones de Recupera una región de una actualización con errores.
  4. Recupera la región afectada. Para recuperar, crea una región nueva, como se describe en Implementación multirregional en GKE, GKE On-Prem y AKS.

Restablece una instalación multirregional a partir de una copia de seguridad con apigee-datastore en mal estado

Si la actualización del componente apigee-datastore no se realizó de forma correcta, no puedes revertir de la versión 1.12 a la versión 1.11. En su lugar, debes restablecer a partir de una copia de seguridad realizada a partir de una instalación de la versión v1.11. Usa la siguiente secuencia para restablecer tu versión anterior.

  1. Si no tienes una instalación activa de la versión 1.11 de Apigee Hybrid (por ejemplo, en otra región), crea una instalación nueva de v1.11 con tus gráficos de copia de seguridad y archivos de anulación. Consulta las instrucciones de instalación de la versión 1.11 de Apigee Hybrid.
  2. Restablece la región v1.11 (o la instalación nueva) de tu copia de seguridad mediante las instrucciones que se indican en:
  3. Verifica el tráfico a la instalación restablecida
  4. Para las instalaciones multirregionales, vuelve a compilar y restablece la siguiente región. Consulta las instrucciones en Restablece a partir de una copia de seguridad en Restablece en varias regiones.
  5. Quita la instalación de la versión 1.12 según las instrucciones en Desinstala el entorno de ejecución híbrido.

APÉNDICE: Recupera una región de una actualización con errores

Quita un centro de datos si la actualización falla de la versión 1.11 a la 1.12.

  1. Valida el estado del clúster de Cassandra desde una región activa:
    1. Cambia el contexto de kubectl a la región que se quitará:
      kubectl config use-context CONTEXT_OF_LIVE_REGION
    2. Genera una lista de los Pods de Cassandra:
      kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

      Por ejemplo:

      kubectl get pods -n apigee -l app=apigee-cassandra
      NAME                 READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          2h
      apigee-cassandra-default-1   1/1     Running   0          2h
      apigee-cassandra-default-2   1/1     Running   0          2h
    3. Ejecuta uno de los Pods de Cassandra:
      kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash
    4. Verifica el estado del clúster de Cassandra:
      nodetool -u JMX_USER -pw JMX_PASSWORD status

      El resultado debería ser similar a lo siguiente:

      Datacenter: dc-1
      ================
      Status=Up/Down
      |/ State=Normal/Leaving/Joining/Moving
      --  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
      UN  10.48.12.16  813.84 KiB  256          100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
      UN  10.48.14.16  859.89 KiB  256          100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
      UN  10.48.0.18   888.95 KiB  256          100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
      
    5. Describe el clúster para verificar que solo veas las IP de los Pods de Cassandra de la región activa y que todas tengan la misma versión de esquema:
      nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

      El resultado debería ser similar a lo siguiente:

      nodetool -u JMX_USER -pw JMX_PASSWORD describecluster
      
      Schema versions:
          4bebf2de-0582-31b4-9c5f-e36f60127e1b: [10.48.14.16, 10.48.12.16, 10.48.0.18]
      
  2. Limpia la replicación del espacio de claves de Cassandra:
    1. Obtén el trabajo user-setup y bórralo. Se creará un trabajo user-setup nuevo de inmediato.
      kubectl get jobs -n APIGEE_NAMESPACE

      Por ejemplo:

      kubectl get jobs -n apigee
        NAME                                                           COMPLETIONS   DURATION   AGE
        apigee-cassandra-schema-setup-myhybridorg-8b3e61d          1/1           6m35s      3h5m
        apigee-cassandra-schema-val-myhybridorg-8b3e61d-28499150   1/1           10s        9m22s
       apigee-cassandra-user-setup-myhybridorg-8b3e61d            0/1           21s        21s
      
      kubectl delete jobs USER_SETUP_JOB_NAME -n APIGEE_NAMESPACE

      El resultado debería mostrar el inicio del trabajo nuevo:

      kubectl delete jobs apigee-cassandra-user-setup-myhybridorg-8b3e61d -n apigee
      
        apigee-cassandra-user-setup-myhybridorg-8b3e61d-wl92b         0/1     Init:0/1    0               1s
        
    2. Para validar la configuración de la replicación del espacio de claves de Cassandra, crea un contenedor de cliente mediante las instrucciones que se indican en Crea el contenedor del cliente.
    3. Obtén todos los espacios de claves. Ejecuta el Pod cassandra-client y, luego, inicia un cliente cqlsh:
      kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

      Conéctate al servidor de Cassandra con ddl user, ya que tiene los permisos necesarios para ejecutar los siguientes comandos:

      cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

      Obtén los espacios de claves:

      select * from system_schema.keyspaces;

      El resultado debería ser similar a lo siguiente, en el que dc-1 es el DC en vivo:

      select * from system_schema.keyspaces;
      
       keyspace_name            | durable_writes | replication
      --------------------------+----------------+--------------------------------------------------------------------------------
         kvm_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                    system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                  system_schema |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
       quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
       cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         rtc_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
             system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                         system |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                         perses |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                  system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         kms_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      
      (11 rows)
      
    4. Si, por algún motivo, el trabajo user-setup sigue generando errores y la validación falla, usa los siguientes comandos para corregir la replicación en los espacios de claves.
      kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

      Conéctate al servidor de Cassandra con ddl user, ya que tiene los permisos necesarios para ejecutar los siguientes comandos:

      cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

      Obtén los espacios de claves:

      select * from system_schema.keyspaces;

      Usa los nombres de espacio de claves del comando anterior y reemplázalos en los siguientes ejemplos.

      alter keyspace quota_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace kms_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace kvm_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace cache_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace perses_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace rtc_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace system_distributed WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace system_traces WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
    5. Valida que todos los espacios de claves se repliquen en la región correcta con el siguiente comando cqlsh:
      select * from system_schema.keyspaces;

      Por ejemplo:

      select * from system_schema.keyspaces;
      
       keyspace_name           | durable_writes | replication
      -------------------------+----------------+--------------------------------------------------------------------------------
      kvm_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                system_auth    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
              system_schema    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
      quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      rtc_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         system_distributed    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                     system    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                     perses    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
              system_traces    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      kms_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      
      (11 rows)

En esta etapa, quitaste por completo todas las referencias del DC inactivo del clúster de Cassandra.

APÉNDICE: Quita los nodos DOWN del clúster de Cassandra

Usa este procedimiento cuando reviertas una instalación multirregión y no todos los Pods de Cassandra estén en un estado Up/Normal (UN).

  1. Ejecuta uno de los Pods de Cassandra:
    kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash
  2. Verifica el estado del clúster de Cassandra:
    nodetool -u JMX_USER -pw JMX_PASSWORD status
  3. Valida que el nodo esté inactivo (DN). Ejecuta el Pod de Cassandra en una región en la que no se pueda iniciar.
    Datacenter: dc-1
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
    UN  10.48.12.16  1.15 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
    UN  10.48.0.18   1.21 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
    UN  10.48.14.16  1.18 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
    
    Datacenter: us-west1
    ====================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
    DN  10.8.4.4     432.42 KiB  256     100.0%            cd672398-5c45-4c88-a424-86d757951e53  rc-1
    UN  10.8.19.6    5.8 MiB     256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
    UN  10.8.21.5    5.74 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1
    
  4. Quita la referencia al nodo abajo (DN). En el ejemplo anterior, quitaremos la referencia del host 10.8.4.4.
    kubectl exec -it -n apigee apigee-cassandra-default-2 -- /bin/bash
     nodetool -u JMX_USER -pw JMX_PASSWORD removenode HOST_ID
    
  5. Después de quitar la referencia, finaliza el Pod. Se debería mostrar el nuevo Pod de Cassandra y unirse al clúster.
    kubectl delete pod -n POD_NAME
  6. Valida que el nuevo Pod de Cassandra se haya unido al clúster.
    Datacenter: dc-1
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
    UN  10.48.12.16  1.16 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
    UN  10.48.0.18   1.22 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
    UN  10.48.14.16  1.19 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
    
    Datacenter: us-west1
    ====================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
    UN  10.8.19.6    5.77 MiB    256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
    UN  10.8.4.5     246.99 KiB  256     100.0%            0182e675-eec8-4d68-a465-69211b621601  rc-1
    UN  10.8.21.5    5.69 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

En este punto, puedes continuar con la actualización o revertir las regiones restantes del clúster.

APÉNDICE: Solución de problemas: apigee-datastore en estado atascado después de la reversión

Usa este procedimiento cuando hayas revertido apigee-datastore a la versión Hybrid 1.11 después de la actualización y esté en estado de bloqueo.

  1. Antes de volver a corregir el estado del controlador del almacén de datos, valida que esté en un estado releasing y que los Pods no aparezcan junto con el estado del clúster de Cassandra.
    1. Valida con el comando Helm que se revirtió el almacén de datos:
      helm -n APIGEE_NAMESPACE list

      Por ejemplo:

      helm -n apigee list
      NAME              NAMESPACE  REVISION  UPDATED                                   STATUS    CHART                              APP VERSION
      datastore         apigee     3         2024-04-04 22:15:08.792539892 +0000 UTC   deployed   apigee-datastore-1.11.0           1.11.0
      ingress-manager   apigee     1         2024-04-02 22:24:27.564184968 +0000 UTC   deployed   apigee-ingress-manager-1.12.0     1.12.0
      redis             apigee     1         2024-04-02 22:23:59.938637491 +0000 UTC   deployed   apigee-redis-1.12.0               1.12.0
      telemetry         apigee     1         2024-04-02 22:23:39.458134303 +0000 UTC   deployed   apigee-telemetry-1.12             1.12.0
      myhybridorg       apigee     1         2024-04-02 23:36:32.614927914 +0000 UTC   deployed   apigee-org-1.12.0                 1.12.0
      
    2. Obtén el estado de los Pods de Cassandra:
      kubectl get pods -n APIGEE_NAMESPACE

      Por ejemplo:

      kubectl get pods -n apigee
      NAME                         READY   STATUS             RESTARTS      AGE
      apigee-cassandra-default-0   1/1     Running            0             2h
      apigee-cassandra-default-1   1/1     Running            0             2h
      apigee-cassandra-default-2   0/1     CrashLoopBackOff   4 (13s ago)   2m13s
      
    3. Valida que el controlador apigeeds esté atascado en el estado de lanzamiento:
      kubectl get apigeeds -n APIGEE_NAMESPACE

      Por ejemplo:

      kubectl get apigeeds -n apigee
      NAME      STATE       AGE
      default   releasing   46h
    4. Valida el estado de los nodos de Cassandra (observa que un nodo está en estado DN, que es el nodo atascado en estado CrashLoopBackOff):
      kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

      Por ejemplo:

      kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
      Defaulted container "apigee-cassandra" out of: apigee-cassandra, apigee-cassandra-ulimit-init (init)
      Datacenter: us-west1
      ====================
      Status=Up/Down
      |/ State=Normal/Leaving/Joining/Moving
      --   Address       Load       Tokens   Owns (effective)   Host ID                               Rack
      UN   10.68.7.28    2.12 MiB   256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3  rc-1
      UN   10.68.10.29   2.14 MiB   256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452  rc-1
      DN   10.68.6.26    5.77 MiB   256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1
      
  2. Actualiza el almacén de datos mediante los gráficos 1.12.
    helm upgrade datastore APIGEE_HELM_1.12.0_HOME/apigee-datastore/   --install   --namespace APIGEE_NAMESPACE   -f overrides.yaml
  3. Valida que todos los Pods sean Running y que el clúster de Cassandra vuelva a estar en buen estado.
    1. Vuelve a validar que todos los Pods sean READY:
      kubectl get pods -n APIGEE_NAMESPACE

      Por ejemplo:

      kubectl get pods -n apigee
      NAME                         READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          29h
      apigee-cassandra-default-1   1/1     Running   0          29h
      apigee-cassandra-default-2   1/1     Running   0          60m
    2. Valida el estado del clúster de Cassandra:
      kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

      Por ejemplo:

      kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
      Datacenter: us-west1
      ====================
      Status=Up/Down
      |/ State=Normal/Leaving/Joining/Moving
      --   Address       Load      Tokens   Owns (effective)   Host ID                                Rack
      UN   10.68.4.15    2.05 MiB  256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1
      UN   10.68.7.28    3.84 MiB  256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3   rc-1
      UN   10.68.10.29   3.91 MiB  256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452   rc-1
        
    3. Valida el estado del controlador apigeeds:
      kubectl get apigeeds -n APIGEE_NAMESPACE

      Por ejemplo:

      kubectl get apigeeds -n apigee
      NAME      STATE     AGE
      default   running   2d1h

En este punto, corregiste el almacén de datos y debería estar en un estado running.