Kubernetes 확장판: Gateway API

들어가며

저는 현업에서 Kserve를 활용해서 모델 서빙을 하고 있습니다.
Kserve는 Serveless 모드로 설치하는 것이 표준이었고, Istio/Knative와 함께 설치해서 사용하고 있었습니다. 

그런데 0.15 버전부터는 RawDeployment 모드(0.16 버전부터는 Standard 모드라고 불림) 설치가 생겼고, LLM 서빙 시에는 해당 설치 방법이 권장된다고 합니다. 

아무래도 Serverless 모드의 핵심인 'Scale-to-zero'는 LLM에서 비현실적으로 다가왔던 것 같습니다. 기가바이트 단위의 모델 가중치를 다시 로드하는 데 시간이 너무 오래 걸리기 때문입니다.
Knative의 구성요소가 많고 디버깅도 어려워 걷어내고 싶다는 니즈가 있었는데, 여러 곳에서 유사한 고민이 있었던 것 같습니다.

그 와중에 Kubernetes Gateway API 기능이 추가되고, 이 기능이 표준으로 정의되면서 굳이 무거운 외부 솔루션을 덕지덕지 붙이지 않아도 정교한 서빙이 가능해졌습니다.
이번에 Kubernetes Gateway API에 대해서 살펴보겠습니다.

 

---

Kubernetes Gateway API란?

Gateway API는 Kubernetes 서비스 네트워킹(Ingress, Load Balancing, Service Mesh)의 차세대 표준을 정의하는 공식 프로젝트입니다.
이는 단순한 서비스가 아니라, 다양한 벤더(Istio, Kong, AWS 등)가 공통으로 따를 수 있는 표준 명세입니다.

3단계 리소스 구조

기존에 Ingress 하나의 파일에 모든 설정이 있어 운영자와 개발자 사이에 충돌이 있었다면,
Gateway API는 이를 3개의 계층으로 나누어 관심사 분리를 구현했습니다. 

1단계: 인프라 제공자 (Infrastructure Provider) → GatewayClass

어떤 장비를 사용할 것인지를 결정하는 단계입니다.
주로 클라우드 벤더(AWS, GCP 등)나 사내 플랫폼 팀이 담당합니다.

2단계: 클러스터 운영자 (Cluster Operator) → Gateway

어디를 통해 트래픽을 받을 것인지 결정하는 단계입니다.
"이 게이트웨이는 어떤 네임스페이스의 서비스들에게 길을 열어줄 것인가?"를 필터링 및 라우팅합니다.

3단계: 애플리케이션 개발자 (Application Developer) → Routes

들어온 트래픽을 어디로 보낼 것인지 결정하는 단계입니다.
운영자가 만들어둔 Gateway에 자신의 서비스(Service)를 구체적인 라우팅 규직을 통해 연결합니다. (/v1/train 경로는 학습 서비스로, 헤더에 version=v2가 있으면 신규 모델로 보내라.)

 

어떻게 정의하는가? (리소스 구성)

리소스들은 독립적으로 생성/삭제되며, 서로 참조하여 네트워크를 구성하는 방식입니다.

1. GatewayClass (Cluster-scoped)

• 어떤 컨트롤러가 이 설정을 처리할지 정의하는 템플릿입니다.
• 클러스터에 Istio, Kong, AWS ALB 등 여러 종류의 인프라가 동시에 존재할 수 있게 해줍니다.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: istio-gateway-class # 게이트웨이 클래스 이름
spec:
  controllerName: istio.io/gateway-controller # 이 설정을 처리할 컨트롤러 엔진

 

2. Gateway (Namespace-scoped)

• 클러스터 내 서비스로 트래픽을 변환하는 방법을 정의합니다.
• listners 필드를 통해서 게이트웨이가 트래픽을 수신하는 방법을 정의합니다.
• 트래픽은 단 하나의 listner에만 일치하도록 정의해야 합니다. 따라서 listner들은 서로 달라야 합니다.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  namespace: infra-namespace # 운영팀 관리 네임스페이스
spec:
  gatewayClassName: istio-gateway-class # 위에서 만든 클래스 참조
  listeners:
  - name: http
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: All # 모든 네임스페이스의 Route 연결 허용 (보안을 위해 특정 가능)

 

