Gateway API + Istio

이 문서에서는 Gateway API + Istio의 기본 개념과 실제 적용에 필요한 구성 요소들을 설명합니다.

Gateway API

Kubernetes SIG Network에서 개발한 L4/L7 라우팅을 위한 공식 Kubernetes 프로젝트입니다.

핵심 설계 원칙

• 역할 기반 (Role-oriented): GatewayClass/Gateway/Route로 리소스를 분리하여 역할별 책임을 명확히 구분합니다.
• 이식성 (Portable): Istio, Cilium 등 다양한 구현체에서 동일한 CRD를 사용할 수 있습니다.
• 표현력 (Expressive): 헤더 매칭, 트래픽 가중치 등 고급 기능을 기본으로 지원합니다.
• 확장성 (Extensible): 구현체별로 별도 CRD를 정의하여 확장 가능합니다. (예: Istio의 VirtualService)

주요 구성 요소

리소스	관리 주체	설명
GatewayClass	Infrastructure Provider	어떤 Gateway 구현체(Istio, Cilium 등)를 사용할지 정의
Gateway	DevOps Engineer	포트, 도메인, TLS 등 인프라 수준 설정
HTTPRoute	Software Engineer	자신의 앱으로 트래픽을 라우팅하는 규칙 정의
GRPCRoute	Software Engineer	gRPC 트래픽이 필요할 경우
TCPRoute/UDPRoute	Software Engineer	L4 트래픽 처리가 필요할 경우 (Alpha)

Ingress와의 비교

항목	Ingress	Gateway API
역할 분리	단일 리소스에 모든 설정 혼재	GatewayClass/Gateway/Route로 책임 분리
프로토콜	HTTP, HTTPS	HTTP, HTTPS, gRPC, TCP, UDP
라우팅	기본 경로 기반	헤더, 가중치, 메서드 등 고급 라우팅
Canary 배포	Annotation 필요	weight 필드가 표준 스펙이므로 바로 트래픽 분배 가능
이식성	Annotation이 구현체마다 다름	핵심 기능은 표준 CRD, 고급 기능만 추가 CRD 정의로 확장
Cross-NS Route Attachment	미지원	다른 NS의 Gateway에 Route 연결 가능1
Cross-NS Backend Reference	미지원	다른 NS의 Service를 backendRef로 참조 가능2

Ingress API 자체는 feature-frozen 상태이며, Ingress NGINX는 2026년 3월 EOL 예정입니다.³ 신규 프로젝트는 Gateway API를 사용하는 것이 권장됩니다.

Istio

Service Mesh의 대표적인 구현체로, CNCF Graduated 프로젝트입니다.

핵심 기능:

• 트래픽 관리: 재시도, 타임아웃, 서킷브레이커, 트래픽 분할 등
• 보안: mTLS 암호화, 인증/인가, 정책 일관성 있는 적용
• 관측성: 메트릭/트레이싱/로깅

다른 구현체와의 비교

항목	Istio	Linkerd	Cilium Service Mesh
프록시	Envoy (L7 풀스펙)	linkerd2-proxy (경량)	eBPF (커널 레벨)
기능 범위	가장 풍부	심플함 우선	네트워크 성능 우선
복잡도	높음	낮음	중간
Ambient Mode	지원	미지원	기본이 Sidecarless

Istio를 선택하는 이유:

• 가장 성숙하고 기능이 풍부함 (CNCF Graduated)
• 멀티클러스터, VM 워크로드 등 다양한 환경 지원
• Ambient Mode로 Sidecar 방식의 단점 해결

Ambient Mode

기존 Sidecar 방식의 단점을 해결한 데이터 플레인 아키텍처입니다. Pod마다 Envoy sidecar를 주입하는 대신, 노드 레벨 L4 프록시(ztunnel)와 선택적 L7 프록시(Waypoint)를 사용합니다.

장점:

• 낮은 리소스 소비: 노드당 하나의 ztunnel로 CPU/메모리 절감
• 간소화된 운영: Pod와 독립된 프록시로 운영되며, 역할과 생명주기를 완전히 분리
• 점진적 도입 가능: L4, L7 프록시를 선택적으로 추가하여 점진적으로 도입 가능

아키텍처

Istio는 컨트롤 플레인과 데이터 플레인으로 구성됩니다. 컨트롤 플레인은 정책과 설정을 관리하고 데이터 플레인으로 전달하며, istiod가 그 역할을 수행합니다. 데이터 플레인은 ztunnel(L4)과 waypoint(L7)로 구성되며, 실제로 트래픽을 처리하게 됩니다.

