Envoy를 사용하여 고급 트래픽 관리 구성
이 구성은 미리보기 고객에게도 지원되지만 새로운 Cloud Service Mesh 사용자에게 권장되지 않습니다. 자세한 내용은 Cloud Service Mesh 서비스 라우팅 개요를 참조하세요.
이 문서에서는 Envoy를 사용하는 Cloud Service Mesh 배포에 대해 고급 트래픽 관리를 구성하는 방법을 설명합니다.
시작하기 전에
고급 트래픽 관리를 구성하기 전에 Envoy로 Cloud Service Mesh 설정 준비의 안내를 따릅니다. 여기에는 Cloud Service Mesh 및 모든 가상 머신(VM) 호스트 또는 필요한 Google Kubernetes Engine(GKE) 클러스터를 구성하는 방법 등이 나와 있습니다. 필요한 Google Cloud 리소스를 만듭니다.
고급 트래픽 관리 기능 사용 가능 여부는 선택한 요청 프로토콜에 따라 다릅니다. 이 프로토콜은 대상 HTTP 또는 HTTPS 프록시, 대상 gRPC 프록시 또는 대상 TCP 프록시 리소스를 사용하여 라우팅을 구성할 때 구성됩니다.
- 대상 HTTP 프록시와 대상 HTTPS 프록시를 사용하면 이 문서에 설명된 모든 기능을 사용할 수 있습니다.
- 대상 gRPC 프록시를 사용하면 일부 기능을 사용할 수 있습니다.
- 대상 TCP 프록시를 사용하면 고급 트래픽 관리 기능을 사용할 수 없습니다.
자세한 내용은 Cloud Service Mesh 기능 및 고급 트래픽 관리를 참조하세요. 엔드 투 엔드 설정 가이드는 프록시리스 gRPC 서비스로 고급 트래픽 관리 구성을 참조하세요.
트래픽 분할 설정
여기에서는 다음과 같이 설정되었다고 가정합니다.
- Cloud Service Mesh 배포에는
review-url-map이라는 URL 맵이 포함됩니다. - URL 맵은 모든 트래픽을 기본 백엔드 서비스로 사용되는
review1이라는 하나의 백엔드 서비스로 보냅니다. - 트래픽의 5%를 새 버전의 서비스로 라우팅하려고 합니다. 이 서비스는 백엔드 서비스
review2에 연결된 네트워크 엔드포인트 그룹(NEG)의 백엔드 VM 또는 엔드포인트에서 실행 중입니다. - 호스트 규칙도, 경로 일치자도 사용되지 않습니다.
이전에 URL 맵에서 참조하지 않은 새 서비스로 트래픽을 분할하는 경우 먼저 weightedBackendServices에 새 서비스를 추가하고 가중치 0을 지정합니다. 그런 다음 서비스에 할당된 가중치를 점차적으로 늘립니다.
트래픽 분할을 설정하려면 다음 단계를 따르세요.
콘솔
Google Cloud 콘솔에서 Cloud Service Mesh 페이지로 이동합니다.
라우팅 규칙 맵을 클릭합니다.
라우팅 규칙 맵 만들기를 클릭합니다.
라우팅 규칙 맵 만들기 페이지에서 이름을 입력합니다.
프로토콜 메뉴에서 HTTP를 선택합니다.
기존 전달 규칙을 선택합니다.
라우팅 규칙에서 고급 호스트, 경로 및 경로 규칙을 선택합니다.
호스트 및 경로 일치자에서 호스트 및 경로 일치자 추가를 클릭합니다. 그러면 트래픽을 분할하도록 구성할 수 있는 새로운 경로 일치자가 추가됩니다.
경로 일치자 필드에 다음 설정을 추가합니다.
- defaultService: global/backendServices/review1 name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: '' routeAction: weightedBackendServices: - backendService: global/backendServices/review1 weight: 95 - backendService: global/backendServices/review2 weight: 5완료를 클릭합니다.
저장을 클릭합니다.
새 버전에 만족하면 두 서비스의 가중치를 점차적으로 조정하고 최종적으로 모든 트래픽을 review2에 전송할 수 있습니다.
gcloud
gcloud export명령어를 사용하여 URL 맵 구성을 가져옵니다.gcloud compute url-maps export review-url-map \ --destination=review-url-map-config.yamlreview-url-map-config.yaml파일에 다음 섹션을 추가합니다.hostRules: - description: '' hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: global/backendServices/review1 name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: '' routeAction: weightedBackendServices: - backendService: global/backendServices/review1 weight: 95 - backendService: global/backendServices/review2 weight: 5URL 맵을 업데이트합니다.
gcloud compute url-maps import review-url-map \ --source=review-url-map-config.yaml
새 버전에 만족하면 두 서비스의 가중치를 점차적으로 조정하고 최종적으로 모든 트래픽을 review2에 전송할 수 있습니다.
부분 출시 설정
카나리아라고도 부르는 부분 배포 프로세스를 사용하여 소수의 서버에 새 소프트웨어 버전을 출시한 후에 새 버전을 나머지 프로덕션 서버에 출시합니다.
부분 출시에는 weightedBackendServices가 사용됩니다. 부분 출시를 사용 설정하려면 백엔드 서비스를 테스트 또는 카나리아 서비스로 지정하고 2 또는 5와 같은 낮은 가중치를 지정합니다. 이러한 서버에만 새 소프트웨어 버전을 배포합니다. 새 버전에 문제가 없으면 나머지 서비스에 배포합니다.
- 부분 출시를 사용 설정하려면 다음 YAML 코드 샘플을 사용합니다.
pathMatchers:
- defaultService: DEFAULT_SERVICE_URL
name: matcher1
routeRules:
- matchRules:
- prefixMatch: '/'
routeAction:
weightedBackendServices:
- backendService: BACKEND_SERVICE_PARTIAL_URL
weight: 2
- backendService: BACKEND_SERVICE_URL
weight: 98
DEFAULT_SERVICE_URL은 서비스의 기본 URL입니다.BACKEND_SERVICE_PARTIAL_URL은 트래픽의 2%를 수신하는 백엔드 서비스의 URL입니다.BACKEND_SERVICE_URL은 트래픽의 98%를 수신하는 백엔드 서비스의 URL입니다.
블루-그린 배포 설정
블루-그린 배포는 프로덕션 트래픽을 서비스의 새 출시 버전 또는 서비스의 이전 출시 롤백으로 전환하는 데 필요한 시간을 줄여주는 출시 모델입니다. 이러한 배포는 프로덕션에서 두 버전의 서비스를 모두 제공하고 트래픽을 다른 위치로 이동시킵니다.
블루-그린 배포에는 weightedBackendServices가 사용됩니다. 다음 YAML 예시에서 SERVICE_BLUE_URL 백엔드는 현재 프로덕션 출시 버전을 사용하여 완전히 배포되고 SERVICE_GREEN_URL에 대한 백엔드는 새 출시 버전을 사용하여 완전히 배포됩니다. 예시 구성에서 GREEN 배포는 프로덕션 트래픽을 100% 수신합니다. 문제가 발견되면 두 배포의 가중치를 반대로 적용해서 결함이 있는 GREEN 출시 버전을 효과적으로 되돌리고 정상 상태의 BLUE 출시 버전을 복원할 수 있습니다. 문제와 상관없이 두 버전 모두 트래픽을 수신할 수 있어 트래픽을 빠르게 옮길 수 있습니다.
- 블루-그린 배포를 사용 설정하려면 다음 YAML 코드 샘플을 사용합니다.
pathMatchers:
- defaultService: DEFAULT_SERVICE_URL
name: matcher1
routeRules:
- matchRules:
- prefixMatch: '/'
routeAction:
weightedBackendServices:
- backendService: BACKEND_SERVICE_BLUE_URL
weight: 0
- backendService: BACKEND_SERVICE_GREEN_URL
weight: 100
DEFAULT_SERVICE_URL은 서비스의 기본 URL입니다.BACKEND_SERVICE_BLUE_URL은 트래픽을 수신하지 않는 백엔드 서비스의 URL입니다.BACKEND_SERVICE_GREEN_URL은 트래픽의 100%를 수신하는 백엔드 서비스의 URL입니다.
트래픽 미러링 설정
디버깅 또는 새로운 서비스 테스트를 목적으로 두 개의 서로 다른 백엔드 서비스로 트래픽을 전달하려고 할 때 트래픽 미러링을 사용합니다.
다음 예시에서는 모든 요청이 SERVICE_URL 및 MIRROR_SERVICE_URL로 전송됩니다. SERVICE_URL의 응답만 클라이언트로 다시 전송됩니다. MIRROR_SERVICE_URL은 클라이언트에 영향을 주지 않습니다.
트래픽 미러링을 설정하려면 다음 단계를 따르세요.
콘솔
Google Cloud 콘솔에서 Cloud Service Mesh 페이지로 이동합니다.
라우팅 규칙 맵을 클릭합니다.
라우팅 규칙 맵 만들기를 클릭합니다.
라우팅 규칙 맵 만들기 페이지에서 이름을 입력합니다.
프로토콜 목록에서 HTTP를 선택합니다.
기존 전달 규칙을 선택합니다.
라우팅 규칙에서 고급 호스트, 경로 및 경로 규칙을 선택합니다.
호스트 및 경로 일치자에서 호스트 및 경로 일치자 추가를 클릭합니다. 그러면 트래픽을 미러링하도록 구성할 수 있는 새로운 경로 일치자가 추가됩니다.
경로 일치자 필드에 다음 설정을 추가합니다.
- defaultService: DEFAULT_SERVICE_URL name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: BACKEND_SERVICE_URL weight: 100 requestMirrorPolicy: backendService: BACKEND_SERVICE_MIRROR_URLDEFAULT_SERVICE_URL은 서비스의 기본 URL입니다.BACKEND_SERVICE_URL은 미러링된 백엔드의 URL입니다.BACKEND_SERVICE_MIRROR_URL은 미러링하려는 백엔드 서비스의 URL입니다.
완료를 클릭합니다.
저장을 클릭합니다.
gcloud
gcloud export명령어를 사용하여 URL 맵 구성을 가져옵니다.gcloud compute url-maps export review-url-map \ --destination=review-url-map-config.yamlreview-url-map-config.yaml파일에 다음 섹션을 추가합니다.hostRules: - description: '' hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: DEFAULT_SERVICE_URL name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: BACKEND_SERVICE_URL weight: 100 requestMirrorPolicy: backendService: BACKEND_SERVICE_MIRROR_URLDEFAULT_SERVICE_URL은 서비스의 기본 URL입니다.BACKEND_SERVICE_URL은 미러링된 백엔드의 URL입니다.BACKEND_SERVICE_MIRROR_URL은 미러링하려는 백엔드 서비스의 URL입니다.
URL 맵을 업데이트합니다.
gcloud compute url-maps import review-url-map \ --source=review-url-map-config.yaml
회로 차단 설정
회로 차단을 통해 클라이언트 요청으로 인해 백엔드에 과부하가 발생하지 않도록 장애 임곗값을 설정할 수 있습니다. 요청이 설정한 한도에 도달하면 클라이언트가 새 연결 허용 또는 추가 요청 전송을 중지하여 백엔드를 복구할 시간을 줍니다.
따라서 회로 차단은 백엔드에 과부하를 발생시키지 않고 클라이언트에 오류를 반환하여 연쇄적 장애를 방지합니다. 이렇게 하면 일부 트래픽을 제공하면서도 자동 확장을 통해 용량을 늘려 트래픽 급증을 처리하는 것과 같은 과부하 상황 관리를 위한 시간을 확보할 수 있습니다.
다음 예시에서는 회로 차단기를 다음과 같이 설정합니다.
- 연결당 최대 요청 수: 100
- 최대 연결 수: 1,000
- 대기 중 최대 요청 수: 200
- 최대 요청 수: 1,000
- 최대 재시도 수: 3
회로 차단을 설정하려면 다음 단계를 따르세요.
콘솔
Google Cloud 콘솔에서 Cloud Service Mesh 페이지로 이동합니다.
업데이트할 백엔드 서비스의 이름을 클릭합니다.
수정을 클릭합니다.
고급 구성을 클릭합니다.
회로 차단기에서 사용 설정 체크박스를 선택합니다.
수정을 클릭합니다.
- 연결당 최대 요청 수에
100을 입력합니다. - 최대 연결 수에
1000을 입력합니다. - 최대 대기 요청 수에
200을 입력합니다. - 최대 요청 수에
1000을 입력합니다. - 최대 재시도 수에
3을 입력합니다.
- 연결당 최대 요청 수에
저장을 클릭한 후 다시 저장을 클릭합니다.
gcloud
gcloud export명령어를 실행하여 백엔드 서비스 구성을 내보냅니다.BACKEND_SERVICE_NAME을 백엔드 서비스 이름으로 바꿉니다.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --globalBACKEND_SERVICE_NAME.yaml 파일을 다음과 같이 업데이트합니다.affinityCookieTtlSec: 0 backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group:https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroups/INSTANCE_GROUP_NAME maxUtilization: 0.8 circuitBreakers: maxConnections: 1000 maxPendingRequests: 200 maxRequests: 1000 maxRequestsPerConnection: 100 maxRetries: 3 connectionDraining: drainingTimeoutSec: 300 healthChecks: - https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME loadBalancingScheme: INTERNAL_SELF_MANAGED localityLbPolicy: ROUND_ROBIN name: BACKEND_SERVICE_NAME port: 80 portName: http protocol: HTTP sessionAffinity: NONE timeoutSec: 30백엔드 서비스 구성 파일을 다음과 같이 업데이트합니다.
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
HTTP_COOKIE를 기준으로 세션 어피니티 설정
고급 트래픽 관리를 사용하면 제공된 쿠키를 기반으로 세션 어피니티를 구성할 수 있습니다.
HTTP_COOKIE를 사용하여 세션 어피니티를 설정하려면 다음 단계를 수행합니다.
콘솔
Google Cloud 콘솔에서 Cloud Service Mesh 페이지로 이동합니다.
업데이트할 백엔드 서비스의 이름을 클릭합니다.
수정을 클릭합니다.
고급 구성을 클릭합니다.
세션 어피니티에서 HTTP 쿠키를 선택합니다.
지역 부하 분산 정책에서 링 해시를 선택합니다.
- HTTP 쿠키 이름 필드에
http_cookie를 입력합니다. - HTTP 쿠키 경로 필드에
/cookie_path를 입력합니다. - HTTP 쿠키 TTL 필드에
100을 입력합니다. - 최소 링 크기 필드에
10000을 입력합니다.
- HTTP 쿠키 이름 필드에
저장을 클릭합니다.
gcloud
gcloud export명령어를 실행하여 백엔드 서비스 구성을 내보냅니다.BACKEND_SERVICE_NAME을 백엔드 서비스 이름으로 바꿉니다.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global다음과 같이
YAML파일을 업데이트합니다.sessionAffinity: 'HTTP_COOKIE' localityLbPolicy: 'RING_HASH' consistentHash: httpCookie: name: 'http_cookie' path: '/cookie_path' ttl: seconds: 100 nanos: 30 minimumRingSize: 10000백엔드 서비스 구성 파일을 다음과 같이 가져옵니다.
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
이상점 감지 설정
이상점 감지는 부하 분산 풀에서의 비정상 호스트 제거를 제어합니다. Cloud Service Mesh는 NEG에서 비정상 백엔드 VM 또는 엔드포인트를 제거하는 기준과 백엔드 또는 엔드포인트가 트래픽을 다시 수신할 수 있는 정상 상태의 기준을 정의하는 정책 집합을 사용하여 이를 수행합니다.
다음 예시에서 백엔드 서비스에는 백엔드로 인스턴스 그룹 1개가 있습니다. 이상점 감지를 설정하면 이상점 감지 분석이 1초마다 실행하도록 지정됩니다. 엔드포인트가 5번 연속으로 5xx 오류를 반환하면 처음 30초 동안 부하 분산 대상에서 제거됩니다. 동일한 엔드포인트의 실제 제거 시간은 제거된 횟수에 30초를 곱한 만큼입니다.
백엔드 서비스 리소스에 이상점 감지를 설정하려면 다음 단계를 따르세요.
콘솔
Google Cloud 콘솔에서 Cloud Service Mesh 페이지로 이동합니다.
서비스 이름을 클릭합니다.
수정을 클릭합니다.
고급 구성을 클릭합니다.
이상점 감지 체크박스를 선택합니다.
수정을 클릭합니다.
- 연속 오류를
5로 설정합니다. - 간격을
1000밀리초로 설정합니다. - 기본 제거 시간을
30000밀리초로 설정합니다.
- 연속 오류를
저장을 클릭한 후 다시 저장을 클릭합니다.
gcloud
gcloud export명령어를 실행하여 백엔드 서비스 구성을 내보냅니다.BACKEND_SERVICE_NAME을 백엔드 서비스 이름으로 바꿉니다.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global다음과 같이
YAML파일을 업데이트하고BACKEND_SERVICE_NAME은 백엔드 서비스 이름으로 바꿉니다.name: BACKEND_SERVICE_NAME loadBalancingScheme: INTERNAL_SELF_MANAGED backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: $INSTANCE_GROUP_URL healthChecks: - $HEALTH_CHECK_URL port: 80 portName: http protocol: HTTP outlierDetection: consecutiveErrors: 5, interval: seconds: 1, nanos: 0 baseEjectionTime: seconds: 30, nanos: 0백엔드 서비스 구성 파일을 다음과 같이 가져옵니다.
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
지역 부하 분산 정책 설정
지역 부하 분산 정책을 사용하여 Cloud Service Mesh가 제공하는 지역별 가중치 및 우선순위에 따라 부하 분산 알고리즘을 선택합니다. 예를 들어 정상 엔드포인트 간에 가중치가 적용된 라운드 로빈을 수행하거나 일관된 해싱을 수행할 수 있습니다.
다음 예시에서 백엔드 서비스에는 백엔드로 인스턴스 그룹 1개가 있습니다. 지역 부하 분산 정책이 RING_HASH로 설정됩니다.
지역 부하 분산 정책을 설정하려면 다음 단계를 수행합니다.
콘솔
Google Cloud 콘솔에서 Cloud Service Mesh 페이지로 이동합니다.
서비스 이름을 클릭합니다.
수정을 클릭합니다.
고급 구성을 클릭합니다.
트래픽 정책의 지역 부하 분산 정책 메뉴에서 링 해시를 선택합니다.
저장을 클릭합니다.
gcloud
gcloud export명령어를 실행하여 백엔드 서비스 구성을 내보냅니다.BACKEND_SERVICE_NAME을 백엔드 서비스 이름으로 바꿉니다.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --globalBACKEND_SERVICE_NAME.yaml 파일을 다음과 같이 업데이트합니다.name: shopping-cart-service loadBalancingScheme: INTERNAL_SELF_MANAGED backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: $INSTANCE_GROUP_URL healthChecks: - $HEALTH_CHECK_URL port: 80 portName: http protocol: HTTP localityLbPolicy: RING_HASH
백엔드 서비스 구성 파일을 다음과 같이 가져옵니다.
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
지역 부하 분산 정책의 작동 방식에 대한 자세한 내용은 backendService 리소스에 대한 문서를 참조하세요.
URL 리디렉션 설정
여기에서는 다음과 같이 설정되었다고 가정합니다.
- Cloud Service Mesh 배포에는
review-url-map이라는 URL 맵이 포함됩니다. - URL 맵은 모든 트래픽을 기본 백엔드 서비스로 사용되는
review1이라는 하나의 백엔드 서비스로 보냅니다. - 한 호스트에서 다른 호스트로 트래픽을 리디렉션합니다.
URL 리디렉션을 설정하려면 다음 단계를 수행합니다.
콘솔
Google Cloud 콘솔에서 Cloud Service Mesh 페이지로 이동합니다.
라우팅 규칙 맵을 클릭합니다.
라우팅 규칙 맵 만들기를 클릭합니다.
라우팅 규칙 맵 만들기 페이지에서 이름을 입력합니다.
프로토콜 메뉴에서 HTTP를 선택합니다.
기존 전달 규칙을 선택합니다.
라우팅 규칙에서 고급 호스트, 경로 및 경로 규칙을 선택합니다.
호스트 및 경로 일치자에서 호스트 및 경로 일치자 추가를 클릭합니다. 그러면 트래픽을 리디렉션하는 새로운 경로 일치자가 추가됩니다.
경로 일치자 필드에 다음 설정을 추가합니다.
- defaultService: global/backendServices/review1 name: matcher1 routeRules: - matchRules: - prefixMatch: '' urlRedirect: hostRedirect: '[REDIRECT_HOST]' pathRedirect: '[REDIRECT_URL]' redirectResponseCode: 'FOUND', stripQuery: True완료를 클릭합니다.
저장을 클릭합니다.
gcloud
gcloud export명령어를 사용하여 URL 맵 구성을 가져옵니다.gcloud compute url-maps export review-url-map \ --destination=review-url-map-config.yamlreview-url-map-config.yaml파일에 다음 섹션을 추가합니다.hostRules: - description: '' hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: global/backendServices/review1 name: matcher1 routeRules: - matchRules: - prefixMatch: '' urlRedirect: hostRedirect: '[REDIRECT_HOST]' pathRedirect: '[REDIRECT_URL]' redirectResponseCode: 'FOUND', stripQuery: TrueURL 맵을 업데이트합니다.
gcloud compute url-maps import review-url-map \ --source=review-url-map-config.yaml
URL 재작성으로 트래픽 조정 설정
트래픽 조정을 통해 헤더 값과 같은 요청 속성에 따라 서로 다른 백엔드 서비스로 트래픽을 전달할 수 있습니다. 또한 요청이 백엔드 서비스로 전달되기 전 요청에서 URL 재작성과 같은 작업을 구성할 수 있습니다.
아래의 예시에서는 요청 경로에 /mobile/이라는 프리픽스가 지정되고 요청의 User-Agent에 Android가 포함된 경우 요청이 SERVICE_ANDROID_URL로 전달됩니다. 요청을 백엔드 서비스로 전송하기 전에 URL 프리픽스를 REWRITE_PATH_ANDROID(예: /android/)로 변경할 수 있습니다. 하지만 이 경로에 /mobile/ 프리픽스가 지정되고 iPhone을 포함한 User-Agent가 있으면 트래픽이 SERVICE_IPHONE_URL로 전달되며 URL 프리픽스가 REWRITE_PATH_IPHONE으로 변경됩니다. /mobile/ 프리픽스가 붙는 다른 모든 요청 그리고 Android 또는 iPhone 외의 값이 있는 User-Agent가 있으면 SERVICE_GENERIC_DEVICE_URL로 전달됩니다.
pathMatchers:
- defaultService: [DEFAULT_SERVICE_URL]
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /mobile/
headerMatches:
- headerName: User-Agent
regexMatch: .*Android.*
service: $[SERVICE_ANDROID_URL]
routeAction:
urlRewrite:
pathPrefixRewrite: [REWRITE_PATH_ANDROID]
- matchRules:
- prefixMatch: /mobile/
headerMatches:
- headerName: User-Agent
regexMatch: .*iPhone.*
service: [SERVICE_IPHONE_URL]
routeAction:
urlRewrite:
pathPrefixRewrite: [REWRITE_PATH_IPHONE]
- matchRules:
- prefixMatch: /mobile/
service: [SERVICE_GENERIC_DEVICE_URL]
결함 주입 설정
결함 주입을 사용하면 고정 지연 시간 또는 강제 중단(취소라고 함) 중 하나 또는 모두를 특정 경로에 삽입하여 애플리케이션의 복원력을 테스트할 수 있습니다.
다음 예시에서는 모든 요청이 SERVICE_URL로 전송되고, 요청 중 100%에 10초의 고정된 지연 시간이 추가됩니다. 요청을 전송하는 클라이언트에는 모든 응답이 10초 지연된 것으로 표시됩니다. 또한 Service Unavailable 503 응답을 사용하는 중지 오류가 요청 중 50%에 적용됩니다. 클라이언트에서는 요청 중 50%에 503 응답이 수신되는 것으로 표시됩니다.
이러한 요청은 백엔드 서비스에 도달하지 않습니다.
pathMatchers:
- defaultService: [DEFAULT_SERVICE_URL]
name: matcher1
routeRules:
- matchRules:
- prefixMatch: '/'
routeAction:
weightedBackendServices:
- backendService: [SERVICE_URL]
weight: 100
faultInjectionPolicy:
delay:
fixedDelay:
seconds: 10
nanos: 0
percentage: 100
abort:
httpStatus: 503
percentage: 50
MetadataFilters 일치를 기반으로 구성 필터링 설정
MetadataFilters는 전달 규칙과 HttpRouteRuleMatch로 사용 설정됩니다.
이 기능을 사용하여 특정 제어 규칙 또는 라우팅 규칙을 제어하면 컨트롤 플레인이 노드 메타데이터가 메타데이터 필터 설정과 일치하는 프록시에만 전달 규칙 또는 라우팅 규칙을 전송합니다. MetadataFilters를 지정하지 않는 경우 규칙이 모든 Envoy 프록시로 전송됩니다.
이 기능을 사용하면 단계적 구성 배포를 쉽게 수행할 수 있습니다.
예를 들어 노드 메타데이터에 app: review 및 version: canary가 포함된 Envoy로만 푸시하려는 forwarding-rule1라는 전달 규칙을 만듭니다.
전달 규칙에 MetadataFilters를 추가하려면 다음 단계를 따르세요.
gcloud
gcloud export명령어를 실행하여 전달 규칙 구성을 가져옵니다.gcloud compute forwarding-rules export forwarding-rule1 \ --destination=forwarding-rule1-config.yaml \ --global전달 규칙 삭제:
gcloud compute forwarding-rules delete forwarding-rule1 \ --globalforwarding-rule1-config.yaml파일을 업데이트합니다.다음 예시에서는
MATCH_ALL메타데이터 필터를 만듭니다.metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels: - name: 'app' value: 'review' - name: 'version' value: 'canary'다음 예시에서는
MATCH_ANY메타데이터 필터를 만듭니다.metadataFilters: - filterMatchCriteria: 'MATCH_ANY' filterLabels: - name: 'app' value: 'review' - name: 'version' value: 'production'forwarding-rule1-config.yaml파일에서 모든 출력 전용 필드를 삭제합니다. 자세한 내용은gcloud compute forwarding-rules import에 대한 문서를 참조하세요.gcloud import명령어를 실행하여forwarding-rule1-config.yaml파일을 업데이트합니다.gcloud compute forwarding-rules import forwarding-rule1 \ --source=forwarding-rule1-config.yaml \ --global다음 안내를 사용하여 Envoy를 시작하기 전에 Envoy에 노드 메타데이터를 추가합니다. 문자열 값만 지원됩니다.
a. VM 기반 배포의 경우
bootstrap_template.yaml의metadata섹션에 다음을 추가합니다.app: 'review' version: 'canary'b. Google Kubernetes Engine 기반 또는 Kubernetes 기반 배포의 경우
trafficdirector_istio_sidecar.yaml의env섹션에 다음을 추가합니다.- name: ISTIO_META_app value: 'review' - name: ISTIO_META_version value: 'canary'
메타데이터 필터링 예시
여러 프로젝트가 동일한 공유 VPC 네트워크에 있고 각 서비스 프로젝트의 Cloud Service Mesh 리소스가 동일한 프로젝트의 프록시에 표시되도록 하려면 다음 안내를 따르세요.
공유 VPC 설정은 다음과 같습니다.
- 호스트 프로젝트 이름:
vpc-host-project - 서비스 프로젝트:
project1,project2 project1및project2에서 xDS 호환 프록시를 실행하는 백엔드 인스턴스 또는 엔드포인트가 있는 백엔드 서비스
project1을 격리하도록 Cloud Service Mesh를 구성하려면 다음 단계를 따르세요.
gcloud
다음 메타데이터 필터를 사용하여
project1에 모든 전달 규칙을 만듭니다.metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels - name: 'project_name' value: 'project1' - name: 'version' value: 'production'project1의 인스턴스 또는 엔드포인트에 배포된 프록시를 구성할 때 부트스트랩 파일의 노드 메타데이터 섹션에 다음 메타데이터를 포함합니다.project_name: 'project1' version: 'production'project2에 이미 배포된 프록시가 첫 번째 단계에서 생성된 전달 규칙을 수신하지 않았는지 확인합니다. 이렇게 하려면project2에서 프록시를 실행하는 시스템에서project1의 서비스에 액세스해 보세요. Cloud Service Mesh 구성이 올바르게 작동하는지 확인하는 방법에 대한 자세한 내용은 구성 확인을 참조하세요.
프록시 하위 집합에 대한 새 구성을 모든 프록시에 제공하기 전에 테스트하려면 다음 단계를 따르세요.
gcloud
다음 노드 메타데이터로 테스트에 사용하는 프록시를 시작합니다. 테스트에 사용하지 않는 프록시에는 이 노드 메타데이터를 포함하지 마세요.
version: 'test'테스트할 새 전달 규칙마다 다음 메타데이터 필터를 포함합니다.
metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels: - name: 'version' value: 'test'테스트 프록시로 트래픽을 전송하여 새 구성을 테스트하고 필요한 경우 변경합니다. 새 구성이 올바르게 작동하면 테스트하는 프록시만 새 구성을 수신합니다. 나머지 프록시는 새 구성을 수신하지 않으며 이를 사용할 수 없습니다.
새 구성이 제대로 작동하는지 확인한 후 연결된 메타데이터 필터를 삭제합니다. 이렇게 하면 모든 프록시에서 새 구성을 수신할 수 있습니다.
문제 해결
구성된 라우팅 규칙 및 트래픽 정책에 따라 트래픽이 라우팅되지 않으면 이 정보를 사용하여 문제를 해결합니다.
증상
- 문제가 되는 규칙보다 상위 규칙의 서비스로 전송되는 트래픽이 증가했습니다.
- 특정 라우팅 규칙에 대한
4xx및5xxHTTP 응답이 예기치 않게 증가했습니다.
해결책: 라우팅 규칙은 우선순위 순서대로 해석되므로 각 규칙에 할당된 우선순위를 검토합니다.
라우팅 규칙을 정의할 때 우선순위가 높은(즉, 우선순위 번호가 낮은) 규칙이 후속 라우팅 규칙에 의해 라우팅된 트래픽을 의도하지 않게 라우팅하지 않는지 확인합니다. 다음 예시를 참조하세요.
첫 번째 라우팅 규칙
- 경로 규칙 일치 matchPathPrefix =
/shopping/ - 리디렉션 작업:
service-1백엔드 서비스로 트래픽 전송 - 규칙 우선순위:
4
- 경로 규칙 일치 matchPathPrefix =
두 번째 라우팅 규칙
- 라우팅 규칙 일치 regexMatch =
/shopping/cart/ordering/.* - 리디렉션 작업:
service-2백엔드 서비스로 트래픽 전송 - 규칙 우선순위:
8
- 라우팅 규칙 일치 regexMatch =
이 경우 경로가 /shopping/cart/ordering/cart.html인 요청이 service-1로 라우팅됩니다. 두 번째 규칙이 일치하더라도 첫 번째 규칙에 우선순위가 있으므로 무시됩니다.
서비스 간 트래픽 차단
서비스 A와 서비스 B 간의 트래픽을 차단하려고 하고 배포가 GKE에 있는 경우, 서비스 보안을 설정하고 승인 정책을 사용하여 서비스 간의 트래픽을 차단합니다. 전체 안내는 Cloud Service Mesh 서비스 보안과 Envoy 및 프록시리스 gRPC를 사용한 설정 안내를 참조하세요.
다음 단계
- Cloud Service Mesh 구성 문제를 해결하려면 Envoy 사용 배포 문제 해결을 참조하세요.