Istio 1.7 이상에서 Anthos Service Mesh 및 Mesh CA로 마이그레이션

이 문서에서는 Google Kubernetes Engine(GKE) 관리자가 Anthos Service Mesh를 설치하고 현재 Istio 서비스 메시를 사용하여 현재 실행 중인 워크로드를 마이그레이션하는 방법을 설명합니다. 배포된 Anthos Service Mesh 구성에는 원격 분석을 사용되는 Cloud Monitoring과 관리형 고가용성 메시 인증서 관리에 사용되는 Anthos Service Mesh 인증 기관(Mesh CA)이 포함됩니다. 메시 토폴로지를 정의하는 게이트웨이, 가상 서비스, 기타 메시 구성은 마이그레이션에 보존됩니다.

이 프로세스는 단일 클러스터 설치를 다룹니다. 멀티 클러스터 메시 설치는 설치 후 Anthos Service Mesh에 클러스터를 추가하는 단계가 포함된 GKE에서 멀티 클러스터 메시 설정을 참조하세요.

이 문서의 단계를 완료하려면 GKE 클러스터에서 Istio 1.7 이상을 사용해야 합니다. Anthos Service Mesh는 설치 또는 구성에 Helm을 지원하지 않습니다. 메시 관리자는 메시 구성에 IstioOperator API를 사용하는 것이 좋습니다. 이 프로세스에서는 인증 기관을 전환하는 동안 애플리케이션에 다운타임이 발생할 수 있으므로 예정된 유지보수 기간 중에 이 프로세스를 수행하는 것이 좋습니다.

Anthos Service Mesh는 동일한 Istio 및 Envoy API를 사용하여 메시를 구성하므로 기존 리소스를 변경할 필요가 없습니다.

마이그레이션 후의 구현 차이점은 다음과 같습니다.

  • Istio 제어 영역은 Anthos Service Mesh 제어 영역으로 대체됩니다.

  • Citadel 인증 기관은 삭제되며 인증서는 Google Cloud Mesh CA 서비스에서 관리됩니다.

  • 원격 분석은 Cloud Logging 및 Cloud Monitoring으로 전송됩니다. Google Cloud Console에서 대시보드와 SLO 관리를 사용할 수 있습니다.

  • 맞춤설정된 IstioOperator 리소스가 있으면 스크립트에서 이를 입력으로 사용할 수 있습니다.

  • 오픈소스 Istio 설치(버전 1.7 이상)는 Mesh CA와 함께 Anthos Service Mesh 버전 1.10으로 마이그레이션됩니다. 다른 버전의 Istio가 있거나 다른 버전의 Anthos Service Mesh가 필요한 경우 또는 Google 관리 제어 영역을 사용하여 Anthos Service Mesh를 배포하려면 Istio에서 마이그레이션 준비를 참조하세요.

기본 요건

이 가이드를 완료하려면 다음 기본 요건이 충족되어야 합니다.

  • Istio 버전 1.7 이상이 설치된 GKE 클러스터가 있습니다. GKE 클러스터가 없거나 새(테스트) 클러스터에서 이 가이드를 먼저 테스트하려면 부록의 단계를 따라 테스트 애플리케이션을 사용하여 Istio 버전 1.7 이상에서 새 GKE 클러스터를 만듭니다.

  • 이 가이드는 Cloud Shell에서 테스트되었으므로 Cloud Shell을 사용하여 이 가이드의 단계를 수행합니다.

목표

이 가이드에서는 마이그레이션 경로를 선택합니다. 한 번에 스크립트된 경로나 단계별 스크립트된 마이그레이션 중에서 선택할 수 있습니다.

자세한 내용은 마이그레이션 경로 선택을 참조하세요.

이 마이그레이션에 대해 자주 묻는 질문(FAQ)의 답변을 보려면 Istio 1.7 이상에서 Anthos Service Mesh 및 Mesh CA FAQ로 마이그레이션를 참조하세요.

시작하기 전에

이 가이드에서는 Istio가 설치된 GKE 클러스터에 대한 관리 액세스 권한이 필요합니다. 마이그레이션 프로세스 중에 애플리케이션 동작 방식을 관찰하려면 먼저 개발 또는 스테이징 환경의 클러스터 하나에서 이 프로세스를 수행하는 것이 좋습니다.

Anthos Service Mesh 요구사항은 다음과 같습니다. 이를 사용자가 수동으로 직접 수행하거나 사전 설치 프로세스 중에 제공된 도구에서 사용자를 대신해 종속 항목을 사용 설정하도록 허용할 수 있습니다.

  1. 다음 Google Cloud API를 사용 설정합니다.

    • container.googleapis.com
    • meshca.googleapis.com
    • meshconfig.googleapis.com
    • gkehub.googleapis.com
    • stackdriver.googleapis.com

  2. GKE 클러스터에 워크로드 아이덴티티와 Stackdriver를 사용 설정합니다.

  3. 클러스터에 라벨을 지정하여 서비스 사용자 인터페이스를 사용 설정합니다.

  4. Kubernetes 클러스터에서 클러스터 관리자 권한을 가져옵니다.

  5. Fleet에 클러스터를 등록합니다.

  6. Fleet에 servicemesh 기능을 사용 설정합니다.

