Ajouter plusieurs organisations hybrides à un cluster

Cet article explique comment ajouter une deuxième organisation Apigee hybrid à un cluster Kubernetes existant. Dans cette configuration multi-organisation par cluster, les deux organisations utilisent et partagent le même anneau Cassandra. Vous pouvez configurer plusieurs environnements et groupes d'environnement pour chaque organisation.

Limites

Une configuration multi-organisation par cluster est compatible avec les limitations suivantes. Tant que ces limitations ne sont pas corrigées, nous vous déconseillons d'utiliser cette configuration.

Si vous prévoyez de disposer de plusieurs instances Apigee hybrid, chaque instance doit avoir son propre cluster. Le fait d'exécuter plusieurs instances Apigee hybrid sur un même cluster Kubernetes peut entraîner des problèmes d'instabilité, ce qui peut entraîner des temps d'arrêt.
Les métriques des pods ne sont envoyées qu'au premier projet Google Cloud configuré. Cette limitation est plus évidente dans l'outil Cloud Monitoring. Elle ne concerne que les métriques de cluster. Les analyses d'API ne sont pas affectées. Les métriques des autres organisations Apigee ne seront pas envoyées au projet Google Cloud correspondant.
Toutes les journalisations des pods sont envoyées au premier projet Google Cloud configuré. Cette limitation est plus évidente dans l'outil Cloud Logging. Les métriques des autres organisations Apigee ne seront pas envoyées au projet Google Cloud correspondant. Les journaux sont toujours capturés au niveau du pod et peuvent être récupérés à l'aide des commandes kubectl. Ils ne sont toutefois pas envoyés au bon projet Cloud via Cloud Logging.
Vous ne pouvez pas supprimer les données d'organisation d'une seule organisation dans la base de données Cassandra. Cela signifie que vous ne pouvez pas supprimer les organisations de manière sélective. Toute modification de la configuration de la base de données affecte toutes les organisations déployées sur ce cluster.
La procédure de mise à niveau hybride met à niveau l'intégralité du cluster en une seule fois.
La sauvegarde et la restauration sont effectuées en tant que cluster et ne peuvent pas être effectuées pour une organisation spécifique.
La fonctionnalité Apigee API Monitoring (Chronologie, Récente, Examen) ne fonctionne que pour la première organisation configurée et déployée. Elle ne fonctionnera pas pour les autres organisations d'un cluster multi-organisation.

Options multi-organisation

Cette section décrit comment l'assistance Apigee gère les clusters multi-organisations existants et fournit des recommandations pour les déploiements ultérieurs :

Si vous avez déployé des clusters Kubernetes multi-organisations dans des contextes hors production et de production, l'assistance Apigee continuera à les prendre en charge. Notez toutefois les limites techniques décrites dans la section suivante. Nous vous recommandons de modifier vos déploiements de production futurs pour utiliser une organisation Apigee par cluster.
Si vous possédez des clusters multi-organisation existants dans des contextes hors production, l'assistance Apigee continuera à les prendre en charge. Nous vous recommandons de migrer tous les clusters de production vers une nouvelle configuration utilisant une organisation Apigee par cluster.

Prérequis

Avant de continuer, tenez compte des points suivants :

Vous devez disposer d'une organisation hybride existante avec un ou plusieurs environnements installés et configurés dans un cluster Kubernetes existant. Consultez les instructions d'installation de la solution hybride.
Lorsque vous combinez plusieurs organisations dans un seul cluster, les versions hybrides doivent toutes correspondre. Avant d'ajouter une deuxième organisation à un cluster, mettez à niveau l'installation hybride existante, si nécessaire. Consultez la page Mettre à niveau Apigee hybrid.

Créer une organisation à ajouter au cluster existant

Pour créer l'organisation supplémentaire, suivez les étapes décrites dans la section Partie 1 : Configuration du projet et de l'organisation.

Configurer la nouvelle organisation

Dans les étapes suivantes, vous allez créer un fichier de remplacement et le configurer pour la nouvelle organisation. Un fichier overrides.yaml n'accepte que les informations d'une organisation. Par conséquent, vous devez créer un fichier overrides.yaml et l'appliquer au cluster Kubernetes existant.

