全体マップ
Serviceは全体マップのPodの集合体の上部に位置するNodePortと記載のある部分です。
Serviceとは
Podをクラスター内外に公開する静的IPを持ったL4ロードバランサーです。
Podやコンテナの命は儚い。
ちょうどこんな感じで、要するに、いつくたばるかわからない。
つまり、いつIPが変化するかわかりません。
そこでそれらのIPをバンドルして抽象化する何かが必要。
その何かががServiceリソースです。
Serviceの3つのタイプ
ClusterIP
ClusterIPは文字とおりCluster内部にPodIPを抽象化して静的IPアドレスを公開します。
しかし、これはあくまでCluster内部でのPodIPの抽象化やロードバランシングのためでありこれだけではCluster外部にはまだ公開されない。
kubectl expose pod helloworld \
--type ClusterIP --port 8080 \
--name helloworld-clusterip
NodePort
ClusterIPでは不可能だったクラスタ外部へのPodの公開をNodeIPとNodePort経由で可能にします。
しかし、これにはまだ問題があり、
- NodeIPを知らなければアクセスできない
- Node Portをしらないとアクセスできない。
kubectl expose pod helloworld \
--type NodePort --port 8080 \
--name helloworld-nodeport
LoadBalancer
クラウドプロバイダのL4ロードバランサーのDNSから、各ノードの特定ポートにRoutingしてPodにアクセスする。
しかしこれの問題は
- 一つのServiceごとに1つのLBが作られてしまいコスパが悪い
- L4LBなのでTCP/IPまでしかわかってないので、L7のhttpホストやパス、headerでのLB振り分けができない。
kubectl expose pod helloworld \
--type LoadBalancer --port 8080 \
--name helloworld-loadbalancer
まとめ
今回紹介した3つのタイプのServiceのうち、実は上記で説明した問題点にあるように、LoadBalancerタイプはレイヤー4しか理解出来ない事と、一つのサービス公開ごとに1つのロードバランサーが形成されると、単純に財布に優しくないことから本番運用では使いません。
その代わりにレイヤー7ロードバランシングが可能な、Serviceをまとめ上げることのできるLBであるIngressリソースというものを使用します。
次回はそのIngressについてまとめようと思います。