이 참조 아키텍처는 Google Distributed Cloud (GDC) 에어 갭에서 고객 관리형 레이어 7 부하 분산 솔루션을 제공합니다. 고객은 HAProxy Kubernetes 인그레스 또는 NGINX 게이트웨이 패브릭과 같은 인기 있는 오픈소스 컨트롤러를 GDC 표준 클러스터에 배포하여 L7 트래픽을 하이브리드 환경으로 원활하게 라우팅할 수 있습니다. 이 아키텍처는 TLS 종료(Ingress / HTTPRoute)를 사용하여 서버 이름 표시(SNI)를 기반으로 기본 제공되는 컨테이너화된 포드와 외부 가상 머신에서 호스팅되는 애플리케이션 모두에 트래픽을 라우팅합니다.
특징 및 기능
- 고급 레이어 7 라우팅: 호스트 기반 라우팅, 경로 기반 라우팅, 헤더 기반 일치 및 트래픽 가중치와 같은 고급 트래픽 관리를 지원합니다.
- 중앙 집중식 TLS 관리: 중앙 집중식 TLS 관리 및 종료를 제공합니다.
- 하이브리드 환경 지원: 기본 제공되는 컨테이너화된 포드와 외부 가상 머신에서 호스팅되는 애플리케이션 모두에 L7 트래픽을 원활하게 라우팅합니다.
- 유연한 컨트롤러 옵션: 최신 NGINX Gateway Fabric(Gateway API 사용) 또는 잘 알려진 HAProxy 인그레스 컨트롤러 중에서 선택할 수 있습니다.
- 에어 갭 준비: Harbor Registry와 통합되어 연결이 끊긴 비공개 환경 내에서 프록시 및 애플리케이션 이미지를 저장하고 제공합니다.
- 복잡한 트래픽 분할: 최신 애플리케이션 배포를 위한 고급 트래픽 분산 전략을 지원합니다.
아키텍처 원칙
- 2계층 부하 분산 패턴: 이 아키텍처는 GDC의 기본 제공 L4 부하 분산기 (진입점)를 Kubernetes 내에 배포된 고객 관리형 L7 게이트웨이와 결합합니다.
- 역할 중심 분리: 특정 리소스(예:
GatewayClass,Gateway,HTTPRoute또는Ingress)를 통해 인프라 제공업체, 클러스터 운영자, 개발자 간의 책임을 분리하는 설계를 따릅니다. - 최신 표준으로 전환: 이 아키텍처는 최신 라우팅 기능을 위해 Gateway API를 우선시하는 동시에 특정 컨트롤러의 안정성이 필요한 기존 인그레스 API에 대한 지원을 유지합니다.
- 고객 관리형 유연성: 자체 관리형 컨트롤러를 배포하면 고객은 GDC 관리형 L4 부하 분산기에서 기본적으로 제공하지 않는 L7 기능 및 구성을 제어할 수 있습니다.
- 워크로드 위치 추상화: 이 아키텍처는 Kubernetes 서비스 추상화(표준 또는 헤드리스)를 통해 컨테이너화된 워크로드와 VM 기반 워크로드를 일관되게 처리합니다.
개념적 아키텍처
논리 아키텍처
논리적 아키텍처는 외부 트래픽을 내부 또는 외부 백엔드로 라우팅하기 위해 함께 작동하는 여러 기능 구성요소로 구성됩니다.
- 인그레스/게이트웨이 진입점: 클라이언트가 HTTPS 요청을 시작하면 이 요청은 먼저 GDC L4 부하 분산기에 도달합니다. 이 기본 제공 부하 분산기는 진입점 역할을 하며 TCP/443 트래픽을 L7 부하 분산기로 분산합니다.
- 컨트롤 플레인: 인그레스 또는 게이트웨이 컨트롤러 (HAProxy 또는 NGINX 연산자)는
Ingress,Gateway,HTTPRoute와 같은 Kubernetes 리소스를 모니터링합니다. - 데이터 영역: 관찰된 리소스를 기반으로 컨트롤러는 SNI 기반 호스트 라우팅 규칙 및 TLS 종료를 기반으로 실제 트래픽 라우팅을 수행하는 기본 프록시를 동적으로 업데이트합니다.
- 백엔드 서비스:
- 컨테이너화된 포드: 표준 배포로 관리되고 일반 Kubernetes 서비스로 노출됩니다.
- 외부 VM: 헤드리스 Kubernetes 서비스 및 VM의 직접 IP가 포함된 커스텀 엔드포인트 (또는
EndpointSlice)를 사용하여 클러스터에 통합됩니다.
- 아티팩트 관리: 프록시 및 애플리케이션의 모든 이미지는 에어 갭 환경에서 기능을 보장하기 위해 로컬 Harbor Registry에서 제공됩니다.
핵심 개념 및 기술
이 아키텍처는 GDC의 기본 제공 L4 부하 분산기와 Kubernetes에 배포된 고객 관리형 L7 게이트웨이를 결합한 2계층 부하 분산 패턴을 사용합니다. 주요 구성요소는 다음과 같습니다.
- 클라이언트: 애플리케이션과 상호작용하기 위해 HTTPS 요청을 시작하는 항목입니다.
- GDC 표준 클러스터: GDC는 Kubernetes 바닐라 클러스터를 만드는 기본 제공 방법을 제공합니다. 이 솔루션에서 클러스터는 외부 VM의 워크로드 및 헤드리스 서비스와 함께 L7 LB 및 컨트롤러를 호스팅합니다.
- GDC L4 부하 분산기: 진입점 역할을 하는 기본 제공 L4 부하 분산기로, TCP/443 트래픽을 인그레스 또는 게이트웨이 컨트롤러를 실행하는 Kubernetes 포드에 직접 분산합니다.
- 인그레스 및 게이트웨이 컨트롤러: 표준 클러스터에서 실행되는 HAProxy 또는 NGINX 연산자입니다. Nginx의 경우 Gateway API 리소스 (예:
Gateway및HTTPRoute)를 모니터링하고 기본 프록시를 동적으로 업데이트합니다. HAProxy의 경우Ingress리소스를 모니터링하고 기본 프록시를 동적으로 업데이트합니다.- HAProxy 인그레스 컨트롤러: HAProxy를 리버스 프록시 및 레이어 7 부하 분산기로 활용하고 TLS 종료도 처리하는 Kubernetes용 인그레스 컨트롤러입니다.
- Nginx Gateway Fabric: NGINX를 데이터 영역으로 사용하는 Gateway API 구현입니다.
- 인그레스 및 게이트웨이(HTTPRoute 사용): TLS 종료를 사용하여 물리적 리스닝 포트(443)와 SNI 기반 호스트 라우팅 규칙을 정의하는 표준화된 Kubernetes 리소스입니다.
- 컨테이너화된 워크로드(포드): 일반 Kubernetes
Service를 사용하여 내부적으로 노출되는 표준 Kubernetes 배포입니다. - VM 기반 워크로드 (외부): 프로젝트 네트워크의 외부 VM에서 호스팅되는 워크로드로, 헤드리스 Kubernetes
Service및 VM의 직접 IP가 포함된 커스텀 엔드포인트를 사용하여 프록시에 노출됩니다. - Harbor 레지스트리: 에어 갭 환경에서 프록시 및 애플리케이션 이미지를 저장하고 제공하는 데 사용되는 비공개 Container Registry입니다.
인그레스 API와 게이트웨이 API
Kubernetes 네트워킹 환경은 기존 Ingress API에서 최신 Gateway API로 전환되고 있습니다. 워크로드에 적합한 아키텍처를 선택하려면 이 두 가지의 차이점을 이해하는 것이 중요합니다.
Ingress API: 이전에는 인그레스가 HTTP 서비스에 대한 외부 액세스를 관리하는 표준이었습니다. 호스트 기반 및 경로 기반 라우팅을 제공하지만 설계가 비교적 기본적이며 공급업체별 주석에 의존하지 않고 고급 트래픽 관리(예: 헤더 기반 일치 또는 트래픽 가중치)에 대한 기본 제공 지원이 부족합니다. 중요한 점은 이제 Kubernetes 커뮤니티에서 Ingress API를 기능 고정으로 간주한다는 것입니다 (Ingress 제한사항 및 Kubernetes 네트워킹의 발전).
Gateway API: 인그레스의 V2라고도 하는 Gateway API는 서비스 네트워킹을 위한 더 강력하고 확장 가능한 모델을 제공하는 커스텀 리소스 정의 (CRD) 모음입니다. 인프라 제공업체 (
GatewayClass), 클러스터 운영자 (Gateway), 개발자(HTTPRoute/TLSRoute) 간의 책임을 분리하는 역할 지향으로 설계되었습니다(GKE의 게이트웨이 API). 이렇게 분리하면 더 세밀한 제어가 가능하고 멀티 테넌시 지원이 향상됩니다.
이 GDC 에어 갭 솔루션에서는 두 가지 주요 컨트롤러에 대해 의도적으로 서로 다른 API를 선택했습니다.
- NGINX(Gateway API): NGINX 구현의 경우 Gateway API의 완성도 높은 기본 제공 구현인 NGINX Gateway Fabric을 사용합니다. NGINX용 게이트웨이 API를 활용하면 고객은 API에 기본 제공되는 최신 표준과 고급 라우팅 기능 (예:
HTTPRoute)을 활용할 수 있습니다. - HAProxy(Ingress API): Gateway API가 전략적 방향이지만 이 가이드에서는 HAProxy에 Ingress API를 선택했습니다. 이는 HAProxy의 게이트웨이 API 통합이 성숙하지 않은 것으로 간주되기 때문입니다. 잘 확립된 HAProxy 인그레스 컨트롤러를 사용하면 HAProxy를 선호하는 고객에게 안정적이고 신뢰할 수 있는 L7 솔루션을 보장하는 동시에 최신 L7 기능으로의 경로를 제공할 수 있습니다.
가정 및 제약조건
가정
- 인프라 준비: 배포에서는 GDC 에어 갭 1.15.x 표준 클러스터의 가용성을 가정합니다.
- 로컬 레지스트리: 로컬 Harbor 레지스트리가 에어 갭 환경에서 프록시 및 애플리케이션 이미지를 저장하고 제공하도록 올바르게 구성되었다고 가정합니다.
- 기본 진입점: 트래픽이 먼저 기본 제공 GDC L4 부하 분산기에 도달한 후 L7 프록시로 분산된다고 가정합니다.
제약조건
- 고객 관리형 솔루션: GDC에는 SLA 지원 L7 관리형 서비스가 없습니다. 이 구현은 고객이 전적으로 자체 관리합니다.
- 표준 클러스터만 해당: 공유 사용자 클러스터는 인그레스 및 게이트웨이 컨트롤러 배포에 필요한 높은 권한으로 인해 범위에 포함되지 않습니다.
- API 성숙도: NGINX는 최신 Gateway API를 사용하는 반면 HAProxy는 Gateway API 통합이 아직 성숙하지 않은 것으로 간주되므로 Ingress API로 제한됩니다.
- 에어 갭 적용 유지보수: 모든 컨테이너 이미지를 로컬 Harbor 레지스트리 내에서 수동으로 승격하고 관리해야 합니다.
- 커뮤니티 버전: 이 아키텍처는 Nginx 및 HAProxy의 오픈소스 커뮤니티 버전을 위해 설계되었습니다. Enterprise 버전은 작동할 수 있지만 명시적으로 테스트되지 않았습니다.
- 운영 소유권: 고객은 서드 파티 컨트롤러의 확장, 고가용성, 패치를 직접 관리해야 합니다.
- 지원 범위: Google 지원은 기본 GDC 인프라만 지원합니다. HAProxy 또는 NGINX 소프트웨어 자체의 문제는 고객 또는 공급업체의 책임입니다.
- API 노후화: HAProxy에 사용되는 Ingress API는 Kubernetes 커뮤니티에서 기능이 동결되어 향후 라우팅 기능이 제한될 수 있습니다.
라이선스
- 커뮤니티 버전: 이 아키텍처는 오픈소스 커뮤니티 버전 (일반적으로 Apache 2.0 이상)을 위해 설계되었으며, 무료로 사용할 수 있지만 고객이 관리합니다.
- 엔터프라이즈 조달: NGINX Plus 또는 HAProxy Enterprise와 같은 상용 라이선스의 조달 및 관리는 전적으로 고객의 책임입니다.