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

multiOrgCluster: true ## Enables exporting metrics for this org to the Google Cloud Project named with gcp:projectID

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. El espacio de nombres para la mayoría de las instalaciones es `apigee`.
`new-environment-group-name`	El nuevo grupo de entornos que creaste para la nueva organización. Precaución: Los nombres de los grupos de entornos para la nueva organización no deben ser los mismos que los nombres de los grupos de entornos de cualquier otra organización. Los nombres de las versiones de Helm para los entornos serían los mismos, lo que dificultaría la administración de los charts.
`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. Precaución: Los nombres de los entornos de la nueva organización no deben ser los mismos que los nombres de los entornos de cualquier otra 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 prueba de validación para verificar si hay problemas:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f OVERRIDES_FILE.yaml \
  --dry-run
```
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:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml
```

Instala el entorno. En este paso, se instalan los componentes de apigee-runtime, el sincronizador y UDCA, por entorno:

helm upgrade ENV_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --atomic \
  --set env=ENV_NAME \
  -f overrides.yaml \
  --dry-run

helm upgrade ENV_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --atomic \
  --set env=ENV_NAME \
  -f overrides.yaml

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:

helm upgrade NEW_ENV_GROUP_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=NEW_ENV_GROUP_NAME \
  -f overrides.yaml \
  --dry-run

helm upgrade NEW_ENV_GROUP_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=NEW_ENV_GROUP_NAME \
  -f overrides.yaml

Habilita el acceso del sincronizador para tu organización nueva siguiendo los pasos en Habilita el acceso del sincronizador.
De forma predeterminada, cuando instalas el entorno de ejecución de Apigee Hybrid por primera vez, el componente de telemetría se configura con multiOrgCluster inhabilitado. Sigue estos pasos para habilitar la telemetría multiorganización de cada organización en el clúster:
1. Borra el componente de telemetría existente con los siguientes comandos:
```
helm delete telemetry
```
  Nota: Borrar el componente de telemetría detendrá las métricas que se exportan a Google Monitoring. Sigue estos pasos para volver a habilitar las métricas.
2. Agrega la siguiente línea al archivo overrides.yaml de tu organización existente.
```
multiOrgCluster: true
```
3. Aplica los cambios para instalar el componente de telemetría de la organización.
  Realiza primero una ejecución de prueba:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f FIRST_OVERRIDES_FILE.yaml \
  --dry-run
```
  Si la ejecución de prueba se realiza de forma correcta, aplica los cambios y, luego, instala el componente de telemetría:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f FIRST_OVERRIDES_FILE.yaml
```
4. Asegúrate de que la línea siguiente esté en el archivo overrides.yaml de cada organización nueva.
```
multiOrgCluster: true
```
5. Aplica los cambios a fin de instalar el componente de telemetría para cada organización nueva. Repite esto para cada organización nueva en tu clúster multiorganización.
  Realiza primero una ejecución de prueba:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml \
  --dry-run
```
  Si la ejecución de prueba se realiza de forma correcta, aplica los cambios y, luego, instala el componente de telemetría:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml
```