さて、最近、生成AIの話が多いですが、こういう基礎的な部分、インフラ部分の理解は、どのエンジニアでも必要です。AIエンジニアであっても、大規模サービスがどのように動いているかを理解する必要が中野哲平はあると思いっています。

Docker 基礎

Q1: Dockerとは何か？簡潔に。
A: アプリとその実行環境（依存・設定）を軽量なコンテナという単位でパッケージ化して実行する仕組み。VMよりも起動が速く、同じイメージでどこでも同一動作を実現できる。

Q2: コンテナと仮想マシンの違いを述べよ。
A: 仮想マシンはハイパーバイザ上に完全なゲストOSを立てる（重い）。コンテナはホストOSのカーネルを共有しプロセス分離で軽量。起動時間・リソース効率がコンテナ優位。

Q3: イメージとコンテナの違いは？
A: イメージは読み取り専用の静的な設計図、コンテナはそのイメージを実行した可変の実行環境。

Q4: Dockerfile の基本命令を3つ挙げて簡単に説明せよ。
A: FROM（ベースイメージ指定）、RUN（ビルド時コマンド実行）、CMD/ENTRYPOINT（コンテナ起動時のコマンド）。他に COPY/ADD/EXPOSE など。

Q5: イメージのレイヤーとは？なぜ重要？
A: Dockerfile の各命令がイメージのレイヤーになる。キャッシュ効率やイメージサイズに影響し、キャッシュを活用するとビルド高速化できる。

Q6: コンテナのライフサイクル（主要ステータス）を説明せよ。
A: Created → Running → Paused（任意）→ Stopped/Exited → Removed。restartポリシーで自動再起動可能。

Q7: docker run -it --rm ubuntu bash の意味は？
A: -i：標準入力を保持、-t：疑似TTY割当、--rm：終了時にコンテナ自動削除。ubuntu イメージで bash を起動。

Dockerfile / イメージ設計

Q8: 良い Dockerfile の書き方（ベストプラクティス）を3つ挙げよ。
A: ①不要なファイルは .dockerignore に列挙、②キャッシュを活かすため頻繁に変わるものは下側に配置、③最小ベース（slim/alpine）でサイズを小さく。

Q9: マルチステージビルドとは何か、いつ使う？
A: ビルド段階と実行段階を分け、不要なビルドアーティファクトを最終イメージに含めない。GoやNodeのビルドで本番イメージを小さくするために使う。

Q10: ENTRYPOINT と CMD の違いは？
A: ENTRYPOINT はコンテナの主コマンドを固定、CMD はデフォルト引数や実行コマンドを指定（ENTRYPOINT と組み合わせて引数渡しが可能）。

Q11: イメージのタグ戦略はどうする？（例）
A: latest は曖昧になるため避ける。<app>:<semver> とビルドID/hash（例：myapp:1.2.3 / myapp:sha256-...）を使う。CIで自動タグ付け推奨。

Q12: イメージサイズを小さくする方法は？
A: マルチステージ、不要ファイル除外、--no-cache 付けない（キャッシュ利用）、軽量ベースイメージ使用、不要パッケージの削除。

Docker ネットワーク・ボリューム・セキュリティ

Q13: Docker のネットワークドライバの種類を挙げ、それぞれ用途を述べよ。
A: bridge（デフォルト、単一ホストのコンテナ接続）、host（ホストのネットワークを共有）、overlay（複数ホスト間、SwarmやK8sで使用）、macvlan（L2で直接IP割当）。

Q14: ボリュームとバインドマウントの違いは？
A: ボリュームは Docker 管理の永続ストレージ（推奨）。バインドマウントはホストのパスを直接マウント（開発時便利だが移植性低い）。

Q15: コンテナ内でのセキュリティ対策（基本）を3つ挙げよ。
A: ①最小特権で実行（非rootユーザ）、②イメージの脆弱性スキャン、③不要なCAPを削除・seccompやAppArmor利用。

Q16: どのようにコンテナの脆弱性をチェックする？
A: Clair、Trivy、Anchore 等のスキャナでイメージスキャンをCIに組み込む。

Docker Compose / CI・運用

Q17: docker-compose を使う場面は？
A: 複数コンテナ（DB, キャッシュ, アプリ等）をローカルで一括起動・連携して開発・テストする時。

Q18: 本番で docker-compose を使うのはどうか？
A: 小規模なら可だが、拡張性・可用性・クラスタ管理が必要なら Kubernetes 等のオーケストレーターを使う。

