第1章 Workload Availability for Red Hat OpenShift 25.9 リリースノート

場合によっては、古いワークロードが正常なノード上に残り、そのワークロードがサービス停止中の taint によって削除されないことがあります。これは正常なノードの使用に影響します。有効期限メカニズムが、サービス停止中の taint に追加されました。ワークロードが終了に失敗した場合でも、有効期限メカニズムによってサービス停止の taint がクリーンアップされます。

場合によっては、SNR マネージャーが正常でないノードに配置され、SNR マネージャーが退避させられることがあります。SNR マネージャーは正常なノードに再スケジュールされ、修復 CR の処理が遅延されます。デプロイメントには、maxSkew: 1, topologyKey: kubernetes.io/hostname, whenUnsatisfiable: DoNotSchedule の設定を持つ topologySpreadConstraints が含まれているため、SNR マネージャーは 2 つのレプリカで実行されますが、これらは同じノード上に配置されません。ノードの障害により SNR マネージャーが退避させられた場合、正常なノード上の別の SNR マネージャーが制御を引き継ぎ、CR を処理して、SNR 処理の遅延を削減できます。

ハードコードされた apiServerTimeout の 3 秒は、デフォルトで 5 秒に設定されている PeerTimeout よりも短くなる可能性があります。その結果、ピア間の競合状態が始まり、API サーバーの過負荷によりピアの応答が遅くなっただけで、1 つのノードが修復を早期に開始する可能性があります (ネットワークまたはピアの障害を想定)。設定された PeerTimeout が apiServerTimeout と MinimumBuffer の合計より小さい場合、Operator はピアチェックに内部的に apiServerTimeout と MinimumBuffer を使用します。アドミッション Webhook は、警告を発行し、ピア間の競合状態を回避するためにも使用されます。

SNR では、修復が行われる前に少なくとも 1 つの他のピアワーカーノードが必要です。単一ワーカーノードクラスターのセットアップでは、修復を開始できません。単一ワーカーノードクラスターのセットアップをサポートするために、最小ワーカーノード数を設定できるようになりました。SNR は、単一ワーカーノードクラスターセットアップ上の単一ワーカーノードを自己修復できます。

以前は、pendingPods ステータスフィールドは保留中の Pod のリストを追跡していましたが、Pod の名前のみで追跡されていたため、Pod の識別が困難でした。新しい pendingPodsRefs ステータスフィールドは、namespace と Pod の名前の両方で保留中の Pod を追跡し、Pod の識別を容易にします。