3.4. 既知の制限

Red Hat build of Keycloak アップグレードのロールアウト中のダウンタイム

この問題は、パッチリリースの場合、ローリング更新が可能かどうかを確認 する機能を有効にすることで解消できます。

whenUnsatisfiable: ScheduleAnyway が指定されたデフォルトの topologySpreadConstraints を使用するデプロイメントでは、障害が発生したノード/ゾーンに複数の Pod がスケジュールされている場合、ノード/アベイラビリティーゾーンの障害時にデータ損失が発生する可能性があります。

ユーザーは、topologySpreadConstraints に whenUnsatisfiable: DoNotSchedule を定義して、常にゾーンおよびノード全体に Pod を均等にスケジュールさせることで、この状況を緩和できます。ただし、この制約を満たすことができない場合、一部の Red Hat build of Keycloak インスタンスがデプロイされない可能性があります。

Infinispan はキャッシュエントリーを配布するときにネットワークトポロジーを認識しません。そのため、キャッシュされたデータの num_owner 個のコピーが、すべて障害が発生したノード/ゾーンに保存されている場合、ノード/アベイラビリティーゾーンの障害時にデータ損失が発生する可能性があります。ノードおよびアベイラビリティーゾーンに対して requiredDuringSchedulingIgnoredDuringExecution を定義することで、利用可能なノードまたはゾーンの数に応じて、Red Hat build of Keycloak インスタンスの合計数を制限できます。ただし、プロビジョニングできる Red Hat build of Keycloak インスタンスの数が、{kubernetes} クラスター内のノード/アベイラビリティーゾーンの数に制限されるため、スケーラビリティーが犠牲になります。

カスタムのアンチアフィニティー topologySpreadConstraints ポリシーを設定する方法は、Operator の 高度な設定 の詳細を参照してください。