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