환경 설정

환경을 설정하려면 다음 단계를 수행합니다.

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

    Cloud Shell 활성화

    Google Cloud 콘솔 페이지 하단에서 Cloud Shell 세션이 시작되고 명령줄 프롬프트가 표시됩니다. Cloud Shell은 Google Cloud CLI가 사전 설치된 셀 환경으로, 현재 프로젝트의 값이 이미 설정되어 있습니다. 세션이 초기화되는 데 몇 초가 걸릴 수 있습니다.

  2. 이 가이드에서 사용되는 환경 변수를 만듭니다.

    export PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}
export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
export CLUSTER_NAME=GKE_CLUSTER_NAME
export CLUSTER_LOCATION=GKE_CLUSTER_REGION_OR_ZONE

  3. WORKDIR 폴더를 만듭니다.

    mkdir -p migrate-to-asm-working-dir && cd migrate-to-asm-working-dir && export WORKDIR=`pwd`

  4. 이 가이드에 사용할 KUBECONFIG 파일을 만듭니다.

    touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig

  5. GKE 클러스터에 연결합니다.

    영역 클러스터

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
   --zone ${CLUSTER_LOCATION}

    리전 클러스터

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
   --region ${CLUSTER_LOCATION}

  6. 마이그레이션 스크립트를 다운로드합니다.

    curl -LO https://storage.googleapis.com/csm-artifacts/asm/migrate-to-asm
chmod +x ./migrate-to-asm

마이그레이션 경로 선택

Anthos Service Mesh로 마이그레이션할 경로 두 개 중 하나를 선택할 수 있습니다. 다음 두 전략 중 하나만 선택한 후 해당 섹션으로 진행합니다.

  • Anthos Service Mesh로 한 번에 마이그레이션. 이름에서 알 수 있듯이 단일 명령어를 사용하여 Anthos Service Mesh로 마이그레이션하는 데 필요한 모든 단계를 수행할 수 있습니다. 클러스터 수가 많고 Anthos Service Mesh로 빠르고 쉽게 업그레이드해야 하는 경우에 유용할 수 있습니다. 그러나 이 방법을 사용하면 애플리케이션 다운타임이 발생할 수 있습니다.

  • Anthos Service Mesh로 단계별 마이그레이션. 이 방법을 사용하면 각 단계를 더 세부적으로 제어할 수 있으며 Anthos Service Mesh로 마이그레이션하는 데 필요한 항목을 정확하게 이해할 수 있습니다.

Anthos Service Mesh로 한 번에 마이그레이션

이 섹션에서는 현재 Istio 버전 1.7(이상) 설치를 Anthos Service Mesh 버전 1.10으로 마이그레이션합니다. 이 섹션에서는 단일 단계를 실행하여 마이그레이션을 수행할 수 있습니다. 일련의 단계를 실행하여 마이그레이션을 수행하려면 Anthos Service Mesh로 단계별 마이그레이션 섹션을 참조하세요.

Anthos Service Mesh로 마이그레이션하려면 다음 명령어를 실행합니다. 모든 명령어로 --dry-run 플래그를 사용하여 명령어를 실행하는 대신 명령어를 출력하거나 --verbose 플래그를 사용하여 스크립트에서 명령어를 실행하는 동안 출력할 수 있습니다. 이전에 종속 항목을 구성한 경우 시작하기 전에 섹션의 설명대로 --enable-dependencies 플래그를 생략할 수 있습니다.

커스텀 리소스 없음

커스텀 IstioOperator 리소스를 사용하지 마세요.

./migrate-to-asm migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies \
    --verbose

커스텀 리소스 사용

커스텀 IstioOperator 리소스를 사용합니다.

export ISTIO_OPERATOR_FILEPATH=PATH_OF_ISTIO_OPERATOR_YAML_FILE

./migrate-to-asm migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies \
    --custom_overlay ${ISTIO_OPERATOR_FILEPATH} \
    --verbose