flowchart TB
    subgraph ControlPlane["컨트롤 플레인"]
        istiod["istiod<br/>(설정 배포, 인증서 관리, 서비스 디스커버리)"]
    end

    subgraph DataPlane["데이터 플레인 (Ambient Mode)"]
        ztunnel["ztunnel<br/>(L4: mTLS, 인증/인가)"]
        waypoint["Waypoint Proxy<br/>(L7: HTTP 정책, 텔레메트리)"]
    end

    subgraph App["애플리케이션"]
        pod1["Pod A"]
        pod2["Pod B"]
    end

    istiod -->|설정/인증서 전달| ztunnel
    istiod -->|설정/인증서 전달| waypoint
    pod1 <-->|트래픽| ztunnel
    pod2 <-->|트래픽| ztunnel
    ztunnel <-->|L7 필요시| waypoint

주요 CRD

CRD	용도
VirtualService	트래픽 라우팅 규칙 (재시도, 타임아웃, 트래픽 분할 등)
DestinationRule	백엔드 정책 (로드밸런싱, 서킷브레이커, 연결 풀 설정 등)
AuthorizationPolicy	접근 제어 (어떤 서비스가 어떤 서비스를 호출할 수 있는지)
PeerAuthentication	mTLS 모드 설정 (STRICT, PERMISSIVE 등)
RequestAuthentication	JWT 검증 등 요청 수준 인증
EnvoyFilter	Envoy 저수준 설정 (최후의 수단, 아래 참고)

EnvoyFilter 사용 시 주의사항

EnvoyFilter는 표준 CRD로 표현할 수 없는 Envoy 저수준 설정이 필요할 때 제한적으로 사용합니다.

불가피하게 사용해야 하는 경우:

상황	예시
요청 본문 크기 제한	max_request_bytes 설정
커스텀 헤더 조작	특정 조건에서만 헤더 추가/삭제
Rate Limiting	Envoy의 local/global rate limit 필터
Lua/WASM 플러그인	복잡한 요청/응답 변환 로직

주의사항:

• 버전 호환성: Istio/Envoy 업그레이드 시 EnvoyFilter가 깨질 수 있음. 업그레이드 후 반드시 테스트 필요
• Ambient Mode 제약: ztunnel은 Envoy가 아니므로 EnvoyFilter 적용 불가. Waypoint Proxy에만 적용 가능
• 디버깅 어려움: 표준 CRD와 EnvoyFilter가 섞이면 문제 추적이 복잡해짐

Helm Charts

Chart	설명
istio-base	Istio CRD 및 클러스터 레벨 리소스 설치
istiod	컨트롤 플레인 (istiod) 설치
istio-cni	CNI 플러그인 - Pod 네트워크 설정 담당
ztunnel	Ambient Mode L4 프록시 DaemonSet
istio-gateway	Gateway 구현체 (외부 트래픽 처리 시 필요)

Gateway API + Istio 함께 사용하기

VirtualService vs HTTPRoute

항목	HTTPRoute (Gateway API)	VirtualService (Istio)
표준화	Kubernetes 표준	Istio 전용
적용 범위	North-South (외부→내부)	North-South + East-West (내부↔내부)
이식성	다른 구현체로 이동 가능	Istio에 종속
기능	라우팅, 트래픽 분할, 헤더 매칭	HTTPRoute의 기능 + 재시도, 타임아웃, fault injection 등

요약하면 기능적으로는 VirtualService가 더 풍부하지만, 표준화나 다른 Gateway API 구현체로 이전 계획이 있다면 HTTPRoute를 사용하는 것이 나을 수 있습니다.

CORS 설정

Istio + Gateway API 환경에서 CORS를 설정하는 방법은 여러 가지가 있습니다.

Istio VirtualService (권장)

Istio 환경에서 가장 일반적인 방법입니다. VirtualService의 corsPolicy 필드를 사용합니다.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
    - my-service.example.com
  http:
    - corsPolicy:
        allowOrigins:
          - exact: https://app.example.com
          - regex: "https://.*\\.example\\.com"
        allowMethods:
          - GET
          - POST
          - PUT
          - DELETE
          - OPTIONS
        allowHeaders:
          - Authorization
          - Content-Type
          - X-Custom-Header
        exposeHeaders:
          - X-Response-Header
        maxAge: "24h"
        allowCredentials: true
      route:
        - destination:
            host: my-service.default.svc.cluster.local

