Cloud Service Mesh 서비스 라우팅 API 개요

이 문서는 Cloud Service Mesh 및 서비스 메시 개념에 대해 중급 이상 수준의 지식을 갖추고 VM 인스턴스를 사용하여 Compute Engine에서 Cloud Service Mesh를 배포하는 메시 또는 플랫폼 관리자와 서비스 개발자를 대상으로 합니다. 이 문서는 Envoy 및 gRPC 클라이언트를 사용하는 배포에 적용됩니다. Cloud Service Mesh 개념에 대한 자세한 내용은 일반 개요를 참조하세요.

Cloud Service Mesh는 고급 트래픽 관리, 관측 가능성, 보안을 포함하여 애플리케이션에 서비스 네트워킹 기능을 제공합니다. 하지만 서비스 메시 구성과 운영은 메시지 관리자 및 서비스 개발자에게 복잡한 태스크입니다.

이 문서에서는 Cloud Service Mesh 구성에 사용되는 서비스 라우팅 API를 설명합니다. 이러한 API는 전반적으로 메시 구성 환경을 간소화하고 향상시킬 수 있도록 설계되었습니다.

서비스 라우팅 모델은 Mesh, Gateway, Route라는 API 리소스를 사용합니다. 이러한 리소스는 서비스 네트워킹 컨트롤 플레인을 정의할 때 상황에 맞는 구성 환경을 제공합니다.

이 문서에서는 다음과 같은 서비스 라우팅 API 모델 및 리소스를 소개합니다.

• Mesh 리소스
  • Envoy 사이드카 프록시 및 프록시리스 gRPC 클라이언트에 대한 서비스 간(East-West) 트래픽 관리 및 보안 구성

• Gateway 리소스

  • 인그레스 게이트웨이 역할을 하는 Envoy 프록시의 트래픽 관리 및 보안 구성으로 외부 클라이언트가 서비스 메시(North-South)에 연결 가능

• 다음 유형의 Route 리소스:

  • HTTPRoute
  • GRPCRoute
  • TCPRoute
  • TLSRoute

Google Cloud 콘솔은 서비스 라우팅 API를 지원하지 않습니다. Google Cloud CLI 또는 REST API를 사용하여 이러한 API 리소스를 구현해야 합니다.

사용 사례 및 이점

서비스 라우팅 API를 사용하면 프록시리스 gRPC 및 Envoy 프록시 배포 모두에 Cloud Service Mesh를 구성할 수 있습니다. 서비스 라우팅 API 모델은 몇 가지 중요한 이점을 제공합니다.

다음 다이어그램에서는 서비스 메시의 두 서비스가 Mesh 리소스로 연결되어 있습니다. 두 HTTPRoute 리소스가 라우팅을 구성합니다. 메시 또는 플랫폼 관리자가 Mesh 리소스를 관리하고 두 서비스 소유자가 서비스에 대한 라우팅 구성을 만듭니다.

역할 중심의 API 설계로 명확한 책임 구분 가능

서비스 라우팅 API에서는 조직 역할을 기준으로 메시 구성 책임을 분리할 수 있습니다.

• 메시 관리자는 논리적 메시와 인그레스 게이트웨이 인프라를 정의할 수 있습니다.
• 서비스 소유자(애플리케이션 개발자)는 서비스에 대한 액세스 패턴을 독립적으로 정의할 수 있습니다. 또한 서비스에 대한 트래픽 관리 정책을 정의하고 적용할 수 있습니다.

다음 다이어그램에서 Cloud Load Balancing 및 Gateway 리소스는 메시에 없는 클라이언트에서 메시로 들어가는 트래픽에 대한 인그레스 게이트웨이를 제공합니다. 메시 관리자는 Gateway 리소스를 구성 및 관리하고 서비스 소유자는 자신의 고유 서비스 및 트래픽 라우팅을 구성하고 관리합니다.

셀프 서비스 모델로 안정성 향상

서비스 라우팅 API는 독립 서비스 소유자가 구성하고 소유할 수 있는 프로토콜별, 라우팅별 리소스를 사용합니다. 이 방식의 장점은 다음과 같습니다.