이 명령어는 다음 단계를 수행합니다.

  • Istio 버전이 1.7 이상인지 확인합니다.
  • 클러스터에서 워크로드 아이덴티티를 사용 설정합니다. Mesh CA에 워크로드 아이덴티티가 필요합니다. 기존 노드 풀에서 GKE 메타데이터 서버를 사용 설정할 필요가 없습니다.
  • Anthos Service Mesh에 필수 API를 사용 설정합니다.
  • 클러스터를 Fleet에 등록합니다.
  • 필수 라벨로 클러스터를 업데이트합니다.
  • 지정된 클러스터에 Google 관리 제어 영역이 더 효과적일지 평가합니다.
  • 최적의 제어 영역 구성으로 Anthos Service Mesh를 배포합니다.
  • 모든 Istio 지원 네임스페이스의 라벨을 필수 Anthos Service Mesh 라벨로 다시 지정합니다.
  • 워크로드가 새 Anthos Service Mesh 프록시를 가져오도록 모든 Anthos Service Mesh 지원 네임스페이스에서 워크로드를 다시 시작합니다.
  • Istio 제어 영역을 삭제합니다.

Anthos Service Mesh로 단계별 마이그레이션

이 섹션에서는 Istio 버전 1.7(이상) 설치를 Anthos Service Mesh 버전 1.10으로 마이그레이션합니다. 이 섹션을 통해 일련의 단계를 실행하여 마이그레이션을 수행할 수 있습니다. 한 번에 마이그레이션을 수행하려면 Anthos Service Mesh로 한 번에 마이그레이션 섹션을 참조하세요.

Anthos Service Mesh로 마이그레이션하려면 다음 단계가 필요합니다.

  1. 마이그레이션 전 단계를 수행하여 Anthos Service Mesh로 마이그레이션할 클러스터와 환경을 검증하고 준비합니다.
  2. 기존 Istio 제어 영역과 함께 카나리아 제어 영역으로 Anthos Service Mesh를 설치하고 워크로드를 준비합니다.
  3. Anthos Service Mesh에서 워크로드를 테스트하고 Anthos Service Mesh 사이드카 삽입의 네임스페이스 라벨을 다시 지정합니다.
  4. Anthos Service Mesh 대시보드에 액세스하고 검사합니다.
  5. Istio 아티팩트를 정리하거나 기존 Istio 버전으로 롤백합니다.

마이그레이션 전 단계 수행

마이그레이션하기 전 단계에서 다음 작업을 수행합니다.

  • 프로젝트와 클러스터 정보가 올바르고 설치된 Istio 버전이 마이그레이션과 호환되는지 검증합니다.

  • 기본 게이트웨이의 구성과 현재 Istio 서비스 메시의 라벨을 백업합니다.

  • --enable-dependencies 플래그를 사용하면 사용자를 대신하여 종속 항목을 사용 설정합니다. 그렇지 않으면 종속 항목이 사용 설정되어 있는지 확인합니다.

사전 마이그레이션 스크립트는 현재 디렉터리에 configuration_backup이라는 새 폴더를 만들거나 기존 폴더를 덮어씁니다.

마이그레이션 전 단계를 수행하려면 다음 명령어를 실행합니다.

종속 항목

종속 항목을 사용 설정합니다.

./migrate-to-asm pre-migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies

종속 항목 없음

종속 항목을 사용 설정하지 마세요.

./migrate-to-asm pre-migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID

