에지에서 메시로: GKE 인그레스를 통해 서비스 메시 애플리케이션 노출

Last reviewed 2023-10-24 UTC

이 참조 아키텍처에서는 Cloud Service Mesh와 Cloud Load Balancing을 결합하여 서비스 메시의 애플리케이션을 인터넷 클라이언트에 노출하는 방법을 보여줍니다.

Cloud Service Mesh는 Istio 기반의 관리형 서비스 메시로, 보안이 강화되고 관측 가능성이 높은 표준화된 애플리케이션 통신 레이어를 제공합니다. 서비스 메시는 메시에서 통신 중인 클라이언트를 위한 종합적인 통신 플랫폼을 제공합니다. 그러나 메시 외부에 있는 클라이언트를 메시 내부에서 호스팅된 애플리케이션에 연결하는 방법은 여전히 해결해야 할 문제입니다.

클라이언트 위치에 따라 여러 가지 방법으로 클라이언트에 애플리케이션을 노출할 수 있습니다. 이 참조 아키텍처는 Cloud Service Mesh를 실행하는 고급 실무자를 대상으로 하지만 Google Kubernetes Engine (GKE)의 Istio에도 적용됩니다.

메시 인그레스 게이트웨이

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

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

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

Google Cloud의 경우 이 설정의 표준 예시는 공개 네트워크 부하 분산기 (L4)를 배포하는 외부 부하 분산 서비스입니다. 이 부하 분산기는 GKE 클러스터의 NodePort를 가리킵니다. 이러한 NodePort는 트래픽을 다운스트림 메시 사이드카 프록시로 라우팅하는 Istio 인그레스 게이트웨이 포드를 노출합니다.

아키텍처

이 토폴로지를 다이어그램으로 나타내면 다음과 같습니다. 내부 비공개 트래픽의 부하 분산은 이 아키텍처와 유사하지만 내부 패스 스루 네트워크 부하 분산기를 배포한다는 점이 다릅니다.

외부 부하 분산기는 외부 클라이언트를 인그레스 게이트웨이 프록시를 통해 메시로 라우팅합니다.

위의 다이어그램은 메시 인그레스 게이트웨이를 통해 투명한 L4 부하 분산을 사용하면 다음과 같은 이점이 있음을 보여줍니다.

  • 이 설정은 부하 분산기의 배포를 간소화합니다.
  • 부하 분산기는 클러스터 변경, 노드 중단 또는 프로세스 중단이 발생할 때 안정적인 가상 IP 주소(VIP), 상태 확인, 안정적인 트래픽 분산을 제공합니다.
  • 모든 라우팅 규칙, TLS 종료, 트래픽 정책은 메시 인그레스 게이트웨이의 단일 위치에서 처리됩니다.

GKE 게이트웨이 및 서비스

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

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

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

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

GKE 게이트웨이에서는 적절한 GatewayClass를 지정하여 이 동작을 제어합니다.

Cloud Service Mesh의 기본 부하 분산기는 네트워크 부하 분산기이지만 이 참조 아키텍처는 외부 애플리케이션 부하 분산기 (L7)에 중점을 둡니다. 외부 애플리케이션 부하 분산기는 IAP(Identity-Aware Proxy) 및 Google Cloud Armor와 같은 에지 서비스, URL 리디렉션 및 재작성, 전 세계에 분산된 에지 프록시 네트워크와 통합될 수 있습니다. 다음 섹션에서는 두 레이어의 HTTP 부하 분산을 사용하는 경우의 아키텍처와 이점을 설명합니다.

클라우드 인그레스 및 메시 인그레스

외부 L7 부하 분산을 메시 인그레스 레이어와 함께 메시 외부에 배포하면 인터넷 트래픽에 상당한 이점을 제공합니다. Cloud Service Mesh 및 Istio 인그레스 게이트웨이는 메시에서 고급 라우팅 및 트래픽 관리를 제공하지만 일부 기능은 네트워크 에지에서 더욱 효과적으로 제공됩니다. Google Cloud의 외부 애플리케이션 부하 분산기를 통해 인터넷 에지 네트워킹을 활용하면 메시 기반 인그레스에 비해 성능과 안정성이 대폭 향상되고 보안 관련 이점을 제공할 수 있습니다. 이점은 다음과 같습니다.

이 L7 부하 분산의 외부 레이어는 메시 인그레스에 사용되는 자체 호스팅 프록시 대신 클라우드 관리 부하 분산기를 기반으로 빌드되기 때문에 클라우드 인그레스라고 합니다. 클라우드 인그레스와 메시 인그레스의 조합은 Google Cloud 인프라와 메시를 상호 보완하는 기능을 활용합니다. 다음 다이어그램은 클라우드 인그레스 (GKE 게이트웨이를 통해)와 메시 인그레스를 결합하여 인터넷 트래픽을 위한 두 가지 부하 분산 레이어로 사용하는 방법을 보여줍니다.

클라우드 인그레스는 VPC 네트워크를 통해 메시에 대한 외부 트래픽의 게이트웨이 역할을 합니다.

