에지에서 멀티 클러스터 메시로: GKE 게이트웨이와 Cloud Service Mesh를 통해 노출되는 전역으로 분산된 애플리케이션

Last reviewed 2024-06-30 UTC

이 참조 아키텍처에서는 서비스 메시 내의 여러 GKE 클러스터에서 실행되는 Google Kubernetes Engine(GKE) 게이트웨이를 통해 애플리케이션을 외부에 노출할 때의 이점을 설명합니다. 이 가이드는 플랫폼 관리자를 대상으로 합니다.

각 클러스터가 추가 장애 도메인이 되는 여러 GKE 클러스터에 애플리케이션을 일관되게 배포하여 서비스의 복원력과 중복성을 높일 수 있습니다. 예를 들어 단일 GKE 클러스터에 배포할 때 서비스 수준 목표(SLO)가 99.9% 인 서비스는 GKE 클러스터 2개(1~(0.001)2)에 배포될 때 SLO 99.9999%를 달성합니다. 또한 들어오는 요청이 가장 잠재성이 낮은 사용 가능한 메시 인그레스 게이트웨이로 자동 전달되는 환경을 사용자에게 제공할 수 있습니다.

단일 클러스터에서 실행되는 서비스 메시 지원 애플리케이션을 노출할 때의 이점을 알아보려면 에지에서 메시로: GKE 게이트웨이를 통해 서비스 메시 애플리케이션 노출을 참조하세요.

아키텍처

다음 아키텍처 다이어그램에서는 클라우드 인그레스와 메시 인그레스를 통해 데이터가 흐르는 방식을 보여줍니다.

클라이언트, 부하 분산기, 메시의 TLS 암호화

위 다이어그램에서는 다음과 같은 데이터 흐름 시나리오를 보여줍니다.

  • 자체 Google 관리 TLS 인증서를 사용하여 Google Cloud 부하 분산기에서 종료되는 클라이언트에서
  • 자체 서명 TLS 인증서를 사용하여 Google Cloud 부하 분산기에서 메시 인그레스 프록시로
  • 서비스 메시 지원 mTLS를 사용하여 메시 인그레스 게이트웨이 프록시에서 워크로드 사이드카 프록시로

이 참조 아키텍처에는 다음과 같은 인그레스 레이어 2개가 포함됩니다.

  • 클라우드 인그레스: 이 참조 아키텍처에서는 Kubernetes Gateway API(및 GKE Gateway Controller)를 사용하여 외부 멀티 클러스터 HTTP(S) 부하 분산 레이어를 프로그래밍할 수 있습니다. 부하 분산기는 여러 리전에서 메시 인그레스 프록시를 확인하여 요청을 가장 가까운 정상 클러스터로 보냅니다. 또한 Google Cloud Armor 보안 정책을 구현합니다.
  • 메시 인그레스: 메시에서는 로컬로 부하 분산과 트래픽 관리를 실행할 수 있도록 백엔드에서 직접 상태 점검을 수행합니다.

인그레스 레이어를 함께 사용하면 레이어마다 상호 보완적인 역할이 있습니다. Google Cloud는 다음 목표를 달성하기 위해 클라우드 인그레스 레이어와 메시 인그레스 레이어에서 가장 적합한 기능을 최적화합니다.

  • 짧은 지연 시간을 제공합니다.
  • 가용성을 높입니다.
  • 클라우드 인그레스 레이어의 보안 기능을 사용합니다.
  • 메시 인그레스 레이어의 보안, 승인, 관측 가능성을 사용합니다.

클라우드 인그레스

메시 인그레스와 함께 사용하는 클라우드 인그레스는 에지 보안과 글로벌 부하 분산에 가장 적합합니다. 클라우드 인그레스 레이어는 다음 서비스와 통합되므로 메시 외부의 에지에서 이러한 서비스를 실행하는 데 탁월합니다.

  • DDoS 보호
  • 클라우드 방화벽
  • 인증 및 승인
  • 암호화

라우팅 로직은 일반적으로 클라우드 인그레스 레이어에서 간단합니다. 하지만 멀티 클러스터와 멀티 리전 환경에서는 더 복잡할 수 있습니다.

