クラスタへの複数のハイブリッド組織の追加

このトピックでは、既存の Kubernetes クラスタに 2 つ目の Apigee ハイブリッド組織を追加する方法について説明します。この複数組織の構成では、両方の組織が同じ Cassandra リングを使用し、共有します。それぞれの組織に複数の環境と環境グループを構成できます。

制限事項

クラスタごとの複数組織構成は、次の制限付きでサポートされています。こうした制限が軽減されるまで、この構成を使用することはおすすめしません。

複数の Apigee ハイブリッドインスタンスがある場合は、各インスタンスに独自のクラスタが必要です。同じ Kubernetes クラスタ上で複数の Apigee ハイブリッドインスタンスを実行すると、不安定性の問題につながり、ダウンタイムが発生する可能性があります。
Pod からのすべてのロギングは、最初に構成された Google Cloud プロジェクトに送信されます。この制限は Cloud Logging ツールで特に顕著です。他の Apigee 組織のログは、一致する Google Cloud プロジェクトには送信されません。ログは依然として Pod レベルでキャプチャされ、kubectl コマンドで取得できます。ただし、Cloud Logging を通じて正しい Cloud プロジェクトに送信されることはありません。
Cassandra データベースの 1 つの組織だけの組織データを削除することはできません。つまり、組織を選択的に削除できません。データベース構成を変更すると、そのクラスタにデプロイされているすべての組織に影響します。
ハイブリッドアップグレードの手順では、クラスタ全体が一度にアップグレードされます。
バックアップと復元はクラスタとして行われ、特定の組織に対して行うことはできません。
Apigee API Monitoring 機能（タイムライン、履歴、調査）は、最初に構成およびデプロイされた組織でのみ機能します。複数組織のクラスタ内の他の組織に対しては機能しません。

複数組織のオプション

このセクションでは、Apigee サポートが既存の複数の組織クラスタを処理する方法と、今後のデプロイに関する推奨事項について説明します。

非本番環境と本番環境のコンテキストに既存の複数組織の Kubernetes クラスタがデプロイされている場合、Apigee サポートは引き続きそれらをサポートします。ただし、次のセクションで概説している技術的制限に留意してください。今後、本番環境のデプロイを変更する場合は、クラスタごとに 1 つの Apigee 組織を使用することをおすすめします。
非本番環境のコンテキストで既存の複数組織クラスタがある場合、Apigee サポートは引き続きそれらをサポートします。本番環境クラスタについては、クラスタごとに 1 つの Apigee 組織を使用する新しい構成に移行することをおすすめします。

前提条件

続行する前に、次の点に注意してください。

既存の Kubernetes クラスタに 1 つ以上の環境がインストールおよび構成されている既存のハイブリッド組織が必要です。ハイブリッドインストール手順をご覧ください。
単一のクラスタで複数の組織を組み合わせる場合は、ハイブリッドバージョンがすべて一致する必要があります。2 番目の組織をクラスタに追加する前に、必要に応じて既存のハイブリッドインストールをアップグレードします。Apigee ハイブリッドのアップグレードをご覧ください。

既存のクラスタに追加する組織を作成する

追加の組織を作成するには、パート 1: プロジェクトと組織の設定の手順に沿って操作します。

新しい組織を構成する

次の手順では、新しいオーバーライドファイルを作成し、新しい組織用に構成します。overrides.yaml ファイルでサポートできる組織の情報は 1 つのみです。したがって、新しい overrides.yaml ファイルを作成して、既存の Kubernetes クラスタに適用する必要があります。

新しい組織で使用するサービスアカウントを作成します。サービスアカウントを作成するをご覧ください。
certs ディレクトリにある TLS 証明書ファイル（.key と .pem）をメモします。証明書を再度作成する必要がある場合は、TLS 証明書の作成の手順に沿って行ってください。
既存の overrides.yaml を新しいファイルにコピーし、新しい組織を構成するときの起点として使用します。たとえば、new-overrides.yaml のようになります。

次の構成で新しいオーバーライドファイルを編集します。

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

次の表に、オーバーライドファイルで指定する必要があるプロパティ値を示します。詳細については、構成プロパティのリファレンスをご覧ください。

