Kubernetes の restartPolicyRules を安全に使用するにはどうすればよいですか？

問題と背景

Kubernetes v1.35 では、RestartAllContainers アクションが有効な場合にコンテナ向けの restartPolicyRules が導入されています。Pod にはライフサイクルと準備状態（readiness）の規約が存在する一方で、このルールにより終了コードを再起動アクションにマッピングできます。この機能は障害の分類として扱い、プローブやアラートの代替とは見なさないでください。

ワーカー Pod に障害ドメインの異なる3つのコンテナがあると仮定します。fetcher は一時的な認証情報リフレッシュの失敗から回復する可能性があります。proxy の設定エラーはオペレータにアラート通知（page）を送る必要があります。reporter はローカルステートが破損した場合に Pod 全体の再起動が必要になる可能性があります。

面接官が評価するポイント

面接官は、正確な障害分類体系、フィーチャーゲートとバージョンの前提条件に対する認識、そして再起動ループによってインシデントが隠蔽されるのを防ぐ計画を評価します。優れた回答では、終了コードをオーナーシップ、readiness、バックオフ、メトリクス、ロールアウトの安全性と結びつけて説明します。

一般的な回答では、すべてのコンテナに restartPolicyRules を追加するだけにとどまります。優れた回答では、どのコードが安定した API セマンティクスであり、どれが偶発的なプロセスの詳細であるか、そして各コンテナのステートに対して再起動が安全であることをどのように証明するかを説明します。

最初に確認すべき明確化のための質問

すべてのクラスタでどの Kubernetes バージョンとフィーチャーゲートが保証されているか？
終了コードはアプリケーションの規約によって制御されているか、それともランタイムやシェルラッパーから出力されているか？
コンテナのステートは破棄可能か、チェックポイント化されているか、それとも Pod 内の別のコンテナと結合しているか？
同じコードが繰り返された場合に何が起こるべきか：バックオフ、Pod の置換、またはエスカレーションか？
1つのコンテナが再起動している間、どのシグナルがユーザーに対する準備完了状態（readiness）を定義するか？

コードがテスト済みのアプリケーション規約の一部でない場合は、一律の再起動ポリシーを優先し、まずプロセスの規約を改善してください。ステートが結合している場合、1つのコンテナを再起動すると他のコンテナとの間でスプリットブレイン状態の相互作用が発生する可能性があります。

30秒での回答

「まず Kubernetes のバージョンとフィーチャーゲートを確認し、各コンテナの規約で終了コードのセマンティクスを定義します。一時的でステートレスな障害のみを再起動し、恒久的な設定障害は可視化させ、破損した共有ステートに対しては Pod の置換を使用します。ルールのマッチ、再起動回数、バックオフ、readiness、繰り返し発生するコードのアラートをインスツルメンテーションし、ポリシーをカナリアリリースして、エラー率や再起動ループが増加した場合はロールバックします。」

ステップごとの設計

前提条件の確認。 v1.35 の動作、RestartAllContainers、アドミッションポリシー、およびクラスタのコントローラーと可観測性スタックが新しいフィールドを認識しているかを確認します。
終了コードのオーナーシップの定義。 一時的なリフレッシュ、恒久的な設定エラー、回復不能なステートなど、文書化された小さなセットを確保します。シグナルが誤って再マッピングされないよう、ラッパーをテストします。
最小限の安全なアクションのマッピング。 一時的なコードに対してはステートレスな fetcher を再起動します。不正な設定の proxy は再起動せず、NotReady として表面化させてアラートを発報します。共有ステートが無効な場合は Pod を置換します。
依存関係の保護。 readiness を依存関係の規約に基づいて制御し、シャットダウンフックを調整して、再起動されたコンテナにウォームアップされたステートがない間はトラフィックの受け入れを避けます。
繰り返しの制御。 再起動回数、指数バックオフ、および繰り返しコードのアラートを組み合わせます。再起動を繰り返すルールは、最終的にオペレータから確認できる障害として表面化させる必要があります。
段階的なロールアウト。 1つのワークロードでカナリアリリースを行い、前回のポリシーと比較して再起動ループ率、リカバリ時間、エラー率、Pod のチャーンを検証し、ガードレールが維持されている場合にのみ適用範囲を広げます。

代替案には、1つのコンテナ内のスーパーバイザー、独立した障害ドメインのための個別の Deployment、または Pod を置換するコントローラーが含まれます。ステートを保護し、障害を可視化できる最もシンプルな境界を選択してください。

回答例

「fetcher については、終了コード 42 は一時的な認証情報リフレッシュの失敗を意味し、永続的なローカルステートを持たないため安全に再起動できます。設定エラーは NotReady のままでオーナーに通知します。再起動しても同じ失敗が繰り返されるだけだからです。reporter が破損したローカルチェックポイントを検出した場合は、クリーンなボリュームまたは置換によって一貫した回復ができるよう Pod を終了します。フィーチャーゲート配下のルールを1つのカナリアにデプロイし、繰り返しのマッチや再起動ループについてアラートを設定し、リカバリ時間やエラー率が悪化した場合はポリシーを削除します。」

よくある間違い

間違い: すべての非ゼロ終了を一時的なものとして扱う → 失敗する理由: 恒久的な障害が無音の再起動ループになる → 対策: テスト済みの終了コードセマンティクスを定義する。
間違い: フィーチャーゲートとクラスタのバージョン差異（skew）を無視する → 失敗する理由: 環境によってマニフェストの動作が異なる → 対策: アドミッションチェックとロールアウトチェックを追加する。
間違い: ステートが結合しているコンテナを1つだけ再起動する → 失敗する理由: 他のコンテナが互換性のないステートを保持し続ける → 対策: Pod を置換するか、リカバリを調整する。
間違い: コンテナの再起動のみを監視する → 失敗する理由: 再起動が正常に見えてもユーザーにはエラーが表示され続ける可能性がある → 対策: 再起動メトリクスを readiness およびサービス SLO と組み合わせる。

フォローアップの質問と回答

終了コード 42 がシェルラッパーによって出力され、イメージ更新後に変更された場合はどうしますか？

コードを API として扱います。ラッパーを固定（ピン留め）してテストし、オーナーシップを文書化し、規約が変更された場合はロールアウトを失敗させます。ランタイム固有のコードを暗黙的に引き継がないようにしてください。

再起動ループが障害を隠蔽するのを防ぐにはどうすればよいですか？

ルールの繰り返しマッチ、再起動率、バックオフの飽和、および readiness の喪失についてアラートを発報します。制限された試行回数の後、Pod の置換またはオペレータから確認できる障害へとエスカレーションします。

Pod 全体を再起動する方が安全なのはどのような場合ですか？

ステートが共有されている場合、初期化順序が重要である場合、または1つのコンテナの破損が他のコンテナを無効化する可能性がある場合は、Pod の置換を使用します。一貫性のない部分的なリカバリよりも、広範囲な再起動の方が適しています。

この機能をどのようにロールバックしますか？

ワークロードテンプレートでポリシーを無効化し、以前の再起動動作を復元して、古いレプリカが収束することを確認します。ロールバック後も可観測性を維持できるように、終了コードの規約とダッシュボードを保持します。