KubernetesのサービスとはPodに安定した接続先を与える仕組み
KubernetesのServiceとは、入れ替わるPodの集まりに、変わらない接続先を与える仕組みです。ClusterIP・NodePort・LoadBalancerの違い、セレクターとポートの書き方、公開範囲の注意点を公式ドキュメントから整理します。
公的機関・公式資料などの一次情報と照合して作成しています。このサイトについて
Kubernetesのサービスとは
Kubernetes の Service（サービス）とは、クラスター内で動いている1つ以上の Pod を、ネットワーク経由で使えるように公開する方法です。公式ドキュメントによれば、主な目的は、Pod の集まりが動的に変わる環境でも、安定した接続先を提供することです。
Pod は使い捨てで、Deployment などによって、作られては削除されます。そのたびに、IP アドレスも変わります。利用する側が、Pod の IP アドレスを直接指定していると、入れ替わった途端に、つながらなくなります。Service は、この問題を解決します。
基本（仕組みと種類）
Service は、ラベルの条件（セレクター）に合う Pod を見つけて、そこへ通信を振り分けます。Pod の集合が変わると、Service は自動で更新されると説明されています。Service には、クラスター内の仮想の IP アドレス（ClusterIP）が割り当てられ、Pod が入れ替わっても、この IP は変わりません。
定義の例です。
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
selector が対象の Pod を見分ける条件、port が Service が受け付けるポート、targetPort が Pod の中で受け付けるポートです。この例では、80番で受けた通信を、対象 Pod の9376番に届けます。
公式ドキュメントに記載されている、主な種類（type）です。
| 種類 | 内容 | 向いている場面 |
|---|---|---|
| ClusterIP（既定） | クラスターの内部だけで使える仮想 IP | クラスター内のサービス間の通信 |
| NodePort | 各ノードの特定のポートから、Service を公開する | 簡易な外部公開、検証 |
| LoadBalancer | クラウド事業者のロードバランサーを使って公開する | クラウド上で、外部に公開 |
| ExternalName | 外部の DNS 名に対応づける | 外部のサービスを、内部の名前で呼ぶ |
Kubernetesのサービスの具体例
3つの Pod で動く Web アプリがあるとします。
| 構成 | 結果 |
|---|---|
| Pod の IP アドレスを直接指定する | Pod が入れ替わると、接続先が無効になる |
| Service を作って、Service の名前や IP で接続する | Pod が入れ替わっても、同じ接続先で使える。3つの Pod に振り分けられる |
公開範囲の考え方の例です。
| 対象 | 推奨される種類の考え方 |
|---|---|
| データベース（内部だけで使う） | ClusterIP。外部に出さない |
| 内部の API | ClusterIP |
| 外部の利用者向けの Web | LoadBalancer など、外部へ公開できる種類（環境の方針に従う） |
| 検証用の簡易な公開 | NodePort（本番での使用は慎重に） |
内部だけで使うものを、外部に公開すると、攻撃の入口になります。既定の ClusterIP で足りるものは、そのままにするのが基本です。
接続先の数え方の例です。Pod が3つで、Service が1つなら、利用者が覚える接続先は1つです。Pod が10個に増えても、接続先は変わりません。Pod の数が増減しても、利用する側の設定を変えずに済むことが、Service の価値です。
Kubernetesのサービスの実践ステップ
- 通信する関係（誰が、どの Pod に接続するか）を書き出す。
- Pod に、目印となるラベルを付ける。
- Service を作り、selector をそのラベルに合わせる。
- port と targetPort を、取り違えないように設定する。
- クラスター内の別の Pod から、Service の名前で接続できるか確認する。
- 外部に公開する必要があるものだけ、公開用の種類を選ぶ。
- 定義ファイルを、バージョン管理に入れる。
Kubernetesのサービスの注意点
- selector とラベルが一致しないと、Service は、どの Pod にも届きません。つながらないときの最初の確認点です。
- port と targetPort を取り違えると、通信が届きません。
- 外部に公開する種類は、安全面の影響が大きいため、必要最小限にします。
- クラウドの LoadBalancer は、費用が発生する場合があります。公式の料金の案内を確認します。
- 仕様や推奨は更新されます。最新の公式ドキュメントを確認してください。
Kubernetesのサービスでよくあるミス
- ラベルの書き間違いで、Service が Pod を見つけられない。
- 内部のデータベースまで、外部に公開してしまう。
- Pod の IP アドレスを、設定に直接書く。
- port と targetPort の取り違え。
Kubernetesのサービスのチェックリスト
- 通信の関係を、書き出したか。
- selector と ラベルが一致しているか。
- 公開範囲が、必要最小限か。
- 接続は、IP ではなく Service を使っているか。
- 外部公開による費用や、安全面の影響を確認したか。
KubernetesのサービスのFAQ（よくある質問）
Q. Service と Deployment は、何が違いますか。
A. Deployment は Pod の数や更新を管理するもの、Service は、その Pod への安定した接続先を提供するものです。役割が異なり、組み合わせて使います。
Q. Service の IP アドレスは変わりますか。
A. 公式ドキュメントでは、Pod の集まりが変わっても、ClusterIP は変わらないと説明されています。
Q. 外部に公開するには、どの種類を使えばよいですか。
A. 環境（クラウドか自前か）と、要件によります。環境の方針と、公式ドキュメントを確認して選んでください。
筆者の見解（Kubernetesのサービス）
Service の設計で最も大切なのは、何を公開し、何を公開しないかを、先に決めておくことだと考えます。つながらない問題は、ラベルやポートの確認で直せますが、公開しすぎた設定は、気づかないまま、危険な状態を続けてしまうためです。私見では、既定の ClusterIP を基本にして、外部公開は必要な窓口だけを、意識して追加する運用が、安全です。
Kubernetesのサービスの関連項目
出典（一次情報）
本記事は一般的な情報の提供を目的としています。SaaS・ツールの機能・料金・無料枠・仕様は頻繁に更新されるため、最新の内容は各社の公式ページでご確認ください。契約・法務・セキュリティに関する判断は、専門家や社内の担当部門にご相談ください。「筆者の見解」は一つの考え方です。