컨테이너를 Google Cloud로 마이그레이션: 멀티 클러스터 인그레스 멀티 클러스터 서비스 검색을 사용하여 멀티 클러스터 GKE 환경으로 마이그레이션

이 문서에서는 최소한의 다운타임으로 단일 클러스터 Google Kubernetes Engine(GKE) 환경에서 멀티 클러스터 GKE 환경으로 마이그레이션하는 방법을 설명합니다. 멀티 클러스터 GKE 환경에는 다음이 사용됩니다.

이 문서는 최소한의 다운타임으로 단일 클러스터 환경에서 멀티 클러스터 환경으로 마이그레이션을 계획하는 경우에 유용합니다. 이 문서는 마이그레이션 기회를 살펴보고 마이그레이션 과정을 미리 알아보고자 할 때 유용합니다.

멀티 클러스터 환경은 단일 장애점으로 발생하는 확장성 문제 및 서비스 중단을 완화하는 데 도움을 줄 수 있습니다. 멀티 클러스터 인그레스 및 멀티 클러스터 서비스 검색을 사용하는 경우 워크로드의 여러 인스턴스를 배포하고 클러스터 외부에 있거나 멀티 클러스터 환경의 다른 클러스터에서 실행되는 클라이언트에 투명하게 노출할 수 있습니다.

이 문서는 컨테이너를 Google Cloud로 마이그레이션하는 방법을 설명하는 시리즈의 일부입니다.

이 튜토리얼에서는 사용자가 다음 항목에 익숙하다고 가정합니다.

  • Kubernetes
  • GKE
  • 멀티 클러스터 인그레스
  • 멀티 클러스터 서비스 검색

이 튜토리얼에서 사용하는 소프트웨어는 다음과 같습니다.

  • Terraform: 클라우드 환경에서 리소스를 프로비저닝하기 위한 도구입니다.

이 튜토리얼의 단계는 대부분 Cloud Shell에서 수행됩니다.

목표

  • GKE 클러스터를 프로비저닝하여 원본 환경을 시뮬레이션합니다.
  • 다중 GKE 클러스터를 프로비저닝하여 대상 환경을 시뮬레이션합니다.
  • 이 튜토리얼에서 제공되는 예시 워크로드를 배포합니다.
  • 멀티 클러스터 서비스 검색 및 멀티 클러스터 인그레스를 구성합니다.
  • 멀티 클러스터 인그레스로 예시 워크로드를 노출합니다.
  • 멀티 클러스터 서비스 검색을 배포하고 사용합니다.
  • 트래픽을 대상 환경으로 전환합니다.
  • 원본 환경을 사용 중단합니다.

비용

이 가이드에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

시작하기 전에

이 튜토리얼의 단계를 완료하려면 다음이 필요합니다.

새 조직 및 새 결제 계정을 만들거나 기존 조직 및 결제 계정을 사용할 수 있습니다. 이 튜토리얼에서는 스크립트를 실행하여 2개의 Google Cloud 프로젝트를 만듭니다.

환경 준비

  1. Cloud Console에서 Cloud Shell을 활성화합니다.

    Cloud Shell 활성화

    Cloud Console 하단에 Cloud Shell 세션이 시작되고 명령줄 프롬프트가 표시됩니다. Cloud Shell은 gcloud 명령줄 도구가 포함되고 Cloud SDK가 사전 설치된 셸 환경으로, 현재 프로젝트의 값이 이미 설정되어 있습니다. 세션이 초기화되는 데 몇 초 정도 걸릴 수 있습니다.

  2. 작업 디렉터리를 홈 디렉터리로 변경합니다.

    cd "${HOME}"
    
  3. GitHub 저장소를 클론합니다.

    git clone https://github.com/GoogleCloudPlatform/solutions-multicluster-gke-migration.git
    

    저장소에는 데모 워크로드를 배포하고 구성하기 위한 스크립트 및 매니페스트 파일이 포함되어 있습니다.

  4. 애플리케이션 기본 사용자 인증 정보를 사용하여 사용자 계정을 인증합니다.

    gcloud auth application-default login
    

    출력은 다음과 비슷하며 애플리케이션 기본 사용자 인증 정보 파일에 대한 경로를 보여줍니다.

    Credentials saved to file:
    [/tmp/tmp.T5Qae7XwAO/application_default_credentials.json]
    
    These credentials will be used by any library that requests Application Default Credentials (ADC).
    

    애플리케이션 기본 사용자 인증 정보 파일의 경로를 기록해 둡니다. 다음 단계에서 사용합니다.

  5. 다음 환경 변수를 설정합니다.

    APPLICATION_DEFAULT_CREDENTIALS_PATH=ADC_PATH
    BILLING_ACCOUNT_ID=BILLING_ACCOUNT_ID
    DEFAULT_PROJECT=DEFAULT_PROJECT
    DEFAULT_REGION=DEFAULT_REGION
    DEFAULT_ZONE=DEFAULT_ZONE
    GOOGLE_APPLICATION_CREDENTIALS="${APPLICATION_DEFAULT_CREDENTIALS_PATH}"
    MCI_MCS_TUTORIAL_DIRECTORY_PATH="$(pwd)"/solutions-multicluster-gke-migration
    ORGANIZATION_ID=ORGANIZATION_ID
    TERRAFORM_STATE_PROJECT=TERRAFORM_STATE_PROJECT
    export GOOGLE_APPLICATION_CREDENTIALS
    

    다음을 바꿉니다.

    • ADC_PATH: 이전 단계에서 기록해 둔 애플리케이션 기본 사용자 인증 정보 파일의 경로입니다.
    • BILLING_ACCOUNT_ID: 사용하려는 결제 정보의 ID입니다. 결제 계정 ID 목록을 가져오려면 다음을 실행합니다.

      gcloud beta billing accounts list --filter=open=true
      
    • DEFAULT_PROJECT: 이 튜토리얼에 대해 리소스를 프로비저닝하기 위해 사용하려는 클라우드 프로젝트 ID입니다. 나중에 Terraform 스크립트를 실행하여 이 프로젝트를 만듭니다.

    • DEFAULT_REGION: 리소스를 프로비저닝할 기본 리전입니다.

    • DEFAULT_ZONE: 리소스를 프로비저닝할 기본 영역입니다.

    • ORGANIZATION_ID: Google Cloud 조직의 ID입니다. 조직 ID를 찾으려면 다음을 실행합니다.

      gcloud organizations list
      
    • TERRAFORM_STATE_PROJECT: Terraform 상태 정보를 저장하는 데 사용할 클라우드 프로젝트 ID입니다. 나중에 초기화 스크립트를 실행하여 이 프로젝트를 만듭니다. 이 튜토리얼에서 TERRAFORM_STATE_PROJECT 프로젝트는 DEFAULT_PROJECT 프로젝트와 달라야 하지만 두 프로젝트 모두 동일한 조직에 있어야 합니다.

