v1.21 서비스 메시 문서를 보고 있습니다.

사용 가능한 버전

Cloud Service Mesh
1.22 보관 파일
1.21 보관 파일
1.20 보관 파일
1.19 보관 파일
1.18 보관 파일

서비스 디렉터리 통합 설정

이 가이드에서는 Cloud Service Mesh 배포를 실행 중이고 서비스 디렉터리에 서비스가 하나 이상 등록되었다고 가정합니다. 설정 안내는 Envoy 또는 프록시리스 gRPC를 사용 중인지 여부에 관계없이 적용됩니다.

서비스 디렉터리 및 Cloud Service Mesh를 사용할 때 첫 단계는 서비스를 서비스 디렉터리에 게시하는 것입니다. 일반 개요 정보는 서비스 디렉터리에 서비스 게시 또는 서비스 디렉터리 문서 정보를 참조하세요.

서비스가 서비스 디렉터리에 등록된 다음 Cloud Service Mesh의 API 리소스를 사용하여 서비스 결합을 만듭니다. 서비스 결합을 참조하는 백엔드 서비스가 백엔드 또는 연결된 상태 확인을 가질 수 없으므로, 서비스 디렉터리와 통합에만 사용되는 백엔드 서비스를 만듭니다.

부하 분산 API를 사용하는 Cloud Service Mesh 전달 규칙 및 호스트 규칙 요구사항

서비스 디렉터리에 사용할 Cloud Service Mesh를 구성하고 이전 부하 분산 API를 사용하는 경우 다음 가이드라인을 따르세요.

Cloud Service Mesh 전달 규칙이 0.0.0.0 가상 IP 주소(VIP)를 사용하는지 확인합니다.
비공개 영역이 있으면 URL 맵에서 호스트 규칙이 서비스 디렉터리가 Cloud DNS 비공개 영역에 구성하는 DNS 이름과 일치하는지 확인합니다.

이 안내를 따르지 않으면 애플리케이션의 아웃바운드 요청이 실패할 수 있습니다.

`network-services` API 엔드포인트 설정

백엔드 서비스를 만들고 사용하려면 network-services 아래의 서비스 결합 리소스 가 올바르게 참조되도록 network-services API 엔드포인트가 설정되었는지 확인합니다. 다음 명령어를 사용하여 network-services API 엔드포인트를 설정합니다.

export CLOUDSDK_API_ENDPOINT_OVERRIDES_NETWORKSERVICES="https://networkservices.googleapis.com/"

역할 및 권한 요구사항

Cloud Service Mesh 배포를 만들기 전 다음 권한 및 역할이 있는지 확인합니다.

서비스 결합 권한 및 역할

이 섹션에서는 프로젝트 수준의 소유자, 편집자, 뷰어 권한에 대해 설명하지 않습니다. 리소스 만들기, 읽기, 업데이트, 삭제에 필요한 권한 및 역할에 대해 설명합니다.

작업	권한	역할
서비스 결합을 만듭니다.	`networkservices.serviceBindings.create`	네트워크 관리자
서비스 결합을 가져옵니다.	`networkservices.serviceBindings.get`	네트워크 관리자, 네트워크 뷰어
Google Cloud 프로젝트의 서비스 결합을 나열합니다.	`networkservices.serviceBindings.list`	네트워크 관리자, 네트워크 뷰어
서비스 결합을 업데이트합니다.	`networkservices.serviceBindings.update`	네트워크 관리자
서비스 결합을 삭제합니다.	`networkservices.serviceBindings.delete`	네트워크 관리자

서비스 디렉터리 서비스 권한

서비스 디렉터리 관리자는 서비스 결합을 서비스 디렉터리 서비스에 연결하려고 시도하는 서비스 계정에 servicedirectory.services.bind 권한을 부여해야 합니다. 이렇게 하면 서비스 계정이 서비스 디렉터리 서비스를 사용할 수 있습니다. 즉, 계정이 서비스 결합에서 서비스 디렉터리 서비스를 참조할 수 있습니다.

권한 적용

