Compute Engine VM의 Istio ServiceEntry를 GCPBackend로 마이그레이션

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

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

  1. 엔드포인트 검색 - 백엔드 서비스의 VM 엔드포인트는 VM 인스턴스가 추가되거나 삭제될 때 자동으로 업데이트됩니다.
  2. 중앙 집중식 상태 확인 - VM 엔드포인트의 상태가 확인되고 트래픽이 비정상 백엔드에서 정상 백엔드로 자동 라우팅됩니다.
  3. 글로벌 부하 분산 및 고급 부하 분산 알고리즘 - VM 엔드포인트를 여러 리전에 배포할 수 있습니다. Google의 부하 분산 알고리즘을 사용하여 이러한 리전에서 부하 분산 동작을 구성합니다. 자세한 내용은 https://cloud.google.com/service-mesh/docs/service-routing/advanced-load-balancing-overview 및 https://cloud.google.com/service-mesh/docs/service-routing/advanced-load-balancing-overview를 참고하세요.
  4. 원활한 마이그레이션: 트래픽 분할 및 미러링을 활용하여 애플리케이션을 중단하지 않고도 트래픽을 안전하게 마이그레이션합니다.
  5. 향상된 관리 가능성: 간소화된 구성 및 관리의 이점을 누리세요.

시작하기 전에

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

  1. Cloud Service Mesh가 사용 설정된 GKE 클러스터
  2. Istio 서비스 항목
  3. Compute Engine VM용 GCPBackend 리소스를 구성했습니다.

ServiceEntry와 GCPBackend를 모두 대상에 포함하도록 기존 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 구성

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

기능 검증

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

애플리케이션 외부에서 테스트하려면 curl 클라이언트를 배포하면 됩니다. 요청이 GCPBackend API를 사용하도록 라우팅된 경우 Cloud Service Mesh에서 자동으로 연결하므로 요청에 명시적으로 연결된 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 응답이어야 합니다.