소개¶

게이트웨이 API는 쿠버네티스의 L4 및 L7 라우팅에 초점을 맞춘 공식 쿠버네티스 프로젝트이다. 이 프로젝트는 쿠버네티스 인그레스, 로드 밸런싱, 서비스 메시 API의 차세대 버전을 대표한다. 시작부터 범용적이고 표현력이 풍부하며 역할 중심으로 설계되었다.

전체 리소스 모델은 3개의 개별 페르소나와 그들이 관리할 것으로 예상되는 리소스에 초점을 맞춘다.

Gateway API Resource Model

이 API의 대부분의 설정은 라우팅 레이어에 포함되어 있다. 이러한 프로토콜별 리소스 (HTTPRoute, GRPCRoute 등)는 인그레스와 메시 모두에 대해 고급 라우팅 기능을 제공한다.

게이트웨이 API 로고는 API의 이중 목적을 시각적으로 설명하며, 북/남 (인그레스) 및 동/서 (메시) 트래픽이 동일한 구성 설정을 공유하며 라우팅을 가능하게 한다.

인그레스를 위한 게이트웨이 API ¶

v0.5.0 부터 표준 채널

게이트웨이, 게이트웨이클래스, HTTPRoute는 v0.5.0부터 게이트웨이 API의 표준 채널에 포함되었으며 안정적인 API로 간주된다. 자세한 내용은 버전 관리 가이드를 참조하자.

게이트웨이 API를 사용하여 인그레스 트래픽을 관리할 때, 게이트웨이 리소스는 트래픽이 여러 컨텍스트를 거쳐 라우팅될 수 있는 접근 지점을 정의한다. 예를 들어, 클러스터 외부에서 내부로의 (북/남 트래픽)이 있다.

각 게이트웨이는 게이트웨이클래스와 연결되며, 이는 게이트웨이의 트래픽을 처리할 게이트웨이 컨트롤러의 실제 타입을 설명한다. 개별 라우팅 리소스(예: HTTPRoute)는 게이트웨이 리소스와 연결된다. 이러한 서로 다른 관심사를 별도의 리소스로 분리하는 것은 게이트웨이 API의 역할 지향적 특성의 핵심 부분이며, 동일한 클러스터 내에서 여러 타입의 게이트웨이 컨트롤러(게이트웨이클래스 리소스로 표현)와 각각의 여러 인스턴스(게이트웨이 리소스로 표현)를 허용한다.

서비스 메시를 위한 게이트웨이 API (GAMMA initiative) ¶

v1.1.0 부터 표준 채널

서비스 메시 사용 사례를 지원하기 위한 GAMMA 이니셔티브 작업은 v1.1.0부터 표준 채널에 포함되었으며 GA로 간주된다. 자세한 내용은 버전 관리 가이드를 참조하자.

게이트웨이 API를 사용하여 서비스 메시를 관리할 때는 상황이 약간 다르다. 클러스터 내에서 일반적으로 하나의 메시만 활성화되므로 게이트웨이와 게이트웨이클래스 리소스는 사용되지 않는다. 대신, 개별 라우팅 리소스(예: HTTPRoute)는 서비스 리소스와 직접 연결되며, 이를 통해 메시가 해당 서비스로 향하는 모든 트래픽을 관리하면서 게이트웨이 API의 역할 지향적 특성을 유지한다.

현재까지 GAMMA는 게이트웨이 API에 최소한의 변경만으로 메시 기능을 지원해왔다. 하지만 GAMMA에서 특히 빠르게 중요해진 영역은 서비스 리소스의 다양한 측면 정의이다.

시작하기¶

게이트웨이 API 사용에 관심 있는 사용자든, API 준수를 원하는 구현자든, 아래의 리소스는 필요한 배경 정보를 제공한다.

게이트웨이 API 개념¶

이어지는 설계 목표는 게이트웨이 API의 개념을 이끌어낸다. 이는 게이트웨이가 인그레스와 같은 현재 표준을 어떻게 개선하려는지 보여준다.

역할-지향적 - 게이트웨이는 쿠버네티스 서비스 네트워킹을 사용하고 설정하는 조직적 역할을 모델링하는 API 리소스로 구성되어 있다.
이식성 - 이는 개선이라기보다는 유지해야 할 특성이다. 인그레스가 수많은 구현을 가진 보편적 사양인 것처럼, 게이트웨이 API는 다양한 구현을 지원하는 이식 가능한 사양으로 설계되었다.
표현력 - 게이트웨이 API 리소스는 헤더 기반 매칭, 트래픽 가중치 설정 등 인그레스에서는 사용자 정의 주석을 통해서만 가능했던 핵심 기능을 지원한다.
확장 가능 - 게이트웨이 API는 API의 다양한 계층에서 사용자 정의 리소스를 연결할 수 있도록 한다. 이를 통해 API 구조 내 적절한 위치에서 세분화된 사용자 정의가 가능하다.

기타 주목할 만한 기능은 다음과 같다.

