[Kubernetes]

ネイティブ HA キュー・マネージャーの独自ローリング更新を実行する場合の考慮事項

ネイティブ HA キュー・マネージャーの IBM® MQ バージョンまたはポッド仕様を更新する場合は、キュー・マネージャー・インスタンスのローリング更新を実行する必要があります。 これは IBM MQ Operator によって自動的に処理されますが、独自のデプロイメント・コードを作成する場合は、いくつかの重要な考慮事項があります。

注 Helmのサンプルには、ローリングアップデートを実行するためのシェルスクリプトが含まれていますが、このトピックで説明している考慮事項が含まれていないため、本番環境での使用には適していません。

Kubernetes では、StatefulSet リソースは、順序付けられた始動およびローリング更新を管理するために使用されます。 始動手順の一環として、各ポッドを個別に開始し、そのポッドが作動可能になるまで待ってから、次のポッドに移動します。 すべてのポッドを開始してリーダー選出を実行できるようにする必要があるため、これはネイティブ HA では機能しません。 したがって、.spec.podManagementPolicy フィールド (StatefulSet 上) を Parallel に設定する必要があります。 これはすべてのポッドが並行して更新されることも意味しますが、これは特に望ましくありません。 このため、 StatefulSet は OnDelete 更新方針も使用する必要があります。

StatefulSet ローリング更新コードを使用できないため、カスタム・ローリング更新コードが必要になります。以下の点を考慮してください。
  • 一般的なローリング更新手順
  • 最適な順序でポッドを更新することによるダウン時間の最小化
  • クラスター状態の変更を処理
  • エラーの処理
  • タイミングの問題を処理

一般的なローリング更新手順

ローリング更新コードは、各インスタンスが REPLICA の状況を dspmq から示すまで待ちます。 つまり、インスタンスは何らかのレベルの始動を行った (例えば、コンテナーが開始され、MQ プロセスが実行されている) が、必ずしもその他のインスタンスと対話するようにはなっていません。 例えば、ポッド A が再始動され、 REPLICA 状態になるとすぐにポッド B が再始動されます。 ポッド B は新しい構成で開始されると、ポッド A と対話できるようになり、クォーラムを形成できます。A または B のいずれかが新しいアクティブ・インスタンスになります。

その一環として、各ポッドが REPLICA 状態になった後に遅延を設定して、そのポッドがピアに接続してクォーラムを確立できるようにすると便利です。

最適な順序でポッドを更新することによるダウン時間の最小化

ローリング更新コードは、既知のエラー状態にあるポッドから、正常に開始されなかったポッドまで、一度に 1 つずつポッドを削除する必要があります。 通常、アクティブなキュー・マネージャー・ポッドは最後に更新する必要があります。

また、前回の更新でポッドが既知のエラー状態になった場合は、ポッドの削除を一時停止することも重要です。 これにより、すべてのポッドにわたって、中断された更新がロールアウトされなくなります。 例えば、これが行われる可能性があるのは、アクセスできない (または誤植が含まれる) 新しいコンテナー・イメージを使用するようにポッドが更新される場合です。

クラスター状態の変更を処理

ローリング更新コードは、クラスター状態のリアルタイム変更に適切に対応する必要があります。 例えば、キュー・マネージャーのポッドの 1 つが、ノード・リブートまたはノード圧力が原因で排除されることがあります。 排除されたポッドは、クラスターがビジーだと即時に再スケジュールされない可能性があります。 この場合、ローリング更新コードは、他のすべてのポッドを再始動する前に適切に待機する必要があります。

エラーの処理

ローリング更新コードは、Kubernetes API の呼び出し時や他の予期しないクラスター動作時の障害に対して堅牢でなければなりません。

さらに、ローリング更新コード自体は、再始動を許容できなければなりません。 ローリング更新は長時間実行される可能性があり、コードの再始動が必要になる可能性があります。

タイミングの問題を処理

ローリング更新コードは、ポッドが再始動したことを確認できるように、ポッドの更新改訂を検査する必要があります。 これにより、ポッドが「開始済み」であることを示していても実際はまだ終了していないというタイミングの問題が回避されます。