예시 워크로드

이 튜토리얼에서는 도서에 대한 정보를 표시하는 4계층 Polyglot 마이크로서비스 앱인 Bookinfo를 사용합니다. 이 예시 워크로드가 이미 컨테이너화되어 있지만 이 문서 시리즈에 설명된 이 접근 방법은 컨테이너화되지 않은 서비스에도 적용됩니다. 이러한 경우 마이그레이션하려는 서비스를 컨테이너화하는 현대화 단계를 추가할 수 있습니다.

Bookinfo 앱에는 다음 마이크로서비스 구성요소가 포함됩니다.

  • productpage: details, ratings, reviews 마이크로서비스를 호출하여 도서 정보 페이지를 채웁니다.
  • details: 도서 관련 정보를 제공합니다.
  • reviews: 도서 리뷰를 포함합니다.
  • ratings: 도서 리뷰에 첨부할 도서 순위 정보를 반환합니다.

원본 및 대상 환경 프로비저닝

이 섹션에서는 Terraform을 사용하여 원본 및 대상 환경을 자동으로 프로비저닝합니다. Terraform을 사용해서 제안된 변경사항을 적용하여, 다음 태스크를 자동화합니다.

  1. Google Cloud 조직에서 클라우드 프로젝트를 만듭니다.
  2. 필요한 Cloud API를 사용 설정합니다.
  3. 원본 및 대상 환경을 시뮬레이션하기 위해 3개의 리전별 GKE 클러스터를 프로비저닝합니다. GKE 클러스터를 프로비저닝하기 위해 Terraform은 kubernetes-engine Terraform 모듈을 사용합니다.
  4. GKE 클러스터에 대해 워크로드 아이덴티티를 구성합니다.
  5. 멀티 클러스터 Fleet의 일부로 GKE 클러스터를 등록합니다.

제안된 변경사항을 적용하기 위해 다음을 수행합니다.

  1. Cloud Shell에서 작업 디렉터리를 저장소 디렉터리로 변경합니다.

    cd "${MCI_MCS_TUTORIAL_DIRECTORY_PATH}"
    
  2. Terraform 백엔드 구성을 초기화합니다.

    scripts/init-terraform.sh \
      --application-credentials "${APPLICATION_DEFAULT_CREDENTIALS_PATH}" \
      --billing-account-id "${BILLING_ACCOUNT_ID}" \
      --default-project "${DEFAULT_PROJECT}" \
      --default-region "${DEFAULT_REGION}" \
      --default-zone "${DEFAULT_ZONE}" \
      --organization-id "${ORGANIZATION_ID}" \
      --terraform-state-project "${TERRAFORM_STATE_PROJECT}"
    

    init-terraform.sh 스크립트가 다음을 수행합니다.

    1. 프로젝트 및 Cloud Storage 버킷을 만들어 Terraform 상태 정보를 저장합니다.
    2. 설명자를 생성하여 해당 버킷을 원격 백엔드로 사용하도록 Terraform을 구성합니다.
    3. Terraform 작업 디렉터리를 초기화합니다.
  3. 작업 디렉터리를 terraform 디렉터리로 변경합니다.

    cd "${MCI_MCS_TUTORIAL_DIRECTORY_PATH}"/terraform
    
  4. Terraform을 사용하여 변경사항을 적용합니다.

    terraform apply
    

    메시지가 표시되면 제안된 변경사항을 검토합니다. 확인하려면 yes를 입력합니다.

    출력은 다음과 비슷하며, Terraform이 만든 리소스에 대한 세부정보를 보여줍니다.

    Apply complete! Resources: 60 added, 0 changed, 0 destroyed
    

