// シス担のミカタ
Kubernetes

Service（Kubernetes） さーびす（くーばねてぃす）

KubernetesPodロードバランサーClusterIPNodePortエンドポイント
KubernetesのServiceって何？

簡単に言うとこんな感じ！

Kubernetesの中で動くアプリ（Pod）は、起動するたびにIPアドレスが変わっちゃうんだ。Serviceはその「変わるIPをひとつの固定窓口でまとめてくれる受付係」みたいなもの！外から「ここに来ればOK」って伝えられる安定した入口を作ってくれるんだよ。

Serviceとは

Kubernetesでは、アプリケーションは Pod（ポッド）と呼ばれる小さな実行単位で動きます。しかしPodはスケールアウト・障害回復などで頻繁に起動・停止し、そのたびに IPアドレスが変わるという性質を持っています。これでは「どこに通信すればいいか」がわからなくなってしまいます。

Serviceはこの問題を解決するKubernetesのリソースです。特定のラベルを持つPod群をまとめ、一つの固定された名前・IPアドレス（ClusterIP） を提供します。通信の送り先はServiceが自動的に振り分けるため、Podが何台に増えても、入れ替わっても、呼び出し側は同じ宛先に送るだけでOKです。

実務上は「システムの各部品（マイクロサービス）同士をつなぐ内線電話の交換機」と理解すると掴みやすいでしょう。ServiceなしにPod同士を直接つなごうとすると、IPが変わるたびに設定を書き直す必要が生じ、運用が破綻します。

Serviceの種類と役割

Serviceには用途に応じて複数の type（タイプ） があります。公開範囲と使いどころが異なるため、システム設計時に選び分けます。

type公開範囲典型的な使いどころ
ClusterIP（デフォルト）クラスター内部のみマイクロサービス同士の内部通信
NodePortクラスター外部（ノードのIPとポート経由）開発・検証環境での簡易公開
LoadBalancerクラスター外部（クラウドのLB経由）本番環境での外部公開
ExternalName外部DNSへの転送外部サービスをクラスター内名前で参照

覚え方：「内・外・LB・名前」

  • ClusterIP → クラスターの”内側”だけ
  • NodePort → ノード（サーバー）のポートから”外に出る”
  • LoadBalancer → クラウドのLBで本番公開
  • ExternalName → 外部URLに”名前だけ”つける

Serviceが通信を届ける仕組み

[クライアント（Pod or 外部）]
        │
        ▼
  Service（固定IP・固定名）
        │ kube-proxy がルーティング
        ├──▶ Pod A (192.168.x.1)
        ├──▶ Pod B (192.168.x.2)
        └──▶ Pod C (192.168.x.3)

Serviceは セレクター（selector） というラベル条件で対象Podを自動検出します。Podが増減しても、ラベルさえ合っていれば自動的にルーティング先に追加・削除されます（これを エンドポイント の動的管理と呼びます）。

歴史と背景

  • 2014年 — Kubernetesがオープンソース公開。当初からServiceリソースが設計に組み込まれていた。マイクロサービスアーキテクチャの普及と歩調を合わせて開発された
  • 2016年 — Kubernetes 1.2でIngressリソースが追加。HTTPルーティングはIngressに委ね、Serviceはレイヤ4（TCP/UDP）の安定した接続口として役割分担が明確化
  • 2018年頃 — クラウド各社（AWS EKS・GKE・AKS）がLoadBalancer typeを自社のLBサービスと自動連携させる機能を整備。本番運用での採用が急拡大
  • 2020年以降 — Serviceの上位互換として Gateway API の開発が進む。より柔軟なルーティング制御が可能になり、将来的にIngressとServiceを統合する方向で標準化が進行中

typeごとの通信経路

各typeでパケットがどう流れるかをイメージで整理します。

Serviceのtypeと通信経路 ClusterIP クラスター内部のみ Pod（呼び出し側） Service（ClusterIP） 対象Pod群 外部からは見えない 内部通信に最適 NodePort ノードIPで外部公開 外部クライアント ノードIP:NodePort （30000〜32767番台） 対象Pod群 開発・検証向け 本番には不向き LoadBalancer クラウドLB経由 外部クライアント クラウドLB （固定グローバルIP） 対象Pod群 本番公開に最適 クラウド費用が発生 内部専用 外部公開（簡易） 外部公開（本番）

ServiceとIngressの使い分け

Serviceだけでは「URLのパスに応じて異なるサービスへ振り分ける」といったHTTPレベルの制御はできません。その場合は Ingress（イングレス）を組み合わせます。

機能ServiceIngress
レイヤL4（TCP/UDP）L7（HTTP/HTTPS）
パスベースルーティング✗✓
TLS終端✗✓
外部公開LoadBalancer typeで可Ingress Controller経由

関連する規格・RFC

規格・ドキュメント内容
Kubernetes API Reference v1 / Servicespec.type やセレクター仕様の公式定義
Gateway API（SIG Network）Serviceの次世代となるL7ルーティングAPI仕様
RFC 793（TCP）ServiceがL4で扱うTCPプロトコルの基礎仕様

関連用語

  • Pod — Kubernetesの最小実行単位。Serviceのルーティング先となるコンテナの集まり