Kubernetesクラスタをインターネットからアクセス可能にするには、主に以下の2つの方法があります：
- Layer 4（L4）: LoadBalancer Service
- Layer 7（L7）: Ingress Controller
本記事では、それぞれの仕組み・特徴・違いについて、できるだけ分かりやすく解説します。
🔹 LoadBalancerタイプのService（第4層）
🧠 イメージ：サービスごとに「個別の正門」を作る
インターネットからのリクエストは、クラウドが自動作成するロードバランサーを通じて、Kubernetesノードに届き、さらにPodに転送されます。
🔁 データフロー：
-
type: LoadBalancerのServiceを作成 - クラウドプロバイダーがL4ロードバランサーを作成
- 外部からのリクエストがLBに届く
- LBはノード（VM）にリクエストを転送
- ノード上のiptablesがPodへルーティング
- Podからのレスポンスは、iptablesとconntrackによりLBのIPに書き換えられ、クライアントに返される
✅ メリット・デメリット
| メリット | デメリット |
|---|---|
| シンプルで設定が簡単 | サービスごとにLBが必要でコスト高 |
| L4レベルでTCP/UDPに対応 | パスベースのルーティング不可 |
🔸 Ingress Controller（第7層）
🧠 イメージ：複数サービスをまとめる「一つの玄関」
Ingress Controllerは、HTTP/HTTPSリクエストをルーティングするアプリケーションレベルのゲートウェイです。リクエストのパスやホスト名によって適切なServiceに転送します。
🔁 データフロー（例：AWS ALB Ingress Controller）：
- Ingress ControllerがIngressリソースを監視
- マッチする設定がある場合、ALBを作成
- ALBのListenerがHTTPリクエストを受信
- Pathに応じてTarget Groupに振り分け
- Target Group経由でノードのNodePortに到達
- ノード→Pod→レスポンス返却（LBのIPに書き換え）
✅ メリット・デメリット
| メリット | デメリット |
|---|---|
| 1つのLBで複数サービス公開可能 | セットアップがやや複雑 |
| パス/ホスト単位のルーティング可 | L4には不向き（HTTP/HTTPSのみ） |
🆚 LoadBalancer vs Ingress 比較表
| 項目 | LoadBalancer | Ingress Controller |
|---|---|---|
| 対応レイヤー | L4（TCP/UDP） | L7（HTTP/HTTPS） |
| LB数 | サービスごとに必要 | 一つで複数サービス対応可 |
| コスト | 高い（LBが複数） | 比較的安い |
| 適用場面 | 単体サービスを公開 | 複数サービスを一括管理・公開 |
| 柔軟性 | 少ない | 高い（パス・ホスト名対応） |
📝 まとめ
- 単純にサービスを公開したい → LoadBalancer
- ドメインやパスで複数サービスを整理して公開したい → Ingress Controller
Kubernetesのネットワーク構成は環境（クラウド or オンプレ、CNIプラグイン）により異なることもあるため、構成前にしっかりと設計・検証を行いましょう。