출력은 다음과 비슷합니다.

    migrate-to-asm: Checking installation tool dependencies...
    migrate-to-asm: Checking for $PROJECT_ID...
    migrate-to-asm: Confirming cluster information for $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
    migrate-to-asm: Confirming node pool requirements for $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
    migrate-to-asm: Checking existing Istio version(s)...
    migrate-to-asm:   1.9.5
    migrate-to-asm: No version issues found.
    migrate-to-asm: Enabling required APIs...
    migrate-to-asm:
    migrate-to-asm: APIs enabled.
    migrate-to-asm: Enabling the service mesh feature...
    migrate-to-asm:
    migrate-to-asm: The service mesh feature is already enabled.
    migrate-to-asm: Enabling Stackdriver on $LOCATION/$CLUSTER_NAME...
    Updating $CLUSTER_NAME...
    .........................done.
    Updated [https://container.googleapis.com/v1/projects/$PROJECT_ID/zones/$LOCATION/clusters/$CLUSTER_NAME].
    To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/$LOCATION/$CLUSTER_NAME?project=$PROJECT_ID
    migrate-to-asm:
    migrate-to-asm: Stackdriver enabled.
    migrate-to-asm: Querying for core/account...
    migrate-to-asm: Binding user@example.com to cluster admin role...
    migrate-to-asm:
    migrate-to-asm:
    migrate-to-asm: Successfully bound to cluster admin role.
    migrate-to-asm: Initializing meshconfig API...
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
    100     3    0     3    0     0      6      0 --:--:-- --:--:-- --:--:--     6
    migrate-to-asm:
    migrate-to-asm: Finished pre-migration!

Anthos Service Mesh 설치 및 워크로드 준비

이 단계에서는 다음을 수행합니다.

  • configuration_backup 폴더가 있는지 확인합니다. 없으면 마이그레이션 전 도구가 성공적으로 실행되었는지 확인되지 않습니다.
  • 클러스터 및 메시 구성에 대한 분석을 토대로 Anthos Service Mesh 제어 영역을 설치하고 구성합니다.
  • 커스텀 IstioOperator 리소스가 제공되면 이 리소스를 사용합니다. IstioOperator 리소스를 사용하여 구성한 커스텀 게이트웨이나 여러 게이트웨이가 있는 경우 이 단계에서 동일한 리소스를 사용합니다.

분석을 건너뛰고 클러스터 리소스를 사용해 실행되는 비관리형 제어 영역을 설치하도록 도구를 강제로 적용하려면 명령어에 --no-mcp 플래그를 추가합니다.

Anthos Service Mesh를 설치할 때 다음 세 가지 경로 중 하나를 선택할 수 있습니다.

  • 옵션 1: 커스텀 IstioOperator 리소스를 사용하지 않음. 커스텀 리소스를 사용하지 않고 Anthos Service Mesh를 설치할 수 있습니다. 이 옵션을 사용하면 Istio의 기본 구성이 설치되고 기본 istio-ingressgateway가 업데이트됩니다.

  • 옵션 2: --no-gateways 옵션 사용. 커스텀 IstioOperator 리소스를 사용하지 않고 Anthos Service Mesh를 설치할 때 --no-gateways 옵션을 사용하면 기본 istio-ingressgateway가 즉시 업데이트되지 않습니다. 이 옵션을 사용하는 경우 설치 후 게이트웨이를 수동으로 업그레이드해야 합니다.

  • 옵션 3: 커스텀 IstioOperator 리소스 사용. 커스텀 IstioOperator 리소스를 사용하여 Anthos Service Mesh를 설치할 수 있습니다. 커스텀 IstioOperator 리소스를 사용하여 Istio를 배포한 경우 Anthos Service Mesh를 설치할 때 동일한 IstioOperator 리소스를 사용하는 것이 좋습니다.

Anthos Service Mesh를 설치하려면 다음 명령어 중 하나를 실행합니다.

옵션 1

기본 istio-ingressgateway를 즉시 업그레이드합니다.

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

옵션 2

기본 istio-ingressgateway를 즉시 업그레이드하지 마세요.

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID \
     --no-gateways

옵션 3

커스텀 IstioOperator 리소스를 사용하여 게이트웨이를 즉시 업그레이드합니다.

 export ISTIO_OPERATOR_FILEPATH=PATH_OF_ISTIO_OPERATOR_YAML_FILE

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID \
     --custom-overlay ${ISTIO_OPERATOR_FILEPATH}

출력은 다음과 비슷합니다.

 migrate-to-asm: Checking installation tool dependencies...
 migrate-to-asm: Checking for $PROJECT_ID...
 migrate-to-asm: Fetching/writing Google Cloud credentials to kubeconfig file...
 Fetching cluster endpoint and auth data.
 kubeconfig entry generated for $CLUSTER_NAME.
 migrate-to-asm:
 migrate-to-asm: Verifying connectivity (20s)...
 migrate-to-asm: kubeconfig set to $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
 migrate-to-asm: Configuring kpt package...
 asm/
 set 20 field(s) of setter "gcloud.container.cluster" to value "$CLUSTER_NAME"
 asm/
 set 28 field(s) of setter "gcloud.core.project" to value "$PROJECT_ID"
 asm/
 set 2 field(s) of setter "gcloud.project.projectNumber" to value "42"
 asm/
 set 5 field(s) of setter "gcloud.project.environProjectNumber" to value "42"
 asm/
 set 20 field(s) of setter "gcloud.compute.location" to value "$LOCATION"
 asm/
 set 1 field(s) of setter "gcloud.compute.network" to value "$PROJECT_ID-default"
 asm/
 set 6 field(s) of setter "anthos.servicemesh.rev" to value "asm-1102-2"
 asm/
 set 5 field(s) of setter "anthos.servicemesh.tag" to value "1.10.2-asm.2"
 asm/
 set 4 field(s) of setter "anthos.servicemesh.hubTrustDomain" to value "$PROJECT_ID.svc.id.goog"
 asm/
 set 2 field(s) of setter "anthos.servicemesh.hub-idp-url" to value "https://container.googleapis.com/v1/projects/$PROJECT_ID/locations/$LOCATION/clusters/$CLUSTER_NAME"
 asm/
 set 4 field(s) of setter "anthos.servicemesh.trustDomainAliases" to value "$PROJECT_ID.svc.id.goog"
 migrate-to-asm: Configured.
 migrate-to-asm: Installing Anthos Service Mesh control plane...
 migrate-to-asm:
 - Processing resources for Istio core.
 ✔ Istio core installed
 - Processing resources for Istiod.
 - Processing resources for Istiod. Waiting for Deployment/istio-system/istiod-asm-1102-2
 ✔ Istiod installed
 - Processing resources for CNI, Ingress gateways.
 - Processing resources for CNI, Ingress gateways. Waiting for Deployment/istio-system/istio-ingressgateway
 ✔ CNI installed
 - Processing resources for Ingress gateways. Waiting for Deployment/istio-system/istio-ingressgateway
 ✔ Ingress gateways installed
 - Pruning removed resources
 migrate-to-asm:
 migrate-to-asm:
 namespace/asm-system created
 customresourcedefinition.apiextensions.k8s.io/canonicalservices.anthos.cloud.google.com configured
 role.rbac.authorization.k8s.io/canonical-service-leader-election-role created
 clusterrole.rbac.authorization.k8s.io/canonical-service-manager-role configured
 clusterrole.rbac.authorization.k8s.io/canonical-service-metrics-reader unchanged
 serviceaccount/canonical-service-account created
 rolebinding.rbac.authorization.k8s.io/canonical-service-leader-election-rolebinding created
 clusterrolebinding.rbac.authorization.k8s.io/canonical-service-manager-rolebinding unchanged
 clusterrolebinding.rbac.authorization.k8s.io/canonical-service-proxy-rolebinding unchanged
 service/canonical-service-controller-manager-metrics-service created
 deployment.apps/canonical-service-controller-manager created
 deployment.apps/canonical-service-controller-manager condition met
 migrate-to-asm:
 migrate-to-asm:
 migrate-to-asm: *******
 migrate-to-asm: Control plane installation complete!

워크로드 다시 삽입 및 애플리케이션 동작 확인

이제 Anthos Service Mesh 제어 영역이 워크로드를 처리할 수 있지만 기존 워크로드는 계속 기존 Istio 제어 영역에서 관리됩니다. 이러한 워크로드를 마이그레이션하려면 현재 Anthos Service Mesh 버전 라벨을 사용하여 Istio 삽입으로 라벨이 지정된 Kubernetes 네임스페이스의 라벨을 지정해야 합니다. 그런 다음 네임스페이스에서 워크로드를 다시 시작해야 합니다. 수동으로(1단계의 참고 확인) 또는 도구를 사용하여 한 번에 이 작업을 수행할 수 있습니다.

라벨 다시 지정 단계는 다음과 같습니다.

  • 현재 Istio 삽입 라벨을 사용하는 모든 네임스페이스를 찾습니다.
  • 네임스페이스 라벨을 istio.io/rev=asm-1102-2로 다시 지정합니다.
  • 네임스페이스에서 워크로드를 다시 시작합니다.

워크로드를 다시 삽입하려면 다음 단계를 수행합니다.

  1. 다음 명령어를 실행하여 모든 Istio 지원 네임스페이스의 라벨을 다시 지정하고 워크로드를 다시 시작합니다.

     ./migrate-to-asm relabel \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

    출력은 다음과 비슷합니다.

    migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for $PROJECT_ID...
migrate-to-asm: Fetching/writing Google Cloud credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for $CLUSTER_NAME.
migrate-to-asm:
migrate-to-asm: Verifying connectivity (20s)...
migrate-to-asm: kubeconfig set to $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
******
migrate-to-asm: Installation of Anthos Service Mesh has completed. Migration will continue
migrate-to-asm: by relabeling and restarting workloads in the following namespaces:
migrate-to-asm:     namespace/default
migrate-to-asm:
Continue with migration? (Y/n)Y
migrate-to-asm: Relabeling namespace/default...
namespace/default labeled
migrate-to-asm: Restarting workloads in namespace/default and waiting for them to become available (max 5 min)...
deployment.apps/frontend restarted
deployment.apps/backend restarted
deployment.apps/frontend condition met
deployment.apps/backend condition met
migrate-to-asm: *******
migrate-to-asm: Finished restarting workloads!

  2. 모든 배포가 다시 시작될 때까지 기다린 후 다음 명령어를 실행하여 데이터 영역의 버전을 확인합니다.

    istioctl version

    출력은 다음과 비슷합니다.

    client version: 1.8.0
pilot version: 1.9.5
istiod version: 1.10.2-asm.2
data plane version: 1.10.2-asm.2 (14 proxies)

  3. 다시 시작한 후에 애플리케이션이 올바르게 작동하는지 확인합니다.

Anthos Service Mesh 대시보드에 액세스

이 섹션에서는 Anthos Service Mesh 대시보드로 이동하여 모든 서비스의 골든 신호를 수신하는지 확인합니다. 또한 애플리케이션 토폴로지를 확인할 수 있어야 합니다.

  1. Google Cloud 콘솔에서 Anthos Service Mesh 페이지로 이동합니다.

    Anthos Service Mesh로 이동

  2. 서비스의 측정항목과 토폴로지를 볼 수 있어야 합니다.

Anthos Service Mesh 대시보드에 대한 자세한 내용은 Google Cloud 콘솔에서 Anthos Service Mesh 탐색을 참조하세요.

마이그레이션 완료

마이그레이션을 완료하기 전에 모든 애플리케이션이 올바르게 작동하는지 확인합니다. 마이그레이션을 완료한 후에는 기존 Istio 버전으로 롤백할 수 없습니다. 마이그레이션을 마무리하려면 다음 단계를 수행합니다.

  • 클러스터에서 실행 중인 모든 프록시가 Anthos Service Mesh를 사용하고 있는지 확인합니다.
  • 클러스터에서 사용되지 않는 Istio 구성요소를 삭제합니다. 이 단계를 되돌릴 수 없습니다.

Anthos Service Mesh로 마이그레이션을 완료하려면 다음 명령어를 실행합니다.

 ./migrate-to-asm finalize \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID
출력은 다음과 비슷합니다. 
migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for asm-scriptaro-oss...
migrate-to-asm: All proxies running Anthos Service Mesh!
Remove previous control plane resources? (Y/n)
migrate-to-asm: ****
migrate-to-asm: Previous Istio control plane has been removed.

기존 Istio 버전으로 롤백

롤백 단계를 실행하여 이전 Istio 삽입 라벨로 네임스페이스 라벨을 다시 지정하고 워크로드를 다시 시작하고 게이트웨이 변경사항을 롤백합니다. 그런 다음 이 도구는 클러스터에 배포된 모든 Anthos Service Mesh 구성요소를 삭제합니다.

마이그레이션 전 단계에서 사용 설정한 모든 종속 항목을 수동으로 되돌려야 합니다.

Istio로 롤백하려면 다음 명령어를 실행합니다.

 ./migrate-to-asm rollback \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID
출력은 다음과 비슷합니다. 
migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for $PROJECT_ID...
******
migrate-to-asm: Rolling back migration by relabeling and restarting workloads
migrate-to-asm: in the following namespaces:
migrate-to-asm:     namespace/default
migrate-to-asm:
Continue with rollback? (Y/n)
migrate-to-asm: Relabeling namespace/default...
namespace/default labeled
migrate-to-asm: Restarting workloads in namespace/default and waiting for them to become available (max 5 min)...
deployment.apps/frontend restarted
deployment.apps/backend restarted
deployment.apps/frontend condition met
deployment.apps/backend condition met
migrate-to-asm: *******
migrate-to-asm: Finished restarting workloads!
service/istio-ingressgateway configured
deployment.apps/istio-ingressgateway configured
There are still 14 proxies pointing to the control plane revision asm-1102-2
istio-ingressgateway-66c85975d-2gt8c.istio-system
istio-ingressgateway-66c85975d-jdd96.istio-system
...
frontend-685dcb78d6-9l45j.default
If you proceed with the uninstall, these proxies will become detached from any control plane and will not function correctly.

Removed HorizontalPodAutoscaler:istio-system:istio-ingressgateway.
Removed HorizontalPodAutoscaler:istio-system:istiod-asm-1102-2.
...
Removed ClusterRoleBinding::mdp-controller.
✔ Uninstall complete
namespace "asm-system" deleted
migrate-to-asm: ****
migrate-to-asm: Anthos Service Mesh has been uninstalled from the cluster.

부록

Istio가 설치된 GKE 클러스터 만들기

이 섹션에서는 Istio가 사용 설정된 GKE 클러스터를 배포합니다. 비공개 또는 비공개가 아닌 GKE 클러스터를 사용할 수 있습니다. 비공개 GKE 클러스터에는 공개 GKE 엔드포인트가 있어야 합니다. Istio 설치도 확인합니다.

기존 GKE 클러스터가 이미 있으면 만들기 단계를 건너뛰고 KUBECONFIG 파일을 사용하는 클러스터에 액세스할 수 있는지 확인할 수 있습니다. 이 가이드에서 사용하는 컨텍스트는 ${CLUSTER_1_CTX} 변수에 정의되어 있습니다. 클러스터의 컨텍스트를 이 변수로 설정할 수 있습니다.

  1. 이 가이드에서 사용되는 환경 변수를 만듭니다.

    # Enter your project ID
export PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}
export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
export CLUSTER_NAME=GKE_CLUSTER_NAME
export CLUSTER_LOCATION=GKE_CLUSTER_REGION_OR_ZONE
export CLUSTER_CTX=gke_${PROJECT_ID}_${CLUSTER_LOCATION}_${CLUSTER_NAME}
export ISTIO_VERSION=ISTIO_VERSION # Must be versions 1.7 through 1.10 and must be of the form major.minor.patch, for example 1.7.4 or 1.9.5

  2. Istio가 사용 설정된 GKE 클러스터를 만듭니다 (비공개 클러스터). 비공개가 아닌 GKE 클러스터에서도 이러한 단계를 수행할 수도 있습니다.

    영역 클러스터

    gcloud container clusters create ${CLUSTER_NAME} \
    --project ${PROJECT_ID} \
    --zone ${CLUSTER_LOCATION} \
    --machine-type "e2-standard-4" \
    --num-nodes "4" --min-nodes "2" --max-nodes "5" \
    --enable-ip-alias --enable-autoscaling

    리전 클러스터

    gcloud container clusters create ${CLUSTER_NAME} \
    --project ${PROJECT_ID} \
    --region ${CLUSTER_LOCATION} \
    --machine-type "e2-standard-4" \
    --num-nodes "4" --min-nodes "2" --max-nodes "5" \
    --enable-ip-alias --enable-autoscaling

  3. 클러스터가 RUNNING인지 확인합니다.

     gcloud container clusters list

    출력은 다음과 비슷합니다.

    NAME      LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
