プロンプトとコンテキスト
プラットフォームチームがKubernetesのPodレベルのCPUおよびメモリリサイズを有効化しようとしています。プロダクトチームは自動チューニングを求め、財務チームはコストを懸念し、SREチームはメモリの変更によってコンテナが再起動する可能性を懸念しています。チーム横断のアドミッション、監査、インシデント対応、およびロールバックポリシーを作成してください。
面接官がテストするポイント
- 技術的な機能が明確な所有権、権限、および予算の境界に落とし込まれているか。
- リスク階層によって、どのワークロードが自動リサイズ可能かが決定されているか。
- ステータス条件、再起動ポリシー、およびSLOが承認の証拠となっているか。
- 監査と訓練によって、インシデント下でポリシーが機能することが証明されているか。
確認すべき質問
- どのネームスペース、環境、ワークロードがリサイズ可能ですか？
- 制限を承認し、コストを所有し、緊急に変更を凍結できるのは誰ですか？
- コンテナの
resizePolicy、ステートフル接続、およびメモリ再起動リスクをどのように検出しますか？ - 組織にはすでにクォータ、変更ウィンドウ、監査、およびインシデント指揮系統が存在しますか？
30秒の回答
環境、ビジネスの重要度、および再起動リスクによって階層化します。開発環境は自動的にチューニングできますが、重要な本番サービスには承認が必要です。ポリシーによってCPUとメモリの境界、ステップ幅、クールダウン、ネームスペースクォータ、SLOのガードレールを定め、所有者、理由、observedGenerationを含む/resizeサブリソースを必須とします。アドミッションは理由のないリクエストや範囲外のリクエストを拒否し、イベントによってPending、InProgress、Infeasible、Deferredを区別します。監査はコストと再起動を関連付け、定期的な訓練によって凍結、ロールバック、所有権の引き継ぎを演習します。
ステップバイステップの詳細解説
リスク階層の定義
環境、SLO、データ状態、接続の遮断耐性、およびコンテナのresizePolicyに基づいて階層化します。重要なステートフル、決済、コントロールプレーンのワークロードはデフォルトでメモリ変更に承認を必要とし、低リスクのステートレスワークロードは制限内でチューニング可能とします。
アドミッションルールの確立
ネームスペースの許可リスト、リソース境界、ステップ幅、クールダウン、ノードキャパシティ、クォータ、変更ウィンドウ、およびラベルを必須とします。すべてのリクエストでメトリクスソース、ターゲット、および予想コストを明記します。
ポリシーをKubernetesのステータスにバインド
コントローラが要求リソース/実際のリソース、observedGeneration、およびリサイズ条件を読み取ることを必須とします。実際値と一致して完了したInProgressのみを成功とし、Pending、Infeasible、Deferredは理由とともに可視化された状態を維持します。
再起動とロールバックの処理
メモリ変更によってコンテナが再起動する可能性があるため、サービスは接続のドレイン、状態の復元、および最大再起動回数を宣言します。ゲートを超過した場合は自動化を凍結し、最後に安定していた予算を復元します。PodフェーズのRunningはビジネス継続性の証明にはなりません。
コストと監査をファーストクラス化
変更前後のCPUおよびメモリ、期間、見積もりコスト、所有者、承認者、および結果を記録します。財務チームはネームスペース、チーム、ワークロードごとの予算差異を確認し、SREチームはSLO、OOM、および再起動イベントを関連付けます。
インシデント訓練の実施とガバナンスの進化
ノードキャパシティ不足、コントローラの停止、不適切な予算、広範囲なロールバックの訓練を実施します。事後にポリシー、ランブック、および連絡先を更新します。一時的な許可リストが恒久化しないよう、すべての例外に有効期限を設定します。
模範解答
Podのリサイズは自由なスイッチではなく、ガバナンスされた変更として扱います。環境、SLO、状態、およびresizePolicyによって階層化し、重要なステートフルサービスには承認を必須とします。アドミッションによってネームスペース、境界、ステップ幅、クールダウン、クォータ、キャパシティ、および変更ウィンドウを固定し、所有者、理由、observedGenerationを含む/resizeを必須とします。コントローラはPending、Infeasible、Deferredを報告し、実際の状態からのみ成功を確認します。メモリ再起動ゲートではドレインと復元を必須とし、違反時は凍結およびロールバックします。監査によってコスト、SLO、OOM、restartCountを関連付け、訓練によって凍結、ロールバック、所有権の引き継ぎをリハーサルします。
よくある間違い
- 承認者、凍結権限、所有者を定めずにリソース制限を作成すること。
- すべての本番ネームスペースで自動メモリリサイズを許可すること。
/resizeの条件やコンテナの再起動ポリシーを無視すること。- Running状態のPodフェーズを中断のないビジネスサービスの証拠として扱うこと。
- コスト監査、例外の有効期限、ロールバック訓練を省略すること。
- インシデントが発生してから初めて所有者やランブックを探すこと。
フォローアップの質問
どのサービスをデフォルトで自動メモリリサイズ無効にすべきですか？
迅速にドレインできないサービス、状態の復元にコストがかかるサービス、または再起動時に整合性が損なわれるリスクがある重要なサービスは、承認と訓練の完了を必須とすべきです。
チームがPodを直接編集してポリシーを回避するのをどう防ぎますか？
アドミッション、RBAC、フィールド管理、および監査を使用して不正な書き込みを拒否します。緊急権限は期限付きで追跡可能とし、自動的に失効させます。
コストとSLOが競合した場合、誰が決定しますか？
ポリシーによって優先順位と予算のしきい値を事前に設定します。コントローラが暗黙のうちに選択するのではなく、指定されたプロダクト所有者とSRE所有者がしきい値を超えた場合に判断を下します。
ポリシーが機能していることをどのように確認しますか？
拒否された範囲外リクエスト、SLOの低下、OOM、再起動、予算差異、ロールバック時間、および訓練の完了状況を比較し、各チームとともに見直します。