Agrega varias organizaciones híbridas a un clúster

En este tema, se explica cómo agregar una segunda organización (org) híbrida de Apigee a un clúster de Kubernetes existente. En esta configuración multiorganización por clúster, ambas organizaciones usan y comparten el mismo anillo de Cassandra. Cada org puede tener varios entornos y grupos de entornos configurados.

Limitaciones

Se admite una configuración multiorganización por clúster con las siguientes limitaciones. No se recomienda usar esta configuración hasta que se mitiguen estas limitaciones.

Si vas a tener varias instancias de Apigee Hybrid, cada instancia debe tener su propio clúster. Varias instancias de Apigee Hybrid que se ejecutan en el mismo clúster de Kubernetes pueden generar problemas de inestabilidad que pueden causar tiempo de inactividad.
Las métricas de Pods solo se envían al primer proyecto de Google Cloud que se configuró. Esta limitación es más evidente en la herramienta de Cloud Monitoring. Solo afecta las métricas del clúster; las estadísticas de la API no se ven afectadas. Las métricas de las otras organizaciones de Apigee no se enviarán al proyecto de Google Cloud coincidente.
Todos los registros de los Pods se envían al primer proyecto de Google Cloud que se configuró. Esta limitación es más evidente en la herramienta de Cloud Logging. Los registros de las otras organizaciones de Apigee no se enviarán al proyecto de Google Cloud coincidente. Los registros aún se capturan a nivel del Pod y se pueden recuperar con los comandos de kubectl. Sin embargo, no se envían al proyecto de Cloud correcto a través de Cloud Logging.
No puedes borrar datos de organización en la base de datos de Cassandra para una sola organización. Esto significa que no puedes quitar las organizaciones de forma selectiva. Cualquier modificación en la configuración de la base de datos afecta a todas las organizaciones implementadas en ese clúster.
El procedimiento de actualización híbrida actualiza todo el clúster de una sola vez.
Las copias de seguridad y los restablecimientos se realizan como un clúster y no para una organización específica.
La característica de supervisión de la API de Apigee (Cronograma, Recientes, Investigar) solo funciona en la primera organización que se configuró y se implementó. No funcionará para las otras organizaciones de un clúster multiorganización.

Opciones multiorganización

En esta sección, se describe cómo el servicio de asistencia de Apigee controla los clústeres multiorganización y las recomendaciones existentes para implementaciones futuras:

Si tienes clústeres multiorganización de Kubernetes existentes implementados en contextos de producción y no producción, la Compatibilidad de Apigee continuará admitiéndolos. Sin embargo, ten en cuenta las limitaciones técnicas que se describen en la sección siguiente. Te recomendamos que cambies cualquier implementación de producción futura para usar una organización de Apigee por clúster.
Si tienes clústeres multiorganización existentes en contextos que no son de producción, la Compatibilidad de Apigee continuará admitiéndolos. Recomendamos que migres los clústeres de producción a una configuración nueva que use una organización de Apigee por clúster.

Requisitos previos

Antes de continuar, ten en cuenta lo siguiente:

Debes tener una organización híbrida existente con uno o más entornos instalados y configurados en un clúster de Kubernetes existente. Consulta las instrucciones de instalación híbrida.
Cuando se combinan varias organizaciones en un solo clúster, todas las versiones híbridas deben coincidir. Antes de agregar una segunda organización a un clúster, actualiza la instalación híbrida existente, si es necesario. Consulta Actualiza Apigee Hybrid.

Crea una organización para agregarla al clúster existente

Para crear la organización adicional, sigue los pasos de la Parte 1: Configuración del proyecto y de la organización.

Configura la organización nueva

En los siguientes pasos, crearás un archivo de anulaciones nuevo y lo configurarás para la organización nueva. Un archivo overrides.yaml solo puede admitir la información de una organización. Por lo tanto, debes crear un archivo overrides.yaml nuevo y aplicarlo al clúster de Kubernetes existente.

Crea cuentas de servicio para usar con la organización nueva. Consulta Crea cuentas de servicio.
Toma nota de los archivos del certificado TLS (.key y .pem) en el directorio certs. Si necesitas volver a crearlos, puedes seguir las instrucciones en Crea certificados TLS.
Copia tu overrides.yaml existente en un archivo nuevo para usarlo como punto de partida a fin de configurar la organización nueva. Por ejemplo: new-overrides.yaml.

