本記事は、非エンジニアである筆者がKubernetesを学習する中でのアウトプット（備忘録）です。
なお、記事の執筆にあたり生成AIも活用し調査のうえ記載していますが、万が一誤りがあればご指摘いただけると幸いです。
前回は、屋台（Pod）の大事な売上やデータを守るための「Storage（貸し倉庫）」について学びました。
※前回の記事：「【備忘】非エンジニアによるKubernetes学習アウトプット⑤（Storageについて）」
ここまでで「屋台を自動で増やし（Deployment）」「窓口を設け（Service）」「データも守れる（Storage）」ようになりました。
かなり最強の屋台村になってきましたが、運営していくうちに新たな疑問が湧いてきました。
「屋台（Pod）同士って、どうやって連絡を取り合っているの？」
「そもそも、サーバー（コンピュータ）の中で通信するってどういうこと？」
今回は、Kubernetesの通信の仕組みを学ぶ前に、まずは基礎となる「Docker時代の通信（4つのモード）」をおさらいし、その上でKubernetesがどのように問題を解決しているのか（Ingress, Namespace）をまとめます。
1. 前提知識：Dockerの「4つの通信モード」
Kubernetesを使う前（Docker単体）の時代、コンテナが外の世界や他のコンテナと会話するには、以下の4つのモードを使い分ける必要がありました。
これを「住まいと電話」に例えて整理してみます。
① None Network（無人島モード）
- 状態: ネットワークケーブルが一切繋がっていない状態。
- イメージ: 「無人島にある独房」。
- 特徴: 外部とは一切連絡が取れません。最高のセキュリティですが、誰とも会話できないので、ただ計算するだけの処理などに使われます。
② Bridge Network（マンションの個室モード） ※デフォルト
- 状態: コンテナごとに独自のIP（内線番号）を持つが、外に出るにはホストの変換機能（NAT）を通る必要がある。
- イメージ: 「マンションの各部屋」。
- 特徴: 「101号室」「102号室」のように個別の番号を持ちます。マンション内（同じホスト内）の住民とは内線で話せますが、外の世界と話すには「管理人室（Bridge）」を経由して中継してもらう必要があります。一番よく使われる基本の形です。
③ Host Network（シェアハウスのリビングモード）
- 状態: コンテナがホスト（サーバー本体）のネットワークをそのまま共有する。
- イメージ: 「シェアハウスのリビング」。
- 特徴: 個室（独自のIP）を持たず、住人全員が同じ電話回線を共有します。「俺への電話はリビングの電話にかけて！」という状態です。通信は速いですが、「電話の取り合い（ポートの競合）」が起きやすく、管理が大変です。
④ Overlay Network（どこでもドアモード）
- 状態: 物理的に離れたサーバー（ホスト）同士を、仮想のトンネルで繋ぐ。
- イメージ: 「別のマンションへ繋がる地下トンネル」。
-
特徴: これが一番重要です！A棟のマンションとB棟のマンションを繋ぎ、あたかも「同じマンションの隣の部屋」であるかのように通信できるようにします。
Kubernetesでは、CNIプラグインと呼ばれる仕組みを通じて、このOverlay的な通信が実現されています。
だからこそ、複数のサーバーにまたがって屋台（Pod）を置けるのです。
※左から「None（孤立）」「Bridge（個室）」「Host（同居）」「Overlay（トンネル接続）」のイメージ
2. Kubernetes村の「3つの通信ルール」
Dockerの基礎（特にOverlayの概念）を踏まえた上で、Kubernetesの世界を見てみます。Kubernetesでは、複雑な設定をしなくても、以下のルールが最初から適用されています。
-
全ての屋台は「独自の住所（IP）」を持つ
（DockerのBridgeモードのように、全ての屋台に個別の番号が与えられます） -
屋台同士は「内線電話」で直接話せる
（DockerのOverlayモードのように、別のサーバーにある屋台とも、面倒な手続きなしで直接会話できます） -
「自分が見ている住所」と「相手から見える住所」は同じ
（なりすましや変換をせず、シンプルに繋がります）
つまり、Kubernetesは「最初から全店舗に直通電話が完備された、巨大なチェーン店ネットワーク」なのです。
3. Ingress：【総合案内所】（スマートな入り口）
内部の連絡網は完璧です。
では、外部のお客さんをどう案内しましょうか？
これまでは「Service」を使って、屋台ごとに窓口を作っていました。
しかし、屋台が50個に増えたら、窓口も電話番号も50個必要になり、お客さんは混乱してしまいます。
そこで登場するのが、Ingress（イングレス） です。
Ingressは、ショッピングモールの入り口にある「総合案内所（コンシェルジュ）」のような存在です。
Ingressのお仕事イメージ
- 入り口は一つだけ: お客さんは全員、まずこの「総合案内所」に来ます。（電話番号・IPは1つでOK！）
- 看板（URL）を見て誘導: コンシェルジュはお客さんの要望（URL）を見て、適切な窓口（Service）へ案内します。
- 「
/food（食事）に行きたい」 → 「はい、ラーメン屋の窓口（Service A）へどうぞ」 - 「
/drink（飲み物）に行きたい」 → 「では、カフェの窓口（Service B）へどうぞ」
これなら、裏側で屋台がいくら増減しても、お客さんは「いつもの入り口」さえ知っていれば迷いません。
4. Namespace：【フロア分け】（混雑と事故を防ぐ）
最後にもう一つ、覚えておきたい大事な概念が Namespace（ネームスペース） です。
これは、巨大なショッピングモールを「フロア」や「エリア」で区切る機能です。
もし、この屋台村（クラスター）を、「開発チーム」と「本番チーム」で共有していたらどうなるでしょうか？
開発チームが「テスト用の新しいラーメン屋（Pod）」を作ろうとしたとき、間違って「本番用のラーメン屋」を壊して上書きしてしまったら大惨事です。
そこで、Namespaceを使って空間を分けます。
- Namespace A（1階：本番フロア）: お客さんが入る本番エリア。ここには本番用の屋台しか置かない。
- Namespace B（2階：開発フロア）: 従業員専用の研究エリア。ここで何回屋台を爆発させても、1階には影響しない。
Namespaceのメリット
- 名前被りOK: 1階と2階なら、同じ「ラーメン屋（my-app）」という名前のお店があっても区別できます。
- 事故防止: 「2階の屋台を全部消して！」という命令を間違って出しても、1階の屋台は無事です。
まとめ
-
Dockerの通信:
- None: 孤立（無人島）
- Bridge: 個室（基本）
- Host: 同居（高速だが競合する）
- Overlay: トンネル接続（複数サーバーを繋ぐ）
-
Kubernetesの通信: CNIプラグインによって実現されており、Overlay的な考え方をベースに、Pod同士が自由に通信できる環境が提供されている
-
Ingress: 外部からのアクセスを一手に引き受ける「総合案内所」。URLを見て適切なServiceへ振り分ける
-
Namespace: クラスター内を論理的に区切る「フロア分け」。開発環境と本番環境を混ぜないために使う
これで、安全かつスムーズにお客さんを迎え入れる準備が整いました！