K8Sデプロイ設計判断（面接質問）¶
原文¶
面接官: 「アプリケーションをKubernetesにデプロイするにはどうしますか。」
🔴 候補者A: 「Deployment、Service、Ingressを作成します。」 YAMLを書き始めます
🟢 候補者B: 「その前に、いくつか質問してもいいですか？」
面接官: 「もちろんです。」
候補者B: - 「アプリはステートフルですか、それともステートレスですか？」 - 「予想されるトラフィックは？」 - 「オートスケーリングの必要性はありますか？」 - 「ノードやゾーンをまたいだ高可用性が必要ですか？」
面接官: 「ステートレスで、高トラフィック、オートスケーリングが必要です。」
候補者B: 「素晴らしい。HPA、リソース制限、レディネスプローブを含めます…」
教訓: Kubernetesへのデプロイは簡単です。難しいのは正しくデプロイすることです。
要約¶
K8S面接で差がつくのは「いきなりYAMLを書き始める」vs「前提条件を聞いて適切な構成を選ぶ」。ステートフル/レス、トラフィック規模、スケーリング要件、可用性要件で必要なリソース（Deployment/StatefulSet、HPA、リソース制限、Readinessプローブ等）が変わる。要件確認が設計の第一歩。
解説¶
候補者Aが見落としているもの¶
候補者AはK8Sの基本構成（Deployment/Service/Ingress）を知っているが、なぜその構成でよいかの判断基準がない。本番でよく起きる問題：
- ステートフルなのにDeploymentで作ってPod再起動時にデータ消失
- リソース制限がなくノード全体が落ちる（ノイジーネイバー）
- Readiness/Liveness プローブがなくて障害中のPodにトラフィックが流れる
- HPAなしでトラフィック急増時にサービス停止
候補者Bが聞くべき4つの観点¶
| 観点 | 影響する設計 |
|---|---|
| ステートフル/レス | Deployment vs StatefulSet、PV/PVC有無 |
| トラフィック規模 | レプリカ数、HPA、リソース制限値 |
| オートスケーリング要件 | HPA/VPA、Cluster Autoscaler |
| 高可用性要件 | PodAntiAffinity、マルチAZ、PodDisruptionBudget |
本番K8Sに必要な最低限の構成¶
- HPA (Horizontal Pod Autoscaler): CPU/メモリやカスタムメトリクスに応じてPodを自動スケール
- リソース制限:
resources.requests/limitsでノードの適切な配置とOOM回避 - Readinessプローブ: 起動/トラフィック受付可能かの判定
- Livenessプローブ: ハング検知と自動再起動
- PodDisruptionBudget: ノード停止時の最小利用可能Pod数
→ 既存材料: K8S_マニフェストのアノテーション、AWS_K8S学習