Istio ingress gateway VS API Gateway (istio ver. 1.19)

개요

Service mesh가 클러스터 내부 서비스간 트래픽 관리 (”east-west” traffic)를 담당한다면 API Gateway는 client와 backend간 트래픽 관리 (”north-south” traffic)를 담당한다.
istio는 0.8 버전 이전 버전에서 쿠버네티스의 ingress를 트래픽 포털로 사용했으나, 0.8 버전부터 gateway 리소스를 베타로 지원한다. (둘 다 ingress controller로 envoy 프록시 사용)
gateway 리소스가 추가되면서 mesh 서비스에서 어떤 api gateway를 사용해야 할 지, api gateway (e.g., zuul, kong)를 istio ingress gateway가 대체할 수 있을지에 대한 궁금증이 생기기 시작했다. 이 글에서는 api gateway, istio gateway, kubernetes ingress를 비교해보며 어떤 api gateway가 service mesh에 적합한지 알아본다.

개념 소개

이 글에서는 istio gateway와 api gateway 비교를 중점으로 이야기 할 것이기 때문에 각 개념들은 짧은 소개만 진행한다.

Ingress는 api gateway나 istio gateway와 다른 역할을 하기 때문에 동일 선상에서 비교할 수 없음에 주의

Kubernetes Ingress

Kubernetes ingress는 쿠버네티스 구성요소 중 하나로 rule base loadbalancing, canary update, TLS, 가상 호스트 기능을 갖고 있다.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: istio
  name: ingress
