Ingress ― HTTPの入口とパスルーティング

導入

Web サービスを公開したいとき、画面用・API 用・管理画面用…とアプリが増えるたびに LoadBalancer の Service を1つずつ立てると、コストも管理も膨れ上がります。Ingress は、HTTP/HTTPS 専用の一枚看板の入口を用意し、ホスト名やパスごとに適切な Service へ振り分ける仕組みです。

説明

Ingress は L7（レイヤー7、HTTP のレベル） で動く交通整理役です。「/api で来たら api の Service へ、/ で来たら web の Service へ」「shop.example.com はこっち、admin.example.com はあっち」といった パスルーティング／ホストルーティング を1か所で定義できます。加えて TLS 終端（https:// の暗号化をここで解く役目）も担えます。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
spec:
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-svc     # /api は api-svc へ
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-svc     # それ以外は web-svc へ
                port:
                  number: 80

ここで注意が1つ。上の Ingress はルール（設定）を書いた紙にすぎません。実際にトラフィックをさばく実体として、Ingress Controller（イングレスコントローラー） をクラスタに導入しておく必要があります。よく使われるのは nginx ベースのものです。Ingress Controller が、あなたが書いた Ingress のルールを読み取り、そのとおりに通信を振り分けます。

graph TB
    User["外部の利用者<br/>shop.example.com"]
    User --> ING["Ingress Controller<br/>（nginx等・唯一の入口）"]
    ING -->|"/api"| S1["Service: api-svc"]
    ING -->|"/"| S2["Service: web-svc"]
    S1 --> P1["api の Pod"]
    S2 --> P2["web の Pod"]

まとめると、Service は「変わらない内部の宛先」、Ingress は「外部からの HTTP を1か所で受けて振り分ける入口」です。小さな検証なら NodePort、クラウドの本番外部公開は LoadBalancer や Ingress、という使い分けを覚えておきましょう。