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
yTargetV2
ya no se usarán de forma predeterminada. Todas las métricas de proxy y de destino se publicarán en los recursos supervisadosProxy
yTarget
.Para seguir emitiendo métricas a los recursos supervisados
ProxyV2
yTargetV2
, configurametrics.disablePrometheusPipeline
comotrue
enoverrides.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 realizaCassandra
. - 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 componenteapigee-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.
- Si el componente
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:
- 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.
- 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.
- Actualiza la región recién agregada a Hybrid 1.12.
- Cambia el tráfico a la región nueva y valida el tráfico.
- Una vez validada, actualiza la región anterior con la versión Hybrid 1.12.
- Vuelve a cambiar todo el tráfico a la región anterior y valida el tráfico.
- Quita la región nueva.
Consideraciones antes de actualizar una instalación multirregional
Apigee recomienda la siguiente secuencia para actualizar una instalación multirregional:
- Crea una copia de seguridad y valida los datos de cada región antes de comenzar la actualización.
- 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.
- Valida el tráfico en la región recién actualizada.
- Actualiza cada región posterior solo después de validar el tráfico en la región anterior.
- 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.
- Si administras tu instalación de Hybrid con
apigeectl
, primero debes migrar tus clústeres a la administración de Helm. Consulta Migra Apigee Hybrid a Helm desde apigeectl en la documentación de Hybrid v1.11. - Si tu instalación híbrida ejecuta una versión anterior a la versión 1.11, debes actualizar a la versión 1.11 antes de actualizar a la versión 1.12. Consulta cómo actualizar Apigee híbrido a la versión 1.11.
- Si administras tu instalación de Hybrid con
- 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:
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:
-
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 . . . - Borra un Pod:
kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME
Por ejemplo:
kubectl delete pod -n apigee apigee-cassandra-default-0
-
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 . . .
-
Genera una lista de los Pods de Cassandra:
- 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:
- 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 - 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
- Genera una lista de los Pods de Cassandra:
Crea una copia de seguridad de los directorios de instalación híbridos
- En estas instrucciones, se usa la variable de entorno APIGEE_HELM_CHARTS_HOME para el directorio en tu sistema de archivos en el que instalaste los charts de Helm. Si es necesario, cambia el directorio a este directorio y define la variable con el siguiente comando:
Linux
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
macOS
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
Windows
set APIGEE_HELM_CHARTS_HOME=%CD%
echo %APIGEE_HELM_CHARTS_HOME%
- Realiza una copia de seguridad de tu directorio
$APIGEE_HELM_CHARTS_HOME/
versión 1.11. Puedes usar cualquier proceso de copia de seguridad. Por ejemplo, puedes crear un archivotar
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
- 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.
- 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/
-
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
- 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
- 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
- Instala las CRD de Apigee actualizadas:
-
Usa la función de ejecución de prueba
kubectl
mediante la ejecución del siguiente comando:kubectl apply -k apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false --dry-run=server
-
Después de validar con el comando de ejecución de prueba, ejecuta el siguiente comando:
kubectl apply -k apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false
- Valida la instalación con el comando
kubectl get crds
:kubectl get crds | grep apigee
La respuesta debería ser similar a la siguiente:
apigeedatastores.apigee.cloud.google.com 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
-
-
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 etiquetacloud.google.com/gke-nodepool=apigee-runtime
. Puedes personalizar las etiquetas de tu grupo de nodos en el archivooverrides.yaml
.Para obtener más información, consulta Configura grupos de nodos dedicados.
Instala los gráficos de Helm de Apigee Hybrid
- Si no lo hiciste, navega a tu directorio
APIGEE_HELM_CHARTS_HOME
. Ejecuta los siguientes comandos desde ese directorio. - Actualiza el operador o controlador de Apigee:
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
- 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
- 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
- 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
- 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
- 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
- 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, esapigee-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
- ENV_RELEASE_NAME es el nombre con el que se instaló el chart
-
Actualiza los grupos de entornos (
virtualhosts
).- 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, esapigee-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
- 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
- Debes actualizar un grupo de entornos (virtualhost) a la vez. Especifica el grupo de
entornos con
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:
-
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
-
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
-
Revierte cada componente excepto
apigee-datastore
con los siguientes comandos:- 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.
- 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, esapigee-virtualhost-ENV_GROUP_NAME
. En la versión híbrida 1.11 y posteriores, suele ser ENV_GROUP_NAME. - 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, esapigee-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
- 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
- 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
- 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
- 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
- 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
- Revierte las CRD de Apigee Hybrid:
kubectl apply -k $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false
- Crea la siguiente variable de entorno:
-
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
-
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.
- 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.
- Restablece la región v1.11 (o la instalación nueva) de tu copia de seguridad mediante las instrucciones que se indican en:
- Copias de seguridad de Cloud Storage Interface (CSI): copia de seguridad y restablecimiento de CSI de Cassandra.
- Copias de seguridad que no son de CSI: Restablece en una sola región.
- Verifica el tráfico a la instalación restablecida
- 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.
-
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
- 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:
- 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 - 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. - Genera una lista de los Pods de Cassandra:
- Navega al directorio en el que se instalaron los charts anteriores de Helm para Apigee Hybrid
-
Cambia el contexto a la región que se actualizó
kubectl config use-context UPGRADED_REGION_CONTEXT
-
Valida que todos los Pods estén en estado de ejecución:
kubectl get pods -n APIGEE_NAMESPACE
kubectl get pods -n apigee-system
-
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
-
Revierte cada componente excepto
apigee-datastore
con los siguientes comandos:- 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.
- 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, esapigee-virtualhost-ENV_GROUP_NAME
. En la versión híbrida 1.11 y posteriores, suele ser ENV_GROUP_NAME. - 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, esapigee-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
- 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
- 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
- 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
- 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
- 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
- Revierte las CRD de Apigee Hybrid:
kubectl apply -k $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false
- Crea la siguiente variable de entorno:
-
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:
- 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.
- 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.
- Limpia la región con errores según las instrucciones de Recupera una región de una actualización con errores.
- 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.
- 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.
- Restablece la región v1.11 (o la instalación nueva) de tu copia de seguridad mediante las instrucciones que se indican en:
- Copias de seguridad de Cloud Storage Interface (CSI): copia de seguridad y restablecimiento de CSI de Cassandra.
- Copias de seguridad que no son de CSI: Restablece en varias regiones.
- Verifica el tráfico a la instalación restablecida
- 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.
- 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.
-
Valida el estado del clúster de Cassandra desde una región activa:
-
Cambia el contexto de kubectl a la región que se quitará:
kubectl config use-context CONTEXT_OF_LIVE_REGION
- 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 -
Ejecuta uno de los Pods de Cassandra:
kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash
-
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
-
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]
-
Cambia el contexto de kubectl a la región que se quitará:
-
Limpia la replicación del espacio de claves de Cassandra:
-
Obtén el trabajo
user-setup
y bórralo. Se creará un trabajouser-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 21skubectl 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 - 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.
-
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) - 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'};
- 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)
-
Obtén el trabajo
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
).
-
Ejecuta uno de los Pods de Cassandra:
kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash
-
Verifica el estado del clúster de Cassandra:
nodetool -u JMX_USER -pw JMX_PASSWORD status
-
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
-
Quita la referencia al nodo abajo (
DN
). En el ejemplo anterior, quitaremos la referencia del host10.8.4.4
.kubectl exec -it -n apigee apigee-cassandra-default-2 -- /bin/bash nodetool -u JMX_USER -pw JMX_PASSWORD removenode HOST_ID
-
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
-
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.
-
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.-
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 -
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 -
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 -
Valida el estado de los nodos de Cassandra (observa que un nodo está en estado
DN
, que es el nodo atascado en estadoCrashLoopBackOff
):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
-
Valida con el comando Helm que se revirtió el almacén de datos:
-
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
-
Valida que todos los Pods sean
Running
y que el clúster de Cassandra vuelva a estar en buen estado.-
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 -
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 -
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
-
Vuelve a validar que todos los Pods sean
En este punto, corregiste el almacén de datos y debería estar en un estado running
.