다음 다이어그램은 DEFAULT_REGIONus-central1로 설정된, 이 섹션에 대한 시스템의 대상 아키텍처를 보여줍니다.

GKE 클러스터가 비어 있고 워크로드 배포가 준비되었습니다.

앞의 다이어그램은 기본 리전의 다음 GKE 클러스터를 보여줍니다.

  • source-cluster-1: 원본 환경
  • target-cluster-1target-cluster-2: 대상 환경

GKE 클러스터는 현재 워크로드를 호스팅하지 않으며, 워크로드 배포를 마이그레이션할 준비가 되었습니다.

원본 환경에서 예시 워크로드 배포

이 섹션에서는 원본 환경에서 예시 워크로드를 배포합니다. 예시 워크로드는 대상 환경으로 마이그레이션하는 워크로드를 시뮬레이션합니다.

  1. Cloud Shell에서 작업 디렉터리를 저장소 디렉터리로 변경합니다.

    cd "${MCI_MCS_TUTORIAL_DIRECTORY_PATH}"
    
  2. 원본 환경에서 예시 워크로드를 배포하고 GKE 인그레스를 사용하여 클러스터 외부에서 워크로드를 노출합니다.

    scripts/workloads.sh \
      --cluster-name source-cluster-1 \
      --cluster-region "${DEFAULT_REGION}" \
      --google-cloud-project "${DEFAULT_PROJECT}" \
      --expose-with GKE_INGRESS
    
  3. 예시 워크로드의 Pod가 준비되었는지 확인합니다.

    kubectl get pods --namespace bookinfo
    

    출력은 다음과 비슷합니다. 모든 Pod가 준비되었으면 STATUS 필드에 RUNNING이 표시됩니다.

    NAME                              READY   STATUS    RESTARTS   AGE
    details-v1-79f774bdb9-95khd       1/1     Running   0          43h
    productpage-v1-7b8d9dcc69-95lc6   1/1     Running   0          23h
    ratings-v1-b6994bb9-gt94b         1/1     Running   0          43h
    reviews-v3-674d9bff46-4gl2v       1/1     Running   0          23h
    
  4. 예시 워크로드의 인그레스 객체가 준비되었는지 확인합니다.

    kubectl get ingress --namespace bookinfo
    

    출력은 다음과 비슷하며, 여기에서 IP 열에는 bookinfo 인그레스 객체의 IP 주소가 표시됩니다.

    NAME       CLASS    HOSTS   ADDRESS        PORTS   AGE
    bookinfo   <none>   *       34.117.181.7   80      45h
    
  5. 브라우저에서 다음 URL로 이동합니다. 여기서 EXTERNAL_IP는 이전 단계의 IP 주소입니다.

    http://EXTERNAL_IP/productpage
    

    로드되는 페이지에 도서 및 관련 평점에 대한 정보가 표시됩니다.

환경이 이제 원본 환경을 시뮬레이션하도록 프로비저닝 및 구성되었습니다.

다음 다이어그램은 이 섹션에 설명된 시스템의 대상 아키텍처를 보여줍니다.

예시 워크로드가 소스 GKE 클러스터에 배포되어 있습니다.

앞의 다이어그램은 GKE 클러스터 source-cluster-1에서 실행되는 예시 워크로드와 이 워크로드를 노출하는 부하 분산기를 보여줍니다. GKE 인그레스 객체를 사용하여 Cloud Load Balancing을 구성했습니다. 대상 GKE 클러스터 target-cluster-1target-cluster-2는 워크로드를 호스팅하지 않습니다. 클라이언트는 GKE 인그레스 객체로 구성된 부하 분산기를 통해 워크로드에 액세스합니다.

대상 환경에서 예시 워크로드 배포

