プロンプトとコンテキスト
あるマルチコンテナPodに、APIプロキシ、キャッシュサイドカー、バッチワーカーが含まれています。チームはPodを削除することなく、レイテンシとキュー長に基づいてPodレベルのCPUおよびメモリバジェットを調整したいと考えています。オブザーバビリティ、判断ロジック、/resizeへの書き込み、ステータストラッキング、並行性保護、実行不可能なリクエストの処理、およびロールバックを含めてコントローラーを設計してください。
面接官がテストするポイント
- 希望リソース（desired resources）、実際のリソース（actual resources）、コンテナ再起動ポリシーを区別できているか。
- 冪等なリコンサイル、ステータス条件、保留（Deferred）/実行不可能（Infeasible）リトライを設計できるか。
- Podバジェットとコンテナリクエストに明示的な境界とセーフティレールが存在するか。
- メトリクス、パーミッション、リカバリ、プログレッシブロールアウトが設計に含まれているか。
確認すべき質問
- クラスターはPodレベルのリサイズをサポートしていますか？また、どの機能ゲート（feature gates）とkubectlバージョンがインストールされていますか？
- コントローラーはCPU、メモリ、あるいはPodとコンテナ両方のリソースを変更しますか？
- どのコンテナが再起動可能で、どのコンテナに中断不可能な接続や状態がありますか？
- 目的はコスト削減、SLOの維持、それともバースト的なキューの吸収ですか？
30秒の回答
イベント駆動型の冪等なリコンサイラーを構築します。メトリクスとPod状態を読み取り、バジェット、SLO、ノード容量、クールダウンの範囲内でターゲットを計算し、/resizeサブリソースを介して小さな変更を送信します。ステータスにはobservedGeneration、PodResizePending、PodResizeInProgress、およびInfeasibleまたはDeferredの理由を記録します。リトライにはバックオフ、優先度、最大試行回数を使用します。CPUとメモリは個別に評価され、コンテナのresizePolicyが尊重され、メモリのリスクやSLOの低下が発生した場合は最後に検証されたバジェットが復元されます。すべての書き込みにはオーナー、監査証跡、RBAC境界が設定されます。
ステップバイステップの詳細解説
リソースモデルとセーフティ境界の定義
Podレベルのspec.resourcesは集約バジェットであり、コンテナのrequestsとlimitsは依然として保証や再起動の挙動に影響します。ワークロードごとに最小値、最大値、ステップ幅、クールダウン、SLOのガードレールを維持し、ネームスペースクォータやノード容量を超えるリクエストは拒否します。
メトリクスの収集とターゲットの計算
レイテンシ、キュー長、CPUスロットリング、ワーキングセット、OOMイベントを使用します。単一のスパイクに反応しないようウィンドウとヒステリシスを適用します。ターゲットはPodバジェットとコンテナリクエストの合計制約の両方を満たす必要があります。
冪等なリサイズサブリソース更新の送信
コントローラーはリソースバージョンとオーナー情報を用いて希望状態を更新します。リクエストの例：
spec:
resources:
requests:
cpu: "300m"
memory: "512Mi"
limits:
cpu: "1"
memory: "1Gi"/resizeサブリソースを呼び出し、resourceVersionを確認します。コンフリクトが発生した場合は、ユーザーや他のコントローラーを上書きするのではなく、再読み込みしてリコンサイルを実行します。
条件とリトライ優先度のトラッキング
PodResizePendingやPodResizeInProgress、さらにobservedGenerationなどの条件を読み取ります。Infeasibleは現在の制約ではリクエストを満たせないことを意味し、Deferredは延期されたことを意味します。理由、次回の試行時間、試行回数を永続化します。低優先度のワークロードが永久に枯渇しないよう、ワークロードの優先度、QoS、待機時間に基づいてリトライをスケジュールします。
コンテナ再起動ポリシーの処理
Podレベルの変更は、コンテナレベルのresizePolicyをトリガーする可能性があります。CPUは再起動なしで適用できる場合がありますが、メモリは再起動が必要になる場合があります。各コンテナのポリシー、接続、状態を検査します。再起動不可能なリクエストはセーフティキューの背後に配置し、Podレベルの成功のみをもってビジネスの継続性を判断してはいけません。
監視、ロールバック、高可用性の維持
ターゲット値と実際の値、条件遷移、再起動回数、レイテンシSLO、メモリピーク、失敗理由を記録します。リーダー選挙（leader election）を用いてコントローラーレプリカを実行し、Podキーによってキューを重複排除します。不正なバジェット、OOM、SLO低下が発生した場合は、最後の安定したターゲットを復元し、人間による確認のために自動化を一時停止します。
模範回答
レイテンシ、キュー、スロットリング、ワーキングセット、OOMメトリクスを読み取り、最小/最大バジェット、ステップ幅、クールダウン、ノード容量、ネームスペースクォータ内でターゲットを計算する冪等なリコンサイラーを構築します。/resizeを介してリソースバージョン管理された小さな変更を送信し、コンフリクト時には再読み込みします。observedGeneration、Pending、InProgress、Infeasible、Deferredの理由、リトライ時間を記録し、優先度と待機時間に応じてリトライをスケジュールします。メモリの変更によってコンテナが再起動される前に、すべてのコンテナのリサイズポリシーを検査します。リーダー選挙、メトリクス、監査ログを活用し、SLO低下やOOM発生時には最後の安定したバジェットを復元して自動化を一時停止します。
よくある間違い
- Pod specを直接編集し、
/resizeサブリソースを無視してkubeletがそれを適用すると想定してしまう。 - 希望リソースのみを読み取り、実際のリソースやステータス条件を無視する。
- クールダウンやヒステリシスを省略し、振動（フラッピング）や頻繁な再起動を引き起こす。
- Deferredリクエストを永久に破棄したり、Infeasibleリクエストを制限なしにリトライし続けたりする。
- コンテナの
resizePolicyやメモリ再起動リスクを無視する。 - resourceVersion、オーナー、RBACが不足しており、コントローラー同士が互いに上書きしてしまう。
フォローアップ質問
2つのコントローラーが互いに上書きし合うのをどのように防ぎますか？
明示的な所有権、resourceVersion、フィールド管理（field management）、および単一の書き込みオーナーを使用します。無条件な上書きではなく、コンフリクト時に再読み込みして意図をマージします。
InfeasibleとDeferredをどのように区別しますか？
Infeasibleは現在の制約ではターゲットを満たせず、新しいターゲットまたはキャパシティが必要であることを意味します。Deferredは一時的なものであり、理由と優先度を保持したままリトライする必要があります。
自動化はいつ一時停止すべきですか？
OOM、持続的なSLO低下、条件の不変、過剰な再起動、または無効な観測データが発生した場合に一時停止し、手動リカバリパスを維持します。
中断が発生しなかったことをどのように証明しますか？
ポリシーごとに、リサイズ条件、コンテナのrestartCount、接続エラー、レイテンシ、キューのメトリクスを関連付けて検証します。PodフェーズがRunningのままであることだけでは不十分です。