Linux の namespace となんやねん？ k8s の Namespace と何が違うんや？

俺の最初の疑問

手元に、こういう学習スクリプトがあった。「Phase 0」と名前が付いている。

sudo ip netns add red
sudo ip netns add blue
# このあと red と blue に veth を挿して IP を振り、ping で疎通を確認するところまで続く…

ip netns で red と blue という「仮想の mini マシンみたいなもん」を 2 つ作っている。俺はネットワークの技術サポートをやっていて (Azure の Application Gateway / Load Balancer / VNet あたりが守備範囲)、最近 k8s をかじり始めたところ。

この namespace という言葉を見て、知りたいことが 2 つに絞れた。今回はこの 2 つだけを潰す。

1. そもそも Linux の namespace とはなんぞや？
2. k8s にも namespace が出てくるけど、あれと何が違うんや？

まず一言でいうと

namespace ＝ Linux カーネルが「あるプロセスから、どのリソースが見えるか」を仕切る仕組み。

ポイントは「隔離された箱を作る」ではなく、プロセスごとに見える景色 (ビュー) を制限するという発想だった。リソースそのものを複製するんやなくて、「お前にはこのグループの IF とルーティングテーブルしか見えへんよ」とカーネルが視界を切り分けている。

そして namespace は 1 種類ではない。隔離する対象ごとに種類が分かれている (network・PID・mount・UTS・IPC・user・cgroup・time …。詳しくは後述)。今回の ip netns add red では、そのうちの 1 つである network 版 namespace (netns) を 1 個作ること。新品の netns は最初 lo(しかも down) だけの、ネットワーク的に孤立した状態だった。

何と比べるとわかるか (VM とくらべる)

「隔離環境」と言うと VM を思い浮かべがちやけど、そこと比べると概念が一気にスッキリした。

VM はカーネルごと丸ごと複製する。namespace はカーネル 1 個を共有したまま、見え方だけを割る。だから軽くて、起動が一瞬。コンテナ (Docker など) が VM より速くて軽いのは、ここが根っこだった。

そして コンテナ ＝ namespace (視界の隔離) + cgroup (CPU / メモリ等の量の制限) + ファイルシステム。魔法の箱やなくて、この 3 つを束ねた呼び名にすぎない。

で、空の箱に何が嬉しいのか (＝コンテナの正体)

ここがいちばん引っかかった。順を追うと、嬉しさは最後の一段で初めて出る。

• sudo ip netns add red ── red という名前の箱 (netns) ができる。ただし、これはただの空箱ができただけで、まだ何も嬉しくない。
• 箱に IP アドレスを振る ── 箱が IP 通信できるようになる。でもそれをやっても「箱が IP 通信可能になっただけ」で、そんなに嬉しくない。
• 箱の上でサービスを動かす ── ここで初めて嬉しい。クライアントからの要求に応答を返すアプリ (Web サーバなど) を、その箱の中で動かせる。

これがコンテナの正体や。 そして箱 (namespace) は VM とちがってカーネルを複製しない (前の図のとおり)。だから 1 個のカーネルの上で、この箱を何個も並べて、それぞれ別のサービスを動かせる ── VM を何台も立てる重さ無しで、同居と隔離を両立できる。軽量で嬉しい、というのはここだった。

k8s の Namespace は、これと完全に別物

ここが 2 つ目のコアであり、いちばん引っかかったところ。掘っている途中で「k8s にも namespace って出てくるけど同じか？」と思った。**結論、名前が同じだけで完全に別物。**多くの人がハマるポイントらしい。

• ① Linux namespace (この記事でずっと話してきたやつ)── カーネルレベルの隔離技術。network / PID / mount などでリソースの視界を仕切る、ip netns の世界。
• ② Kubernetes Namespace ── クラスタの中を論理的に区切る整理用の箱。1 つのクラスタを dev / production / kube-system のように名前で分けて、リソースをグループ管理する。名前の衝突防止・アクセス権限の分離・リソース上限の設定をする。

②はカーネルの隔離とは関係ない。プログラミング言語の名前空間 (C++ の namespace、Python のモジュール) と同じ感覚の 論理的な仕切りにすぎなかった。

	① Linux namespace	② Kubernetes Namespace
層	カーネル (低レイヤー)	Kubernetes (高レイヤー)
目的	リソースの隔離	論理的な整理・区分
例えるなら	部屋の壁 (物理的に遮断)	書類のフォルダ分け (ラベル)
関連語	ip netns, veth, cgroup	Pod, ラベル, RBAC

混乱しやすいポイント

ややこしいのは、この 2 つが実際には入れ子で動いていること。k8s の production Namespace (②) の中で Pod が動くと、その Pod のコンテナは裏で Linux namespace (①) で隔離されている。「②の箱の中で①が働いている」。

同じ単語が層をまたいで出てくるから、余計に混乱しやすい。逆に言うと、namespace という単語自体が IT 業界で「区切られた領域」という意味で広く使い回されているので、出てきた文脈で①なのか②なのか見分けるしかない。引っかかったのは、むしろ概念をちゃんと区別できている証拠だった。

たとえ話

namespace は「視界を仕切るパーテーション」。VM は「家ごと建てる」。

VM は、隣に住みたい人のために家 (OS) を丸ごともう一軒建てる。土地も基礎も水道も全部別。だから重いし、建つのに時間がかかる。

namespace は、一軒の家 (1 つのカーネル) の中にパーテーションを立てて「あなたからはこの部屋とこの窓しか見えません」とビューを切る。家は 1 軒のままなので、パーテーションを増やすのは一瞬。同じ家の別の部屋にいる住人どうしは、お互いの存在を基本知らない (同じ 10.0.0.1 を名乗っても気づかない)。

そして k8s の Namespace (②) は、家の壁とは別の話。書類棚のフォルダ分けにすぎない。「この書類は production フォルダ、こっちは dev フォルダ」と名前で整理しているだけで、部屋の壁 (①) とはレイヤーが違う。

出てきた言葉の変換表

出てくる言葉	つまり何の話？
namespace (Linux)	カーネルがプロセスに見せる「景色」を仕切る隔離の仕組み。コンテナの土台
network namespace / netns	その network 版。IF・ルーティング・ポートを丸ごと別にする。≒ VRF の上位互換
cgroup	CPU / メモリ等の「量」を制限する仕組み。namespace (視界) とセットでコンテナを作る
コンテナ	namespace + cgroup + ファイルシステム を束ねた呼び名。魔法の箱ではない
Kubernetes Namespace	(①とは別物) クラスタを論理的に区切る整理用の箱。フォルダ・ラベルに近い

深掘りメニュー 次におすすめのトピック

• veth と bridge で「線」を引く ── 今回は namespace の概念に絞ったが、ip netns で作った red / blue を実際に繋ぐのが veth (仮想 LAN ケーブル＝vNIC のペア) と bridge (仮想スイッチ ≒ Subnet のスイッチ役)。手で配線すると、コンテナのネットワークの底が見える。次はこれ。
• Pod の IP が 1 個しかない理由 ── namespace が分かった今なら回収できる。「Pod ＝ 複数コンテナで network namespace を 1 個共有する単位」を pause コンテナで追うと、k8s の中身が一気に繋がる。
• cgroup を手で触る ── namespace (視界) の相方。CPU / メモリの「量」を制限する側を ip netns 同様に生で 1 回触ると、「コンテナ ＝ namespace + cgroup」の残り半分が体で分かる。
• PID namespace / user namespace の実験 ── 「中では PID 1」「中では root でも外では一般ユーザー」という挙動を手で確かめると、network 以外の namespace の感覚が掴める。