⚽

API Gateway + Service Mesh = Kubernetes Gateway API

Introduction

API Gateway와 Service Mesh의 통합을 위한 방안으로서의 k8s Gateway API에 대해 논한다.

Motivation

Service Mesh, 예컨데 istio의 경우, internet facing service에 대해 virtual service에 기반한 traffic 관리를 위해서는 istio ingress gateway가 필요하다. 이는 명칭에도 보듯 아키텍처 상 API Gateway와 또 다른 중복이다.

앞선 글인 Ingress + API Gateway = Kubernetes Gateway API에서 위와 같이 문제를 제기했지만 k8s Gateway API가 이를 어떻게 해결하는지에 대해서는 언급하지 않았다. 사실, API Gateway 앞단에 load balancer나 ingress를 위치시키는 것은 network topology 상 역할 중복임에도 여러 이유로 일반적일 것이라 예상한다(e.g. ingress/L4 load balancer vendor ≠ API Gateway vendor). 이러한 상황에 ingress gateway 추가는 결국 이중 중복을 유발한다. 불편한 마음이 몰려든다.

North-Sourth traffic과 East-West traffic

본 주제에 키가 되는 주요 용어 먼저 설명한다.

•

North-South traffic : 클러스터 내외로 발생하는 트래픽이다.

•

East-West traffic : 클러스터 내에서 각 workload 간에 흐르는 트래픽이다.

이들 두 용어 관점에서 보자면 API Gateway는 Noth-South traffic를 다루는 모듈이다. 이 traffic은 API Gateway를 이후로 끝나거나(API Gateway에 연결된 worload에서 처리가 끝나는 경우), East-West traffic으로 전환된다(API Gateway에 연결된 service가 타 worload를 호출하는 경우). Ingress + API Gateway = Kubernetes Gateway API 는 본 관점의 설명임과 동시에 아래 그림은 바로 이 상황을 나타낸다.

North-South traffic과 East-West traffic의 차이 및 API Gateway 와의 관계 이미지 출처 : https://glasnostic.com/blog/what-is-an-api-gateway-aws-express-kong/

하지만 API Gateway가 cluster 내부, 타 workload와 동일 cluster 내에 위치한다면?

이러한 배치는 그다지 낯선 경우가 아니며, CSP 제공이 아닌 API Gateway를 사용할 경우 오히려 일반적이라 예상한다. 이 경우 API Gateway는 위의 용어 정의에 따라 East-West traffic 역시 처리 대상이 되어 버린다. 그리고 이 East-West traffic의 실체는 다름 아닌 North-South traffic으로, 동일 traffic을 관점에 따라 나뉜 것일 뿐이다. 이 경우 위 그림의 API Gateway는 아래와 표현 가능하다.

East-West traffic을 나타내는 푸른색 테두리 참조. 앞선 그림과는 달리, cluster 내부의 API Gateway는 Noth-South traffic 뿐 아니라 East-West traffic도 담당한다. 그리고 이들 두 traffic은 사실 동일 traffic이며 관점에 따라 나뉠 뿐이다.

단순 용어 상 분류 아니냐 싶겠는데 실상은 그렇지가 않다. East-West traffic은 일반적으로 North-South traffic과는 달리 Service Mesh가 담당하기에 다음의 문제가 발생하기 때문이다.

클러스터 내에 위치한 API Gateway에서의 traffic은 API Gateway 또는 Service Mesh 중 누가 담당해야 하는가?

사실, 이 문제의 근본적 원인은 API Gateway와 Service Mesh가 기술적으로 본질이 동일함에도(이들 둘 모두 사실 proxy에 기반하며, 다른 점이라면 Service Mesh는 여러 proxy를 다룬다는 점 정도이다), 명칭에서도 보듯, 서로 다른 요구에 의해 각기 다른 지점에서 출발했음에 있지 않나 싶다.

API Gateway + Service Mesh = k8s Gateway API

위 문제를 해결하는 가장 직관적인 방법은 API Gateway와 Service Mesh용 gateway(e.g. istio ingress gateway)의 직렬 연결이지만, Motivation에서 언급한 중복 이슈를 유발한다. 이에 대한 전형적인 해결안은 둘을 하나로 합치는 것이다. 나아가 cluster 내 API Gateway에서의 North-South와 East-West traffic는 동일 실체임을 감안하자면 이 해결안의 타당성은 더욱 강화된다.

k8s Gateway API는 이 해결안의 구현물로서, 2023.10.03 현재 The GAMMA initiative (Gateway API for Service Mesh)란 이름으로 k8s Gateway API 하위로 구현되고 있다.

Gateway API는 원래 클러스터 외부 클라이언트에서 클러스터 내부 서비스(ingress 또는 North/South 케이스)로의 트래픽을 관리하도록 설계되었습니다. 그러나 시간이 지남에 따라 Service Mesh 사용자의 관심으로 인해 2022년에 GAMMA(Gateway API for Mesh Management and Administration) 이니셔티브가 생성되어 Gateway API가 서비스 간 또는 동일한 클러스터 내의 East-West 트래픽 관리에 사용될 수 있는 방법을 정의하게 되었습니다.

