# Kubernetes面接対策：Pod、Service、Deploymentの仕組みと実践的な質問解説

> Kubernetesの3大構成要素であるPod、Service、Deploymentを本番レベルのYAMLマニフェストとともに解説。ネットワーキングの内部動作、スケーリング戦略、面接頻出の質問と回答を網羅します。

- Published: 2026-04-04
- Updated: 2026-04-04
- Author: SharpSkill
- Tags: kubernetes, devops, interview, containers, orchestration
- Reading time: 10 min

---

Kubernetesの技術面接では、Pod、Service、Deploymentという3つの基本オブジェクトに関する質問が繰り返し出題されます。コンテナのスケジューリングからネットワークルーティング、ローリングアップデートに至るまで、これらの相互作用を深く理解していることが、定義を暗記しただけの候補者と、本番システムを設計できるエンジニアを分ける決定的な要素です。

本記事では、各プリミティブを本番品質のYAMLで解説し、面接官が重視する内部構造を説明し、DevOpsおよびプラットフォームエンジニアリングの面接で実際に出題される質問を取り上げます。

> **クイックリファレンス**
>
> Podは単一ノード上で1つ以上のコンテナを実行します。DeploymentはPodのレプリカとロールアウトを管理します。ServiceはそれらのPodに到達するための安定したネットワークエンドポイントを提供します。この3つのオブジェクトが、Kubernetes v1.35以降のクラスタにおけるワークロード管理の80%を担っています。

## Kubernetes Podの理解：最小のデプロイ単位

Podは、Kubernetesにおけるスケジューリングの最小単位です。同一のネットワーク名前空間、IPC名前空間、ストレージボリュームを共有する1つ以上のコンテナをラップします。Pod内のすべてのコンテナは同じIPアドレスを取得し、`localhost`を通じて兄弟コンテナと通信できます。

単一コンテナのPodが最も一般的なパターンです。マルチコンテナPodは、ログコレクタ、サービスメッシュ、メインプロセス起動前にファイルシステムを準備するinitコンテナなどのサイドカーシナリオで使用されます。

```yaml
# api-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: api-server
  labels:
    app: api
    version: v2
spec:
  containers:
    - name: api
      image: registry.example.com/api:3.1.0
      ports:
        - containerPort: 8080
      resources:
        requests:
          cpu: "250m"
          memory: "256Mi"
        limits:
          cpu: "500m"
          memory: "512Mi"
      readinessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 20
```

`resources`ブロックは面接において重要なポイントです。`requests`はスケジューリングを決定します。スケジューラは十分な空き容量を持つノードにPodを配置します。`limits`はランタイム時の上限を強制します。メモリ制限を超えるとOOMKillが発生し、CPU制限を超えるとスロットリングが発生します。

> **面接でよく出る落とし穴**
>
> memory limitsをrequestsなしで設定すると、予測不可能なスケジューリングが発生します。kubeletが実際にはワークロードを維持できないノードにPodを配置する可能性があります。本番環境のPodでは、必ず`requests`と`limits`の両方を設定してください。

## Podのライフサイクルフェーズとリスタートポリシー

KubernetesはすべてのPodを5つのフェーズで追跡します：`Pending`、`Running`、`Succeeded`、`Failed`、`Unknown`。面接では各遷移のトリガーが頻繁に問われます。

| フェーズ | 意味 | 主な原因 |
|---------|------|----------|
| Pending | スケジュール済みだが未実行 | イメージプル中、リソース不足 |
| Running | 少なくとも1つのコンテナが実行中 | 通常動作 |
| Succeeded | すべてのコンテナが終了コード0で終了 | バッチジョブ、initコンテナ |
| Failed | 少なくとも1つのコンテナが非ゼロで終了 | アプリクラッシュ、OOMKill |
| Unknown | ノードとの通信が途絶 | ネットワーク分断、ノード障害 |

`restartPolicy`フィールドは、コンテナ終了後の動作を制御します。`Always`（Deploymentのデフォルト）は終了コードに関係なく再起動します。`OnFailure`は非ゼロ終了時のみ再起動します（Jobsに有用です）。`Never`はコンテナを停止したままにします（ワンショットのデバッグPodに使用されます）。

```yaml
# batch-job-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: data-migration
spec:
  restartPolicy: OnFailure
  containers:
    - name: migrate
      image: registry.example.com/migrate:1.0.0
      command: ["python", "migrate.py"]
      env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: connection-string
```

`valueFrom.secretKeyRef`パターンは、機密データをマニフェストから分離します。Kubernetes Secretsはデフォルトでbase64エンコードされますが、暗号化はされません。本番環境では、`EncryptionConfiguration` APIによるat-rest暗号化を有効にするか、HashiCorp Vaultなどの外部シークレットマネージャーを使用します。

