Kubernetes Gateway API 사용해야 하는 5가지 이유

Kubernetes 커뮤니티는 Ingress 리소스에 대한 더 나은 대안을 제공하는 새로운 프로젝트인 Gateway API 를 사용해야 하는 5가지 이유와 함께 Ingress 리소스와 비교하는 방법에 대해 설명합니다. 또한, NGINX 를 Data Plane으로 활용하면서 Kubernetes 클러스터에서 Gateway API를 사용할 수 있게 해주는 오픈 소스 프로젝트인 NGINX Gateway Fabric에 대해서도 소개합니다.

초기부터 Kubernetes 는 service로의 외부 HTTP 트래픽 요청 라우팅을 구성하기 위한 API(built-in ingress resource)를 포함했습니다. 사용자가 널리 채택하고 많은 구현(예: Ingress Controller)에서 지원하지만, Ingress 리소스는 크게 세 가지 방식으로 사용자를 제한합니다:

  • 기능 부족 – 지원되는 사용 사례 수가 줄어듭니다.
  • 확장성 모델 부족 – NGINX와 같은 많은 Data Plane 에서 사용할 수 있는 고급 기능에 대한 액세스가 제한됩니다.
  • 다양한 사용자 역할 부족 – 클러스터 내의 여러 팀 간에 Data Plane 인프라를 안전하게 공유하지 못합니다.

참고 : Gateway API는 실험적인 Service Mesh를 포함하여 service 네트워킹과 관련된 여러 사용 사례를 지원합니다. 하지만 이 포스트에서는 클러스터의 service로 외부 트래픽을 라우팅하는 Gateway API의 주요 사용 사례에 중점을 둡니다. 또한, API는 여러 프로토콜을 지원하지만, 가장 일반적인 프로토콜인 HTTP로 논의를 제한합니다.

목차

1. Gateway API 개요
2. Gateway API를 사용해야 하는 이유는 무엇인가요?
2-1. 지원되는 기능의 수
2-2. 강력한 확장성 모델
2-3. 역할 분리
2-4. 이식성
2-5. 커뮤니티
3. Gateway API를 사용해 보는 방법
4. 요약

1. Gateway API 개요

Gateway API는 클러스터의 service에 대한 service 네트워킹 트래픽을 모델링하기 위해 Data Plane을 프로비저닝하고 구성하는 사용자 지정 리소스 모음입니다.

이것이 기본 Gateway API 리소스입니다:

  • GatewayClass – 아직 프로비저닝되지 않은 Data Plane에 대한 템플릿을 정의합니다.
  • Gateway – 템플릿(GatewayClass)에서 Data Plane을 프로비저닝하고 외부 트래픽을 받아들이기 위한 진입점(포트)을 구성합니다.
  • HTTPRoute – 클러스터의 service에 대한 외부 트래픽의 HTTP 요청 라우팅 규칙을 구성하고 이러한 규칙을 Gateway에 정의된 엔트리 포인트에 연결합니다.

Gateway API의 또 다른 중요한 부분은 Gateway 구현으로, Gateway API 리소스에 따라 실제로 Data Plane을 프로비저닝하고 구성하는 Kubernetes Controller 입니다.

API에 대해 자세히 알아보려면 Gateway API 프로젝트 웹사이트를 방문하거나 소개 동영상을 시청하세요.

2. Gateway API 사용해야 하는 이유는 무엇인가요?

새로운 Gateway API를 사용해야 하는 5가지 이유는 다음과 같습니다:

  • 지원되는 기능의 수
  • 강력한 확장성 모델
  • 역할 분리
  • 이식성
  • 커뮤니티

각 이유를 자세히 살펴보겠습니다.

2-1. 지원되는 기능의 수

Gateway API는 다양한 기능을 제공하여 수많은 사용 사례를 열어주며, 그중 일부는 Ingress 리소스에서 완전히 지원되지 않을 수 있습니다.

