Service（サービス）

2025年11月6日

Service（サービス）

英語表記: Service

概要

Service（サービス）は、コンテナオーケストレーションシステムであるKubernetesにおいて、変動するPod群に対して安定したネットワークアクセスを提供するために欠かせない「オブジェクト」です。Podは障害やスケールアウトによって頻繁に生成・破棄され、そのIPアドレスも変わってしまうため、外部や他のマイクロサービスから直接アクセスするのは非常に困難です。Serviceは、この動的なPod群を抽象化し、固定的なアクセスポイント（永続的なIPアドレスやDNS名）として機能する、いわば「窓口」の役割を果たします。これにより、Kubernetesアーキテクチャ内で動作するアプリケーションは、背後のPodの状態を気にすることなく、安定して通信を行うことができるようになります。

詳細解説

Serviceは、Kubernetesアーキテクチャを理解する上で、PodやDeploymentと並んで非常に重要な概念です。私は、ServiceこそがKubernetesの「魔法」の鍵の一つだと感じています。

目的と背景：なぜServiceが必要なのか

Kubernetesにおいて、アプリケーションの実行単位であるPodは一時的な存在です。もしPodがクラッシュしたり、リソース効率のために再配置されたりすると、そのPodに割り当てられていたIPアドレスは失われてしまいます。これは、従来の固定サーバー環境とは大きく異なる点です。もしフロントエンドのPodがバックエンドのデータベースPodにアクセスしたい場合、バックエンドのIPアドレスが頻繁に変わってしまうと、通信が成り立ちません。

Serviceの主な目的は、この「揮発性」の問題を解決し、アプリケーションの疎結合性を高めることにあります。Serviceは特定のPod群を論理的にグループ化し、そのグループ全体に対して単一のエンドポイントを提供します。

動作原理：ラベルセレクタの活用

ServiceがどのPod群を対象とするかを決定するために使用するのが、「ラベルセレクタ（Label Selector）」という仕組みです。これはKubernetesオブジェクト共通の強力な機能です。

開発者がPodを作成する際、そのPodに「app: web」「tier: frontend」などのラベルを付与します。次にServiceオブジェクトを定義する際、このラベルセレクタを指定します。Serviceは、指定されたラベルを持つすべてのPodを自動的に検出リスト（エンドポイントリスト）に追加し、そのPod群へのトラフィックを負荷分散するようになります。

もしPodが新しく作成されてラベルが一致すれば自動的にServiceの配下に入り、Podが終了すれば自動的にリストから削除されます。この動的な管理こそが、Serviceの真骨頂であり、Kubernetesアーキテクチャの柔軟性を支えています。

主要なServiceタイプ

Serviceには、利用シーンに応じていくつかのタイプが用意されており、これらを使い分けることがKubernetes運用では必須となります。

ClusterIP（クラスターIP）:
- 最も一般的なデフォルトのタイプです。
- Kubernetesクラスター内部でのみアクセス可能な仮想IPアドレスを割り当てます。
- 主にクラスター内のマイクロサービス間通信（例：フロントエンドからバックエンドへのアクセス）に使用されます。外部からは直接アクセスできません。
NodePort（ノードポート）:
- クラスター内の各ノード（物理または仮想マシン）の特定のポートを開放し、外部からのアクセスを許可します。
- クライアントは、「どのノードのIPアドレス」と「指定されたポート番号」を使ってアクセスできます。
- 手軽に外部公開できますが、ポート番号がランダムに選ばれる（または指定される）ため、本番環境での外部公開にはあまり使われません。
LoadBalancer（ロードバランサー）:
- クラウド環境（AWS, GCP, Azureなど）でKubernetesを使用している場合に利用できるタイプです。
- Serviceを定義すると、クラウドプロバイダーの提供する外部ロードバランサーが自動的にプロビジョニングされ、トラフィックをクラスター内のノードへ分散します。
- 外部公開する際に最も一般的で推奨される方法です。
ExternalName（外部名）:
- Podではなく、クラスター外部のサービス（例：外部のデータベース）をServiceオブジェクトとして定義するために使用します。
- リダイレクト機能を提供し、プロキシは行いません。

これらのServiceタイプは、Kubernetesアーキテクチャにおいて、Podという「オブジェクト」群をいかに外部や内部に対して安全かつ効率的に公開するかを決定づける、非常に重要な設計要素となっています。

具体例・活用シーン

Serviceの役割を理解するために、具体的なアナロジーを交えて説明します。

アナロジー：企業の代表電話番号

Serviceの役割は、企業の代表電話番号に例えることができます。

Pod（社員）: 企業の中で実際に業務を処理する個々の社員（サーバー担当者、営業担当者など）です。社員は入れ替わったり（再起動）、増減したり（スケールアウト）します。個々の社員の直通電話番号（Pod IP）は変動する可能性があり、外部の人が覚えるのは不便です。
Service（代表電話番号）: 企業全体にかかってくる固定の代表電話番号です。この番号は変わりません。
ラベルセレクタ（内線ルール）: 代表電話にかかってきた顧客（トラフィック）が「営業に関する問い合わせです」と告げると、電話交換手（kube-proxy）はルールに基づき、現在空いている適切な営業担当者（Pod）に電話を転送します。

この仕組みのおかげで、顧客（クライアント）は、裏側で誰が対応しているか、社員が何人いるかを知る必要がなく、常に同じ代表番号にかけるだけで用事を済ませることができます。これが、Kubernetesアーキテクチャにおける安定した通信の基盤です。

活用シーンの例

マイクロサービス間の通信:
- ECサイトの「注文処理サービス」が、「在庫管理サービス」にアクセスする場合。注文処理サービスは、在庫管理サービスのClusterIP ServiceのDNS名を知っていれば、背後で在庫管理Podが何台動いていようと、IPが変わろうと、常に安定して通信ができます。
外部からのWebサイト公開:
- WebサイトのPod群を外部に公開する場合、LoadBalancerタイプのServiceを使用します。これにより、クラウドプロバイダーのロードバランサーを経由して、安全かつ分散された形でユーザーからのリクエストを受け付けることができます。
データベース接続の抽象化:
- アプリケーションが使用するデータベースがクラスター内部にある場合、そのデータベースPod群へのアクセスをClusterIP Serviceで抽象化しておけば、データベースの移行やメンテナンスでPodが再起動しても、アプリケーション側の接続設定を変更する必要がありません。

Serviceは単なるルーティング機能ではなく、Kubernetes環境における「疎結合」を実現するための設計思想そのものだと私は考えています。

資格試験向けチェックポイント

Kubernetesは、応用情報技術者試験や基本情報技術者試験の午後問題、特にクラウドや仮想化技術のトピックで重要度が増しています。ITパスポート試験ではまだ詳細な出題は少ないですが、コンテナ技術の基本的な概念として問われる可能性があります。

典型的な出題パターンと対策:

Serviceの役割に関する問題: 「PodのIPアドレスが頻繁に変わる問題を解決し、安定したアクセスを提供するKubernetesのオブジェクトは何か？」→ Serviceです。
Serviceタイプに関する選択問題: 「外部のクラウドロードバランサーと連携し、外部公開に利用されるServiceタイプはどれか？」→ LoadBalancerです。
PodとServiceの関係: ServiceとPodを紐づけるためのメカニズムは何か？→ ラベルセレクタです。

これらのポイントは、Kubernetesアーキテクチャにおける「オブジェクト」の連携を理解する上で非常に重要ですので、ぜひ覚えておいてください。