サポートされるプロジェクト (名前空間) 構成

クラスター上に作成する必要があるプロジェクト (名前空間) は、いくつかの要因によって異なります。 以下の情報を確認して、作成する必要があるプロジェクトを判別します。

ヒント: cpd-cliは、プロジェクトを自動的に作成できます。 ただし、これらのプロジェクトを手動で作成する場合は、インストールおよびアップグレードの資料に、OpenShift® CLI からのプロジェクトの作成に関するガイダンスが記載されています。

共有クラスター・コンポーネントのプロジェクト

共有クラスター・コンポーネントは、クラスター上に 1 回のみインストールされ、クラスター上の IBM® Software Hub のすべてのインスタンスによって共有されます。 各コンポーネントは独自のプロジェクトにインストールされ、そのプロジェクトに他のソフトウェアをインストールしてはなりません。

以下の表に、デフォルトのプロジェクト名と、資料全体でコマンドでプロジェクトを識別するために使用される環境変数を示します。 デフォルトのプロジェクト名を使用する必要はありません。 デフォルト名は、コンポーネントのインストール時にプロジェクト名を指定しなかった場合にのみ使用されます。

コンポーネント デフォルトのプロジェクト名 環境変数
IBM Certificate manager ibm-cert-manager ${PROJECT_CERT_MANAGER}
License Service ibm-licensing ${PROJECT_CS_CONTROL}
Scheduling service No default. ${PROJECT_SCHEDULING_SERVICE}

これらのコンポーネントについて詳しくは、共有コンポーネントを参照してください。

IBM Software Hub のインスタンスをインストールするために必要なプロジェクト

IBM Software Hubのインスタンスには、少なくとも 2 つのプロジェクト (名前空間) があります。オペレーター・プロジェクトとオペランド・プロジェクトです。

オペレーター・プロジェクトおよびオペランド・プロジェクトには、指定されたソフトウェアのみをインストールする必要があります。 プロジェクトにはデフォルト名はありません。

オペレーター・プロジェクト
オペレーターがインストールされているプロジェクト。

インストールおよび管理コマンドでは、${PROJECT_CPD_INST_OPERATORS} 環境変数はオペレーター・プロジェクトを参照します。

オペレーターとは何か

  • オペレーター は、カスタム・Kubernetes・コントローラーです。 controller は、クラスター上の特定のオブジェクトの状態を継続的に監視し、必要に応じて調整を行って、オブジェクトが期待どおりに実行されるようにする制御ループを実装します。

  • IBM Software Hub の各コンポーネントには、そのコンポーネントの管理を担当するオペレーターが含まれています。 例えば、control planeには専用のオペレーターがあり、各サービスには専用のオペレーターがあります。

  • IBM Software Hubの各インスタンスには、独自のオペレーター・セットがあります。 このプロジェクト内のすべてのオペレーターは、同じリリースでインストールする必要があります。 例えば、すべてのオペレーターがバージョン 5.3.1 でインストールされている必要があります。

オペランド・プロジェクトにインストールする予定のサービスのオペレーターをインストールします。 各オペレーターは、オペランド・プロジェクト内の該当するオペランドをモニターします。

オペランド・プロジェクト
IBM Software Hub control planeおよびサービスがインストールされているプロジェクト。

インストールおよび管理コマンドでは、${PROJECT_CPD_INST_OPERANDS} 環境変数はオペランド・プロジェクトを参照します。

オペレーターは、オペランドが予期したとおりに実行されていることを確認するために、オペランドをモニターします。

IBM Software Hubの各インスタンスには、独自のオペランドのセットがあります。 このプロジェクトのオペランドは、operators プロジェクトのオペレーターと同じリリースでインストールする必要があります。

IBM Software Hub のインスタンスのオプション・プロジェクト

オプションで、1 つ以上のプロジェクトをオペランド・プロジェクトに連結することができます。

連結プロジェクトには、指定されたソフトウェアのみをインストールする必要があります。 プロジェクトにはデフォルト名はありません。

連結プロジェクト
ワークロードまたはサービス・インスタンスをデプロイできるプロジェクト。
制約事項: すべてのサービスが、連結プロジェクトでのワークロードまたはサービス・インスタンスの実行をサポートしているわけではありません。 詳しくは、『マルチテナンシー・サポート』』を参照してください。
連結プロジェクトは、以下の環境変数によって識別されます。
  • インストールおよび管理コマンドでは、${PROJECT_CPD_INSTANCE_TETHERED}は、IBM Software Hubのインスタンスに関連付けられた単一の連結プロジェクトを指します。
  • インストールおよび管理コマンドでは、${PROJECT_CPD_INSTANCE_TETHERED_LIST} 環境変数は、IBM Software Hub のインスタンスに関連付けられた連結プロジェクトのリストを参照します。

IBM Software Hub control planeは、連結プロジェクト内のソフトウェアを管理します。 ただし、ソフトウェアは、control planeや、オペランド・プロジェクトで実行されている他のサービスやワークロードからは分離されています。

プロジェクトをオペランド・プロジェクトに連結すると、cpd-cli manage setup-tethered-ns コマンドは以下のようになります。
  • オペレーター・プロジェクト内の IBM NamespaceScope Operator を更新して、オペレーターが連結プロジェクトを監視できるようにします。
  • ZenService カスタム・リソースをオペランド・プロジェクトで更新して、tetheredNamespaces エントリーに連結プロジェクトを追加します。

    これにより、IBM Software Hub control planeは、連結プロジェクト内のワークロードをモニターおよび管理できます。