앞의 다이어그램의 토폴로지에서 클라우드 인그레스 레이어는 서비스 메시 외부에서 유입되는 트래픽을 수집하고 이 트래픽을 메시 인그레스 레이어로 전달합니다. 그러면 메시 인그레스 레이어가 메시에서 호스팅된 애플리케이션 백엔드로 트래픽을 전달합니다.

클라우드 및 메시 인그레스 토폴로지

이 섹션에서는 각 인그레스 레이어를 함께 사용할 때 충족되는 보완 역할을 설명합니다. 이러한 역할은 구체적인 규칙이 아니라 각 레이어의 이점을 사용하는 가이드라인입니다. 사용 사례에 따라 이 패턴이 달라질 수 있습니다.

  • 클라우드 인그레스: 메시 인그레스와 함께 사용하는 클라우드 인그레스는 에지 보안과 글로벌 부하 분산에 가장 적합합니다. 클라우드 인그레스 레이어는 에지의 DDoS 보호, 클라우드 방화벽, 인증, 암호화 제품과 통합되므로 메시 외부에서 이러한 서비스를 실행하는 데 진가를 발휘합니다. 일반적으로 라우팅 로직은 간단하지만 멀티 클러스터 및 멀티 리전 환경에서는 더 복잡합니다. 인터넷 연결용 부하 분산기의 중요한 기능 때문에 클라우드 인그레스 레이어는 인터넷에서 애플리케이션을 노출하고 보호하는 방법을 독점적으로 제어하는 인프라 팀에 의해 관리될 가능성이 높습니다. 또한 이러한 제어 기능으로 인해 이 레이어는 개발자 중심의 인프라보다 동적 유연성이 저하되므로 이 레이어에 대한 관리 액세스를 제공하는 사용자와 방법에 영향을 미칠 수 있습니다.
  • 메시 인그레스: 메시 인그레스는 클라우드 인그레스와 함께 사용할 경우 애플리케이션에 가까운 유연한 라우팅을 제공합니다. 이러한 유연성 덕분에 메시 인그레스는 클라우드 인그레스보다 복잡한 라우팅 로직과 애플리케이션 수준 가시성에 더 적합합니다. 또한 인그레스 레이어를 분리할 경우 애플리케이션 소유자는 다른 팀에 영향을 미치지 않고도 이 레이어를 직접 더 쉽게 제어할 수 있습니다. L7 부하 분산기 대신 L4 부하 분산기를 통해 서비스 메시 애플리케이션을 노출하는 경우 애플리케이션을 보호하기 위해 메시 내부의 메시 인그레스 레이어에서 클라이언트 TLS를 종료해야 합니다.

상태 확인

L7 부하 분산의 두 레이어를 사용하는 경우의 한 가지 복잡성은 상태 확인입니다. 다음 레이어에서 트래픽을 수신할 수 있는지 상태를 확인하도록 각 부하 분산기를 구성해야 합니다. 다음 다이어그램의 토폴로지는 클라우드 인그레스에서 메시 인그레스 프록시의 상태를 확인하고 메시에서 애플리케이션 백엔드의 상태를 확인하는 방법을 보여줍니다.

클라우드 인그레스에서 메시 인그레스의 상태를 확인하고 메시 인그레스는 애플리케이션 백엔드의 상태를 확인합니다.

위 토폴로지에서는 다음을 고려해야 합니다.

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

보안

위 토폴로지에는 여러 보안 요소도 포함되어 있습니다. 가장 중요한 요소 중 하나는 암호화를 구성하고 인증서를 배포하는 방법입니다. GKE 게이트웨이는 Google 관리 인증서와 통합됩니다. 게이트웨이 정의의 인증서 관리자 CertificateMap을 참조할 수 있습니다. 인터넷 클라이언트는 공개 인증서로 인증하고 Virtual Private Cloud(VPC)에서 첫 번째 홉으로 외부 부하 분산기에 연결합니다.

Google 프런트엔드(GFE)와 메시 인그레스 프록시 사이에 있는 다음 홉은 기본적으로 암호화됩니다. GFE와 백엔드 간의 네트워크 수준 암호화는 자동으로 적용됩니다. 그러나 보안 요구사항에 따라 플랫폼 소유자가 암호화 키의 소유권을 보유해야 할 경우 클러스터 게이트웨이(GFE)와 메시 인그레스(envoy 프록시 인스턴스) 간에 TLS 암호화로 HTTP/2를 사용 설정할 수 있습니다. 이 경로에 대해 TLS 암호화로 HTTP/2를 사용 설정하는 경우 GFE가 인증을 이에 대해 수행하지 않기 때문에 자체 서명 또는 공개 인증서를 사용하여 트래픽을 암호화할 수 있습니다. 이 추가 암호화 레이어는 관련 배포 가이드에서 설명합니다. 인증서의 잘못된 처리를 방지하기 위해 다른 곳에서 공용 부하 분산기의 공개 인증서를 사용하지 마세요. 대신 서비스 메시에는 별도의 인증서를 사용하는 것이 좋습니다.

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

메시 외부의 관리형 인증서와 메시 내부의 내부 인증서를 사용하여 보안이 구현됩니다.

비용 최적화

이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

Deployment

이 아키텍처를 배포하려면 에지에서 메시로: GKE 게이트웨이를 통해 서비스 메시 애플리케이션 배포를 참조하세요.

다음 단계