本記事は、非エンジニアである筆者がKubernetesを学習する中でのアウトプット（備忘録）です。
なお、記事の執筆にあたり生成AIも活用し調査のうえ記載していますが、万が一誤りがあればご指摘いただけると幸いです。
前回は、Kubernetes（以下K8s）を理解するための前提知識として「Linuxコマンド」と「Dockerコンテナ」について学びました。
【備忘】非エンジニアによるKubernetes学習アウトプット①（前提知識：LinuxとDocker）
今回からいよいよ、K8sの世界に入っていきます。
まずは、K8sでアプリケーションを動かすための、最小にして基本の単位である「Pod（ポッド）」についてアウトプットします。
1. Podとは何か？
一言で言うと、Podは「K8sが管理する最小単位の“箱”」です。
技術的には、「1つ以上のコンテナをまとめた、小さな仮想ホスト」のような存在と認識しています。
前回、Dockerコンテナを「たい焼き（実体）」に例えました。
K8sでは、この「たい焼き」をそのまま裸で管理するのではなく、「Podという袋(パッケージ)」に入れて管理します。
※Gemini作（イメージがわかりにくかったらすみません）
なぜコンテナを直接管理しないのか？
「1つのPodには、通常1つのコンテナ」が入ることが多いですが、時には「メインのアプリ」と「それを補助するアプリ（ログ収集など）」のように、密接に関わる複数のコンテナをセットで動かしたい場合があります。
Podという「袋」にまとめることで、以下のメリットが生まれます。
-
同じIPアドレスを共有できる: Pod内のコンテナ同士は、まるで同じPC内にいるかのように
localhostで通信できます。 - 同じボリューム（保存領域）を共有できる: Pod内のコンテナ同士でファイルを簡単に共有できます。
イメージとしては、以下のような図になります。（あくまでイメージです）
※Gemini作（イメージがわかりにくかったらすみません）
図のように、Podという大きな枠組みの中に、Nginxなどのコンテナが含まれ、IPアドレスやストレージを共有していることがわかります。K8sは、コンテナ単体ではなく、このPod単位でデプロイ（配置）や管理を行います。
2. Podを動かしてみる (実践)
では、実際にPodを作成して動かしてみましょう。
K8sでは、リソース（Podなど）の状態を「マニフェストファイル」と呼ばれるYAML形式のテキストファイルで定義するのが一般的です。
これは、「どうやって作るか（命令的）」ではなく「最終的にどういう状態であってほしいか（宣言的）」を定義するというK8sの特徴的なアプローチです。
① マニフェストファイルの作成
まず、テキストエディタで nginx-pod.yaml というファイルを作成し、以下の内容を記述します。
これは「Nginxのコンテナが1つ入ったPodを作りたい」という定義書（注文書）です。
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
- name: nginx-container
image: nginx
② Podの作成と確認
作成したマニフェストファイルをK8sクラスターに適用します。
- Podの作成:
kubectl apply -f nginx-pod.yaml
-
Podの一覧表示:
STATUSがRunningになれば起動成功です。
kubectl get pod
-
Podの詳細確認:
PodのIPアドレスやイベントログなど、詳細な情報を確認できます。起動しない時の調査によく使います。
kubectl describe pod nginx-pod
③ Podの中に入ってみる
前回のDockerと同じように、起動しているPod（の中のコンテナ）に入ってLinuxコマンドを実行できます。トラブルシューティングで非常によく使います。
# Podの中のシェル(/bin/sh)を起動して入る
kubectl exec -it nginx-pod -- /bin/sh
# 中でコマンドを実行してみる（例：ファイル一覧を見る）
# ls /etc/nginx
# 出る
# exit
④ Podの削除
不要になったPodを削除します。
kubectl delete pod nginx-pod
# またはマニフェストファイルを指定して削除
kubectl delete -f nginx-pod.yaml
3. Podの重要な性質：「使い捨て」
最後に、Podについて絶対に覚えておくべき性質があります。
それはPodは「使い捨て（エフェメラル）」であるということです。
Podは、何らかの理由（障害、スケーリング、ノードのメンテナンスなど）で簡単に停止・削除され、新しいPodに置き換わります。
- IPアドレスが変わる: Podが作り直されると、新しいIPアドレスが割り当てられます。そのため、PodのIPアドレスを直接指定して通信するのは確実ではありません。
- データが消える: Pod内のコンテナに保存したデータは、Podが削除されると一緒に消えてしまいます。
この「使い捨て」という性質が、次回以降に学ぶ「Service（安定した通信窓口）」や「Persistent Volume（永続ストレージ）」といった機能が必要になる理由です。
今回はここまでです。
次回は、IPアドレスがコロコロ変わるPodに対して、安定してアクセスするための仕組みである「Service」について学びます。