인터넷 연결용 부하 분산기의 중요한 기능으로 인해 인터넷에서 애플리케이션을 노출하고 보호하는 방법을 독점적으로 제어하는 인프라 팀에서 클라우드 인그레스 레이어를 관리할 가능성이 높습니다. 이러한 제어로 인해 이 레이어는 개발자 중심 인프라보다 동적 유연성이 저하됩니다. 이 레이어에 대한 관리 액세스 권한을 결정하고 해당 액세스 권한을 제공하는 방법을 결정할 때는 다음 요인을 고려하세요.

메시 인그레스

메시 인그레스를 클라우드 인그레스와 함께 사용할 경우 메시 인그레스는 트래픽이 서비스 메시에 진입할 수 있도록 진입점을 제공합니다. 또한 이 레이어는 백엔드 mTLS, 승인 정책, 유연한 정규식 일치를 제공합니다.

메시 인그레스 레이어를 사용하여 메시 외부에 외부 애플리케이션 부하 분산을 배포하면 특히 인터넷 트래픽 관리에 많은 이점이 있습니다. 서비스 메시와 Istio 인그레스 게이트웨이는 메시에서 고급 라우팅 및 트래픽 관리를 제공하지만 일부 기능은 네트워크 에지에서 더욱 효과적으로 제공됩니다. Google Cloud의 외부 애플리케이션 부하 분산기를 통해 인터넷 에지 네트워킹을 활용하면 메시 기반 인그레스에 비해 더 많은 성능, 신뢰성 또는 보안 관련 이점이 제공될 수 있습니다.

사용된 제품 및 기능

다음 목록에서는 이 참조 아키텍처에서 사용하는 모든 Google Cloud 제품과 기능을 요약해서 보여줍니다.

  • GKE Enterprise: Google 인프라를 사용하여 컨테이너화된 애플리케이션을 대규모로 배포하고 운영하는 데 사용할 수 있는 관리형 Kubernetes 서비스입니다. 이 참조 아키텍처를 위해 애플리케이션을 제공하는 각 GKE 클러스터은 같은 Fleet에 있어야 합니다.
  • Fleet 및 멀티 클러스터 게이트웨이: Google 인프라와 GKE Enterprise를 사용하여 엔터프라이즈 규모에서 컨테이너화된 애플리케이션을 만드는 데 사용되는 서비스입니다.
  • Google Cloud Armor: 서비스 거부 및 웹 공격으로부터 애플리케이션과 웹사이트를 보호하는 데 도움이 되는 서비스입니다.
  • Cloud Service Mesh: Envoy 및 Istio 기반 완전 관리형 서비스 메시입니다.
  • 애플리케이션 부하 분산기: 서비스를 실행하고 확장할 수 있게 해주는 프록시 기반 L7 부하 분산기입니다.
  • 인증서 관리자: Cloud Load Balancing에서 사용할 TLS 인증서를 획득하고 관리할 수 있게 해주는 서비스입니다.

Fleet

멀티 클러스터 배포를 관리하기 위해 GKE Enterprise 및 Google Cloud는 Fleet을 사용하여 Kubernetes 클러스터를 논리적으로 그룹화하고 정규화합니다.

Fleet을 하나 이상 사용하면 개별 클러스터에서 전체 클러스터 그룹으로 관리 수준을 상향시킬 수 있습니다. 클러스터 관리 문제를 줄이려면 네임스페이스 동일성에 대한 Fleet 원칙을 사용합니다. Fleet의 GKE 클러스터마다 모든 메시 인그레스 게이트웨이를 동일한 방식으로 구성해야 합니다.

또한 네임스페이스 계정의 서비스 분산 리더가 Fleet의 각 GKE 클러스터에서 동일한 서비스와 연관되도록 애플리케이션 서비스를 일관적으로 배포합니다. Fleet 내에서 유지되는 동일성과 신뢰성에 대한 원칙에 따라 GKE Enterprise 및 Google Cloud에서 모든 Fleet 지원 특성을 활용할 수 있습니다.

