ServiceとIngress — 変わるPodへ届く通信設計
Podは再作成・増減でIPが変わります。Serviceはその変化を吸収するクラスター内の窓口、IngressはHTTP(S)の外部入口を定義するルールです。
TL;DR
- ServiceはラベルセレクタでPod群を選び、安定した接続先を作る。
- ClusterIP・Headless・NodePort・LoadBalancerは到達させ方が違う。
- Ingressは単体で通信を処理せず、Ingress Controllerが実装を担う。
01ServiceはPodの入れ替わりを隠す
Serviceが複数Podへ振り分け、Pod入れ替わりを吸収する図
Serviceはラベルで対象Podを選び、クラスター内で安定した名前と仮想IPを提供します。クライアントが特定のPod IPを知る必要はありません。
押さえること：ServiceはラベルセレクタでPod群を選び、安定した接続先を作る。
02Serviceの種類は到達経路で選ぶ
4種類のServiceを内側から外側へ並べた通信経路
ClusterIPは内部公開、Headlessは個々のPodを直接見つけたい用途、NodePortはNodeのポートを開く方式、LoadBalancerはクラウド連携で外部ロードバランサを作る方式です。用途と公開範囲で選びます。
押さえること：ClusterIP・Headless・NodePort・LoadBalancerは到達させ方が違う。
03IngressはHTTPの入口ルール
利用者→Ingress Controller→Ingress規則→Service→Podの流れ
Ingressにはホスト名やパスごとにどのServiceへ送るかを定義します。実際に外部通信を受けるのはIngress Controllerであり、Ingressリソースだけでは公開されません。
押さえること：Ingressは単体で通信を処理せず、Ingress Controllerが実装を担う。
結論
- ServiceはラベルセレクタでPod群を選び、安定した接続先を作る。
- ClusterIP・Headless・NodePort・LoadBalancerは到達させ方が違う。
- Ingressは単体で通信を処理せず、Ingress Controllerが実装を担う。