이 섹션에서는 대상 환경에서 예시 워크로드를 배포하여 마이그레이션을 시작합니다. 대상 환경에서 대상 워크로드를 준비하면 대상 환경이 클라이언트의 요청을 이행하도록 준비됩니다. 대상 환경에 준비되기 전 워크로드를 노출하면 서비스 중단으로 인해 클라이언트가 문제에 노출될 수 있습니다.

  1. Cloud Shell에서 작업 디렉터리를 저장소 디렉터리로 변경합니다.

    cd "${MCI_MCS_TUTORIAL_DIRECTORY_PATH}"
    
  2. 대상 환경에 대해 target-cluster-1 클러스터에서 예시 워크로드를 배포합니다.

    scripts/workloads.sh \
      --cluster-name target-cluster-1 \
      --cluster-region "${DEFAULT_REGION}" \
      --google-cloud-project "${DEFAULT_PROJECT}"
    
  3. 예시 워크로드의 Pod가 준비되었는지 확인합니다.

    kubectl get pods --namespace bookinfo
    

    출력은 다음과 비슷합니다. 모든 Pod가 준비되었으면 STATUS 필드에 표시되는 값이 RUNNING입니다.

    NAME                              READY   STATUS    RESTARTS   AGE
    details-v1-79f774bdb9-95khd       1/1     Running   0          43h
    productpage-v1-7b8d9dcc69-95lc6   1/1     Running   0          23h
    ratings-v1-b6994bb9-gt94b         1/1     Running   0          43h
    reviews-v3-674d9bff46-4gl2v       1/1     Running   0          23h
    
  4. 대상 환경에서 target-cluster-2 클러스터에 예시 워크로드를 배포합니다.

    scripts/workloads.sh \
      --cluster-name target-cluster-2 \
      --cluster-region "${DEFAULT_REGION}" \
      --google-cloud-project "${DEFAULT_PROJECT}"
    
  5. 예시 워크로드의 Pod가 준비되었는지 확인합니다.

    kubectl get pods --namespace bookinfo
    

    출력은 다음과 비슷합니다. 모든 Pod가 준비되었으면 STATUS 필드에 표시되는 값이 RUNNING입니다.

    NAME                              READY   STATUS    RESTARTS   AGE
    details-v1-79f774bdb9-95khd       1/1     Running   0          43h
    productpage-v1-7b8d9dcc69-95lc6   1/1     Running   0          23h
    ratings-v1-b6994bb9-gt94b         1/1     Running   0          43h
    reviews-v3-674d9bff46-4gl2v       1/1     Running   0          23h
    

다음 다이어그램은 이 섹션에 설명된 시스템의 대상 아키텍처를 보여줍니다.

소스 클러스터가 GKE 인그레스 객체를 사용하여 노출됩니다.

앞의 다이어그램은 GKE 클러스터 source-cluster-1에서 실행되는 예시 워크로드와 이 워크로드를 노출하는 부하 분산기를 보여줍니다. 다이어그램의 아키텍처는 부하 분산기가 GKE 인그레스 객체를 사용하는 데 설정한 구성과 일치합니다. 대상 GKE 클러스터인 target-cluster-1target-cluster-2는 클라이언트 또는 다른 GKE 클러스터에서 실행되는 워크로드에 노출되지 않는 예시 워크로드의 인스턴스를 호스팅합니다. 클라이언트는 GKE 인그레스 객체로 구성된 부하 분산기를 통해 워크로드에 액세스합니다.

멀티 클러스터 인그레스 및 멀티 클러스터 서비스 검색 구성

이 섹션에서는 멀티 클러스터 인그레스 및 멀티 클러스터 서비스 검색을 프로비저닝하고 구성합니다. 멀티 클러스터 인그레스를 사용하면 다중 클러스터 외부에 워크로드를 노출하고, 멀티 클러스터 서비스 검색을 사용하면 다중 클러스터 사이에 워크로드를 노출할 수 있습니다.

  1. Cloud Shell에서 작업 디렉터리를 저장소 디렉터리로 변경합니다.

    cd "${MCI_MCS_TUTORIAL_DIRECTORY_PATH}"
    
  2. 멀티 클러스터 인그레스 및 멀티 클러스터 서비스 검색을 프로비저닝하고 구성합니다.

    scripts/mci-mcs.sh \
      --config-cluster-membership-name "${DEFAULT_REGION}-target-cluster-1" \
      --google-cloud-project "${DEFAULT_PROJECT}"
    

    mci-mcs.sh 스크립트가 다음을 수행합니다.

  3. 멀티 클러스터 인그레스가 올바르게 설정되었는지 확인합니다.

    gcloud alpha container hub ingress describe
    

    출력은 다음과 비슷합니다. 여기서 featureState.details.code 필드에는 OK가 표시됩니다.

    featureState:
      details:
        code: OK
        description: Ready to use
        updateTime: '2021-05-10T12:39:28.378476653Z'
      detailsByMembership:
        projects/324979197388/locations/global/memberships/us-central1-source-cluster-1:
          code: OK
          updateTime: '2021-05-12T09:22:39.420038966Z'
        projects/324979197388/locations/global/memberships/us-central1-target-cluster-1:
          code: OK
          updateTime: '2021-05-12T09:22:39.420038676Z'
        projects/324979197388/locations/global/memberships/us-central1-target-cluster-2:
          code: OK
          updateTime: '2021-05-12T09:22:39.420039116Z'
      hasResources: true
      lifecycleState: ENABLED
    
  4. 멀티 클러스터 서비스 검색이 올바르게 설정되었는지 확인합니다.

    gcloud alpha container hub multi-cluster-services describe
    

    멀티 클러스터 서비스 검색이 준비되려면 몇 분 정도 걸릴 수 있습니다. 준비되었으면 출력이 다음과 비슷합니다. 여기서 featureState code 필드에 표시된 값은 OK입니다.

    featureState:
    detailsByMembership:
      projects/PROJECT/locations/global/memberships/CLUSTER1:
        code: OK
        description: Firewall successfully created.
        updateTime: '2020-09-24T05:16:27.675313587Z'
      projects/PROJECT/locations/global/memberships/CLUSTER2:
        code: OK
        description: Firewall successfully created.
        updateTime: '2020-09-24T05:15:26.665213577Z'
    lifecycleState: ENABLED
    