spec:
  rules:
  - host: httpbin.example.com
    http:
      paths:
      - path: /status/*
        backend:
          serviceName: httpbin
          servicePort: 8000

kubernetes.io/ingress.class 어노테이션으로 어떤 ingress controller를 적용할 지 선택하고 있다. ingress controller를 클라우드 플랫폼 기능으로 자체 제공하고 있는데 이 어노테이션 지정을 하지 않으면 자체 ingress controller의 규칙을 적용시킨다.

 
하지만 쿠버네티스 Ingress는 비교적 기능이 적고, L7 레이어에 대한 규칙만 구성 할 수 있다는 한계를 갖고 있다. 이를 해결하기 위해 ingress 앞 단(클러스터 앞)에 api gateway 또는 istio gateway를 두어 L7에 특화된 기능을 수행하도록 했다.
(aws에서 제공하는 api gateway가 아니라 kong과 같이 클러스터 내부에 배포되어야 하는 경우도 있으므로, 명확한 설명은 아니나 쉬운 이해를 위해 클러스터 앞 단이라 표현함)

Istio gateway

Istio gateway는 mesh의 edge와 서비스를 연결하는 로드밸런서 역할을 한다는 점에서 “north-south” 트래픽을 담당한다고 볼 수 있다. Istio gateway 자체는 L4~L6에 대한 구성만 가능하지만, VirtualService에 L7 규칙을 구성하여 바인딩 시킬 수 있다.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: httpbin-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "httpbin.example.com"

 
selector 필드로 istio라는 키와 ingressgateway라는 값을 라벨로 가진 pod을 선택한다.

실제로 pod으로 배포되어 있는 istio-ingressgateway를 살펴보면 app=istio-ingressgateway와 istio=ingressgateway라는 라벨을 확인할 수 있다.
(따라서 istio: ingressgateway 대신 app: istio-ingressgateway라고 선택하거나, envoy가 있는 다른 pod의 라벨 선택도 가능하다.)

API gateway

API gateway는 클라이언트와 서버 사이에 위치해서 클라이언트 인터페이스를 서버로부터 분리하여 decoupling 목적으로 사용되는 api 관리 도구이다. API를 외부로 부터 숨겨 보호하거나 요청받은 프로토콜을 서비스에서 지원하는 프로토콜로 변경하는 등 다양한 기능을 제공한다.
zuul, kong, Gloo 같은 서비스가 유명하다.

API gateway, Istio gateway 비교

	API gateway	Istio gateway	비고
Telemetry 수집	O	O
분산 추적	O	O
Service discovery	O	O
Load balancing	O	O
TLS	O	O
JWT 인증	O	O
요청 라우팅	O	O
트래픽 분기	O	O
Canary 업데이트	O	O
트래픽 shadowing	O	O
API Throttling	O	O
요청 / 응답 변환	O	X	Boundary decoupling
Protocol 변환	O	X	"
직접 응답	O	X	"
프록시 파이프라인 정밀 제어	O	X	"
API 그룹화	O	X	"
데이터 / 요청 통제	O	X	Edge security
Caching	O	X

istio 버전과 api gateway 종류에 따라 지원 여부가 달라질 수 있음

 
API gateway는 istio gateway는 제공하지 못하는 세 가지 주요 기능을 제공한다.

• boundary decoupling
• 요청에 대한 엄격한 제어
• 신뢰 도메인 보안

Boundary decoupling

api 인터페이스를 클라이언트에게 제공하여 안정적인 api를 제공한다.
세부적으로 보면 아래의 기능들을 제공한다.

• 요청 / 응답 변환 (Request / response transformation)
  • 헤더 추가 or 제거, 본문에 헤더 배치, 요청 포맷 변경 등
• protocol 변환 (Application protocol transformations)
  • http, https 뿐만 아니라 XML, SOAP, JSON, rSocket 등 요청된 프로토콜을 변환
• 직접 응답 (Direct responses)
  • 신뢰할 수 없는 클라이언트 또는 차단된 리소스를 요청 시 미리 준비된 응답 반환
• 프록시 파이프라인 정밀 제어 (Precise control over Proxy pipeline)
  • api gateway의 기능들이 적용되는 순서 (라우팅, 변환, rate limit 등) 변경 및 디버깅 기능
• API 그룹화 (API composition)
  • 여러 API를 묶어 하나의 API처럼 사용하는 기능

요청에 대한 엄격한 제어

서비스로 들어오고 나가는 데이터에 대해 허용 여부를 추가해 요청을 더 엄격하게 통제할 수 있다. 예를 들어 SQL Injection이 우려되는 요청에 대한 통제를 할 수 있다.

신뢰 도메인 보안

요청에 대한 엄격한 제어기능을 이용해 OIDC, Single Sign On에 대해 접근 가능한 사용자를 정의할 수 있다.

API gateway와 istio’s gateway의 경계에 대해

API gateway가 istio의 gateway에 비해 다양한 기능을 제공하는 것을 알 수 있었다.
하지만 실무적으로 따졌을 때 아래와 같은 내용을 고려해야 한다.

1. API gateway의 주요 기능 대부분은 istio gateway에서도 지원 중이다.
2. API gateway를 도입할 경우 관리 포인트가 늘어나며 별도의 설치를 진행해야 한다.
3. Istio gateway를 사용하다가 추가 기능이 필요할 경우 API gateway를 함께 사용할 수 있다.

새로운 istio’s gateway 버전이 업그레이드 될 때마다 점차 기능이 추가되고 있으며, 위에서 지원되지 않는다고 언급한 기능들(예를 들어 커스텀 응답, 직접 응답, 헤더 조작 등) 또한 envoy filter를 이용해 구현할 수 있다.

Envoy filter의 기능을 알고 싶다면 아래 페이지에서 확인 가능
https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/filter/filter

https://gateway-api.sigs.k8s.io/blog/2023/0829-mesh-support/

많은 api gateway 서비스들도 istio gateway를 통합하는 모습을 보이고 있으며(e.g., Kong Istio gateway), 8월 29일 쿠버네티스도 공식적으로 istio (v1.16+)가 gateway api (v0.8.0)를 완벽하게 지원한다는 발표를 했다. 이런 양상을 볼 때 앞으로 kubernetes’ ingress, istio’s gateway, api gateway의 구분이 점차 희미해 질 것으로 예측된다.

---

Reference

• https://jimmysong.io/en/blog/istio-servicemesh-api-gateway/
• https://blog.christianposta.com/microservices/do-i-need-an-api-gateway-if-i-have-a-service-mesh/
• https://blog.christianposta.com/microservices/api-gateways-are-going-through-an-identity-crisis/
• https://gateway-api.sigs.k8s.io/blog/2023/0829-mesh-support/
• https://tetrate.io/blog/istio-service-mesh-api-gateway/
• https://www.zhaohuabing.com/post/2019-04-16-how-to-choose-ingress-for-service-mesh-english/