서비스 메시 및 트래픽 정책 내 횡방향(East-West) 라우팅 규칙은 메시 인그레스 레이어에서 처리됩니다. 메시 인그레스 레이어는 Fleet의 모든 GKE 클러스터에 배포됩니다. Fleet의 네임스페이스 동일성 원칙에 따라 같은 방식으로 각 메시 인그레스 게이트웨이를 구성합니다.

GKE 게이트웨이의 단일 구성 클러스터가 있지만 Fleet의 모든 GKE 클러스터에서 GKE 게이트웨이 구성을 동기화해야 합니다.

새 구성 클러스터를 지정해야 하는 경우 ConfigSync를 사용합니다. ConfigSync는 이러한 모든 구성이 Fleet의 모든 GKE 클러스터에서 동기화되도록 보장하고 현재가 아닌 구성과의 조정을 방지하는 데 도움이 됩니다.

메시 인그레스 게이트웨이

Istio 0.8에는 메시 인그레스 게이트웨이가 도입되었습니다. 게이트웨이는 서비스 메시 외부에서 들어오는 트래픽에 포트가 노출되는 전용 프록시 집합을 제공합니다. 이러한 메시 인그레스 프록시를 사용하면 애플리케이션 라우팅 동작과 별도로 네트워크 노출 동작을 제어할 수 있습니다.

또한 프록시를 사용하면 트래픽이 애플리케이션 사이드카에 도달하기 전에 라우팅 및 정책을 메시 외부에 있는 트래픽에 적용할 수 있습니다. 메시 인그레스는 메시의 모드에 도착한 트래픽 처리를 정의하지만 외부 구성요소에서 트래픽이 처음 메시에 도착하는 방법을 정의해야 합니다.

외부 트래픽을 관리하려면 메시 외부에 있는 부하 분산기가 필요합니다. 배포를 자동화하기 위해 이 참조 아키텍처에서는 GKE 게이트웨이 리소스를 통해 프로비저닝되는 Cloud Load Balancing을 사용합니다.

GKE 게이트웨이 및 멀티 클러스터 서비스

클러스터 외부에 있는 클라이언트에 애플리케이션 액세스를 제공하는 방법에는 여러 가지가 있습니다. GKE 게이트웨이는 Kubernetes Gateway API의 구현입니다. GKE 게이트웨이는 인그레스 리소스를 발전시키고 개선합니다.

GKE 게이트웨이 리소스를 GKE 클러스터에 배포하면 게이트웨이 컨트롤러가 Gateway API 리소스를 감시합니다. 컨트롤러는 Cloud Load Balancing 리소스를 조정하여 게이트웨이 리소스에서 지정한 네트워킹 동작을 구현합니다.

GKE 게이트웨이를 사용할 때 애플리케이션을 클라이언트에 노출하기 위해 사용하는 부하 분산기 유형은 주로 다음 요인에 따라 달라집니다.

  • 백엔드 서비스가 단일 GKE 클러스터에 있는지 아니면 같은 Fleet의 여러 GKE 클러스터에 분산되는지 여부
  • 클라이언트의 상태(외부 또는 내부)
  • 부하 분산기의 필수 성능(Google Cloud Armor 보안 정책과 통합하는 기능 포함)
  • 서비스 메시의 스팬 요구사항. 서비스 메시는 여러 GKE 클러스터를 확장하거나 단일 클러스터에 포함될 수 있습니다.

게이트웨이에서는 적합한 GatewayClass를 지정하여 이 동작을 제어합니다. 게이트웨이 클래스를 참조할 때 멀티 클러스터 시나리오에서 사용할 수 있는 클래스의 이름은 -mc로 끝납니다.

이 참조 아키텍처에서는 외부 애플리케이션 부하 분산기를 통해 애플리케이션 서비스를 외부에 노출하는 방법을 설명합니다. 하지만 게이트웨이를 사용할 때는 멀티 클러스터 리전 내부 애플리케이션 부하 분산기를 만들 수도 있습니다.

멀티 클러스터 시나리오에서 애플리케이션 서비스를 배포하려면 다음 두 가지 방법으로 Google Cloud 부하 분산기 구성요소를 정의하면 됩니다.

애플리케이션 서비스를 배포할 수 있는 이러한 두 가지 방법에 대한 자세한 내용은 GKE용 멀티 클러스터 부하 분산 API 선택을 참조하세요.

