Ingress とは何で、外部トラフィックを Service へどうルーティングしますか？

Question

IT Interview Practice · Accepted Answer

**Ingress** は、**HTTP/HTTPS のルーティングルール**を定義する Kubernetes オブジェクトで、ホスト名と URL パスをバックエンドの **Service** にマッピングします。それは **Ingress Controller**（nginx、Traefik、クラウドの gateway）によって実現され、service ごとの LoadBalancer の代わりに、単一の入口・TLS termination・host/path ルーティングを与えます。

## Ingress が解決する問題

```text
Exposing many services with type: LoadBalancer means MANY cloud LBs (and public IPs)
— expensive, and no shared hostname/path routing or TLS.
Ingress gives ONE entry point that routes by host & path to internal ClusterIP Services.
```

## どう組み合わさるか

```text
      Internet
         │
   ┌─────┴──────────────┐
   │ Ingress Controller │  (a Pod, e.g. nginx; usually behind ONE LoadBalancer)
   │  reads Ingress rules│
   └─────┬──────────────┘
         │ routes by host / path
   ┌─────┼───────────────┬───────────────┐
   ▼                     ▼               ▼
 Service: web        Service: api    Service: admin  (all ClusterIP)
   │                     │               │
 Pods                  Pods            Pods

Ingress (rules)  ≠  Ingress Controller (the running proxy that enforces them)
```

## Ingress の manifest

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
    - hosts: [shop.example.com]
      secretName: shop-tls        # TLS の cert/key を Secret に保存
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api
                port: { number: 80 }
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port: { number: 80 }
```

```text
shop.example.com/api/... → Service "api" → api Pods
shop.example.com/...     → Service "web" → web Pods
TLS is terminated at the controller using the cert in the "shop-tls" Secret.
```

## 要点

```text
• You MUST run an Ingress Controller — the Ingress object alone does nothing.
• ingressClassName selects which controller handles the rules.
• Ingress is HTTP/HTTPS (L7) only. For raw TCP/UDP use a Service or Gateway API.
• The newer Gateway API is the evolving successor with richer, role-oriented routing.
```

```bash
kubectl get ingress                  # ルール、ホスト、アドレスを一覧表示
kubectl describe ingress app-ingress # バックエンドとイベントを見る
```

## なぜ重要なのか

Ingress は Kubernetes 上で HTTP/HTTPS アプリケーションを外界に公開する標準的な方法であり、それを理解することは中級エンジニアにとって必須のネットワーキング知識です。それが解決する問題は具体的で一般的です。多数の service を `type: LoadBalancer` で公開するとは、service ごとに別々のクラウド load balancer と public IP をプロビジョニングすることを意味し — 高価でホスト名ルーティングや TLS を共有できません — 一方 **Ingress** は、**host と path** で内部の ClusterIP Service にルーティングし、**TLS** を集中的に終端する単一の入口を与えます。人がつまずく区別は、**Ingress オブジェクト**（宣言的なルーティングルール）と **Ingress Controller**（それらのルールを監視し強制する実際の proxy — nginx、Traefik、クラウド gateway）の間にあります。controller がインストールされていなければルールは何もせず、`ingressClassName` がどの controller が処理するかを選びます。Ingress が **L7（HTTP/HTTPS のみ）**で動作すること — したがって素の TCP/UDP には Service または新しい Gateway API が必要なこと — そして **Gateway API** が進化中でより表現力の高い後継であることを理解するのは、現在の実務に即した知識です。Kubernetes 上のほぼすべてのユーザー向けアプリケーションが、単一の入口からの host/path ベースのルーティングと TLS を必要とし、オブジェクト対 controller の区別が面接でも実務でも頻繁な混乱の元であるため、Ingress をしっかり把握することは、cluster 上で web workload を公開・運用するための基礎です。

Ingress が解決する問題

どう組み合わさるか

Ingress の manifest

要点

なぜ重要なのか

関連する質問