Docker & Kubernetes 面接の質問

Docker & Kubernetes 面接で問われる内容

Docker & Kubernetes 面接の質問例

• Dockerイメージとコンテナの違いは何ですか？
  良い回答が押さえる点

  • イメージは静的テンプレート、コンテナは実行インスタンス
  • イメージは読み取り専用、コンテナは書き込み可能レイヤーを持つ
  • イメージはレジストリで共有、コンテナは隔離プロセス
  • イメージから複数のコンテナを作成可能

  サンプル回答を見る

  Dockerイメージはコンテナを生成するための静的なテンプレートであり、アプリケーションとその依存関係をパッケージ化したものです。イメージは読み取り専用のレイヤーで構成され、Dockerfileからビルドされます。一方、コンテナはイメージの実行インスタンスであり、分離されたプロセスとして動作します。コンテナはイメージに加えて書き込み可能なレイヤーを持ち、ファイルの変更やプロセスの実行が可能です。イメージはDocker Hubなどのレジストリに保存され、複数のコンテナのベースとして使用できます。コンテナはそのライフサイクル中に状態を変更できますが、イメージは不変です。開発者はイメージを配布し、ユーザーはそのイメージからコンテナを起動してアプリケーションを実行します。

• CrashLoopBackOff状態でスタックしているPodをどのようにデバッグしますか？
  良い回答が押さえる点

  • ログを確認（kubectl logs）
  • イベントとdescribeを確認
  • リソース制限とプローブ設定を確認
  • 環境変数や設定の誤りを確認
  • コンテナ内で手動プロセス起動

  サンプル回答を見る

  CrashLoopBackOffはPodが繰り返しクラッシュする状態を示します。デバッグの第一歩はkubectl logs <pod-name>でコンテナのログを確認し、エラーメッセージを特定することです。次にkubectl describe pod <pod-name>でイベントとコンテナの終了コードを確認します。よくある原因は、アプリケーションの設定ミス（不正な環境変数やマウントポイント）、リソース不足（メモリ/CPUの制限が低すぎる）、または依存サービスの接続失敗です。また、readiness probeやliveness probeの設定が不適切な場合もクラッシュを引き起こします。必要に応じて、kubectl execでコンテナ内に入り、手動でプロセスを起動して動作を確認します。さらに、エラーログを外部サービスに送信するようにアプリケーションを修正することも有効です。最後に、Deploymentのロールバックやイメージの変更も検討します。

• ポート3000で動作するNode.jsアプリケーションのDockerfileを書いてください。
  良い回答が押さえる点

  • ベースイメージはnode:18-alpine
  • 作業ディレクトリを設定
  • 依存関係をnpm ciでインストール
  • ソースコードをコピー
  • ポート3000を公開し、CMDで起動

  サンプル回答を見る

  以下はNode.jsアプリケーションのDockerfileです。軽量なAlpineベースを使用し、マルチステージビルドは省略していますが、必要に応じて追加してください。

  # 軽量なNode.jsベースイメージを使用
  FROM node:18-alpine
  
  # アプリケーションディレクトリを作成
  WORKDIR /usr/src/app
  
  # package.jsonとpackage-lock.jsonをコピー
  COPY package*.json ./
  
  # 依存関係をインストール（本番のみ）
  RUN npm ci --only=production
  
  # アプリケーションコードをコピー
  COPY . .
  
  # ポート3000を公開
  EXPOSE 3000
  
  # アプリケーションを起動
  CMD ["node", "app.js"]

• Kubernetes Serviceがどのように機能し、ロードバランシングを可能にするか説明してください。
  良い回答が押さえる点

  • ServiceはPodの論理セットに安定エンドポイントを提供
  • kube-proxyがiptables/IPVSでロードバランシング
  • ClusterIP, NodePort, LoadBalancerのタイプ
  • セレクタでPodを選択
  • クライアントはService経由でアクセス

  サンプル回答を見る

  Kubernetes Serviceは、Podのグループへのネットワークアクセスを提供する抽象化レイヤーです。Podは動的にIPアドレスが変わるため、Serviceは安定したエンドポイント（ClusterIP、DNS名）を提供します。Serviceはkube-proxyコンポーネントを介して実装され、デフォルトではラウンドロビン方式のロードバランシングを行います。ユーザーはServiceのtypeをClusterIP（クラスタ内通信）、NodePort（ノードのポート経由）、LoadBalancer（外部LB経由）などから選択できます。Serviceはselectorラベルに一致するPodを自動的に検出し、トラフィックをそれらのPodに分散します。また、Serviceを介して異なるバージョンのPodへのカナリアリリースやブルーグリーンデプロイが容易になります。ただし、Serviceのロードバランシングはクライアントサイドではなく、kube-proxyによるパケット転送レベルで行われます。この設計により、アプリケーションコードはロードバランシングを意識せずに済みます。

