Kubernetes Gateway API v1.0: 전환해야 할까요?

Navendu Pottekkat

Navendu Pottekkat

December 15, 2023

Ecosystem

Kubernetes Gateway API가 v1.0 릴리스를 발표한 지 한 달이 넘었으며, 이는 주요 API 중 일부가 일반적으로 사용 가능한 상태로 졸업했음을 의미합니다.

작년에 Gateway API가 베타로 졸업했을 때 이에 대해 글을 썼지만, 1년이 지난 지금도 여전히 같은 질문이 남아 있습니다. Ingress API에서 Gateway API로 전환해야 할까요?

작년의 제 답변은 전환하지 말아야 한다는 것이었습니다. 그리고 그 이유는 _매우 강력_했습니다.

Gateway API와 그 구현체들은 아직 초기 단계였습니다. 반면, Ingress API는 안정적이었고 대부분의 사용자에게 적합한 주요 사용 사례를 다루고 있었습니다.

더 많은 기능이 필요한 사용자들에게는 이식성(다른 Ingress 구현체 간 전환)을 희생하고 Ingress 컨트롤러가 제공하는 커스텀 리소스를 사용할 것을 제안했습니다.

v1.0 릴리스와 함께 이 상황이 바뀔 수 있습니다. Gateway API는 이제 훨씬 더 강력해졌으며, 20개 이상의 구현체가 빠르게 따라잡고 있습니다.

따라서, 새로 시작하면서 Ingress와 Gateway API 중 하나를 선택해야 한다면, API와 선택한 구현체가 원하는 모든 기능을 지원한다면 Gateway API를 선택할 것을 권장합니다.

Ingress API의 문제점은 무엇인가요?

Ingress API는 잘 작동하지만, 일반적인 사용 사례의 작은 부분집합에만 적합합니다. 기능을 확장하기 위해 Ingress 구현체들은 커스텀 어노테이션을 사용하기 시작했습니다.

예를 들어, Nginx Ingress를 선택했다면, 수십 개의 어노테이션 중 일부를 사용하게 될 것입니다. 이는 Apache APISIX와 같은 다른 Ingress 구현체로 전환할 경우 이식성이 없습니다.

이러한 구현체별 어노테이션은 관리하기 번거롭고, Kubernetes 네이티브 방식으로 Ingress를 관리하는 목적을 훼손합니다.

결국, Ingress 컨트롤러 구현체들은 Kubernetes 사용자에게 더 많은 기능을 노출하기 위해 자체 CRD를 개발하기 시작했습니다. 이러한 CRD는 Ingress 컨트롤러에 특화되어 있습니다. 하지만 이식성을 희생하고 하나의 Ingress 컨트롤러에 고수할 수 있다면, CRD는 작업하기 더 쉽고 더 많은 기능을 제공합니다.

Gateway API는 Ingress API의 벤더 중립성과 CRD의 유연성을 모두 제공하여 이 문제를 한 번에 해결하려고 합니다. 이 목표를 달성하기에 매우 적합한 위치에 있습니다.

장기적으로, Ingress API는 새로운 기능을 추가하지 않을 것이며, 모든 노력은 Gateway API와 통합하는 데 집중될 것입니다. 따라서, Ingress API를 채택하면 기능의 한계에 부딪힐 때 문제가 발생할 수 있습니다.

명백한 이점

표현력, 확장성, 역할 지향적 설계는 Gateway API 개발의 핵심 아이디어입니다.

Ingress API와 달리, Gateway API는 여러 API(HTTPRoute, Gateway, GatewayClass 등)의 모음으로, 각각 다른 조직 역할에 맞춰 설계되었습니다.

예를 들어, 애플리케이션 개발자는 HTTPRoute 리소스만 신경 쓰면 되며, 여기서 트래픽을 라우팅하는 규칙을 정의할 수 있습니다. 클러스터 수준의 세부 사항은 클러스터를 관리하고 개발자의 요구를 충족시키는 운영자에게 위임할 수 있습니다.

Gateway API

이 역할 지향적 설계는 다른 사람들이 클러스터를 사용하면서도 통제를 유지할 수 있게 합니다.

Gateway API는 Ingress API보다 훨씬 더 강력합니다. Ingress API에서 어노테이션이 필요한 기능들은 Gateway API에서 기본적으로 지원됩니다.

공식 확장

Gateway API는 공식 Kubernetes API이지만, CRD 세트로 구현됩니다.

이는 기본 Kubernetes 리소스를 사용하는 것과 다르지 않습니다. 하지만 이 CRD를 설치해야 합니다.

APISIX의 Gateway API 지원

이는 Kubernetes가 장기적인 안정성을 위해 천천히 움직이는 것과 비교하여 빠른 반복을 가능하게 합니다.

확산될까요?

이 유명한 XKCD 만화가 자주 상기시키듯, 표준은 확산되는 경향이 있습니다.

