Tech Learning Daily

Service だけでは複数ドメインを 1 つの IP で捌けない

Service（ClusterIP や NodePort）は kube-proxy が iptables のルールで宛先 IP・ポート単位に転送するだけの L4 の仕組みで、HTTP の Host ヘッダやパスを見ることができない。そのため type: LoadBalancer の Service で foo.example.com と bar.example.com を別々のアプリに振り分けようとすると、Service ごとに別のクラウドロードバランサーと外部 IP を用意するしかなくなる。

foo.example.com ─▶ IP-A ─▶ Service A
bar.example.com ─▶ IP-B ─▶ Service B

ドメインの数だけ外部 IP とロードバランサーのコストが積み上がる。しかも Service 側はそもそも Host ヘッダの中身に興味が無いので、この構成は「たまたまドメインごとに IP を分けている」だけで、1 つのエンドポイントで複数ドメインをさばく仕組みにはなっていない。

Ingress は「ルールを書くだけ」——それ自体は動かない

ここで登場する kind: Ingress は、Service や Deployment と同じく Kubernetes API サーバーに保存される 1 つの API オブジェクトでしかない。だが Deployment を作れば kubelet が Pod を起動し、Service を作れば kube-proxy が iptables ルールを書き換えるのに対し、Ingress にはそれに相当する標準搭載のコンポーネントが存在しない。

Kubernetes 公式ドキュメントはこの点をはっきり書いている。You must have an Ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect.——Ingress リソースを作成しただけでは、エラーも出ないまま本当に何も起きない。これが冒頭の「ADDRESS 欄が空のまま」の正体で、マニフェストの書き方の問題ではなくクラスタに Ingress Controller が存在しないことが原因であるケースが多い。

Ingress Controller が実際に振り分ける

Ingress Controller（nginx ingress、Envoy ベースの Contour、Traefik など複数の実装がある）は、Ingress オブジェクトの変更を API サーバーへ問い合わせ続け、そこに書かれたルールを自分自身が動かすリバースプロキシの設定に変換する Pod 群だ。Controller 自身は普通の Service（多くは type: LoadBalancer）としてクラスタの外に公開されており、kubectl get ingress の ADDRESS 欄に入る IP は、実は Ingress そのものではなく Controller 側の Service が持つ外部 IP になる。

Client (HTTPS)
     │
     ▼
Ingress Controller Pod
 (Service: LoadBalancer)
     │ ルールを見て転送(HTTP)
     ▼
  Service ──▶ Pod

1 つのクラスタに複数の Controller を共存させることもでき、どの Ingress をどの Controller に処理させるかは、Controller ごとに登録された IngressClass（Controller の識別子を持つ API オブジェクト）を spec.ingressClassName で指定して結びつける。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  ingressClassName: nginx   # このIngressを担当するController
  rules:
  - host: foo.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web
            port:
              number: 80

ingressClassName を省略すると、ingressclass.kubernetes.io/is-default-class: "true" が付いた IngressClass を持つ Controller が既定で処理する。複数の Controller を入れているのに ingressClassName を書き忘れると、意図しない Controller がルールを拾ってしまうことがある。

host/path のマッチングと TLS 終端の具体挙動

pathType には Prefix（接頭辞一致。/testpath なら /testpath/one にもマッチする）と Exact（完全一致のみ）があり、どちらを選ぶかでルールが想定より広く／狭く効くかが決まる。spec.rules のどれにも一致しないリクエストは、spec.defaultBackend を指定していればそこへ送られ、指定していなければ Controller 自身が返す 404 になる。spec.rules を書かずに defaultBackend だけの Ingress を作ることもでき、その場合は必須項目になる。

spec:
  tls:
  - hosts: ["foo.example.com"]
    secretName: foo-tls   # 証明書とキーを持つ Secret
  rules:
  - host: foo.example.com
    http:
      paths: [...]

TLS を設定すると Client と Ingress の間は HTTPS で暗号化されるが、Ingress は受け取った時点でその暗号を解いてしまう。この「暗号化された通信を復号して平文に戻す地点」をTLS 終端（TLS termination）と呼び、Ingress から先の Service・Pod へは平文の HTTP で転送される。これは「TLS を設定したから通信は最後まで暗号化されている」という思い込みを裏切る点で、Pod まで暗号化を続けたいなら Ingress とは別にサービスメッシュや mTLS の仕組みを重ねる必要がある。

Ingress の次: Gateway API

Ingress の仕様はホスト名とパスによる単純な振り分けしか標準では定義しておらず、ヘッダーによる振り分けやトラフィックの重み付けのような細かい制御は、これまで Controller ごとに異なる独自アノテーション（nginx.ingress.kubernetes.io/* など）に頼るしかなかった。Controller を乗り換えるとアノテーションごと書き直しになるのはこのためだ。

Kubernetes 公式は現在 Ingress API を凍結しており、今後の変更や新機能は追加されないと明言した上で、後継として Gateway API への移行を推奨している。Gateway API はヘッダーベースのマッチングやトラフィックの重み付けを、ベンダー独自のアノテーションではなく標準の API フィールドとして扱える設計になっている。Ingress 自体が撤去される予定はないが、新しい振り分け要件が出てきたときに「Ingress のアノテーションで頑張る」以外の選択肢があることは覚えておいて損はない。