Kubernetes の Pod レベルのリソース要求をどのように設計しますか？

問題と背景

Kubernetes の Pod レベルリソースを使用すると、Pod はコンテナレベルの値に加えて CPU、メモリ、または hugepages のリクエストとリミットを宣言できます。両方が存在する場合は Pod レベルの値が優先され、スケジューリング、QoS、および OOM スコアリングに影響を与えます。ロールアウト前に PodLevelResources フィーチャーゲートとクラスタバージョンを確認する必要があります。

プロキシとワーカーがバースト性のあるワークロードを共有しているものの、プロキシにはレイテンシ SLO があり、ワーカーは余剰キャパシティを使用できる状況を想定します。目標は、スケジューラや kubelet にチームが意図していなかったバジェットを強制させることなく、その関係性を表現することです。

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

面接官は、明確なリソース所有モデル、正しい優先順位ルール、および Pod レベルのリクエストがスケジューリングと QoS を変更することへの認識をチェックします。優れた回答では、集約とコンテナごとの保証の比較、リミット、オートスケーリング、可観測性、および移行テストについて議論されます。

一般的な回答は、コンテナリクエストの合計を spec.resources にコピーするだけです。優れた回答では、Pod のバジェットが共有プールであるかどうか、どのコンテナに下限（floor）が必要か、そして 1 つのワーカーがプロキシのレイテンシヘッドルームを消費してしまうのを防ぐ方法を説明します。

最初に明確にすべき質問

Pod レベルのリクエストは共有バジェットなのか、それとも各コンテナに対する厳格な最小値なのか？
どの Kubernetes バージョン、フィーチャーゲート、リソースマネージャー、オペレーティングシステムが対象範囲か？
プロキシにはワーカーから独立した保証された CPU 下限またはメモリリミットが必要か？
HPA、VPA、およびエビクションポリシーは新しいスコープをどのように認識するか？
移行中に Pod レベルとコンテナレベルの両方のリクエストが指定された場合、何が起きるか？

コンテナのスケーリングや障害ドメインが独立している場合は、別々の Pod に分ける方が安全な場合があります。ライフサイクルとバーストバジェットを真に共有している場合は、Pod レベルのリソースを使用することでその関係をより直接的に表現できます。

30秒での回答

「まずフィーチャーゲートとバージョンのサポートを確認し、次に Pod を明示的なプロキシの下限を持つ共有バジェットとしてモデル化します。Pod レベルのリクエストが優先されるため、誤った混在設定を避け、QoS と OOM の動作をテストし、オートスケーラーの入力を確認します。マニフェストをカナリアリリースし、以前のポリシーとレイテンシ、スロットリング、エビクション、コストを比較し、コンテナレベルのリクエストへのロールバック手段を保持します。」

ステップバイステップの設計

リソースの役割をマッピングする。 プロキシのレイテンシ感度、ワーカーのバースト性、定常状態の使用率、およびメモリ増加を測定します。コンテナがバジェットを共有するのか、それとも隔離された保証が必要なのかを決定します。
機能を確認する。 Kubernetes サーバーのバージョン、コントロールプレーンおよびノード上の PodLevelResources ゲート、サポートされているリソースタイプ、および該当する場合は Linux のみの制限を確認します。
Pod バジェットを設定する。 スケジューリング用のリクエストと集約上限用（ceiling）のリミットを選択します。バジェットがプロキシのレイテンシ下限とワーカーのバーストのための余地を残していることを確認します。
曖昧な優先順位を避ける。 移行中、Pod レベルの値がコンテナレベルの値を上書きすることを文書化します。不要になったコンテナの値を削除するか、ポリシー上意図的に両方のスコープが必要な場合にのみ残します。
QoS とエビクションを確認する。 QoS クラスと OOM の挙動を再計算し、ノードのプレッシャー、スロットリング、ワーカーの競合をテストします。集約値が健全であっても、プロキシのリソース枯渇（starvation）が隠れている可能性があります。
ロールアウトと観察。 1 つのワークロードをカナリアリリースし、p95 レイテンシ、CPU スロットリング、メモリプレッシャー、OOM Kill、エビクション、再起動、コストを追跡します。ガードレールが維持されている場合にのみ展開を拡大します。

代替案としては、個別の Deployment、コンテナ固有のリクエストのみ、または明示的なリミットを持つサイドカーなどがあります。Pod レベルのリソースは、ライフサイクルとバーストキャパシティが意図的に共有されている場合に最も役立ちます。

回答例

「プロキシにはレイテンシの下限が必要ですが、ワーカーは余剰 CPU を借用できます。通常時の集約を反映した Pod リクエストとバースト上限のためのリミットを設定し、ワーカーの負荷下でもプロキシが枯渇しないことを検証します。移行中は、Pod レベルの値が優先されるため、競合するコンテナリクエストを削除するか、その目的を文書化します。2 つのノードでカナリアリリースを行い、p95 レイテンシ、スロットリング、OOM、エビクション、オートスケーラーの挙動を監視し、プロキシの SLO が低下した場合は以前のコンテナポリシーにロールバックします。」

よくある間違い

間違い: Pod のリクエストが自動的にコンテナごとの保証になると想定すること → 失敗する理由: バジェットが共有される可能性があるため → 修正方法: 下限と隔離を明示的に定義する。
間違い: 競合するコンテナの値を文書化せずに放置すること → 失敗する理由: Pod レベルの優先順位が運用者を混乱させるため → 修正方法: 有効なリソースを文書化してテストする。
間違い: CPU 使用率のみをチェックすること → 失敗する理由: メモリプレッシャーと OOM の挙動が変化する可能性があるため → 修正方法: CPU、メモリ、QoS、エビクション、レイテンシを合わせて観察する。
間違い: 1 つのコントロールプレーンコンポーネントでのみ機能を有効にすること → 失敗する理由: 必要なすべてのノードとコンポーネントがそれをサポートしている必要があるため → 修正方法: ロールアウト前にクラスタ全体での機能サポートを確認する。

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

Pod がリミットを下回っているにもかかわらず、プロキシが枯渇した場合はどうしますか？

競合による障害として対処します。プロキシの下限を追加するか、ワークロードを分離するか、コンテナレベルの隔離を使用します。集約のヘッドルームだけではレイテンシは保証されません。

Pod レベルのリクエストは QoS にどのように影響しますか？

両方のスコープが存在する場合は Pod レベルのリクエストが優先され、Pod の QoS および OOM 計算に影響します。移行中にクラスを再計算し、ノードのプレッシャーをテストしてください。

Windows Pod は Pod レベルのリソースを使用できますか？

バージョン固有の制限を確認してください。文書化されている Kubernetes 1.35 の動作では Windows Pod の Pod レベルリソースはサポートされていないため、その場合はコンテナレベルのポリシーを維持してください。

代わりに Pod を分割するのはどのような場合ですか？

コンテナが個別にスケーリング、失敗、または個別の SLO を持っている場合に分割します。共有ライフサイクルとバーストバジェットが意図的かつ観察可能である場合は、1 つの Pod を維持します。