導入
前のレッスンの Service は、クラスタの内側からしか使えませんでした。ではブラウザなど外の世界から Pod へアクセスさせたいときはどうするのか。Service には公開範囲の異なる**種類（type）**があり、それを選ぶことで外部公開を実現します。代表的な3種を比べます。
説明
Service の spec.type には主に次の3つがあります。
apiVersion: v1
kind: Service
metadata:
name: web-svc
spec:
type: NodePort # ここで種類を選ぶ（既定は ClusterIP）
selector:
app: web
ports:
- port: 80
targetPort: 8080| 種類 | 公開範囲 | 仕組み | 主な用途 |
|---|---|---|---|
| ClusterIP（既定） | クラスタ内部のみ | 内部専用の仮想 IP を割り当てる | Pod 同士の内部通信 |
| NodePort | 外部から可 | 各ノードの特定ポート（例 30080）を開ける | 検証・小規模な外部公開 |
| LoadBalancer | 外部から可 | クラウドのロードバランサーを自動で用意し公開する | 本番の外部公開（クラウド上） |
NodePort は、クラスタを構成する各ノードの同じ番号のポートを開放し、そこへ来た通信を Service 経由で Pod へ流します。手軽ですが、利用者にノードの IP とポート番号を意識させるため、本番向きではありません。
LoadBalancer は、AWS や Google Cloud などクラウド環境で使うと、クラウド側の**ロードバランサー（負荷分散装置）**を自動的に1台立ち上げ、そこに外部からアクセス可能なアドレスを付けてくれます。外部公開の実運用ではこれが基本になります。
graph TB
User["外部の利用者"]
User -->|クラウドのLB経由| LB["Service type: LoadBalancer"]
User -->|ノードのポート:30080| NP["Service type: NodePort"]
LB --> Pod1["Pod"]
NP --> Pod2["Pod"]
Internal["内部のPod"] -->|内部だけ| CI["Service type: ClusterIP"]
CI --> Pod3["Pod"]
LoadBalancer はクラウドが対応していないと使えません。次のレッスンでは、HTTP なら LoadBalancer をいくつも立てずに済む、もっと賢い外部公開の入口 Ingress を紹介します。