게이트웨이클래스 - 게이트웨이클래스는 부하 분산 구현의 타입을 공식화한다. 이러한 클래스는 사용자가 쿠버네티스 리소스 모델을 통해 어떤 기능이 사용 가능한지 명확하고 쉽게 이해할 수 있도록 한다.
공유 게이트웨이와 네임스페이스 간 지원 - 독립적인 라우트 리소스가 동일한 게이트웨이에 연결될 수 있도록 하여 로드 밸런서와 VIPs를 공유한다. 이를 통해 팀(심지어 네임스페이스를 넘어) 간 직접적인 조정 없이 안전하게 인프라를 공유할 수 있다.
타입화된 라우트 및 백엔드 - 게이트웨이 API는 타입화된 라우트 리소스와 다양한 백엔드 타입을 지원한다. 이를 통해 API는 (HTTP, gRPC와 같이) 다양한 프로토콜과 (쿠버네티스 서비스, 스토리지 버킷, 함수와 같은) 다양한 백엔드 타겟을 지원하는 데 유연성을 갖는다.
실험적 서비스 메시 지원 (GAMMA 이니셔티브) - 게이트웨이 API는 라우팅 리소스를 서비스 리소스와 연결하여 인그레스 컨트롤러뿐만 아니라 서비스 메시를 구성할 수 있도록 지원한다.

왜 역할 지향적 API가 중요한가?¶

도로, 전력, 데이터 센터, 쿠버네티스 클러스터 등 인프라는 공유를 목적으로 구축된다. 하지만 공유 인프라는 공통적인 도전 과제를 제시한다. 즉, 인프라 사용자에게 유연성을 제공하면서 인프라 소유자의 통제력을 어떻게 유지할 것인가?

게이트웨이 API는 쿠버네티스 서비스 네트워킹을 위한 역할 지향적 설계를 통해 분산된 유연성과 중앙 집중식 통제 간의 균형을 이룬다. 이를 통해 공유 네트워크 인프라(하드웨어 부하 분산기, 클라우드 네트워킹, 클러스터 호스팅 프록시 등)를 클러스터 운영자가 설정한 정책과 제약에 따라 서로 협력하지 않는 다양한 팀이 사용할 수 있다.

게이트웨이 API의 설계에 사용되는 역할은 세 가지 페르소나로 정의된다.

페르소나¶

Ian (그/그의)은 인프라 제공자이다. 그의 역할은 여러 개별 클러스터가 다수의 테넌트를 제공할 수 있도록 인프라를 관리하고 유지하는 것이다. 그는 단일 테넌트에 얽매이지 않고, 모든 테넌트를 집합적으로 고려한다.
Chihiro (그들/그들의)은 >클러스터 운영자이다. 그들의 역할은 단일 클러스터를 관리하여 여러 사용자의 요구를 충족하도록 하는 것이다. Chihiro는 클러스터의 단일 사용자에게 얽매이지 않으며, 클러스터가 모든 사용자를 필요에 따라 지원하도록 해야 한다.
Ana (그녀/그녀의)은 애플리케이션 개발자이다. Ana는 게이트웨이 API 역할 중 유일한 위치에 있다. 그녀의 초점은 애플리케이션이 제공해야 하는 비즈니스 요구에 있으며, 쿠버네티스나 게이트웨이 API 자체가 아니다. 실제로, Ana는 게이트웨이 API와 쿠버네티스를 일을 완수하는 데 방해가 되는 순수한 마찰로 볼 가능성이 높다.

(이 세 가지에 대한 자세한 내용은 역할과 페르소나에서 자세히 설명한다).

Ana, Chihiro, Ian이 모든 점에서 의견이 일치하지는 않지만, 원활한 운영을 위해 협력해야 한다는 점은 분명하다. 한마디로 이것이 게이트웨이 API의 핵심 과제이다.

사용 사례¶

예제 사용 사례는 역할-지향적 모델이 작동하는 모습을 보여준다. 이 모델의 유연성은 API가 매우 다른 조직 모델과 구현에 적응하면서도 이식 가능하고 표준적인 API로 남을 수 있게 한다.

제시된 사용 사례는 위에서 소개한 역할들을 기준으로 의도적으로 구성되었다. 궁극적으로 게이트웨이 API는 인간이 사용하도록 설계되었으며, 이는 Ana, Chihiro, Ian 각각이 API를 사용하는 목적에 맞아야 함을 의미한다.

게이트웨이 API와 API 게이트웨이의 차이점은 무엇인가?¶

API 게이트웨이는 고유한 애플리케이션 API를 집계하여 한 곳에서 모두 사용 가능하게 만드는 도구이다. 이를 통해 조직은 인증, 권한 부여, 애플리케이션 간 요청 수 제한과 같은 핵심 기능을 중앙에서 관리할 수 있다. API 게이트웨이는 (종종 외부) API 소비자를 위한 공통 인터페이스로 기능한다.

게이트웨이 API는 쿠버네티스에서 서비스 네트워킹을 모델링하는 일련의 쿠버네티스 리소스로 정의된 인터페이스이다. 주요 리소스 중 하나는 게이트웨이로, 인스턴스화할 게이트웨이 타입(또는 클래스)과 그 설정을 선언한다. 게이트웨이 제공자로서 게이트웨이 API를 구현하여 쿠버네티스 서비스 네트워킹을 표현력 있고 확장 가능하며 역할 지향적인 방식으로 모델링할 수 있다.

일부 API 게이트웨이는 게이트웨이 API를 사용하여 프로그래밍할 수 있다.

누가 게이트웨이 API를 개발하고 있는가?¶

게이트웨이 API는 쿠버네티스에서 서비스 네트워킹을 개선하고 표준화하기 위해 SIG-네트워크 프로젝트로 개발되고 있다. 최신 게이트웨이를 지원하는 프로젝트 및 제품은 구현 참조에서 확인할 수 있다. 게이트웨이 API를 사용해 기여하거나 구현을 구축하는 데 관심이 있다면 주저하지 말고 참여하라!