プロンプトと適用コンテキスト
あなたは、アプリケーションの横でログエージェント、サービスメッシュプロキシ、またはローカルキャッシュデーモンを実行するKubernetesワークロードを担当しています。チームはそのヘルパーを通常のコンテナからKubernetesネイティブサイドカーへと移行したいと考えています。アプリケーションはヘルパーの準備完了を待つ必要があり、ヘルパーの障害には明示的な可用性境界が必要であり、設計はJob、ローリングリリース、リソースクォータ、ロールバックを網羅しなければなりません。移行計画を提案し、バージョンスキュー、プローブ、終了順序、障害処理について説明してください。
これはシステムデザインの質問です。評価されるのは、暗記したYAMLの断片ではなく、境界とトレードオフに関する論理的思考力です。ライフサイクル、互換性、リソース、オブザーバビリティ、ロールバックを網羅してください。
面接官が評価するポイント
- サービスレベル目標（SLO）を起動、Readiness、終了、障害ポリシーへと落とし込めるか。
- ネイティブサイドカー、通常のコンテナ、個別のDeployment、DaemonSetの間の境界を説明できるか。
- APIサーバー、ノード、Webhook、クライアント間のバージョンスキューのリスクを特定できるか。
- リソースバジェット、段階的ロールアウト、メトリクス、ロールバックによって移行リスクを低減できるか。
- Jobの完了、プロキシのスタック、プローブの失敗、ノードのアップグレードなどの反例に対処できるか。
AmazonのSDE II準備資料では、システムデザインの評価基準として、実用性、正確性、効率性、信頼性、最適化、スケーラビリティが挙げられています。この質問では、これらの目標をPodのライフサイクルとリリースコントロールに適用することが求められます。
明確化のための質問
- ヘルパーはPodごとに1つですか、それともノードごとに1つですか？ アプリケーションのネットワーク名前空間やボリュームを共有する必要がありますか？
- ヘルパーの準備が整う前に、アプリケーションはトラフィックを受信してもよいですか？ 起動失敗時はリリースをブロックしますか、動作を縮退（デグレード）させますか、それともバイパスを許可しますか？
- これは長時間実行されるサービスですか、それとも一度限りのJobですか、あるいはその両方ですか？ 終了時にログのフラッシュやデータのアップロードが必要ですか？
- クラスター、APIサーバー、ノード間でKubernetesのバージョンは揃っていますか？ Admission Webhook、テンプレートレンダラー、またはクライアントが未知のフィールドを削除する可能性はありますか？
- ヘルパーのCPU、メモリ、エフェメラルストレージ、ネットワークのバジェットはどのくらいですか？ その障害はアプリケーションのエラーバジェットを消費しますか？
- 通常コンテナのテンプレートをロールバックスイッチとして保持しながら、名前空間またはワークロード単位でカナリアリリースを実行できますか？
30秒の回答フレームワーク
目標から始めます。ヘルパーとアプリケーションを1つのPod内に維持し、順序通りに起動させ、動作を観測可能にし、無期限にブロックするヘルパーを許容することなく迅速なロールバックを可能にすることです。initContainers内にコンテナレベルのrestartPolicy: Always、適切なReadinessプローブ、明示的なリソースバジェットを設定してネイティブサイドカーを実装します。クラスターとAdmissionのチェックによって互換性を保護します。2つのテンプレートを段階的にロールアウトし、起動レイテンシとエラー率を比較し、しきい値を超えた場合は古い形式に戻し、Jobの完了と終了時のフラッシュを個別にテストします。
ステップバイステップの詳細な回答
1. まずライフサイクルの境界を定義する
Kubernetesネイティブサイドカーは特別なinitコンテナです。コンテナレベルのrestartPolicy: Alwaysにより、初期化中に起動して実行を継続できます。依然としてinitコンテナの順序に従うため、後続のinitコンテナおよびアプリケーションコンテナは、サイドカーが使用可能になるまで待機します。「プロキシが最初に準備完了になる」ことは、アプリケーションのポーリングループではなく、Podレベルの構造的な保証となります。
アプリケーションとサイドカーはPodのネットワークおよびストレージ名前空間を共有します。これはUnixソケット、ログボリューム、またはローカルプロキシポートに有用です。ヘルパーがノードレベルの機能のみを提供する場合は、Podごとにコストを支払う代わりにDaemonSetを検討してください。
2. Readinessと障害ポリシーを定義する
ヘルパーには、コントロールプレーン設定の読み込み完了、リッスンポートの利用可能性、重要な証明書の有効性など、実際の機能を表すreadinessProbeを設定します。サイドカーのReadinessはPodのReadinessに影響を与える可能性があるため、プローブが失敗するとPod全体がサービスから外れる場合があります。プローブは状態を報告するものであり、リトライ、レート制限、グレースフルデグラデーションを代替するものではありません。
起動失敗、実行中のクラッシュ、一時的に利用できない依存関係を区別します。通常、起動失敗時はPodをサービス外に保ちます。実行中のクラッシュはAlwaysによって再起動されますが、再起動回数、復旧時間、エラー率からSLOがすでに損なわれていないかを確認する必要があります。オプションのヘルパーにはバイパスを設けることができます。セキュリティや認証のプロキシはフェイルクローズとし、エラーバジェットを超過した場合は迅速にロールアウトを停止する必要があります。
3. 終了処理、Job、フラッシュに対処する
ネイティブサイドカーはアプリケーションコンテナの後に終了し、複数のサイドカーは逆順でシャットダウンします。したがって、ログエージェントはアプリケーション終了後にバッファを排出（ドレイン）できますが、終了猶予期間（termination grace period）には厳格な上限が必要です。フラッシュがタイムアウトした際の損失量を記録し、決して無期限に待機させてはなりません。
Jobの場合、コントローラーがサイドカーを無期限に待機するのではなく、メインコンテナの完了をもってJobの完了として扱うことを検証します。サイドカーはJob完了前まで再起動を繰り返す可能性があるため、タスクの結果、サイドカーのフラッシュ結果、最終的なデータ整合性を別々のシグナルおよびアラートとして公開します。
4. バージョンとミューテーションの経路を確認する
ネイティブサイドカーはKubernetes v1.33で安定版（GA）となり、デフォルトで有効化されています。この機能はv1.29からベータ版としてデフォルトで有効でした。移行前には、すべてのノードプールにおける実際のkubelet、APIサーバー、Admissionコンポーネント、フィーチャーゲートを確認してください。
古いMutating Webhook、テンプレートツール、またはクライアントはコンテナレベルのrestartPolicyを認識できず、オブジェクトの書き換え時にそれを削除してしまう可能性があります。CIで最終オブジェクトを検証し、Admissionログにサイドカーの定義構造を記録し、ランタイムの順序を確認するプローブPodを実行します。パイプラインが信頼できない場合は、通常コンテナへのフォールバックを維持するか移行を一時停止します。
5. リソースとスケジューリングへの影響を計算する
サイドカーは無料ではありません。そのCPU、メモリ、エフェメラルストレージのRequestsはPodの実効リソース計算に関与し、QoS、クォータ、スケジューリングに影響を与えます。アプリケーションのピーク、ヘルパーの起動ピーク、バッファ制限を使用してRequestsとLimitsを計算し、ノードの断片化、Eviction、OOM、起動キュー時間を監視します。
ヘルパーに独立したスケーリング、個別のリリースサイクル、またはより広い障害ドメインが必要な場合は、個別のDeploymentの方が適している可能性があります。ネイティブサイドカーは、スケジューリング、リソース、リリースを1つのユニットに結合する一方で、ローカル共有とライフサイクル順序の制御を提供します。
6. カナリア、オブザーバビリティ、ロールバックを設計する
ネイティブサイドカー用と従来の通常コンテナ用の2つのPodテンプレートを準備します。名前空間、ラベル、またはワークロードごとにロールアウトし、バッチごとに自動停止条件を設けます。少なくとも、Pod作成からReadyまでのレイテンシ、サイドカーのReadiness失敗、再起動回数、アプリケーションリクエストエラー、バッファの深さ、フラッシュ損失、CPUおよびメモリのピーク、Jobの完了レイテンシを追跡します。
移行中は、期待される定義構造と実際の定義構造を記録します。Deploymentオブジェクトの適用成功だけでは不十分です。Webhookによってフィールドが削除されたり、Readyレイテンシが悪化したり、ヘルパーの再起動がしきい値を超えた場合は、展開を停止して古いテンプレートに切り替えます。ロールバック時は、古いテンプレートが新しい設定、ボリューム形式、ポートの前提条件を引き継いでいないことも確認する必要があります。
7. セキュリティとオブザーバビリティを境界内に組み込む
サイドカーはPodのネットワークとボリュームを共有するため、Podと同じアクセス権限を持ちます。最小権限、読み取り専用のルートファイルシステム、明示的なサービスアカウント、ネットワークポリシーを適用します。「単なるヘルパー」だからといって監査コントロールを省略してはなりません。ログ、メトリクス、トレースにPod、コンテナ、リリースバージョンのラベルを追加し、アプリケーションの障害とヘルパーの障害を分離できるようにします。
質の高い模範解答
まず、ヘルパーをPod単位の依存関係として分類し、ネットワークまたはストレージの共有が本当に必要であるかを確認します。ノードレベルの機能であれば、DaemonSetを選択します。移行テンプレートにはネイティブサイドカーを使用します。ヘルパーをinitContainersに配置し、コンテナレベルのrestartPolicy: Alwaysを設定します。これによりinit順で起動し、readinessProbeで設定とポートが使用可能であることを確認した後にのみ、アプリケーションがサービスを開始します。
障害は、起動失敗、実行中クラッシュ、一時的に利用できない依存関係に分類します。セキュリティプロキシはフェイルクローズとし、オプションの機能拡張はバイパスを保持します。終了時は、サイドカーがアプリケーションの後にシャットダウンする順序を利用して、制限時間付きのフラッシュを実行します。Jobについては、長時間実行されるヘルパーがJobの状態をブロックしないよう、メインコンテナの完了とサイドカーのフラッシュを個別に検証します。
ロールアウト前に、古いツールがrestartPolicyを削除する可能性があるため、APIサーバー、すべてのノードプール、フィーチャーゲート、Webhook、テンプレートクライアントを確認します。CIで最終オブジェクトを検証し、カナリアリリースで実際のPodの順序とReadinessを検証します。リソースバジェットにはヘルパーのピークを含めてQoS、クォータ、スケジューリングを考慮し、ダッシュボードでReadyレイテンシ、再起動、エラー、バッファ、損失を可視化します。2つのテンプレートを段階的にロールアウトし、しきい値違反が発生した場合は展開を停止して古い形式にロールバックします。これにより、ネイティブなライフサイクル保証を活用しながら、バージョン、リソース、障害の境界を観測可能なリリースゲートとして機能させます。
よくある間違い
- ネイティブサイドカーが必要な理由や、通常のコンテナや個別のワークロードが適しているケースを説明せずにYAMLを貼り付ける。
restartPolicy: Alwaysをサイドカーのコンテナ定義内ではなく、Podレベルに記述してしまう。- livenessProbeのみを設定し、Readinessの失敗がトラフィックやロールアウトの挙動をどのように変化させるかを省略する。
- ノード、Webhook、クライアントのスキューを確認せずに、Kubernetesのバージョンだけで十分だと仮定する。
- サイドカーを無料であるかのように扱い、リソースクォータ、起動ピーク、バッファリング、QoSへの影響を見落とす。
- 長時間実行サービスのみをテストし、Jobの完了、フラッシュのタイムアウト、逆順での終了処理を忘れる。
- 古いテンプレート、ポート、ボリューム、Admissionの出力を確認せずに、イメージのみをロールバックする。
フォローアップの質問と回答
古いノードがネイティブサイドカーをサポートしていない場合はどうしますか？
ロールアウトを停止し、ノードプール単位で隔離します。オブジェクトがコンテナレベルのポリシーを保持できるか信頼できない場合は、通常コンテナのテンプレートを使用するか、ノードをアップグレードします。未知のフィールドを暗黙的に削除することは互換性とは言えません。
サイドカーのReadinessが失敗し続けるとどうなりますか？
PodはReady状態にならず、ロールアウトコントローラーは展開を停止する必要があります。設定エラー、利用できない依存関係、プローブのバグを切り分け、修正またはロールバックを行います。プローブの判定を無制限に緩めて実際の利用不可状態を隠蔽してはなりません。
Jobのメインコンテナが終了した後もサイドカーは実行され続けますか？
ネイティブサイドカーは実行および再起動を継続する可能性がありますが、Jobコントローラーはメインコンテナの完了を認識できます。フラッシュに制限時間を設け、タスクの結果をデータの整合性とは別に記録することで、ヘルパーの長時間実行がタスクの失敗と誤認されないようにします。
プロキシに個別のDeploymentを使用しないのはなぜですか？
プロキシに独立したスケーリング、リリース、またはより広い障害ドメインが必要な場合は、分離を選択します。ローカルソケット、共有ネットワーク、厳密な起動順序が不可欠な場合は、ネイティブサイドカーを選択します。決定は結合度とSLOに基づきます。
移行後のリソース圧迫の増加はどのように診断しますか？
移行前後のPodの実効Requests、起動ピーク、ノードの断片化、Eviction、OOMを比較し、ヘルパーのバッファと並行性を調査します。ヘルパーがノードレベルの機能のみを提供する場合は、DaemonSetを検討します。Pod内に維持する必要がある場合は、バジェットを見直すかカナリアの規模を縮小します。
ロールバックが安全であることをどのように証明しますか？
古いテンプレートのハッシュを保持します。ロールバック中は、コンテナの構造、ポート、ボリューム、サービスアカウント、Webhookの出力を検証し、カナリアバッチでReadyレイテンシ、エラー率、フラッシュ損失を監視します。シグナルが回復した後にのみ展開を継続します。