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

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

複数組織のオプション

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

  • 非本番環境と本番環境のコンテキストに既存の複数組織の Kubernetes クラスタがデプロイされている場合、Apigee サポートは引き続きそれらをサポートします。ただし、次のセクションで概説している技術的制限に留意してください。今後、本番環境のデプロイを変更する場合は、クラスタごとに 1 つの Apigee 組織を使用することをおすすめします。
  • 非本番環境のコンテキストで既存の複数組織クラスタがある場合、Apigee サポートは引き続きそれらをサポートします。本番環境クラスタについては、クラスタごとに 1 つの 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 機能(タイムライン、履歴、調査)は、最初に構成およびデプロイされた組織でのみ機能します。複数組織のクラスタ内の他の組織に対しては機能しません。

前提条件

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

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

構成を適用する

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

  1. ドライラン インストールを実行して、問題がないか確認します。
    apigeectl apply -f overrides/new-overrides.yaml --org --dry-run=client
  2. 問題がない場合は、組織レベルのコンポーネントを適用します。このステップでは、Cassandra ジョブ(ユーザーとスキーマ)、Apigee Connect、Apigee Watcher、MART サービスをインストールします。
    apigeectl apply -f overrides/new-overrides.yaml --org
  3. 環境をインストールします。このステップでは、環境ごとに 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}
  4. ロードバランサの変更を適用します。このステップでは、2 番目の組織の新しい仮想ホストをリッスンするように Ingress を構成します。
    apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts --dry-run=client
    apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts
  5. Synchronizer アクセスを有効にするの手順に沿って、新しい組織の Synchronizer アクセスを有効にします。