이제 멀티 클러스터 인그레스 및 멀티 클러스터 서비스 검색이 프로비저닝되고 구성되었습니다.

멀티 클러스터 인그레스를 사용한 워크로드 노출

이 섹션에서는 멀티 클러스터 인그레스를 배포하여 예시 워크로드를 노출합니다.

  1. Cloud Shell에서 작업 디렉터리를 저장소 디렉터리로 변경합니다.

    cd "${MCI_MCS_TUTORIAL_DIRECTORY_PATH}"
    
  2. 멀티 클러스터 인그레스를 사용하여 클러스터 외부에 예시 워크로드를 노출합니다.

    scripts/workloads.sh \
      --cluster-name target-cluster-1 \
      --cluster-region "${DEFAULT_REGION}" \
      --google-cloud-project "${DEFAULT_PROJECT}" \
      --expose-with MCI
    

    workloads.sh 스크립트는 구성 클러스터에서 멀티 클러스터 인그레스 설명자를 배포합니다. 구성 클러스터의 시스템 워크로드가 멀티 클러스터 인그레스의 프로비저닝 및 구성을 처리합니다.

  3. 멀티 클러스터 인그레스가 올바르게 설정되었는지 확인합니다.

    kubectl describe mci productpage --namespace bookinfo
    

    멀티 클러스터 서비스 검색이 준비되려면 몇 분 정도 걸릴 수 있습니다. 준비가 완료되면 출력에 다음과 비슷한 Status 메시지가 표시됩니다.

    Status:
      Cloud Resources:
        Backend Services:
          gkemci-24ipb2-9080-bookinfo-productpage
        Firewalls:
          gkemci-24ipb2-mcs-mci-tutorial-2-workloads-vpc-l7
        Forwarding Rules:
          gkemci-24ipb2-fw-bookinfo-bookinfo-mci
        Health Checks:
          gkemci-24ipb2-9080-bookinfo-productpage
        Network Endpoint Groups:
          zones/us-central1-a/networkEndpointGroups/k8s1-2f4b7c0c-bookinf-mci-productpage-svc-ohon2ru3-908-d8e31dbd
          zones/us-central1-a/networkEndpointGroups/k8s1-c05699ee-bookinf-mci-productpage-svc-ohon2ru3-908-a9236573
          zones/us-central1-a/networkEndpointGroups/k8s1-fa6c2f9b-bookinf-mci-productpage-svc-ohon2ru3-908-8f28ea70
          zones/us-central1-b/networkEndpointGroups/k8s1-2f4b7c0c-bookinf-mci-productpage-svc-ohon2ru3-908-d8e31dbd
          zones/us-central1-b/networkEndpointGroups/k8s1-c05699ee-bookinf-mci-productpage-svc-ohon2ru3-908-a9236573
          zones/us-central1-c/networkEndpointGroups/k8s1-fa6c2f9b-bookinf-mci-productpage-svc-ohon2ru3-908-8f28ea70
          zones/us-central1-f/networkEndpointGroups/k8s1-2f4b7c0c-bookinf-mci-productpage-svc-ohon2ru3-908-d8e31dbd
          zones/us-central1-f/networkEndpointGroups/k8s1-c05699ee-bookinf-mci-productpage-svc-ohon2ru3-908-a9236573
          zones/us-central1-f/networkEndpointGroups/k8s1-fa6c2f9b-bookinf-mci-productpage-svc-ohon2ru3-908-8f28ea70
        Target Proxies:
          gkemci-24ipb2-bookinfo-bookinfo-mci
        URL Map:  gkemci-24ipb2-bookinfo-bookinfo-mci
      VIP:        34.117.121.178
    

    VIP 필드에서 IP 주소를 기록해 둡니다. 이 튜토리얼 전체에 사용됩니다.

  4. 브라우저를 열고 다음 URL로 이동합니다. 여기서 MCI_IP는 이전 단계의 VIP 필드에 있는 IP 주소입니다.

    http://MCI_IP/productpage
    

    페이지가 준비되려면 몇 분 정도 걸릴 수 있습니다. 준비가 완료되면 페이지에 도서 및 관련 평점에 대한 정보가 표시됩니다.

다음 다이어그램은 이 섹션에 설명된 시스템의 대상 아키텍처를 보여줍니다.

대상 클러스터가 멀티 클러스터 인그레스 객체를 사용하여 노출됩니다.

이전 다이어그램은 source-cluster-1, target-cluster-1, target-cluster-2 GKE 클러스터에서 실행되는 예시 워크로드를 보여줍니다. Cloud Load Balancing은 각 GKE 클러스터에서 실행되는 워크로드를 노출합니다. 다이어그램의 아키텍처는 다음과 같이 설정한 구성과 일치합니다.

  • GKE 클러스터 source-cluster-1에서 실행 중인 워크로드는 GKE 인그레스 객체를 사용하는 부하 분산기에서 노출되고, 멀티 클러스터 인그레스를 사용하는 부하 분산기에서 노출됩니다.
  • GKE 클러스터 target-cluster-1target-cluster-2에서 실행되는 워크로드는 멀티 클러스터 인그레스를 사용하는 부하 분산기에서 노출됩니다.

