2.5. Operator デプロイメントノート
このセクションでは、Operator ベースのデプロイメントを計画する際の重要な考慮事項について説明します。
- AMQ Broker Operator に付随するカスタムリソース定義 (CRD) をデプロイするには、OpenShift クラスターのクラスター管理者権限が必要です。Operator がデプロイされると、管理者以外のユーザーは対応するカスタムリソース (CR) を使用してブローカーインスタンスを作成できます。通常のユーザーが CR をデプロイできるようにするには、クラスター管理者は、まず、ロールと権限を CRD に割り当てる必要があります。詳細は、OpenShift Container Platform ドキュメントの カスタムリソース定義のクラスターロールの作成 を参照してください。
- 最新の Operator バージョンの CRD を使用してクラスターを更新する場合、今回の更新はクラスターのすべてのプロジェクトに影響を与えます。以前のバージョンの Operator からデプロイされたブローカー Pod は、それらのステータスを更新できなくなる可能性があります。OpenShift Container Platform Web コンソールで実行中のブローカー Pod の Logs タブをクリックすると、UpdatePodStatus が失敗したことを示すメッセージが表示されます。ただし、そのプロジェクトのブローカー Pod および Operator は予想通りに機能し続けます。影響を受けるプロジェクトに対してこの問題を解決するには、Operator の最新バージョンを使用するようプロジェクトをアップグレードする必要もあります。
複数のカスタムリソース (CR) インスタンスをデプロイして、特定の OpenShift プロジェクトに複数のブローカーデプロイメントを作成できますが、通常、プロジェクトに単一のブローカーデプロイメントを作成してから、アドレスに複数の CR インスタンスをデプロイします。
Red Hat は、個別のプロジェクトで デプロイメントを作成することを推奨します。
永続ストレージでブローカーをデプロイし、OpenShift クラスターに Container-native ストレージがない場合、永続ボリューム (PV) を手動でプロビジョニングし、それらが Operator で要求できるようにする必要があります。たとえば、永続ストレージ (CR に
persistenceEnabled=true) を使用して 2 つのブローカーで設定されるクラスターを作成する場合は、永続ボリュームを 2 つ利用可能にしておく必要があります。デフォルトでは、各ブローカーインスタンスには 2 GiB のストレージが必要です。CR に
persistenceEnabled=falseを指定した場合、デプロイされたブローカーは 一時 ストレージを使用します。一時ストレージは、ブローカー Pod を再起動するたびに、既存のデータが失われることを意味します。OpenShift Container Platform での永続ストレージのプロビジョニングについての詳細は、以下を参照してください。
CR を初めてデプロイする前に、リスト表示されている項目の設定をメインブローカー CR インスタンスに追加する必要があります。これらのアイテムの設定をすでに実行中のブローカーデプロイメントに追加することはできません。
-
Operator が StatefulSet で動的に更新できない CR のパラメーターを更新すると、Operator は StatefulSet を削除し、更新されたパラメーター値でそれを再作成します。StatefulSet を削除すると、すべての Pod が削除されて再作成されるため、ブローカーが一時的に停止します。Operator が StatefulSet で動的に更新できない CR 更新の例は、
persistenceEnabled=falseをpersistenceEnabled=trueに変更した場合です。