Q19: CIでのイメージビルド時に注意する点は？
A: キャッシュ戦略、マルチアーキ構成（arm/amd）、秘密情報の取り扱い（シークレット管理）、ビルドの再現性。

Kubernetes 基礎・アーキテクチャ

Q20: Kubernetesの役割を一言で。
A: 大量のコンテナを自動で配置・管理・スケール・復旧するオーケストレーション基盤。

Q21: Kubernetes の主な制御プレーンコンポーネントを挙げよ。
A: kube-apiserver（APIエンドポイント）、etcd（状態ストア）、kube-scheduler（スケジューリング）、kube-controller-manager（各種コントローラ）。

Q22: 各 Node 上の主要コンポーネントは？
A: kubelet（Pod のライフサイクル管理）、kube-proxy（Service のネットワーク）、コンテナランタイム（containerd/mobyなど）。

Q23: Control plane と Node の違いは？
A: Control plane はクラスタの意思決定（管理）、Node は実際にワークロードを走らせる作業者。

Q24: kube-apiserver と etcd の関係は？
A: kube-apiserver がすべてのCRUD操作のフロントで、状態は etcd に永続化される。etcd の可用性はクラスタ健全性に直結。

Kubernetes オブジェクト（Pod / Deployment 等）

Q25: Pod とは？
A: Kubernetes の最小実行単位。通常は1つの主要コンテナ＋サイドカー等で構成され、同じネットワークネームスペースを共有する。

Q26: ReplicaSet と Deployment の違いは？
A: ReplicaSet は指定数の Pod を維持するオブジェクト。Deployment は ReplicaSet を管理しロールアウト戦略やアップデートを扱う上位オブジェクト。通常は Deployment を使う。

Q27: StatefulSet はどんな用途に使う？
A: ステートフルなサービス（例：データベース）で順序性や安定した永続ボリューム、固定ホスト名が必要な場合に使用。

Q28: DaemonSet の用途は？
A: 各 Node に一つずつ Pod を配置したい（ログ収集エージェント、監視エージェント、ネットワークプラグイン）場合に使用。

Q29: Job と CronJob の違いは？
A: Job は一度実行するバッチ処理。CronJob はスケジュール（cron）で定期実行する Job を生成する。

Q30: InitContainer とは何か？使いどころは？
A: メインコンテナより先に実行されるコンテナで、初期化処理（設定生成、待機）に使う。

Q31: sidecar パターンとは？例をあげよ。
A: 主コンテナの機能を補助するコンテナを同じ Pod に入れるパターン（ログ転送、プロキシ、TLS終端）。例：Fluentd sidecar でログを外部に送る。

サービス（Service / Ingress）とネットワーキング

Q32: Service（ClusterIP/NodePort/LoadBalancer）の違いを説明せよ。
A: ClusterIP：クラスタ内のみアクセス可能（デフォルト）。NodePort：各 Node の特定ポートで公開。LoadBalancer：クラウドのLBをプロビジョニングして外部公開。

Q33: Ingress は何のため？
A: HTTP/HTTPS のルーティングを集約してホスト名やパス単位で Service に振るため。Ingress Controller（例：nginx, GCE, Traefik）が必要。

Q34: kubectl port-forward と Service の違いは？
A: port-forward は一時的にローカルから Pod/Service へトンネルする開発用。Service はクラスタ内外で継続的にアクセスするためのリソース。

Q35: CNI プラグインとは？いくつか例を挙げよ。
A: Container Network Interface：K8s の Pod ネットワークを提供。例：Calico, Flannel, Weave Net, Cilium（eBPFベース）。

Q36: Service Discovery の仕組みを簡潔に。
A: Service 作成時に DNS（CoreDNS）がエントリを作成し、<service>.<namespace>.svc.cluster.local で名前解決できる。ClusterIPへルーティングされる。

ストレージ（PV/PVC/StatefulSet）

Q37: PersistentVolume（PV）と PersistentVolumeClaim（PVC）の関係を説明せよ。
A: PV はクラスター管理者が提供する実際のストレージ、PVC はユーザが要求する永続ボリュームの要求（抽象）。PVC がバインドされて PV を使う。

Q38: StorageClass の目的は？
A: 動的プロビジョニングを定義するためのクラス（例：SSD/標準/HDD、プロビジョナ指定）、プロビジョニングポリシーを指定できる。

Q39: StatefulSet と Deployment の違い（ストレージ面）を述べよ。
A: StatefulSet は Pod ごとに安定した PVC を割り当てるのに対し、Deployment は Pod が壊れても同じ PVC を保証しない。DB等は StatefulSet。