• ゼロダウンタイムで更新をロールアウトするデプロイメントを作成してください。
  良い回答が押さえる点

  • RollingUpdate戦略を使用
  • maxSurgeとmaxUnavailable設定
  • レプリカ数は3以上
  • readiness probeでトラフィック制御

  サンプル回答を見る

  以下はゼロダウンタイム更新を実現するDeploymentマニフェストです。RollingUpdate戦略により、新しいPodを徐々に作成し、古いPodを削除します。readiness probeを適切に設定することで、新しいPodが準備できるまでトラフィックを送らないようにします。

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: my-app
  spec:
    replicas: 3
    strategy:
      type: RollingUpdate
      rollingUpdate:
        maxSurge: 1        # 更新中に追加できるPodの最大数
        maxUnavailable: 0  # 更新中に利用不可となるPodの最大数（0でゼロダウンタイム）
    selector:
      matchLabels:
        app: my-app
    template:
      metadata:
        labels:
          app: my-app
      spec:
        containers:
        - name: app
          image: my-app:latest
          ports:
          - containerPort: 80
          readinessProbe:   # 準備ができたか確認
            httpGet:
              path: /healthz
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10

• Kubernetesでシークレットを管理するにはどうすればよいですか？
  良い回答が押さえる点

  • Secretオブジェクトでbase64エンコード保存
  • etcd暗号化で保存時暗号化
  • 環境変数またはボリュームマウントで注入
  • 外部ストア（Vault等）統合が推奨
  • RBACでアクセス制御

  サンプル回答を見る

  Kubernetesでは、Secretオブジェクトを使用してパスワード、トークン、キーなどの機密情報を管理します。Secretはbase64エンコードされたデータとして保存されますが、これは難読化であり暗号化ではありません。etcdの暗号化を有効にすることで保存時の暗号化を強化できます。SecretはPodに環境変数として注入するか、ボリュームとしてマウントすることができます。環境変数はPod作成時に評価されるため、更新時に再作成が必要ですが、ボリュームマウントは動的に更新されます。セキュリティを高めるためには、外部のSecretストア（HashiCorp Vault、AWS Secrets Managerなど）と統合し、CSIドライバーやExternal Secrets Operatorを使用するのが一般的です。また、RBACを使用してSecretへのアクセスを制限し、最小権限の原則を適用します。よくある落とし穴として、Secretを誤ってGitリポジトリにコミットしないように注意する必要があります。また、Secretのサイズは1MBに制限されているため、大きなデータは別の方法で管理すべきです。

• Podのライフサイクルを生成から削除まで説明してください。
  良い回答が押さえる点

  • Pending: スケジューリング待ち
  • Running: コンテナ実行中
  • Succeeded/Failed: 終了状態
  • Unknown: ノード通信不可
  • InitコンテナやProbeを含む詳細段階

  サンプル回答を見る

  Podのライフサイクルは、主にPending、Running、Succeeded、Failed、Unknownの5つのフェーズで構成されます。Podが作成されるとPending状態になり、スケジューラがノードを割り当て、コンテナイメージをプルします。Initコンテナがある場合は、それが最初に実行され、完了後にメインコンテナが起動します。コンテナ起動後、PostStartフックが実行され、Readiness Probeが成功するとServiceのエンドポイントに追加されます。Liveness Probeはコンテナが正常に動作しているか定期的にチェックし、失敗するとコンテナを再起動します。Podが終了する際にはPreStopフックが実行され、SIGTERMシグナルが送られ、その後SIGKILLで終了します。コンテナが正常終了するとSucceeded、異常終了するとFailed状態になります。Unknownはノードとの通信が途絶えた場合などに発生します。デバッグ時にはPodのイベントとコンテナの終了コードを確認することが重要です。

• HorizontalPodAutoscalerを使用してCPU使用率に基づいてデプロイメントをスケーリングするにはどうすればよいですか？
  良い回答が押さえる点

  • Metrics Serverが必要
  • targetCPUUtilizationPercentageを設定
  • minReplicasとmaxReplicasで範囲指定
  • 定期的にメトリクス取得しレプリカ調整
  • クールダウン期間あり

  サンプル回答を見る

  HorizontalPodAutoscaler（HPA）は、CPU使用率やカスタムメトリクスに基づいてDeploymentやStatefulSetのレプリカ数を自動的にスケーリングするKubernetesリソースです。まず、Metrics Serverがクラスタにデプロイされている必要があります。HPAマニフェストでは、scaleTargetRefで対象のDeploymentを指定し、metricsでターゲットのメトリクス（例：resource.cpu.targetAverageUtilization: 50）を定義します。HPAは定期的にメトリクスを取得し、現在の使用率と目標値を比較してレプリカ数を計算します。スケーリングの安定性を保つために、デフォルトで5分間のクールダウン期間があります。また、最大・最小レプリカ数を設定することで、過剰なスケーリングを防ぎます。よくある問題として、Metrics Serverが正しく動作していない、またはアプリケーションがリソースリクエストを設定していないためにHPAが機能しないことがあります。したがって、コンテナに適切なリソースリクエストを設定することが前提です。HPAはCluster Autoscalerと併用することで、ノード自体も自動スケーリングできます。

準備方法

• ツールに頼らずに手動でDockerfileやKubernetes YAMLマニフェストを書く練習をしましょう。
• Minikubeやkindを使ってローカルクラスタをセットアップし、実際のデプロイメントやサービスを試しましょう。
• kubectlコマンドライン（kubectl describe、kubectl logs、kubectl execなどのトラブルシューティングコマンドを含む）を完全に理解しましょう。
• コンテナネットワーキングの基本概念と、KubernetesがCNIプラグインでどのようにネットワーキングを実装するかを学びましょう。
• ローリングアップデート、カナリアデプロイメント、Podリソース制限などの一般的なインタビューシナリオを勉強しましょう。

よくある質問