1. はじめに
- 前回の続き
- 本日は実運用を見据えた「YAML（マニフェスト）管理」への移行と、実際に稼働しているPodの内部構造を調査した結果をまとめます(GeminiにおすすめされたのでYAMLの検証をしてみました)
2. 【検証】マニフェスト（YAML）管理への移行と「状態」の定義
- 手動での kubectl create をなんとなく理解したので、YAMLによる宣言型管理を検証します
マニフェストの中身を解剖する
- 任意のディレクトリにhello-node.yaml を作成
- Geminiの出力どおりにyamlファイルを更新します
# 1. 管理職（Deployment）の設定
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-node-manifest
spec:
replicas: 2 # せっかくなのでPodを2つに増やしてみましょう
selector:
matchLabels:
app: hello-node
template:
metadata:
labels:
app: hello-node
spec:
containers:
- name: hello-node
image: registry.k8s.io/e2e-test-images/agnhost:2.39
args: ["netexec", "--http-port=8080"]
ports:
- containerPort: 8080
---
# 2. 受付窓口（Service）の設定
apiVersion: v1
kind: Service
metadata:
name: hello-node-service
spec:
type: LoadBalancer
ports:
- port: 8080
targetPort: 8080
nodePort: 30001 # ポート番号を固定してあげましょう
selector:
app: hello-node
- 作成したyamlを指定してapplyを実行します
tak@tak-MacBookAir:~$ kubectl apply -f hello-node.yaml
deployment.apps/hello-node-manifest created
service/hello-node-service created
tak@tak-MacBookAir:~$
tak@tak-MacBookAir:~$
tak@tak-MacBookAir:~$ kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-node-585ccb7764-hqwc9 1/1 Running 1 (20h ago) 20h #前回つくったやつ
hello-node-585ccb7764-mlb24 1/1 Running 1 (20h ago) 20h #前回つくったやつ
hello-node-585ccb7764-r26wn 1/1 Running 1 (20h ago) 21h #前回つくったやつ
hello-node-manifest-547866896f-bvhvt 1/1 Running 0 18s #今回作ったやつ
hello-node-manifest-547866896f-jvvn7 1/1 Running 0 18s #今回作ったやつ
tak@tak-MacBookAir:~$
agnhostとは？
- ちなみに前回の記事でもagnhostを使ってましたがこれがなにかわかってなかったのでGeminiに解説してもらいました。
わたし「agnhost:2.39 の中身が気になる。ツールってなに？」
Gemmy「その好奇心、素晴らしいですね。agnhost は、一言で言えば 「Kubernetesの開発者たちが、テストのために作った『何でも屋』ツール」 です。
普通のアプリ（WordPressやNGINX）は一つの機能しかありませんが、こいつは「ネットワークのテストに便利な機能」を詰め合わせたスイスアーミーナイフのような存在です。
- agnhost の正体
名前の由来は "Agostic Host"。特定の機能に依存しない（不可知な）ホスト、という意味です。
Kubernetesのソースコード（GitHub）の中に含まれている「e2e（エンドツーエンド）テスト」用のツールで、K8s自体が正しく動いているかを確認するために使われます。- 今回実行した netexec とは？
あなたがYAMLの args に書いた netexec は、agnhost が持っている「機能の一つ」です。
役割: 指定されたポート（今回は8080）でHTTPサーバーを立ち上げる。
動作: ブラウザでアクセスすると、自分のホスト名や現在時刻を返す。
検証に最適な理由: 非常に軽量で、かつ「確かにPodまで通信が届いているか」を視覚的に確認できるからです。- 他にどんなことができるのか？
実は agnhost は、引数（args）を変えるだけで全く別の顔を見せます。
dns-lookup: 他のサービスの名前解決ができるかテストする。
port-forward: ポート転送のテストをする。
connect: 他のPodに接続できるか試す。
- なるほど、わたしはこれを理解してなかったのでk8sの仕組みが腹落ちしていなかったわけだ。
3. 【深掘り】kubectl exec で暴く Pod の正体
- 「Podの中ってどうなってるの？」が疑問だったので、Gemmyに聞いたらexecコマンドを教えてくれました
- node名とshを指定してexecするとpod内で起動するOS領域にアクセスできました
tak@tak-MacBookAir:~$ kubectl exec -it hello-node-manifest-547866896f-bvhvt -- /bin/sh
/ #
/ #
/ #
/ # ls -l
total 83956
-rwxr-xr-x 1 root root 42009211 May 25 2022 agnhost
lrwxrwxrwx 1 root root 7 May 25 2022 agnhost-2 -> agnhost
drwxr-xr-x 1 root root 4096 May 25 2022 bin
-rwxrwxr-x 1 1000 1000 43888256 Aug 14 2019 coredns
drwxr-xr-x 5 root root 360 Mar 17 05:43 dev
drwxr-xr-x 1 root root 4096 Mar 17 05:43 etc
drwxr-xr-x 2 root root 4096 Apr 4 2022 home
~後略~
/ #
/ #
/ # whoami
root
/ #
/ # cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 142
model name : Intel(R) Core(TM) i5-8210Y CPU @ 1.60GHz #cpuはローカルを間借りしている…!!
~後略~
検証から得られた発見
この結果から、以下の事実が裏付けられました。
- 仮想マシン（VM）との違い: VMがハードウェアをシミュレートするのに対し、コンテナはホストの「カーネル」や「CPU」を直接共有している。
- 実体: コンテナとは、ホストOS上で「あたかも独立した環境に見えるよう、厳重に壁を立てられたプロセス」に過ぎない。
- 「自分の部屋にいるつもりが、実は大家（ホストOS）の心臓の音をそのまま聞いている」ような、コンテナ特有の 居候構造 をデータとして確認できたことが今回の最大の収穫です。
4. 考察：コンテナとホストのリソース共有
- Pod 内で CPU 情報を確認したところ、ホストマシン（MacBook Air）の Core i5 情報がそのまま出力された
- ↑のおかげで、「Podとは？」が理解できたし「その上で何が動いてらっしゃるの？」までが綺麗につながった(ローカルホストのCPUを間借りして、k8sのテストツール(ahnhost)が起動している)
5. まとめ
- YAML管理に移行することで、インフラの状態を「コード」として定義できるようになった。
- Pod の内部を覗くことで、K8s が「プロセスの集合体」を効率よく管理する仕組みであることを体感できた。
- 次回はGemmyに相談しながら実際のコンテナの活用事例を考えてみたいと思います。