Gateway API + Istio

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

Gateway API

Kubernetes SIG Network에서 개발한 차세대 Ingress API로, L4/L7 라우팅을 위한 공식 Kubernetes 프로젝트입니다.
2023년 말 v1.0 GA 출시 이후 빠르게 성장하여, 새로운 네트워크 구현의 표준으로 자리잡았습니다.

Gateway API의 핵심 설계 원칙

• 역할 기반 (Role-oriented):
  • 기존 Ingress는 하나의 Ingress 리소스에 모든 설정이 섞여 있었습니다.
  • Gateway API는 역할별로 Gateway, HTTPRoute 등의 리소스를 분리하고, 각 역할별로 책임과 관리 범위를 명확히 구분합니다. 예를 들어, DevOps Engineer가 GatewayClass와 Gateway를 관리하며, 일반 Software Engineer는 HTTPRoute만 신경 쓸 수 있습니다.
• 이식성 (Portable):
  • Istio, Cilium 등 다양한 구현체에서 동일한 CRD를 사용할 수 있습니다.
• 표현력 (Expressive): 헤더 매칭, 트래픽 가중치 등 고급 기능을 기본으로 지원합니다.
• 확장성 (Extensible):
  • 추가 특수/고급 기능은 구현체별로 별도 CRD를 정의하는 등 구현체별로 확장이 가능합니다.
  • 예를 들어 Istio의 VirtualService와 DestinationRule, NGINX Gateway Fabric의 ClientSettingsPolicy 등이 있습니다.

Gateway API의 주요 구성 요소

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

Ingress와의 차이점 (Gateway API를 사용해야 하는 이유)

항목	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 개발은 Gateway API로 전환되었으며, 당분간 공존하지만 점차 Deprecated 될 예정입니다.³
신규 프로젝트는 처음부터 Gateway API를 사용하는 것이 권장됩니다.

Istio

Service Mesh란?

마이크로서비스 환경에서 서비스 간 통신에 필요한 공통 기능을 애플리케이션 코드 변경 없이 인프라 레이어에서 처리해주는 기술입니다.

Service Mesh가 없다면 다음을 직접 구현해야 합니다:

문제	직접 구현 시
서비스 간 암호화	각 앱에 TLS 설정, 인증서 관리 코드 추가
재시도/타임아웃/서킷브레이커	각 앱에 Resilience 라이브러리 추가
트래픽 관측	각 앱에 메트릭/트레이싱 SDK 삽입
접근 제어	각 앱에 인증/인가 로직 구현

이 과정에서 중복 코드, 언어별로 다른 구현, 일관성 없는 정책 적용 등 여러 문제가 발생할 수 있습니다. Service Mesh를 사용하면 이 모든 것을 앱 외부에서 일관되게 처리할 수 있습니다.

Istio란?

Google, IBM, Lyft가 2016년 시작한 오픈소스 Service Mesh로, 2023년 CNCF Graduated 프로젝트가 되었습니다. 핵심 기능은 다음과 같습니다.

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

다른 Service Mesh와의 비교

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

Istio를 선택하는 이유:

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

Ambient Mode란?

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

장점:

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

Istio 아키텍처

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 저수준 설정 (최후의 수단, 아래 참고)

VirtualService vs HTTPRoute

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

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

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

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 ↩