Kubernetes Nginx コンテナと Service ClusterIP – クラスタ内部通信の入口を作る

この記事では、Nginx の Deployment に ClusterIP Service を作成し、クラスタ内部から Service 名でアクセスできることを確認します。

ClusterIP は Kubernetes Service の基本です。Pod に直接アクセスするのではなく、Service を安定した入口として使うことで、Pod が再作成されても同じ名前でアクセスできるようになります。

ClusterIP の位置づけ

ClusterIP はクラスタ内部向けの Service です。外部公開を目的にするものではなく、Pod 間通信やアプリケーション内部の接続先として使います。

• Pod の IP アドレスは作り直しで変わる
• Service は label selector で対象 Pod を束ねる
• Service 名はクラスタ DNS で名前解決できる
• ClusterIP はクラスタ内部からのみ使う入口になる

Namespace と Deployment を作成する

まず確認用の Namespace を作成し、その中に Nginx の Deployment を作成します。Service の selector と対応するように、Pod には app: nginx の label を付けます。

kubectl create namespace nginx-clusterip-ns

kubectl -n nginx-clusterip-ns apply -f - <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80
EOF

ClusterIP Service を作成する

次に ClusterIP の Service を作成します。selector が Deployment の Pod label と一致していることが重要です。

kubectl -n nginx-clusterip-ns apply -f - <<'EOF'
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
    - name: http
      port: 80
      targetPort: 80
EOF

Service と Endpoints を確認する

Service が作成されても、selector が間違っていると Pod にはつながりません。Service と Endpoints を合わせて確認します。

kubectl -n nginx-clusterip-ns get deploy,pod,svc,endpoints -o wide
kubectl -n nginx-clusterip-ns describe svc nginx-svc
kubectl -n nginx-clusterip-ns get endpoints nginx-svc -o yaml

Endpoints に Pod の IP アドレスが入っていれば、Service が対象 Pod を正しく選択できています。Endpoints が空の場合は、Service の selector と Pod の label を確認します。

クラスタ内部から接続確認する

ClusterIP は外部から直接アクセスするものではないため、クラスタ内部に一時的な curl Pod を起動して確認します。

kubectl -n nginx-clusterip-ns run curl   --rm -it   --image=curlimages/curl   --restart=Never   -- curl -I http://nginx-svc/

同じ Namespace 内であれば、Service 名の nginx-svc だけで名前解決できます。

FQDN で確認する

Namespace をまたいでアクセスする場合や、名前解決の仕組みを確認したい場合は、Service の FQDN を使います。

kubectl -n nginx-clusterip-ns run curl   --rm -it   --image=curlimages/curl   --restart=Never   -- curl -I http://nginx-svc.nginx-clusterip-ns.svc.cluster.local/

Service の一般的な FQDN は service-name.namespace.svc.cluster.local です。クラスタの DNS 設定によって suffix は異なる場合があります。

切り分けの見る順番

ClusterIP で疎通できない場合は、Pod、Service、Endpoints、DNS の順に見ると整理しやすいです。

• Pod が Running になっているか
• Pod の label が Service の selector と一致しているか
• Endpoints に Pod の IP アドレスが入っているか
• curl Pod から Service 名を名前解決できるか
• Service の port と targetPort が正しいか

後片付け

確認が終わったら、Namespace ごと削除します。

kubectl delete namespace nginx-clusterip-ns

関連する記事

Service の公開範囲を広げる流れは、ClusterIP、NodePort、LoadBalancer の順に見ると理解しやすくなります。

• Kubernetes Nginx コンテナの実行
• Kubernetes Nginx コンテナと Service NodePort
• Kubernetes Nginx コンテナと Service LoadBalancer – MetalLB で外部 IP を確認する
• Kubernetes MetalLB の導入 – LoadBalancer Service をオンプレ環境で成立させる
• Kubernetes 設定マニュアル – オンプレ環境でクラスタ運用を整理する

まとめ

ClusterIP は、Kubernetes クラスタ内部で Service 名を入口にして Pod へアクセスするための基本的な Service です。

Pod の IP アドレスは作り直しで変わりますが、Service を使えば、label selector に一致する Pod へ安定して接続できます。まず ClusterIP の動きを理解しておくと、NodePort や LoadBalancer、MetalLB の役割も見えやすくなります。

Related posts:

Kubernetes Nginx コンテナと Service NodePort – Node のポート経由でアクセスする Kubernetes Nginx コンテナと Service LoadBalancer – MetalLB で外部 IP を確認する Kubernetes Nginx コンテナの実行 – Deployment で Pod を管理する Kubernetes MetalLB の導入 – LoadBalancer Service をオンプレ環境で成立させる Kubernetes MetalLB を Helm で導入する – オンプレ環境で LoadBalancer Service を使う Ubuntu 22.04 Docker で Nginx コンテナを外部公開する Podman Redmine 構築 – MySQL と Nginx を Pod でまとめる Ubuntu 26.04 Nginx の基本設定 netplan apply で ovsdb-server.service is not running と表示される原因 – Open vSwitch を使わない環境での考え方 Kubernetes kubectlの導入 Kubernetes クラスター構築 – kubeadm で controlPlaneEndpoint と CNI を整理する kubernetes diskfullでpodが起動しなくなった