이러한 사용 사례는 다음과 같습니다.

  • Canary Release
  • A/B testing
  • 요청 및 응답 조작
  • 리다이렉션 요청
  • 트래픽 미러링
  • Namespace 간 트래픽 라우팅

예를 들어, 아래는 가중치를 사용하여 두 개의 Kubernetes service 간에 트래픽을 분할하는 HTTPRoute의 요청 라우팅 규칙입니다. 이를 통해 Canary Release 사용 사례를 활성화할 수 있습니다.

- matches: 
  - path: 
      type: PathPrefix 
      value: / 
  backendRefs: 
  - name: my-app-old 
    port: 80 
    weight: 95 
  - name: my-app-new 
    port: 80 
    weight: 5

결과적으로 Data Plane은 요청의 95%를 내 앱 이전 service로 라우팅하고 나머지 5%는 내 앱 새 service로 라우팅합니다.

다음은 두 가지 규칙이 포함된 예제입니다. 이 규칙 중 하나는 라우팅을 위해 헤더와 쿼리 매개변수를 사용하는 Gateway API 고급 라우팅 기능을 활용합니다.

- matches: # rule 1 
  - path: 
      type: PathPrefix 
      value: /coffee 
  backendRefs: 
  - name: coffee-v1-svc 
    port: 80 
- matches: # rule 2 
  - path: 
      type: PathPrefix 
      value: /coffee 
    headers: 
    - name: version 
      value: v2 
  - path: 
      type: PathPrefix 
      value: /coffee 
    queryParams: 
    - name: TEST 
      value: v2 
  backendRefs: 
  - name: coffee-v2-svc 
    port: 80

결과적으로 Data Plane은 헤더 버전이 v2이거나 쿼리 매개변수 TEST가 v2인 경우(예: rule 2의 /coffee?TEST=v2)라는 두 가지 조건에서 URI가 /coffee로 시작되는 요청을 coffee-v2-svc service로 라우팅합니다. 동시에 Data Plane은 /coffee에 대한 모든 요청을 coffee-v1-svc로 라우팅합니다(rule 1에서 볼 수 있듯이).

지원되는 모든 기능에 대해 자세히 알아보려면 HTTPRoute 가이드를 읽어보세요.

2-2. 강력한 확장성 모델

Gateway API는 강력한 확장성 모델과 함께 제공되며, 이를 통해 구현은 API 자체에서 본질적으로 지원하지 않는 고급 Data Plane 기능을 노출할 수 있습니다. Ingress Controller는 적용된 어노테이션을 통해 사용자 정의 확장을 지원함으로써 Ingress 리소스의 일부 제한을 해결하지만, Gateway API 확장성 모델은 Ingress 확장성 모델보다 더 우수합니다.

예를 들어, 아래는 NGINX Ingress Controller의 어노테이션을 통해 리소스를 확장하여 일부 고급 NGINX 기능을 활성화한 예시입니다(각 기능에 대한 설명은 어노테이션 옆에 주석으로 추가되어 있습니다):

apiVersion: networking.k8s.io/v1 
kind: Ingress 
metadata: 
  name: webapp  
 annotations: 
    nginx.org/lb-method: "ip_hash" # ip_hash 로드 밸런싱 방법을 선택합니다
    nginx.org/ssl-services: "webapp" # 백엔드 메소드에 TLS를 활성화합니다
    nginx.org/proxy-connect-timeout: "10s" # 백엔드에 대한 시간 초과를 구성합니다.
    nginx.org/proxy-read-timeout: "10s" 
    nginx.org/proxy-send-timeout: "10s" 
    nginx.org/rewrites: "serviceName=webapp rewrite=/v1" # 요청 URI rewrite
    nginx.com/jwt-key: "webapp-jwk" # 요청의 JWT 인증 활성화
    nginx.com/jwt-realm: "Webb App" 
    nginx.com/jwt-token: "$cookie_auth_token" 
    nginx.com/jwt-login-url: "https://login.example.com" 
