このトピックでは、既存の 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
エントリと一致する必要があります。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 を構成します。
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts --dry-run=client
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts
- Synchronizer アクセスを有効にするの手順に沿って、新しい組織の Synchronizer アクセスを有効にします。