쿠버네티스는 계속 발전하고 있으며, 이와 함께 복잡하고 분산된 마이크로서비스를 대규모로 관리하는 네트워킹 과제도 진화하고 있습니다. 기존의 Ingress API와 같은 도구는 외부 트래픽에 서비스를 노출하기 위해 사용되어 왔지만, 환경이 복잡해지면서 개발자와 운영자들은 네트워크 트래픽에 대한 더 큰 유연성, 확장성 및 세밀한 제어를 요구하고 있습니다.
이번 글에서는 게이트웨이 API가 무엇인지, 왜 개발되었는지, 그리고 쿠버네티스에서 네트워킹을 다루는 방식을 어떻게 변화시킬 것인지에 대해 깊이 탐구해 보겠습니다.
쿠버네티스 네트워킹의 진화
초기에는 클러스터 내 서비스에 대한 외부 접근을 관리하기 위해 Ingress 리소스가 도입되었습니다. Ingress는 그 목적을 잘 수행했지만, 몇 가지 한계가 있었습니다:
- 복잡한 라우팅 시나리오 지원 부족
- 비 HTTP 프로토콜 지원 부족
- 다양한 구현에서 기능을 확장하는 데 어려움
게이트웨이 API의 등장
이러한 문제를 해결하기 위해 쿠버네티스 커뮤니티는 2019년부터 게이트웨이 API 작업을 시작했습니다. 게이트웨이 API는 Ingress의 한계를 해결하고 더 유연하고 확장 가능하며 강력한 트래픽 라우팅 방식을 제공하도록 설계되었습니다.
게이트웨이 API의 주요 기능은 다음과 같습니다:
- 향상된 리소스 모델: GatewayClass, Gateway, Route (HTTPRoute, TCPRoute 등)와 같은 새로운 커스텀 리소스를 도입하여 라우팅 규칙을 더 세분화하고 표현할 수 있게 되었습니다.
- 프로토콜 독립성: Ingress가 주로 HTTP를 위해 설계된 것과 달리, 게이트웨이 API는 TCP, UDP, TLS를 포함한 다양한 프로토콜을 지원합니다.
- 강화된 보안: TLS 구성 및 더 세밀한 접근 제어를 기본적으로 지원합니다.
- 크로스 네임스페이스 지원: 다른 네임스페이스의 서비스로 트래픽을 라우팅할 수 있어 더 유연한 아키텍처 구성이 가능합니다.
- 확장성: 커스텀 리소스 및 정책으로 쉽게 확장할 수 있도록 설계되었습니다.
- 역할 기반 설계: 클러스터 운영자, 애플리케이션 개발자, 보안 팀 간의 명확한 역할 분리를 제공합니다.
이러한 역할 기반 설계는 게이트웨이 API의 가장 흥미로운 기능 중 하나입니다. 게이트웨이 API의 로고가 북-남(Ingress) 및 동-서(Mesh) 트래픽을 라우팅하는 이중 목적을 나타내는 이유가 바로 여기에 있습니다.
게이트웨이 API와 API 게이트웨이의 차이점
게이트웨이 API를 처음 탐구하면서 "API 게이트웨이와 어떻게 다른가?"라는 질문이 떠올랐습니다. 아마 여러분도 같은 질문을 가지고 있을 것 같아 이 부분을 정리해 보았습니다.
둘 다 트래픽 라우팅 및 관리를 포함하지만, 그 목적은 매우 다릅니다.
1. 쿠버네티스 게이트웨이 API란?
쿠버네티스 게이트웨이 API는 쿠버네티스의 기존 Ingress API를 확장하고 개선한 네트워킹 API입니다. 주로 쿠버네티스 클러스터 내에서 실행 중인 서비스로의 트래픽 관리를 목적으로 합니다. HTTP, TCP 등 다양한 프로토콜을 처리하고 북-남(외부에서 내부) 및 동-서(내부 서비스 간) 트래픽 모두를 관리할 수 있도록 설계되었습니다.
- OSI 모델의 4계층(전송) 및 7계층(응용): HTTP, TCP, UDP와 같은 다양한 프로토콜을 관리할 수 있습니다.
- 쿠버네티스와 통합: 쿠버네티스 생태계의 일부로서 작동합니다.
- 유연한 라우팅: 기존 Ingress API보다 더 고급 라우팅 구성을 허용합니다.
- 다양한 리소스 유형: Gateway, HTTPRoute, TCPRoute, TLSRoute, GatewayClass 등 다양한 리소스를 사용하여 트래픽을 세밀하게 제어할 수 있습니다.
2. API 게이트웨이란?
API 게이트웨이는 외부 클라이언트(모바일 앱, 브라우저, 외부 API 등)와 백엔드 마이크로서비스 또는 API 간의 중개 역할을 하는 애플리케이션 레벨의 서비스입니다. 주된 목적은 모든 클라이언트 요청에 대한 단일 진입점 역할을 하면서 API 트래픽을 관리하고 조율하는 것입니다.
- API에 초점: API 호출과 관련된 트래픽을 주로 다룹니다.
- API 요청 관리: API 소비자를 위한 단일 진입점 역할을 하며, API 경로에 따라 요청을 다른 백엔드 서비스로 프록시합니다.
- 추가 기능: 보안(인증, 권한 부여), 트래픽 관리(속도 제한, 쓰로틀링), 캐싱 및 모니터링과 같은 기능을 포함합니다.
- 쿠버네티스에 국한되지 않음: 클라우드, 온프레미스, 하이브리드 환경 등 어디에서나 사용할 수 있으며, 쿠버네티스 클러스터에 국한되지 않습니다.
게이트웨이 API의 주요 구성 요소
게이트웨이 API의 주요 구성 요소는 다음과 같습니다:
1. GatewayClass
- 정의: StorageClass가 스토리지 유형을 정의하는 것처럼 GatewayClass는 네트워킹 인프라(로드 밸런서, 프록시 등)의 프로비저닝 및 관리를 정의합니다.
- 역할: 특정 게이트웨이 유형의 구현 세부 정보를 정의하며, 클라우드 기반, 온프레미스, 또는 서비스 메쉬 등 네트워크 구성을 추상화합니다.
2. Gateway
- 정의: 네트워킹 인프라의 세부 사항(리스닝 포트 및 지원 프로토콜 등)을 설명하는 리소스입니다.
- 역할: 클러스터로 들어오는 트래픽에 대한 논리적 진입점 역할을 하며, HTTP(S), TCP, UDP 등 다양한 프로토콜을 위한 리스너를 가집니다.
3. Route 리소스
게이트웨이를 통해 들어온 트래픽이 백엔드 서비스로 라우팅되는 규칙을 정의하는 리소스입니다. 복잡한 트래픽 라우팅 및 분할 로직을 구현할 수 있습니다.
4. ParentRef
Route 리소스(HTTPRoute, TCPRoute 등)에서 부모 게이트웨이를 참조하는 필드입니다. 이를 통해 Route 리소스가 특정 게이트웨이와의 관계를 선언하고, 보안 및 멀티 테넌트 환경에서의 질서를 유지할 수 있습니다.
5. 리스너
리스너는 게이트웨이의 구성 요소로서 특정 포트와 프로토콜에서 트래픽을 수락하는 방식을 정의합니다. 예를 들어, HTTP(포트 80)와 HTTPS(포트 443) 리스너를 같은 게이트웨이에 정의하여 암호화된 트래픽과 암호화되지 않은 트래픽을 모두 처리할 수 있습니다.
6. BackendRefs
BackendRefs는 트래픽이 게이트웨이를 통과한 후 어떤 백엔드 서비스로 전달될지 지정하는 리소스입니다. HTTPRoute, TCPRoute 등과 같은 라우팅 리소스에 정의되며, 트래픽을 하나 이상의 서비스로 보내는 규칙 또는 로드 밸런싱 방법을 설정할 수 있습니다.
이제 쿠버네티스 게이트웨이 API의 주요 개념들에 대해 알아보았습니다. 전통적인 Ingress API에 비해 어떤 장점이 있는지, 그리고 그 핵심 구성 요소들에 대해 살펴보았습니다. 다음 글에서는 게이트웨이 API의 실제 구현을 통해 이 API의 전체 기능을 설명할 예정입니다. 이를 통해 인프라 제공자, 클러스터 운영자, 애플리케이션 개발자가 어떻게 협력하여 트래픽 라우팅을 관리할 수 있는지, 그리고 게이트웨이 API가 외부(북-남) 및 내부(동-서) 트래픽을 어떻게 관리하는지 살펴볼 것입니다.🚀
'Kubernetes' 카테고리의 다른 글
| Kubernetes 설정 도구: Helm과 Kustomize 외에도 놓쳐서는 안 될 도구들 (0) | 2024.09.24 |
|---|---|
| Kubernetes의 패키지 관리자 Helm: 클러스터 관리의 새로운 표준 (0) | 2024.09.06 |
| Ambient Mesh: 차세대 서비스 메쉬의 새로운 패러다임 (0) | 2024.08.23 |
| 서비스 메쉬(Service Mesh): 마이크로서비스의 숨겨진 히어로 (0) | 2024.08.23 |
| [AutoScaling] Kubernetes AutoScaling에 대해 알아보기! (0) | 2024.07.10 |