• 서비스 소유자가 자신이 소유하는 서비스에 대한 정책과 트래픽 관리 방식을 자율적으로 구성할 수 있습니다.
• 하나의 Route 리소스를 업데이트해도 메시의 다른 Route 리소스에는 영향을 주지 않습니다. 서비스 소유자가 작은 구성을 관리하므로 업데이트 프로세스가 더욱 안정적입니다.
• 대상 서비스 또는 호스트 이름을 담당하는 서비스 소유자가 각 Route 리소스를 소유합니다.
• 서비스 소유자가 라우팅을 업데이트하기 위해 메시 관리자에게 의존할 필요가 없습니다.

공유 VPC 환경의 여러 프로젝트에 걸쳐 서비스 메시 사용 설정

서비스 라우팅 API 모델을 사용하면 서비스 소유자가 공유 VPC 및 기타 연결 방법을 사용하여 공유 메시 인프라에 참여하면서도 자신의 서비스를 독립적으로 제어할 수 있습니다. 예를 들어 서비스 소유자가 자신의 프로젝트에 Route 리소스를 정의할 수 있습니다. 플랫폼 관리자는 중앙에서 관리되는 호스트 프로젝트에 Mesh를 정의한 후 서비스 소유자에게 Route 리소스를 공유 Mesh 또는 Gateway에 연결할 수 있는 IAM 권한을 부여할 수 있습니다. 다음 다이어그램은 공유 VPC가 포함된 예시를 보여줍니다.

또한 서비스 라우팅 API를 사용하면 VPC 네트워크 피어링을 통해 다른 네트워크에 서비스 메시 클라이언트를 연결할 수 있습니다.

서버 이름 표시기 기준 트래픽 라우팅

TLSRoute 리소스를 사용하면 TLS 핸드셰이크의 서버 이름 표시(SNI)를 기준으로 TLS로 암호화된 트래픽을 라우팅할 수 있습니다. TLSRoute 리소스에 SNI 일치를 구성하여 TLS 트래픽이 적절한 백엔드 서비스로 라우팅되도록 구성할 수 있습니다. 이러한 배포에서 프록시는 트래픽만 라우팅하고 대상 백엔드 인스턴스에서 TLS 세션이 종료됩니다.

TLSRoute 리소스는 사이드카 프록시 또는 게이트웨이로 배포되는 Envoy 프록시에만 지원됩니다.

Mesh 리소스에 연결된 TLSRoute 리소스

다음 다이어그램에 표시된 배포는 service1 값이 포함된 SNI 확장 프로그램이 있는 서비스 메시 트래픽을 백엔드 서비스 service1로 라우팅합니다. 또한 SNI 확장 프로그램에 service2 값이 포함된 서비스 메시 트래픽이 백엔드 서비스 service2로 라우팅됩니다. SNI 확장 프로그램 값과 백엔드 서비스 이름은 서로 독립적입니다.

Gateway 리소스에 연결된 TLSRoute 리소스

다음 다이어그램에 표시된 배포는 SNI 확장 프로그램에 serviceA 값이 포함된 Gateway 리소스에 대한 인바운드 트래픽을 백엔드 서비스 serviceA로 라우팅합니다. 또한 SNI 확장 프로그램에 serviceB 값이 포함된 Gateway에 대한 인바운드 트래픽이 백엔드 서비스 serviceB로 라우팅됩니다. SNI 확장 프로그램 값과 백엔드 서비스 이름은 서로 독립적입니다. SNI 확장 프로그램 값과 HTTP 요청의 헤더도 서로 독립적입니다.

Gateway 리소스는 Gateway의 Envoy 프록시에서 TLS 연결을 종료하지 않습니다. 대신 해당 백엔드 서비스에서 TLS 연결이 종료됩니다. Gateway는 일반 텍스트 SNI 확장 프로그램을 포함하는 ClientHello를 볼 수 있는 것 외에 TLS 레이어에서 어떠한 암호화된 정보도 검사할 수 없습니다. Gateway는 이 모드에서 TLS 패스스루를 수행합니다. 암호화된 ClientHello는 지원되지 않습니다.

핵심 gRPC 지원

메서드별 일치와 같은 핵심 gRPC 속성을 사용하여 프록시리스 gRPC 클라이언트를 구성할 수 있습니다.

TCP 트래픽의 트래픽 분할

여러 백엔드 서비스에서 TCP 트래픽에 대한 가중치 기반 트래픽 분할을 구현할 수 있습니다. 서비스를 업데이트할 때 카나리아(블루-그린) 출시와 같은 패턴을 구성할 수 있습니다. 또한 트래픽 분할을 통해 다운타임 없이 제어된 방식으로 트래픽을 마이그레이션할 수 있습니다.

