Gateway API

🚀 Gateway API가 등장한 이유

🔥 Ingress의 한계

1. 멀티 테넌시 불가능
   → 하나의 Ingress 리소스를 여러 팀이 공유함 → 충돌 발생

2. 기능 확장성 부족
   → HTTP 레이어만 지원 (Host, Path 매칭)
   → TCP, UDP, gRPC, TLS, Canary, Rate limiting 불가

3. 컨트롤러 의존적인 설정
   → 기능 확장은 모두 annotations에 의존
   → 컨트롤러별로 문법 다름 (예: NGINX vs Traefik)
   → 쿠버네티스는 이 설정을 전혀 이해하지 못함 (검증 불가)

---

🏗️ Gateway API 구조

🔥 기존 Ingress 구조

• 인프라 관리자와 앱 개발자가 동일한 Ingress 리소스 수정
• 모든 설정이 뒤섞임 (혼란, 충돌)

🔥 Gateway API 구조 → 역할 분리

역할	리소스 종류	설명
인프라 관리자	GatewayClass	인프라 종류 정의 (예: NGINX, Istio)
클러스터 운영자	Gateway	인프라 인스턴스 배포 (LB, 포트 관리)
앱 개발자	HTTPRoute 등	라우팅 규칙 정의 (도메인, Path 매칭)

---

🔥 리소스 예시

1️⃣ GatewayClass (인프라 정의)

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: example-class
spec:
  controllerName: example.net/gateway-controller

• controllerName → 어떤 컨트롤러를 쓸지 명시 (NGINX, Istio 등)

---

2️⃣ Gateway (LB 인스턴스)

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All

• LB 역할
• 포트(80, 443)와 프로토콜 정의
• 어떤 네임스페이스의 Route를 허용할지 설정 가능

---

3️⃣ HTTPRoute (앱 라우팅 설정)

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-httproute
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "www.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /login
    backendRefs:
    - name: example-svc
      port: 8080

• /login 경로로 들어온 요청을 example-svc:8080으로 전달

---

🔥 강력한 기능들

✅ 멀티 프로토콜 지원

• HTTPRoute, TCPRoute, TLSRoute, UDPRoute, GRPCRoute

✅ Traffic Splitting (Canary 배포)

backendRefs:
- name: app-v1
  port: 80
  weight: 80
- name: app-v2
  port: 80
  weight: 20

→ 버전 간 트래픽 분배

---

✅ TLS Termination (HTTPS)

listeners:
- name: https
  protocol: HTTPS
  port: 443
  tls:
    mode: Terminate
    certificateRefs:
    - name: tls-cert

→ 별도 어노테이션 없이 명확하게 TLS 관리

---

✅ 필터 기반 고급 기능

예) CORS 설정

filters:
- type: RequestHeaderModifier
  requestHeaderModifier:
    add:
    - name: Access-Control-Allow-Origin
      value: "*"

→ 더 이상 복잡한 annotations 불필요

---

🔥 Gateway API vs Ingress 비교

기능	Ingress	Gateway API
Multi-Tenancy	불가능	가능 (Route, Gateway 분리)
프로토콜 지원	HTTP/S	HTTP/S, TCP, UDP, gRPC, TLS
Traffic Splitting	Annotation 필요 (NGINX 한정)	Native 기능
TLS 관리	Spec + Annotation	완전 Spec 기반
CORS, Rate Limiting	Annotation	필터 기반 (Spec 지원)
컨트롤러 의존성	매우 높음	낮음 (표준 API)
클라우드/온프레미스 통합	제한적	강력 (EKS, GKE, AKS, NGINX 모두 지원)

---

🌍 이미 GA(정식 버전)로 지원하는 플랫폼

• ✅ AWS EKS
• ✅ Google GKE
• ✅ Azure AKS
• ✅ Istio, NGINX Gateway Fabric
• ✅ Traefik Proxy
• ✅ Kong Gateway
• ✅ Envoy Gateway
• ✅ HAProxy, Contour, Kuma 등

→ 업계 표준으로 급속히 자리 잡는 중.

---

🚩 결론

• Gateway API는 단순히 인그레스를 대체하는 것이 아님.
  → 쿠버네티스 네트워킹의 차세대 표준.

• Infra → Gateway → Route 구조로
  → 역할 분리, 보안 강화, 멀티테넌시 완벽 지원.

---

💡 즉시 적용 가능한 시나리오

• 팀별 네임스페이스 격리
• Canary 배포 (80% v1, 20% v2)
• HTTP + TCP + gRPC 혼합 서비스 운영
• TLS 인증서 중앙 관리