Kubernetes Nginx コンテナと Service LoadBalancer – MetalLB で外部 IP を確認する

この記事では、Nginx の Deployment と type: LoadBalancer の Service を作成し、MetalLB によって外部 IP アドレスが割り当てられることを確認します。

MetalLB の導入そのものではなく、導入後に Kubernetes の Service と外部ネットワークがどのようにつながるかを見るための確認用記事です。

前提

この手順は、Kubernetes クラスタに MetalLB が導入済みで、IPAddressPool と L2Advertisement などの広告設定が済んでいることを前提にします。

• MetalLB が導入済みであること
• Service に割り当てる外部 IP アドレス範囲が定義済みであること
• クライアントから MetalLB のアドレス範囲へ到達できること
• 確認用の Nginx を作成できる Kubernetes 権限があること

Namespace と Deployment を作成する

まず確認用の Namespace を作成し、その中に Nginx の Deployment を作成します。ここでは Pod を 2 個起動し、Service から label selector で束ねられるようにします。

kubectl create namespace nginx-loadbalancer-ns

kubectl -n nginx-loadbalancer-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

LoadBalancer Service を作成する

次に、Nginx Deployment に向けた type: LoadBalancer の Service を作成します。MetalLB が正常に動作していれば、この Service に外部 IP アドレスが割り当てられます。

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

Service と Pod の状態を確認する

kubectl get service の EXTERNAL-IP にアドレスが表示されていれば、MetalLB による IP アドレス割り当ては成立しています。

kubectl -n nginx-loadbalancer-ns get deploy,pod,svc -o wide
kubectl -n nginx-loadbalancer-ns describe svc nginx-svc

EXTERNAL-IP が <pending> のままの場合は、MetalLB の Pod、IPAddressPool、L2Advertisement、Service のイベントを確認します。

外部 IP アドレスへ接続する

外部 IP アドレスが割り当てられたら、クライアントから HTTP で接続します。クラスタ外から疎通できる場合、MetalLB、Service、Pod の一連の経路が成立しています。

kubectl -n nginx-loadbalancer-ns get svc nginx-svc

VIP=$(kubectl -n nginx-loadbalancer-ns get svc nginx-svc -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
curl -I http://${VIP}/

うまく接続できない場合の見る順番

LoadBalancer Service は複数の要素が関係するため、疎通できない場合は順番に切り分けます。最初からネットワーク全体を疑うより、Kubernetes 内部から外側へ広げて見る方が見通しやすいです。

• Deployment の Pod が起動しているか
• Service の selector が Pod の label と一致しているか
• Service に EXTERNAL-IP が割り当てられているか
• MetalLB の controller / speaker が正常に動作しているか
• MetalLB のアドレス範囲と既存ネットワークが衝突していないか
• クライアントから Service の外部 IP アドレスへ到達できるか

後片付け

確認が終わったら、作成した Namespace を削除します。Namespace ごと削除すれば、Deployment と Service もまとめて削除されます。

kubectl delete namespace nginx-loadbalancer-ns

まとめ

Nginx と LoadBalancer Service を使うと、MetalLB が外部 IP アドレスを Service に割り当て、クラスタ外から Pod へ到達できる流れを確認できます。

ここで重要なのは、Service は Pod の入口を作る Kubernetes 側の抽象であり、MetalLB はその Service に外部ネットワークから到達するための IP アドレス通知を担う、という役割分担です。

MetalLB の動作確認では、単に Nginx が表示されるかだけでなく、EXTERNAL-IP、Service のイベント、MetalLB の Pod、上位ネットワークの到達性を合わせて確認すると、障害時にも切り分けやすくなります。

関連する記事

次に進む

参考書籍

関連記事

Kubernetes Nginx コンテナと Service NodePort – Node のポート経由でアクセスする Kubernetes MetalLB を Helm で導入する – オンプレ環境で LoadBalancer Service を使う Kubernetes MetalLB の導入 – LoadBalancer Service をオンプレ環境で成立させる Kubernetes に LoadBalancer はないのか – Service、MetalLB、CNI BGP を分けて考える Kubernetes Nginx コンテナと Service ClusterIP – クラスタ内部通信の入口を作る Kubernetes MetalLB を Helm で導入する – Harbor で Chart を管理する考え方 Kubernetes Nginx コンテナの実行 – Deployment で Pod を管理する MicroK8s MetalLB speaker が socket permission denied を出す原因 – L2 / 権限 / ホストネットワークを切り分ける