트래픽 가로채기

서비스 라우팅 API Mesh 및 Gateway 리소스를 사용하면 모든 트래픽이 자동으로 차단됩니다. 자세한 내용은 자동 Envoy 배포를 사용한 Compute Engine VM 설정 옵션을 참조하세요.

아키텍처 및 리소스

이 섹션에서는 서비스 라우팅 API 모델과 해당 리소스를 설명하고 서비스 라우팅 API 리소스가 함께 작동하는 방식을 설명합니다.

Mesh 리소스

Mesh 리소스는 서비스 메시의 인스턴스를 나타냅니다. 이를 사용해서 프로젝트에 논리적 서비스 메시를 만듭니다. 각 Mesh 리소스는 프로젝트에서 이름이 고유해야 합니다. Mesh 리소스를 만든 후에는 이름을 수정할 수 없습니다.

Mesh 리소스는 Route 리소스에서 참조되어 메시의 일부인 서비스의 경로를 추가합니다.

Envoy 프록시 및 프록시리스 gRPC 클라이언트는 Mesh 리소스 이름으로 식별된 서비스 메시에 조인하여 Cloud Service Mesh에서 구성을 받습니다. Mesh 리소스는 다음 데이터 영역 배포를 지원합니다.

• 사이드카 프록시로 애플리케이션과 함께 실행되는 Envoy
• 프록시리스 gRPC 클라이언트
• Envoy 사이드카 및 프록시리스 gRPC 클라이언트 혼합

Route 리소스

Route 리소스는 서비스에 라우팅을 설정하기 위해 사용됩니다. Route API 리소스에는 네 가지 유형이 있습니다. 이러한 리소스는 트래픽을 백엔드 서비스로 라우팅하기 위해 사용되는 프로토콜을 정의합니다.

• HTTPRoute
• GRPCRoute
• TCPRoute
• TLSRoute

API에는 Route API가 포함되어 있지 않습니다. 구성 가능한 API 리소스는 HTTPRoute, GRPCRoute, TCPRoute, TLSRoute뿐입니다.

Route 리소스는 하나 이상의 Mesh 및 Gateway 리소스를 참조하여 해당 Mesh 또는 Gateway 구성의 일부인 경로를 추가합니다. Route 리소스는 Gateway 및 Mesh 리소스를 참조할 수 있습니다.

Route 리소스도 백엔드 서비스 리소스 하나 이상을 참조합니다. 이 서비스는 백엔드 서비스 API를 통해 구성됩니다. MIG 또는 NEG 백엔드 하나 이상을 가리키는 백엔드 서비스 리소스를 만듭니다.

다음 다이어그램은 Mesh, Gateway, Route 리소스와 백엔드 서비스 리소스 및 해당 백엔드 사이의 관계를 보여줍니다.

Route 리소스에서 라우팅, 헤더 수정, 시간 제한, 가중치 기반 트래픽 분할 등의 다른 트래픽 관리 기능을 정의합니다. 예를 들어 다음 다이어그램에서 HTTPRoute 리소스는 두 백엔드 서비스 간의 70%/30% 트래픽 분할을 정의합니다.

서비스 메시 관리를 간소화하려면 Mesh 또는 Gateway 리소스에 연결된 모든 Route 리소스를 나열하면 됩니다.

TLSRoute 리소스

TLSRoute 리소스를 사용하여 SNI 호스트 이름 및 애플리케이션 레이어 프로토콜 협상(ALPN) 이름을 기준으로 TLS 트래픽을 백엔드 서비스로 라우팅합니다. TLSRoute 구성은 Envoy 프록시가 TLS 트래픽을 종료하지 않는 TLS 패스스루를 의미합니다.

TLSRoute 리소스는 하나 이상의 Mesh 및 Gateway 리소스를 참조하여 해당 메시 또는 게이트웨이 구성의 일부인 경로를 추가합니다.

TLSRoute 리소스도 백엔드 서비스 리소스 하나 이상을 참조합니다. 이 서비스는 백엔드 서비스 API 리소스를 통해 구성됩니다.

Gateway 리소스