gke-east  us-east1-b  1.19.10-gke.1600  34.73.171.206  e2-standard-4  1.19.10-gke.1600  4          RUNNING

  4. 클러스터에 연결합니다.

    영역 클러스터

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --zone ${CLUSTER_LOCATION}

    리전 클러스터

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --region ${CLUSTER_LOCATION}

마지막에 KUBECONFIG 변수를 설정 해제해야 합니다.

Istio 설치

이 섹션에서는 Istio 버전 1.7을 GKE 클러스터에 배포합니다.

  1. Istio를 다운로드합니다.

    curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} TARGET_ARCH=x86_64 sh -

  2. istioctl 명령줄 도구를 사용하여 Istio를 설치합니다. 다음 옵션 중 하나를 선택합니다.

    • 옵션 1: 커스텀 IstioOperator 리소스를 사용하지 않음

    • 옵션 2: 커스텀 IstioOperator 리소스 사용

    옵션 1

    커스텀 IstioOperator 리소스를 사용하지 않는 경우에는 다음을 실행합니다.

    ./istio-${ISTIO_VERSION}/bin/istioctl install --set profile=default -y

    출력은 다음과 비슷합니다.

    ✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete

    옵션 2

    커스텀 IstioOperator 리소스를 사용하는 경우 다음을 실행합니다.

    cat <<EOF > istio-operator.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
 name: istio-operator
