3.3.3. ブローカーデプロイメントの実行へのカスタムリソース変更の適用
以下は、ブローカーデプロイメントの実行にカスタムリソース (CR) 変更の適用について留意すべき重要な事項です。
-
CR の
persistenceEnabled属性を動的に更新することはできません。この属性を変更するには、クラスターをゼロにスケールダウンします。既存の CR を削除します。次に、変更で CR を再作成し、再デプロイします。また、デプロイメントサイズも指定します。 -
CR の
deploymentPlan.size属性の値は、oc scaleコマンドによるブローカーデプロイメントのサイズの変更を上書きします。たとえば、oc scaleを使用してデプロイメントのサイズを3つのブローカーから 2 つ変更する場合、CR のdeploymentPlan.sizeの値は 3 つになります。この場合、OpenShift はまずデプロイメントを 2 つのブローカーにスケールダウンします。ただし、縮小操作が完了すると、Operator は CR で指定される 3 つのブローカーにデプロイメントを復元します。 -
「CLI を使用した Operator のデプロイ」 で説明されているように、永続ストレージ (CR に
persistenceEnabled=true) でブローカーデプロイメントを作成する場合、ブローカー Pod について AMQ Broker Operator が要求する永続ボリューム (PV) をプロビジョニングする必要がある場合があります。ブローカーデプロイメントのサイズを縮小する場合、Operator はシャットダウンされるブローカー Pod で以前に要求された PV を解放します。ただし、CR を削除してブローカーデプロイメントを削除する場合、AMQ Broker Operator は削除時にデプロイメントにあるブローカー Pod の Persistent Volume Claim (永続ボリューム要求、PVC) を解放しません。また、これらのリリースされていない PV はいずれの新規デプロイメントでも利用できません。この場合は、ボリュームを手動で解放する必要があります。詳細は、OpenShift ドキュメントの ボリュームの解放 を参照してください。 AMQ Broker 7.7 では、以下の項目を設定する必要がある場合、最初に CR をデプロイする前に、メインの CR インスタンスに適切な設定を追加する必要があります。
- アクティブなスケーリングイベント時に、さらに適用する変更は Operator によってキューに入れられ、スケーリングが完了した場合にのみ実行されます。たとえば、デプロイメントのサイズを 4 つのブローカーから 1 つにスケールダウンするとします。次に、縮小が行われる間、ブローカー管理者のユーザー名およびパスワードの値も変更します。この場合、Operator は 1 つのアクティブなブローカーでデプロイメントが実行されるまで、ユーザー名とパスワードの変更をキューに入れます。
-
すべての CR の変更: デプロイメントのサイズを変更したり、アクセプター、コネクター、またはコンソールの
expose属性の値を変更することとは別に、既存のブローカーが再起動されます。デプロイメントに複数のブローカーがある場合は、1 度に 1 つのブローカーのみを再起動します。
