Anthos Service Mesh와 Traffic Director가 이제 Cloud Service Mesh로 통합되었습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

교차 프로젝트 네트워크 엔드포인트 그룹 설정

교차 프로젝트 네트워크 엔드포인트 그룹(NEG) 기능을 사용하면 고객이 다른 프로젝트의 NEG를 Traffic Director/Cloud Service Mesh BackendService에 연결하여 다음과 같은 사용 사례를 지원할 수 있습니다.

다중 프로젝트 배포에서 BackendServices는 중앙 집중식 프로젝트의 연결된 라우팅 및 트래픽 정책과 함께 다른 프로젝트의 백엔드 엔드포인트와 함께 사용됩니다.
다중 프로젝트 배포에서는 단일 중앙 Google Cloud 프로젝트에서 모든 컴퓨팅 리소스(Compute Engine VM, GKE NEG 등)를 관리할 수 있으며 서비스팀은 자체 Google Cloud 서비스 프로젝트를 소유하고 각 서비스 프로젝트에서 BackendServices로 표현된 서비스 정책과 서비스 라우팅 경로를 정의합니다. 이렇게 하면 여러 서비스팀 간에 공유될 수 있는 컴퓨팅 리소스를 긴밀하게 제어하면서 서비스 관리를 위임할 수 있습니다.

이 페이지에서는 프로젝트 A (워크로드 프로젝트라고 함)의 NEG가 프로젝트 B (정책 프로젝트라고 함)의 BackendService에 연결된 기준 2개 프로젝트 설정을 만드는 방법을 보여줍니다. 다음 예에서는 워크로드 프로젝트의 기본 VPC 네트워크에 워크로드 VM을 설정하고 클라이언트가 정책 프로젝트의 구성에 따라 워크로드 프로젝트로 라우트할 수 있음을 보여줍니다.

기준 교차 프로젝트 NEG 예시

보다 정교한 설정의 경우 여러 프로젝트 간에 상호 연결된 데이터 영역을 사용하려면 공유 VPC와 같은 솔루션이 필요합니다. 또한 NEG 엔드포인트에는 고유한 IP가 있습니다. 이 설정 예시는 워크로드가 여러 프로젝트에 걸쳐 있는 공유 VPC 네트워크에 있는 더 복잡한 시나리오로 확장할 수 있습니다.

제한사항

일반적인 Traffic Director 제한사항 및 BackendService/NetworkEndpointGroup 제한사항이 적용됩니다.

다음 제한사항도 적용되지만 다중 프로젝트 설정에는 해당하지 않을 수 있습니다.

단일 BackendService는 최대 50개의 백엔드(NEG, MIG 포함)만 지원할 수 있습니다.
GCP_VM_IP_PORT 유형의 영역별 NEG만 지원됩니다.
프로젝트 간 BackendServices와 인스턴스 그룹(관리형 또는 비관리형) 참조는 지원되지 않습니다.
지정된 BackendService에 연결할 수 있는 프로젝트 간 NEG를 나열하는 기능은 지원되지 않습니다.
특정 NEG를 사용하는 프로젝트 간 BackendServices를 나열하는 것은 지원되지 않습니다.

시작하기 전에

교차 프로젝트 NEG를 설정하려면 먼저 다음 기본 요건을 충족해야 합니다.

필요한 API 사용 설정

이 가이드를 완료하려면 다음 API가 필요합니다.

osconfig.googleapis.com
trafficdirector.googleapis.com
compute.googleapis.com
networkservices.googleapis.com

다음 명령어를 실행하여 워크로드 프로젝트와 정책 프로젝트 모두에서 필요한 API를 사용 설정합니다.

gcloud services enable --project PROJECT_ID \
    osconfig.googleapis.com \
    trafficdirector.googleapis.com \
    compute.googleapis.com \
    networkservices.googleapis.com

필수 IAM 권한 부여