클라이언트는 GKE 인그레스 객체로 구성된 부하 분산기를 통해 워크로드에 액세스합니다.

멀티 클러스터 서비스 검색을 사용하여 워크로드 노출

이 섹션에서는 예시 워크로드를 노출하도록 멀티 클러스터 서비스 검색을 구성합니다.

  1. Cloud Shell에서 작업 디렉터리를 저장소 디렉터리로 변경합니다.

    cd "${MCI_MCS_TUTORIAL_DIRECTORY_PATH}"
    
  2. 멀티 클러스터 서비스 검색을 사용하여 클러스터 target-cluster-1 클러스터 간에 예시 워크로드를 노출합니다.

    scripts/workloads.sh \
      --cluster-name target-cluster-1 \
      --cluster-region "${DEFAULT_REGION}" \
      --google-cloud-project "${DEFAULT_PROJECT}" \
      --expose-with MCI \
      --deploy-mcs
    

    workloads.sh 스크립트는 구성 클러스터에서 멀티 클러스터 서비스 검색을 구성하기 위해 Kubernetes 리소스를 배포합니다. 구성 클러스터의 시스템 워크로드는 멀티 클러스터 서비스 검색 프로비저닝 및 구성을 처리합니다. 멀티 클러스터 서비스 검색을 처음 프로비저닝 및 구성할 때는 약 5분 정도가 걸립니다.

  3. 멀티 클러스터 서비스 검색이 올바르게 설정되었는지 확인합니다.

    kubectl get serviceimport --namespace bookinfo
    

    출력은 다음과 비슷하며, IP 열에는 3개의 ServiceImports 리소스의 IP 주소가 표시됩니다.

    NAME          TYPE           IP                    AGE
    details       ClusterSetIP   ["192.168.115.96"]    41h
    ratings       ClusterSetIP   ["192.168.107.46"]    41h
    reviews       ClusterSetIP   ["192.168.167.69"]    41h
    

    멀티 클러스터 서비스 검색 설정이 완료되었으면 출력에 3개의 ServiceImport 리소스가 포함됩니다. 리소스가 점진적으로 표시되고 모든 항목을 사용할 수 있으려면 몇 분 정도 걸릴 수 있습니다. 출력에 No resources found in bookinfo namespace 오류 메시지가 표시되면 잠시 기다린 후 명령어를 다시 실행합니다.

  4. 멀티 클러스터 서비스 검색을 사용하여 클러스터 target-cluster-2 클러스터 간에 예시 워크로드를 노출합니다.

    scripts/workloads.sh \
      --cluster-name target-cluster-1 \
      --cluster-region "${DEFAULT_REGION}" \
      --google-cloud-project "${DEFAULT_PROJECT}" \
      --expose-with MCI \
      --deploy-mcs
    

    workloads.sh 스크립트가 올바른 GKE 클러스터를 가리키도록 kubectl 컨텍스트를 자동으로 업데이트합니다.

  5. 멀티 클러스터 서비스 검색이 올바르게 설정되었는지 확인합니다.

    kubectl get serviceimport --namespace bookinfo
    

    출력은 다음과 비슷하며, IP 열에는 3개의 ServiceImports 리소스의 IP 주소가 표시됩니다.

    NAME          TYPE           IP                    AGE
    details       ClusterSetIP   ["192.168.115.96"]    41h
    ratings       ClusterSetIP   ["192.168.107.46"]    41h
    reviews       ClusterSetIP   ["192.168.167.69"]    41h
    

    멀티 클러스터 서비스 검색 설정이 완료되었으면 출력에 3개의 ServiceImport 리소스가 포함됩니다. 출력의 각 서비스가 이제 2개의 DNS A 레코드에 매핑됩니다. 여기서 각 [SERVICE_NAME] 값은 출력에 있는 ServiceImports 리소스 이름 중 하나입니다.

    • [SERVICE_NAME].bookinfo.svc.cluster.local 리소스는 서비스가 있는 클러스터에 로컬인 ClusterIP로 확인됩니다.
    • [SERVICE_NAME].bookinfo.svc.clusterset.local 리소스는 멀티 클러스터 서비스 검색을 가리키는 ClusterSetIP로 확인됩니다.
  6. 멀티 클러스터 서비스 검색을 사용하도록 target-cluster-1 클러스터에서 실행되는 예시 워크로드 Pod를 업데이트하고 다시 시작합니다.

    scripts/workloads.sh \
      --cluster-name target-cluster-1 \
      --cluster-region "${DEFAULT_REGION}" \
      --google-cloud-project "${DEFAULT_PROJECT}" \
      --consume-mcs
    
  7. 예시 워크로드의 Pod가 준비되었는지 확인합니다.

    kubectl get pods --namespace bookinfo
    

    출력은 다음과 비슷합니다. 모든 Pod가 준비되었으면 STATUS 필드에 표시되는 값이 RUNNING입니다.

    NAME                              READY   STATUS    RESTARTS   AGE
    details-v1-79f774bdb9-95khd       1/1     Running   0          43h
    productpage-v1-7b8d9dcc69-95lc6   1/1     Running   0          23h
    ratings-v1-b6994bb9-gt94b         1/1     Running   0          43h
    reviews-v3-674d9bff46-4gl2v       1/1     Running   0
    
  8. 멀티 클러스터 서비스 검색을 사용하도록 target-cluster-2 클러스터에서 실행되는 예시 워크로드 Pod를 업데이트합니다.

    scripts/workloads.sh \
      --cluster-name target-cluster-2 \
      --cluster-region "${DEFAULT_REGION}" \
      --google-cloud-project "${DEFAULT_PROJECT}" \
      --consume-mcs
    
  9. 예시 워크로드의 Pod가 준비되었는지 확인합니다.

    kubectl get pods --namespace bookinfo
    

    출력은 다음과 비슷합니다. 모든 Pod가 준비되었으면 STATUS 필드에 표시되는 값이 RUNNING입니다.

    NAME                              READY   STATUS    RESTARTS   AGE
    details-v1-79f774bdb9-95khd       1/1     Running   0          43h
    productpage-v1-7b8d9dcc69-95lc6   1/1     Running   0          23h
    ratings-v1-b6994bb9-gt94b         1/1     Running   0          43h
    reviews-v3-674d9bff46-4gl2v       1/1     Running   0
    
  10. 브라우저를 열고 다음 URL로 이동합니다. 여기서 MCI_IP는 이 튜토리얼의 앞 부분에서 멀티 클러스터 인그레스를 사용하여 워크로드를 노출했을 때 기록해 둔 VIP 주소입니다.

    http://MCI_IP/productpage
    

    도서 및 관련 평점에 대한 정보가 있는 페이지가 표시됩니다.

