Esta página se ha traducido con Cloud Translation API.

Añadir varias organizaciones híbridas a un clúster

En este tema se explica cómo añadir una segunda organización de Apigee hybrid a un clúster de Kubernetes. En esta configuración de varias organizaciones, ambas organizaciones usan y comparten el mismo anillo de Cassandra. Cada organización puede tener configurados varios entornos y grupos de entornos.

Limitaciones

Se admite una configuración de varias organizaciones por clúster con las siguientes limitaciones. Hasta que se mitiguen estas limitaciones, no te recomendamos que uses esta configuración:

Si vas a tener varias instancias de Apigee hybrid, cada instancia debe tener su propio clúster. Si se ejecutan varias instancias híbridas de Apigee en el mismo clúster de Kubernetes, pueden producirse problemas de inestabilidad que provoquen tiempos de inactividad.
Todos los registros de los pods se envían al primer proyecto de Google Cloud que se haya configurado. Esta limitación es más evidente en la herramienta Cloud Logging. Los registros de las otras organizaciones de Apigee no se enviarán al proyecto de Google Cloud correspondiente. Los registros se siguen recogiendo a nivel de pod y se pueden recuperar con comandos kubectl. Sin embargo, no se envían al proyecto de Cloud correcto a través de Cloud Logging.
No puede eliminar los datos de una organización en la base de datos de Cassandra. Esto significa que no puedes eliminar organizaciones de forma selectiva. Cualquier modificación en la configuración de la base de datos afecta a todas las organizaciones que se hayan implementado en ese clúster.
El procedimiento de actualización híbrida actualiza todo el clúster a la vez.
Las copias de seguridad y la restauración se realizan en el clúster y no se pueden hacer en una organización específica.
La función de monitorización de APIs de Apigee (Cronología, Recientes e Investigar) solo funciona en la primera organización que se configuró e implementó. No funcionará en las otras organizaciones de un clúster de varias organizaciones.

Opciones de varias organizaciones

En esta sección se describe cómo gestiona el equipo de Asistencia de Apigee los clústeres multiorganización y las recomendaciones para futuros despliegues:

Si tienes clústeres de Kubernetes multiorganización desplegados en contextos de no producción y producción, el equipo de Asistencia de Apigee seguirá ofreciéndote asistencia. Sin embargo, ten en cuenta las limitaciones técnicas que se indican en la siguiente sección. 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 en contextos que no son de producción, el equipo de Asistencia de Apigee seguirá ofreciéndote asistencia. Te recomendamos que migres todos los clústeres de producción a una nueva configuración 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 con uno o varios entornos instalados y configurados en un clúster de Kubernetes. 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 añadir una segunda organización a un clúster, actualiza la instalación híbrida, si es necesario. Consulta Actualizar Apigee Hybrid.

Crea una organización para añadirla al clúster

Para crear la organización adicional, sigue los pasos de la parte 1: Configuración de proyectos y organizaciones.

Configurar la nueva organización

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

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

Edita el nuevo archivo de anulaciones con las siguientes configuraciones:

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 describen los valores de propiedad que debe proporcionar en el archivo de anulaciones. 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` del archivo de anulaciones de tu organización original. En las instalaciones multirregión, cada región requiere su propio clúster, ya que los clústeres individuales no abarcan varias regiones. Por lo tanto, cada clúster debe tener su propio ID de instancia único, que se comparte con todas las organizaciones del clúster.
`existing-cluster-name`	El nombre del clúster al que vas a añadir esta organización. Debe coincidir con la entrada `k8sCluster.name` del archivo de anulaciones de su clúster original.
`existing-cluster-analytics-region`	Región en la que se aprovisiona el clúster original. Debe coincidir con la entrada `k8sCluster.region` del archivo de anulaciones de su 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 analíticas que especificó al crear la organización. No tiene por qué ser la misma que la de la organización.
`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ó en la organización original. El espacio de nombres de la mayoría de las instalaciones es `apigee`.
`new-environment-group-name`	El nuevo grupo de entornos que has creado para la nueva organización. Precaución: Los nombres de los grupos de entornos de la nueva organización no deben ser los mismos que los de los grupos de entornos de ninguna otra organización. Los nombres de las versiones de Helm de los entornos serían los mismos, lo que dificultaría la gestión de los gráficos.
`cert-file-name` y `key-file-name`	Los archivos de certificado y clave TLS del clúster que has comprobado o creado en el paso 1 de esta sección.
`new-environment-name`	El nombre del entorno que has creado para la nueva organización. Precaución: Los nombres de los entornos de la nueva organización no deben ser los mismos que los de ninguna otra organización.
`new-service-accounts-directory`	El directorio en el que se encuentran los archivos de claves de cuenta de servicio que has creado para la nueva organización.

Aplica la configuración

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

Haz una prueba de instalación para comprobar si hay algún problema:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f OVERRIDES_FILE.yaml \
  --dry-run=server
```
Nota: Es recomendable hacer una prueba de funcionamiento antes de aplicar la configuración para determinar si hay algún problema.
Si no hay ningún problema, aplica los componentes a nivel de organización. En este paso se instalan los trabajos de Cassandra (usuario y esquema), Apigee Connect, Apigee Watcher y los servicios 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 apigee-runtime, synchronizer y UDCA por entorno:

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

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

Aplica los cambios del balanceador de carga. En este paso se configura el ingreso 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=server

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 nueva organización siguiendo los pasos que se indican en Habilitar el acceso al plano de control.
De forma predeterminada, cuando instalas por primera vez el entorno de ejecución híbrido de Apigee, el componente Telemetría se configura con multiOrgCluster inhabilitado. Sigue estos pasos para habilitar la telemetría de varias organizaciones en cada organización de tu clúster:
1. Elimina el componente Telemetry con los siguientes comandos:
```
helm delete telemetry
```
  Nota: Si eliminas el componente Telemetría, las métricas dejarán de exportarse a Google Monitoring. Sigue estos pasos para volver a habilitar las métricas.
2. Añade la siguiente línea al archivo overrides.yaml de tu organización.
```
multiOrgCluster: true
```
3. Aplica los cambios para instalar el componente Telemetría en la organización.
  Primero, haz una prueba de funcionamiento:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f FIRST_OVERRIDES_FILE.yaml \
  --dry-run=server
```
  Si la prueba se realiza correctamente, aplica los cambios e instala el componente Telemetry:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f FIRST_OVERRIDES_FILE.yaml
```
4. Asegúrate de que la siguiente línea esté en el archivo overrides.yaml de cada nueva organización.
```
multiOrgCluster: true
```
5. Aplica los cambios para instalar el componente Telemetría en cada nueva organización. Repite este proceso con cada organización nueva de tu clúster multiorganización.
  Primero, haz una prueba de funcionamiento:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml \
  --dry-run=server
```
  Si la prueba se realiza correctamente, aplica los cambios e instala el componente Telemetry:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml
```