이 가이드를 완료하려면 충분한 Identity and Access Management(IAM) 권한이 있어야 합니다. Cloud Service Mesh를 사용 설정하려는 프로젝트에 소유자 또는 편집자 프로젝트 역할(roles/owner 또는 roles/editor)이 있으면 올바른 권한이 자동으로 부여됩니다.

그렇지 않으면 다음 IAM 역할을 모두 부여해야 합니다. 이러한 역할이 있는 경우 Compute Engine IAM 문서에 설명된 대로 관련 권한도 갖게 됩니다.

워크로드 프로젝트와 정책 프로젝트 둘 다에 다음 역할이 필요합니다.

roles/iam.serviceAccountAdmin
roles/serviceusage.serviceUsageAdmin
roles/compute.networkAdmin

워크로드 프로젝트에만 다음 역할이 필요합니다.

roles/compute.securityAdmin
roles/container.admin
다음 권한이 포함된 모든 역할 NEG를 BackendService에 연결하는 데 필요한 모든 권한을 포함하는 가장 상세한 사전 정의된 역할은 roles/compute.loadBalancerServiceUser입니다.
- compute.networkEndpointGroups.get
- compute.networkEndpointGroups.use

또한 Traffic Director 관리 xDS 클라이언트 (예: Envoy 프록시)에는 roles/trafficdirector.client에 권한이 있어야 합니다. 데모 목적으로 다음 명령어를 사용하여 정책 프로젝트에서 워크로드 프로젝트의 기본 컴퓨팅 서비스 계정에 이 권한을 부여할 수 있습니다.

gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
    --member "serviceAccount:WORKLOAD_PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role "roles/trafficdirector.client"

각 항목의 의미는 다음과 같습니다.

POLICY_PROJECT_ID: 정책 프로젝트의 ID
WORKLOAD_PROJECT_NUMBER: 워크로드 프로젝트의 프로젝트 번호

워크로드 프로젝트에서 서비스 백엔드 구성

다음 명령어를 실행하여 Google Cloud CLI를 정책 프로젝트로 가리키고 기본 Google Cloud 컴퓨팅 영역을 설정합니다.
```
gcloud config set project WORKLOAD_PROJECT_ID
gcloud config set compute/zone ZONE
```
각 항목의 의미는 다음과 같습니다.
- WORKLOAD_PROJECT_ID: 워크로드 프로젝트의 ID
- ZONE: GKE 클러스터의 영역(예: us-central1)
GKE 클러스터 만들기 데모 목적으로 다음 명령어는 영역 GKE 클러스터를 만듭니다. 하지만 이 기능은 지역별 GKE 클러스터에서도 작동합니다.
```
gcloud container clusters create test-cluster \
    --scopes=https://www.googleapis.com/auth/cloud-platform
    --zone=ZONE
```

방화벽 규칙 만들기

gcloud compute firewall-rules create http-allow-health-checks \
    --network=default \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=35.191.0.0/16,130.211.0.0/22 \
    --rules=tcp:80

방화벽 규칙을 사용하면 Google Cloud 컨트롤 플레인이 기본 VPC 네트워크의 백엔드에 상태 확인 프로브를 전송할 수 있습니다.

kubectl의 현재 컨텍스트를 새로 만든 클러스터로 변경합니다.

gcloud container clusters get-credentials test-cluster \
    --zone=ZONE

whereami 샘플 앱을 만들고 배포합니다.

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whereami
spec:
  replicas: 2
  selector:
    matchLabels:
      app: whereami
  template:
    metadata:
      labels:
        app: whereami
    spec:
      containers:
      - name: whereami
        image: gcr.io/google-samples/whereami:v1.2.20
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: whereami
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"8080":{"name": "example-neg"}}}'
spec:
  selector:
    app: whereami
  ports:
  - port: 8080
    targetPort: 8080
EOF

