Ingress란 무엇이며 외부 트래픽을 어떻게 Service로 라우팅하는가?

Question

IT Interview Practice · Accepted Answer

**Ingress**는 **HTTP/HTTPS 라우팅 규칙**을 정의하는 Kubernetes 객체다 — 호스트명과 URL 경로를 백엔드 **Service**에 매핑한다. 그것은 **Ingress Controller**(nginx, Traefik, 클라우드 게이트웨이)에 의해 이행되며, 서비스마다 LoadBalancer를 두는 대신 하나의 진입점, TLS 종료, 호스트/경로 라우팅을 제공한다.

## Ingress가 해결하는 문제

```text
type: LoadBalancer로 많은 서비스를 노출하면 클라우드 LB(와 공인 IP)가 많아진다
— 비싸고, 공유되는 호스트명/경로 라우팅이나 TLS도 없다.
Ingress는 host & path로 내부 ClusterIP Service에 라우팅하는 하나의 진입점을 제공한다.
```

## 어떻게 맞물리는가

```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 (규칙)  ≠  Ingress Controller (규칙을 집행하는 실행 중인 proxy)
```

## 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 인증서/키가 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 Pod
shop.example.com/...     → Service "web" → web Pod
TLS는 "shop-tls" Secret의 인증서를 사용해 controller에서 종료된다.
```

## 핵심 포인트

```text
• Ingress Controller를 반드시 실행해야 한다 — Ingress 객체만으로는 아무것도 안 한다.
• ingressClassName이 어느 controller가 규칙을 처리할지 선택한다.
• Ingress는 HTTP/HTTPS (L7) 전용. 원시 TCP/UDP에는 Service나 Gateway API를 쓴다.
• 더 새로운 Gateway API가 더 풍부하고 역할 지향적인 라우팅을 가진 진화하는 후계자다.
```

```bash
kubectl get ingress                  # 규칙, 호스트, 주소 목록
kubectl describe ingress app-ingress # 백엔드 & 이벤트 보기
```

## 왜 중요한가

Ingress는 Kubernetes에서 HTTP/HTTPS 애플리케이션을 외부 세계에 노출하는 표준 방식이므로, 그것을 이해하는 것은 미들급 엔지니어에게 필수적인 네트워킹 지식이다. 그것이 해결하는 문제는 구체적이고 흔하다: `type: LoadBalancer`로 많은 서비스를 노출하면 서비스마다 별도의 클라우드 load balancer와 공인 IP를 프로비저닝해야 하는데 — 비싸고 공유되는 호스트명 라우팅이나 TLS도 없다 — 반면 **Ingress**는 **host와 path**로 내부 ClusterIP Service에 라우팅하고 **TLS**를 중앙에서 종료하는 단일 진입점을 제공한다. 사람들을 걸려 넘어지게 하는 구분은 **Ingress 객체**(선언적 라우팅 규칙)와 **Ingress Controller**(그 규칙을 감시하고 집행하는 실제 실행 중인 proxy — nginx, Traefik, 클라우드 게이트웨이) 사이다; 규칙은 controller가 설치되지 않으면 아무것도 하지 않으며, `ingressClassName`이 어느 controller가 그것을 처리할지 선택한다. Ingress가 **L7(HTTP/HTTPS 전용)**에서 동작한다는 것 — 그래서 원시 TCP/UDP에는 Service나 더 새로운 Gateway API가 필요하다는 것 — 과 **Gateway API**가 진화하는 더 표현력 있는 후계자라는 것을 이해하는 것은 현재의 실제 지식을 반영한다. Kubernetes의 거의 모든 사용자 대면 애플리케이션이 단일 진입점에서 host/path 기반 라우팅과 TLS를 필요로 하고, 객체 대 controller 구분이 면접과 실무 양쪽에서 흔한 혼동의 원천이므로, Ingress를 확실히 파악하는 것은 클러스터에서 웹 워크로드를 노출하고 운영하는 데 기초가 된다.

Ingress가 해결하는 문제

어떻게 맞물리는가

Ingress manifest

핵심 포인트

왜 중요한가

관련 질문