Guía del usuario de la vista previa:
Vista previa de los procedimientos nuevos de instalación y administración para Apigee hybrid v1.8.
En este documento:
- Vista previa
- Descripción general
- Requisitos previos
- Instalación básica de Apigee hybrid
- Instalación personalizada de Apigee Hybrid
- Descarga archivos de configuración
- Crear espacio de nombres
- Usa imágenes de Docker de repositorios privados (opcional)
- Configura imagePullSecrets (opcional)
- Configura el proxy de reenvío (opcional)
- Especifica certificados TLS de entrada
- Actualiza la implementación de entrada
- Configura cuentas de servicio personalizadas de Google Cloud
- Usa Workload Identity
- Edita recursos yamls
- Crea un controlador y recursos de inicialización
- Otorga permisos a la cuenta de servicio de Synchronizer para interactuar con el plano de control
- Crea componentes del plano de datos de Apigee
- Espera a que se inicien los recursos
- Personaliza la instalación de cert-manager en un espacio de nombres personalizado
- Kustomize y componentes
- Conceptos
- Información sobre la secuencia de comandos
- Estructura de carpetas de configuración de Apigee Hybrid
- Almacena claves de cuentas de servicio en almacenes de datos externos
- Actualización de Apigee Hybrid
- Reversión de Apigee Hybrid
- Limpieza
- Borra un entorno
- Instalación de varias instancias
Vista previa
Este documento está dirigido a los operadores de Apigee (usuarios que instalan, gestionan o administran instalaciones de Apigee hybrid). El requisito para instalar Apigee Hybrid en una de las plataformas de Kubernetes compatibles es seguir las instrucciones de este documento. Se recomienda que crees una organización de Apigee de evaluación para probar los siguientes pasos.
Comentarios
Envía comentarios sobre este proceso a Apigee-hybrid-install-preview@google.com.
Descripción general
La nueva experiencia de instalación de Apigee Hybrid instala componentes de Apigee mediante kubectl y, además, integra la instalación y administración de Apigee Hybrid en herramientas de organización de configuración de Kubernetes como Kustomize. Las validaciones y la visibilidad mejoradas de los componentes que se instalan proporcionan una mejor capacidad de depuración y mejoran el proceso de instalación general.
Una secuencia de comandos de instalación, apigee-hybrid-setup.sh
, proporciona una herramienta fácil para la instalación básica. Puedes usar esa opción a fin de crear tu instalación de hybrid y, luego, modificarla para que se adapte a tus necesidades con kubectl
, o puedes crear la instalación de hybrid desde cero con kubectl
.
Todas las propiedades de configuración de Apigee hybrid se almacenan en archivos yaml, una para cada componente principal. Esto permite un control mucho más detallado de tu instalación de hybrid en tu entorno de Kubernetes. Puedes encontrar los archivos de configuración y las secuencias de comandos de instalación en el repositorio en GitHub.
Cambios en el nuevo proceso de instalación
Apigee está cambiando el proceso de instalación de Apigee Hybrid por los siguientes motivos:
- El nuevo método para instalar Apigee Hybrid se puede integrar en herramientas de CI/CD de Kubernetes existentes, como Argo, Flux o Anthos Config Management, que no usan un
overrides.yaml
archivo de configuración. - Apigee Hybrid proporcionó
apigeectl
, una herramienta de plantillas personalizada que genera manifiestos de Kubernetes (entre otras funciones) para instalar y administrar Apigee Hybrid en clústeres de Kubernetes. El nuevo proceso de instalación y administración proporciona una experiencia similar a la de otros proveedores de software. - El nuevo proceso permite la instalación básica con rapidez mediante la creación automática de cuentas de servicio con los permisos necesarios, los certificados TLS, la prepropagación de valores predeterminados y otros elementos fundamentales necesarios.
Requisitos previos
Antes de usar esta instalación de vista previa, debes cumplir con los siguientes requisitos previos:
Versión de vista previa
Esta vista previa está diseñada para funcionar con Apigee hybrid versión 1.8.x. Las versiones posteriores de Apigee hybrid no son compatibles.
Configuración de Apigee hybrid
Antes de continuar con la instalación real de Apigee hybrid, se espera que hayas completado las siguientes instrucciones que se enumeran en las siguientes secciones de la documentación:
- Configuración del proyecto y la organización
- Descripción general de los requisitos para instalar Apigee Hybrid.
- Paso 1: Habilitar las APIs
- Paso 2: Crear una organización
- Paso 3: Crea un entorno y un grupo de entornos
- Configurar el entorno de ejecución híbrido
Herramientas
Además, debes tener las siguientes herramientas descargadas y configuradas en tu estación de trabajo:
curl
- Se requiere
docker
para ejecutar la secuencia de comandosapigee-hybrid-setup.sh
. Sigue las instrucciones en Obtén Docker para instalar Docker. envsubst
debe estar disponible en la mayoría de los sistemas basados en Linux/UNIX. Para MacOS y otros sistemas, sigue las instrucciones de este repositorio.jq
debe estar instalado. Descarga jq.kpt
Descarga kpt.kubectl
versión 1.23 o posterior Consulta Install Tools: kubectl en la documentación de Kubernetes.
Variables comunes que se usan en esta guía
En esta guía, se usan las siguientes variables de entorno en varios pasos. Puedes definirlos en la línea de comandos o con una secuencia de comandos, o puedes reemplazar el texto de los comandos cuando los ingreses.
APIGEE_NAMESPACE
: tu espacio de nombres de Apigee. El valor predeterminado esapigee
. Sin embargo, puedes usar un espacio de nombres diferente.CLUSTER_NAME
: Es el nombre del clúster en el que se instalará Apigee Hybrid. Este es el clúster que creas en el Paso 1: Crea un clústerCLUSTER_LOCATION
: es la región del clúster. En los procedimientos de esta guía, se supone que usas un clúster regional. Si usas un clúster zonal, consulta las instrucciones en el Paso 1: Crea un clúster.ENV_GROUP
: Es el nombre del grupo de entornos para la instalación de Apigee Hibrid. Este es el grupo de entornos que creas en el Paso 3: Crea un grupo de entornos. Puedes crear varios grupos de entornos.ENV_NAME
: Es el nombre del grupo de entornos para la instalación de Apigee Hibrid. Este es el grupo de entornos que creas en el Paso 3: Crea un grupo de entornos. Puedes crear varios grupos de entornos.INSTALL_DIR
: El directorio en el que se instala Apigee Hybrid. De forma predeterminada, este es el subdirectorioapigee-hybrid-install/
del directorio en el que descargas el instalador, por ejemplo:/myhybrid/apigee-hybrid-install/
. Este es el directorio raíz de la estructura de archivos documentada en Estructura de carpetas de configuración de Apigee Hybrid.INSTANCE_DIR
: El directorio para una instancia específica de Apigee Hybrid. De forma predeterminada, la primera instancia se llamainstance-1
. El directorio dir de la instancia es un subdirectorio de${INSTALL_DIR}/overlays/instances/
. Puedes especificar cualquier nombre para tus instancias híbridas. Consulta Instalación de varias instancias.ORG_NAME
: El nombre de tu organización de Apigee Hybrid. Debe ser el mismo que el ID del proyecto de Google Cloud. Consulta Paso 2: Crea una organización.
Instalación básica de Apigee Hybrid
Para instalar Apigee Hybrid con rapidez sin una personalización intensa, puedes usar el siguiente procedimiento de dos pasos.
- Un solo entorno
- Un solo grupo de entornos
- Se crea y usa una sola cuenta de servicio de Google Cloud para todos los componentes individuales.
- Valores predeterminados para todas las claves de encriptación y contraseñas.
Descarga archivos de configuración
Si deseas descargar y preparar los archivos de configuración, clona el repositorio de GitHub en https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1
:
Clone el repositorio:
git clone https://github.com/apigee/apigee-hybrid-install.git
Navega al directorio del repositorio clonado:
cd apigee-hybrid-install
Crea una rama a partir de la etiqueta preview-1:
git branch preview-1 preview-1 git checkout preview-1
Haz que la secuencia de comandos de configuración sea ejecutable:
chmod +x ./tools/apigee-hybrid-setup.sh
El repositorio clonado tendrá una estructura similar a la que se describe en Estructura de carpetas de configuración de Apigee Hybrid:
Ejecuta la configuración
Ejecuta la secuencia de comandos de shell apigee-hybrid-setup.sh
dentro de la carpeta tools/
.
./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATION --org $ORG_NAME --setup-all
Si experimentas errores, intenta ejecutar la secuencia de comandos por segunda vez.
Estas son otras opciones que puedes usar:
--env $ENV_NAME
especifica el nombre del entorno de Apigee.--envgroup $ENV_GROUP
especifica el grupo de entornos.--ingress-domain $HOSTNAME
especifica el nombre de host que proporcionaste para tu grupo de entornos.--gcp-project-id $PROJECT_ID
especifica el ID del proyecto de Google Cloud.
Para obtener más opciones, consulta Información sobre la secuencia de comandos.
Cualquier error durante la ejecución se imprimirá en el resultado estándar.
Una vez que la secuencia de comandos se complete correctamente, habrás completado la instalación básica de hybrid. Puedes probar tu instalación si creas un proxy de muestra como se detalla en Crea e implementa un proxy de API nuevo.
Instalación personalizada de Apigee Hybrid
Para los usuarios más avanzados que desean un control detallado sobre la instalación, puedes seguir esta secuencia de pasos (para muchos de los pasos dados a continuación, puedes optar por realizar el paso de forma manual o puedes usar la secuencia de comandos de shell para automatizar eso paso individual):
Descarga archivos de configuración
Descarga y prepara los archivos de configuración:
Clona el repositorio de GitHub en
https://github.com/apigee/apigee-hybrid-install/
El repositorio clonado tendrá una estructura similar a la que se describe en Estructura de carpetas de configuración de Apigee Hybrid:
cd
en el directorioapigee-hybrid-install/
Haz que la secuencia de comandos de configuración sea ejecutable:
chmod +x ./tools/apigee-hybrid-setup.sh
Crear espacio de nombres
Crea un espacio de nombres de Kubernetes en tu clúster que contendrá todos los componentes del clúster de Apigee.
kubectl create namespace apigee
Si eliges otro nombre para el espacio de nombres, puedes seguir una de las tres opciones a continuación:
- (Recomendado) Usa
--namespace={YOUR_NAMESPACE_NAME}
mientras completas valores en Edita recursos yamls. Ejecuta los dos comandos siguientes:
Usa
kpt
para especificar el espacio de nombres de Apigee:kpt fn eval "${INSTALL_DIR}/overlays/" \ --image gcr.io/kpt-fn/apply-setters:v0.2.0 -- \ APIGEE_NAMESPACE="${APIGEE_NAMESPACE}" # This is for replacing the namespace in istio discoveryAddress which cannot be # achieved with kpt
Usa
sed
para reemplazar el espacio de nombres en istio discoveryAddress:sed -i -E -e "s/(discoveryAddress: apigee-ingressgateway-manager\.).*(\.svc:15012)/\1${APIGEE_NAMESPACE}\2/" "${INSTALL_DIR}/overlays/controllers/istiod/apigee-istio-mesh-config.yaml"
Como alternativa, puedes cambiar de forma manual los recursos que se crearán en el espacio de nombres que elijas.
Usa imágenes de Docker de repositorios privados (opcional)
Puedes elegir no usar las imágenes alojadas de forma pública y puedes usar las imágenes de tus propios repositorios privados:
- El primer paso es enviar todas las imágenes a tu repositorio privado. Para ello, sigue los pasos que se indican en apigee-pull-push | Apigee X. De forma predeterminada, las imágenes se etiquetan con la versión de Apigee Hybrid a la que corresponden, y se recomienda no editar estas etiquetas. También te recomendamos que no edites los nombres de las imágenes para que la ruta final de la imagen se pueda construir como se explica en Image Hub.
Configura el valor del campo
imageHub
presente dentro del archivo apigee-hybrid-config.yaml en la ruta del host del repositorio privado. (Consulta Image Hub para obtener más detalles).imageHub: "your.private.repo/apigee/hybrid"
Esto garantizará que todos los componentes de Apigee Hybrid usen las imágenes de tu repositorio privado.
Además, puedes usar una imagen privada para elcontrolador y la puerta de enlace de entrada de Apigee, para lo que tendrás que editar apigee-controller-deployment.yaml y apigee-ingressgateway-manager-deployment.yaml, y reemplazar todos los campos image
con la imagen de su repositorio privado.
Configura imagePullSecrets (opcional)
- Crea un secret de Kubernetes que contenga las credenciales para autenticar con los repositorios privados. Consulta Extrae una imagen desde un registro privado para comprender cómo se debe crear el secret.
- Una vez que se crea el secret, lo único que queda es hacer referencia a ese secret. Para ello, edita el archivo apigee-hybrid-config.yaml y configura el valor del campo
imagePullSecret
con el nombre del secret que creaste antes, y habilita el componenteimagePullSecret
en el archivokustomization.yaml
correspondiente.
Si en caso de que especifiques imagePullSecrets
en ambos lugares, el que está presente en el archivo apigee-controller-manager.yaml tendrá prioridad.
Configura el proxy de reenvío (opcional)
Los proxies de reenvío se pueden configurar si agregas el campo forwardProxy
al archivo apigee-hybrid-config.yaml
. Por ejemplo:
forwardProxy: |
scheme: HTTP
host: 10.12.0.47
port: 3128
Especifica certificados TLS de entrada
Usa la secuencia de comandos
./tools/apigee-hybrid-setup.sh --create-ingress-tls-certs
Consulta Información sobre la secuencia de comandos para obtener más detalles sobre esta marca.
Manual
Se espera que proporciones certificados TLS para que se usen en la puerta de enlace de entrada de Istio. Puedes hacer lo siguiente:
- usar certificados firmados por una autoridad conocida mediante los pasos mencionados en Obtén certificados TLS: Un ejemplo | Apigee X
- o generar certificados autofirmados.
Aquí, usaremos certificados autofirmados como ejemplo. Los certificados autofirmados se pueden generar mediante (suponiendo que DOMAIN
se configuró correctamente y debe coincidir con el nombre de host configurado en tu grupo de entornos):
openssl req -nodes -new -x509 -keyout ./tls.key -out ./tls.crt -subj '/CN='$DOMAIN'' -days 3650
Esto creará dos archivos llamados tls.key
y tls.crt
.
Luego, debes crear un secret con el siguiente formato. Puedes usar kubectl create
o kubectl apply
como se explica en Usa el par de clave/certificado personalizado para la autoridad de firma de certificados (opcional):
apiVersion: v1
kind: Secret
metadata:
name: "{ORG_NAME}-{ENV_GROUP_NAME}"
namespace: {$APIGEE_NAMESPACE}
type: Opaque
data:
cert: |
{BASE64_ENCODED_TLS_CRT}
key: |
{BASE64_ENCODED_TLS_KEY}
---
Ejemplo de la creación del secret con kubectl create
:
kubectl create secret tls {ORG_NAME}-{ENV_GROUP_NAME} \
--cert="tls.crt" \
--key="tls.key" \
-n {$APIGEE_NAMESPACE}
Actualiza la implementación de entrada
Para crear o modificar implementaciones de entrada, debes modificar el campo spec.components.ingressGateways
en el recurso personalizado de ApigeeOrganization en bases/initialization/crds/customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
.
De forma predeterminada, creamos una implementación de entrada con parámetros predeterminados (los valores predeterminados se mostrarán en los documentos de referencia de CR ):
ingressGateways:
- name: "prod-1"
Ejemplos:
A. Anula campos de servicio de entrada
ingressGateways:
- name: "prod-1"
serviceSpec:
annotations:
{KEY}: ${VALUE}
loadBalancerIP: ${IP}
B. Cambia los valores mínimos y máximos de las réplicas
ingressGateways:
- name: "prod-1"
autoScaler:
minReplicas: 4
maxReplicas: 10
C. Cómo agregar una nueva implementación de entrada
ingressGateways:
- name: "prod-1"
- name: "prod-2"
Configura cuentas de servicio personalizadas de Google Cloud
Usa la secuencia de comandos
./tools/apigee-hybrid-setup.sh --create-gcp-sa-and-secrets --namespace APIGEE_NAMESPACE
En el ejemplo anterior, APIGEE_NAMESPACE es el espacio de nombres personalizado. El espacio de nombres predeterminado es apigee
.
Consulta Información sobre la secuencia de comandos para obtener más detalles sobre las marcas.
Manual
Las claves de la cuenta de servicio de Google Cloud deben almacenarse como secretos en el clúster. El secret yaml debe tener la siguiente estructura:
apiVersion: v1
kind: Secret
metadata:
name: "{NAME}"
namespace: {APIGEE_NAMESPACE}
type: Opaque
data:
client_secret.json: |
{BASE64_ENCODED_SA_KEY}
Para obtener más detalles sobre lo que requieren todas las cuentas de servicio y los nombres de los secret, consulta la sección Cuentas de servicio de Google Cloud.
Puede elegir un nombre diferente para los secrets, pero luego deberá realizar el cambio correspondiente en el componente en el que se usó el nombre. Por ejemplo, si decides cambiar el nombre del secret de la cuenta de servicio del entorno de ejecución de apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME}
a my-runtime-svc
, tendrás que realizar un cambio correspondiente en el apigee-environment.yaml
para ese entorno.
Usa Workload Identity
Es obligatorio configurar una cuenta de servicio de Google Cloud personalizada o usar identidades de carga de trabajo.
Requisitos previos
Antes de usar identidades de carga de trabajo, asegúrate de que tu clúster de GKE tenga habilitada la compatibilidad. Consulta Actualiza grupos de nodos | Apigee X para obtener más detalles.
Habilita workload-identity
Consulta la sección Identidades de las cargas de trabajo en Kustomize y componentes para obtener detalles sobre cómo habilitar las identidades de las cargas de trabajo antes de la instalación.
Edita recursos yamls
Algunos lugares del componente yaml requieren la presencia de nombres de grupos de entornos, entornos y organizaciones correctos. Puedes establecer estos valores de forma manual o usar la secuencia de comandos de shell para completar estos valores de forma automática.
Usa la secuencia de comandos
./tools/apigee-hybrid-setup.sh --fill-values
Crea un controlador y recursos de inicialización
#Additional steps for openshift
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/openshift
//apigee datastore
kubectl apply -f ${INSTANCE_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/components/openshift-scc/scc.yaml
//telemetry
kubectl apply -f ${INSTANCE_DIR}/overlays/instances/${INSTANCE_DIR}/telemetry/components/openshift-scc/scc.yaml
#Create Apigee initialization kubernetes resources
kubectl apply -f ${INSTALL_DIR}/overlays/initialization/namespace.yaml
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/certificates
kubectl apply --server-side --force-conflicts -k ${INSTALL_DIR}/overlays/initialization/crds
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/webhooks
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/rbac
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/ingress
# Create controller config and controller
kubectl apply -k ${INSTALL_DIR}/overlays/controllers
# Wait for the controllers to be available
kubectl wait deployment/apigee-controller-manager deployment/apigee-ingressgateway-manager -n "${APIGEE_NAMESPACE}" --for=condition=available --timeout=2m
# Create the datastore and redis secrets first and then the rest of the secrets.
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/redis/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/${ENV_NAME}/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/organization/secrets.yaml
Otorga permisos a la cuenta de servicio de Synchronizer para interactuar con el plano de control
Sigue los pasos del Paso 8: Habilita el acceso del sincronizador y reemplaza el nombre de la cuenta de servicio, ya sea apigee-non-prod
o apigee-synchronizer
, con apigee-all-sa
, el nombre de la cuenta de servicio creada por el proceso de instalación nuevo.
★ Importante: Asegúrate de cambiar el nombre de la cuenta de servicio en las instrucciones de Habilita el acceso del sincronizador. De lo contrario, fallará el acceso del sincronizador.
Crea componentes del plano de datos de Apigee
Si cambiaste los nombres de cualquiera de los recursos en los pasos anteriores, deberás realizar el cambio correspondiente en otros archivos YAML en los que se hizo referencia a ese recurso. Cuando finalices, usa los comandos del siguiente ejemplo:
# Create the rest of the resources.
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
para instalar todos los componentes.
Espera a que se inicien los recursos
kubectl wait "apigeedatastore/default" \
"apigeeredis/default" \
"apigeeenvironment/${ORG_NAME}-${ENV_NAME}" \
"apigeeorganization/${ORG_NAME}" \
"apigeetelemetry/apigee-telemetry" \
-n "${APIGEE_NAMESPACE}" --for="jsonpath=.status.state=running" --timeout=15m
Personaliza la instalación de cert-manager en un espacio de nombres personalizado
Personaliza el espacio de nombres en el que se ejecuta cert-manager con el siguiente procedimiento.
Si cert-manager se instala en tu clúster en un espacio de nombres que no sea cert-manager, deberás actualizar el espacio de nombres que se usa para crear el certificado raíz de Apigee.
- Edita el archivo custom.yaml para la creación del certificado:
$INSTALL_DIR/overlays/initialization/certificates/kustomize.yaml
Agrega los siguientes al final del archivo:
- patch: |- - op: replace path: /metadata/namespace value: "gk-cert-manager" target: group: cert-manager.io version: v1 kind: Certificate name: apigee-root-certificate
Guarda el archivo.
Kustomize y componentes
Descripción general
La nueva instalación híbrida hereda la ideología Kustomize de estructurar yamls en forma de Bases y Superposiciones.
- Las bases son archivos que proporciona Apigee y que pueden cambiar entre cada versión nueva de hybrid. No se espera que modifiques estos archivos. Estos archivos contienen algunos valores predeterminados que proporciona Apigee. Todos los archivos en la carpeta de nivel superior
bases/
contienen estas bases. Las Superposiciones contienen la configuración del usuario y sirven como medios a través de los cuales puedes modificar los valores predeterminados especificados en las Bases. Todos los archivos en la carpeta de nivel superior
overlays/
contienen estas Superposiciones.
Cómo usar componentes
Las subcarpetas dentro del directorio overlays/
de nivel superior se estructuraron de tal manera que puedes habilitar (o inhabilitar) una función adicional mediante el comentario (o quitar los comentarios) de ciertas líneas en los archivos kustomization.yaml
.
Por ejemplo, así se ve la estructura de la carpeta overlays/instances/{INSTANCE_NAME}/telemetry
:
telemetry
├── components
│ ├── http-proxy
│ ├── imagepullsecret
│ ├── logger
│ ├── metrics
│ ├── nodeselector
│ ├── openshift-scc
│ ├── workload-identity-logger
│ └── workload-identity-metrics
├── apigee-telemetry.yaml
└── kustomization.yaml
Así es como se verían los archivos telemetry/kustomization.yaml
de forma predeterminada:
resources:
- apigee-telemetry.yaml
components:
- ./components/metrics
# - ./components/workload-identity-metrics
# - ./components/logger
# - ./components/workload-identity-logger
# - ./components/http-proxy
# - ./components/nodeselector/
# - ./components/imagepullsecret
# - ./components/openshift-scc
Podemos ver que ./components/logger
se marcó como comentario, lo que significa que no habilitamos el registrador de Google Cloud de forma predeterminada. Para habilitar esto, simplemente puedes quitar el comentario de la siguiente línea:
components:
- ./components/logger
Del mismo modo, para inhabilitar las métricas, puedes comentar la línea ./components/metrics
:
...
components:
...
# - ./components/metrics
…
En las secciones siguientes, se analizarán todos los componentes, cuándo se pueden usar y cómo se pueden configurar.
OpenShift
Para los usuarios que desean instalar Apigee Hybrid en un clúster de OpenShift
, es posible que debas habilitar algunos componentes o recursos antes de realizar la instalación. (Esto es necesario si no usas la secuencia de comandos para realizar la instalación). Los archivos que se deben modificar son los siguientes:
overlays/initialization/openshift/kustomization.yaml
En la secciónresources:
, quita el comentario:# - ../../../bases/initialization/openshift/
overlays/instances/{INSTANCE_NAME}/datastore/kustomization.yaml
Quitar comentario:# - ./components/openshift-scc
Quita el comentario en el campo "
components:
" si aún tiene comentarios.overlays/instances/{INSTANCE_NAME}/telemetry/kustomization.yaml
Quitar comentario:# - ./components/openshift-scc
Quita el comentario en el campo "
components:
" si aún tiene comentarios.
Luego, puedes continuar con los pasos de instalación.
imagepullsecret
Este componente se puede habilitar cuando tienes imágenes almacenadas en tu repositorio privado. Para extraer imágenes de un repositorio privado, puedes crear un secret de Kubernetes que tenga tus detalles de autenticación y, luego, hacer referencia a este secret en su interior. Consulta Configura imagePullSecrets (opcional) para obtener instrucciones. Consulta Extrae una imagen desde un registro privado | Kubernetes en la documentación de Kubernetes para obtener más información.
Disponible en:
overlays/controllers/apigee-controller
overlays/controllers/istiod
overlays/instances/{INSTANCE_NAME}/datastore
overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
overlays/instances/{INSTANCE_NAME}/organization
overlays/instances/{INSTANCE_NAME}/redis
overlays/instances/{INSTANCE_NAME}/telemetry
Habilita:
Quita los comentarios de la línea "./components/imagepullsecret/
" en los archivos kustomization.yaml
respectivos cuando sea necesario.
Modificaciones que se realizarán:
- components/imagepullsecret/patch.yaml
- OBLIGATORIO Agrega nombres de secrets relevantes a la lista en
spec.template.spec.imagePullSecrets
.
- OBLIGATORIO Agrega nombres de secrets relevantes a la lista en
Uso:
- Si aún no instalaste Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán en el proceso
Si ya tienes Apigee Hybrid instalado, deberás aplicar estos nuevos cambios mediante los siguientes pasos:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
nodeselector
Este componente te permite programar los Pods para un recurso de Apigee en nodos específicos. Consulta Asigna Pods a nodos | Kubernetes para obtener información adicional.
Disponible en:
overlays/controllers/apigee-controller
overlays/controllers/istiod
overlays/instances/{INSTANCE_NAME}/datastore
overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
overlays/instances/{INSTANCE_NAME}/organization
overlays/instances/{INSTANCE_NAME}/redis
overlays/instances/{INSTANCE_NAME}/telemetry
Habilita:
Quita los comentarios de la línea "./components/nodeselector
" en los archivos kustomization.yaml
respectivos cuando sea necesario.
Modificaciones que se realizarán:
- components/nodeselector/patch.yaml
- OPTIONAL: Cambia el valor de la etiqueta del selector de nodos de
apigee-runtime
oapigee-data
a la deseada.
- OPTIONAL: Cambia el valor de la etiqueta del selector de nodos de
Uso:
- Si aún no instalaste Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán en el proceso
Si ya tienes Apigee Hybrid instalado, deberás aplicar estos nuevos cambios mediante los siguientes pasos:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
workload-identity
Varios contenedores del ecosistema de Apigee Hybrid requieren permisos para realizar ciertas llamadas a la API al plano de control o al plano de administración de Apigee. Workload Identity es una de las opciones que le otorga estos permisos a los Pods (y los contenedores dentro de ellos). Estos son algunos recursos útiles para obtener más información: Presentación de Workload Identity: Mejor autenticación para tus aplicaciones de GKE | Blog de Google Cloud -Usa Workload Identity | Documentación de Kubernetes Engine | Google Cloud
Disponible en:
overlays/instances/{INSTANCE_NAME}/datastore
overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
overlays/instances/{INSTANCE_NAME}/organization
overlays/instances/{INSTANCE_NAME}/redis
overlays/instances/{INSTANCE_NAME}/telemetry
Requisito:
Para poder usar Workload Identity, debes otorgar los permisos relevantes dentro de tu proyecto de Google Cloud mediante lo siguiente:
gcloud iam service-accounts add-iam-policy-binding \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:${ORG_NAME}.svc.id.goog[${APIGEE_NAMESPACE}/${KSA_NAME}]" \
${GSA_NAME}@${ORG_NAME}.iam.gserviceaccount.com
Aquí:
- ${ORG_NAME} - Es el nombre de tu organización de Apigee.
- ${APIGEE_NAMESPACE}: El espacio de nombres de Kubernetes en el que se instalaron los componentes de Apigee. Por lo general, sería apigee
, a menos que el usuario lo cambie de forma explícita durante la instalación
- ${KSA_NAME}: Es el nombre del espacio de nombres de Kubernetes. Deberás ejecutar este comando para cada cuenta de servicio de Kubernetes que se menciona en Cuentas de servicio de Kubernetes.
- ${GSA_NAME}: Es el nombre de la cuenta de servicio de Google Cloud. Si no realizaste ningún cambio durante la instalación, este tendrá el valor apigee-all-sa
. Si configuras varias cuentas de servicio de Google Cloud para componentes individuales, deberás hacer coincidir KSA_NAME con el GSA_NAME correspondiente. Puedes comparar las tablas de Cuentas de servicio de Google Cloud con las Cuentas de servicio de Kubernetes para encontrar los equivalentes.
Habilita:
Quita los comentarios de la línea ./components/workload-identity
en los archivos kustomization.yaml
respectivos cuando sea necesario. Ten en cuenta que, en la telemetría, tenemos complementos independientes de Workload Identity para los componentes de metrics
y logger
que se pueden habilitar de forma individual.
Uso:
- Si aún no instalaste Hybrid, puedes habilitar la identidad de carga de trabajo como se mencionó en la sección anterior y continuar con la instalación, que usará la identidad de carga de trabajo de forma automática.
Si ya tienes Apigee Hybrid instalado, deberás aplicar estos nuevos cambios mediante los siguientes pasos:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
http-proxy
Puedes configurar un servidor proxy en cada uno de los siguientes componentes para que el tráfico de ese componente pase por el proxy HTTP configurado para ese componente. Puedes configurar el proxy para cada componente de Apigee de forma individual.
Disponible en:
overlays/instances/{INSTANCE_NAME}/datastore
overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
overlays/instances/{INSTANCE_NAME}/organization
overlays/instances/{INSTANCE_NAME}/telemetry
Habilita:
Quita los comentarios de la línea "./components/http-proxy/
" en los archivos kustomization.yaml
respectivos cuando sea necesario.
Modificaciones que se realizarán:
- components/http-proxy/patch.yaml
Se pueden configurar los siguientes parámetros en
spec.httpForwardProxy
scheme
: OBLIGATORIO Debe serHTTP
oHTTPS
host
: OBLIGATORIO La dirección del host de tu proxyport
: OBLIGATORIO el número de puertousername
: OPTIONAL El nombre de usuario asociado a tu proxypassword
: OPTIONAL La contraseña para acceder al proxy
Uso:
- Si aún no instalaste Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán en el proceso
Si ya tienes Apigee Hybrid instalado, deberás aplicar estos nuevos cambios mediante los siguientes pasos:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
registrador y métricas
Puedes habilitar o inhabilitar de forma individual el registrador o overlays/instances/{INSTANCE_NAME}/telemetry. De forma predeterminada, el registrador está inhabilitado y las métricas están habilitadas. Habilitarlos o inhabilitarlos es simplemente quitar los comentarios de las líneas en telemetry/kustomization.yaml
gcs-backup y gcs-restore
Este componente de kustomize se puede usar para realizar una copia de seguridad y restablecimiento de la base de datos de Cassandra en Google Cloud Storage.
Disponible en:
overlays/instances/{INSTANCE_NAME}/datastore
Requisito:
Descarga las claves de las cuentas de servicio de Google Cloud para una cuenta que tenga el rol de Administrador de objetos de almacenamiento.
- Si usaste la secuencia de comandos para realizar la instalación y no usaste workload-identities, puedes volver a usar las claves descargadas disponibles en la carpeta service-accounts que crea la secuencia de comandos.
También puedes usar la secuencia de comandos create-service-account.sh para crear una cuenta de servicio nueva y descargar sus claves:
./tools/create-service-accounts=.sh --env prod --profile apigee‑cassandra
Una vez que se hayan descargado las claves, debes crear un secret de Kubernetes con el nombre apigee-cassandra-backup-and-restore-gcp-sa-key, que se puede realizar mediante el siguiente comando:
kubectl create secret generic "apigee-cassandra-backup-and-restore-gcp-sa-key" \ --from-file="dbbackup_key.json=${PATH_TO_SA_KEY}" \ -n "${APIGEE_NAMESPACE}"
Dónde:
- ${PATH_TO_SA_KEY}: La ruta de acceso al archivo que contiene las claves de la cuenta de servicio.
- ${APIGEE_NAMESPACE}: Es el espacio de nombres de Kubernetes en el que se instalaron los componentes de Apigee. Por lo general, se usaría apigee, a menos que se cambie de forma explícita durante la instalación
Como alternativa, puedes usar las plantillas del archivo templates/secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml para crear este secret.
Habilita:
- Si deseas habilitar la copia de seguridad, quita el comentario de la línea "./components/gcs-backup" en el archivo kustomization.yaml.
- Si deseas restablecer una copia de seguridad, quita el comentario de la línea "./components/gcs-restore" en el archivo kustomization.yaml.
Modificaciones solo para la copia de seguridad
- components/gcs-backup/apigee-datastore-patch.yaml
- OBLIGATORIO Cambia el valor de la variable de entorno DATABASE_STORAGE_BUCKET, que tendrá el formato gs://BUCKET_NAME y apuntará al bucket de Google Cloud Storage donde se debe crear una copia de seguridad de los datos. La descripción coincide con dbStorageBucket que se describe aquí.
- components/gcs-backup/cron-patch.yaml
- OBLIGATORIO Cambia spec.schedule para especificar la frecuencia de la copia de seguridad. Field acepta el formato de programación estándar de Crontab. La descripción coincide con el programa descrito aquí.
- OBLIGATORIO Cambia el valor de la variable de entorno DATABASE_STORAGE_BUCKET, que tendrá el formato gs://BUCKET_NAME y apuntará al bucket de Google Cloud Storage donde se debe crear una copia de seguridad de los datos. La descripción coincide con dbStorageBucket que se describe aquí.
- OPTIONAL: Cambia el valor de HTTP_PROXY_URL para que apunte a cualquier proxy configurado. El formato podría ser el siguiente:
http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS>:${HOST_PORT}
Realiza una copia de seguridad
Puedes realizar la copia de seguridad con el siguiente comando:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
Para aplicar los cambios y habilitar la copia de seguridad, haz lo siguiente:
Modificaciones solo para el restablecimiento
- components/gcs-restore/apigee-datastore-patch.yaml
- OBLIGATORIO Cambia el valor de la variable de entorno DATABASE_STORAGE_BUCKET, que tendrá el formato gs://BUCKET_NAME y apuntará al bucket de Google Cloud Storage donde se debe crear una copia de seguridad de los datos. La descripción coincide con dbStorageBucket que se describe aquí.
- components/gcs-restore/job-patch.yaml
- OBLIGATORIO Cambia el valor de la variable de entorno DATABASE_STORAGE_BUCKET, que tendrá el formato gs://BUCKET_NAME y apuntará al bucket de Google Cloud Storage donde se debe crear una copia de seguridad de los datos.
- OBLIGATORIO Cambia el valor de la variable de entorno BACKUP_SNAPSHOT_TIMESTAMP. La descripción coincide con restore:snapshotTimestamp descrita aquí.
- OPTIONAL: Cambia el valor de HTTP_PROXY_URL para que apunte a cualquier proxy configurado.
El formato podría ser el siguiente:
http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
Realiza el restablecimiento:
Para obtener información general sobre cómo restablecer copias de seguridad, consulta Restablece copias de seguridad | Apigee X | Google Cloud
- Crea un clúster de Kubernetes nuevo con un espacio de nombres nuevo en el que se restablezca la implementación del entorno de ejecución híbrido. No puedes usar el mismo clúster o espacio de nombres que usaste para la instalación híbrida original.
Instala el híbrido en el nuevo clúster con la configuración anterior, además de cualquier otra configuración que desees:
- Puedes usar la instalación básica y, luego, instalar Hybrid en el espacio de nombres nuevo:
./tools/apigee-hybrid-setup.sh \ --cluster-name $CLUSTER_NAME \ --cluster-region $CLUSTER_LOCATION \ --namespace ${NEW_APIGEE_NAMESPACE}
- O bien, sigue la instalación personalizada de Apigee Hybrid para configurar elementos según tu elección.
Una vez que se completa el restablecimiento, se pueden borrar todos los recursos en el espacio de nombres anterior y cambiarse al nuevo espacio de nombres.
Para obtener más información, consulta Restablece copias de seguridad.
non-gcs-backup y non-gcs-restore
Este componente de kustomize se puede usar para realizar una copia de seguridad y restablecimiento de la base de datos de Cassandra en Google Cloud Storage.
Disponible en:
overlays/instances/{INSTANCE_NAME}/datastore
Requisito:
- Se pueden usar los pasos de la documentación existente para Configurar el servidor y SSH.
En los pasos anteriores, deberás usar la clave privada SSH, que está disponible en el archivo “ssh_key” generado en los pasos anteriores. Luego, crearemos un secret de Kubernetes con el nombre apigee-cassandra-backup-and-restore-gcp-sa-key, que contiene esta clave privada SSH.
El secret de Kubernetes se puede crear con el siguiente comando:
kubectl create secret generic "apigee-cassandra-backup-and-restore-key-file" \ --from-file="key=${PATH_TO_SSH_PRIVATE_KEY}" \ -n "${APIGEE_NAMESPACE}"
Dónde:
- ${PATH_TO_SSH_PRIVATE_KEY}: La ruta de acceso al archivo que contiene la clave privada SSH
- ${APIGEE_NAMESPACE}: Es el espacio de nombres de Kubernetes en el que se instalaron los componentes de Apigee. Por lo general, se usaría apigee, a menos que se cambie de forma explícita durante la instalación
De manera alternativa, puedes usar las plantillas del archivo de templates/secret-apigee-cassandra-backup-and-restore-key-file.yaml para crear este secret.
Habilita:
- Si deseas habilitar la copia de seguridad, quita el comentario de la línea "
./components/non-gcs-backup
" en el archivo kustomization.yaml. - Si deseas restablecer una copia de seguridad, quita el comentario de la línea "
./components/non-gcs-restore
" en el archivo kustomization.yaml.
Modificaciones solo para la copia de seguridad
- components/non-gcs-backup/apigee-datastore-patch.yaml
- OBLIGATORIO Cambia el valor de BACKUP_SERVER_IP. La descripción coincide con BACKUP_SERVER_IP que se describe aquí.
- OBLIGATORIO Cambia el valor de BACKUP_STORAGE_DIR. La descripción coincide con BACKUP_STORAGE_DIR que se describe aquí.
- components/non-gcs-backup/cron-patch.yaml
- OBLIGATORIO Cambia spec.schedule para especificar la frecuencia de la copia de seguridad. Field acepta el formato de programación estándar de Crontab. La descripción coincide con el programa descrito aquí.
- OBLIGATORIO Cambia el valor de BACKUP_SERVER_IP. La descripción coincide con BACKUP_SERVER_IP que se describe aquí.
- OBLIGATORIO Cambia el valor de BACKUP_STORAGE_DIR. La descripción coincide con BACKUP_STORAGE_DIR que se describe aquí.
- OPTIONAL: Cambia el valor de HTTP_PROXY_URL para que apunte a cualquier proxy configurado. El formato podría ser el siguiente:
http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
Realiza una copia de seguridad
Puedes realizar la copia de seguridad con el siguiente comando:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
Para aplicar los cambios y habilitar la copia de seguridad, haz lo siguiente:
Modificaciones solo para la copia de seguridad
- components/non-gcs-restore/apigee-datastore-patch.yaml
- OBLIGATORIO Cambia el valor de
BACKUP_SERVER_I
P. La descripción coincide conBACKUP_SERVER_IP
descrita aquí. - OBLIGATORIO Cambia el valor de BACKUP_STORAGE_DIR. La descripción coincide con
BACKUP_STORAGE_DIR
que se describió aquí.
- OBLIGATORIO Cambia el valor de
- components/non-gcs-restore/job-patch.yaml
- OBLIGATORIO Cambia el valor de la variable de entorno
BACKUP_SNAPSHOT_TIMESTAMP
. La descripción coincide conrestore:snapshotTimestamp
descrita aquí. - OBLIGATORIO Cambia el valor de
BACKUP_SERVER_IP
. La descripción coincide conBACKUP_SERVER_IP
descrita aquí. - OBLIGATORIO Cambia el valor de
BACKUP_STORAGE_DIR
. La descripción coincide conBACKUP_STORAGE_DIR
que se describió aquí. - OPTIONAL: Cambia el valor de
HTTP_PROXY_URL
para que apunte a cualquier proxy configurado. El formato podría ser el siguiente:http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
- OBLIGATORIO Cambia el valor de la variable de entorno
Realiza el restablecimiento:
Para obtener una descripción general sobre el restablecimiento de copias de seguridad, consulta la descripción general del restablecimiento de Cassandra.
- Crea un clúster de Kubernetes nuevo con un espacio de nombres nuevo en el que se restablezca la implementación del entorno de ejecución híbrido. No puedes usar el mismo clúster o espacio de nombres que usaste para la instalación híbrida original.
Además de instalar cualquier otro parámetro de configuración que desees, instala Hybrid en el clúster nuevo mediante la configuración anterior: puedes usar la instalación básica y la instalación híbrida en el espacio de nombres nuevo:
./tools/apigee-hybrid-setup.sh \ --cluster-name $CLUSTER_NAME \ --cluster-region $CLUSTER_LOCATION \ --namespace ${NEW_APIGEE_NAMESPACE}
O bien, sigue la instalación personalizada de Apigee Hybrid para configurar elementos según tu elección.
Una vez que se completa el restablecimiento, se pueden borrar todos los recursos en el espacio de nombres anterior y cambiarse al nuevo espacio de nombres.
Para obtener más información, consulta Programa copias de seguridad en un servidor remoto.
http-client
Para obtener instrucciones, consulta Habilita clientes HTTP | Apigee.
Disponible en:
- overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}
Habilita:
Quita los comentarios de la línea "./components/http-client
" en el archivo route-config/${ENV_GROUP}/kustomization.yaml
correspondiente
Modificaciones que se realizarán:
- No se requieren modificaciones obligatorias.
Uso:
- Si aún no instalaste Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán en el proceso
Si ya tienes Apigee Hybrid instalado, deberás aplicar estos nuevos cambios mediante los siguientes pasos:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
non-sni-client
Equivalente al existente Cómo configurar un cliente que no sea SNI | Apigee.
Disponible en:
- overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}
Habilita:
Quita los comentarios de la línea "./components/non-sni-client
" en el archivo route-config/${ENV_GROUP}/kustomization.yaml
correspondiente
Modificaciones que se realizarán:
- components/non-sni-client/apigee-route.yaml
- OBLIGATORIO
credentialName
La descripción coincide concredential_name
descrita aquí.
- OBLIGATORIO
Uso:
- Si aún no instalaste Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán en el proceso
Si ya tienes Apigee Hybrid instalado, deberás aplicar estos nuevos cambios mediante los siguientes pasos:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
http-and-non-sni-client
Para obtener instrucciones, consulta Habilita la compatibilidad con clientes HTTP y sin SNI | Apigee.
Habilita:
Quita los comentarios de la línea "./components/http-and-non-sni-client
" en el archivo route-config/${ENV_GROUP}/kustomization.yaml
correspondiente
Modificaciones que se realizarán:
- components/http-and-non-sni-client/apigee-route.yaml
- OBLIGATORIO
credentialName
La descripción coincide concredential_name
descrita aquí.
- OBLIGATORIO
Uso:
- Si aún no instalaste Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán en el proceso
Si ya tienes Apigee Hybrid instalado, deberás aplicar estos nuevos cambios mediante los siguientes pasos:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
multirregión
Este componente se puede usar cuando se configura una implementación multirregión de Cassandra. Para obtener más información, consulta Implementación multirregional en GKE y GKE On-Prem
Habilita:
Quita los comentarios de la línea "./components/multi-region
" en el archivo datastore/kustomization.yaml
Modificaciones que se realizarán:
components/multi-region/cassandra-data-replication.yaml
- OBLIGATORIO
source.region
Es el nombre del centro de datos de Cassandra que se usará para replicar datos. Se pueden identificar mediante el siguiente comando en el clúster de origen:
kubectl get apigeedatastore -n ${APIGEE_NAMESPACE} -o=jsonpath='{.items[*].spec.components.cassandra.properties.datacenter}'
- OBLIGATORIO
components/multi-region/patch.yaml
- OBLIGATORIO
spec.components.properties.multiRegionSeedHost
La IP del Pod de cualquiera de los Pods de Cassandra de origen. Podemos usar lo siguiente:
kubectl get pods -n ${APIGEE_NAMESPACE} -o wide
- Para enumerar todos los Pods y obtener la IP de cualquier Pod de Cassandra, usa el siguiente comando:
kubectl get pods -o wide -n apigee
La respuesta debería ser similar a la siguiente:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE apigee-cassandra-default-0 1/1 Running 0 5d 10.0.0.11 gke-k8s-dc-2-default-pool-a2206492-p55d apigee-cassandra-default-1 1/1 Running 0 5d 10.0.2.4 gke-k8s-dc-2-default-pool-e9daaab3-tjmz apigee-cassandra-default-2 1/1 Running 0 5d 10.0.3.5 gke-k8s-dc-2-default-pool-e589awq3-kjch
- OBLIGATORIO
Para obtener más información, consulta Requisitos previos para GKE en "Implementación en GKE multirregionales, GKE local y AKS":
Uso:
El uso de este componente tiene más sentido cuando configuras Apigee Hybrid en un clúster nuevo y ya tienes otra configuración funcional de Apigee Hybrid.
- El clúster nuevo y el existente deben usar los mismos certificados TLS para garantizar una comunicación adecuada entre los Pods de Cassandra. Por lo tanto, necesitaremos copiar el secret
apigee-root-certificate
del clúster existente y usarlo en el más reciente: Ejecuta:
kubectl config get-contexts
- Para obtener una lista de todos los contextos de Kubernetes y, luego, ejecutarlo
kubectl config use-context SOURCE_CLUSTER_CONTEXT
donde SOURCE_CLUSTER_CONTEXT es el nombre del clúster de Kubernetes de origen.
Almacena el secret de certificado raíz en un archivo:
kubectl get secret/apigee-root-certificate -n cert-manager -o yaml > apigee-root-certificate.yaml
Cambia el contexto del clúster al clúster nuevo en el que instalarás Apigee Hybrid.
kubectl config use-context ${NEW_CLUSTER_CONTEXT}
Crea el secret raíz en el clúster nuevo:
kubectl -n cert-manager apply -f apigee-root-certificate.yaml
Inhabilita la creación de un certificado raíz nuevo. Esto garantizará que no creemos un nuevo
apigee-root-certificate
y terminemos reemplazando el que creamos en el paso anterior.Quita los comentarios de las siguientes líneas en el archivo
overlays/initialization/certificates/kustomization.yaml
:# components: # - ./components/disable-apigee-root-certificate-generation
Continúa con el resto de la instalación de Apigee Hybrid mediante el uso de la Instalación básica de Apigee Hybrid oInstalación personalizada de Apigee Hybrid. Por ejemplo, después de la instalación básica de Apigee Hybrid, puedes ejecutar lo siguiente:
./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATION
Verifica el estado de recompilación con el siguiente comando.
kubectl -n ${APIGEE_NAMESPACE} get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
Verifica los procesos de recompilación de los registros. Además, verifica el tamaño de los datos con el comando de estado nodetool:
kubectl logs apigee-cassandra-default-0 -f -n ${APIGEE_NAMESPACE} kubectl exec apigee-cassandra-default-0 -n ${APIGEE_NAMESPACE} -- nodetool -u ${JMX_USER} -pw ${JMX_PASSWORD} status
Verifica el estado de recompilación con el siguiente comando.
kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
El resultado debería ser similar a lo siguiente:
{ "rebuildDetails": { "apigee-cassandra-default-0": { "state": "complete", "updated": 1623105760 }, "apigee-cassandra-default-1": { "state": "complete", "updated": 1623105765 }, "apigee-cassandra-default-2": { "state": "complete", "updated": 1623105770 } }, "state": "complete", "updated": 1623105770 }
Consulta también: Implementación multirregional.
Quita las siguientes líneas de
components/multi-region/patch.yaml
:properties: multiRegionSeedHost: {IP_ADDRESS} # To be modified. REQUIRED
Aplique los cambios:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
Conceptos
Image Hub
Por lo general, las imágenes de contenedor de Docker se especifican en el siguiente formato:
${REGISTRY_HOST_PATH}/${IMAGE_NAME}:${IMAGE_TAG}
o los que usan un resumen se ven de la siguiente manera:
${REGISTRY_HOST_PATH}/${IMAGE_NAME}@${DIGEST}
Apigee usa el concepto de “Image Hub” que, en los formatos anteriores, se refiere a ${REGISTRY_HOST_PATH}
. El valor predeterminado de Image Hub es gcr.io/apigee-release/hybrid/
.
(Las imágenes que usan DIGEST deberán establecerse de forma individual en cada subcomponente)
Para construir la ruta final de la imagen, Apigee combina el valor de lo siguiente:
- "Image Hub" que se puede anular en apigee-hybrid-config.yaml (consulta la sección Usa imágenes de Docker de repositorios privados para obtener instrucciones detalladas sobre cómo anular el Image Hub).
- El valor de
IMAGE_TAG
se obtiene del campoversion
, que está presente dentro del archivo yaml para cada uno de los componentes individuales (por ejemplo, apigee-organization.yaml). Apigee etiqueta las imágenes con la versión de Apigee Hybrid, lo que significa queIMAGE_TAG
es 1.8 para la versión de Apigee Hybrid 1.8. IMAGE_NAME
se determina de forma implícita a partir del nombre del contenedor en el que se usará la imagen. Por ejemplo, para el contenedorapigee-runtime
, elIMAGE_NAME
será apigee-runtime.
Por lo tanto, un ejemplo completo de una ruta de imagen sería gcr.io/apigee-release/hybrid/apigee-runtime:1.8.0
De esta manera, se construye la ruta de acceso de la imagen final, que luego se usaría dentro de cada uno de los contenedores en sus respectivos Pods.
Cuentas de servicio de Google Cloud
Las cuentas de servicio de Google Cloud son cuentas que usan las aplicaciones para realizar llamadas autorizadas a las APIs de Google. Se pueden descargar las claves de cuenta de servicio de Google Cloud, que luego se pueden usar para la autenticación. Apigee espera que el usuario proporcione claves de cuenta de servicio mediante la creación de secrets. Estos son los nombres de los componentes y el nombre predeterminado del secret donde se buscan las claves de la cuenta de servicio:
Componente | Subcomponente | Nombre predeterminado del secret de Kubernetes que contiene una clave de cuenta de servicio |
---|---|---|
organización | ||
connectAgent | apigee-connect-agent-gcp-sa-key-${ORG_NAME} |
|
watcher | apigee-watcher-gcp-sa-key-${ORG_NAME} |
|
mart | apigee-mart-gcp-sa-key-${ORG_NAME} |
|
udca | apigee-udca-gcp-sa-key-${ORG_NAME} |
|
ingressGateways | N/A | |
entorno | ||
runtime | apigee-runtime-gcp-sa-key-${ORG_NAME}-${ENV_NAME} |
|
udca | apigee-udca-gcp-sa-key-${ORG_NAME}-${ENV_NAME} |
|
synchronizer | apigee-synchronizer-gcp-sa-key-${ORG_NAME}-${ENV_NAME} |
|
telemetry | ||
métricas | apigee-metrics-gcp-sa-key |
|
containerLogs | apigee-logger-gcp-sa-key |
Cuentas de servicio de Kubernetes
Las cuentas de servicio de Kubernetes proporcionan identidades a los Pods de tu clúster. De forma predeterminada, el controlador de Apigee los crea. Pero, si quieres anular la creación (por ejemplo, cuando usas Identidades de la carga de trabajo), puedes hacerlo si especificas elpodServiceAccountName
en los diversos subcomponentes.
Lista de componentes y sus respectivos subcomponentes, en la que la cuenta de servicio de Kubernetes se puede especificar junto con el nombre predeterminado de la cuenta de servicio de k8s cuando habilitas el parche de Workload Identity para ellos.
Componente | Subcomponente | Nombre predeterminado (disponible cuando habilitaste el parche de Workload Identity) |
---|---|---|
organización | ||
connectAgent | apigee-connect-agent-svc-account-${ORG_NAME} |
|
watcher | apigee-watcher-svc-account-${ORG_NAME} |
|
mart | apigee-mart-svc-account-${ORG_NAME} |
|
udca | apigee-udca-svc-account-${ORG_NAME} |
|
entorno | ||
synchronizer | apigee-synchronizer-svc-account-${ORG_NAME}-${ENV_NAME} |
|
udca | apigee-udca-svc-account-${ORG_NAME}-${ENV_NAME} |
|
runtime | apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME} |
|
datastore | ||
cassandra | apigee-datastore-svc-account |
|
telemetry | ||
metricsApp | apigee-metricsApp-svc-account |
|
metricsProxy | apigee-metricsProxy-svc-account |
|
metricsAdapter | apigee-metricsAdapter-svc-account |
|
containerLogs | apigee-container-logs-svc-account |
Identidades de cargas de trabajo
Las identidades de cargas de trabajo permiten que los Pods (que usan cuentas de servicio de Kubernetes) que se ejecutan en GKE se autentiquen directamente con las APIs de Google Cloud sin necesidad de claves de cuenta de servicio de Google Cloud.
Agrega un entorno nuevo
.
├── ...
├── instances/instance1/components
│ ├── ...
│ ├── environments
│ │ ├── dev
│ │ │ └── apigee-environment.yaml
│ │ │ └── secrets.yaml
│ │ └── new-env-name (new)
│ │ └── apigee-environment.yaml (new)
│ │ └── secrets.yaml (new)
└── ...
Agrega un entorno nuevo es tan simple como:
- Crea una carpeta nueva dentro del directorio de los entornos (o de la estructura de tus carpetas)
- Copia el archivo
apigee-environment.yaml
de cualquier entorno existente a la carpeta nueva. - Si deseas crear una cuenta de servicio y claves de encriptación nuevas para el entorno nuevo, copia el archivo
secrets.yaml
en la carpeta nueva y cambia el nombre de los secret de forma adecuada a fin de distinguirlos de los otros entornos existentes (por lo general, esto se agrega agregando el nombre del entorno como sufijo) - Realiza los cambios adecuados en el
apigee-environment.yaml
, como los siguientes:- Cambia el nombre del entorno
- Si se crearán cuentas de servicio y claves de encriptación nuevas, se debe hacer referencia a ellas de forma correcta en el archivo yaml.
- Aplica los
yaml
:
kubectl apply -f components/environments/new-env-name/secrets.yaml
kubectl apply -f components/environments/new-env-name/apigee-environment.yaml
Usa la eliminación forzada en Apigee Datastore
Si la eliminación del almacén de datos no avanza por algún motivo, ahora se puede forzar la eliminación del almacén de datos mediante los siguientes comandos, sin importar el estado actual del clúster.
Borra
apigeeds
en el espacio de nombresapigee
:Kubectl delete -n apigee apigeeds default
Si este paso se atasca, puede salir de eso con CTRL + C.
Edita un
apigeeds
nuevo:Kubectl edit -n apigee apigeeds default
Agrega o actualiza el campo forceDelete en la especificación del almacén de datos de Apigee
spec: forceDelete: true
Guarda el archivo y cierra.
Ahora espera a que se borre el almacén de datos. Borra todos los recursos de Cassandra toma unos minutos.
Información sobre la secuencia de comandos
La secuencia de comandos apigee-hybrid-setup.sh
realiza algunas validaciones básicas y ayuda a automatizar los pasos que deberías seguir si deseas realizar una personalización más detallada, como se documenta en Instalación personalizada de Apigee Hybrid. Incluso con la instalación personalizada, puedes usar la secuencia de comandos de forma parcial para ayudar con ciertas tareas.
Puedes ejecutar ./tools/apigee-hybrid-setup.sh --help
para ver una lista de marcas compatibles y obtener ayuda adicional con la secuencia de comandos. En este momento, se admiten las siguientes marcas:
--namespace
De forma predeterminada, la secuencia de comandos instala todos los componentes en el espacio de nombresapigee
. Puedes cambiar este comportamiento si especificas el nombre del espacio de nombres con esta marca.--org
se usa para proporcionar el nombre de la organización de Apigee. Si no se especifica, se establece de forma predeterminada en el proyecto de Google Cloud seleccionado actualmente engcloud
.--envgroup
se usa para proporcionar el nombre del grupo de entornos dentro de tu organización. Si no se especifica, se intenta consultar las API del plano de control para determinar el nombre del grupo de entornos. Si se encuentran varios grupos de entornos, se muestra un error y la secuencia de comandos se cierra.--env
se usa para proporcionar el nombre del entorno dentro de tu organización. Si no se especifica, se intenta consultar las API del plano de control para determinar el nombre del entorno. Si se encuentran varios entornos o el entorno no forma parte del grupo de entornos, se muestra un error y la secuencia de comandos se cierra.--cluster-name
: El nombre del clúster de Kubernetes.--cluster-region
es la región en la que se encuentra el clúster de Kubernetes.--gcp-project-id
es el ID del proyecto de Google Cloud en el que existe el clúster de Kubernetes.--ingress-domain
Especifica el nombre de host o el nombre de dominio que se usará para generar los certificados TLS autofirmados para la puerta de enlace de entrada de Istio. Si no se especifica ninguno, se intenta determinar el valor mediante una consulta a las APIs del plano de control para obtener el valor del entorno. Si hubo algunos problemas para determinar el grupo de entornos o había varios nombres de host configurados para el entorno, se muestra el error y la secuencia de comandos se cierra.--generate-internal-tls-certs
Esto generará un secret de Kubernetes llamado apigee-ca que contiene un certificado y un par de claves que generamos.--create-ingress-tls-certs
Esto generará un secret llamado{ORG_NAME}-{ENV_GROUP_NAME}
(derivado de los nombres de la organización y el entorno) dentro del espacio de nombres istio-system que contendrá un certificado y un par de claves que se usarán para la comunicación TLS. El nombre de dominio que se usó para generar estos certificados deriva del valor que se encuentra en la configuración del grupo de entornos. En caso de conflictos (como cuando encontramos varios dominios), se mostrarán los mensajes de error adecuados.--create-gcp-sa-and-secrets
Crea una sola cuenta de servicio de Google Cloud en el proyecto de Google Cloud, descarga las claves y, luego, crea los secretos de Kubernetes que contienen la clave. Los nombres de los secretos se pueden encontrar en las cuentas de servicio de Google Cloud.--fill-values
Reemplaza los valores de la org, env, envgroup y otros nombres donde sean necesarios en los diferentes yamls.--apply-configuration
Esto creará los emisores de los certificados, las definiciones de recursos personalizados, los webhooks, los roles y el recurso del controlador. Los recursos se crearán en el orden correcto y el comando se bloqueará hasta que todos estén en buen estado.-- rename-directories
Cambia el nombre del entorno y el grupo de entornos por los nombres del entorno y del grupo de entornos correctos.--verbose
Muestra un resultado detallado para la depuración.--help
Muestra información sobre el uso.--setup-all
Esto ejecutará todas las tareas que puede realizar esta secuencia de comandos
Estructura de carpetas de configuración de Apigee Hybrid
La carpeta apigee-hybrid-setup
tiene la siguiente estructura jerárquica de forma predeterminada:
.
├── bases
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-controller-deployment.yaml
│ │ │ └── kustomization.yaml
│ │ └── apigee-ingressgateway-manager
│ │ ├── apigee-ingressgateway-manager-deployment.yaml
│ │ └── kustomization.yaml
│ ├── datastore
│ │ └── backup-and-restore
│ │ ├── backup
│ │ │ ├── cronjob.yaml
│ │ │ └── kustomization.yaml
│ │ ├── common
│ │ │ ├── kustomization.yaml
│ │ │ ├── rbac.yaml
│ │ │ └── tls-certificate.yaml
│ │ └── restore
│ │ ├── job.yaml
│ │ └── kustomization.yaml
│ └── initialization
│ ├── certificates
│ │ ├── certificates-and-issuers.yaml
│ │ └── kustomization.yaml
│ ├── crds
│ │ ├── customresourcedefinition-apigeedatastores.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeedeployments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeenvironments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeredis.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeerouteconfigs.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeroutes.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeetelemetries.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-cassandradatareplications.apigee.cloud.google.com.yaml
│ │ └── kustomization.yaml
│ ├── openshift
│ │ ├── kustomization.yaml
│ │ └── scc.yaml
│ ├── rbac
│ │ ├── apigee-controller
│ │ │ ├── kustomization.yaml
│ │ │ └── rbac.yaml
│ │ └── apigee-embedded-ingress-controller
│ │ ├── cluster-role-bindings.yaml
│ │ ├── cluster-roles.yaml
│ │ ├── kustomization.yaml
│ │ └── service-account.yaml
│ └── webhooks
│ ├── kustomization.yaml
│ ├── mutatingwebhookconfiguration.yaml
│ └── validatingwebhookconfiguration.yaml
├── CONTRIBUTING.md
├── docs
│ └── api_references
│ ├── v1alpha1.md
│ └── v1alpha2.md
├── kokoro
│ ├── build.sh
│ ├── common.cfg
│ ├── continuous.cfg
│ ├── presubmit.cfg
│ └── release.cfg
├── LICENSE
├── overlays
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-hybrid-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ ├── apigee-ingressgateway-manager
│ │ │ ├── apigee-ingressgateway-manager-deployment-patch.yaml
│ │ │ ├── apigee-istio-mesh-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ ├── initialization
│ │ ├── certificates
│ │ │ ├── apigee-ingressgateway-manager-certificate-patch.yaml
│ │ │ ├── apigee-serving-cert-patch.yaml
│ │ │ ├── components
│ │ │ │ └── disable-apigee-root-certificate-generation
│ │ │ │ └── kustomization.yaml
│ │ │ └── kustomization.yaml
│ │ ├── crds
│ │ │ └── kustomization.yaml
│ │ ├── ingress
│ │ │ ├── envoyfilter-1.11.yaml
│ │ │ └── kustomization.yaml
│ │ ├── namespace.yaml
│ │ ├── openshift
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── rbac
│ │ │ ├── apigee-controller
│ │ │ │ └── kustomization.yaml
│ │ │ ├── apigee-ingressgateway-manager
│ │ │ │ └── kustomization.yaml
│ │ │ └── kustomization.yaml
│ │ └── webhooks
│ │ ├── kustomization.yaml
│ │ ├── mutatingwebhookconfiguration.yaml
│ │ └── validatingwebhookconfiguration.yaml
│ └── instances
│ └── instance1
│ ├── datastore
│ │ ├── apigee-datastore.yaml
│ │ ├── components
│ │ │ ├── gcs-backup
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── cron-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── gcs-restore
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── job-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── multi-region
│ │ │ │ ├── cassandra-data-replication.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── non-gcs-backup
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── cron-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── non-gcs-restore
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── job-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── openshift-scc
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── scc.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── environments
│ │ ├── kustomization.yaml
│ │ └── test
│ │ ├── apigee-environment.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── kustomization.yaml
│ ├── organization
│ │ ├── apigee-organization.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── redis
│ │ ├── apigee-redis.yaml
│ │ ├── components
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── route-config
│ │ ├── kustomization.yaml
│ │ └── test-envgroup
│ │ ├── apigee-route-config.yaml
│ │ ├── components
│ │ │ ├── http-and-non-sni-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ ├── http-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ └── non-sni-client
│ │ │ ├── apigee-route.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── telemetry
│ ├── apigee-telemetry.yaml
│ ├── components
│ │ ├── http-proxy
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── imagepullsecret
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── logger
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── metrics
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── nodeselector
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── openshift-scc
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── workload-identity-logger
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ └── workload-identity-metrics
│ │ ├── kustomization.yaml
│ │ ├── patch.yaml
│ │ └── service-accounts.yaml
│ └── kustomization.yaml
├── README.md
├── templates
│ ├── certificate-org-envgroup.yaml
│ ├── secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml
│ ├── secret-apigee-cassandra-backup-and-restore-key-file.yaml
│ ├── secret-gcp-sa-key.yaml
│ └── secret-ingress-tls-cert-key.yaml
└── tools
├── apigee-hybrid-setup.sh
├── apigee-pull-push.sh
├── common.sh
├── create-service-account.sh
└── dump_kubernetes.sh
Puedes encontrar una versión de los archivos anteriores en la etiqueta preview-1 del repositorio de github en: https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1.
La carpeta anterior contiene manifiestos de Kubernetes para el entorno de ejecución de Apigee Hybrid y usa Kustomize para la administración de configuración. Los manifiestos se organizan según el concepto de bases y superposiciones de Kustomize. La carpeta base contiene la configuración mínima requerida para cada componente de Apigee. La carpeta de superposiciones contiene varias características adicionales (configuraciones) que se definen como componentes. Para quitar un componente, se puede quitar el comentario de la referencia del componente en kustomization.yaml
Ejemplo : A fin de habilitar gcs-backup
para el almacén de datos de Apigee, se quitó el comentario del componente gcs-backup
en el archivo custom.yaml siguiente.
Ruta: ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/kustomization.yaml
namespace: "apigee" # kpt-set: ${APIGEE_NAMESPACE}
resources:
- apigee-datastore.yaml
components:
# - ./components/http-proxy
# - ./components/nodeselector/
# - ./components/imagepullsecret
# - ./components/workload-identity
# - ./components/openshift-scc
- ./components/gcs-backup (uncommented)
# - ./components/gcs-restore
# - ./components/non-gcs-backup
# - ./components/non-gcs-restore
Cualquier valor que requiera personalizaciones debe establecerse en el parche patch.yaml correspondiente para gcs-backup.
En el siguiente archivo, el usuario debe establecer el valor de CLOUD_STORAGE_BUCKET_PATH
.
Ruta: $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/datastore/components/gcs-backup/cron-patch.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: apigee-cassandra-backup
namespace: apigee
spec:
schedule: "${YOUR_BACKUP_SCHEDULE_CODE}" # To be modified
jobTemplate:
spec:
template:
spec:
containers:
- name: apigee-cassandra-backup
env:
- name: APIGEE_CLOUDPROVIDER
value: "GCP"
- name: DATABASE_STORAGE_BUCKET
value: "${CLOUD_STORAGE_BUCKET_PATH}" # To be modified. REQUIRED
volumeMounts:
- name: apigee-cassandra-backup
mountPath: /var/secrets/google
volumes:
- name: apigee-cassandra-backup
secret:
secretName: "apigee-cassandra-backup-and-restore-svc-account"
Del mismo modo, cualquier función o configuración que requiera personalizaciones se puede habilitar quitando el comentario del componente en el kustomization.yaml del componente de Apigee. Además, según sea necesario, los valores correspondientes para los campos en el patch.yaml del componente deben configurarse en consecuencia.
Explicación breve de las carpetas y los archivos:
bases
Esta carpeta tiene las plantillas con la configuración mínima requerida por cada uno de los componentes de Apigee. No sería necesario realizar modificaciones en los manifiestos de esta carpeta.
superposiciones
Esta carpeta contiene las plantillas de componentes de Kustomize para las configuraciones adicionales
inicialización
namespaces.yaml
El espacio de nombres en el que se instalarán los componentes del plano de datos de Apigee. El nombre del espacio de nombres predeterminado es apigee
Certificados
Contiene los recursos Issuer
y Certificate
que se usan para emitir certificados a los webhooks. También contiene el Issuer
que se usa a fin de emitir certificados a varios pods para la comunicación de TLS.
rbac
Contiene Role
, ClusterRole
, RoleBinding
y ClusterRoleBinding
que usarán varios componentes.
crds
Contains the definition of all the CRDs which are used by Apigee.
webhooks
Contiene ValidatingWebhookConfiguration
y MutatingWebhookConfiguration
que se usarán para realizar validaciones en los recursos personalizados.
entrada
Contiene una configuración que se aplica a todos los POD de Ingress. P. ej., Modificación común de encabezado, verificación de estado, etcétera.
openshift
Contiene la definición de SecurityContextConstraints de openshift.
Controladores
apigee-controller
apigee-hybrid-config.yaml
Contiene un ConfigMap
que se proporciona como entrada en apigee-controller-manager.yaml. Este ConfigMap contiene una configuración como imageHub
, imagePullSecrets
, forwardProxy
, entre otras.
apigee-controller-deployment.yaml
Contiene dos objetos Service para el controlador y el webhook, y el Deployment para el controlador. Si en caso de que deseas usar una imagen privada para el controlador, debes realizar el cambio.
istiod
Apigee-istio-mesh-config.yaml contiene la configuración de malla para Istio que usa Apigee. Esto no se aplica a otras instalaciones de ASM/Istio en el clúster.
apigee-ingressgateway-manager-deployment-patch.yaml
Contiene un servicio y el Deployment de Istiod. Este es un Istio privado que se usa solo para los casos de uso de Apigee.
instances/{instanceName}
datastore
apigee-datastore.yaml
Contiene el recurso personalizado ApigeeDatastore
que administra Cassandra.
secrets.yaml
Contiene credenciales predeterminadas para el almacén de datos.
Redis
apigee-redis.yaml
Contiene el recurso personalizado ApigeeRedis
que administra Redis.
secrets.yaml
Contiene credenciales predeterminadas para el almacén de datos.
organización
apigee-organization.yaml
Contiene el recurso personalizado ApigeeOrganization
que administra otros subcomponentes, como connectAgent, WatcherAndSynchronizer, MART,UDCA e Ingress.
secrets.yaml
Contiene los Secret
a los que se hace referencia en apigee-organization.yaml. Algunos secret se comentan a medida que los genera la secuencia de comandos. Si inhabilitas su generación, deberás crearlas de forma manual.
entornos
Contiene todo el entorno de tu organización. Para crear una carpeta distinta para cada entorno, copia la que ya se te proporcionó y configúrala según el requisito.
dev
apigee-environment.yaml
Contiene el recurso personalizado ApigeeEnvironment
que administra otros subcomponentes, como el entorno de ejecución.
secrets.yaml
Contiene los Secret
a los que se hace referencia en apigee-environment.yaml. Algunos secret se comentan a medida que los genera la secuencia de comandos. Si inhabilitas su generación, deberás crearlos de forma manual.
telemetry
apigee-telemetry.yaml
Contiene el recurso personalizado ApigeeTelemetry
.
secrets.yaml
Contiene los Secret
a los que se hace referencia en apigee-telemetry.yaml. Algunos secret se comentan a medida que los genera la secuencia de comandos. Si inhabilitas su generación, deberás crearlas de forma manual.
route-config
dev-envgroup
apigee-route-config.yaml
Contiene el recurso personalizado ApigeeRouteConfig
.
secrets.yaml
Contiene un Secret
al que se hace referencia en apigee-route-config.yaml. Se comenta porque la secuencia de comandos apigee-hybrid-setup.sh lo genera de forma automática y se guarda allí para proporcionar una muestra de cómo debería ser el secret si decides crearlo de forma manual.
diagnóstico
diagnostic-collector.yaml
Recursos que se usarán para abrir el Deployment de diagnóstico
herramientas
apigee-hybrid-setup.sh
apigee-create-service-account.sh
dump-kubernetes.sh
apigee-pull-push.sh
Almacena claves de cuentas de servicio en almacenes de datos externos
Vault (de Hashicorp) es un sistema de administración de secret popular que tiene varias integraciones en almacenes de secrets proporcionados por Google, Azure, AWS y otros. Hashicorp Vault te permite recuperar secrets de una fuente externa y, luego, usarlos en los recursos de Kubernetes. Existen varias formas en las que se puede usar Vault para obtener secrets. Los siguientes pasos servirán como ejemplo básico sobre cómo usar el proveedor de CSI de Vault para activar claves de cuentas de servicio de Google Cloud que se almacenan en algún motor de secrets proporcionado por Vault.
- Usaremos Helm para instalar los recursos relacionados con Vault en tu clúster. Sigue los pasos que se indican en Instala Helm para configurar Helm en tu sistema.
Sigue los pasos de la página sobre cómo instalar el gráfico de Helm para Vault, es decir:
Agrega el repositorio de Hashicorp a helm
helm repo add hashicorp https://helm.releases.hashicorp.com
Actualiza repositorios de Helm
helm repo update
Instala Vault
helm install vault hashicorp/vault \ --set "server.dev.enabled=true" \ --set "injector.enabled=false" \ --set "csi.enabled=true"
Ahora, almacenaremos el secret en Vault.
Obtén una shell dentro del Pod de desarrollo de Vault
kubectl exec -it vault-0 -- /bin/sh ```
En este ejemplo, usaremos el motor de secrets de clave-valor para almacenar datos.
vault kv put secret/runtime-gcp-sa-key key="${BASE_64_ENCODED_KEY}"
Para verificar que la clave se haya almacenado de forma correcta, usa lo siguiente:
vault kv get secret/runtime-gcp-sa-key
Configura la autenticación para permitir que el Pod del entorno de ejecución extraiga la clave. Como se explica en Cuentas de servicio de Kubernetes, las cuentas de servicio de Kubernetes proporcionan identidad a los Pods y les permiten autenticarse con otros sistemas.
Obtén una shell dentro del Pod de desarrollo de Vault
kubectl exec -it vault-0 -- /bin/sh
Habilita el método de autenticación de Kubernetes
vault auth enable kubernetes
Escribe la configuración de autenticación
vault write auth/kubernetes/config \ issuer="https://kubernetes.default.svc.cluster.local" \ token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \ kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \ kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \ disable_iss_validation=true
Crea la política de autenticación
vault policy write apigee-runtime-app - <<EOF path "secret/data/runtime-gcp-sa-key" { capabilities = ["read"] } EOF
Vincula la política con la cuenta de servicio
vault write auth/kubernetes/role/apigee-runtime-role \ bound_service_account_names=apigee-runtime-sa \ bound_service_account_namespaces=${APIGEE_NAMESPACE} \ policies=apigee-runtime-app \ ttl=20m
Aquí, suponemos que la cuenta de servicio está dentro del espacio de nombres de Apigee. Si tienes otro espacio de nombres para instalar Apigee, usarás ese nombre.
Sal de la shell dentro de vault-0
exit
Instala el controlador de CSI de la tienda de secrets
# Add repo to helm helm repo add secrets-store-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/secrets-store-csi-driver/master/charts # Install driver in cluster helm install csi secrets-store-csi-driver/secrets-store-csi-driver
Crea un recurso de Kubernetes
SecretProviderClass
que haga referencia al secret que creaste dentro del almacén de Vaultcat > spc-vault.yaml <<EOF apiVersion: secrets-store.csi.x-k8s.io/v1alpha1 kind: SecretProviderClass metadata: name: vault-apigee-runtime-gcp-sa-key spec: provider: vault parameters: vaultAddress: "http://vault.default:8200" roleName: "apigee-runtime-role" objects: | - objectName: "client_secret.json" secretPath: "secret/data/runtime-gcp-sa-key" secretKey: "key" EOF
Aplica el
yaml
kubectl apply -f spc-vault.yaml
Crea la cuenta de servicio de Kubernetes a la que asignamos los permisos en el paso (4.e)
kubectl create serviceaccount -n ${APIGEE_NAMESPACE} apigee-runtime-sa
Modifica el archivo apigee-environment.yaml para el entorno y agrega las siguientes líneas:
apiVersion: apigee.cloud.google.com/v1alpha2 kind: ApigeeEnvironment # existing content spec: name: {ENV_NAME} organizationRef: {ORG_NAME} components: runtime: # existing content pod containers: - name: apigee-runtime podServiceAccountName: apigee-runtime-sa # existing content volumeMounts: - name: secrets-store-inline mountPath: "/opt/apigee/sa" readOnly: true volumes: - name: secrets-store-inline csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: "vault-apigee-runtime-gcp-sa-key"
Aplique los cambios:
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/$ENV_NAME
Actualización de Apigee Hybrid
Debes completar todos los requisitos mencionados en los requisitos previos. Además, recomendamos que reinicies todos los componentes para verificar si el clúster está en buen estado. El orden de los reinicios será Cassandra, Redis, ApigeeOrganization y ApigeeEnvironment.
Crea una copia de seguridad
Crea una copia de seguridad de la configuración actual de hybrid. Necesitarás una copia de seguridad en caso de que necesites revertir la actualización a la versión actual.
tar -czvf apigee-hybrid-install.v-X.Y.Z.tar.gz $HYBRID_INSTALL_BASE_DIR
Crea la copia de seguridad de la base de datos de Cassandra. Las copias de seguridad de Cassandra son una medida importante de protección contra situaciones de desastre.
Actualiza tu plataforma de Kubernetes si es necesario
Este paso no es obligatorio cada vez, pero deberá actualizar su plataforma de Kubernetes, como Kubernetes, OpenShift y componentes como cert-manager, Cassandra, etc., si ya no lo admite una versión más reciente de Apigee Hybrid. La documentación contendrá versiones compatibles de plataformas y componentes.
Descarga archivos de configuración
Descarga el repositorio y reemplaza las carpetas bases
y tools
en la configuración de Apigee Hybrid existente por una más nueva:
Clona la etiqueta preview-1 del repositorio de GitHub en
https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1
El repositorio clonado tendrá una estructura similar a la que se describe en Estructura de carpetas de configuración de Apigee Hybrid:
En la configuración de Apigee Hybrid existente, reemplaza la carpeta de inicialización, las herramientas y el controlador.
export HYBRID_INSTALL_HOME=PATH_TO_PREVIOUS_HYBRID_INSTALL_DIRECTORY mv -f bases $HYBRID_INSTALL_HOME/bases mv -f tools $HYBRID_INSTALL_HOME/tools
Actualiza los permisos de la cuenta de servicio si es necesario
Este paso tampoco es necesario cada vez, pero deberás crear una cuenta de servicio nueva o actualizar los permisos de las cuentas de servicio existentes si es necesario. La guía de actualización proporcionará los detalles sobre las cuentas de servicio que se deben modificar o crear y qué roles se deben agregar.
Si necesitas modificar los permisos de las cuentas de servicio existentes, usa el comando de
gcloud
adecuado. La guía de actualización tendrá comandos y roles detallados que se deben agregar.gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:apigee-component@$PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/$NEW_ROLE"
Si la versión más reciente de Apigee Hybrid puede requerir una cuenta de servicio adicional para los componentes nuevos o existentes, debes crearlos. Puedes usar la secuencia de comandos
apigee-create-service-account.sh
enviada dentro de la carpeta de herramientas para crear cuentas de servicio nuevas. Como la secuencia de comandos ya se actualizará como parte del paso 4, tendrá detalles y un perfil nuevo necesario para una cuenta de servicio nueva que se debe crear.Se debe hacer referencia al nombre de la cuenta de servicio recién creada en el CR de componente correspondiente.
./tools/create-service-account --env prod --profile apigee-component
Actualiza el controlador
Cambia los campos de versión para los componentes enumerados en ${INSTALL_DIR}/overlays/instances/$INSTANCE_DIR/kustomization.yaml
a la versión relevante de hybrid.
Aquí hay un archivo $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/kustomization.yaml de ejemplo. El valor del campo de versión debe actualizarse a la versión relevante.
resources:
- datastore/
- environments/
- organization/
- redis/
- route-config/
- telemetry/
patches:
- target:
group: apigee.cloud.google.com
version: v1alpha1
kind: ApigeeDatastore
patch: |-
- op: add
path: /spec/version
value: 1-6-1 (Modify the version)
- target:
group: apigee.cloud.google.com
version: v1alpha2
kind: ApigeeEnvironment
patch: |-
- op: add
path: /spec/version
value: 1-6-1 (Modify the version)
Sigue el mismo conjunto de pasos proporcionados en Crea recursos y controladores de inicialización en el flujo de trabajo de instalación híbrido de Apigee. Puedes usar la secuencia de comandos o puedes seguir los pasos manuales proporcionados para actualizar el controlador y los recursos de inicialización.
Actualiza los componentes de Kubernetes de Apigee
Deberás realizar los siguientes cambios: - En caso de cambios arquitectónicos o introducción de campos nuevos o baja de los campos anteriores, tendrás que modificar las CR con los cambios apropiados de acuerdo con las instrucciones proporcionadas en la guía de actualización. - Como mínimo, debe actualizar los campos de versión dentro de CR (que denotarán la versión de Apigee Hybrid instalado) a la versión más reciente de Apigee Hybrid.
Aplica los cambios para las CR de Apigee. En un entorno que no es de producción, puedes aplicar todos los cambios a los componentes de Apigee de forma simultánea.
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
Reversión de Apigee Hybrid
Restablece apigee-hybrid-setup
Ve al directorio que contiene la versión anterior de la configuración de Apigee Hybrid. Si no está disponible, restablécelo desde el archivo ZIP creado en el paso 1[link] durante la actualización de Apigee Hybrid.
Componentes de Kubernetes de reversión
Aplica los cambios para las CR de Apigee
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
Controlador de reversión
Sigue el mismo conjunto de pasos proporcionados en crea recursos y controladores de inicialización en el flujo de trabajo de instalación de Apigee hybrid. Puedes usar una secuencia de comandos o puedes seguir los pasos manuales proporcionados para revertir el controlador y los recursos de inicialización.
Limpieza
Deberás limpiar cualquier recurso adicional nuevo creado durante la actualización, como nuevos componentes o cuentas de servicio ingresados en la versión de hybrid más reciente. En la guía de actualización, se proporcionarán todos los recursos que se deben limpiar y los pasos para hacerlo.
Borra un entorno
A continuación, se indican los pasos para borrar todos los recursos relacionados con un entorno de tu clúster de Kubernetes:
Obtén el nombre de la CR del entorno. Para ello, obtén todos los entornos:
kubectl get env -n ${APIGEE_NAMESPACE}
Almacena el nombre del recurso en la variable de entorno
APIGEE_ENV
.Borra las claves de encriptación del entorno. Por ejemplo, si no cambiaste el nombre de las claves de encriptación, puedes borrarlas con el siguiente comando:
kubectl delete secret -n ${APIGEE_NAMESPACE} $APIGEE_ENV-encryption-keys
Borra los secrets de la cuenta de servicio de Google Cloud:
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.appServiceAccountSecretName}')
Borra las cuentas de servicio de Kubernetes:
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.podServiceAccountName}')
Borra el recurso personalizado del entorno de Apigee:
kubectl -n ${APIGEE_NAMESPACE} delete env $APIGEE_ENV
Borra una configuración híbrida
A continuación, se indican los pasos para borrar todos los recursos relacionados con Apigee Hybrid de tu clúster de Kubernetes:
Deberás borrar los trabajos de configuración de usuario y configuración de esquema de Apigee.
# To list all jobs in ${APIGEE_NAMESPACE} kubectl -n ${APIGEE_NAMESPACE} get jobs # To delete all jobs in ${APIGEE_NAMESPACE} kubectl -n ${APIGEE_NAMESPACE} delete jobs $(kubectl -n ${APIGEE_NAMESPACE} get jobs -o custom-columns=':.metadata.name')
Deberás borrar los componentes de Apigee Hybrid Dataplane implementados. Usa el siguiente comando para borrar todos los componentes:
kubectl delete -k ${INSTALL_DIR}/overlays/instances/$INSTANCE_NAME
Este paso solo es necesario si no se basaste en los nombres predeterminados de las cuentas de servicio de Kubernetes, los secrets de la cuenta de servicio de Google Cloud, etc. Si te basaste en los nombres predeterminados, se borrarán en el siguiente paso; de lo contrario, deberás borrarlos de forma manual comandos siguientes:
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get ${APIGEE_COMPONENT} ${APIGEE_COMPONENT_NAME} -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.appServiceAccountSecretName}') kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get ${APIGEE_COMPONENT} ${APIGEE_COMPONENT_NAME} -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.podServiceAccountName}')
En caso de OpenShift, deberás borrar scc (restricciones de contexto de seguridad) creados durante la instalación de Apigee Hybrid.
kubectl delete scc ${SECURITY_CONTEXT_CONSTRAINTS_NAME}
Ejecuta el siguiente comando para borrar funciones, vincular roles, CRD, implementaciones de controladores, etcétera.
kubectl delete -k ${INSTALL_DIR}/overlays/initialization/ingress kubectl delete -k ${INSTALL_DIR}/overlays/initialization/rbac kubectl delete -k ${INSTALL_DIR}/overlays/initialization/webhooks kubectl delete -k ${INSTALL_DIR}/overlays/initialization/crds kubectl delete -k ${INSTALL_DIR}/overlays/initialization/certificates
Ejecuta el siguiente comando para borrar el espacio de nombres de Apigee
kubectl delete -f ${INSTALL_DIR}/overlays/initialization/namespace.yaml
Como alternativa, puedes usar el siguiente comando:
kubectl delete $APIGEE_NAMESPACE
Instalación de varias instancias
La configuración de varias instancias hace referencia a la configuración de hybrid que puede abarcar varias regiones o también dentro de las mismas regiones. Apigee recomienda organizar las configuraciones de la segunda instancia en una estructura de directorio separada, ya que las configuraciones del entorno (réplicas, etc.) no varían entre instancias. Las configuraciones de cada instancia se separan y se organizan de forma independiente en sus respectivas estructuras de carpetas.
Por ejemplo, para una configuración Activa-pasiva en una situación multirregional, puedes configurar una segunda región en una espera semiactiva con diferentes tamaños y configuraciones.
En la siguiente estructura de carpetas, puedes hacer una copia del directorio instance1 llamado instance2 y modificar el almacén de datos y las configuraciones de entrada según sea necesario.
Estructura de carpetas apigee-hybrid-setup
para la configuración de varias instancias.]
.
├── bases
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-controller-deployment.yaml
│ │ │ └── kustomization.yaml
│ │ └── istiod
│ │ ├── apigee-ingressgateway-manager-deployment.yaml
│ │ └── kustomization.yaml
│ └── initialization
│ ├── certificates
│ │ ├── certificates-and-issuers.yaml
│ │ └── kustomization.yaml
│ ├── crds
│ │ ├── customresourcedefinition-apigeedatastores.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeedeployments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeenvironments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeredis.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeerouteconfigs.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeroutes.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeetelemetries.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-cassandradatareplications.apigee.cloud.google.com.yaml
│ │ └── kustomization.yaml
│ ├── ingress
│ │ ├── envoyfilter-1.11.yaml
│ │ └── kustomization.yaml
│ ├── openshift
│ │ ├── kustomization.yaml
│ │ └── scc.yaml
│ ├── rbac
│ │ ├── apigee-controller
│ │ │ ├── kustomization.yaml
│ │ │ └── rbac.yaml
│ │ └── apigee-embedded-ingress-controller
│ │ ├── cluster-role-bindings.yaml
│ │ ├── cluster-roles.yaml
│ │ ├── kustomization.yaml
│ │ └── service-account.yaml
│ └── webhooks
│ ├── kustomization.yaml
│ ├── mutatingwebhookconfiguration.yaml
│ └── validatingwebhookconfiguration.yaml
├── instances
│ └── instance1 (Add the 2nd instance under instances directory similar to instance1)
│ ├── datastore
│ │ ├── apigee-datastore.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── environments
│ │ ├── kustomization.yaml
│ │ └── test
│ │ ├── apigee-environment.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── kustomization.yaml
│ ├── organization
│ │ ├── apigee-organization.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── redis
│ │ ├── apigee-redis.yaml
│ │ ├── components
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── route-config
│ │ ├── kustomization.yaml
│ │ └── test-env-group
│ │ ├── apigee-route-config.yaml
│ │ ├── components
│ │ │ ├── http-and-non-sni-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ ├── http-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ └── non-sni-client
│ │ │ ├── apigee-route.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── telemetry
│ ├── apigee-telemetry.yaml
│ ├── components
│ │ ├── http-proxy
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── imagepullsecret
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── logger
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── metrics
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── nodeselector
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── workload-identity-logger
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ └── workload-identity-metrics
│ │ ├── apigee-workload-identities.yaml
│ │ ├── kustomization.yaml
│ │ └── patch.yaml
│ └── kustomization.yaml
├── overlays
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-hybrid-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ ├── istiod
│ │ │ ├── apigee-ingressgateway-manager-deployment-patch.yaml
│ │ │ ├── apigee-istio-mesh-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ ├── initialization
│ │ ├── certificates
│ │ │ ├── apigee-ingressgateway-manager-certificate.yaml
│ │ │ └── kustomization.yaml
│ │ ├── crds
│ │ │ └── kustomization.yaml
│ │ ├── ingress
│ │ │ └── kustomization.yaml
│ │ ├── namespace.yaml
│ │ ├── openshift
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── rbac
│ │ │ ├── apigee-controller
│ │ │ │ └── kustomization.yaml
│ │ │ ├── apigee-embedded-ingress-controller
│ │ │ │ └── kustomization.yaml
│ │ │ └── kustomization.yaml
│ │ └── webhooks
│ │ ├── kustomization.yaml
│ │ ├── mutatingwebhookconfiguration.yaml
│ │ └── validatingwebhookconfiguration.yaml
│ └── instances
│ └── instance1
│ ├── datastore
│ │ ├── apigee-datastore.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── openshift-scc
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── scc.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── environments
│ │ ├── kustomization.yaml
│ │ └── test
│ │ ├── apigee-environment.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── kustomization.yaml
│ ├── organization
│ │ ├── apigee-organization.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── redis
│ │ ├── apigee-redis.yaml
│ │ ├── components
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── route-config
│ │ ├── kustomization.yaml
│ │ └── test-envgroup
│ │ ├── apigee-route-config.yaml
│ │ ├── components
│ │ │ ├── http-and-non-sni-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ ├── http-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ └── non-sni-client
│ │ │ ├── apigee-route.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── telemetry
│ ├── apigee-telemetry.yaml
│ ├── components
│ │ ├── http-proxy
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── imagepullsecret
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── logger
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── metrics
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── nodeselector
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── openshift-scc
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── workload-identity-logger
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ └── kustomization.yaml
│ │ └── workload-identity-metrics
│ │ ├── apigee-workload-identities.yaml
│ │ ├── kustomization.yaml
│ │ └── patch.yaml
│ └── kustomization.yaml
├── README.md
├── templates
│ ├── ingress-certificate.yaml
│ ├── ingress-cert-secret.yaml
│ └── service-account-key-secret.yaml
└── tools
├── apigee-hybrid-setup.sh
├── common.sh
├── create-service-account.sh
└── dump_kubernetes.sh
Configuración de instancias múltiples en GKE
Requisitos previos
Antes de configurar varias instancias de Hybrid, se espera que hayas completado los siguientes requisitos previos:
- Configura clústeres de Kubernetes en varias regiones (iguales o diferentes) con diferentes bloques de CIDR
- Configura la comunicación entre regiones
- Abre los puertos de Cassandra 7000 y 7001 entre clústeres de Kubernetes en todas las regiones (7000 se puede usar como opción de copia de seguridad durante la solución de problemas). Consulta también Configura puertos.
Puedes usar una herramienta como ntpdate para verificar que los horarios del servidor estén sincronizados.
Configura el host de origen multirregión
- Haz una copia de la carpeta $INSTANCE_NAME de tu instancia existente y agrégala a la carpeta de instancias.
- Modifica el valor del campo del espacio de nombres si difiere del espacio de nombres instance1.
- Sigue los pasos especificados en Especifica los certificados TLS de entrada a fin de modificar la configuración de entrada para la otra instancia.
Consulta la administración de la puerta de enlace de entrada de Apigee para obtener información sobre cómo configurar la IP del balanceador de cargas para la otra instancia
Configura el contexto de kubectl en el clúster original antes de recuperar el nombre de origen
kubectl config use-context original-cluster-name
Ejecuta el siguiente comando kubectl para identificar una dirección de host de origen de Cassandra en la región actual.
kubectl get pods -o wide -n apigee -l app=apigee-cassandra
Cualquiera de las direcciones IP del pod que se muestran en el comando anterior se puede considerar como host inicial multirregión.
En la segunda instancia, configura el valor de multiRegionSeedHost en el CR del almacén de datos de Apigee en ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/apigee-datastore.yaml
Configura la instancia nueva
Configura el contexto en el clúster existente.
kubectl config use-context existing-cluster-name
Exporta el secret apigee-ca a un archivo
kubectl -n cert-manager get secret apigee-root-certificate -o yaml > apigee-root-certificate.yaml
Establece el contexto en el nombre del clúster de la región nueva:
kubectl config use-context NEW_CLUSTER_NAME
Importa el secret al clúster nuevo
kubectl -n cert-manager apply -f apigee-root-certificate.yaml
Para instalar Hybrid en la instancia nueva (región), sigue los pasos descritos en Crea un controlador y recursos de inicialización.
Configura Cassandra en todos los Pods de los nuevos centros de datos. Obtén apigeeorg del clúster con el siguiente comando:
kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
Crea un archivo de recurso personalizado de replicación de datos (YAML). El archivo puede tener cualquier nombre. En los siguientes ejemplos, el archivo tendrá el nombre datareplication.yaml. El archivo debe contener la siguiente información
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: REGION_EXPANSION namespace: NAMESPACE spec: organizationRef: APIGEEORG_VALUE force: false source: region: SOURCE_REGION
Dónde:
- REGION_EXPANSION es el nombre que le asignas a estos metadatos. Puedes elegir un nombre como “cassandra-data-replication”
- NAMESPACE es el mismo espacio de nombres que se eligió para la segunda instancia. Por lo general, es “apigee”.
- APIGEEORG_VALUE es el valor de salida del comando kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name en el paso anterior.
- SOURCE_REGION es el valor del centro de datos de Cassandra del estado de nodetool del clúster de origen.
Aplica CassandraDataReplication con el siguiente comando:
kubectl apply -f datareplication.yaml
Verifica el estado de recompilación con el siguiente comando.
kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
El resultado debería ser similar a lo siguiente
{ "rebuildDetails": { "apigee-cassandra-default-0": { "state": "complete", "updated": 1623105760 }, "apigee-cassandra-default-1": { "state": "complete", "updated": 1623105765 }, "apigee-cassandra-default-2": { "state": "complete", "updated": 1623105770 } }, "state": "complete", "updated": 1623105770 }
Verifica los procesos de recompilación de los registros. Además, verifica el tamaño de los datos con el comando de estado nodetool:
kubectl logs apigee-cassandra-default-0 -f -n apigee
Consulta datastore/secrets.yaml para ver JMX_user y JMX_password
kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool -u JMX_user -pw JMX_password status
Quita
multiRegionSeedHost
de la CR de Apigee Datastore y ejecuta el siguiente comando para aplicar el cambiokubectl apply k apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore
Comprueba el estado del clúster de Cassandra
El siguiente comando es útil para ver si la configuración del clúster se realizó de forma correcta en dos centros de datos. El comando comprueba el estado de la herramienta del nodo de las dos regiones.
kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool -u JMX_user -pw JMX_password status
Datacenter: us-central1 ======================= Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.12.1.45 112.09 KiB 256 100.0% 3c98c816-3f4d-48f0-9717-03d0c998637f ra-1 UN 10.12.4.36 95.27 KiB 256 100.0% 0a36383d-1d9e-41e2-924c-7b62be12d6cc ra-1 UN 10.12.5.22 88.7 KiB 256 100.0% 3561f4fa-af3d-4ea4-93b2-79ac7e938201 ra-1 Datacenter: us-west1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.4.33 78.69 KiB 256 100.0% a200217d-260b-45cd-b83c-182b27ff4c99 ra-1 UN 10.0.0.21 78.68 KiB 256 100.0% 9f3364b9-a7a1-409c-9356-b7d1d312e52b ra-1 UN 10.0.1.26 15.46 KiB 256 100.0% 1666df0f-702e-4c5b-8b6e-086d0f2e47fa ra-1
Soluciona problemas
Guía de asistencia, diagnóstico y solución de problemas
Limpieza manual después de usar forceDelete en la configuración multirregional de Apigee Hybrid
- En el siguiente ejemplo, hay 2 regiones:
us-east1
yus-west1
. - En la región
us-west1
, se borró el almacén de datos de Apigee con la eliminación forzada. - En la región
us-east1
, Cassandra aún está en funcionamiento. Verifica que se haya borrado
apigeeds
con el comandokubectl get apigeeds -n apigee No resources found in apigee namespace.
Cambia el contexto de kubectl a la otra región en la que el clúster de Cassandra aún está en funcionamiento (aquí
us-east1
).Verifica que el almacén de datos esté en ejecución
kubectl get apigeeds -n apigee NAME STATE AGE default running 23h
Ejecuta uno de los Pods de Cassandra en la región ascendente (aquí
us-east1
).kubectl exec -it -n apigee apigee-cassandra-default-0 -- bash apigee@apigee-cassandra-default-0:~$
Verifica el estado de nodetool; mostrará todos los nodos hacia abajo en la región borrada (aquí
us-west1
).apigee@apigee-cassandra-default-0:~$ nodetool -u ${APIGEE_JMX_USER} -pw ${APIGEE_JMX_PASSWORD} status
Datacenter: us-east1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.52.0.212 685.01 KiB 256 ? e1aa61e3-4eae-4549-9b58-506d495d87ab ra-1 UN 10.52.0.72 606.75 KiB 256 ? 477dfc03-f93e-40ea-810a-d15769822ad5 ra-1 UN 10.52.0.104 648.3 KiB 256 ? a8854cff-c2e3-4f0c-a342-e692787efcab ra-1 Datacenter: us-west1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack DN 10.60.0.143 567.06 KiB 256 ? 355d6ace-ab77-42cb-8138-9993bfd62d0e ra-1 DN 10.60.0.40 535.99 KiB 256 ? 4ed2c903-ff56-40fa-a15e-80a3de3cb22d ra-1 DN 10.60.0.17 573.08 KiB 256 ? f9a50d19-c04a-4d0d-a088-612384bed9f5 ra-1
Quita todos los nodos de la región borrada (aquí
us-west1
)apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode 355d6ace-ab77-42cb-8138-9993bfd62d0e apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode 4ed2c903-ff56-40fa-a15e-80a3de3cb22d apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode f9a50d19-c04a-4d0d-a088-612384bed9f5
Verifica que no queden nodos de la región borrada (aquí
us-west1
)apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status
Datacenter: us-east1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.52.0.212 699.71 KiB 256 ? e1aa61e3-4eae-4549-9b58-506d495d87ab ra-1 UN 10.52.0.72 586.77 KiB 256 ? 477dfc03-f93e-40ea-810a-d15769822ad5 ra-1 UN 10.52.0.104 623.6 KiB 256 ? a8854cff-c2e3-4f0c-a342-e692787efcab ra-1
Una vez que se complete esta acción, borra el trabajo de configuración del usuario en la región ascendente (aquí
us-east1
). El trabajo se volverá a crear automáticamente en unos segundos.kubectl get jobs -n apigee
NAME COMPLETIONS DURATION AGE apigee-cassandra-schema-setup-apigee--0d2504c 0/1 5m54s 5m54s apigee-cassandra-user-setup--apigee--0d2504c 0/1 7s 7s
kubectl delete job apigee-cassandra-user-setup--apigee--0d2504c
Espera a que se complete el trabajo de configuración del usuario
kubectl get jobs -n apigee
NAME COMPLETIONS DURATION AGE apigee-cassandra-schema-setup-apigee--0d2504c 1/1 5m54s 5m54s apigee-cassandra-user-setup--apigee--0d2504c 1/1 7m 7m
Verifica que los espacios de claves no tengan la región borrada.
Crea un Pod de depuración de Cassandra.
Accede a cqlsh en el Pod de depuración con el comando siguiente
apigee@cassandra-debug-client:~$ cqlsh apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local -u ddl_user --ssl Password:
Verifica que se quite la región
us-west1
de todos los espacios de clavesddl_user@cqlsh> SELECT * FROM system_schema.keyspaces;
keyspace_name | durable_writes | replication ---------------------------+----------------+----------------------------------------------------------------------------------- cache_prince_hybrid_hybrid | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} rtc_prince_hybrid_hybrid | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} system_auth | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} system_schema | True | {'class': 'org.apache.cassandra.locator.LocalStrategy'} quota_prince_hybrid_hybrid | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} kms_prince_hybrid_hybrid | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} system_distributed | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} system | True | {'class': 'org.apache.cassandra.locator.LocalStrategy'} perses | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} kvm_prince_hybrid_hybrid | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} system_traces | True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'} (11 rows)