title: API Gateway + Service Mesh = Kubernetes Gateway API
description: API Gateway와 Service Mesh의 통합을 위한 방안으로서의 k8s Gateway API에 대해 논한다.
cleanUrl: /sw-engineer/kubernetes-gateway-api-2
ogImage: "<https://oopy.lazyrockets.com/api/v2/notion/image?src=https%3A%2F%2Fprod-files-secure.s3.us-west-2.amazonaws.com%2F7570d2fc-66b1-4e23-bb3c-ff7b56842b0d%2F4dc568f5-f8a9-450d-b94d-622387ed93ae%2FUntitled.png&blockId=900c9c56-c3e4-43df-bd23-f4f747b4db88>"
floatFirstTOC: right
API Gateway와 Service Mesh의 통합을 위한 방안으로서의 k8s Gateway API에 대해 논한다.
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 추가는 결국 이중 중복을 유발한다. 불편한 마음이 몰려든다.
본 주제에 키가 되는 주요 용어 먼저 설명한다.
이들 두 용어 관점에서 보자면 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/
이러한 배치는 그다지 낯선 경우가 아니며, 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를 다룬다는 점 정도이다), 명칭에서도 보듯, 서로 다른 요구에 의해 각기 다른 지점에서 출발했음에 있지 않나 싶다.