変数	説明
`new-org-name`	新しい組織の名前。
`instance-id`	このクラスタ内のすべての組織は、同じインスタンス ID を持つ必要があります。したがって、これは元の組織のオーバーライドファイルの `instanceID` エントリと一致する必要があります。マルチリージョンインストールの場合、各リージョンに独自のクラスタが必要です（個々のクラスタはリージョンにまたがりません）。したがって、各クラスタには、クラスタ内の各組織で共有される独自の一意のインスタンス ID が必要です。
`existing-cluster-name`	この組織を追加するクラスタの名前。元のクラスタのオーバーライドファイルの `k8sCluster.name` エントリと一致している必要があります。
`existing-cluster-analytics-region`	元のクラスタがプロビジョニングされるリージョン。元のクラスタのオーバーライドファイルの `k8sCluster.region` エントリと一致している必要があります。
`new-project-id`	新しいプロジェクトのプロジェクト ID。プロジェクト ID と組織名は同じです。
`new-project-default-location`	新しい組織の作成時に指定した分析リージョン。既存の組織のリージョンと同じにする必要はありません。
`namespace`	クラスタ内のすべての組織は、同じ Namespace を共有する必要があります。元の組織で使用されていた Namespace と同じものを使用してください。ほとんどのインストールの Namespace は `apigee` です。
`new-environment-group-name`	新しい組織用に作成した新しい環境グループ。注意: 新しい組織の環境グループ名は、他の組織の環境グループ名と同じにしないでください。環境の Helm リリース名が同じになり、チャートの管理が難しくなります。
`cert-file-name` と `key-file-name`	このセクションのステップ 1 で確認または作成したクラスタの TLS 証明書と鍵ファイル。
`new-environment-name`	新しい組織用に作成した環境の名前。注意: 新しい組織の環境名は、他の組織の環境名と同じにしないでください。
`new-service-accounts-directory`	新しい組織用に作成したサービスアカウントキーファイルが存在するディレクトリ。

構成を適用する

新しい組織構成をクラスタに適用します。

ドライランインストールを実行して、問題がないか確認します。
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f OVERRIDES_FILE.yaml \
  --dry-run
```
注: 構成を適用する前にドライランを行って、問題がないか確認することをおすすめします。
問題がない場合は、組織レベルのコンポーネントを適用します。このステップでは、Cassandra ジョブ（ユーザーとスキーマ）、Apigee Connect、Apigee Watcher、MART サービスをインストールします。
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml
```
環境をインストールします。このステップでは、環境ごとに apigee-runtime、synchronizer、UDCA のコンポーネントをインストールします。
```
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
```
注: 新しい組織に複数の環境がある場合は、環境ごとにこのステップを繰り返します。
ロードバランサの変更を適用します。このステップでは、2 番目の組織の新しい仮想ホストをリッスンするように Ingress を構成します。
重要: 2 つの組織間でホスト名またはドメイン名を重複させないでください。ルーティングが予測不能になる可能性があります。
```
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
```
Synchronizer アクセスを有効にするの手順に沿って、新しい組織の Synchronizer アクセスを有効にします。
デフォルトでは、Apigee ハイブリッドランタイムを初めてインストールするときに、テレメトリーコンポーネントが multiOrgCluster を無効にして構成されます。次のステップを用いて、クラスタ内の組織ごとに複数組織のテレメトリーを有効にします。
1. 次のコマンドで、既存のテレメトリーコンポーネントを削除します。
```
helm delete telemetry
```
  注: テレメトリーコンポーネントを削除すると、Google Monitoring への指標のエクスポートが停止します。次の手順で指標を再度有効にします。
2. 既存の組織の overrides.yaml ファイルに次の行を追加します。
```
multiOrgCluster: true
```
3. 変更を適用して、組織のテレメトリーコンポーネントをインストールします。
  最初にドライランを実行します。
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f FIRST_OVERRIDES_FILE.yaml \
  --dry-run
```
  ドライランが成功したら、変更を適用してテレメトリーコンポーネントをインストールします。
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f FIRST_OVERRIDES_FILE.yaml
```
4. それぞれの新しい組織の overrides.yaml ファイルに次の行が含まれていることを確認します。
```
multiOrgCluster: true
```
5. 変更を適用して、新しい組織ごとにテレメトリーコンポーネントをインストールします。複数組織のクラスタ内の新しい組織のすべてに、これを繰り返します。
  最初にドライランを実行します。
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml \
  --dry-run
```
  ドライランが成功したら、変更を適用してテレメトリーコンポーネントをインストールします。
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml
```