Cloud Service Mesh 워크로드에서 Cloud Run 서비스로 트래픽 라우팅
이 페이지에서는 GKE의 Cloud Service Mesh 워크로드에서 Cloud Run 서비스로 네트워크 트래픽을 안전하게 라우팅하는 방법을 보여줍니다.
GKE에서 Cloud Run으로 트래픽을 라우팅할 때 Cloud Run 서비스가 Cloud Service Mesh에 참여할 필요는 없습니다. 하지만 Cloud Run 서비스는 Cloud Service Mesh GKE 클러스터와 동일한 프로젝트에 있어야 합니다. 이 제한사항은 이 기능이 공개 미리보기 버전으로 제공되는 동안 적용됩니다.
시작하기 전에
다음 섹션에서는 다음 사항을 충족했다고 가정합니다.
또는 다음 명령어를 실행하여 샘플 Cloud Run 서비스를 배포할 수 있습니다.
클러스터의 kubeconfig 컨텍스트를 생성합니다.
gcloud container clusters get-credentials CLUSTER_NAME --project=PROJECT_ID --location=CLUSTER_LOCATION각 항목의 의미는 다음과 같습니다.
- CLUSTER_NAME은 클러스터의 이름입니다.
- PROJECT_ID는 프로젝트의 프로젝트 ID입니다.
- CLUSTER_LOCATION은 클러스터의 리전 또는 영역입니다.
샘플 Cloud Run 서비스를 배포합니다.
gcloud run deploy hello-world \ --image=us-docker.pkg.dev/cloudrun/container/hello \ --no-allow-unauthenticated \ --port=8080 \ --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com \ --region=us-central1 \ --project=PROJECT_ID각 항목의 의미는 다음과 같습니다.
- PROJECT_NUMBER는 프로젝트의 프로젝트 번호입니다.
- PROJECT_ID는 프로젝트의 프로젝트 ID입니다.
IAM 구성
Cloud Run 서비스를 호출하려면 Cloud Run Identity and Access Management (IAM) 검사를 통과해야 합니다. Google 서비스 계정에 Cloud Run 호출자 역할을 부여해야 합니다. 또한 Google 서비스 계정을 가장하도록 GKE Kubernetes 서비스 계정 (KSA)을 구성해야 합니다.
Kubernetes 서비스 계정이 Google 서비스 계정을 가장하도록 허용하려면 다음 단계를 따르세요.
IAM 서비스 계정에 IAM 정책 바인딩을 추가합니다.
gcloud iam service-accounts add-iam-policy-binding PROJECT_NUMBER-compute@developer.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA]"각 항목의 의미는 다음과 같습니다.
- NAMESPACE는 네임스페이스 이름입니다. 이 가이드에서는 네임스페이스
default를 사용할 수 있습니다. - KSA는 Kubernetes 서비스 계정의 이름입니다. 이 가이드에서는 KSA
default를 사용할 수 있습니다.
- NAMESPACE는 네임스페이스 이름입니다. 이 가이드에서는 네임스페이스
서비스 계정에 주석을 추가합니다.
kubectl annotate serviceaccount KSA \ --namespace NAMESPACE \ iam.gke.io/gcp-service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.comGoogle 서비스 계정에 Cloud Run 호출자 역할을 부여합니다.
gcloud run services add-iam-policy-binding hello-world \ --region=us-central1 \ --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \ --role="roles/run.invoker"
Cloud Run 서비스를 GCPBackend로 구성
이 섹션에서는 GCPBackend를 사용하여 Cloud Run 서비스를 GKE 워크로드에 노출합니다. GCPBackend는 다음으로 구성됩니다.
- 프런트엔드 정보 - 특히 GKE 워크로드가 이 GCPBackend를 호출하는 데 사용할 호스트 이름과 포트입니다.
- 백엔드 정보 - 서비스 이름, 위치, 프로젝트 번호와 같은 Cloud Run 서비스 세부정보
GCPBackend에는 호스트 이름 및 포트 세부정보와 Cloud 서비스 세부정보 (서비스 이름, 위치, 프로젝트 번호)가 포함됩니다. GKE 워크로드는 HTTP 요청에서 GCPBackend 호스트 이름과 포트를 사용하여 Cloud Run 서비스에 액세스해야 합니다.
클러스터 내에서 호스트네임 DNS를 확인할 수 있도록 하려면 (기본적으로 확인할 수 없음) 선택한 호스트네임 아래의 모든 호스트를 임의의 IP 주소로 확인하도록 Google Cloud DNS를 구성해야 합니다. 이 DNS 항목을 구성할 때까지 요청이 실패합니다. Google Cloud DNS 구성은 맞춤 도메인별로 일회성으로 설정됩니다.
관리형 영역을 만듭니다.
gcloud dns managed-zones create prod \ --description="zone for gcpbackend" \ --dns-name=gcpbackend \ --visibility=private \ --networks=default이 예에서 DNS 이름은 gcpbackend이고 VPC 네트워크는 default입니다.
도메인을 확인할 수 있도록 레코드를 설정합니다.
gcloud beta dns record-sets create *.gcpbackend \ --ttl=3600 --type=A --zone=prod \ --rrdatas=10.0.0.1이전 도메인 아래에 호스트 이름이 있는 GCPBackend를 만듭니다.
cat <<EOF > gcp-backend.yaml apiVersion: networking.gke.io/v1 kind: GCPBackend metadata: name: cr-gcp-backend namespace: NAMESPACE spec: hostname: hello-world.gcpbackend type: CloudRun cloudrun: service: hello-world regions: [us-central1] EOF kubectl apply -f gcp-backend.yaml이 예에서 GCP_BACKEND_NAME는
cr-gcp-backend입니다.GKE와 Cloud Run 간의 연결을 확인하기 위한 테스트 포드를 만듭니다.
cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: testcurl namespace: default spec: containers: - name: curl image: curlimages/curl command: ["sleep", "3000"] EOF kubectl exec testcurl -c curl -- curl http://hello-world.gcpbackend/hello이제 GKE 워크로드는 hello-world.gcpbackend/hello에 HTTP 요청을 전송하여 Cloud Run 서비스에 액세스할 수 있습니다.
기존 Kubernetes 서비스 또는 Istio 서비스 항목과의 충돌을 방지하려면 GCPBackend에 고유한 이름을 사용해야 합니다. 충돌하는 경우 우선순위 순서 (높음에서 낮음)는 Kubernetes 서비스, istio ServiceEntry, GCPBackend입니다.
가상 서비스와 GCPBackend는 동일한 네임스페이스에 있어야 하며 Cloud Run 서비스는 Cloud Service Mesh GKE 클러스터와 동일한 프로젝트에 있어야 합니다.
(선택사항) Cloud DNS 대신 Cloud Run의 호스트 이름 사용
모든 Cloud Run 서비스에는 호스트 이름 (예: hello-world.us-central1.run.app)이 할당되며 전 세계에서 DNS로 확인할 수 있습니다. GCPBackend 호스트 이름에서 이 호스트 이름을 직접 사용하고 Cloud DNS 구성을 건너뛸 수 있습니다.
cat <<EOF | kubectl apply -f -
apiVersion: networking.gke.io/v1
kind: GCPBackend
metadata:
name: cr-gcp-backend
namespace: NAMESPACE
spec:
hostname: hello-world.us-central1.run.app
type: CloudRun
cloudrun:
service: hello-world
region: [us-central1]
EOF
이제 GKE 워크로드는 hello-world.us-central1.run.app에 HTTP 요청을 전송하여 Cloud Run 서비스에 액세스할 수 있습니다.
(선택사항) Istio 가상 서비스 또는 대상 규칙 구성
GCPBackend 호스트 이름에 Istio 가상 서비스 또는 Istio 대상 규칙을 구성하여 GCPBackend에 대한 요청의 소비자 또는 클라이언트 정책을 설정할 수 있습니다.
다음 예에서는 요청의 50% 에 5초의 지연을 삽입하고 GCPBackend로 전송되는 요청의 10% 를 중단(503 HTTP 상태)합니다.
cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: cr-virtual-service
namespace: NAMESPACE
spec:
hosts:
- hello-world.us-central1.run.app
gateways:
- mesh
http:
- fault:
delay:
percentage:
value: 50 # Delay 50% of requests
fixedDelay: 5s
abort:
percentage:
value: 10 # Abort 10% of requests
httpStatus: 503
- route:
- destination:
host: hello-world.us-central1.run.app
EOF
이 예에서 VIRTUAL_SERVICE_NAME는 cr-virtual-service입니다.
문제 해결
이 섹션에서는 Cloud Service Mesh 및 Cloud Run의 일반적인 오류를 해결하는 방법을 보여줍니다.
Cloud Run 사이드카 로그
Envoy 오류는 Cloud Logging에 로깅됩니다.
예를 들어 Cloud Run 서비스 계정에 메시 프로젝트에서 trafficdirector 클라이언트 역할이 부여되지 않으면 다음과 같은 오류가 로깅됩니다.
StreamAggregatedResources gRPC config stream to trafficdirector.googleapis.com:443 closed: 7, Permission 'trafficdirector.networks.getConfigs' denied on resource '//trafficdirector.googleapis.com/projects/525300120045/networks/mesh:test-mesh/nodes/003fb3e0c8927482de85f052444d5e1cd4b3956e82b00f255fbea1e114e1c0208dbd6a19cc41694d2a271d1ab04b63ce7439492672de4499a92bb979853935b03d0ad0' (or it may not exist).
CSDS
trafficdirector 클라이언트 상태는 CSDS를 사용하여 검색할 수 있습니다.
gcloud alpha container fleet mesh debug proxy-status --membership=<CLUSTER_MEMBERSHIP> --location=<CLUSTER_LOCATION>
External Clients:
....