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. Istio 서비스 항목
  3. Cloud Run 서비스에 대한 GCPBackend 리소스 구성

ServiceEntry와 GCPBackend를 모두 대상으로 포함하도록 VirtualService를 만들거나 기존 VirtualService를 수정

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

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

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

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

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

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

  • VIRTUAL_SERVICE은 gcpbackend-migration입니다.
  • SERVICE_ENTRY_HOSTNAME은 service-entry.com입니다.
  • GCP_BACKEND_HOSTNAME은 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 응답이어야 합니다.