IAM 권한 검사는 Cloud Service Mesh를 구성할 때 수행됩니다. 서비스 결합을 만들고, 서비스 결합을 특정 서비스 디렉터리 서비스와 연결하는 데 필요한 권한이 있어야 합니다. 올바른 권한이 있으면 서비스 디렉터리 서비스를 알아보고 여기에 트래픽을 전송하도록 메시지 클라이언트를 구성할 수 있습니다.

이러한 검사가 구성 시에 수행되기 때문에 기존 서비스 디렉터리 서비스에서 바인딩 권한을 삭제해도 트래픽 흐름이 중단되지 않습니다. 서비스 바인딩이 설정된 후에는 권한을 삭제해도 메시 클라이언트가 서비스 디렉터리 서비스를 알아보고 여기에 트래픽을 전송하는지 여부에 영향을 주지 않습니다.

메시 클라이언트가 서비스 디렉터리 서비스와 통신하지 않도록 다른 메커니즘을 사용할 수 있습니다.

서비스 디렉터리 서비스에 대해 액세스를 제한합니다. 예를 들어 방화벽 규칙을 사용할 수 있습니다.
서비스 디렉터리 서비스를 삭제합니다.
백엔드 서비스에서 서비스 결합 삭제 등 Cloud Service Mesh 구성을 업데이트합니다.

권장사항

Service Directory는 서비스 디렉터리 API를 사용해서 엔드포인트 등록을 허용하므로, 사용 가능할 때 서비스 디렉터리에 자동으로 등록되는 통합을 사용하는 것이 좋습니다. 이러한 통합에 대한 자세한 내용은 GKE에 대한 서비스 디렉터리 개요 및 서비스 디렉터리 및 Cloud Load Balancing 개요를 참조하세요.
서비스가 서로 다른 리전에 배포되는 경우에도 특정 논리 서비스에 동일한 네임스페이스와 서비스를 사용하는 것이 좋습니다.

서비스 검색에 서비스 디렉터리 사용

다음 다이어그램에서는 구성, 여러 시스템의 상호작용 방법, 요청이 서비스 엔드포인트로 해결되는 방법을 포함하여 이 설정 절차의 종료 상태에 대한 개요를 보여줍니다. 이 예시에서는 서비스 디렉터리에 서비스가 이미 등록되어 있다고 가정합니다.

서비스 검색에 서비스 디렉터리를 사용하기 위한 구성 세부정보입니다. — 서비스 검색에 서비스 디렉터리를 사용하기 위한 구성 세부정보(확대하려면 클릭)

서비스 디렉터리 서비스를 Cloud Service Mesh에 제공하는 가정은 다음 단계로 구성됩니다.

Cloud Service Mesh에서 새 백엔드 서비스를 만들고 백엔드 서비스에 대해 백엔드를 만들지 않습니다.
서비스 디렉터리 서비스에 대해 전역 서비스 결합을 만듭니다.
서비스 디렉터리 서비스를 이 백엔드 서비스에 바인딩합니다. 백엔드 서비스에 추가 필드 및 정책을 설정합니다(선택사항).
클라이언트 요청을 새 백엔드 서비스로 라우팅할 수 있도록 새 라우팅 구성을 만들거나 기존 구성을 업데이트합니다.

서비스 바인딩을 참조하는 백엔드 서비스에 상태 확인을 설정할 수 없습니다. 또한 백엔드 서비스가 백엔드를 포함할 수 없습니다.

통합 만들기

다음 안내에 따라 Cloud Service Mesh를 서비스 디렉터리와 통합합니다.

백엔드 서비스 만들기

다음 안내에 따라 Cloud Service Mesh 배포에서 백엔드 서비스를 만듭니다.

서비스 디렉터리 서비스에 사용할 백엔드 서비스를 만듭니다.

gcloud compute backend-services create td-sd-demo-service \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED

서비스 디렉터리 서비스를 참조하는 서비스 결합을 만듭니다.

gcloud beta network-services service-bindings create my-sd-binding \
 --location global \
 --service-directory-region us-east1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service

백엔드 서비스에 서비스를 바인딩합니다.

gcloud beta compute backend-services update td-sd-demo-service \
 --global \
 --service-bindings my-sd-binding

