Gateway API 기반 k8s resources(Gateway, HTTPRoute)와 타 k8s resources(Service, Pod)와의 관계
이미지 출처 : https://gateway-api.sigs.k8s.io/api-types/httproute/
Introduction
k8s ingress의 superset에 해당하는 Kubernetes Gateway API에 대해 논한다. 사실 상 Kubernetes Gateway API 공식 문서인 https://gateway-api.sigs.k8s.io/를 주로 참조한 개념적 요약이다.
Motivation
•
Network topology 관점에서 보자면 ingress와 API Gateway 모두는 L7 load balancer에 해당한다(k8s 외부로의 단일 접점 제공, L7 기반 부하 분산). 따라서 이들 둘을 별도로 운용하는 것은 비효율적이다. (이로 인해, 일반적으로는 L4 Load balancer에 API Gateway를 붙여 사용하리라 예상한다).
•
Service Mesh, 예컨데 istio의 경우, internet facing service에 대해 virtual service에 기반한 traffic 관리를 위해서는 istio ingress gateway가 필요하다. 이는 명칭에도 보듯 아키텍처 상 API Gateway와 또 다른 중복이다.
Kubernetes Gateway API는 이들 문제에 대한 해결안이다.
What is k8s Gateway API?
Gateway API는 SIG-NETWORK 커뮤니티 에서 관리하는 오픈 소스 프로젝트로서, Kubernetes에서 서비스 네트워킹을 모델링하는 API(리소스 모음)입니다… 이전 Ingress API 에 익숙하다면 Gateway API를 해당 API의 더욱 표현력이 풍부한 차세대 버전과 유사하다고 생각할 수 있습니다.
from k8s Gateway API 공식 site
위의 공식 site의 정의 중 둘째 문장이 중요한데, Gateway API는 ingress API를 사실 상 대체 가능한 superset임을 암시한다. 참고로, ingress와 API Gateway 모두는 Network 관점에서 보면 L7 Load balancer에 해당하지만, API Gateway는 ingress와는 달리 L7 protocol(e.g. HTTP)에 특화된 다양한 작업을 수행 가능하다.
한마디로 말해, k8s Gateway API란 ingress + API Gateway인 셈이다.
k8s Gateway API의 resources 및 이들 간 관계
다음 그림은 Gateway API의 주요 resources 식별 및 resource 간의 관계 및 담당자를 보여준다. 주목할 점으로 resource 별 담당자의 역할 분배를 고려했음이 보인다. ingress와는 달리 k8s Gateway API는 단일 runtime에 대해(API Gateway - ingress) Gateway와 HTTPRoute 라는 두 개의 resource로 나누어, Cluster와 application level 담당자를 분리 가능하도록 함과 동시에 application level 내에서도 각기 담당하는 resource를 분리 가능하도록 한다.
이미지 출처 : https://gateway-api.sigs.k8s.io/
•
GatewayClass : 인프라 제공자가 정의하는 클러스터 범위의 resource로서 생성 가능한 gateway를 정의한다. ingress의 networking.IngressClass 에 해당한다.
◦
◦
manifest example
apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
name: istio-gateway # Gateway resource에서 사용할 이름
spec:
controllerName: "istio.io/gateway-controller" # istio의 gateway class를 추가
YAML
복사
•
Gateway : GatewayClass 에 의해 Gateway를 provisioning한다.
◦
◦
manifest example
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: mygateway # HTTPRoute resource에서 사용할 이름
namespace: mysystem
spec:
gatewayClassName: istio-gateway # GatewayClass resource의 name 참조
listeners:
- name: http-a # 80 port의 HTTP로 a.example.com의 host traffic을 수신
hostname: "a.example.com"
port: 80
protocol: HTTP
- name: https-b # 443 port의 HTTPS로 b.example.com의 host traffic을 수신
hostname: "b.example.com"
port: 443
protocol: HTTPS
tls: # mygateway-credential secret에 저장된 certificate 적용
mode: Terminate
certificateRefs:
- name: mygateway-credential
YAML
복사
•
HTTPRoute : HTTP request를 서비스로 routing을 위한 규칙이다. GatewayClass, Gateway 까지는 gateway의 설치에 해당한다면, HTTPRoute 는 gateway가 갖는 다양한 기능을 적용하는 부분이다.
◦
주요 기능 : route by path/header, redirect, URL rewrite, header modification, traffic splitting, cross namespace routing
◦
◦
manifest example
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: httpbin
spec:
parentRefs:
- name: mygateway # Gateway resource의 name 참조
namespace: mysystem
hostnames:
- "a.example.com" # rule 적용 대상 incoming host
rules:
- matches:
- path: # /status path를 prefix로 하는 traffic에 대해 적용
type: PathPrefix
value: /status
- path: # /delay path를 prefix로 하는 traffic에 대해 적용
type: PathPrefix
value: /delay
backendRefs: # httpbin service의 8000 port로 traffic을 routing
- name: httpbin
port: 8000
YAML
복사
추가로, HTTPRoute 와 동일 선상에서 gRPC을 대응하는 GRPCRoute나 TCP, UDP에 대응하는 TCPRoute , UDPRoute , HTTPS를 지원하는 TLSRoute 가 있으나 이들은 23.09.24 현재 alpha 버전이며, 이들을 지원하지 않는 제품이 상당하다.
이외에 타 namespace의 Gateway API를 참조하도록 하는 ReferenceGrant 가 있으며 이에 대해서는 https://gateway-api.sigs.k8s.io/api-types/referencegrant/를 참조한다.
Wrap-up
간단히 Kubernetes Gateway API에 대해 알아보았으며 핵심은 ingress + API Gateway에 있다. 또한 담당자 별 역할 기반 resource 분리를 이루기에 역할 분리의 관리적 이점을 얻는다. 한편, Motivation에서 제기한 Service Mesh의 gateway와의 중복 이슈에 대해서는 본 post에서 논하지 않았는데, 이에 대해서는 API Gateway + Service Mesh = Kubernetes Gateway API에서 다룬다.
API Gateway + Service Mesh = Kubernetes Gateway API에서 다룬다.