멀티 클러스터 인그레스는 MultiClusterService 리소스 만들기를 사용합니다. 멀티 클러스터 게이트웨이는 ServiceExport 리소스 만들기 및 ServiceImport 리소스 참조를 사용합니다.

멀티 클러스터 게이트웨이를 사용하는 경우 정책을 만들어 기본 Google Cloud 부하 분산기의 추가 기능을 사용 설정할 수 있습니다. 이 참조 아키텍처와 연결된 배포 가이드에서는 Google Cloud Armor 보안 정책을 구성하여 교차 사이트 스크립팅으로부터 백엔드 서비스를 보호하는 방법을 보여줍니다.

이러한 정책 리소스는 여러 클러스터에 노출되는 Fleet의 백엔드 서비스를 대상으로 합니다. 멀티 클러스터 시나리오에서는 이러한 모든 정책이 ServiceImport 리소스와 API 그룹을 참조해야 합니다.

상태 확인

L7 부하 분산의 두 레이어를 사용하는 경우의 한 가지 복잡성은 상태 확인입니다. 각 부하 분산기에서 다음 레이어 상태를 확인하도록 구성해야 합니다. GKE 게이트웨이에서 메시 인그레스 프록시 상태를 확인하고 메시에서 애플리케이션 백엔드 상태를 확인합니다.

  • 클라우드 인그레스: 이 참조 아키텍처에서는 Google Cloud 부하 분산기가 GKE 게이트웨이를 통해 노출된 상태 점검 포트에서 메시 인그레스 프록시 상태를 확인하도록 구성합니다. 메시 프록시가 중단되거나 클러스터, 메시 또는 리전을 사용할 수 없는 경우 Google Cloud 부하 분산기에서 이 상태를 감지하여 트래픽을 메시 프록시로 전송하지 않습니다. 이 경우 트래픽은 다른 GKE 클러스터나 리전의 대체 메시 프록시로 라우팅됩니다.
  • 메시 인그레스: 메시 애플리케이션에서는 로컬로 부하 분산과 트래픽 관리를 실행할 수 있도록 백엔드에서 직접 상태 점검을 수행합니다.

설계 고려사항

이 섹션에서는 이 참조 아키텍처를 사용하여 보안 및 규정 준수, 신뢰성, 비용에 대한 특정 요구사항을 충족하는 아키텍처를 개발하는 데 도움이 되는 안내를 제공합니다.

보안, 개인정보 보호, 규정 준수

이 문서의 아키텍처 다이어그램에는 여러 보안 요소가 포함되어 있습니다. 가장 중요한 요소는 암호화를 구성하고 인증서를 배포하는 방법입니다. GKE 게이트웨이는 이러한 보안을 위해 인증서 관리자와 통합됩니다.

인터넷 클라이언트는 공개 인증서로 인증하고 Virtual Private Cloud(VPC)에서 첫 번째 홉으로 외부 부하 분산기에 연결합니다. 게이트웨이 정의의 인증서 관리자 CertificateMap을 참조할 수 있습니다. 다음 홉은 Google 프런트엔드(GFE)와 메시 인그레스 프록시 사이에 있습니다. 이 홉은 기본적으로 암호화됩니다.

GFE와 백엔드 간의 네트워크 수준 암호화는 자동으로 적용됩니다. 보안 요구사항에 따라 플랫폼 소유자가 암호화 키 소유권을 보유해야 하는 경우 클러스터 게이트웨이(GFE)와 메시 인그레스(envoy 프록시 인스턴스) 간에 TLS 암호화로 HTTP/2를 사용 설정할 수 있습니다.

클러스터 게이트웨이와 메시 인그레스 간에 TLS 암호화로 HTTP/2를 사용 설정하면 자체 서명 인증서나 공개 인증서를 사용하여 트래픽을 암호화할 수 있습니다. GFE에서 인증하지 않으므로 자체 서명 인증서나 공개 인증서를 사용할 수 있습니다. 이 추가 암호화 레이어는 이 참조 아키텍처와 관련된 배포 가이드에서 설명됩니다.

인증서가 잘못 처리되지 않도록 공개 인증서를 재사용하지 마세요. 서비스 메시의 부하 분산기마다 개별 인증서를 사용합니다.