주요 필드:

필드	설명
allowOrigins	허용할 Origin 목록 (exact, prefix, regex 매칭 지원)
allowMethods	허용할 HTTP 메서드
allowHeaders	요청에서 허용할 헤더
exposeHeaders	클라이언트에 노출할 응답 헤더
maxAge	Preflight 응답 캐시 시간
allowCredentials	쿠키/인증 정보 포함 여부 (true일 경우 와일드카드 사용 불가)

Gateway API CORS Filter (Experimental)

Gateway API v1.3.0부터 CORS 필터가 실험적 기능으로 추가되었습니다.⁴

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      filters:
        - type: CORS
          cors:
            allowOrigins:
              - type: Exact
                value: https://app.example.com
            allowMethods:
              - GET
              - POST
              - OPTIONS
            allowHeaders:
              - Authorization
              - Content-Type
            allowCredentials: false
            maxAge: 86400
      backendRefs:
        - name: my-service
          port: 8080

주의사항:

• Experimental 채널 설치 필요 (gateway.networking.k8s.io/v1 with experimental CRDs)
• HTTPRoute에서 OPTIONS 메서드를 허용해야 Preflight 요청이 처리됨
• allowCredentials: true일 경우 와일드카드(*) 사용 불가, 명시적 Origin 지정 필요

HTTPRoute ResponseHeaderModifier는?

ResponseHeaderModifier로 CORS 헤더를 직접 추가하는 방법⁵도 있지만, Preflight 자동 처리가 안 되고 CORS 규칙을 수동 관리해야 하므로 권장하지 않습니다.

부록: 로드밸런싱 오버헤드 스펙트럼

Service Mesh는 “LB/네트워킹 정책을 어디서 처리하느냐”의 한 지점일 뿐입니다. 규모가 커질수록 편의를 포기하고 오버헤드를 낮추는 쪽으로 내려가며, 방향을 결정하는 건 기술이 아니라 규모와 전담 조직의 유무입니다.

단계	처리 위치	언제	성격	대표
1. server-side LB	중앙 LB 1홉	소규모, north-south, 인스턴스 소수	메시 불필요, 설정	K8s Service, nginx, ALB
2. sidecar mesh	Pod마다 프록시	mTLS·재시도·정책을 앱 코드 안 건드리고 편하게	편의 최고 / 오버헤드 최고	Istio(sidecar), Linkerd
3. ambient mesh	노드당 프록시(ztunnel)	Pod가 많아 sidecar 리소스 등이 부담될 때	편의 유지 + 오버헤드↓	Istio Ambient, Cilium
4. 인프로세스 client-side LB	앱 내 라이브러리(홉 0)	내부 gRPC 초고빈도, 수백~수천 서비스	자체 SDK를 언어마다 개발·유지	Finagle, gRPC 내장 LB
5. 자체 eBPF/커널 LB	커널(XDP), 유저스페이스 우회	전 지구 규모, 초당 수억 패킷	범용 제품을 버리고 커널 레벨로 자체 제조	Meta Katran, Google Maglev, Cloudflare Unimog

• 1-3단계는 “제품을 고르고 설정(YAML)“하는 일로, 솔로~중견이 실제로 다루는 범위입니다. eBPF는 3단계를 구현하는 재료(Cilium/ztunnel 내부)이지, 별도 상위 등급이 아닙니다.
• 4-5단계는 문제가 “설정”이 아니라 “R&D”로 바뀝니다. 진입 조건이 기술이 아니라 전담 플랫폼팀·커널 엔지니어라, 개인/초기 스타트업은 경험할 통로 자체가 없습니다.
• 역적용 금지: Meta가 client-side LB나 자체 eBPF LB를 쓰는 건 “ambient를 몰라서”가 아니라, 그 규모에선 (a) 프록시 홉·CPU 총합이 데이터센터 단위 비용이고 (b) 이미 자체 인프라가 ambient보다 최적화돼 있기 때문입니다. 우리 규모에선 편의세를 내는 게 이득인 구간이라 2-3단계가 정답입니다.

Reference

• Gateway API
• Gateway API vs Ingress: The Future of Kubernetes Networking
• Istio official website
• Istio Ambient Mode

Footnotes

1. Cross-Namespace Routing ↩

2. ReferenceGrant ↩

3. Ingress NGINX Retirement: What You Need to Know ↩

4. Gateway API v1.3.0: CORS Filter ↩

5. HTTP Header Modifier ↩