백엔드 서비스를 만들고 하나 이상의 서비스 디렉터리 서비스를 바인딩한 후 Cloud Service Mesh는 서비스 디렉터리 서비스와 연결된 엔드포인트를 추적합니다. 엔드포인트는 고유한 IP:포트 쌍입니다. 이 서비스를 라우팅하려면 라우팅을 구성해야 합니다.

라우팅 구성

다음 안내에 따라 라우팅 구성을 업데이트합니다.

서비스 라우팅 API

다음 예시에서는 sidecar- mesh라는 Mesh 리소스가 있다고 가정합니다. 호스트 이름이 myservice.example.com로 설정되고 대상이 이전 섹션에서 만든 백엔드 서비스 td-sd-demo-service로 설정된 HTTPRoute 리소스를 만듭니다.

HTTPRoute 사양을 만들고 httproute.yaml이라는 파일에 저장합니다.

name: td-sd-demo-route
hostnames:
‐ myservice.example.com
meshes:
‐ projects/PROJECT_NUMBER/locations/global/meshes/sidecar-mesh
rules:
‐ action:
  destinations:
  ‐ serviceName: "projects/PROJECT_NUMBER/locations/global/backendServices/td-sd-demo-service"

HTTPRoute 사양을 가져옵니다.

gcloud network-services httproutes import td-sd-demo-route \
  --source=httproute.yaml \
  --location=global

부하 분산 API

다음 예시에서는 my-url-map이라고 부르는 URL 맵을 포함하여 기본 라우팅 구성이 이미 있다고 가정합니다.

먼저 이 URL 맵에 대해 경로 일치자를 만듭니다. 경로 일치자는 복합적이지 않습니다. 경로 일치자를 사용하면 이전 단계에서 만든 td-sd-demo-service로 확인됩니다.
그런 후 URL 맵에 호스트 규칙을 추가합니다. 이 호스트 규칙은 요청에 myservice.example.com 호스트 이름이 지정되는 경우 경로 일치자를 사용하도록 만듭니다.

백엔드 서비스를 가리키는 단순 경로 일치자를 만듭니다.

gcloud compute url-maps add-path-matcher my-url-map \
 --global \
 --default-service td-sd-demo-service \
 --path-matcher-name my-path-matcher

기존 URL 맵에서 백엔드 서비스를 새 호스트 규칙에 매핑합니다.

gcloud compute url-maps add-host-rule my-url-map \
 --global \
 --path-matcher-name=my-path-matcher \
 --hosts=myservice.example.com

여러 리전에서 동일한 서비스 연결

Cloud Service Mesh를 사용하면 여러 서비스 디렉터리 서비스를 동일한 백엔드 서비스에 바인딩할 수 있습니다. 예를 들어 서로 동일하지만 서로 다른 Google Cloud 리전 또는 영역에 엔드포인트가 있는 2개의 서비스 디렉터리 서비스를 만들 수 있습니다. 즉, 단일 전역 백엔드 서비스에 2개의 전역 서비스 결합을 포함하고, 각 서비스 결합이 us-east1의 서비스와 us-west1의 서비스를 가리키도록 설정할 수 있습니다.

가져온 서비스 디렉터리 서비스에 대해 백엔드 서비스를 만듭니다.

gcloud compute backend-services create td-sd-demo-service \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED

us-east1에서 서비스 디렉터리 서비스에 대해 서비스 결합을 만듭니다.

gcloud beta network-services service-bindings create us-east1-binding \
 --location global \
 --service-directory-region us-east1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service \

us-west1에서 서비스 디렉터리 서비스에 대해 서비스 결합을 만듭니다.

gcloud beta network-services service-bindings create us-west1-binding \
 --location global
 --service-directory-region us-west1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service \

us-east1 및 us-west1 서비스를 백엔드 서비스에 바인딩합니다.

gcloud compute backend-services update td-sd-demo-service \
  --global \
  --service-bindings us-east1-binding,us-west1-binding

고급 트래픽 관리 정책 적용

이전 섹션에서는 Cloud Service Mesh를 사용하여 기존 서비스 디렉터리 서비스에 대한 라우팅 정책을 설정했습니다. 이 패턴을 보다 고급 트래픽 관리 시나리오에 적용할 수 있습니다.