대상 환경에서만 멀티 클러스터 서비스 검색을 사용하는 멀티 클러스터 서비스 검색 및 Pod를 배포합니다. 이 방법을 사용하면 대상 환경을 검증할 때까지 원본 환경에 변경사항이 적용되지 않습니다. 또한 마이그레이션 동안 클라이언트에 영향을 주지 않고, 다운타임을 최소한으로 줄여줍니다.

다음 다이어그램은 이 섹션에 설명된 시스템의 대상 아키텍처를 보여줍니다.

대상 클러스터가 멀티 클러스터 서비스 검색을 사용하여 교차 노출됩니다.

이전 다이어그램은 source-cluster-1, target-cluster-1, target-cluster-2 GKE 클러스터에서 실행되는 예시 워크로드를 보여줍니다. Cloud Load Balancing은 각 GKE 클러스터에서 실행되는 워크로드를 노출합니다. 다이어그램의 아키텍처는 다음과 같이 설정한 구성과 일치합니다.

  • GKE 클러스터 source-cluster-1에서 실행 중인 워크로드는 GKE 인그레스 객체를 사용하는 부하 분산기에서 노출되고, 멀티 클러스터 인그레스를 사용하는 부하 분산기에서 노출됩니다.
  • GKE 클러스터 target-cluster-1target-cluster-2에서 실행되는 워크로드는 멀티 클러스터 인그레스를 사용하는 부하 분산기에서 노출됩니다.
  • 멀티 클러스터 서비스 검색은 GKE 클러스터 target-cluster-1에서 실행되는 워크로드를 GKE 클러스터 target-cluster-2에 노출하고 반대 방향으로도 노출하도록 구성됩니다.

클라이언트는 GKE 인그레스 객체로 구성된 부하 분산기를 통해 워크로드에 액세스합니다.

대상 환경으로 트래픽 전환

이 시점에서 클라이언트는 다음 방법으로 예시 워크로드에 연결될 수 있습니다.

  • 원본 환경에서 예시 워크로드를 노출하는 GKE 인그레스 객체를 사용합니다.
  • 멀티 클러스터 인그레스를 사용하고, 대상 환경의 여러 클러스터에서 예시 워크로드를 노출합니다.

일반적인 프로덕션 환경에서 클라이언트는 DNS 레코드를 사용하여 bookinfo GKE 인그레스 객체가 만든 HTTP 부하 분산기의 IP 주소를 확인할 수 있습니다. 예를 들어 클라이언트는 bookinfo.example.com DNS A 레코드를 사용하여 GKE 인그레스를 사용해서 만든 부하 분산기의 IP 주소를 확인할 수 있습니다.

대상 환경이 요구사항을 충족하는지 검증한 후 멀티 클러스터 인그레스 VIP 주소를 가리키도록 bookinfo.example.com DNS A 레코드를 업데이트할 수 있습니다. 이 업데이트는 클라이언트가 대상 환경의 워크로드를 가리키도록 만듭니다. 이 DNS 기반 마이그레이션 전략을 구현하려면 먼저 DNS 클라이언트가 DNS 레코드의 TTL(수명)을 준수하는지 확인해야 합니다. 동작이 잘못된 DNS 클라이언트는 DNS 레코드에 대한 업데이트를 무시하고 오래된 캐시 값을 대신 사용할 수 있습니다. 이러한 DNS 기반 마이그레이션 전략은 부분 트래픽 이동 또는 트래픽 미러링과 같은 점진적인 마이그레이션 전략을 구현하기 위한 고급 트래픽 관리 기능을 지원하지 않습니다. 트래픽 관리 기능을 지원하는 대안에 대한 자세한 내용은 런타임 플랫폼 및 환경 평가를 참조하세요.