spec: 
  rules: 
  - host: webapp.example.com 
  . . .

어노테이션은 구조, 유효성 검사, 세분성이 결여된 단순한 key-value 쌍으로, 이렇게 많은 양의 구성을 표현하기 위한 것이 아닙니다. (세분성이 부족하다는 것은 Ingress 리소스의 개별 라우팅 규칙과 같은 리소스의 일부가 아니라 전체 리소스별로 어노테이션이 적용된다는 의미입니다.)

Gateway API에는 여러 확장 지점, 사용자 지정 필터, 정책 첨부 파일 및 대상을 갖춘 강력한 어노테이션 없는 확장성 모델이 포함되어 있습니다. 이 모델을 통해 Gateway API 구현은 구조와 유효성 검사를 제공하는 사용자 리소스를 통해 고급 Data Plane 기능을 제공할 수 있습니다. 또한 사용자는 라우팅 규칙과 같은 리소스의 일부에 확장을 적용하여 세분성을 더욱 높일 수 있습니다.

예를 들어, 가상의 Gateway API 구현의 사용자 지정 필터가 /coffee 규칙에 대해 세분화된 rate limit을 적용하여 HTTPRoute의 라우팅 규칙을 향상시키는 방식입니다:

rules: 
- matches: 
  - path: 
      type: PathPrefix 
      value: /coffee 
  filters: 
  - type: ExtensionRef 
    extensionRef: 
      group: someproxy.example.com 
      kind: RateLimit 
      name: coffee-limit 
  backendRefs: 
  - name: coffee 
    port: 80

결과적으로 Gateway API 구현은 coffee-limit 제한 사용자 지정 리소스에 구성된 필터를 /coffee 규칙에 적용하며, 여기서 rate limit 은 다음과 같습니다:

rateLimit: 
  rate: 10r/s 
  key: ${binary_remote_addr}

참고: 구체적인 확장 기능보다는 가능한 확장 기능을 보여드린 이유는 NGINX Gateway Fabric 프로젝트가 아직 Gateway API 확장성 모델을 활용하지 않았기 때문입니다. 그러나 이 프로젝트는 사용자가 Gateway API를 통해 사용할 수 없는 고급 NGINX 기능에 액세스할 수 있도록 많은 확장을 지원할 예정이므로 향후에는 변경될 것입니다.

2-3. 역할 분리

Ingress 리소스는 단일 사용자 역할(애플리케이션 개발자)만 지원하며, 이 역할은 트래픽이 Kuberneters 클러스터의 애플리케이션에 도달하는 방식을 완전히 제어할 수 있습니다. 그러나 이러한 수준의 제어는 필요하지 않은 경우가 많으며, 여러 개발자팀 간에 Data Plane 인프라를 안전하게 공유하는 데 방해가 될 수 있습니다.

Gateway API는 인프라 프로비저닝 및 구성에 대한 책임을 인프라 제공자, 클러스터 운영자, 애플리케이션 개발자의 세 가지 역할로 나눕니다. 이러한 역할은 아래 표에 요약되어 있습니다.

RoleOwner of the Gateway API ResourcesResponsibilities
Infrastructure providerGatewayClassManage cluster-related infrastructure**
Cluster operatorGateway, GatewayClass*Manage a cluster for application developers
Application developerHTTPRouteManage applications
* 클러스터 운영자가 인프라 제공자의 구현을 사용하지 않고 Gateway API 구현을 설치하고 관리하는 경우, GatewayClass 리소스를 소유하게 된다.

** 관리형 Kubernetes 클러스터를 제공하는 클라우드 제공자와 유사합니다.

위의 역할은 RBAC에 기반한 책임 분리를 가능하게 합니다. 이러한 분리는 플랫폼팀(클러스터 운영자)이 Data Plane 인프라를 소유하고 클러스터의 여러 개발자팀(애플리케이션 개발자)과 안전하게 공유하고자 하는 일반적인 상황에 있는 조직에 적합합니다.

