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 연결 가능¹
Cross-NS Backend Reference	미지원	다른 NS의 Service를 backendRef로 참조 가능²

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 구현체 (외부 트래픽 처리 시 필요)