Créez des comptes de service à utiliser avec la nouvelle organisation. Consultez la section Créer des comptes de service.
Notez les fichiers de certificat TLS (.key et .pem) dans votre répertoire certs. Si vous devez les recréer, vous pouvez suivre les instructions de la section Créer des certificats TLS.
Copiez le fichier overrides.yaml existant dans un nouveau fichier à utiliser comme point de départ pour configurer votre nouvelle organisation. Par exemple : new-overrides.yaml.

Modifiez le fichier de remplacement avec les configurations suivantes :

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

Le tableau suivant décrit chacune des valeurs de propriété que vous devez fournir dans le fichier de remplacement. Pour en savoir plus, consultez la documentation de référence sur les propriétés de configuration.

Variable	Description
`new-org-name`	Nom de votre nouvelle organisation
`instance-id`	Toutes les organisations de ce cluster doivent avoir le même ID d'instance. Par conséquent, il doit correspondre à l'entrée `instanceID` du fichier de remplacement de votre organisation d'origine. Pour les installations multirégionales, chaque région nécessite son propre cluster (les clusters individuels ne couvrent pas plusieurs régions). Par conséquent, chaque cluster doit posséder son propre ID d'instance unique, partagé par chaque organisation du cluster.
`existing-cluster-name`	Nom du cluster auquel vous ajoutez cette organisation. Il doit correspondre à l'entrée `k8sCluster.name` du fichier de remplacement de votre cluster d'origine.
`existing-cluster-analytics-region`	La région dans laquelle le cluster d'origine est provisionné. Il doit correspondre à l'entrée `k8sCluster.region` du fichier de remplacement de votre cluster d'origine.
`new-project-id`	ID de votre nouveau projet L'ID du projet et le nom de l'organisation sont identiques.
`new-project-default-location`	Région d'analyse que vous avez spécifiée lors de la création de la nouvelle organisation. Cet emplacement ne doit pas nécessairement être identique à celui de l'organisation existante.
`namespace`	Toutes les organisations du cluster doivent partager le même espace de noms. Veillez à utiliser le même espace de noms que celui utilisé pour l'organisation d'origine. Notez que l'espace de noms par défaut est `apigee`.
`new-environment-group-name`	Le groupe d'environnement que vous avez créé pour la nouvelle organisation.
`cert-file-name` et `key-file-name`	Les certificats TLS et les fichiers de clé pour le cluster que vous avez vérifié ou créé à l'étape 1 dans cette section.
`new-environment-name`	Nom de l'environnement que vous avez créé pour la nouvelle organisation.
`new-service-accounts-directory`	Répertoire où se trouvent les fichiers de clés du compte de service que vous avez créés pour la nouvelle organisation.

Appliquer la configuration

Appliquez la configuration de la nouvelle organisation à votre cluster :

Procédez à une installation de simulation pour détecter les problèmes éventuels :
```
apigeectl apply -f overrides/new-overrides.yaml --org --dry-run=client
```
Remarque : Il est recommandé d'effectuer un dry run (test à blanc) avant d'appliquer la configuration afin de déterminer si des problèmes surviennent.
Si aucun problème ne se produit, appliquez les composants au niveau de l'organisation. Cette étape installe les tâches Cassandra (utilisateur et schéma), Apigee Connect, Apigee Watcher et les services MART :
```
apigeectl apply -f overrides/new-overrides.yaml --org
```
Installez l'environnement. Cette étape installe les composants apigee-runtime, synchronisateur et UDCA, par environnement :
```
apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME} --dry-run=client
```
```
apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME}
```
Remarque : Si votre nouvelle organisation comporte plusieurs environnements, répétez cette étape pour chaque environnement.
Appliquez les modifications de l'équilibreur de charge. Cette étape configure l'entrée pour écouter les nouveaux hôtes virtuels pour la deuxième organisation :
Important : Ne dupliquez pas les noms d'hôte/noms de domaine entre deux organisations car cela peut entraîner un routage imprévisible.
```
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts --dry-run=client
```
```
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts
```
Activez l'accès au synchronisateur pour votre nouvelle organisation en suivant les étapes décrites dans la section Activer l'accès au synchronisateur.