Nueva vista previa del la instalación y administración de Apigee Hybrid

Esta vista previa está descontinuada.

Vista previa — Apigee hybrid new install process (discontinued)

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

---

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
  • Comentarios
• Descripción general
  • Cambios en el nuevo proceso de instalación
• Requisitos previos
  • Versión de vista previa
  • Configuración de Apigee hybrid
  • Herramientas
• Instalación básica de Apigee hybrid
  • Descarga archivos de configuración
  • Ejecuta la configuración
• 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
  • Descripción general
  • Cómo usar componentes
  • OpenShift
  • imagepullsecret
  • nodeselector
  • workload-identity
  • http-proxy
  • registrador y métricas
  • gcs-backup y gcs-restore
  • non-gcs-backup y non-gcs-restore
  • http-client
  • non-sni-client
  • http-and-non-sni-client
  • multirregional
• Conceptos
  • Agrega un entorno nuevo
  • Usa la eliminación forzada en Apigee Datastore
• 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
  • Crea una copia de seguridad
  • Actualiza tu plataforma de Kubernetes si es necesario
  • Descarga archivos de configuración
  • Actualiza los permisos de la cuenta de servicio si es necesario
  • Actualiza el controlador
  • Actualiza los componentes de Kubernetes de Apigee
• Reversión de Apigee Hybrid
  • Restablece apigee-hybrid-setup
  • Componentes de Kubernetes de reversión
  • Controlador de reversión
• Limpieza
• Borra un entorno
  • Borra una configuración híbrida
• Instalación de varias instancias
  • Configuración de instancias múltiples en GKE
  • Solución de 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

Obtener vista previa

---

Nota: Este documento y el software que documenta son parte de una versión preliminar. Apigee no garantiza el software ni los procedimientos en esta vista previa. La documentación y el software están sujetos a cambios sin previo aviso.

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 [e-mail].

---

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:

1. 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
2. Configurar el entorno de ejecución híbrido
   • Paso 1: Crea un clúster
   • Paso 2: Instalar cert-manager

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 comandos apigee-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.

  Nota: Las versiones de KPT v0.39 y anteriores no son compatibles. Descarga kpt desde el vínculo mencionado anteriormente (v1.0+) para asegurarte de que funcione.

• 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 es apigee. 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úster
• CLUSTER_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 subdirectorio apigee-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 llama instance-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.

---

Nota: Una instalación básica tiene la siguiente configuración:

• Un solo entorno
• Un solo grupo de entornos
• Se crea una sola cuenta de servicio de Google Cloud y se usa para todos los componentes individuales.
• Valores predeterminados para todas las claves de encriptación y contraseñas.

---

1. Descarga archivos de configuración
2. Ejecuta la configuración

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:

1. Clone el repositorio:

   git clone https://github.com/apigee/apigee-hybrid-install.git
   

2. Navega al directorio del repositorio clonado:

   cd apigee-hybrid-install
   

3. Crea una rama a partir de la etiqueta preview-1:

   git branch preview-1 preview-1
   git checkout preview-1
   

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

---

Nota: La secuencia de comandos con estos argumentos usa la organización de Apigee, el entorno y el grupo de entornos que creaste en los requisitos previos.

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

---

Nota: Estos pasos requieren una comprensión básica de los conceptos de Kubernetes. Consulta la sección Conceptos o la documentación de Kubernetes para obtener más información.

---

Descarga archivos de configuración

Descarga y prepara los archivos de configuración:

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

2. cd en el directorio apigee-hybrid-install/

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

---

Nota: Apigee es el nombre predeterminado del espacio de nombres. Puedes usar un nombre diferente.

---

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:

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

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

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

2. 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-istiod-deployment.yaml, y reemplazar todos los campos image con la imagen de su repositorio privado.

---

Nota: Si extraes imágenes de un repositorio privado, lo más probable es que debas autenticarse para extraer esas imágenes. Las credenciales necesarias para esta autenticación se especifican como imagePullSecrets, que se analiza en detalle en Configura imagePullSecrets (opcional).

---

Configura imagePullSecrets (opcional)

1. 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.
2. 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 componente imagePullSecret en el archivo kustomization.yaml correspondiente.

---

Nota: Si también usas imágenes privadas para el controlador, es posible que también debas agregar campos imagePullSecret en la especificación de implementación que se encuentra en los archivos apigee-controller-deployment.yaml y apigee-ingressgateway-manager-deployment.yaml.

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}

---

Nota: Si cambias el nombre del secret anterior, deberás realizar el cambio correspondiente en apigee-route-config.yaml cambiando el valor de secretNameRef a YOUR_SECRET_NAME

