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

このトピックでは、既存の 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 クラスタに適用する必要があります。

  1. 新しい組織で使用するサービス アカウントを作成します。サービス アカウントを作成するをご覧ください。
  2. certs ディレクトリにある TLS 証明書ファイル（.key と .pem）をメモします。証明書を再度作成する必要がある場合は、TLS 証明書の作成の手順に沿って行ってください。
  3. 既存の overrides.yaml を新しいファイルにコピーし、新しい組織を構成するときの起点として使用します。例: new-overrides.yaml
  4. 次の構成で新しいオーバーライド ファイルを編集します。
    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 エントリと一致する必要があります。
    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 新しい組織用に作成した新しい環境グループ。
    cert-file-name と
    key-file-name    		 このセクションのステップ 1 で確認または作成したクラスタの TLS 証明書と鍵ファイル。
    new-environment-name 新しい組織用に作成した環境の名前。
    new-service-accounts-directory 新しい組織用に作成したサービス アカウント キー ファイルが存在するディレクトリ。

構成を適用する

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

  1. ドライラン インストールを実行して、問題がないか確認します。
    helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f OVERRIDES_FILE.yaml \
  --dry-run=server
  2. 問題がない場合は、組織レベルのコンポーネントを適用します。このステップでは、Cassandra ジョブ（ユーザーとスキーマ）、Apigee Connect、Apigee Watcher、MART サービスをインストールします。
    helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml
  3. 環境をインストールします。このステップでは、環境ごとに apigee-runtime、synchronizer、UDCA のコンポーネントをインストールします。
    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
  4. ロードバランサの変更を適用します。このステップでは、2 番目の組織の新しい仮想ホストをリッスンするように Ingress を構成します。 
    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
  5. Synchronizer アクセスを有効にするの手順に沿って、新しい組織の Synchronizer アクセスを有効にします。
  6. デフォルトでは、Apigee ハイブリッド ランタイムを初めてインストールするときに、テレメトリー コンポーネントが multiOrgCluster を無効にして構成されます。次のステップを用いて、クラスタ内の組織ごとに複数組織のテレメトリーを有効にします。
    1. 次のコマンドで、既存のテレメトリー コンポーネントを削除します。
      helm delete telemetry
    2. 既存の組織の overrides.yaml ファイルに次の行を追加します。
      multiOrgCluster: true
    3. 変更を適用して、組織の Telemetry コンポーネントをインストールします。

      最初にドライランを実行します。

      helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f FIRST_OVERRIDES_FILE.yaml \
  --dry-run=server

      ドライランが成功したら、変更を適用してテレメトリー コンポーネントをインストールします。

      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=server

      ドライランが成功したら、変更を適用してテレメトリー コンポーネントをインストールします。

      helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml