この記事について
Kubernetes の Service は、使い方は分かるけど実体がつかみずらく、漠然と使われることの多いリソースと思う。そこで Service の実体を整理してみる。
Service の大雑把な理解
まず Kubernetes から離れて、複数台の Web サーバーがあってそれを外部ネットワークに公開したいという場面を考える。
この時、大体以下の考慮が必要になる。
- Web サーバーへのアクセスを負荷分散させたい
- Web サーバーの数が増減することがある
- Web サーバーのIPが変わることがある(サーバーが壊れた等)
- Web サーバーで障害が起きたら、それにはリクエストを転送しないようにする
- Web サーバーには、IP アドレスだけでなく名前でアクセスできるようにしたい
そこで以下のように前段にロードバランサーを置くことが一般的。
このロードバランサーは Web サーバーの増減や IP 変更の追跡、そして死活を把握する必要がある。
これを Kubernetes に置き換えると下図のような感じになる。まず Pod が接続されてるのが Pod Network(または Cluster Network)、Load Balancer の外側が Service Network。そして、図のLoad Balancer には DNS名と IP アドレス(ClusterIPと呼ばれる)が自動で割り当てられる。
そして、赤枠の部分を自動で構成してくれるのが Service というリソースになる。手動で構成しようとすると相当大変なので、これを一発で自動構成してくれる Service リソースはとてもありがたいと言える。
なお、上図の赤枠部分をもう少しちゃんと書くと、Service と Endpoints(または EndpoitSlice) というリソースで役割分担している。Endpoints(または EndpoitSlice) は、Service を作成するとそのペアとして自動で作成される。
何が分かりずらいの？
概念的にはそれほど難しくなさそうだが、では Service がなぜ漠然とするかというと、図に現れたネットワークやロードバランサー、IP 等の実体が何か、それを誰がどこでどう実現してるのか、という Kubernetes 上での実体が掴みづらいところと思う。
それらの実体や構成を行う登場人物を紐解いてみる。
Kubernetes のコンポーネントについて
実体を紐解くにあたって、どうしても Kubernetes を構成するコンポの知識が必要になる。記事の中にも説明を記載するが、例えば公式サイトにも Kubernetesのコンポーネント のページがあるので、必要に応じて参照いただければ。