Serviceとは

kubernetes

全体マップ

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経由で可能にします。

しかし、これにはまだ問題があり、

  1. NodeIPを知らなければアクセスできない
  2. Node Portをしらないとアクセスできない。
kubectl expose pod helloworld \
--type NodePort --port 8080 \
--name helloworld-nodeport

LoadBalancer

クラウドプロバイダのL4ロードバランサーのDNSから、各ノードの特定ポートにRoutingしてPodにアクセスする。
しかしこれの問題は

  1. 一つのServiceごとに1つのLBが作られてしまいコスパが悪い
  2. 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についてまとめようと思います。

タイトルとURLをコピーしました