Cloud Run용 Istio ServiceEntry를 GCPBackend로 마이그레이션

이 페이지에서는 ServiceEntry에서 GCPBackend로 이전하는 방법을 보여줍니다. Istio의 트래픽 관리 기능을 사용하여 원활하고 안전하게 전환하는 방법을 보여줍니다.

GCPBackend로 이전하면 다음과 같은 이점이 있습니다.

  1. 간소화된 애플리케이션 코드: 애플리케이션에서 수동 IAM JWT 삽입이 필요하지 않으므로 복잡성과 잠재적 오류가 줄어듭니다.
  2. 보안 개선: 자동 IAM JWT 삽입을 활용하여 GKE와 Cloud Run 간의 통신을 더 안전하게 보호하세요.
  3. 원활한 마이그레이션: 트래픽 분할 및 미러링을 활용하여 애플리케이션을 중단하지 않고 트래픽을 안전하게 마이그레이션합니다.
  4. 향상된 관리 가능성: 간소화된 구성 및 관리의 이점을 누리세요.

시작하기 전에

다음 섹션에서는 다음 사항을 충족했다고 가정합니다.

  1. Cloud Service Mesh가 사용 설정된 GKE 클러스터
  2. Cloud Run 서비스를 Istio 서비스 항목으로 표시합니다.
  3. GCPBackend 리소스 구성

ServiceEntry와 GCPBackend를 모두 대상에 포함하도록 기존 VirtualService를 만들거나 수정합니다.

트래픽 분할을 사용하여 ServiceEntry에서 GCPBackend로 트래픽을 점진적으로 전환할 수 있습니다. GCPBackend로 전달되는 트래픽의 소수 비율로 시작하고 문제를 모니터링하면서 점진적으로 늘려야 합니다.

다음 예에서는 요청의 10% 를 GCPBackend로 이전하는 방법을 설명합니다.

cat <<EOF > virtual-service.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: cr-gcpbackend-migration
  namespace: NAMESPACE
spec:
  hosts:
  - cr-service-entry.com
  http:
  - route:
    - destination:
        host: cr-gcpbackend.com
      weight: 10 # 10% traffic to gcp backend.
    - destination:
        host: cr-service-entry.com
      weight: 90 # 90% traffic to service entry
EOF
kubectl apply -f virtual-service.yaml

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

  • NAMESPACE는 네임스페이스 이름입니다.

이 예에서는 다음과 같이 정의됩니다.

  • VIRTUAL_SERVICEE은 cr-gcpbackend-migration입니다.
  • SERVICE_ENTRY_HOSTNAME은 cr-service-entry.com입니다.
  • GCP_BACKEND_HOSTNAME은 =cr-gcpbackend.com입니다.

(선택사항) 트래픽 미러링을 위해 VirtualService 구성

원활한 전환을 위해 트래픽 미러링을 구성하여 트래픽 사본을 GCPBackend로 전송하는 동시에 주로 트래픽을 ServiceEntry로 전달할 수 있습니다. 이렇게 하면 기본 트래픽 흐름에 영향을 주지 않고 GCPBackend 구성을 테스트하고 검증할 수 있습니다. 자세한 내용은 Istio Virtual Service API를 참고하세요.

기능 검증

애플리케이션 로그 또는 Cloud Service Mesh 측정항목을 참고하여 $SERVICE_ENTRY_HOSTNAME에 대한 요청의 오류 비율을 확인합니다. 오류가 없어야 합니다.

애플리케이션 외부에서 테스트하려면 curl 클라이언트를 배포하면 됩니다. 요청이 GCPBackend API를 사용하여 CloudRun으로 라우팅되는 경우 Cloud Service Mesh가 자동으로 IAM 토큰을 연결하므로 요청에 명시적으로 연결된 IAM 토큰이 필요하지 않습니다.

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 "$SERVICE_ENTRY_HOSTNAME"

출력은 유효한 HTTP 200 응답이어야 합니다.