K8s Gateway API

k8s Gateway API 는 기존 Ingress 한계를 극복, 클러스터 내외부의 네트워크 트래픽을 유연하고 표준화된 방식으로 관리하기 위해 탄생했다고 한다.
사실 Ingress 만으로는 표준화된 기능이 없어서, annotation 으로 지정하거나 하는 등 쿠버네티스에서 오류를 검출할 수 없었다.
왜냐하면 공식적으로 지원하는 기능이 아니기 때문에...
그런 관점에서 손쉽게 사용하기 위해 탄생한게 Gateway API 가 아닌가 싶다.

무엇보다 Ingress 로 구현하면 멀티 테넌시 환경에서 독립적으로 개발이 어렵기 때문에 이러한 점을 개선하여, 리소스 모델을 제공하고 클러스터 운영자, 인프라 제공자, 애플리케이션 개발자 등 각각 범위에 맞게 운영이 가능하다.

핵심 리소스

1. GatewayClass :

- 게이트웨이의 동작 방식을 정의하는 상위 클래스 
- 클러스터 수준에서 관리, 특정 게이트웨이 구현체와 연결

2. Gateway :

- 실제 네트워크 트래픽을 처리하는 인프라 인스턴스
- 하나 이상의 Listener 를 통해 외부 트래픽을 수신, 해당 트래픽을 적절한 Route 로 전달

3. Route (HTTPRoute, TCPRoute 등)

- Gateway를 통해 들어오는 트래픽을 백엔드 서비스로 라우팅하는 규칙을 정의
- HTTPRoute 는 호스트명, 경로, 헤더 등을 기반으로 트래픽 분기가 가능

이러한 특징을 가지고 있는 Gateway API 는 Ingress 에서 annotation 을 통해 간접적으로 설정하던 기능을 명시적으로 정의가 가능하다.
또한 클러스터 운영자, 인프라 운영자, 애플리케이션 개발자 각각의 범위에서 리소스를 관리할 수 있도록 설계되어 있어서, 협업 측면에서 유리함.
다양한 프로토콜도 지원하기 때문에 복잡한 네트워크의 요구사항도 충족시킬 수 있다.

 

활용 사례

1. 멀티 테넌시 환경

여러 개발팀이 하나의 클러스터를 공동으로 사용하는 경우에 각 팀에 별도의 HTTPRoute 를 할당하여 독립성을 확보할 수 있다.
Gateway 는 인프라 팀에서 담당하고, Route 는 애플리케이션 개발자가 관리하여 독립적인 셈.
네임스페이스 간 격리, 권한 제어등을 쉽게 구현할 수 있게 된다.

2. 고급 트래픽 분기 및 제어

트래픽을 조건에 따라 세분화가 필요할 때, 예를 들어 URL 경로, 호스트, HTTP 헤더 등을 기준으로 라우팅이 가능함.
/api/v1/* 은 기존 서비스, /api/v2/* 는 신규 버전으로 전송하는 등에 활용할 수 있다.

3. Canary 배포 / A,B 테스트

새로운 버전이 배포될 때 HTTPRoute 를 통해 트래픽 가중치를 설정하여 Canary 로 활용이 가능함.
혹은 쿠키/헤더 값을 기반으로 A/B 테스트도 가능

4. gRPC, TCP, UDP 등 다양한 프로토콜 지원

기존 Ingress 에서 불가능했던 HTTP 외 서비스도 지원 (TCPRoute, UDPRoute, GRPCRoute)

5. 서비스 메시 통합

Istio, Linkerd 등 외부 서비스와 함께 사용할 때 해당 istio-ingressgateway 를 GatewayClass 로 등록하여 Gateway API 를 통해 외부 진입점을 제어할 수 있다.

6. Public & Private Gateway 분리

외부, 내부 트래픽을 분리하려면 GatewayClass 를 두 가지로 설정, 하나는 public-gateway, 다른건 internal-gateway
외부용은 LB 로 , 내부용은 ClusterIP 로 설정하여 사용한다.

7. DNS 기반 라우팅 및 다중 호스트 처리

도메인 별로 서로 다른 서비스 연결도 가능하고, HTTPRoute 에서 hostnames 에 2개의 도메인을 연결하여 다중 도메인 처리도 가능하다.

 

예시

1. GatewayClass

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: example-gateway-class
spec:
  controllerName: example.net/gateway-controller

게이트웨이 클래스 이름과 controllerName 등을 설정하여 선언할 수 있다.

2. Gateway

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
  namespace: default
spec:
  gatewayClassName: example-gateway-class
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      hostname: "example.com"

앞서 게이트웨이 클래스 이름을 등록하여 Class 를 연결해주며, listeners 를 등록해준다.
gateway 인스턴스를 배포하면 리스너가 실행되어, 해당 호스트 포트의 트래픽을 수신한다.

3. HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
  namespace: default
spec:
  parentRefs:
    - name: example-gateway
  hostnames:
    - "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

canary 배포에 사용되는 HTTPRoute 예시이다.
namespace 등을 지정하여 격리를 제공하며, parentRefs 는 gateway 의 이름을 지정해준다. 
즉 어떤 리스너로 부터 수신된 트래픽들을 어떻게 라우팅해줄지 처리해주는 과정이다.
hostnames 을 지정해주고, rules 에는 weight 를 통해 서비스마다 가중치를 준다. 이러한 방식으로 명시적으로 canary 구현이 가능하다.

 

ref.

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

Introduction - Kubernetes Gateway API