Kubernetes Ingress, 이제 정말 보내줘야 할까요? Gateway API 전격 파헤치기 🚀

안녕하세요! 쿠버네티스 환경에서 서비스를 운영하고 계신가요? 그렇다면 아마도 외부 트래픽을 클러스터 내부 서비스로 연결해주는 'Ingress'에 매우 익숙하실 겁니다. Ingress는 오랫동안 쿠버네티스의 표준 관문 역할을 해왔죠.

하지만 서비스가 복잡해지고 요구사항이 다양해지면서, 이런 생각을 한 번쯤 해보셨을 겁니다.

"모바일 유저에게만 다른 페이지를 보여주고 싶은데... 🤔" "새로운 버전 앱을 10% 트래픽에만 먼저 배포해볼 수 없을까? 🐦" "특정 HTTP 헤더가 있는 요청만 다른 서비스로 보내고 싶은데... 🧐"

Ingress의 기본 기능만으로는 이런 고급 라우팅 전략을 구현하기가 까다롭습니다. 물론 Ingress Controller마다 제공하는 어노테이션(annotation)을 사용하면 일부 가능하지만, 이는 특정 벤더에 종속되고 표준화되지 않아 이식성이 떨어지는 문제가 있었죠.

바로 이 지점에서 쿠버네티스의 차세대 네트워킹 표준, Gateway API가 등장합니다!

---

🧱 Ingress의 한계: 왜 우리는 새로운 것을 필요로 할까?

Gateway API를 이해하기 전에, 기존 Ingress가 가진 한계를 명확히 짚고 넘어가는 것이 중요합니다.

1. 제한적인 라우팅 규칙: Ingress는 기본적으로 호스트 이름(hostname)과 경로(path) 기반의 라우팅만 표준으로 지원합니다. 헤더, 쿼리 파라미터, 가중치 기반 라우팅 등은 표준 기능이 아닙니다.
2. 벤더 종속적인 설정: 위에서 언급했듯, 고급 기능을 사용하려면 nginx.ingress.kubernetes.io/rewrite-target 같은 특정 Ingress Controller의 어노테이션에 의존해야 합니다. 이는 다른 Ingress Controller로 교체할 때 모든 설정을 다시 변경해야 함을 의미합니다. 😩
3. 권한 관리의 어려움: Ingress 리소스는 보통 클러스터 관리자나 플랫폼 팀이 관리합니다. 하지만 애플리케이션 개발자가 특정 경로에 대한 라우팅 규칙을 수정하고 싶을 때, 거대한 Ingress YAML 파일을 함께 수정해야 하므로 권한 분리가 어렵고 충돌의 위험이 존재합니다.

이러한 문제들을 해결하기 위해, 더 유연하고, 표현력 풍부하며, 역할 기반으로 설계된 Gateway API가 탄생했습니다.

---

✨ Gateway API의 등장: 무엇이 다른가?

Gateway API는 Ingress의 후속 프로젝트로, 네트워킹 설정을 여러 개의 독립적인 리소스로 분리하여 관리의 유연성을 극대화합니다. 핵심적인 3가지 컴포넌트를 기억하세요.

• GatewayClass: 클러스터 전체에 적용되는 템플릿입니다. 어떤 종류의 로드밸런서(예: AWS LB, NGINX, Istio)를 사용할지 정의합니다. (주로 클러스터 관리자 담당) ☁️
• Gateway: GatewayClass의 실제 인스턴스입니다. 특정 IP 주소, 포트, TLS 설정 등을 정의하며, 로드밸런서 자체를 나타냅니다. (주로 인프라 운영자 담당) 🚪
• HTTPRoute: 실제 라우팅 규칙을 정의합니다. "/login 경로는 auth-service로 보내고, /api/v2 경로는 new-api-service로 보내라"와 같은 애플리케이션 레벨의 규칙을 담습니다. (주로 애플리케이션 개발자 담당) 🗺️

이 구조의 가장 큰 장점은 역할 분리(Separation of Concerns)입니다. 인프라팀은 Gateway를 통해 안정적인 관문을 제공하고, 개발팀은 자신들의 서비스에 필요한 HTTPRoute 규칙만 신경 쓰면 되죠. 서로의 영역을 침범하지 않고 독립적으로 작업할 수 있습니다. 🤝

