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

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

複数組織のオプション

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

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

制限事項

クラスタごとの複数組織設定は、次の制限付きでサポートされています。

  • Pod 指標は、最初に構成された Google Cloud プロジェクトにのみ送信されます。この制限は Cloud Monitoring ツールで特に顕著です。これはクラスタ指標にのみ影響します。API 分析に影響はありません。 他の Apigee 組織の指標は、一致する Google Cloud プロジェクトに送信されません。
  • Pod からのすべてのロギングは、最初に構成された Google Cloud プロジェクトに送信されます。この制限は Cloud Logging ツールで特に顕著です。他の Apigee 組織のログは、一致する GCP プロジェクトに送信されません。ログは Pod レベルで引き続きキャプチャされ、kubectl コマンドを使用して取得できます。ただし、Cloud Logging を介して正しい Cloud プロジェクトに送信されることはありません。
  • Cassandra データベースの 1 つの組織の組織データを削除することはできません。 つまり、組織を選択的に削除することはできません。データベースの構成を変更すると、そのクラスタにデプロイされているすべての組織に影響します。
  • ハイブリッド アップグレードの手順では、クラスタ全体が一度にアップグレードされます。
  • バックアップと復元はクラスタとして行われ、特定の組織に対して行うことはできません。
  • Apigee API Monitoring 機能(Timeline、Recent、Investigate)は、構成してデプロイした最初の組織でのみ機能します。複数組織クラスタ内の他の組織に対しては機能しません。

要件

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

  • 既存の Kubernetes クラスタで、既存の Kubernetes クラスタにインストールされ、1 つ以上の環境が構成されている必要があります。ハイブリッド インストール手順をご覧ください。
  • 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 アクセスを有効にします。