spec:
 components:
   base:
     enabled: true
   ingressGateways:
   - enabled: true
     k8s:
       env:
       - name: TERMINATION_DRAIN_DURATION_SECONDS
         value: "10"
       hpaSpec:
         maxReplicas: 10
         metrics:
         - resource:
             name: cpu
             targetAverageUtilization: 80
           type: Resource
         minReplicas: 2
       resources:
         limits:
           cpu: "4"
           memory: 8Gi
         requests:
           cpu: "2"
           memory: 4Gi
       service:
         ports:
         - name: status-port
           port: 15021
           targetPort: 15021
         - name: http2
           port: 80
           targetPort: 8080
         - name: https
           port: 443
           targetPort: 8443
         - name: tls
           port: 15443
           targetPort: 15443
     name: istio-ingressgateway
   - enabled: true
     k8s:
       env:
       - name: TERMINATION_DRAIN_DURATION_SECONDS
         value: "10"
       hpaSpec:
         maxReplicas: 10
         minReplicas: 2
       resources:
         limits:
           cpu: "4"
           memory: 8Gi
         requests:
           cpu: "2"
           memory: 4Gi
       service:
         ports:
         - name: status-port
           port: 15021
           targetPort: 15021
         - name: http2
           port: 80
           targetPort: 8080
         - name: https
           port: 443
           targetPort: 8443
         - name: tls
           port: 15443
           targetPort: 15443
     label:
       istio: istio-api-ingressgateway
     name: istio-api-ingressgateway
 meshConfig:
   defaultConfig:
     tracing:
       sampling: 1
       zipkin:
         address: jaeger-collector.observability.svc.cluster.local:9411
   enableTracing: true
