멀티 클러스터 메시 장애 조치 설정

참고: 이 가이드는 Istio API가 포함된 Cloud Service Mesh만 지원하고 Google Cloud API를 지원하지 않습니다. 자세한 내용은 Cloud Service Mesh 개요를 참고하세요.

주의: Google Cloud 기반 GKE에서 ISTIOD 컨트롤 플레인을 사용하는 클러스터 내 Cloud Service Mesh는 지원 중단되었습니다. Google Distributed Cloud (소프트웨어만 해당)의 클러스터 내 컨트롤 플레인이 있는 Cloud Service Mesh는 지원되는 플랫폼에 설명된 대로 계속 지원됩니다.

주의: ISTIOD 컨트롤 플레인 구현을 사용하는 관리형 Cloud Service Mesh는 지원 중단되었습니다. 모든 관리형 ISTIOD Fleet를 TRAFFIC_DIRECTOR 컨트롤 플레인 구현으로 현대화해야 합니다.

이 페이지에서는 멀티 클러스터 환경에서 Cloud Service Mesh를 사용하여 고가용성 트래픽 라우팅 전략을 설계하고 구현하는 방법을 보여줍니다. 다음 표에서는 예상되는 동작을 설명합니다.

클러스터 상태	트래픽 동작
두 클러스터 모두 정상	트래픽의 50% 를 클러스터 A로, 50% 를 클러스터 B로
클러스터 A를 사용할 수 없게 됨	클러스터 B로 100% 트래픽
클러스터 A가 복구됨	50/50 분할을 자동으로 복원합니다.

중요: 이 설정은 ISTIOD 컨트롤 플레인 구현이 있는 관리형 Cloud Service Mesh와 클러스터 내 Cloud Service Mesh에만 적용됩니다.

기본 요건

이 가이드에서는 사용자가 다음 요건을 이미 충족한다고 가정합니다.

• Cloud Service Mesh용으로 구성된 서로 다른 두 리전에 동일한 Fleet 호스트 프로젝트에 등록된 두 개의 GKE 클러스터를 만들었습니다.
• Cloud Service Mesh에서 멀티 클러스터 메시를 설정합니다.
• 두 클러스터 모두에 Istio 컨트롤 플레인이 설치되고 구성되어 있습니다.
• istio-ingressgateway가 하나 이상의 클러스터(클러스터 A)에 배포되고 노출됩니다.
• 사이드카 삽입이 사용 설정된 두 클러스터에 모두 배포된 hello-world 애플리케이션

이 실습에서는 다음 리전을 사용합니다.

• 클러스터 A: europe-west1
• 클러스터 B: us-central1

멀티 클러스터 메시 장애 조치 설정

1. Cloud Service Mesh 저장소의 샘플 매니페스트를 사용하여 공개 인그레스 게이트웨이를 배포하고 적용합니다.

   cat <<EOF> istio-ingressgateway.yaml
   apiVersion: networking.istio.io/v1alpha3
   kind: Gateway
   metadata:
     name: public-gateway
     namespace: default
   spec:
     selector:
       istio: ingressgateway
     servers:
     - port:
         number: 80
         name: http
         protocol: HTTP
       hosts:
       - '*'
   EOF
   
   kubectl apply -f istio-ingressgateway.yaml
   

   이 게이트웨이는 hello-world 서비스를 외부에 노출합니다.

2. 클러스터 A에서 VirtualService를 만들어 적용하여 hello-world 서비스로 트래픽을 라우팅합니다.

   cat <<EOF> virtual-service.yaml
   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: hello-world
     namespace: default
   spec:
     hosts:
     - '*'
     gateways:
     - public-gateway
     http:
     - route:
       - destination:
           host: hello-world.default.svc.cluster.local
   EOF
   
   kubectl apply -f virtual-service.yaml
   

   이 구성은 게이트웨이에서 서비스로 HTTP 요청을 전달합니다.

3. 위치 기반 장애 조치를 위해 DestinationRule 구성 및 적용

   cat <<EOF> destination-rule.yaml
   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   metadata:
     name: hello-world
     namespace: default
   spec:
     host: hello-world.default.svc.cluster.local
     trafficPolicy:
       connectionPool:
         http:
           http2MaxRequests: 100
       outlierDetection:
         consecutive5xxErrors: 1
         interval: 1s
         baseEjectionTime: 30s
         maxEjectionPercent: 100
       loadBalancer:
         localityLbSetting:
           enabled: true
           distribute:
           - from: europe-west1
             to:
               europe-west1: 50
               us-central1: 50
           - from: us-central1
             to:
               us-central1: 50
               europe-west1: 50
   EOF
   
   kubectl apply -f destination-rule.yaml
   

다음에 유의하세요.

• DestinationRule의 localityLbSetting을 사용하면 트래픽 분할과 자동 장애 조치도 가능합니다.
• maxEjectionPercent를 사용하면 지역의 모든 엔드포인트가 비정상인 경우 Istio가 모든 트래픽을 장애 조치할 수 있습니다.
• distribute: 소스 클러스터의 리전을 기반으로 클러스터 간에 균등한 50/50 분할을 보장합니다.
• 장애 조치: 한 지역을 사용할 수 없게 되면 암시적으로 처리됩니다. Istio는 트래픽의 100% 를 정상 리전으로 라우팅합니다.
• outlierDetection: 최소 오류 임곗값 후 실패한 엔드포인트를 제거합니다.

경고: VirtualService 내에서 하위 집합을 구성할 때 이러한 설정이 자동 장애 조치 로직보다 우선합니다. 특정 하위 집합에 정상 포드가 없으면 서비스 메시가 자동으로 트래픽을 다른 지역으로 리디렉션하지 않습니다. 대신 메시가 정의된 가중치에 따라 트래픽을 계속 라우팅하므로 대상 버전이나 하위 집합을 사용할 수 없게 되면 요청이 실패할 수 있습니다.

검증

이제 다음 방법으로 이 동작을 검증할 수 있습니다.

1. 클러스터 A의 인그레스 게이트웨이를 통해 요청을 전송합니다.
2. europe-west1에서 hello-world 포드를 0으로 축소합니다.
3. 트래픽이 us-central1로 장애 조치되는 것을 관찰합니다.
4. europe-west1에서 포드를 다시 확장하고 트래픽 분할이 재개되는지 확인합니다.