위의 The GAMMA initiative (Gateway API for Service Mesh)의 설명은 단순히 API Gateway 관점에서 Service Mesh 기능을 통합하는 수준을 넘어, Service Mesh 자체에 대한 지원을 논한다. 그리고 이에 대한 구현으로, 새로운 리소스 정의 도입이 아닌 Ingress + API Gateway = Kubernetes Gateway API 에서 논했던 HTTPRoute를 그대로 활용한다. 즉, 단일 구현체(HTTPRoute)에 API Gateway와 Service Mesh 모두를 지원한 것이다. 다음은 Service Mesh 관점에서 사용된 HTTPRoute 의 예이다.

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: httpbin
spec:
  parentRefs:
  - group: ""
    kind: Service # HTTPRoute 적용 대상 종류. 여기서는 k8s Service를 의미
    name: httpbin # HTTPRoute 적용 대상이 되는 k8s Service 이름
  rules:
  - matches:
    - path: # /status path를 prefix로 하는 traffic에 대해 적용
        type: PathPrefix
        value: /status
    - path: # /delay path를 prefix로 하는 traffic에 대해 적용
        type: PathPrefix
        value: /delay
    backendRefs: # httpbin k8s Service의 8000 port로 traffic을 routing
    - name: httpbin
      port: 8000
YAML
복사

위 예는 앞선 글의 HTTPRoute 예와 동일하나, parentRefs field만 달라, API Gateway로부터의 outbound 트래픽이 아닌, httpbin이란 k8s Service로의 inbound 트래픽을 정의한다. 이를 정리하자면 다음과 같다.

•

k8s Gateway API는 API Gateway 뿐 아니라 Service Mesh를 지원한다.

•

k8s Gateway API는 API Gateway의 routing 규칙과 Service Mesh의 routing 규칙을 통합한다.

상기 HTTPRoute를 istio의 virtual service로 변환하면 다음과 같은 형태가 된다.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - httpbin
  http:
  - match:
    - uri:
        prefix: /status
    - uri:
        prefix: /delay
    route:
    - destination:
        host: httpbin
        port:
          number: 8080
YAML
복사

k8s Gateway API 진행, 지원 현황

k8s Gateway API는 2023.10.3 기준으로 beta 버전이며, version은 0.8.0이다. 공식 문서의 blog 기준으로 2021.10.14에 v1 alpha2가 나왔으니, 이것만으로도 사실 상 2년을 넘기는 느린 진행으로 보이지만 어쨌건 최종 결과를 향해 나아가는 것으로 보인다. version 0.8.0은 약 한달 전에 나왔으며 바로 이 시점에 Service Mesh 지원을 이룬 듯(링크 참고).

beta와 낮은 버전 상황임에도 이를 무시할 수 없는 것은, 무엇보다 이 beta 버전을 istio 공식 버전에서 지원하고 있기 때문이다(Kiali 또한 지원 중이다. 링크 참고). 나아가 GKE, NGINX Gateway, Linkerd, Kong 등 주요 API Gateway, Service Mesh vendor 역시 여타 많은 vendor와 함께 이를 지원 중이다(링크 참고).

istio 공식 문서에서는 대부분의 예제에 istio API와 함께 Gateway API를 제공한다. 나아가 앞으로 Gateway API를 default API로 사용할 것임을 아래와 같이 명시한다. Istio includes beta support for the Kubernetes Gateway API and intends to make it the default API for traffic management in the future. The following instructions allow you to choose to use either the Gateway API or the Istio configuration API when configuring traffic management in the mesh. Follow instructions under either the Gateway API or Istio APIs tab, according to your preference.

2023.11.18 업데이트 : version 1.0.0 GA release

2023.10.31에 version 1.0.0 GA가 release되었다. 이와 함께 위와 같이 별도의 로고도 만들어졌는데, 앞서 설명한 north-south와 east-west traffic 모두를 다루는 의미라고 한다. 0.9 없이 앞선 version 0.8.0에서 바로 버전이 뛰었는데, 변경 사항은 그리 크지 않은 것으로 보인다(앞선 설명 모두 유효).

Gateway API v1.0: GA Release

Authors: Shane Utt (Kong), Nick Young (Isovalent), Rob Scott (Google) On behalf of Kubernetes SIG Network, we are pleased to announce the v1.0 release of Gateway API! This release marks a huge milestone for this project. Several key APIs are graduating to GA (generally available), while other significant features have been added to the Experimental channel. What's new Graduation to v1 This release includes the graduation of Gateway, GatewayClass, and HTTPRoute to v1, which means they are now generally available (GA).

https://kubernetes.io/blog/2023/10/31/gateway-api-ga/

Wrap-up

앞선 Ingress + API Gateway = Kubernetes Gateway API 의 논의까지 포함하여 결론짓자면, k8s Gateway API는 사실 상 ingress + API Gateway + Service Mesh에 해당한다. 이는 Kubernetes 표준 범위에 신규로 API Gateway와 Service Mesh를 추가한 것임과 동시에 ingress를 대체하는 큰 변화로서 결코 무시할 수 없는 사항이다. 나아가 istio의 경우 Service Mesh를 포함한 Gateway API를 정식 지원하는 상황으로, Gateway API는 이미 사용 가능 범위 안에 들어와 있다.