5.2. 更新ストラテジーの設定
Keycloak CR YAML 定義の spec セクション内で更新ストラテジーを指定します。
| 値 | ダウンタイム? | 説明 |
|---|---|---|
|
| イメージ名またはタグの変更時 | Red Hat build of Keycloak 26.1 以前の動作を模倣します。イメージフィールドが変更されると、Operator は新しいイメージを適用する前に StatefulSet をスケールダウンします。 |
|
| 互換性のない変更時 | Red Hat build of Keycloak Operator は、ローリング更新または再作成更新が可能かどうかを検出します。 現在のバージョンでは、古いイメージと新しいイメージの Red Hat build of Keycloak バージョンが同じである場合、Red Hat build of Keycloak はローリング更新を実行します。Red Hat build of Keycloak の今後のバージョンでは、その動作が変更され、設定、イメージ、バージョンからの追加情報を使用して、ローリング更新でダウンタイムを削減可能かどうかが判断されます。 |
|
|
|
Red Hat build of Keycloak Operator は、 |
5.2.1. Auto および Explicit 更新ストラテジーの理解 リンクのコピーリンクがクリップボードにコピーされました!
Auto 更新ストラテジーを使用する場合、Red Hat build of Keycloak Operator は、ローリングアップグレードが可能かどうかを評価するジョブを自動的に開始します。このプロセスの詳細は ローリング更新が可能かどうかを確認する の章を参照してください。このプロセスはチェック時にクラスターリソースを消費し、StatefulSet の更新が開始されるまでにわずかな遅延が発生します。
Keycloak CR の unsupported 設定パラメーターとして podTemplate が設定されている場合、Keycloak Operator は可能な限りその設定を起動したジョブに使用します。ただし、podTemplate 機能が柔軟である点、サポート対象外であることから、一部の設定が失われる可能性があります。
その結果、podTemplate への変更や、podTemplate 内のシークレット、ConfigMaps、または Volumes から取得された情報からのローリング更新が可能な場合、Operator は誤った結論を導き出す可能性があります。
したがって、サポートされていない podTemplate を使用している場合は、他の更新ストラテジーのいずれかを使用する必要がある場合があります。
Explicit 更新ストラテジーは、更新の決定をユーザーに委任します。revision フィールドは、ユーザーが制御するトリガーとして機能します。Red Hat build of Keycloak Operator は revision 値自体を解釈しませんが、revision が変更されていなくても、カスタムリソース (CR) に変更があると、ローリングアップグレードがトリガーされます。
自動 Operator アップグレードでこれを使用する場合は注意してください。Operator Lifecycle Manager (OLM) は、Red Hat build of Keycloak Operator をアップグレードすることがあります。Explicit 更新ストラテジーが使用されている場合、実際にはサポートされていないローリング更新を Operator が試行するため、予期しない動作やデプロイメントの失敗が発生する可能性があります。Explicit 更新ストラテジーを使用している場合は、アップグレードする前に非実稼働環境で十分にテストすることを強く推奨します。
5.2.2. CR ステータス リンクのコピーリンクがクリップボードにコピーされました!
RecreateUpdateUsed の Keycloak CR ステータスは、最後の更新操作中に使用された更新ストラテジーを示します。lastTransitionTime フィールドは、最後の更新がいつ発生したかを示します。この情報を使用して、Operator によるアクションと決定を確認します。
| ステータス | 説明 |
|---|---|
|
| 初期状態。更新が行われていないことを意味します。 |
|
| Operator は前回の更新でローリング更新ストラテジーを適用しました。 |
|
|
Operator は、最後の更新で再作成更新ストラテジーを適用しました。 |