이러한 버전은 Ingress와 Gateway API에서도 볼 수 있습니다. 일반적으로 다음과 같은 과정을 거칩니다:

  1. 다른 프로젝트/표준을 통합하기 위한 표준이 등장합니다(Kubernetes Ingress API).
  2. 통합된 표준에는 구현자들이 극복하고 싶은 한계가 있습니다(Ingress API는 제한적이었습니다).
  3. 이러한 한계로 인해 구현체들이 표준에서 벗어납니다(커스텀 CRD, 어노테이션).
  4. 각 구현체는 이제 자체 표준을 갖게 됩니다(이식성 없는 CRD, 어노테이션).
  5. 이러한 다른 표준을 통합하기 위한 새로운 표준이 등장합니다(Kubernetes Gateway API).

Gateway API가 여기서 끝이 아닐 수 있다고 생각하는 것은 합리적입니다. 하지만 저는 이것이 Kubernetes에서 라우팅을 위한 표준이 될 가능성이 충분하다고 믿습니다.

다시 말하지만, 제게는 강력한 이유가 있습니다.

표준 확산을 방지하기 위해서는 광범위한 채택이 중요합니다. 구현체들이 다른 표준을 개발할 유인이 줄어들기 때문입니다. Gateway API는 이미 25개 이상의 구현체를 보유하고 있습니다.

구현체는 Gateway API에 대해 다양한 수준으로 준수할 수 있습니다:

  1. 코어: 모든 구현체가 이를 준수해야 합니다.
  2. 확장: 일부 구현체에서만 사용 가능하지만 표준 API입니다.
  3. 구현체별: 구현체에 특화되었지만 표준 확장 포인트를 통해 추가됩니다.

니치 기능은 더 많은 구현체가 이를 지원함에 따라 구현체별에서 확장, 코어로 이동할 수 있습니다. 즉, API는 표준을 준수하면서도 커스텀 확장을 위한 여지를 제공합니다.

Service Mesh Interface (SMI) 프로젝트는 Kubernetes에서 서비스 메시를 구성하기 위한 표준화 시도였습니다. 그러나 이 프로젝트는 초기 서비스 메시 프로젝트들의 참여 이후 큰 관심을 받지 못하고 점차 사라졌습니다.

SMI는 사용자들이 서비스 메시에서 기대하는 공통 기능을 많이 지원하지 못했습니다. 또한 이러한 기능을 지원하기 위해 충분히 빠르게 움직이지 못했습니다. 결국, 서비스 메시 구현체들은 SMI 준수에서 뒤처지게 되었습니다(저는 CNCF TAG Network에서 SMI 준수를 보고하는 프로젝트를 진행하며 SMI와 밀접하게 작업했습니다).

이러한 보편적인 이유들로 인해, 이 프로젝트는 이제 Gateway API를 통해 부활하고 있습니다. 서비스 메시 관리 및 관리를 위한 Gateway API (GAMMA) 이니셔티브는 Gateway API를 서비스 메시와 함께 작동하도록 확장하려고 합니다.

SMI 프로젝트는 최근 GAMMA 이니셔티브와 통합되었으며, 이는 Gateway API에 매우 좋은 소식입니다. 가장 인기 있는 서비스 메시인 Istio도 앞으로 Istio를 관리하기 위한 기본 API로 Gateway API를 사용할 것이라고 발표했습니다. 이러한 채택은 확산을 방지합니다.

마이그레이션 가이드

Gateway API 문서에는 Ingress 리소스를 Gateway 리소스로 마이그레이션하는 포괄적인 가이드가 있습니다. 이를 다시 설명하는 대신, ingress2gateway 도구를 사용하여 Ingress 리소스를 Gateway API 리소스로 변환해 보겠습니다.

릴리스 페이지에서 운영 체제에 맞는 바이너리를 직접 다운로드하여 설치할 수 있습니다.

간단한 Ingress 리소스를 살펴보겠습니다:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: httpbin-route
spec:
  ingressClassName: apisix
  rules:
    - host: local.httpbin.org
      http:
        paths:
          - backend:
              service:
                name: httpbin
                port:
                  number: 80
            path: /
            pathType: Prefix

이는 제공된 호스트 주소의 모든 트래픽을 httpbin 서비스로 라우팅합니다.

이를 Gateway API 리소스로 변환하려면 다음을 실행할 수 있습니다:

ingress2gateway print --input_file=ingress.yaml

이 Gateway API 리소스는 다음과 같습니다:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: httpbin-route
spec:
  hostnames:
  - local.httpbin.org
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: httpbin
      port: 80

실행 가능한 대안

Kubernetes에서 게이트웨이를 구성하기 위한 다른 실행 가능한 대안들이 있습니다.

Apache APISIX에서는 독립 실행 모드로 배포하고 yaml 파일에 라우트 구성을 정의할 수 있습니다. 이 yaml 파일을 전통적인 워크플로우를 통해 업데이트할 수 있으며, Kubernetes API를 통해 게이트웨이 구성을 관리할 필요가 없는 시나리오에서 매우 유용할 수 있습니다.

구현체별 커스텀 CRD도 다른 솔루션으로 전환할 계획이 없거나 구성이 쉽게 마이그레이션할 수 있을 만큼 작다면 실행 가능한 대안입니다.

어쨌든, Gateway API는 여전히 존재할 것입니다.

Tags:
Gateway API
Kubernetes