Gateway 리소스는 인그레스 게이트웨이로 작동하는 Envoy 프록시를 나타내기 위해 사용되며, 외부 클라이언트가 서비스 메시(North-South 트래픽)에 연결하도록 허용합니다. 이 리소스에는 scope 매개변수와 함께 리스닝 포트가 있습니다. 인그레스 게이트웨이로 작동하는 Envoy 프록시는 지정된 포트 및 로컬 VM의 모든 IP 주소를 나타내는 0.0.0.0에 바인딩됩니다. 다음 다이어그램은 인그레스 서비스로 배포되고 Gateway 리소스로 구성된 Envoy 프록시를 보여줍니다. 이 특정 예시에서 Envoy 프록시는 클라이언트에서의 수신 연결을 포트 80에서 리슨하도록 구성됩니다.

Gateway API 리소스는 Envoy 프록시 데이터 영역만 지원합니다. 프록시리스 gRPC를 지원하지 않습니다. gRPCRoutes는 Gateway 리소스에서 지원되지만 gRPC 트래픽이 미들 프록시로 작동하는 Envoy 프록시로 라우팅됩니다.

Gateway 범위 및 병합된 Gateway 구성은 무엇인가요?

Gateway 리소스 인스턴스는 해당 포트에서 수신된 트래픽에 대한 포트 및 구성을 나타냅니다. Gateway API 리소스에는 두 개 이상의 Gateway 리소스 구성을 논리적으로 그룹화하고 병합하는 데 사용되는 scope 매개변수가 있습니다.

예를 들어 Gateway 프록시가 HTTP 및 HTTPS 트래픽을 수신하기 위해 각각 포트 80 및 443에서 리슨하도록 하려면 2개의 Gateway 리소스를 만듭니다. HTTP 트래픽에 대해 포트 80으로 Gateway 리소스를 하나 구성하고 HTTPS 트래픽에 대해서도 포트 443으로 다른 리소스를 하나 구성합니다. 각 리소스의 scope 필드에 동일한 값을 지정합니다. Cloud Service Mesh는 범위가 동일한 모든 게이트웨이의 개별 구성을 동적으로 병합합니다. 또한 Gateway 구성을 수신하려면 데이터 영역 측의 인그레스 게이트웨이 모드에서 실행되는 Envoy 프록시에서 Cloud Service Mesh에 같은 범위 파라미터를 제공해야 합니다. Gateway 리소스를 만들 때 범위를 지정하고 프록시의 부트스트랩 매개변수와 동일한 범위를 지정합니다.

다음은 Gateway 리소스에 대한 주요 고려사항입니다.

• Gateway 범위 매개변수는 필수 항목입니다. Gateway가 하나만 있더라도 Gateway 리소스와 Envoy 프록시의 부트스트랩 구성에 범위를 지정합니다.
• Gateway 리소스를 만들어도 Envoy 프록시가 있는 서비스는 배포되지 않습니다. Envoy 프록시 배포는 별도의 단계입니다.
• Gateway 리소스에는 인그레스 배포 유형을 나타내는 type이 있습니다. 이 필드는 나중에 사용하도록 예약되어 있습니다. 현재 지원되는 유일한 값은 기본값이자 수정할 수 없는 OPEN_MESH입니다.

혼합된 프로토콜 및 데이터 영역을 사용한 메시 배포

혼합된 데이터 영역 배포를 구성하고 Envoy 프록시 및 프록시리스 gRPC를 동일 메시에 포함할 수 있습니다. 이러한 배포를 만들 때는 다음을 고려하세요.

• Envoy 사이드카 배포는 모든 경로(HTTPRoute, GRPCRoute, TCPRoute, TLSRoute)를 지원합니다.
• 프록시리스 gRPC 배포는 GRPCRoute만 지원합니다.
• GRPCRoute는 gRPC 프록시리스 배포에서만 지원되는 기능으로 제한됩니다.

다중 프로젝트 공유 VPC 환경에서 지원되는 토폴로지

Cloud Service Mesh는 다른 프로젝트에 정의된 Route 리소스를 중앙 집중식 관리 프로젝트에 정의된 Mesh 또는 Gateway 리소스에 추가할 수 있습니다. 승인된 서비스 소유자는 자신의 서비스 라우팅 구성을 Mesh 또는 Gateway에 직접 추가할 수 있습니다.

일반적인 교차 프로젝트 시나리오에서는 프로젝트(호스트 프로젝트 또는 중앙에서 관리되는 관리 프로젝트)를 Mesh 리소스를 만들 메시 관리 프로젝트로 선택합니다. 메시 관리 프로젝트 소유자는 다른 프로젝트의 Route 리소스가 Mesh 리소스를 참조하도록 승인하여 다른 프로젝트의 라우팅 구성이 메시의 일부가 되도록 합니다. Envoy 또는 gRPC에 관계없이 메시 데이터 영역은 관리 프로젝트에서 구성을 요청하고 Mesh에 연결된 모든 경로의 통합을 수신합니다. Gateway의 경우 경로는 동일한 범위를 사용하는 모든 Gateways에서 병합됩니다.