외부 DNS 항목과 TLS 인증서를 만드는 데 도움이 되도록 이 참조 아키텍처의 배포 가이드에서는 Cloud Endpoints를 사용합니다. Cloud Endpoints를 사용하면 외부에서 사용할 수 있는 cloud.goog 하위 도메인을 만들 수 있습니다. 엔터프라이즈 수준의 시나리오에서는 더 적절한 도메인 이름을 사용하고 DNS 서비스 제공업체의 전역 애플리케이션 부하 분산기 IP 주소를 가리키는 A 레코드를 만듭니다.

사용 중인 서비스 메시에 TLS가 필요한 경우 사이드카 프록시 간의 모든 트래픽과 메시 인그레스에 대한 모든 트래픽이 암호화됩니다. 아키텍처 다이어그램에서는 클라이언트에서 Google Cloud 부하 분산기로, 부하 분산기에서 메시 인그레스 프록시로, 인그레스 프록시에서 사이드카 프록시로의 HTTPS 암호화를 보여줍니다.

신뢰성 및 복원력

멀티 클러스터, 멀티 리전 에지-메시 패턴의 주요 이점은 애플리케이션 서비스 간 트래픽과 같이 횡방향(East-West) 부하 분산에 모든 서비스 메시 기능을 사용할 수 있다는 점입니다.

이 참조 아키텍처에서는 멀티 클러스터 GKE 게이트웨이를 사용하여 수신되는 클라우드 인그레스 트래픽을 GKE 클러스터로 라우팅합니다. 시스템은 지연 시간을 기준으로 사용자와의 근접성, 가용성, 상태에 따라 GKE 클러스터를 선택합니다. 트래픽이 Istio 인그레스 게이트웨이(메시 인그레스)에 도달하면 서비스 메시를 통해 적절한 백엔드로 라우팅됩니다.

횡방향(East-West) 트래픽을 처리하기 위한 대체 방법은 여러 GKE 클러스터에 배포된 모든 애플리케이션 서비스에 대한 멀티 클러스터 서비스를 사용하는 것입니다. Fleet의 여러 GKE 클러스터에서 멀티 클러스터 서비스를 사용하는 경우 ClusterSet에서 서비스 엔드포인트가 함께 수집됩니다. 서비스가 다른 서비스를 호출해야 하는 경우 두 번째 서비스의 정상 엔드포인트를 타겟팅할 수 있습니다. 엔드포인트는 순환 방식으로 선택되므로 선택한 엔드포인트는 다른 영역이나 다른 리전에 있을 수 있습니다.

멀티 클러스터 서비스를 사용하는 대신 횡방향(East-West) 트래픽에 서비스 메시를 사용할 때의 주요 이점은 서비스 메시에서 지역 부하 분산을 사용할 수 있다는 점입니다. 지역 부하 분산은 멀티 클러스터 서비스 기능이 아니지만 DestinationRule을 통해 지역 부하 분산을 구성할 수 있습니다.

구성이 완료되면 한 서비스에서 다른 서비스로의 호출은 먼저 같은 영역의 서비스 엔드포인트에 도달한 후 호출 서비스와 동일한 리전에서 시도합니다. 마지막으로, 호출은 같은 영역이나 같은 리전의 서비스 엔드포인트를 사용할 수 없는 경우에만 다른 리전의 엔드포인트를 타겟팅합니다.

비용 최적화

이 멀티 클러스터 아키텍처를 기업 전체에서 광범위하게 채택하면 Cloud Service Mesh 및 멀티 클러스터 게이트웨이가 Google Kubernetes Engine(GKE) Enterprise 버전에 포함됩니다. 또한 GKE Enterprise에는 GKE 클러스터, 애플리케이션, 기타 프로세스를 대규모로 관리하고 제어할 수 있는 여러 기능이 포함되어 있습니다.

배포

이 아키텍처를 배포하려면 에지에서 멀티 클러스터 메시로: GKE 게이트웨이 및 Cloud Service Mesh를 통해 전역으로 분산된 애플리케이션 배포를 참조하세요.

다음 단계

참여자

저자:

기타 참여자: