第0章：コンテナ基礎ダイジェスト

本書は Kubernetes 上でアプリを動かすことに焦点を当てるため、コンテナ技術の詳細（名前空間/cgroups、ビルド最適化等）は扱いません。
ただし、最低限の前提がないと後続章の理解が止まるため、本章で「必要最小限」を整理します。

学習目標

• イメージ/コンテナ/レジストリ/ボリュームの用語を、Kubernetes の文脈で説明できる
• 後続章で出てくる image / ports / volumeMounts の意味を理解できる
• 深掘りが必要な場合に参照すべき情報源を把握する

扱う範囲 / 扱わない範囲

扱う範囲

• コンテナの概念（イメージとコンテナ、レジストリ）
• ネットワーク（ポート、到達性の考え方）
• ボリューム（永続化の必要性の判断）
• コンテナ実行基盤（ランタイムの存在）

扱わない範囲

• Linux 名前空間/cgroups の実装詳細
• イメージビルドの最適化（Dockerfile のベストプラクティス等）
• コンテナネットワークの内部実装（CNI の詳細など）

必要に応じて以下を参照してください。

• Podman 完全ガイド: https://itdojp.github.io/podman-book/

1. イメージとコンテナ

• イメージ: 実行に必要なファイル一式をまとめたテンプレート
• コンテナ: イメージから起動した実行単位（プロセス+隔離）

Kubernetes の spec.containers[].image は「どのイメージからコンテナを起動するか」を指定します。

2. レジストリ

イメージはレジストリから取得します。

• Public レジストリ（例: Docker Hub）
• Private レジストリ（組織内）

実務では「どこから pull するか」「認証が必要か」「脆弱性スキャンをどこで行うか」を決める必要があります。

3. ポートと到達性

コンテナは内部でポートを listen していても、外部から到達できるとは限りません。

• コンテナ内のポート: アプリが listen するポート
• Pod 内のネットワーク: 同一 Pod のコンテナは localhost で到達可能
• Pod 外への公開: Service / Ingress で公開します（本書の中心）

4. ボリュームと永続化

コンテナのファイルシステムは原則として揮発的です（再起動や再スケジュールで消える可能性があります）。
永続化が必要なデータは Volume/PV/PVC に逃がします（第9章で扱います）。

5. ランタイム（containerd 等）

Kubernetes はコンテナを直接実行するのではなく、ノード上のコンテナランタイム（例: containerd）に実行を委譲します。

本書ではランタイムの内部実装は扱いませんが、運用編では「ノード/ランタイム運用」として扱います。

ハンズオン（任意）: コンテナが動くことの確認

既にコンテナを利用している読者はスキップして問題ありません。

• Docker または Podman を使い、Nginx を起動して HTTP で応答が返ることを確認する
• 手順は Podman 本の該当章を参照する

出力例（Podman の場合）:

Podman のバージョン確認:

Nginx を起動し、HTTP 応答とログを確認する（例）:

よくある落とし穴

• 「コンテナ内ポート」と「外部公開」の区別が曖昧なまま Service/Ingress を理解しようとする
• 永続化が必要なデータを、コンテナ内のローカルファイルに保持してしまう

まとめ / 次に読む

• 次に読む: 第1章：Kubernetesの全体像