Mesh 관리 프로젝트는 선택한 모든 프로젝트일 수 있으며 기본 프로젝트에서 공유 VPC 또는 VPC 네트워크 피어링을 통해 VPC 네트워크 연결을 유지하는 한 구성이 작동합니다.

IAM 권한 및 역할

다음은 Mesh 및 Route 리소스를 안전하게 가져오고, 만들고, 업데이트하고, 삭제하고, 나열하고, 사용하는 데 필요한 IAM 권한입니다.

• 메시 관리자에게 networkservices.mesh.* 권한이 있어야 합니다.
• 게이트웨이 관리자에게 networkservices.gateways.* 권한이 있어야 합니다.
• 서비스 소유자는 networkservices.grpcRoutes.*, networkservices.httpRoutes.* 또는 networkservices.tcpRoutes.* 권한이 있어야 합니다.

메시 관리자는 서비스 소유자가 Route 리소스를 Mesh 리소스에 연결할 수 있도록 서비스 소유자에게 networkservices.mesh.use 권한을 부여해야 합니다. 동일한 모델이 Gateway 리소스에 적용됩니다.

Mesh 리소스의 모든 IAM 권한을 보려면 IAM 권한 참조 페이지로 이동하고 meshes를 검색합니다.

사전 정의된 추가 역할은 필요하지 않습니다. 기본적으로 기존 사전 정의된 역할 Compute 네트워크 관리자(roles/compute.networkAdmin)에게는 networkservices.* 권한이 있습니다. 이전에 설명된 권한을 커스텀 역할에 추가해야 할 수도 있습니다.

고려사항 및 제한사항

• Google Cloud 콘솔은 서비스 라우팅 API를 지원하지 않습니다.
• xDS API 버전 3 이상을 사용합니다.
  • 최소 Envoy 버전 1.20.0(서비스 라우팅 API는 xDS 버전 3에서만 지원됨)
  • 최소 gRPC 부트스트랩 생성기 버전 v0.14.0.
• TLSRoute 리소스는 사이드카 프록시 또는 게이트웨이로 배포되는 Envoy 프록시에만 지원됩니다.
• 자동 Envoy 배포를 사용하는 Compute Engine VM과 자동 Envoy 삽입을 사용하는 GKE 포드만 지원됩니다. 서비스 라우팅 API에서 수동 배포를 사용할 수 없습니다.
• 서비스 라우팅 API는 이전 API와 하위 호환되지 않습니다.
• TCPRoute 리소스가 Mesh 리소스에 연결되면 TCP 트래픽을 일치시키는 데 사용되는 포트는 이 TCPRoute에서 설명하는 트래픽을 처리하는 것 외에는 사용할 수 없습니다.
  • 예를 들어 배포에 포트 "8000"과 일치하는 TCPRoute 리소스 및 HttpRoute 리소스가 포함될 수 있습니다. 둘 다 동일한 Mesh 리소스에 연결되어 있으면 기본 IP 주소가 다르더라도 HTTPRoute 리소스로 라우팅되는 트래픽이 포트 8000을 사용할 수 없습니다. 이렇나 제한사항은 포트 일치 라우팅에 먼저 우선권을 부여하는 Envoy 프록시 구현으로부터 비롯됩니다.
• Gateway 리소스는 관리형 부하 분산기를 프로비저닝하지 않으며 Envoy 서비스를 동적으로 만들지 않습니다.
• 인그레스 게이트웨이로 작동하는 자동으로 배포된 Envoy에는 serving_ports 인수가 --service-proxy 플래그로 지정되지 않아야 합니다.
• 자동으로 배포된 Envoy는 VM 프로젝트와 다른 프로젝트 번호 제공을 지원하지 않습니다.

다음 단계

• Mesh 또는 Gateway 리소스와 연결된 경로 리소스 나열에 관한 자세한 내용은 Route 리소스 나열을 참조하세요. 이 기능은 미리보기 버전으로 제공됩니다.
• 서비스 라우팅 API에 대한 자세한 내용은 네트워크 서비스 API 문서를 참조하기