2-4. 이식성

Gateway API의 두 가지 측면으로 인해 이식성이 매우 뛰어납니다:

  • 기능 – 섹션 2-1에서 언급했듯이, 많은 기능으로 인해 Gateway API 구현에 특화된 확장 API에 의존할 필요가 줄어들어 사용자가 해당 API에 덜 얽매이게 됩니다. 반면, Ingress 사용자는 Ingress Controller에 특정한 확장 기능에 크게 의존합니다.
  • 적합성 테스트 – Gateway API는 구현에서 API 기능이 지원되는 방식에 일관성을 보장하기 위한 테스트와 함께 제공됩니다. 구현이 적합성을 갖추려면 적합성 테스트를 통과해야 합니다.

이러한 이식성 덕분에 사용자는 Ingress Controller를 전환하는 데 드는 노력보다 훨씬 적은 노력으로 하나의 Gateway API 구현에서 다른 구현으로 전환할 수 있습니다.

2-5. 커뮤니티

Gateway API는 커뮤니티가 주도하는 프로젝트입니다. 또한 아직 완성되지 않은 어린 프로젝트이기도 합니다. 새로운 기능을 제안하거나 피드백을 공유하는 등 프로젝트의 발전에 참여하고 싶으시다면 프로젝트의 기여 페이지를 확인하세요.

3. Gateway API 사용해 보는 방법

Gateway API를 사용하려면 두 단계가 필요합니다:

  • Gateway API를 Kubernetes 클러스터에 설치한다.
  • Gateway API 구현을 설치합니다.

NGINX는 Gateway API 구현인 NGINX Gateway Fabric을 만들었습니다. 이 구현은 NGINX를 Data Plane으로 사용합니다. 사용해 보려면 최신 릴리스의 설치 지침을 따르세요. 궁금한 점이 있거나 프로젝트에 기여하고 싶으시면 기여 가이드를 확인하실 수도 있습니다.

트위터 문서에는 Gateway API로 구현할 수 있는 다양한 사용 사례를 보여주는 여러 가이드와 예제가 포함되어 있습니다. 추가 지원이 필요하면 Kubernetes Gateway API 프로젝트 페이지에서 가이드를 확인하세요.

참고: NGINX Gateway Fabric은 새로운 프로젝트로, 유사한 NGINX Ingress Controller 프로젝트와 비교했을 때 아직 성숙도에 도달하지 않았습니다. 또한 NGINX Gateway Fabric은 Gateway API의 모든 핵심 기능을 지원하지만(섹션 2-1 참조), 아직 인기 있는 NGINX 기능에 대한 Gateway API 확장을 제공하지 않습니다(섹션 2-2 참조). 그 동안 이러한 기능은 NGINX Ingress Controller에서 사용할 수 있습니다.

4. 요약

Kubernetes Gateway API는 Ingress 리소스의 한계를 해결하기 위한 새로운 커뮤니티 프로젝트입니다. 이 새로운 API를 시도해야 하는 5가지 이유에 대해 논의하고 NGINX 기반 Gateway API 구현인 NGINX Gateway Fabric을 간략하게 소개했습니다.

NGINX Gateway Fabric을 통해 NGINX는 Gateway API의 네이티브 NGINX 구현에 집중하고 있습니다. Kubernetes 앱 연결의 미래를 만들어가는 데 동참해 주시기 바랍니다!
NGINX Gateway Fabric에 참여할 수 있는 방법은 다음과 같습니다:

  • 기여자로 프로젝트에 참여하기
  • 실험실에서 구현을 사용해 보세요.
  • 테스트 및 피드백 제공

프로젝트에 참여하려면 GitHub의 NGINX Gateway Fabric을 방문하세요.

NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.

NGINX에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.

NGINX STORE를 통한 솔루션 도입 및 기술지원 무료 상담 신청

* indicates required