以下の状況では、ワークロードまたはサービス・インスタンスを連結プロジェクトにデプロイすることをお勧めします。
  • 特定のサービス・インスタンスにアクセスする必要があるカスタム・アプリケーションを実行していますが、セキュリティー上の理由から、IBM Software Hubで実行されている他のサービスにアプリケーションがアクセスしないようにしたい場合があります。
  • 特定のコンピュート・リソースまたは特定のサービス品質を必要とするワークロードを実行している。

多くのサービスは、特定のプロジェクト内で 1 つのサービス・インスタンスのみをサポートします。 したがって、サービスの複数インスタンスを作成する場合は、サービスの各インスタンスを別々のプロジェクトにデプロイする必要があります。 これは、複数の連結プロジェクトを作成し、各連結プロジェクトにサービスの 1 つのインスタンスを作成することによって実現できます。

同じ連結プロジェクト内の異なるサービスのサービス・インスタンスとワークロードを連結することができます。あるいは、1 つのサービスまたはワークロードがより多くの特権を必要とする場合は、異なる連結プロジェクトを作成することができます。 さまざまな連結プロジェクトを使用して、各サービス・インスタンスまたはワークロードに、最小特権の原則に合わせて必要な特権を付与できます。

連結プロジェクトは、論理的にオペランド・プロジェクトから分離されているため、独自の NetworkPolicies、SecurityContext、および ResourceQuotaを持つことができます。

オペランド・プロジェクトへのプロジェクトの連結について詳しくは、プロジェクトのIBM Software Hub control planeへの連結を参照してください。

マルチテナンシーの考慮事項

IBM Software Hub の複数のインスタンスをクラスターにインストールする場合は、インストールするインスタンスごとにオペレーター・プロジェクトとオペランド・プロジェクトを作成する必要があります。 IBM Software Hubの複数のインスタンスで連結プロジェクトを共有することはできません。 連結プロジェクトを使用する場合は、それらを使用するインスタンスごとに連結プロジェクトを作成する必要があります。

サンプル・プロジェクト構成

以下の図は、サンプル・プロジェクト構成を示しています。 これらの図は、同じクラスター上に IBM Software Hub の複数インスタンスがある環境を示しています。

図1： 共有クラスター・コンポーネントとクラスター上の IBM Software Hub のインスタンスとの間の相互作用の概要
IBM Software Hubのインスタンス数が指定されていない場合のサンプル構成。
上の図は、共有クラスター・コンポーネントがクラスター上の IBM Software Hub の各インスタンスとどのように対話するかを示しています。
  • IBM Certificate managerは、各インスタンスのIBM Software Hub control planeおよびサービスが、マイクロサービス間のセキュアな通信のためにTLS証明書を生成し、自動的にローテーションできるようにします。
  • License Serviceは、IBM Software Hubの各インスタンスを監視して、VPC の使用状況を追跡します。 このデータにより、使用状況の監査スナップショットを生成できます。
  • scheduling serviceは、IBM Software Hubの各インスタンスを監視して、以下のことを行います。
    • IBM Software Hub control plane およびサービスによって開始されるポッドをスケジュールします。
    • 特定のスケジューリング・ポリシーを適用します。
    • 割り当て量を強制します。
図2： IBM Software Hub のさまざまなインスタンスに関連付けられたプロジェクトの詳細ビュー
IBM Software Hubの 2 つのインスタンスを持つサンプル構成。

上の図は、IBM Software Hubの 2 つのインスタンスを持つクラスターを示しています。

IBM Software Hubの各インスタンスには、独自のオペレーター・プロジェクトと独自のオペランド・プロジェクトがあります。 この例では、各インスタンスに少なくとも 1 つの連結プロジェクトがあります。 ただし、連結プロジェクトはオプションです。

ベスト・プラクティス: マルチテナント環境でプロジェクトを管理するためのグループの作成

IBM Software Hubの複数インスタンスをデプロイし、連結プロジェクトを使用する場合は、グループを使用して、IBM Software Hubの特定のインスタンスに関連付けられたプロジェクトを識別する必要があります。

以下の例では、IBM Software Hubのデプロイメントが 2 つあります。
  • IBM Software Hubの 1 つのインスタンスが、dev という名前のプロジェクトにデプロイされます。

    以下のプロジェクトは、dev プロジェクトに連結されています。

    • apps-dev
    • db-dev
  • IBM Software Hubの 1 つのインスタンスが、prod という名前のプロジェクトにデプロイされます。

    以下のプロジェクトは、prod プロジェクトに連結されています。

    • apps-prod
    • db-prod

ラベルを使用して、プロジェクトをグループ化できます。

  • dev デプロイメントに関連付けられているプロジェクトに cpdgroup=devのラベルを付けるには、以下のコマンドを実行します。
    oc label namespace dev apps-dev db-dev cpdgroup=dev
  • prod デプロイメントに関連付けられたプロジェクトを cpdgroup=prodにグループ化するには、以下のコマンドを実行します。
    oc label namespace prod apps-prod db-prod cpdgroup=prod
関連コマンド:
  • ラベルがプロジェクトに適用されたことを確認するには、oc describe コマンドを使用します。 例えば、db-dev プロジェクトに適用されたラベルを検証するには、以下を実行します。
    oc describe namespace db-dev
  • 必要に応じて、グループからプロジェクトを削除できます。 例えば、dv-dev・プロジェクトをdev・グループから削除するには、次のようにします。
    oc label namespace db-dev cpdgroup-