Istio Gateway vs Gateway API

이전 문서에서는 Istio에서 제공하는 virtualservice와 gateway를 사용한 부분을 다루었다. 하지만 2023년 3월 8일에 kuberentes 재단에서 공식적인 GatewayAPI를 정식버전으로 올린후 Istio도 그에 맞추어 GatewayAPI를 사용하기로 마음을 먹은 거같다. 

사실 나는 Istio에 대해 gateway, virtualService, destinataionRule등 많은 부분들을 사용해보기도 했지만 GatewayAPI는 다소 생소한 부분이 있다. 그럼 왜 ?? GatewayAPI를 사용해야 하는지 알아보자. 

(GatewayAPI는 공식문서를 참조하자 나중에 쓸 일이 있을거같지만.. 공식문서 :https://gateway-api.sigs.k8s.io/)

 

일단 요즘 Istio의 Sidecar 공식문서에서도 두 가지를 가지고 가이드를 한다. (istio Gateway, GatewayAPI) 물론 isto Gateway를 버려라!! 이런건 아니다. Multi Cluster를 사용할 때도 필요할 수도 있기에 꼭 Gateway API만써야 돼! 이런건 아닌거 같다. 그래서 이번 글에서는 GatewayAPI에 대해 알아보고 istio가 GatewayAPI를 어떤식으로 활용해 나가는지 진짜 간단히 알아보자!!

 GatewayAPI란?

Kubernetes에 native한 방식 (CRD로 배포)
Kubernetes의 일부인 API 모음으로, 트래픽 라우팅 및 관리에 중점
L4, L7에 중점을 둔 kuberentes 공식 프로젝트

 

설명은 이와같다. 간단히 말하자면 GatewayAPI는 기존에 사용하던 ingress나 istio의 virtualService, Gateway에 동일한 역활을 수행하는 부분이다 라고 생각하면 쉽다. 

gatewayAPI Yaml을 한번 보며 어떤식의 흐름을 가는지 이해해보자

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway
  namespace: istio-ingress
spec:
  gatewayClassName: istio
  listeners:
  - name: default
    hostname: "*.example.com"
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: All
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: http
  namespace: default
spec:
  parentRefs:
  - name: gateway
    namespace: istio-ingress
  hostnames: ["httpbin.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /get
    backendRefs:
    - name: httpbin
      port: 8000

 

yaml의 내용을 보면 Gateway의 apiVersion은 istio가아니고 k8s crd로 배포된 gatewayAPI임을 볼 수 있다. 그리고 HTTPRoute부분이다 이부분은 virtualService와 기능은 비슷하게 작동하면 된다고 보면된다.

yaml을 보았을때 딱히 기본적으로  gateway와 virtualService을 이해한다면 사용에는 크게 무리는 없을 것으로 보여진다.

 

그리고 istio Gateway를 k8s API gateway를 사용할때 어떤식으로 사용해야하는지.. VirtualService를 사용할때는 어떤식으로 사용해야하는지는 https://github.com/kubernetes-sigs/ingress2gateway/blob/main/pkg/i2gw/providers/istio/README.md 해당 문서를 통해 확인해보고 적용도 해보면 좋을 거같다. 

어떤 Gateway를 사용해야 할까??

 

공식홈에서 써준 document 글에서는 아래의 표를 제공해주었다.

API Name	Object Types	Status	Recommedation
Gateway APIs	HTTPRoute, Gateway, …	Stable in Gateway API v1.0 (2023)	새로운 deployments를 배포하거나 ambient 모드에 사용
Istio APIs	Virtual Service, Gateway	v1 in Istio 1.22 (2024)	기존배포 또는 고급기능이 필요한 경우
Ingress API	Ingress	Stable in Kubernetes v1.19 (2020)	legacy한 배포에 사용

 

표와 같이 ambient모드라면 GatewayAPI를 사용해야한다고 봐야한다. 그리고 kuberentes에서 관리하는 GatewayAPI는 확실히 istio 쪽에서도 미래적인 부분으로 사용하기 위해 노력을 하는 모습을 볼 수 있고 또한 Istio Crd를 v1으로 버전 업을 한 이유도지속적으로 장기적으로 유지를 하겠다는 입장을 가지고 있다.

---

 

정리하자면 정답은 없다!! 현재 상황에 맞는대로 사용하는게 중요한거 같다.

 

하지만 대규모 서비스에서 envoy sidecar는 대규모 클러스터에서는 한개한개가 합쳐져서 자원을 차지하는 단점인 요소가 분명해지고 있는 상황이다.. 그렇다면 언젠가는 ambient모드로 가게되고 그때에는 gatewayAPI가 표준이 되지도 않을까하는 생각도 해본다.. 그렇기에 gatewayAPI도 추후에 다루는 법과 여러가지 연동방법도 가이드 작성을 해보아야겠다!!

 

참고 : https://istio.io/latest/blog/2024/gateway-mesh-ga/