3. Route 리소스 (Namespace-scoped)

• 특정 프로토콜에 따른 라우팅 규칙을 정의합니다.
• HTTPRoute, GRPCRoute, TCPRoute, UDPRoute, TLSRoute 등의 다양한 종류의 연결을 지원합니다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: ai-service-route
  namespace: serving-namespace # 서비스 개발팀 네임스페이스
spec:
  parentRefs:
  - name: production-gateway # 연결할 Gateway 참조
    namespace: infra-namespace
  hostnames:
  - "api.nano-banana.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1/predict
    backendRefs:
    - name: model-v1-service # 기존 모델로 90% 트래픽 전송
      port: 8080
      weight: 90
    - name: model-v2-service # 신규 모델로 10% 트래픽 전송 (카나리)
      port: 8080
      weight: 10

 

어떻게 연결하는가?

Gateway와 Route의 연결되는 방식에 있어 유연성을 제공합니다.

1. 일대일 (1:1) - 전담 게이트웨이 모델

• 하나의 게이트웨이가 하나의 라우트만 관리합니다.
• 단일 소유자(팀)가 인프라부터 서비스 경로까지 모두 제어할 때 사용합니다. 보안이나 성능상의 이유로 특정 서비스에 독립된 인프라를 제공해야 하는 경우에 적합합니다.

2. 일대다 (1:N) - 공유 게이트웨이 모델 (가장 권장됨)

• 하나의 게이트웨이에 서로 다른 네임스페이스의 여러 팀이 소유한 라우트들이 연결됩니다.
• Gateway API의 '역할 분리' 철학이 가장 잘 드러나는 패턴입니다. 중앙 인프라 팀이 고가의 로드밸런서(Gateway)를 관리하고, 여러 서비스 팀은 각자의 네임스페이스에서 자유롭게 자신의 경로(Route)를 업데이트합니다.

3. 다대일 (N:1) - 멀티 게이트웨이 바인딩

• 하나의 라우트가 두 개 이상의 게이트웨이에 동시에 바인딩됩니다.
• 단일 애플리케이션 설정을 서로 다른 여러 네트워크 환경(예: 내부망 전용 IP와 외부 공인 IP)에 동시에 노출하고 제어할 때 유용합니다.
  또는 인프라 교체 시 무중단 전환을 위해 두 게이트웨이를 동시에 바라보게 할 수 있습니다.

https://gateway-api.sigs.k8s.io/concepts/api-overview/#example

https://gateway-api.sigs.k8s.io/concepts/api-overview/#combined-types

 

어떻게 사용하는가? (Use Cases)

1. 단순 North/East 연결

Gateway와 Route가 1대1로 연결하는 사례입니다. 워크플로를 예시로 들어 제공합니다.