## Kubernetes Deployment：宣言的なロールアウトとスケーリング

[Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)はReplicaSetを作成・管理し、ReplicaSetがPodを管理します。Deploymentコントローラは望ましい状態を監視し、現実との差分を調整します。スケールアップ時にはPodを追加し、ロールアウト中にはPodを置換し、ヘルスチェックが失敗するとロールバックを行います。

本番環境でPodを直接作成することはほぼ適切ではありません。Deploymentはレプリカ管理、ローリングアップデート、ロールバック履歴、一時停止/再開の機能を提供します。

```yaml
# api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api
spec:
  replicas: 3
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      app: api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: api
        version: v2
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
```

`strategy.rollingUpdate`セクションは、ダウンタイムゼロのデプロイ動作を定義します。`maxUnavailable: 1`と`maxSurge: 1`の設定では、Kubernetesは新しいPodを1つ作成し、readinessチェックに合格するのを待ってから、古いPodを1つ終了します。このサイクルがすべてのレプリカが新しいバージョンで実行されるまで繰り返されます。

### 失敗したKubernetes Deploymentのロールバック

ロールバックは面接で高頻度で出題されるトピックです。DeploymentコントローラはReplicaSetを保持します（`revisionHistoryLimit`で制御）。そのためロールバックは即座に実行可能であり、イメージの再ビルドは不要です。

```bash
# Check rollout status
kubectl rollout status deployment/api-server

# View revision history
kubectl rollout history deployment/api-server

# Roll back to previous version
kubectl rollout undo deployment/api-server

# Roll back to specific revision
kubectl rollout undo deployment/api-server --to-revision=3
```

`undo`コマンドは、対象リビジョンのPodテンプレートに一致するようDeployment specをパッチします。その後、ローリングアップデート戦略が通常通り適用され、現在のPodがロールバックバージョンに徐々に置き換えられます。

## Kubernetes Service：動的なPodのための安定したネットワーキング