---

🎯 핵심 기능: 비교할 수 없는 트래픽 제어 능력

이제 Gateway API가 왜 "더 세분화된 트래픽 제어(More granular control over traffic routing)"를 가능하게 하는지 실제 예시를 통해 살펴보겠습니다.

1. 헤더 기반 라우팅 (Header-based Routing)

모바일 앱 사용자와 웹 사용자를 구분하여 다른 백엔드 서비스로 보내고 싶다고 가정해 봅시다. User-Agent 헤더를 기준으로 라우팅을 분기할 수 있습니다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: mobile-routing-example
spec:
  parentRefs:
  - name: my-production-gateway
  hostnames: ["example.com"]
  rules:
  - matches:
    - headers:
      - type: Exact
        name: User-Agent
        value: "MyMobileApp/1.0"
    backendRefs:
    - name: mobile-app-service
      port: 8080
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: web-app-service
      port: 8080

위 HTTPRoute는 User-Agent 헤더가 MyMobileApp/1.0인 요청은 mobile-app-service로, 그 외의 모든 요청은 web-app-service로 보냅니다. Ingress 어노테이션 없이 표준 기능만으로 이것이 가능합니다!

2. 카나리 배포를 위한 가중치 기반 라우팅 (Weight-based Routing) 🐦

새로운 버전의 my-app-v2를 배포하고, 전체 트래픽의 10%만 먼저 보내서 안정성을 테스트하고 싶습니다. Gateway API는 이를 위한 weight 필드를 표준으로 제공합니다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: canary-deployment-example
spec:
  parentRefs:
  - name: my-production-gateway
  hostnames: ["api.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: my-app-v1 # 기존 버전 서비스
      port: 80
      weight: 90
    - name: my-app-v2 # 새로운 버전 서비스
      port: 80
      weight: 10

이 설정 하나면 끝입니다! my-app-v1 서비스가 90%의 트래픽을, my-app-v2가 10%의 트래픽을 받게 됩니다. 더 이상 복잡한 추가 도구나 비표준 어노테이션에 의존할 필요가 없습니다. ⚖️

---

🌐 전체적인 맥락: 왜 Gateway API로 전환해야 하는가?

개별 기능의 강력함도 중요하지만, Gateway API가 가져오는 더 큰 변화는 쿠버네티스 네트워킹의 표준화와 이식성입니다.

• 역할 기반 API: 인프라팀과 개발팀의 책임과 권한을 명확히 분리하여 협업을 원활하게 하고 실수를 줄입니다.
• 이식성: 모든 라우팅 규칙(헤더, 가중치 등)이 표준 명세에 포함되어 있습니다. 즉, NGINX Gateway Fabric을 사용하다가 Istio 기반 Gateway로 바꾸더라도, HTTPRoute 정의는 거의 그대로 재사용할 수 있습니다. 벤더 종속성에서 자유로워지는 것이죠. 🌍
• 표현력과 확장성: HTTPRoute 외에도 TCPRoute, UDPRoute, TLSRoute 등 다양한 프로토콜을 지원하며, 커스텀 필터를 통해 라우팅 규칙을 무한히 확장할 수 있습니다.

결론

Ingress는 여전히 간단한 웹 서비스를 노출하는 데 훌륭한 도구입니다. 하지만 마이크로서비스 아키텍처가 복잡해지고, 카나리 배포, A/B 테스팅, 세밀한 트래픽 제어 등 고급 기능이 필수가 된 오늘날, Ingress의 한계는 명확합니다.

Gateway API는 단순한 Ingress의 대체재가 아니라, 현대적인 클라우드 네이티브 환경의 요구사항을 충족시키기 위해 설계된 차세대 표준입니다. 지금 당장 모든 Ingress를 교체할 필요는 없겠지만, 새로운 프로젝트를 시작하거나 기존 시스템의 한계를 느끼고 있다면 Gateway API를 적극적으로 검토해볼 시간입니다. ✨