EOF

./istio-${ISTIO_VERSION}/bin/istioctl install -f istio-operator.yaml -y

    출력은 다음과 비슷합니다.

    ✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete

  3. Istio 서비스와 포드가 배포되었고 실행 중인지 확인합니다.

    kubectl --context=${CLUSTER_CTX} -n istio-system get services,pods

    출력은 다음과 비슷합니다.

    옵션 1

    커스텀 IstioOperator 리소스를 사용하지 않는 경우에는 다음을 실행합니다.

    NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP         PORT(S)                                                      AGE
service/istio-ingressgateway   LoadBalancer   10.64.5.113    <pending>           15021:31285/TCP,80:31740/TCP,443:30753/TCP,15443:31246/TCP   33s
service/istiod                 ClusterIP      10.64.15.184   <none>              15010/TCP,15012/TCP,443/TCP,15014/TCP,853/TCP                45s

NAME                                        READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-6f44d6745b-22q9h   1/1     Running   0          34s
pod/istiod-b89f5cc6-nhsrc                   1/1     Running   0          48s

    옵션 2

    커스텀 IstioOperator 리소스를 사용하는 경우 다음을 실행합니다.

    NAME                               TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                                                      AGE
service/istio-api-ingressgateway   LoadBalancer   10.100.0.84    104.196.26.108   15021:32489/TCP,80:30083/TCP,443:30565/TCP,15443:30705/TCP   76s
service/istio-ingressgateway       LoadBalancer   10.100.3.221   34.139.111.125   15021:30966/TCP,80:31557/TCP,443:31016/TCP,15443:31574/TCP   75s
service/istiod                     ClusterIP      10.100.13.72   <none>           15010/TCP,15012/TCP,443/TCP,15014/TCP                        86s