Q40: ReadWriteOnce と ReadWriteMany の違いは？
A: ReadWriteOnce：一つのノードで読み書き可能、ReadWriteMany：複数ノードで読み書き可能（NFS、CSIが対応する場合あり）。

スケジューリング・ノード管理

Q41: NodeSelector と Affinity の違いは？
A: NodeSelector は単純なキー/バリュー一致。Affinity（nodeAffinity/podAffinity）はより柔軟なルール（必須/優先度や演算子）を指定できる。

Q42: Taints と Tolerations の関係は？
A: Node に taint を付けると通常の Pod はスケジュールされない。toleration を Pod に付けるとその taint を許容してスケジュールされる。

Q43: ノードをメンテナンスするときの Pod の移行手順は？
A: kubectl drain <node> で Pod を退避（DaemonSetは除外オプション）。メンテ後に kubectl uncordon <node>。

Q44: Pod の QoS クラスとは？何が決まる？
A: Guaranteed / Burstable / BestEffort。requests と limits の設定で決まる（リソース不足時の優先度に影響）。

ローリングアップデート・リリース戦略

Q45: Deployment のローリングアップデートはどう動く？
A: 新しい ReplicaSet を作り、順次古い Pod を削除して新しい Pod を立ち上げる。maxUnavailable/maxSurge で挙動制御可能。

Q46: Blue/Green と Canary 展開の違いを説明せよ。
A: Blue/Green：本番とほぼ同一の新環境を準備し切り替える。Canary：トラフィックの一部を新バージョンへ段階的に流して検証する。

Q47: ゼロダウンタイムデプロイで考慮すべき点を挙げよ。
A: セッション管理（sticky session回避）、DBスキーマ互換性、readiness probe、適切な maxUnavailable/maxSurge、gradual rollout。

モニタリング・ログ・トラブルシュート

Q48: Pod が CrashLoopBackOff になった時の調査手順は？
A: kubectl describe pod <>（イベント確認） → kubectl logs <pod> --previous（クラッシュ前ログ） → kubectl exec -it <pod> -- /bin/sh（状況確認） → イメージ/設定/Envの確認。

Q49: ロギングとモニタリングの代表的な構成は？
A: ログ：Fluentd/Fluent Bit → Elasticsearch / Loki → Kibana / Grafana。メトリクス：Prometheus + Grafana。トレース：Jaeger。

Q50: ノードが NotReady の場合の対策は？
A: kubectl describe node で原因確認（kubelet落ち/ディスク不足/ネットワーク）。必要ならノードを cordon → drain → 再起動・修復。

Q51: メモリリークで Pod が OOMKilled される。原因特定の方法は？
A: kubectl logs と kubectl describe pod のOOMイベント確認、アプリ側メモリプロファイラ、limits/requests 設定確認、ヒープダンプ収集。

セキュリティ / RBAC / ネットワークポリシー

Q52: Kubernetes の RBAC の基本概念を説明せよ。
A: Role/ClusterRole（権限セット）、RoleBinding/ClusterRoleBinding（主体に権限を割当）。最小権限の原則で運用する。

Q53: NetworkPolicy の用途は？
A: Pod間通信を制限してマイクロセグメンテーションを実現。デフォルトは許可なので、厳密に制御したい場合は deny-by-default にする。

Q54: シークレットを守る方法は？
A: K8s Secret は base64 エンコードのみ（暗号化ではない）。kubectl の --export 回避、Secrets Encryption at Rest（etcd暗号化）、外部シークレット管理（Vault, KMS）を使う。

Q55: Pod の実行ユーザを root でなくするには？
A: Dockerfile で USER 指定、PodSecurityContext/ SecurityContext で runAsUser を指定して非rootで実行。

Q56: Pod Security Admission / PodSecurityPolicy の違い（過去・現状）
A: PSP は古い方式（deprecated）。PodSecurity admission は組み込み方式でポリシーの enforcement を提供。クラスタ毎のポリシー運用が重要。

高度なトピック（Helm / Operator / CRD など）

Q57: Helm とは何か、どんな場面で使う？
A: Kubernetes 用のパッケージマネージャ。テンプレート化されたマニフェストを管理し、リリース管理・再利用を簡単にする。複数環境の値差分管理が得意。

Q58: CRD と Operator の違いを説明せよ。
A: CRD はユーザ定義リソースを作る仕組み。Operator はその CRD を監視してカスタム制御ループを実装するコントローラ。状態管理の自動化に使う。