---

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

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. Agrega una nueva implementación de Ingress

ingressGateways:
- name: "prod-1"
- name: "prod-2"

Configura cuentas de servicio personalizadas de Google Cloud

---

Nota: Una opción es obligatoria: Configurar cuentas de servicio personalizadas de Google Cloud o Usar identidades de carga)

---

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.

---

Nota: Los Secrets que contienen las claves de la cuenta de servicio se pueden obtener de herramientas externas de administración de Secrets, como Vault. Consulta la sección Almacena claves de cuentas de servicio en almacenes de datos externos para obtener detalles sobre cómo hacerlo.

---

Usa Workload Identity

---

Nota: Las identidades de cargas de trabajo solo se pueden usar con clústeres de GKE en Google Cloud.

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.

1. Edita el archivo custom.yaml para la creación del certificado: $INSTALL_DIR/overlays/initialization/certificates/kustomize.yaml

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

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

  ---

  Nota: Para comprender mejor Kustomize y cómo se usaron las superposiciones a fin de modificar las bases, se recomienda que revises Kustomize Patches.

  ---

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ón resources:, 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.

Uso:

1. Si aún no instalaste Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán en el proceso

2. 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
  • OPCIONAL: Cambia el valor de la etiqueta del selector de nodos de apigee-runtime o apigee-data a la deseada.

Uso:

1. Si aún no instalaste Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán en el proceso

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

En el ejemplo anterior, se ilustra lo siguiente: ${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, 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 la GSA_NAME correspondiente. Puedes comparar las tablas de las 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:

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

2. 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 ser HTTP o HTTPS
  • host: OBLIGATORIO La dirección del host de tu proxy
  • port: OBLIGATORIO el número de puerto
  • username: OPCIONAL El nombre de usuario asociado a tu proxy
  • password: OPCIONAL La contraseña para acceder al proxy

Uso:

1. Si aún no instalaste Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán en el proceso

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

1. 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 las identidades de carga de trabajo, puedes volver a usar las claves descargadas disponibles en la carpeta de cuentas de servicio 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
     

2. 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}"
   

   Aquí:

   • ${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í.
  • OPCIONAL: 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í.
  • OPCIONAL: 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

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

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

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

1. Se pueden usar los pasos de la documentación existente para Configurar el servidor y SSH.

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

   ---

   Nota: Asegúrate de que el archivo de claves privadas SSH tenga una línea nueva al final.

   ---

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

   Aquí:

   • ${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í.
  • OPCIONAL: 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_IP. La descripción coincide con BACKUP_SERVER_IP descrita aquí.
  • OBLIGATORIO Cambia el valor de BACKUP_STORAGE_DIR. La descripción coincide con BACKUP_STORAGE_DIR que se describió aquí.
• components/non-gcs-restore/job-patch.yaml
  • OBLIGATORIO Cambia el valor de la variable de entorno BACKUP_SNAPSHOT_TIMESTAMP. La descripción coincide con restore:snapshotTimestamp descrita aquí.
  • OBLIGATORIO Cambia el valor de BACKUP_SERVER_IP. La descripción coincide con BACKUP_SERVER_IP descrita aquí.
  • OBLIGATORIO Cambia el valor de BACKUP_STORAGE_DIR. La descripción coincide con BACKUP_STORAGE_DIR que se describió aquí.
  • OPCIONAL: 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 una descripción general sobre el restablecimiento de copias de seguridad, consulta la descripción general del restablecimiento de Cassandra.

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

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

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

1. Si aún no instalaste Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán en el proceso

2. 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 con credential_name descrita aquí.

Uso:

1. Si aún no instalaste Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán en el proceso

2. 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 con credential_name descrita aquí.

Uso:

1. Si aún no instalaste Apigee Hybrid, puedes continuar con los pasos de instalación y estos cambios se aplicarán en el proceso

2. Si ya tienes Apigee Hybrid instalado, deberás aplicar estos nuevos cambios mediante los siguientes pasos:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

multirregional

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

• 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
  

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.

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

2. Ejecutar:

   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.

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

4. Cambia el contexto del clúster al clúster nuevo en el que instalarás Apigee Hybrid.

   kubectl config use-context ${NEW_CLUSTER_CONTEXT}
   

5. Crea el secret raíz en el clúster nuevo:

   kubectl -n cert-manager apply -f apigee-root-certificate.yaml
   

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

7. Quita los comentarios de las siguientes líneas en el archivo overlays/initialization/certificates/kustomization.yaml:

   # components:
   # - ./components/disable-apigee-root-certificate-generation
   

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

9. Verifica el estado de recompilación con el siguiente comando.

   ---

   Nota: La operación de recompilación puede demorar varias horas en función del tamaño de los datos.

   ---

   kubectl -n ${APIGEE_NAMESPACE} get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
   

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

11. Verifica el estado de recompilación con el siguiente comando.

    ---

    Nota: La operación de recompilación puede demorar varias horas en función del tamaño de los datos.

    ---

    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.

12. Quita las siguientes líneas de components/multi-region/patch.yaml:

      properties:
        multiRegionSeedHost: {IP_ADDRESS} # To be modified. REQUIRED
    

13. 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 campo version, 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 que IMAGE_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 contenedor apigee-runtime, el IMAGE_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 usa dentro de cada contenedor 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 la cuenta de servicio de Google Cloud, que luego se pueden usar para fines de 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
organization
	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	No disponible
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)
organization
	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:

1. Crea una carpeta nueva dentro del directorio de los entornos (o de la estructura de tus carpetas)
2. Copia el archivo apigee-environment.yaml de cualquier entorno existente a la carpeta nueva.
3. 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)
4. 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.
5. 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.