이 DNS 기반 마이그레이션 전략을 구현하려면 Cloud DNS를 사용하여 DNS 레코드를 관리할 수 있습니다. Terraform으로 Cloud DNS 리소스를 프로비저닝하려면 google_dns_managed_zonegoogle_dns_record_set를 참조하세요.

이 문서에서 GKE 인그레스 및 멀티 클러스터 인그레스는 2개의 서로 다른 고정 IP 주소를 사용합니다. 워크로드가 컷오버 기간으로 인한 최소한의 다운타임을 감당할 수 있으면 GKE 인그레스를 먼저 삭제한 후 GKE 인그레스 객체에 사용된 고정 IP 주소를 사용하도록 멀티 클러스터 인그레스를 구성할 수 있습니다. 멀티 클러스터 인그레스에 대해 GKE 인그레스 고정 IP 주소를 다시 사용하면 최소한의 다운타임이 추가되지만 DNS 레코드 변경을 방지할 수 있습니다.

다음 다이어그램은 이 섹션에 설명된 시스템의 대상 아키텍처를 보여줍니다.

트래픽이 멀티 클러스터 인그레스로 구성된 Cloud Load Balancing을 통해 대상 환경에 액세스합니다.

이전 다이어그램은 source-cluster-1, target-cluster-1, target-cluster-2 GKE 클러스터에서 실행되는 예시 워크로드를 보여줍니다. Cloud Load Balancing은 각 GKE 클러스터에서 실행되는 워크로드를 노출합니다. 다이어그램의 아키텍처는 다음과 같이 설정한 구성과 일치합니다.

  • GKE 클러스터 source-cluster-1에서 실행 중인 워크로드는 GKE 인그레스 객체를 사용하는 부하 분산기에서 노출되고, 멀티 클러스터 인그레스를 사용하는 부하 분산기에서 노출됩니다.
  • GKE 클러스터 target-cluster-1target-cluster-2에서 실행되는 워크로드는 멀티 클러스터 인그레스를 사용하는 부하 분산기에서 노출됩니다.
  • 멀티 클러스터 서비스 검색은 GKE 클러스터 target-cluster-1에서 실행되는 워크로드를 GKE 클러스터 target-cluster-2에 노출하고 반대 방향으로도 노출하도록 구성됩니다.

클라이언트는 멀티 클러스터 인그레스로 구성된 부하 분산기를 통해 워크로드에 액세스합니다.

원본 환경 사용 중단

이 섹션에서는 원본 환경을 사용 중단합니다. 계속하기 전에 원본 환경이 클라이언트 요청을 더 이상 처리하지 않는지 확인합니다. 이렇게 하려면 Network Telemetry를 사용하여 원본 환경의 클러스터 로그에 액세스합니다. 모든 클라이언트가 대상 환경으로 전환되었는지 확인되었으면 다음 단계를 수행합니다.

  1. Cloud Shell에서 작업 디렉터리를 저장소 디렉터리로 변경합니다.

    cd "${MCI_MCS_TUTORIAL_DIRECTORY_PATH}"
    
  2. source-cluster-1 클러스터에서 리소스를 삭제합니다.

    gcloud container clusters get-credentials source-cluster-1 --region="${DEFAULT_REGION}" \
    && kubectl delete namespace bookinfo --wait
    
  3. 작업 디렉터리를 terraform 디렉터리로 변경합니다.

    cd "${MCI_MCS_TUTORIAL_DIRECTORY_PATH}"/terraform
    
  4. 원본 환경의 클러스터를 Fleet에서 등록 해제하고 삭제합니다.

    terraform destroy -target module.gke-and-hub-source
    

다음 다이어그램은 이 섹션에 설명된 시스템의 대상 아키텍처를 보여줍니다.

대상 클러스터 및 원본 클러스터에서 실행되는 워크로드가 사용 중단됩니다.

이전 다이어그램은 구성된 아키텍처를 보여줍니다. 여기서 예시 워크로드는 GKE 클러스터 target-cluster-1target-cluster-2에서 실행됩니다. source-cluster-1 클러스터가 사용 중단됩니다. 클라이언트는 멀티 클러스터 인그레스로 구성된 부하 분산기를 통해 워크로드에 액세스합니다.

삭제

이 튜토리얼에서 사용한 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 만든 리소스 및 프로젝트를 모두 삭제합니다.

리소스 및 프로젝트 삭제

Cloud Shell에서 다음을 실행합니다.

  1. 작업 디렉터리를 저장소 디렉터리로 변경합니다.

    cd "${MCI_MCS_TUTORIAL_DIRECTORY_PATH}"
    
  2. 프로비저닝한 리소스를 삭제합니다.

    scripts/cleanup.sh \
      --google-cloud-project "${DEFAULT_PROJECT}" \
      --cluster-region "${DEFAULT_REGION}" \
      --terraform-state-project "${TERRAFORM_STATE_PROJECT}"
    

다음 단계