Q59: Admission Controller とは？何ができる？
A: API サーバに到達するリクエストを検査・変更（Mutating/Validating）するプラグイン。ポリシー適用やラベル自動付与、セキュリティチェックに利用。

Q60: Service Mesh（例：Istio）の利点は？
A: トラフィック管理、観測性（トレース/メトリクス）、認証・認可（mTLS）などをアプリコード改修なしで提供する。通信の細かなルーティング制御が可能。

面接で出やすい設計 / シナリオ問題（要点付き）

Q61: （設計）可用性の高いウェブアプリを Kubernetes 上で設計してください。
A（要点）: Deployment で複数レプリカ、Service(LB)で公開、DBはマネージドRDSまたは StatefulSet + PV（マルチAZ）、PodDisruptionBudget設定、Horizontal Pod Autoscaler、リードレプリカ構成、監視（Prometheus）とアラート、ログ集約、CI/CDでローリング/Canary。

Q62: （トラブル）デプロイ後、いくつかの Pod が CrashLoopBackOff。原因調査をどう進める？
A（手順）: kubectl describe pod（イベント）→ kubectl logs --previous→ イメージタグ確認→環境変数・ConfigMap確認→kubectl execで手動挙動確認→必要ならイメージローカルで実行してデバッグ。

Q63: （スケール）高トラフィック時にレスポンスを保つ設計は？
A（要点）: HPA（CPU/カスタムメトリクス）、Cluster Autoscaler、キャッシュ（Redis / CDN）、DB接続プール制御、リソースrequests/limits適切設定、バックプレッシャー処理。

Q64: （CI/CD）イメージビルド→K8sデプロイの安全なワークフローは？
A（要点）: CIでイメージビルド＋脆弱性スキャン→レジストリへpush（タグ付け）→CD（ArgoCD/Flux/Kustomize/Helm）でマニフェスト適用→Canary/BlueGreen→監視で自動ロールバック条件設定。

Q65: （移行）VM上のアプリをコンテナ化してK8sへ移行する際の注意点は？
A（要点）: ステートレス化（セッション管理の外出し）、設定とシークレット分離、外部依存（DB/ファイルストレージ）の確認、リソース要求見積もり、ログ/監視整備、段階的カットオーバー。

よく使うコマンド（面接で出やすい／覚えておくと便利）

Docker

docker build -t myapp:1.0 .
docker run -it --rm -p 8080:8080 myapp:1.0
docker ps
docker logs <container>
docker exec -it <container> /bin/sh
docker images
docker rmi <image>

kubectl（Kubernetes）

kubectl get nodes
kubectl get pods -A
kubectl describe pod <pod> -n <ns>
kubectl logs <pod> -c <container>
kubectl apply -f deployment.yaml
kubectl delete -f deployment.yaml
kubectl port-forward svc/my-svc 8080:80
kubectl scale deployment/myapp --replicas=5
kubectl rollout status deployment/myapp
kubectl rollout undo deployment/myapp
kubectl get events -n <ns>

その他：面接でよく問われる短問集（素早く答えられるように）

Q: kubectl explain pod は何をする？
A: Pod オブジェクトの仕様（フィールド説明）を表示するヘルプ。
Q: kubectl apply と kubectl create の違いは？
A: apply は宣言的更新（既存を差分で更新）・create は新規作成のみ。
Q: readinessProbe と livenessProbe の違いは？
A: readiness はトラフィック受け入れ可否、liveness は死活監視（再起動判定）。
Q: Pod が Node を跨いで通信できる理由は？
A: 各 Pod がフラットなIPを持つ（CNI がネットワークを確保）ため。
Q: kubectl port-forward でなぜ TLS/HTTPS が必要な場合に使うことがある？
A: ローカル開発で Ingress/LB を経由せずにセキュアにアクセスしたい時に利用。

面接での回答のコツ（短くて実用的）

まず一文で結論（例：「Kubernetes はコンテナのオーケストレーション基盤です。」）
次に根拠・理由を1〜2行（例：「スケーリング、自己修復、サービスディスカバリを提供するため。」）
最後に具体例やコマンド、運用上の注意点を1行（例：「Deployment の maxUnavailable でローリング制御できます。」）
知らない／確信がないときは正直に →「確信がないが一般的には…」と前置きしてから推測を述べる（面接官は誠実さも見る）。

付録：模範的な短い口頭回答（例）

問: Pod が ImagePullBackOff になった。どうする？
答: まず kubectl describe pod でイベント確認。認証エラーなら imagePullSecrets、タグミスならイメージ名/タグを修正、レジストリ unreachable ならネットワークを確認。CIでイメージがpushされているかも確認します。