1. 애플리케이션 개발자는 클러스터 운영자에게 클러스터 설정을 요청하며, 자신의 API가 https://ana.application.com/과 같은 URL 경로로 접속 가능해야 한다고 알립니다.
2. 클러스터 운영자는 인프라 제공자에게 가서 필요한 클러스터를 요청합니다.
3. 인프라 제공자는 basic-gateway-class라는 이름의 GatewayClass 리소스가 실행되는 클러스터를 준비합니다. 이 게이트웨이 컨트롤러는 클러스터 외부에서 내부로 들어오는 트래픽 라우팅에 필요한 인프라를 관리합니다.
4. 인프라 제공자는 클러스터 운영자에게 새 클러스터 접속 권한을 부여하고, basic-gateway-class라는 이름의 GatewayClass를 사용하여 설정을 진행할 수 있다고 알려줍니다.
5. 클러스터 운영자는 TLS 트래픽을 위해 443 포트를 수신받는 ana-gateway라는 이름의 Gateway를 생성합니다. 이때 해당 도메인에 맞는 TLS 인증서를 제공하고, 이 게이트웨이를 basic-gateway-class와 연결합니다.
6. 인프라 제공자가 준비했던 게이트웨이 컨트롤러는 ana-gateway를 위한 로드 밸런서와 IP 주소를 할당합니다. 또한 트래픽을 전달할 수 있는 데이터 플레인 컴포넌트들을 구성하고, 게이트웨이와 관련된 라우팅 리소스를 감시하기 시작합니다.
7. 클러스터 운영자는 게이트웨이의 IP 주소를 확인하여 외부 DNS 서비스에 도메인 이름(ana.application.com)과 매칭되는 DNS 레코드를 생성합니다.
8. 클러스터 운영자는 애플리케이션 개발자에게 ana-gateway를 사용할 준비가 되었다고 전달합니다.
9. 애플리케이션 개발자는 어떤 URL 경로가 어떤 마이크로서비스로 연결될지 정의하는 HTTPRoute 리소스를 작성하여 적용합니다. 이 라우트 리소스들을 Gateway API의 라우트 연결 프로세스를 통해 ana-gateway에 연결합니다.
10. 이제 로드 밸런서에 요청이 도착하면, 애플리케이션 개발자가 정의한 라우팅 규칙에 따라 각 애플리케이션 서비스로 정확하게 전달됩니다.

 

 

2. 공유 게이트웨이 연결

가장 대표적인 유스케이스로, 하나의 인프라(IP, 로드 밸런서)를 여러 팀이 안전하게 나누어 쓰는 상황입니다.
각 개발자들은 서로의 개발 사항을 신경쓸 필요 없이 본인들의 라우팅 규칙만 관리하면 됩니다.

https://gateway-api.sigs.k8s.io/concepts/use-cases/#multiple-applications-behind-a-single-gateway

 

3. 단순 East/West 연결

클러스터 내부의 서비스와 서비스 사이에서 발생하는 통신을 컨트롤합니다.
애플리케이션 개발자들은 인프라 제공자나 클러스터 운영자의 도움없이 Route를 정의하여 연결할 수 있습니다.

North/South 연결과 다른 점은 ParentRef 필드가 Gateway가 아니라 Service를 정의한다는 것입니다.
이는 해당 서비스로 향하는 모든 내부 트래픽에 대해서 이 규칙을 적용하겠다는 의미입니다.

 

왜 이렇게 나누었는가? 

• 최소 권한 원칙: 개발자는 보안 설정(TLS)이나 IP 할당(Gateway)을 건드릴 수 없고, 오직 자신의 서비스 경로(Route)만 수정할 수 있어 실수를 방지합니다.
• 독립적인 생명주기: 운영팀이 인프라를 교체(예: Nginx → Istio)하더라도, 개발자가 작성한 Route 설정은 표준 API이므로 그대로 유지됩니다.
• 전문성 강화: 각 역할은 자신이 가장 잘 아는 영역만 관리하면 됩니다. 개발자는 복잡한 네트워크 인프라를 공부할 필요 없이 라우팅 규칙에만 집중할 수 있습니다.

 

---

마치며

복잡한 Kubernetes의 네트워크를 단순화하고, 체계화 하기 위해서 많은 고민이 있었던 것 같습니다. 

특히 인프라 제공자, 클러스터 운영자, 그리고 애플리케이션 개발자가 서로의 영역을 침범하지 않고 각자의 전문 지식을 발휘할 수 있는 구조는, 현업의 니즈를 가장 정확히 꿰뚫은 설계라고 생각합니다.

앞으로 점점 많은 오픈소스들이 이 툴을 사용할 것으로 보이고, 이 변화에 빠르게 적응해나가야 할 것으로 느껴집니다.

 

참고

https://gateway-api.sigs.k8s.io/

Introduction - Kubernetes Gateway API