本記事は、非エンジニアである筆者がKubernetesを学習する中でのアウトプット（備忘録）です。
なお、記事の執筆にあたり生成AIも活用し調査のうえ記載していますが、万が一誤りがあればご指摘いただけると幸いです。
前回は、Kubernetes（K8s）の最小単位である「Pod」について学びました。
※前回の記事:「【備忘】非エンジニアによるKubernetes学習アウトプット②（Podについて）」
Podは「使い捨て」であり、再起動するたびにIPアドレス（住所）が変わってしまうという弱点がありました。
今回は、その弱点を克服し、常に同じ窓口でアクセスを受け付けてくれる「Service（サービス）」について学習した内容をアウトプットします。
1. Serviceとは何か？
一言で言うと、Serviceは「居場所が変わるPodたちの前に立つ、固定の受付窓口」です。
Podは頻繁に作り直されますが、Serviceは 固定のIPアドレスや名前（DNS） を提供し続けます。
前回、Podを「たい焼き屋の屋台」に例えました。
屋台（Pod）は場所を変えますが、
- お客さんが毎回探し回るのは大変
- 住所が変わるたびに案内を変えるのは非現実的
そこで、固定の注文カウンター（Service）を用意します。
お客さんはその窓口に行くだけで、Serviceが裏側のPodへ自動的に案内してくれます。
2. Serviceの種類と外への公開方法（メリット・デメリット）
Serviceには「どこまで通信を通すか」によって、いくつかのレベルがあります。また、より高度な交通整理を行う「Ingress」についても併せて解説します。
① ClusterIP（クラスター・アイピー）
-
役割：【社内用・内線電話】
- クラスターの「内部」からしか見えない固定IPを作る。
- メリット: 外から攻撃される心配がなく、セキュリティが非常に高い。
- デメリット: インターネットからは一切アクセスできない。WEBサイトの公開には使えない。
- 用途: データベースなど、外に見せる必要がない裏方のシステム用。
② NodePort（ノード・ポート）
-
役割：【特定ドアの開放】
- サーバー（Node）の特定のポート（例：30080番など）を無理やりこじ開けて、外からの通信を通します。
- メリット: クラウド以外の自社サーバー環境でも簡単に外部公開ができる。
-
デメリット:
- 使えるポート番号が「30000〜32767」と決まっていて変な番号になりがち。
- サーバーのIPが変わるとアクセスできなくなる。
- ポートを直接開けるので、セキュリティ管理が煩雑になる。
- 用途: 開発中のテストなど、一時的な確認用。
③ LoadBalancer（ロード・バランサー）
-
役割：【正面玄関の設置】
- クラウド（AWS等）と連携して、専用の「表口（ロードバランサー）」を自動作成します。
- メリット: 本番環境で最も一般的。**分かりやすい1つの入口（固定IP）**が手に入り、負荷分散も強力。
-
デメリット:
- コストがかかる（Serviceを1つ作るごとに、クラウド側の費用が発生する）。
- クラウド環境でないと使えない。
- 用途: 一般ユーザーに公開するWEBサービスのメイン窓口。
④ Ingress（イングレス）
Serviceとは別のリソースですが、セットで覚えるべき「窓口の親玉」です。
-
役割：【総合受付コンシェルジュ】
- 「URLのパス（/shop はこちら、/blog はこちら）」を見て、裏側の各Serviceへ振り分けます。
-
メリット:
- コスト削減: LoadBalancerを1つ用意するだけで、複数のServiceへ振り分けられる。
- 高機能: HTTPS（暗号化）の管理や、ドメイン名での振り分けが一括でできる。
-
デメリット:
- 設定が少し複雑。
- 「Ingress Controller」という、実際に動くためのエンジンを別途用意する必要がある。
- 用途: 大規模なサイトや、1つのドメインで複数の機能（ショップ、ブログ等）を動かす場合。
※Gemini作
3. Serviceの仕組み：「ラベル」で仲間を見つける
Serviceはどうやって「どのPodに案内すればいいか」を知っているのでしょうか？
その答えは、前回のPod編でも少し触れた「ラベル（名札）」です。
Serviceの設定に「app: my-web という名札のPodを案内してね」と書いておけば、Podが100個に増えても、Serviceは自動的にその名札を付けたPodだけを探し出して、通信を振り分けてくれます。
4. Serviceを作ってみる（実践）
実際に、名札（ラベル）を頼りに通信を繋ぐServiceを作ってみます。
① Podを作る（名札を付ける）
# nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: my-nginx # 「my-nginx」という名札
spec:
containers:
- name: nginx-container
image: nginx
② Serviceを作る（名札を指定する）
# nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
name: my-nginx-service
spec:
type: LoadBalancer # 外部公開用の「正面玄関」タイプ
selector:
app: my-nginx # この名札が付いたPodへ案内する！
ports:
- protocol: TCP
port: 80 # Service（窓口）が待ち構えるポート
targetPort: 80 # 実際のPod（中身）のポート
これを適用すると、インターネットからアクセスできる専用の入口（IPアドレス）が発行され、名札の付いたPodへと繋がるようになります。
まとめ
- Serviceは、Podの入れ替わりを隠してくれる「固定窓口」
- ClusterIP（内部）、NodePort（ポート開放）、LoadBalancer（クラウド玄関）の順に公開範囲が広がるが、コストやセキュリティのトレードオフがある
- Ingressはさらに高度な「コンシェルジュ」として、URLごとに振り分けを行う
- ラベル（名札）さえ合っていれば、Serviceは自動でPodを見つけてくれる
次回は、今回のようにPodを1つずつ作るのではなく、自動で増やしたり管理したりしてくれる「Deployment（デプロイメント）」について学びます。
⇒次回ブログ
【備忘】非エンジニアによるKubernetes学習アウトプット④（ReplicaSetとDeploymentについて）