NGINX Ingress controller + MetalLB で Ingress の IP アドレスがうまく払い出されなかった話

NGINX Ingress Controller と MetalLB を使った Ingress の構築に失敗していた話です。

背景

自宅ラボの Kubernetes クラスタでは、NGINX Ingress Controller と MetalLB をデプロイしています。これらを使って、Ingress リソースに NGINX Ingress Controller 向け LoadBalancer Service の External-IP を割り当てて、各種サービスを Ingress 経由で公開しています。

一方、Kubernetes クラスタとは別に自宅ラボ用の DNS サーバを構築しており、夏季休暇中に CoreDNS から PowerDNS に入れ替える作業をしました（この話は別途投稿したいと思います）。

するとどうでしょう、DNS サーバの入れ替え作業後に Ingress で公開していたサービスに接続できなくなってしまいました。

状況

Ingress リソースを確認したところ、設定されている IP アドレスが想定していたアドレスと異なっていました。想定アドレスは上述の通り「NGINX Ingress Controller 向け LoadBalancer Service の External-IP」です。

しかし、実際には「Kubernetes クラスタの Worker Node の IP アドレス」が設定されていました。

$ kubectl get ingress -A
NAMESPACE    NAME                   CLASS    HOSTS                           ADDRESS         PORTS     AGE
argocd       argocd-server-ingress  <none>   argocd-ingress.k8s.nnstt1.work  192.168.2.29   80, 443   22h
monitoring   grafana                <none>   grafana.k8s.nnstt1.work         192.168.2.29   80        20h
monitoring   k8s                    <none>   prometheus.k8s.nnstt1.work      192.168.2.29   80        20h
sandbox      sample-app             <none>   sample-app.k8s.nnstt1.work      192.168.2.29   80, 443   20h
# 192.168.2.29 は Worker Node の IP アドレス

Node Port のように Worker Node の IP アドレスでアクセスしても NGINX Ingress Controller のサービスには到達できないため、Ingress で指定したサービスにも接続できていませんでした。

原因

根本的な原因は、NGINX Ingress Controller の引数に --publish-service を設定できていなかったことでした。

調査のため Ingress や NGINX Ingress Controller を消しては作り直しを繰り返したのですが、最終的には GitHub のこちらの Issue を見つけたことで原因を特定できました。

自宅ラボの Kubernetes クラスタでは NGINX Ingress Controller 公式ドキュメントのベアメタル向け Installation Guide を参照し、ベアメタル向けのマニフェストを使って Ingress Controller をデプロイしていました。

しかし、ベアメタル向けのマニフェストは「MetalLB を使ってベアメタルでも LoadBalancer Service を使えるようにしている環境」向けではないため、--publish-service の引数が設定されていませんでした。

MetalLB を使っている場合は --publish-service が記載されている Cloud 向けのマニフェストを使うほうがよさそうです。

NGINX Ingress Controller の引数に --publish-service をつけることで、無事に LoadBalancer の External-IP が割り当てられるようになりました。

# 説明箇所のみ抜粋
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-nginx-controller
spec:
  template:
    spec:
      containers:
        - name: controller
          image: k8s.gcr.io/ingress-nginx/controller:v0.48.1@sha256:e9fb216ace49dfa4a5983b183067e97496e7a8b307d2093f4278cd550c303899
          args:
            - /nginx-ingress-controller
            - --election-id=ingress-controller-leader
            - --ingress-class=nginx
            - --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
            - --validating-webhook=:8443
            - --validating-webhook-certificate=/usr/local/certificates/cert
            - --validating-webhook-key=/usr/local/certificates/key
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx-controller    # この行を追加

–publish-service とは

NGINX Ingress Controller 公式ドキュメントの Command line arguments ページに記載があります。

Service fronting the Ingress controller. Takes the form “namespace/name”. When used together with update-status, the controller mirrors the address of this service’s endpoints to the load-balancer status of all Ingress objects it satisfies.

(機械翻訳) Ingressコントローラの前にあるサービス。 “namespace/name"という形式をとる。 update-statusと一緒に使用すると、コントローラは、このサービスのエンドポイントのアドレスを、満足するすべてのIngressオブジェクトのロードバランサステータスにミラーリングします。

NGINX Ingress Controller に --publish-service を付けなかった場合、今回のように Worker Node の IP アドレスが Ingress リソースに割り当てられるようですね。

このページをしっかり読んでいれば、今回の事象は防げていたはずです。

そもそも何で今までアクセスできていたの？

なんと、DNS サーバの入れ替え前（CoreDNS を使っていたとき）は、DNS サーバの /etc/hosts に直接 Ingress 用の DNS レコードを記述していたのです。

$ cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

192.168.2.244    argocd-ingress.k8s.nnstt1.work
192.168.2.244    grafana.k8s.nnstt1.work
192.168.2.244    prometheus.k8s.nnstt1.work
192.168.2.244    sample-app.k8s.nnstt1.work

元々 Ingress Controller を正しく設定できていなかったので、ワークアラウンド的に無理やり名前解決させていたようですね（他人事）。

それが PowerDNS への入れ替え時に /etc/hosts を綺麗に整理したことで名前解決できなくなり、Ingress 経由のサービスにアクセスできない事象が発生しました（正確には元々繋がらない設定だった）。

教訓

趣味でワークアラウンドな対応は（極力）しない。
ドキュメントはちゃんと読もう（N 回目の登場）。

背景#

状況#

原因#

–publish-service とは#

そもそも何で今までアクセスできていたの？#

教訓#

背景

状況

原因

–publish-service とは

そもそも何で今までアクセスできていたの？

教訓