---

Nota: El uso de la eliminación forzada también borrará los PVC. Por lo tanto, si la implementación actual de Apigee Hybrid es el único motivo, realiza una copia de seguridad antes de continuar.

---

---

Nota: El uso de la eliminación forzada en clústeres multiregional requiere una limpieza manual en otras regiones después de que se complete la eliminación del almacén de datos para mantener la cascada en buen estado. Consulta la guía de solución de problemas para realizar una limpieza manual.

---

1. Borra apigeeds en el espacio de nombres apigee:

   Kubectl delete -n apigee apigeeds default
   

   Si este paso se atasca, puede salir de eso con CTRL + C.

2. Edita un apigeeds nuevo:

   Kubectl edit -n apigee apigeeds default
   

3. Agrega o actualiza el campo forceDelete en la especificación del almacén de datos de Apigee

   spec:
   forceDelete: true
   

4. 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 nombres apigee. 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 que se encuentra seleccionado en gcloud.
• --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/nombre de dominio que se usará a fin de generar los certificados TLS autofirmados para la entrada de puerta de enlace 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 secrets de Kubernetes que contienen la clave. Los nombres de los secrets 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

certificates

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.

ingress

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.

organization

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

tools

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.

---

Nota: En este ejemplo, se instalará Vault en modo de desarrollador con fines de prueba. Para un sistema de producción real, deseas instalar uno de los otros modos que se enumeran aquí. Si deseas obtener los pasos detallados a fin de instalar Vault para casos de uso de producción, consulta Vault en la guía de implementación de Kubernetes | Vault.

---

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

2. Sigue los pasos de la página sobre cómo instalar el gráfico de Helm para Vault, es decir:

   1. Agrega el repositorio de Hashicorp a helm

      helm repo add hashicorp https://helm.releases.hashicorp.com
      

   2. Actualiza repositorios de Helm

      helm repo update
      

   3. Instala Vault

      helm install vault hashicorp/vault \
      --set "server.dev.enabled=true" \
      --set "injector.enabled=false" \
      --set "csi.enabled=true"
      

