이번 글에서는 외부 트래픽을 K8s 클러스터 내부로 안전하고 정교하게 라우팅하기 위한 L7(애플리케이션 계층) 네트워크 기술의 진화 과정을 살펴봅니다. 기존의 표준이었던 Ingress의 한계점과, 이를 극복하기 위해 등장한 차세대 표준 Gateway API의 개념을 백엔드 개발자의 시각에서 정리합니다.
1. Service의 한계와 Ingress의 등장
K8s의 Service는 기본적으로 L4(TCP/UDP) 레벨의 로드밸런서 역할을 합니다.
만약 백엔드 시스템이 커져서 api.example.com/user는 User 서비스(Pod)로, api.example.com/order는 Order 서비스(Pod)로 보내야 하는 HTTP 라우팅이 필요하다면 어떻게 할까요? 기존 인프라 환경이라면 Nginx나 Spring Cloud Gateway 같은 L7 리버스 프록시(Reverse Proxy)를 앞단에 두었을 것입니다.
K8s에서는 이 역할을 Ingress(인그레스)가 담당해 왔습니다.
- Ingress 리소스: "특정 도메인이나 경로(Path)로 들어온 요청을 어떤 Service로 보낼지" 정의한 라우팅 규칙(YAML)입니다.
- Ingress Controller: 이 규칙을 실제로 읽어들여 트래픽을 분산시키는 실체입니다. Nginx Ingress Controller가 가장 유명합니다.
2. Ingress의 한계: "어노테이션(Annotation) 지옥"
Ingress는 오랫동안 K8s의 표준으로 쓰였지만, 클라우드 네이티브 환경이 복잡해지면서 뚜렷한 한계를 드러내기 시작했습니다.
가장 큰 문제는 Ingress의 기본 스펙이 너무 단순하다는 것이었습니다. 경로 기반 라우팅 정도만 기본 지원할 뿐, 카나리 배포를 위한 가중치 기반 트래픽 분산(Traffic Splitting)이나 특정 HTTP 헤더를 기반으로 한 라우팅, 정교한 타임아웃 설정 등은 표준 스펙에 없었습니다.
이를 해결하기 위해 개발자들은 Nginx 등 각 컨트롤러가 제공하는 자체 어노테이션(Annotation)을 YAML 파일에 덕지덕지 붙여야 했습니다.
# Ingress 어노테이션 지옥의 예시
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10"
# 컨트롤러가 바뀌면 이 어노테이션들은 모두 무용지물이 됩니다.
결국 이 방식은 표준화가 무너지고 특정 벤더(Nginx, HAProxy 등)에 완전히 종속되는 결과를 낳았습니다. 또한, 인프라 관리자와 백엔드 개발자가 하나의 Ingress 파일을 수정하다가 설정이 꼬이는 권한 분리의 문제(RBAC)도 존재했습니다.
3. 차세대 표준: Gateway API의 등장
이러한 Ingress의 한계를 극복하고, K8s L7 네트워킹의 진정한 표준을 세우기 위해 등장한 것이 바로 Gateway API입니다. (참고: API Gateway 패턴과는 다른, K8s의 리소스 이름입니다.)
Gateway API는 거대한 하나의 Ingress 리소스를 역할(Role)에 따라 3가지 오브젝트로 분리한 것이 핵심입니다.
- GatewayClass: "우리는 어떤 인프라(AWS ALB, Istio, Nginx 등)를 사용할 것인가?"를 정의합니다. (인프라 제공자 담당)
- Gateway: 클러스터 진입점의 IP, 포트, TLS(SSL) 인증서 등을 정의합니다. (클러스터 관리자 담당)
- HTTPRoute: "/user로 오면 User Service로 보내고, 헤더에 x-test=true가 있으면 테스트 v2 Service로 보내라" 같은 애플리케이션 레벨의 정교한 라우팅 규칙을 정의합니다. (백엔드 개발자 담당)
💡 백엔드 개발자 관점에서의 Gateway API 장점
- 명확한 역할 분담 (Role-Oriented): 백엔드 개발자는 인프라 설정이나 인증서를 신경 쓸 필요 없이, 오직 자신의 서비스 라우팅 규칙인 HTTPRoute 리소스만 관리하면 됩니다.
- 표준화된 강력한 라우팅: 더 이상 어노테이션에 의존하지 않아도 됩니다. HTTP 헤더 매칭, 트래픽 가중치 분배(A/B 테스트), 리다이렉트 같은 고급 기능이 HTTPRoute의 공식 표준 스펙으로 내장되어 있습니다.
4. 요약: K8s 트래픽 아키텍처의 완성
정리하자면, 외부 트래픽이 K8s 내부의 Spring Boot 앱까지 도달하는 현대적인 파이프라인은 다음과 같이 그려집니다.
Ingress에서 Gateway API로의 전환은 단순히 도구가 바뀌는 것을 넘어, 인프라 관리와 애플리케이션 개발의 관심사를 분리하고 책임을 명확히 하는 과정입니다. 현재 새롭게 구축되는 K8s 클러스터들은 빠르게 Gateway API를 채택하고 있는 추세입니다.