다음 명령어를 실행하여 NEG 참조를 변수에 저장합니다.
```
NEG_LINK=$(gcloud compute network-endpoint-groups describe example-neg --format="value(selfLink)")
```
NEG 컨트롤러는 각 영역의 서비스 백엔드에 대해 영역 NetworkEndpointGroup을 자동으로 만듭니다. 이 예에서 NEG 이름은 example-neg로 하드코딩됩니다. 변수로 저장하면 다음 세션에서 이 NEG를 정책 프로젝트의 BackendService에 연결할 때 유용합니다.

$NEG_LINK의 예를 들면 다음과 같이 표시됩니다.
```
$ echo ${NEG_LINK}
https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT/zones/ZONE/networkEndpointGroups/example-neg
```
또는 서비스에서 neg-status 주석을 읽어서 NEG URL을 검색할 수 있습니다.
```
kubectl get service whereami -o jsonpath="{.metadata.annotations['cloud\.google\.com/neg-status']}"
NEG_LINK="https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT_ID/zones/ZONE/networkEndpointGroups/example-neg"
```

정책 프로젝트에서 Google Cloud 네트워킹 리소스 구성

Google Cloud CLI를 정책 프로젝트로 가리킵니다.
```
gcloud config set project POLICY_PROJECT_ID
```
메시 리소스를 구성합니다.
```
gcloud network-services meshes import example-mesh --source=- --location=global << EOF
name: example-mesh
EOF
```
메시 리소스의 이름은 사이드카 프록시가 서비스 메시의 구성을 요청하는 데 사용하는 키입니다.

상태 점검으로 기준 BackendService를 구성합니다.

gcloud compute health-checks create http http-example-health-check

gcloud compute backend-services create example-service \
  --global \
  --load-balancing-scheme=INTERNAL_SELF_MANAGED \
  --protocol=HTTP \
  --health-checks http-example-health-check

이전 섹션에서 만든 NetworkEndpointGroup을 BackendService에 연결합니다.

gcloud compute backend-services add-backend example-service --global \
  --network-endpoint-group=${NEG_LINK} \
  --balancing-mode=RATE \
  --max-rate-per-endpoint=5

호스트 헤더가 example-service인 모든 HTTP 요청을 워크로드 프로젝트의 서버로 라우팅하는 HTTPRoute를 만듭니다.

gcloud network-services http-routes import example-route --source=- --location=global << EOF
name: example-route
hostnames:
- example-service
meshes:
- projects/POLICY_PROJECT_NUMBER/locations/global/meshes/example-mesh
rules:
- action:
    destinations:
    - serviceName: "projects/POLICY_PROJECT_NUMBER/locations/global/backendServices/example-service"
EOF

여기서 POLICY_PROJECT_NUMBER는 정책 프로젝트의 프로젝트 번호입니다.

설정 확인

HOST 헤더가 example-service로 설정된 HTTP 요청을 Traffic Director 관리 사이드카 프록시 뒤의 VIP에 전송하여 설정을 확인할 수 있습니다.

curl -H "Host: example-service" http://10.0.0.1/

출력은 다음과 비슷합니다.

{"cluster_name":"test-cluster","gce_instance_id":"4879146330986909656","gce_service_account":"...","host_header":"example-service","pod_name":"whereami-7fbffd489-nhkfg","pod_name_emoji":"...","project_id":"...","timestamp":"2024-10-15T00:42:22","zone":"us-west1-a"}

포드의 모든 아웃바운드 트래픽은 서비스 메시의 Envoy 사이드카에 의해 가로채지며, 이전 HTTPRoute는 L7 속성(호스트 헤더)만을 기반으로 모든 트래픽을 'whereami' Kubernetes 서비스로 전송하도록 구성되어 있습니다. 예를 들어 이 명령어의 VIP는 10.0.0.1이지만 VIP는 어떤 IP든 될 수 있습니다.

사이드카 프록시는 정책 프로젝트의 메시 리소스와 연결된 구성을 요청해야 합니다. 이렇게 하려면 노드 ID가 다음 형식으로 설정되어 있는지 확인합니다.

projects/POLICY_PROJECT_NUMBER/networks/mesh:example-mesh/nodes/UUID"

다음 단계

교차 프로젝트 메시 경로 설정