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

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

制限事項

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

複数の Apigee ハイブリッドインスタンスがある場合は、各インスタンスに独自のクラスタが必要です。同じ Kubernetes クラスタ上で複数の Apigee ハイブリッドインスタンスを実行すると、不安定性の問題につながり、ダウンタイムが発生する可能性があります。
Pod の指標は、構成された最初の Google Cloud プロジェクトにのみ送信されます。この制限は Cloud Monitoring ツールで特に顕著です。これはクラスタ指標にのみ影響します。API 分析に影響はありません。他の Apigee 組織の指標は、一致する Google Cloud プロジェクトに送信されません。
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.

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`	クラスタ内のすべての組織は、同じ名前空間を共有する必要があります。元の組織で使用されたものと同じ名前空間を必ず使用するようにしてください。デフォルトの名前空間は `apigee` であることに留意してください。
`new-environment-group-name`	新しい組織用に作成した新しい環境グループ。
`cert-file-name` と `key-file-name`	このセクションのステップ 1 で確認または作成したクラスタの TLS 証明書とキーファイル。
`new-environment-name`	新しい組織用に作成した環境の名前。
`new-service-accounts-directory`	新しい組織用に作成したサービスアカウントキーファイルが存在するディレクトリ。

構成を適用する

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

ドライランインストールを実行して、問題がないか確認します。
```
apigeectl apply -f overrides/new-overrides.yaml --org --dry-run=client
```
注: 構成を適用する前にドライランを実行して、問題がないか確認することをおすすめします。
問題がない場合は、組織レベルのコンポーネントを適用します。このステップでは、Cassandra ジョブ（ユーザーとスキーマ）、Apigee Connect、Apigee Watcher、MART サービスをインストールします。
```
apigeectl apply -f overrides/new-overrides.yaml --org
```
環境をインストールします。このステップでは、環境ごとに apigee-runtime、synchronizer、UDCA のコンポーネントをインストールします。
```
apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME} --dry-run=client
```
```
apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME}
```
注: 新しい組織に複数の環境がある場合は、環境ごとにこのステップを繰り返します。
ロードバランサの変更を適用します。このステップでは、2 番目の組織用の新しい仮想ホストをリッスンするように Ingress を構成します。
重要: 2 つの組織間でホスト名またはドメイン名を重複させないでください。ルーティングが予測不能になる可能性があります。
```
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts --dry-run=client
```
```
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts
```
Synchronizer アクセスを有効にするの手順に沿って、新しい組織の Synchronizer アクセスを有効にします。