이 시나리오를 살펴보겠습니다. Cloud Service Mesh 메시 외부에 있는 기존 테스트 서비스가 있습니다. 테스트 서비스는 내부 애플리케이션 부하 분산기의 백엔드입니다. Cloud Service Mesh 메시에서 시작하는 일부 프로덕션 트래픽을 이 외부 서비스로 재생할 수 있습니다. Cloud Service Mesh는 요청이 처리될 때 트래픽을 다른 백엔드 서비스로 전송할 수 있는 RequestMirrorPolicy를 사용하여 이를 수행할 수 있습니다. 이 프로세스를 요청 섀도잉이라고 부릅니다. 이 프로세스를 사용하면 프로덕션 서비스에 영향을 주지 않고 트래픽을 조사할 수 있습니다.

Cloud Service Mesh 메시에 테스트 서비스 엔드포인트를 수동으로 추가하거나 삭제하여 Envoy 클라이언트가 테스트 서비스로 트래픽을 섀도잉하도록 설정할 수 있습니다. 하지만 서비스 디렉터리 통합을 사용하면 이 프로세스가 더 간단해집니다.

미러링과 함께 서비스 검색에 서비스 디렉터리 사용. — 미러링을 통한 서비스 검색용 서비스 디렉터리 사용(확대하려면 클릭)

이 예시에서는 결제 테스트 서비스를 위해 서비스 디렉터리 등록에 백엔드 서비스를 연결합니다. 그런 후 Cloud Service Mesh의 서비스에 요청 미러링 정책을 추가합니다.

요청 미러링 정책에 대해 백엔드 서비스를 만듭니다.

gcloud compute backend-services create payments-test-bes \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED

서비스 디렉터리 서비스를 참조하는 서비스 결합을 만듭니다.

gcloud beta network-services service-bindings create my-sd-binding \
 --location global \
 --service-directory-region us-east1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service \

서비스 디렉터리 서비스를 테스트 백엔드 서비스에 바인딩합니다.

gcloud beta compute backend-services update payments-test-bes \
 --global \
 --service-bindings my-sd-binding

요청을 테스트 서비스로 미러링하도록 URL 맵을 수정합니다.
```
gcloud compute url-maps edit my-url-map \
  --region=global
```

URL 맵 구성이 편집기에 로드된 후 요청 미러링을 위한 요청 미러 정책을 기존 서비스 디렉터리 서비스에 추가합니다.

defaultService: my-project/global/default-service
   hostRules:
    - hosts:
      - '*'
      pathMatcher: path-matcher-one
   pathMatchers:
    - defaultService: my-project/global/default-service
     name: path-matcher-one
     pathRules:
      - paths:
        - /payments/
        service: my-project/global/default-service
        requestMirrorPolicy:
          backendService: myproject/global/payments-test-bes

백엔드 서비스에서 서비스 바인딩 삭제

백엔드 서비스에서 서비스 결합을 삭제하려면 새 서비스 결합 목록을 gcloud compute backend-services update 명령어에 전달합니다. 새 목록에는 삭제하려는 서비스 결합이 포함되지 않아야 합니다.

모든 서비스 결합을 삭제하려면 --no-service-bindings 플래그를 설정합니다.
하나 이상의 서비스 결합을 삭제하려면 삭제하려는 서비스 결합이 생략된 새로운 서비스 결합 목록을 --service-bindings 플래그로 전달합니다.

서비스 결합 추가 또는 삭제

bind-service 명령어는 백엔드 서비스에서 기존 서비스 결합 집합에 서비스 결합을 추가합니다.

gcloud compute backend-services bind-service BACKEND_SERVICE_NAME \
  --service-binding-name SERVICE_BINDING_URL \
  --global

unbind-service 명령어는 백엔드 서비스의 기존 서비스 결합 집합에서 서비스 결합을 삭제합니다.

gcloud compute backend-services unbind-service BACKEND_SERVICE_NAME \
  --service-binding-name SERVICE_BINDING_URL \
  --global

bind-service 및 unbind-service 명령어는 Google Cloud CLI 구성요소입니다. API 수준 요소가 아닙니다.

다음 단계

이 통합과의 관측 가능성에 대한 자세한 내용은 관측 가능성 및 서비스 디렉터리 디버깅을 참조하세요.