Edita el nuevo archivo de anulaciones con la siguiente configuración:

org: "new-org-name"
instanceID: "instance-id"   ## Must match the instanceID of your existing org.

k8sCluster:
  name: "existing-cluster-name"
  region: "existing-cluster-analytics-region"

gcp:
  projectID: "new-project-id"
  name: "new-project-id"
  region: "new-project-default-location"

namespace: namespace ## must be the same for both new and existing orgs

virtualhosts:
  - name: new-environment-group-name
    sslCertPath: ./certs/cert-file-name # .crt or .pem
    sslKeyPath: ./certs/key-file-name # .key

envs:
  - name: new-environment-name
    serviceAccountPaths:
      runtime: ./new-service-accounts-directory/new-project-id-apigee-runtime.json
      synchronizer: ./new-service-accounts-directory/new-project-id-apigee-synchronizer.json
      udca: ./new-service-accounts-directory/new-project-id-apigee-udca.json

connectAgent:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-mart.json

mart:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-mart.json

metrics:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-metrics.json

watcher:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-watcher.json

En la siguiente tabla, se describe cada uno de los valores de propiedad que debes proporcionar en el archivo de anulación. Para obtener más información, consulta Referencia de la propiedad de configuración.

Variable	Descripción
`new-org-name`	El nombre de tu nueva organización.
`instance-id`	Todas las organizaciones de este clúster deben tener el mismo ID de instancia. Por lo tanto, debe coincidir con la entrada `instanceID` en el archivo de anulaciones para tu organización original. En el caso de las instalaciones multirregionales, cada región requiere su propio clúster, ya que los individuales no abarcan regiones. Por lo tanto, cada clúster debe tener su propio ID de instancia único compartido por todas las organizaciones del clúster.
`existing-cluster-name`	El nombre del clúster al que agregas esta organización. Debe coincidir con la entrada `k8sCluster.name` en el archivo de anulaciones para tu clúster original.
`existing-cluster-analytics-region`	La región en la que se aprovisiona el clúster original. Debe coincidir con la entrada `k8sCluster.region` en el archivo de anulaciones para tu clúster original.
`new-project-id`	El ID del proyecto nuevo. El ID del proyecto y el nombre de la organización son iguales.
`new-project-default-location`	La región de estadísticas que especificaste cuando creaste la organización nueva. No es necesario que sea igual que la región de la organización existente.
`namespace`	Todas las organizaciones del clúster deben compartir el mismo espacio de nombres. Asegúrate de usar el mismo espacio de nombres que se usó para la organización original. Ten en cuenta que el espacio de nombres predeterminado es `apigee`.
`new-environment-group-name`	El nuevo grupo de entorno que creaste para la nueva organización.
`cert-file-name` y `key-file-name`	El certificado TLS y los archivos de claves para el clúster que verificaste o creaste en el paso 1 de esta sección.
`new-environment-name`	El nombre del entorno que creaste para la nueva organización.
`new-service-accounts-directory`	El directorio en el que se encuentran los archivos de claves de la cuenta de servicio que creaste para la organización nueva.

Aplica la configuración

Aplica la nueva configuración de la organización a tu clúster:

Realiza una instalación de ejecución de prueba para verificar si hay problemas:
```
apigeectl apply -f overrides/new-overrides.yaml --org --dry-run=client
```
Nota: Se recomienda realizar una prueba de validación antes de aplicar la configuración para determinar si hay algún problema.
Si no hay problemas, aplica los componentes a nivel de la organización. En este paso, se instalan los trabajos de Cassandra (usuario y esquema), los servicios de Apigee Connect, Apigee Watcher y MART:
```
apigeectl apply -f overrides/new-overrides.yaml --org
```
Instala el entorno. En este paso, se instalan los componentes de UDCA, apigee-runtime y el sincronizador por entorno:
```
apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME} --dry-run=client
```
```
apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME}
```
Nota: Si tienes varios entornos en tu nueva organización, repite este paso para cada entorno.
Aplica los cambios del balanceador de cargas. En este paso, se configura la entrada para que escuche los nuevos hosts virtuales de la segunda organización:
Importante: No dupliques los nombres de host ni los nombres de dominio entre dos organizaciones, ya que puede dar como resultado un enrutamiento impredecible.
```
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts --dry-run=client
```
```
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts
```
Habilita el acceso del sincronizador para tu organización nueva siguiendo los pasos en Habilita el acceso del sincronizador.