[KANS 3기] 6주차 GatewayAPI

이전 이야기

 

앞서, Ingress 에서 Ingress는 더이상 개발이 없다고 언급했습니다. GatewayAPI 리소스가 새롭게 등장하였고, Ingress가 했던  작업을 Gateway API에서 지원되기 때문입니다.

 

Gateway API

기능

gatewayAPI의 주된 기능은 다음과 같습니다.

1. 개선된 리소스 모델
   GatewayClass, Gateway 및 Route(HTTPRoute, TCPRoute 등)와 같은 새로운 사용자 정의(CRD) 리소스를 도입하여 라우팅 규칙을 정의하는 보다 세부적이고 표현력 있는 방법을 제공합니다.
2. 프로토콜 독립적
   Gateway API는 TCP, UDP, TLS를 포함한 여러 프로토콜을 지원합니다. (Ingress는 HTTP용으로 설계됨)
3. 강화된 보안
   TLS 구성 및 보다 세부적인 액세스 제어에 대한 기본 제공 지원합니다.
4. 교차 네임스페이스 지원
   서로 다른 네임스페이스의 서비스로 트래픽을 라우팅하여 보다 유연한 아키텍처를 구축할 수 있는 기능을 제공합니다.
5. 확장성
   API는 사용자 정의 리소스 및 정책으로 쉽게 확장할 수 있도록 설계되었습니다.
6. 역할 지향
   클러스터 운영자, 애플리케이션 개발자, 보안 팀 간의 우려를 명확하게 분리합니다.

 

구성요소

API 명세(https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRoute)

v1 기준 리소스는 4가지 타입이 있습니다. GRPCRoute, Gateway, GatewayClass, HTTPRoute 입니다.

GatewayClass 

인프라구성을 제공하는 역할이 구성합니다. 클러스터 수준의 리소스입니다. 게이트웨이 클래스의 변경사항은 기존 게이트웨이 리소스로 전파되지 않습니다. (게이트웨이 클래스 변경으로 인한 문제가 최소한의 장애를 유발하기 위함)

 

Gateway

클라우드 로드밸런서처럼 인프라스트럭쳐에서 트래픽 핸들링을 정의합니다.

GRPCRoute

게이트웨이 리스너에서 서비스로 gRPC 요청에 대한 라우팅을 위한 Gateway API 유형입니다.

HTTPRoute

게이트웨이 리스너에서 서비스로 HTTP 요청에 대한 라우팅을 위한 Gateway API 유형입니다.

 

 

Gloo Gateway

https://docs.solo.io/gateway/latest/about/architecture/

Architecture | Solo.io documentation

 

Architecture

 

gloo pod의 동작은 다음과 같습니다.

1. 1. The config and secret watcher components in the gloo pod watch the cluster for new Kubernetes Gateway API and Gloo Gateway resources, such as Gateways, HTTPRoutes, or RouteOptions.
2. 2. When the config or secret watcher detect new or updated resources, it sends the resource configuration to the Gloo Gateway translation engine.
3. 3. The translation engine translates Kubernetes Gateway API and Gloo Gateway resources into Envoy configuration. All Envoy configuration is consolidated into an xDS snapshot.
4. 4. The reporter receives a status report for every resource that is processed by the translator.
5. 5. The reporter writes the resource status back to the etcd data store.
6. 6. The xDS snapshot is provided to the Gloo Gateway xDS server component in the gloo pod.
7. 7. Gateway proxies in the cluster pull the latest Envoy configuration from the Gloo Gateway xDS server.
8. 8. Users send a request to the IP address or hostname that the gateway proxy is exposed on.
9. 9. The gateway proxy uses the listener and route-specific configuration that was provided in the xDS snapshot to perform routing decisions and forward requests to destinations in the cluster.

Gloo Gateway control plane

Config watcher

쿠버네티스 게이트웨이 api혹은 (Gateways, HTTPRoutes, and Upstreams)와 같은 글루 게이트웨이 리소스가 신규로 생성되거나 변경됨을 감지하는 역할입니다. 감지한 다음 쿠버네티스 구성을 gloo gateway translate engine을 전달합니다.

Secret watcher

AWS 자격증명과 같은 secret store의 변경을 감지합니다. gloo gateway의 구성을 감지할 수도 있습니다.

Endpoint discovery

쿠버네티스 서비스 등록을 감지합니다. 새 엔드포인트나 업데이트된 엔드포인트를 발견하면 구성을 etcd에 저장합니다.

Translate Engine

사용자가 생성하거나 변경하는 모든 Gateway API, Kubernetes API, Gloo Gateway 리소스 스냅샷을 수신합니다. 이를 적절한 Envoy 구성으로 translate 합니다. envoy 구성을 xDS 스냅샷에 저장합니다.

translate cycle

 

1. 1. The translation cycle starts by defining Envoy clusters from all configured Upstream and Kubernetes service resources. Clusters in this context are groups of similar hosts. Each Upstream has a type that determines how the Upstream is processed. Correctly configured Upstreams and Kubernetes services are converted into Envoy clusters that match their type, including information like cluster metadata.
2.  
3. 2. The next step in the translation cycle is to process all the functions on each Upstream. Function-specific cluster metadata is added and is later processed by function-specific Envoy filters.
4.  
5. 3. In the next step, all Envoy routes are generated. Routes are generated for each route rule that is defined on the HTTPRoute and RouteOption resources. When all of the routes are created, the translator processes any VirtualHostOption, ListenerOption, and HttpListenerOption resources, aggregates them into Envoy virtual hosts, and adds them to a new Envoy HTTP Connection Manager configuration.
6.  
7. 4. Filter plug-ins are queried for their filter configurations, generating the list of HTTP and TCP Filters that are added to the Envoy listeners.
8.  
9. 5. Finally, an xDS snapshot is composed of the all the valid endpoints (EDS), clusters (CDS), route configs (RDS), and listeners (LDS). The snapshot is sent to the Gloo Gateway xDS server. Gateway proxies in your cluster watch the xDS server for new config. When new config is detected, the config is pulled into the gateway proxy.

 

Reporter

Reporter는 translator로부터 모든 Gloo Gateway 리소스에 대해 validation report를 전달받습니다. 유효하지 않은 구성은 쿠버네티스 스토리지 계층에 저장됩니다. 또한 유효하지 않은 리소스는 rejected 마크가 포함되고, 리소스 구성에 에러 메시지가 포함됩니다.

xDS Server

최종 스냅샷은 xDS 서버로 전달되고, 서버 구성 업데이트의 성공을 envoy에 알립니다. Gloo Gateway에서 원하는 상태와 일치하게 envoy 클러스터 구성을 업데이트합니다.

 

Discovery architecture

글루 게이트웨이는 쿠버네티스 서비스 및 기능들을 스캔하고 라우팅과 셀프 서비스를 용이하게 하기 위해서 자동으로 글루 게이트웨이 업스트림 리소스를 생성할 수 있는 서비스 디스커버리 기능을 내장하고 있습니다. 업스트림 생성하는 서비스의 제어를 더 강화하기 위해 서비스 디스커버리를 비활성화하고 업스트림을 수동으로 생성할 수 있습니다.

 

자동으로 discover 하는 리소스는

- 쿠버네티스 서비스

- AWS Lambda Function

- Google Cloud Functions

- OpenAPI-basedd Functions

 

 

그밖에...

Gloo Gateway 이외에도 Cilium Gateway 등과 같은 Gateway API는 https://gateway-api.sigs.k8s.io/implementations/여기를 참조 하시면 됩니다.

List - Kubernetes Gateway API

 

 

 

감사합니다.