NAME                                            READY   STATUS    RESTARTS   AGE
pod/istio-api-ingressgateway-79978ddc65-hslbv   1/1     Running   0          61s
pod/istio-api-ingressgateway-79978ddc65-z92w8   1/1     Running   0          77s
pod/istio-ingressgateway-fb47c4859-pkdn7        1/1     Running   0          60s
pod/istio-ingressgateway-fb47c4859-t2pfq        1/1     Running   0          77s
pod/istiod-9445656d7-fxk9j                      1/1     Running   0          89s

Online Boutique 배포

이 섹션에서는 Online Boutique라는 마이크로서비스 기반 샘플 애플리케이션을 GKE 클러스터에 배포합니다. Online Boutique는 Istio 지원 네임스페이스에 배포됩니다. 애플리케이션이 작동하고 Istio가 모든 포드에 사이드카 프록시를 삽입하는지 확인합니다.

애플리케이션에 기존 클러스터가 이미 있으면 새 네임스페이스 만들기와 Online Boutique 배포를 건너뛸 수 있습니다. Anthos Service Mesh 설치 및 워크로드 준비 섹션의 모든 네임스페이스에 동일한 프로세스를 수행할 수 있습니다.

  1. Online Boutique를 GKE 클러스터에 배포합니다.

    kpt pkg get \
https://github.com/GoogleCloudPlatform/microservices-demo.git/release \
online-boutique

kubectl --context=${CLUSTER_CTX} create namespace online-boutique
kubectl --context=${CLUSTER_CTX} label namespace online-boutique istio-injection=enabled

kubectl --context=${CLUSTER_CTX} -n online-boutique apply -f online-boutique

  2. 모든 배포가 준비될 때까지 기다립니다.

    kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment adservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment checkoutservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment currencyservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment emailservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment frontend
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment paymentservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment productcatalogservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment shippingservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment cartservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment loadgenerator
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment recommendationservice

  3. 포드당 컨테이너 두 개, 즉 애플리케이션 컨테이너와 Istio가 자동으로 포드에 삽입되는 Istio 사이드카 프록시가 있는지 확인합니다.

    kubectl --context=${CLUSTER_CTX} -n online-boutique get pods

    출력은 다음과 비슷합니다.

    NAME                                     READY   STATUS    RESTARTS   AGE
adservice-7cbc9bd9-t92k4                 2/2     Running   0          3m21s
cartservice-d7db78c66-5qfmt              2/2     Running   1          3m23s
checkoutservice-784bfc794f-j8rl5         2/2     Running   0          3m26s
currencyservice-5898885559-lkwg4         2/2     Running   0          3m23s
emailservice-6bd8b47657-llvgv            2/2     Running   0          3m27s
frontend-764c5c755f-9wf97                2/2     Running   0          3m25s
loadgenerator-84cbcd768c-5pdbr           2/2     Running   3          3m23s
paymentservice-6c676df669-s779c          2/2     Running   0          3m25s
productcatalogservice-7fcf4f8cc-hvf5x    2/2     Running   0          3m24s
recommendationservice-79f5f4bbf5-6st24   2/2     Running   0          3m26s
redis-cart-74594bd569-pfhkz              2/2     Running   0          3m22s
shippingservice-b5879cdbf-5z7m5          2/2     Running   0          3m22s

  4. 포드 중 하나에서 사이드카 Envoy 프록시 버전을 검사하여 Istio 버전 1.4 Envoy 프록시가 배포되었는지 확인할 수 있습니다.

    export FRONTEND_POD=$(kubectl get pod -n online-boutique -l app=frontend --context=${CLUSTER_CTX} -o jsonpath='{.items[0].metadata.name}')
kubectl --context=${CLUSTER_CTX} get pods ${FRONTEND_POD} -n online-boutique -o json | jq '.status.containerStatuses[].image'

    출력은 다음과 비슷합니다.

    "docker.io/istio/proxyv2:1.7.4"
"gcr.io/google-samples/microservices-demo/frontend:v0.3.4"

  5. istio-ingressgateway 서비스 IP 주소의 IP 주소로 이동하여 애플리케이션에 액세스합니다.

    kubectl --context=${CLUSTER_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

다음 단계