Podは一時的な存在です。再起動するたびに新しいIPアドレスが割り当てられます。[Service](https://kubernetes.io/docs/concepts/services-networking/service/)は、ラベルセレクタに一致する正常なPodにトラフィックをルーティングする安定した仮想IP（ClusterIP）とDNS名を提供することで、この問題を解決します。

各ノード上のkube-proxyコンポーネントが、iptablesまたはIPVSルールをプログラムし、バックエンドPod間でトラフィックを分散します。PodがreadinessプローブにFailすると、EndpointsコントローラがそのPodをServiceから除外し、不健全なインスタンスにはトラフィックが到達しなくなります。

```yaml
# api-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: ClusterIP
  selector:
    app: api
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP
```

作成後、クラスタ内の任意のPodが`api-service.default.svc.cluster.local`（同一名前空間内では単に`api-service`）でこのServiceに到達できます。名前解決はCoreDNSが処理します。

## Serviceの種類：ClusterIP、NodePort、LoadBalancer

面接官は、3つの主要なServiceタイプとそれぞれの適用場面の説明を期待します。

| タイプ | アクセス範囲 | ユースケース |
|--------|------------|-------------|
| ClusterIP | クラスタ内部のみ | バックエンドAPI、データベース、キャッシュ |
| NodePort | `<ノードIP>:<ポート>`経由で外部から | 開発環境、ベアメタルクラスタ |
| LoadBalancer | クラウドLB経由で外部から | AWS/GCP/Azureでの本番トラフィック |

```yaml
# api-loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-public
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - name: https
      port: 443
      targetPort: 8080
      protocol: TCP
```

`LoadBalancer`タイプは、クラウドプロバイダのロードバランサコントローラに外部エンドポイントのプロビジョニングをトリガーします。AWSではアノテーションに応じてNLBまたはALBが作成されます。クラウド統合のないベアメタルクラスタでは、MetalLBやkube-vipがこの役割を担います。

> **Gateway APIがIngressに取って代わる**
>
> Kubernetes v1.35において、Ingress NGINXコントローラは正式に廃止されました。[Gateway API](https://gateway-api.sigs.k8s.io/)が、HTTPルーティング、TLS終端、トラフィック分割の推奨アプローチとなっています。新規クラスタでは最初からGateway APIを採用すべきです。

## DeploymentとServiceをラベルセレクタで接続する

DeploymentとServiceの連携はラベルセレクタのみで成り立っています。2つのオブジェクト間に明示的な参照は存在しません。Serviceは`spec.selector`に一致するラベルを持つPodを監視し、Endpointsリストを自動的に維持します。

この疎結合アーキテクチャにより、単一のServiceが複数のDeploymentのPodにルーティングでき（カナリアリリースに有用）、1つのDeploymentが複数のServiceで公開できます（異なるポート、異なるアクセスレベル）。

```yaml
# canary-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
        version: v3-canary
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.2.0-rc1
          ports:
            - containerPort: 8080
```

メインのDeploymentが3レプリカ、カナリアが1レプリカで実行されている場合、Serviceはトラフィックの約25%をカナリアに分配します。Serviceの設定変更は不要です。ラベルマッチングがすべてを処理します。

## Kubernetes DeploymentのHorizontal Pod Autoscaling

静的なレプリカ数は、トラフィックが少ない時にリソースを浪費し、スパイク時には処理能力が不足します。[HorizontalPodAutoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)（HPA）は、観測されたメトリクスに基づいてレプリカ数を調整します。

```yaml
# api-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
```

HPAはデフォルトで15秒ごとにメトリクスサーバーをポーリングします。Kubernetes v1.35では設定可能なHPAトレランスが導入され、ハードコードされた10%のしきい値が置き換えられました。これにより、レイテンシに敏感なワークロードを運用するチームは、より厳密なスケーリングトリガーを設定できるようになりました。

`behavior.scaleDown.stabilizationWindowSeconds`はフラッピング（バースト的なトラフィックパターンによるスケールアップ/スケールダウンの急速な繰り返し）を防止します。

## よくあるKubernetes面接質問と回答

以下の質問は、DevOpsおよびプラットフォームエンジニアリングの面接で繰り返し出題されます。各回答は、面接官が求める深さを目指しています。

**Podがメモリ制限を超えた場合、何が起きますか。**
kubeletがOOMキラーを通じてSIGKILLを送信します。コンテナは終了コード137で終了します。DeploymentコントローラがFailしたPodを検出し、リスタートポリシーとバックオフ遅延に基づいて代替Podを作成します。

**カナリアリリース中に、Kubernetesは特定のPodバージョンにどのようにトラフィックをルーティングしますか。**
Serviceセレクタは共有ラベル（例：`app: api`）でマッチングします。安定版とカナリアの両方のDeploymentがこのラベルを使用します。トラフィック分配は準備完了したEndpointの数に比例します。3つの安定版レプリカ + 1つのカナリアレプリカでは、約25%のカナリアトラフィックとなります。より精密なトラフィック分割（例：5%）を行うには、Gateway API HTTPRouteの重み付きバックエンドを使用します。

**`readinessProbe`と`livenessProbe`の違いは何ですか。**
readinessプローブは、PodがServiceからトラフィックを受信するかどうかを制御します。readinessプローブが失敗すると、PodはEndpointsリストから削除されますが、再起動はされません。livenessプローブは、コンテナが再起動されるかどうかを制御します。livenessプローブが失敗すると、コンテナの再起動がトリガーされます。どちらもHTTP、TCP、execチェックが使用可能です。

**ローリングアップデートはどのようにしてダウンタイムゼロを保証しますか。**
Deploymentコントローラは、`maxSurge`と`maxUnavailable`に基づいて、古いPodを終了する前に新しいPodを作成します。新しいPodはreadinessプローブに合格してから古いPodがドレインされます。`terminationGracePeriodSeconds`（デフォルト：30秒）は、SIGKILLの前に処理中のリクエストが完了する時間を確保します。

Kubernetesの面接対策には、理論だけでなく実際のYAMLを使った実践練習が不可欠です。SharpSkillの[DevOps面接問題集](/technologies/devops/interview-questions/kubernetes-basics)では、これらのトピックをインタラクティブなドリルで学習できます。

## まとめ

- Podはスケジューリングの最小単位であり、リソースの`requests`と`limits`を必ず設定し、readinessとlivenessの両方のプローブを構成することが重要です
- DeploymentはReplicaSetを介してレプリカ数、ローリングアップデート、ロールバック履歴を管理します。本番環境では直接Podを作成すべきではありません
- Serviceはラベルセレクタと仮想IPを通じて安定したネットワーキングを提供します。内部トラフィックにはClusterIP、外部トラフィックにはLoadBalancerを使用します
- DeploymentとServiceの連携は純粋にラベルベースであり、設定変更なしでカナリアパターンを実現できます
- HPAはCPU/メモリメトリクスに基づいてDeploymentをスケーリングします。フラッピング防止のために`stabilizationWindowSeconds`を使用してください
- Kubernetes v1.35以降、Gateway APIがIngress NGINXに取って代わりました。新規プロジェクトでは最初から採用すべきです
- 定義の暗記ではなく、実際のYAMLマニフェストと`kubectl`コマンドを使った実践練習を行いましょう

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/ja/blog/devops/kubernetes-interview-pods-services-deployments-explained