Traffic Director 서비스 라우팅 API 개요
이 문서는 Traffic Director 및 서비스 메시 개념에 관해 중급 및 고급 수준의 지식을 갖춘 메시 또는 플랫폼 관리자와 서비스 개발자를 대상으로 합니다. 이 문서는 Envoy 및 gRPC 클라이언트를 사용하는 배포에 적용됩니다. Traffic Director 개념에 대한 자세한 내용은 일반 개요 및 프록시리스 gRPC 서비스 개요를 참조하세요.
Traffic Director는 고급 트래픽 관리, 관측, 보안을 포함하여 애플리케이션에 대한 서비스 네트워킹 기능을 제공합니다. 하지만 서비스 메시 구성과 운영은 메시지 관리자 및 서비스 개발자에게 복잡한 태스크입니다.
이 문서에서는 Traffic Director 구성을 위한 서비스 라우팅 API를 설명합니다. 이 API는 전반적으로 메시 구성 환경을 단순화하고 향상시킬 수 있도록 설계되었습니다.
이 API 모델은 이전의 전달 규칙, 대상 프록시, URL 맵 리소스를 Mesh, Gateway, Route라는 API 리소스로 대체합니다.
이러한 리소스는 서비스 네트워킹 제어 영역을 정의할 때 상황에 맞는 구성 환경을 제공합니다.
이 문서에서는 다음과 같은 서비스 라우팅 API 모델 및 리소스를 소개합니다.
Mesh- Envoy 사이드카 프록시 및 프록시리스 gRPC 클라이언트에 대한 서비스 간(East-West) 트래픽 관리 및 보안 구성
- 서비스 메시를 식별하고 트래픽 가로채기 및 라우팅과 정책 적용을 수행하는 구성요소를 나타내며, 트래픽 가로채기 포트도 식별합니다.
Gateway- 인그레스 게이트웨이 역할을 하는 Envoy 프록시의 트래픽 관리 및 보안 구성으로 외부 클라이언트가 서비스 메시(North-South)에 연결 가능
- 중간 프록시를 식별하고 IP 주소:포트 쌍 목록에서 리슨하고, 트래픽을 라우팅하고, 정책을 적용하는 구성요소를 나타냅니다.
Route
Google Cloud 콘솔은 서비스 라우팅 API를 지원하지 않습니다. Google Cloud CLI 또는 REST API를 사용하여 이러한 API 리소스를 구현해야 합니다. 또한 이전 API에서 서비스 라우팅 API로의 자동화된 마이그레이션 경로도 없습니다. 기존 배포를 바꾸려면 서비스 라우팅 API를 사용하여 새 Traffic Director 배포를 만들고 이전 배포를 종료해야 합니다.
사용 사례 및 이점
서비스 라우팅 API를 사용하면 프록시리스 gRPC 및 Envoy 프록시 배포 모두 Traffic Director를 구성할 수 있습니다. 서비스 라우팅 API 모델은 몇 가지 중요한 이점을 제공합니다.
다음 다이어그램에서는 서비스 메시의 두 서비스가 Mesh 리소스로 연결되어 있습니다. 두 HTTPRoute 리소스가 라우팅을 구성합니다. 메시 또는 플랫폼 관리자가 Mesh 리소스를 관리하고 두 서비스 소유자가 서비스에 대한 라우팅 구성을 만듭니다.
역할 중심의 API 설계로 명확한 책임 구분 가능
서비스 라우팅 API에서는 조직 역할을 기준으로 메시 구성 책임을 분리할 수 있습니다.
- 메시 관리자는 논리적 메시와 인그레스 게이트웨이 인프라를 정의할 수 있습니다.
- 서비스 소유자(애플리케이션 개발자)는 서비스에 대한 액세스 패턴을 독립적으로 정의할 수 있습니다. 또한 서비스에 대한 트래픽 관리 정책을 정의하고 적용할 수 있습니다.
다음 다이어그램에서 Cloud Load Balancing 및 Gateway 리소스는 메시에 없는 클라이언트에서 메시로 들어가는 트래픽에 대한 인그레스 게이트웨이를 제공합니다. 메시 관리자는 Gateway 리소스를 구성 및 관리하고 서비스 소유자는 자신의 고유 서비스 및 트래픽 라우팅을 구성하고 관리합니다.
셀프 서비스 모델로 안정성 향상
이전 Traffic Director API의 URL 맵은 메시의 서비스 간 통신 및 관리형 부하 분산기를 통해 메시에 들어오는 외부 트래픽의 라우팅을 정의합니다. 여러 팀이 단일 URL 맵 리소스를 수정 중일 수 있으며, 이로 인해 잠재적인 안정성 문제가 발생하고 서비스별 구성을 서비스 소유자에게 위임하는 프로세스가 복잡해집니다.
서비스 라우팅 API에는 독립 서비스 소유자가 구성하고 소유할 수 있는 프로토콜별, 라우팅별 리소스가 도입되었습니다. 이 방식의 장점은 다음과 같습니다.
- 이제 서비스 소유자가 자신이 소유하는 서비스에 대한 정책 및 트래픽 관리 구성 방식을 자율적으로 관리할 수 있습니다.
- 하나의
Route리소스를 업데이트해도 메시의 다른Route리소스에는 영향을 주지 않습니다. 또한 서비스 소유자는 훨씬 더 작은 구성을 관리하므로 업데이트 프로세스도 오류가 적게 발생합니다. - 대상 서비스 또는 호스트 이름을 담당하는 서비스 소유자가 각
Route리소스를 소유합니다. - 서비스 소유자는 중앙 집중식 URL 맵 리소스를 사용하여 라우팅을 업데이트하기 위해 메시 관리자에게 의존할 필요가 없습니다.
관련 있는 항목만 구성
서비스 라우팅 API는 전달 규칙, 대상 프록시, URL 맵을 대체합니다. 사이드카 프록시 및 프록시리스 gRPC와 서비스 간 통신을 위해 Virtual Private Cloud(VPC) 네트워크에서 가상 IP 주소를 더 이상 할당할 필요가 없습니다.
공유 VPC 환경의 여러 프로젝트에 걸쳐 서비스 메시 사용 설정
서비스 라우팅 API 모델에서는 서비스 소유자가 공유 VPC 및 기타 연결 방법을 사용하여 공유 메시 인프라에 참여하면서도 자신의 서비스를 독립적으로 제어할 수 있습니다. 예를 들어 서비스 소유자가 자신의 프로젝트에 Route 리소스를 정의할 수 있습니다. 플랫폼 관리자는 중앙에서 관리되는 호스트 프로젝트에 Mesh를 정의한 후 서비스 소유자에게 Route 리소스를 공유 Mesh 또는 Gateway에 연결할 수 있는 IAM 권한을 부여할 수 있습니다. 다음 다이어그램은 공유 VPC가 포함된 예시를 보여줍니다.
또한 서비스 라우팅 API를 사용하면 VPC 네트워크 피어링을 통해 다른 네트워크에 서비스 메시 클라이언트를 연결할 수 있습니다.
서버 이름 표시기 기준 트래픽 라우팅
TLSRoute 리소스를 사용하면 TLS 핸드셰이크의 서버 이름 표시(SNI)를 기준으로 TLS로 암호화된 트래픽을 라우팅할 수 있습니다. TLSRoute 리소스에 SNI 일치를 구성하여 TLS 트래픽이 적절한 백엔드 서비스로 라우팅되도록 구성할 수 있습니다. 이러한 배포에서 프록시는 트래픽만 라우팅하고 대상 백엔드 인스턴스에서 TLS 세션이 종료됩니다.
TLSRoute 리소스는 사이드카 프록시 또는 게이트웨이로 배포되는 Envoy 프록시에만 지원됩니다.
Mesh 리소스에 연결된 TLSRoute 리소스
다음 다이어그램에 표시된 배포는 SNI에 service1 값이 포함된 서비스 메시 트래픽을 백엔드 서비스 service1로 라우팅합니다. 또한 SNI 확장 프로그램에 service2 값이 포함된 서비스 메시 트래픽이 백엔드 서비스 service2로 라우팅됩니다. SNI 확장 프로그램 값과 백엔드 서비스 이름은 서로 독립적입니다.
TLSRoute 리소스 및 Mesh 리소스(확대하려면 클릭)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는 지원되지 않습니다.
TLSRoute 리소스 및 Gateway 리소스(확대하려면 클릭)기본 제공되는 gRPC 지원
동일한 경로로 번역하고 경로 일치자를 사용하는 대신 메서드별 일치와 같은 기본 제공되는 gRPC 속성을 사용하여 프록시리스 gRPC 클라이언트를 구성할 수 있습니다.
TCP 트래픽의 트래픽 분할
이제 여러 백엔드 서비스 간에 TCP 트래픽에 대해 가중치 기반 트래픽 분할을 구현할 수 있습니다. 서비스를 업데이트할 때 카나리아(블루-그린) 출시와 같은 패턴을 구성할 수 있습니다. 또한 트래픽 분할을 통해 다운타임 없이 제어된 방식으로 트래픽을 마이그레이션할 수 있습니다.
트래픽 가로채기
서비스 라우팅 API Mesh 및 Gateway 리소스를 사용하면 모든 트래픽이 자동으로 차단됩니다. 자세한 내용은 자동 Envoy 배포를 사용한 Compute Engine VM 설정 옵션을 참조하세요.
아키텍처 및 리소스
이 섹션에서는 서비스 라우팅 API 모델과 해당 리소스를 설명하고 서비스 라우팅 API 리소스가 함께 작동하는 방식을 설명합니다.
Mesh 리소스
Mesh 리소스는 서비스 메시의 인스턴스를 나타냅니다. 이를 사용해서 프로젝트에 논리적 서비스 메시를 만듭니다. 각 Mesh 리소스는 프로젝트에서 이름이 고유해야 합니다. Mesh 리소스를 만든 후에는 이름을 수정할 수 없습니다.
Mesh Envoy 사이드카 및 프록시리스 gRPC 배포를 사용하는 API 리소스(확대하려면 클릭)Mesh 리소스는 Route 리소스에서 참조되어 메시의 일부인 서비스의 경로를 추가합니다.
Envoy 프록시 및 프록시리스 gRPC 클라이언트는 Mesh 리소스 이름으로 식별된 서비스 메시에 조인하여 Traffic Director에서 구성을 수신합니다. Mesh 이름은 부트스트랩 매개변수로 Compute Engine의 자동 Envoy 배포 및 GKE의 자동 Envoy 인젝터에서 지원됩니다.
Mesh 리소스는 다음 데이터 영역 배포를 지원합니다.
- 사이드카 프록시로 애플리케이션과 함께 실행되는 Envoy
- 프록시리스 gRPC 클라이언트
- Envoy 사이드카 및 프록시리스 gRPC 클라이언트 혼합
Route 리소스
Route 리소스는 서비스에 라우팅을 설정하기 위해 사용됩니다. Route API 리소스에는 네 가지 유형이 있습니다. 이러한 리소스는 트래픽을 백엔드 서비스로 라우팅하기 위해 사용되는 프로토콜을 정의합니다.
API에는 Route API가 포함되어 있지 않습니다. 구성 가능한 API 리소스는 HTTPRoute, GRPCRoute, TCPRoute, TLSRoute뿐입니다.
Route 리소스는 하나 이상의 Mesh 및 Gateway 리소스를 참조하여 해당 Mesh 또는 Gateway 구성의 일부인 경로를 추가합니다. Route 리소스는 Gateway 및 Mesh 리소스를 참조할 수 있습니다.
Route 리소스는 또한 하나 이상의 백엔드 서비스 리소스를 참조합니다. 이 서비스는 기존 구성 흐름에 백엔드 서비스 API를 사용하여 구성됩니다. 서비스 라우팅 API는 백엔드 서비스 및 상태 점검이 Traffic Director 구성에 정의되는 방식을 변경하지 않습니다.
이렇게 하려면 하나 이상의 MIG 또는 NEG 백엔드를 가리키는 백엔드 서비스 리소스를 만듭니다.
다음 다이어그램은 Mesh, Gateway, Route 리소스와 백엔드 서비스 리소스 및 해당 백엔드 사이의 관계를 보여줍니다.
Route API 리소스(확대하려면 클릭)Route 리소스에서 라우팅, 헤더 수정, 시간 제한, 가중치 기반 트래픽 분할 등의 다른 트래픽 관리 기능을 정의합니다.
예를 들어 다음 다이어그램에서 HTTPRoute 리소스는 두 백엔드 서비스 간의 70%/30% 트래픽 분할을 정의합니다.
TLSRoute 리소스
TLSRoute 리소스를 사용하여 SNI 호스트 이름 및 애플리케이션 레이어 프로토콜 협상(ALPN) 이름을 기준으로 TLS 트래픽을 백엔드 서비스로 라우팅합니다. TLSRoute 구성은 Envoy 프록시가 TLS 트래픽을 종료하지 않는 TLS 패스스루를 의미합니다.
TLSRoute 리소스는 하나 이상의 Mesh 및 Gateway 리소스를 참조하여 해당 메시 또는 게이트웨이 구성의 일부인 경로를 추가합니다.
TLSRoute 리소스는 또한 하나 이상의 백엔드 서비스 리소스를 참조합니다.
이 서비스는 기존 구성 흐름 및 API를 사용하여 백엔드 서비스 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 구성은 무엇인가요?
Gateway 리소스 인스턴스는 해당 포트에서 수신된 트래픽에 대한 포트 및 구성을 나타냅니다. Gateway API 리소스에는 두 개 이상의 Gateway 리소스 구성을 논리적으로 그룹화하고 병합하는 데 사용되는 scope 매개변수가 있습니다.
예를 들어 Gateway 프록시가 HTTP 및 HTTPS 트래픽을 수신하기 위해 각각 포트 80 및 443에서 리슨하도록 하려면 2개의 Gateway 리소스를 만듭니다.
HTTP 트래픽에 대해 포트 80으로 Gateway 리소스를 하나 구성하고 HTTPS 트래픽에 대해서도 포트 443으로 다른 리소스를 하나 구성합니다. 각 리소스의 scope 필드에 동일한 값을 지정합니다.
Traffic Director는 범위가 동일한 모든 게이트웨이에 대해 개별 구성을 동적으로 병합합니다. 또한 데이터 영역 측에서 인그레스 게이트웨이 모드로 실행되는 Envoy 프록시는 Gateway 구성을 수신하기 위해 Traffic Director에 동일한 범위 매개변수를 제공해야 합니다. Gateway 리소스를 만들 때 범위를 지정하고 프록시의 부트스트랩 매개변수와 동일한 범위를 지정합니다.
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 환경에서 지원되는 토폴로지
Traffic Director는 다른 프로젝트에 정의된 Route 리소스를 중앙화된 관리 프로젝트에 정의된 Mesh 또는 Gateway 리소스에 추가하도록 지원합니다. 승인된 서비스 소유자는 자신의 서비스 라우팅 구성을 Mesh 또는 Gateway에 직접 추가할 수 있습니다.
Mesh 및 Route 리소스 사이에서 프로젝트 교차 참조(확대하려면 클릭)일반적인 교차 프로젝트 시나리오에서는 프로젝트(호스트 프로젝트 또는 중앙에서 관리되는 관리 프로젝트)를 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.* 권한이 있습니다.
이전에 설명된 권한을 커스텀 역할에 추가해야 할 수도 있습니다.
서비스 라우팅과 이전 API 모델 비교
이 섹션에서는 이전 API 모델과 서비스 라우팅 Traffic Director API 모델을 주제별로 비교합니다.
| 이전 API | 서비스 라우팅 API | |
|---|---|---|
| API 리소스 | 전달 규칙, 대상 프록시, URL 맵, 백엔드 서비스 | 게이트웨이, 메시, 경로, 백엔드 서비스 |
| 서비스의 IP 주소 및 포트 번호 | 서비스의 IP 주소 및 포트 번호를 프로비저닝하고 모든 사용 사례에 대해 IP:Port 쌍과 일치해야 하는 전달 규칙을 구성해야 합니다. IP 주소를 호스트 이름에 수동으로 매핑하거나 포괄 IP 주소 0.0.0.0을 사용해야 합니다. |
Mesh 또는 Gateway 사용 사례의 IP 주소는 구성할 필요가 없습니다. Gateway에는 포트 번호 구성이 필요합니다.
|
| 서비스 메시 범위 | Traffic Director는 메시 범위가 VPC 네트워크가 되도록 VPC 네트워크에 연결된 모든 프록시를 프로그래밍합니다. | Traffic Director는 VPC 네트워크를 기준으로 프록시를 프로그래밍하지 않습니다. East-West 서비스 간 통신을 위해 Envoy 및 프록시리스 gRPC 클라이언트는 Mesh 리소스 이름을 사용합니다.North-South 인그레스 게이트웨이 사용 사례의 경우 여러 Gateways가 병합 구성과 함께 그룹화되도록 허용하는 Gateway API의 scope 매개변수입니다. |
| 공유 VPC 환경의 교차 프로젝트 참조 | 프로젝트 간 참조는 지원되지 않습니다. 모든 API 리소스는 동일한 프로젝트에 구성되어야 합니다. | 중앙에서 관리되는 프로젝트(호스트 프로젝트)에 Mesh 또는 Gateway 리소스를 만들 수 있고 서비스 소유자가 공유 VPC 환경의 서비스 프로젝트에 Route 리소스를 만들 수 있습니다. Route 리소스는 프로젝트 간에 배치된 Mesh 또는 Gateway를 참조할 수 있습니다. |
| 가로채기 포트 | TRAFFICDIRECTOR_INTERCEPTION_PORT 부트스트랩 매개변수는 Traffic Director에 연결하는 모든 Envoy에 지정되어야 합니다.Compute Engine API에 자동 Envoy 배포를 사용하고 GKE에 자동 사이드카 삽입을 사용하면 이 값이 15001로 기본 설정됩니다. |
가로채기 포트는 Mesh 리소스에 구성되며, 해당 Mesh에 대한 구성이 필요한 모든 Envoy에 자동으로 적용됩니다.지정되지 않은 경우 계속 15001이 기본값으로 사용됩니다. |
Compute Engine 및 GKE에서 Envoy 및 gRPC 클라이언트 부트스트래핑
| 이전 API | 서비스 라우팅 API | |
|---|---|---|
| Compute Engine에서 자동 Envoy 배포 사용 | VM 템플릿을 만들 때는 Envoy 프록시를 필요한 속성으로 동적으로 부트스트래핑하는 명령줄 매개변수인 --service-proxy=enabled를 지정합니다. |
VM 템플릿을 만들 때는 추가 매개변수를 지정합니다. 예를 들면 --service-proxy=enabled, mesh=[MESH_NAME](메시), --service-proxy=enabled, scope=[SCOPE_NAME](게이트웨이)입니다. 다른 필수 속성은 동적으로 부트스트래핑됩니다. 게이트웨이로 작동하는 Envoy의 경우 serving_ports가 --service-proxy 명령줄 인수로 지정되지 않도록 해야 합니다. 자세한 내용은 자동 Envoy 배포를 사용한 Compute Engine VM 설정 옵션을 참조하세요. |
| GKE에서 자동 사이드카 삽입 사용 | 사이드카 인젝터의 configMap에 필요한 부트스트랩 속성을 지정합니다. |
configMap에 지정된 새 속성과 동일한 워크플로 |
| GKE에서 수동 사이드카 삽입 사용 | 여기에서 설명한 대로 애플리케이션 포드에는 필요한 속성으로 Envoy 사이드카 컨테이너가 부트스트랩되어야 합니다. | 새 속성을 사용하는 동일한 워크플로 |
| Compute Engine 또는 GKE를 사용하여 gRPC 클라이언트 배포 | 클라이언트 애플리케이션은 필요한 속성으로 부트스트래핑되어야 합니다. | 새 속성을 사용하는 동일한 워크플로 |
메시 및 게이트웨이 보안 사용 사례 구성
| 이전 API | 서비스 라우팅 API | |
|---|---|---|
| GKE의 서비스 간 mTLS | Envoy 사이드카 기반 배포의 경우 여기의 안내를 따르세요. 프록시리스 gRPC 기반 배포의 경우 여기의 안내를 따르세요. |
동일한 안내가 적용됩니다. 클라이언트 TLS 정책 및 서버 TLS 정책을 각각 백엔드 서비스 및 엔드포인트 정책 리소스에 적용해야 합니다. 이러한 두 API가 서비스 라우팅 API에 영향을 주지 않기 때문에 구성 흐름이 이전과 동일하게 유지됩니다. |
| 중간 프록시(인그레스 또는 이그레스 게이트웨이) 배포 보안 | 여기의 도움말을 따르세요. 서버 TLS 정책 및 승인 정책 리소스는 대상 HTTPS 프록시 리소스에 연결됩니다. |
서버 TLS 정책 및 승인 정책 리소스를 게이트웨이에 연결합니다. |
고려사항 및 제한사항
- Google Cloud 콘솔은 서비스 라우팅 API를 지원하지 않습니다.
- xDS API 버전 3 이상을 사용하세요.
- 최소 Envoy 버전 1.24.9
- 최소 gRPC 부트스트랩 생성기 버전 v0.14.0.
TLSRoute리소스는 사이드카 프록시 또는 게이트웨이로 배포되는 Envoy 프록시에만 지원됩니다.- 자동 Envoy 배포를 사용하는 Compute Engine VM과 자동 Envoy 삽입을 사용하는 GKE 포드만 지원됩니다. 서비스 라우팅 API에서 수동 배포를 사용할 수 없습니다.
- Terraform은 이 출시 버전에서 지원되지 않습니다.
- 서비스 라우팅 API는 이전 API와 하위 호환되지 않습니다.
TCPRoute리소스가Mesh리소스에 연결되면 TCP 트래픽을 일치시키는 데 사용되는 포트는 이TCPRoute에서 설명하는 트래픽을 처리하는 것 외에는 사용할 수 없습니다.- 예를 들어 배포에 포트 "8000"과 일치하는
TCPRoute리소스 및 HttpRoute 리소스가 포함될 수 있습니다. 둘 다 동일한Mesh리소스에 연결되어 있으면 기본 IP 주소가 다르더라도HTTPRoute리소스로 라우팅되는 트래픽이 포트 8000을 사용할 수 없습니다. 이렇나 제한사항은 포트 일치 라우팅에 먼저 우선권을 부여하는 Envoy 프록시 구현으로부터 비롯됩니다.
- 예를 들어 배포에 포트 "8000"과 일치하는
Gateway리소스는 관리형 부하 분산기를 프로비저닝하지 않으며 Envoy 서비스를 동적으로 만들지 않습니다.- 인그레스 게이트웨이로 작동하는 자동으로 배포된 Envoy에는
serving_ports인수가--service-proxy플래그로 지정되지 않아야 합니다. - 자동으로 배포된 Envoy는 VM 프로젝트와 다른 프로젝트 번호 제공을 지원하지 않습니다.
다음 단계
- 서비스 라우팅 API에서 사용 가능한 구성에 대한 자세한 내용은 Traffic Director 서비스 라우팅 설정 가이드를 참조하세요.
- 서비스 라우팅 API에 대한 자세한 내용은 네트워크 서비스 API 문서를 참조하세요.