mhKubernetesではアプリケーションをPodとして動かしますが、Podは一時的な存在でIPアドレスも固定されません。
そのため、「ユーザーがアクセスできるようにする仕組み」が必要です。
それが Service と Ingress です。
🔹 Service：Podへの安定したアクセス口を提供する
Serviceは「動的なPodに対する固定的なアクセス手段」を提供します。
主な役割：
- PodのIPが変わっても、Service経由なら常にアクセスできる
- ロードバランシングを行い、複数Podに振り分ける
- クラスタ内/外からのアクセスを柔軟に制御できる
主な種類
| 種類 | 用途 |
|---|---|
| ClusterIP（デフォルト） | クラスタ内部でのみアクセス可能 |
| NodePort | ノードの固定ポートを公開し、外部アクセスを可能に |
| LoadBalancer | クラウド環境で外部LBを自動作成（GCP/AWSなど） |
| ExternalName | 外部ドメインに名前解決（少し特殊なケース） |
例：NodePort型 Service の定義
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: NodePort
selector:
app: my-app
ports:
- port: 80
targetPort: 8080
nodePort: 30080selector: ServiceがどのPodに流すかを決定（ラベルにより）
nodePort: ホストマシンのポートを開けて、外部からアクセスできるようにする
curl http://<NodeIP>:30080/🔸 Ingress：HTTP(S)向けの統合的なルーティング
Serviceはポート単位での公開ですが、複数のアプリを一つの入口でさばく場合、**Ingress（HTTPルーター）**が便利です。
Ingressは 「クラスタの玄関（HTTP用）」として、URLやホスト名ごとにリクエストをルーティングします。
イメージ図
ユーザー
↓
[Ingress] -- /api → Service A
↓
-- /web → Service B例：簡単なIngress定義（Nginx Ingress Controllerが前提）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: sample-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /app
pathType: Prefix
backend:
service:
name: my-service
port:
number: 80/appというパスへのアクセスがmy-serviceに流れます- Ingress単体では機能せず、Ingress Controller（Nginxなど）が必要
📊 ServiceとIngressの使い分け
| 特徴 | Service | Ingress |
|---|---|---|
| 対象プロトコル | TCP/UDP 全般 | HTTP/HTTPS専用 |
| アクセス単位 | ポート単位 | パス/ホスト単位 |
| ロードバランシング | 可能（Pod間） | 可能（複数サービスへ） |
| 外部公開の手段 | NodePort / LoadBalancerなど | 外部URLを使った柔軟なルーティング |
| 利用用途 | 単体アプリ・API公開など | 複数アプリの統合的な公開に最適 |
💡 まとめ
- Serviceは「Podに対する安定したアクセス口」
→ 単体でのアプリ公開、Pod管理には必須 - Ingressは「HTTPアクセスのルーター」
→ 1つのドメインで複数アプリを出し分けたいときに最適