3. Ahora, almacenaremos el secret en Vault.

   1. Obtén una shell dentro del Pod de desarrollo de Vault

      kubectl exec -it vault-0 -- /bin/sh
       ```
      

   2. 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}"
      

   3. Para verificar que la clave se haya almacenado de forma correcta, usa lo siguiente:

      vault kv get secret/runtime-gcp-sa-key
      

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

   1. Obtén una shell dentro del Pod de desarrollo de Vault

      kubectl exec -it vault-0 -- /bin/sh
      

   2. Habilita el método de autenticación de Kubernetes

      vault auth enable kubernetes
      

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

   4. Crea la política de autenticación

      vault policy write apigee-runtime-app - <<EOF
      path "secret/data/runtime-gcp-sa-key" {
      capabilities = ["read"]
      }
      EOF
      

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

   1. Sal de la shell dentro de vault-0

      exit
      

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

6. Crea un recurso de Kubernetes SecretProviderClass que haga referencia al secret que creaste dentro del almacén de Vault

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

7. Aplica el yaml

   kubectl apply -f spc-vault.yaml
   

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

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

10. Aplique los cambios:

    kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/$ENV_NAME
    

Actualización de Apigee Hybrid

---

Nota: Este procedimiento abarca las actualizaciones entre las versiones híbridas que son compatibles con el nuevo modelo de instalación. No abarca la migración de la experiencia de apigeectl al nuevo modelo de instalación.

---

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

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

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

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

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

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

2. Componentes de Kubernetes de reversión

   Aplica los cambios para las CR de Apigee

   kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
   

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

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

---

Precaución: Si tienes varios entornos, asegúrate de que no se haga referencia a los Secrets que borras en los otros entornos. Para verificarlo, haz kubectl get env -n ${APIGEE_NAMESPACE} ${ENV_RESOURCE_NAME} -o yaml y, luego, usa grep para buscar el recurso que quieras borrar.

---

A continuación, se indican los pasos para borrar todos los recursos relacionados con un entorno de tu clúster de Kubernetes:

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

2. Borra las claves de encriptación del entorno. Por ejemplo, si no cambiaste el nombre de las claves de encriptación, puedes borrarlas mediante los siguientes pasos:

   kubectl delete secret -n ${APIGEE_NAMESPACE} $APIGEE_ENV-encryption-keys
   

3. 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}')
   

4. 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}')
   

5. Borra el recurso personalizado del entorno de Apigee:

   kubectl -n ${APIGEE_NAMESPACE} delete env $APIGEE_ENV
   

Borra una configuración híbrida

---

Precaución: Así aparecerán los pasos para la instalación normal de apigee hybrid, los pasos diferirán ligeramente para casos avanzados como tener una segunda organización dentro del mismo clúster, etcétera.

---

A continuación, se indican los pasos para borrar todos los recursos relacionados con Apigee Hybrid de tu clúster de Kubernetes:

1. 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')
   

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

3. 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}')
   

4. 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}
   

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

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

---

Nota: Apigee recomienda que te asegures de que los tiempos de tus servidores estén sincronizados. Varias funciones, como el vencimiento y la revocación de tokens, dependen de horarios precisos del sistema. Si alojas los componentes del entorno de ejecución en diferentes centros de datos, asegúrate de que los tiempos del sistema estén sincronizados.

Puedes usar una herramienta como ntpdate para verificar que los horarios del servidor estén sincronizados.

---

Configura el host de origen multirregión

1. Haz una copia de la carpeta $INSTANCE_NAME de tu instancia existente y agrégala a la carpeta de instancias.
2. Modifica el valor del campo del espacio de nombres si difiere del espacio de nombres instance1.
3. Sigue los pasos especificados en Especifica los certificados TLS de entrada a fin de modificar la configuración de entrada para la otra instancia.

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

   ---

   Nota: Se recomienda no modificar la configuración del resto de los componentes, excepto los que se enumeran en los próximos pasos.

   ---

5. Configura el contexto de kubectl en el clúster original antes de recuperar el nombre de origen

   kubectl config use-context original-cluster-name
   

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

7. Cualquiera de las direcciones IP del pod que se muestran en el comando anterior se puede considerar como host inicial multirregión.

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

1. Configura el contexto en el clúster existente.

   kubectl config use-context existing-cluster-name
   

2. Exporta el secret apigee-ca a un archivo

   kubectl -n cert-manager get secret apigee-root-certificate -o yaml > apigee-root-certificate.yaml
   

3. Establece el contexto en el nombre del clúster de la región nueva:

   kubectl config use-context NEW_CLUSTER_NAME
   

4. Importa el secret al clúster nuevo

   kubectl -n cert-manager apply -f apigee-root-certificate.yaml
   

5. Para instalar Hybrid en la instancia nueva (región), sigue los pasos descritos en Crea un controlador y recursos de inicialización.

6. 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"
   

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

   Aquí:

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

8. Aplica CassandraDataReplication con el siguiente comando:

   kubectl apply -f datareplication.yaml
   

9. Verifica el estado de recompilación con el siguiente comando.

   ---

   Nota: La operación de recompilación puede demorar varias horas en función del tamaño de los datos.

   ---

   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
   }
   

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

11. Quita multiRegionSeedHost de la CR de Apigee Datastore y ejecuta el siguiente comando para aplicar el cambio

    kubectl apply k apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore
    

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

https://cloud.google.com/apigee/docs/api-platform/troubleshoot/playbooks/troubleshooting-apigee-hybrid.

Limpieza manual después de usar forceDelete en la configuración multirregional de Apigee Hybrid

• En el siguiente ejemplo, hay 2 regiones: us-east1 y us-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 comando

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

  • Sigue la versión híbrida 1.5+, sigue la documentación de la guía de solución de problemas de Cassandra (p. ej., para Hybrid 1.5 - enlace, Hybrid 1.6 - enlace) y, luego, ejecuta el Pod creado.

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

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