Istio on GKE에서 Cloud Service Mesh로 마이그레이션

이 가이드에서는 Istio on Google Kubernetes Engine(Istio on GKE) 버전 1.4 또는 1.6(베타)을 사용한 Google Kubernetes Engine(GKE) 클러스터를 Google 관리 컨트롤 플레인 및 Cloud Service Mesh 인증 기관을 사용한 관리형 Cloud Service Mesh으로 업그레이드하는 방법을 보여줍니다.

기본 요건

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

• GKE 클러스터에 Istio on GKE가 사용 설정되어 있어야 합니다. GKE 클러스터가 여러 개 있으면 모든 클러스터에 대해 동일한 단계를 따릅니다.

• Istio on GKE는 버전 1.4 또는 1.6이어야 합니다.

• GKE 버전 1.17.17-gke.3100+, 1.18.16-gke.1600+, 1.19.8-gke.1600+ 이상을 실행 중인지 확인합니다.

• GKE 클러스터는 이러한 위치 중 하나에서 실행되어야 합니다.

• 이 스크립트를 실행하는 사용자 또는 서비스 계정에는 프로젝트 설정에 설명된 IAM 권한이 필요합니다.

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

목표

• 일반 채널에 Cloud Service Mesh Google 관리형 컨트롤 플레인을 배포합니다. 이 가이드는 일반 채널에만 적용되며 공개 버전 또는 빠른 채널에는 약간의 수정이 필요합니다. 출시 채널에 대해 자세히 알아보려면 이 링크를 방문하세요.
• Istio 구성을 Cloud Service Mesh로 마이그레이션합니다.
• Cloud Service Mesh 인증 기관을 구성합니다.
• 애플리케이션을 Cloud Service Mesh로 마이그레이션합니다.
• Istio on GKE의 istio-ingressgateway를 Cloud Service Mesh로 업그레이드합니다.
• Cloud Service Mesh 마이그레이션을 완료하거나 Istio on GKE로 롤백합니다.

환경 설정하기

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

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

   Cloud Shell 활성화

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

   참고: macOS에서는 스크립트가 작동하지 않습니다. Cloud Shell에서만 테스트된 스크립트입니다. 이 스크립트에는 Cloud Shell에 기본적으로 모두 포함된 다음 애플리케이션이 필요합니다.

   • gcloud(버전 346.0.0 이상)
   • kubectl(클라이언트 버전 1.21 이상)
   • jq
   • sed
   • curl
   • awk

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

   # Enter your project ID
   export PROJECT_ID=PROJECT_ID
   
   # Copy and paste the following
   gcloud config set project ${PROJECT_ID}
   export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
   export CLUSTER_1=GKE_CLUSTER_NAME
   export CLUSTER_1_LOCATION=GKE_CLUSTER_REGION_OR_ZONE
   export SHELL_IP=$(curl ifconfig.me) # This is required for private clusters with `master-authorized-networks` enabled.
   

3. WORKDIR 폴더를 만듭니다. 이 가이드와 연관된 모든 파일은 WORKDIR에서 종료되므로 완료되었으면 WORKDIR을 삭제해야 합니다.

   mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`
   

4. 이 가이드에 사용할 KUBECONFIG 파일을 만듭니다. 또한 Cloud Service Mesh에 마이그레이션할 GKE 클러스터의 클러스터 컨텍스트가 포함된 기존 KUBECONFIG 파일을 사용할 수 있습니다.

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

5. GKE 클러스터에 대한 사용자 인증 정보를 가져오고 컨텍스트를 변수에 저장합니다.

   영역 클러스터

   gcloud container clusters get-credentials ${CLUSTER_1} \
     --zone=${CLUSTER_1_LOCATION}
   
   export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}
   

   리전 클러스터

   gcloud container clusters get-credentials ${CLUSTER_1} \
     --region=${CLUSTER_1_LOCATION}
   
   export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}
   

6. 클러스터를 Fleet에 등록해야 합니다. 이 단계는 설치 전 별도로 수행하거나 --fleet-id 및 --enable-all 또는 --enable-registration 플래그 중 하나를 전달하여 설치의 일부로 수행할 수 있습니다.

7. 프로젝트에 서비스 메시 기능이 사용 설정되어 있어야 합니다. 설치 중에 --enable-all 또는 --enable-registration 플래그 중 하나를 전달하거나 설치 전에 다음 명령어를 실행하여 사용 설정할 수 있습니다.

     gcloud container hub mesh enable --project=FLEET_PROJECT_ID
   

   여기서 FLEET_PROJECT_ID는 fleet 호스트 프로젝트의 프로젝트 ID입니다.

선택 사항 단계

클러스터가 비공개 클러스터(master-authorized-networks 사용 설정)이면 $SHELL_IP를 master-authorized-networks 허용 목록에 추가합니다. 클러스터에 이미 액세스 권한이 있으면 이 단계가 필요하지 않을 수 있습니다.

영역 클러스터

export SHELL_IP=$(curl ifconfig.me)

gcloud container clusters update ${CLUSTER_1} \
    --zone=${CLUSTER_1_LOCATION} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${SHELL_IP}/32

리전 클러스터

export SHELL_IP=$(curl ifconfig.me)

gcloud container clusters update ${CLUSTER_1} \
    --region=${CLUSTER_1_LOCATION} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${SHELL_IP}/32

Cloud Service Mesh 설치

이 섹션에서는 일반 채널의 Google 관리 컨트롤 플레인을 사용한 Cloud Service Mesh을 GKE 클러스터에 배포합니다. 이 컨트롤 플레인은 처음에 두 번째(또는 카나리아) 컨트롤 플레인과 함께 배포됩니다.

1. Cloud Service Mesh를 설치하는 최신 버전의 스크립트를 현재 작업 디렉터리에 다운로드하고 스크립트를 실행 파일을 만듭니다.

   curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
   chmod +x asmcli
   

2. GKE 클러스터를 구성하려면 설치 스크립트를 실행하여 일반 채널의 Google 관리 컨트롤 플레인을 사용한 Cloud Service Mesh를 설치합니다.

   ./asmcli install \
   -p ${PROJECT_ID} \
   -l ${CLUSTER_1_LOCATION} \
   -n ${CLUSTER_1} \
   --fleet_id ${FLEET_PROJECT_ID} \
   --managed \
   --verbose \
   --output_dir ${CLUSTER_1} \
   --enable-all \
   --channel regular
   

   이 단계를 완료하는 데 몇 분 정도 걸릴 수 있습니다.

3. Google 관리형 컨트롤 플레인 확인

4. istioctl을 WORKDIR 폴더에 복사합니다.

   cp ./${CLUSTER_1}/istioctl ${WORKDIR}/.
   

다음 섹션에서는 Cloud Service Mesh로 마이그레이션을 지원하도록 migrate_addon 스크립트를 다운로드하여 실행합니다. istioctl 명령줄 유틸리티는 migrate_addon 스크립트와 동일한 폴더에 있어야 합니다. istioctl 명령줄 유틸리티 및 migrate_addon 스크립트 모두에 WORKDIR 폴더를 사용합니다.

Cloud Service Mesh로 구성 마이그레이션

이 섹션에서는 Istio on GKE 구성을 Cloud Service Mesh로 마이그레이션합니다. 이 안내식 스크립트는 마이그레이션 가능한 구성 및 불가능한 구성을 식별해서 보여줍니다.

1. 마이그레이션 도구를 다운로드하고 실행 파일로 만듭니다.

   curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/migrate-addon > ${WORKDIR}/migrate_addon
   chmod +x ${WORKDIR}/migrate_addon
   

2. Galley 검증 웹훅을 사용 중지합니다. 이 단계는 1.4 구성 일부를 Cloud Service Mesh로 마이그레이션하는 데 필요합니다. 두 질문 모두 Y로 답변합니다.

   ${WORKDIR}/migrate_addon -d tmpdir --command disable-galley-webhook
   

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

   tmpdir directory not present. Create directory? Continue? [Y/n] Y
   
   Disabling the Istio validation webhook... Continue? [Y/n] Y
   Running: kubectl get clusterrole istio-galley-istio-system -n istio-system -o yaml
   Running: kubectl patch clusterrole -n istio-system istio-galley-istio-system --type=json -p=[{"op": "replace", "path": "/rules/2/verbs/0", "value": "get"}]
   clusterrole.rbac.authorization.k8s.io/istio-galley-istio-system patched
   Running: kubectl get ValidatingWebhookConfiguration istio-galley --ignore-not-found
   Running: kubectl delete ValidatingWebhookConfiguration istio-galley --ignore-not-found
   validatingwebhookconfiguration.admissionregistration.k8s.io "istio-galley" deleted
   
   

3. 구성을 확인하고 수동으로 마이그레이션합니다. 이 단계는 Google 관리 컨트롤 플레인으로 워크로드를 마이그레이션하기 전 수동으로 마이그레이션해야 하는 일부 구성을 식별하는 데 도움이 됩니다.

   ${WORKDIR}/migrate_addon -d tmpdir --command config-check
   

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

   Installing the authentication CR migration tool...
   OK
   
   Checking for configurations that will need to be explicitly migrated...
   No resources found
   

커스텀 구성 마이그레이션

Cloud Service Mesh로 마이그레이션하기 전 커스텀 구성을 수동으로 마이그레이션해야 할 수 있습니다. 앞의 스크립트는 커스텀 구성을 식별하고 필요한 항목에 대한 정보를 출력합니다. 이러한 맞춤설정은 다음과 같습니다.

• Cloud Service Mesh에서는 감지된 커스텀 envoy 필터를 지원하지 않습니다. 가능하면 삭제하세요. Envoy 필터는 Google 관리 컨트롤 플레인에서 현재 지원되지 않습니다.

• 감지된 커스텀 플러그인 인증서. 플러그인 인증서는 Cloud Service Mesh로 마이그레이션되지 않습니다. 플러그인 인증서가 Istio on GKE에 사용된 경우 이러한 인증서는 워크로드가 Google 관리 컨트롤 플레인으로 마이그레이션된 후 사용되지 않습니다. 모든 워크로드는 Google Cloud Service Mesh 인증 기관에서 서명한 인증서를 사용합니다. Cloud Service Mesh 인증 기관에서는 플러그인 인증서를 지원하지 않습니다. 이 메시지는 정보 제공용이며 조치가 필요하지 않습니다.

• 마이그레이션할 수 없는 보안 정책이 감지되었습니다. <오류 이유>. 이 오류는 일반적으로 수동으로 마이그레이션해야 하는 AuthZ 정책으로 인해 발생합니다. 정책 마이그레이션 방법에 대한 자세한 컨텍스트 및 정보는 Istio 1.4 알파 이전 보안 정책을 현재 API로 마이그레이션을 참조하세요. 오류 메시지에 대한 자세한 내용은 security-policy-migrate을 참조하세요.

• 호환되지 않을 수 있는 VirtualService 구성이 감지되었습니다. <특정 지원 중단된 구성>. 다음 VirtualService 구성을 업데이트해야 합니다.

  • appendHeaders 사용은 지원되지 않습니다. 대신 spec.http.headers를 사용하세요.
  • websocketUpgrade 사용은 필요하지 않습니다. 이 기능은 기본적으로 설정됩니다.
  • abort.percent 필드를 abort.percentage로 바꿉니다.

• 마이그레이션할 수 없는 믹서 리소스의 커스텀 설치가 감지되었습니다. telemetryv2로 수동 마이그레이션이 필요합니다. 기본 Istio on GKE 설치 외에도 커스텀 믹서 정책이 구성된 경우 이러한 정책을 원격 분석 v2로 수동으로 마이그레이션해야 합니다. 이를 수행하는 방법에 대한 자세한 내용은 Istio 측정항목 맞춤설정을 참조하세요.

• <deploymentName> 배포가 커스텀 게이트웨이일 수 있습니다. 이를 수동으로 마이그레이션하세요. istio-ingressgateway(기본적으로 설치됨) 이외의 모든 게이트웨이 배포를 수동으로 마이그레이션해야 합니다. Google 관리 컨트롤 플레인의 게이트웨이 업그레이드 방법은 Google 관리 제어 영 구성을 참조하세요.

마이그레이션을 구성하려면 다음 단계를 수행합니다.

1. 2단계로 진행하기 전에 나열된 모든 커스텀 구성을 수동으로 마이그레이션합니다(마지막 구성 제외).

2. 마이그레이션 도구를 사용하여 자동으로 마이그레이션(또는 무시)될 수 있는 구성을 마이그레이션합니다.

   ${WORKDIR}/migrate_addon -d tmpdir --command migrate-configs
   

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

   Converting authentication CRs...
   2021/06/25 20:44:58 found root namespace: istio-system
   2021/06/25 20:44:59 SUCCESS converting policy /default
   Running: kubectl apply --dry-run=client -f beta-policy.yaml
   peerauthentication.security.istio.io/default created (dry run)
   
   Applying converted security policies in tmpdir/beta-policy.yaml... Continue? [Y/n] Y
   Running: kubectl apply -f beta-policy.yaml
   peerauthentication.security.istio.io/default created
   OK
   
   

3. Cloud Service Mesh 인증 기관 루트 트러스트를 적용합니다. 이렇게 하면 애플리케이션에 다운타임이 발생하지 않고 현재 Citadel CA에서 Cloud Service Mesh 인증 기관으로 마이그레이션할 수 있습니다.

   ${WORKDIR}/migrate_addon -d tmpdir --command configure-mesh-ca
   

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

   Configuring Istio on GKE to trust Anthos Service Mesh... Continue? [Y/n] Y
   Running: kubectl get cm -n istio-system istio-asm-managed -oyaml
   Running: kubectl -n istio-system apply -f -
   secret/meshca-root created
   Running: kubectl get cm istio -n istio-system -o yaml
   Running: kubectl get cm istio -n istio-system -o yaml
   Running: kubectl replace -f -
   configmap/istio replaced
   Running: kubectl get deploy istio-pilot -n istio-system -o yaml
   Running: kubectl patch deploy istio-pilot -n istio-system -p={"spec":{"template":{"spec":{"containers":[{
       "name":"discovery",
       "image":"gcr.io/gke-release/istio/pilot:1.4.10-gke.12",
       "env":[{"name":"PILOT_SKIP_VALIDATE_TRUST_DOMAIN","value":"true"}]
     }]}}}}
   deployment.apps/istio-pilot patched
   Running: kubectl get deploy istio-citadel -n istio-system -o yaml
   Running: kubectl patch deploy istio-citadel -n istio-system -p={"spec":{"template":{"spec":{
       "containers":[{
         "name":"citadel",
         "args": ["--append-dns-names=true", "--grpc-port=8060", "--citadel-storage-namespace=istio-system", "--custom-dns-names=istio-pilot-service-account.istio-system:istio-pilot.istio-system", "--monitoring-port=15014", "--self-signed-ca=true", "--workload-cert-ttl=2160h", "--root-cert=/var/run/root-certs/meshca-root.pem"],
         "volumeMounts": [{"mountPath": "/var/run/root-certs", "name": "meshca-root", "readOnly": true}]
       }],
       "volumes": [{"name": "meshca-root", "secret":{"secretName": "meshca-root"}}]
     }}}}
   deployment.apps/istio-citadel patched
   OK
   
   Waiting for root certificate to distribute to all pods. This will take a few minutes...
   ASM root certificate not distributed to asm-system, trying again later
   ASM root certificate not distributed to asm-system, trying again later
   ASM root certificate distributed to namespace asm-system
   ASM root certificate distributed to namespace default
   ASM root certificate distributed to namespace istio-operator
   ASM root certificate not distributed to istio-system, trying again later
   ASM root certificate not distributed to istio-system, trying again later
   ASM root certificate distributed to namespace istio-system
   ASM root certificate distributed to namespace kube-node-lease
   ASM root certificate distributed to namespace kube-public
   ASM root certificate distributed to namespace kube-system
   ASM root certificate distributed to namespace online-boutique
   Waiting for proxies to pick up the new root certificate...
   OK
   
   Configuring Istio Addon 1.6 to trust Anthos Service Mesh...
   Running: kubectl get cm -n istio-system env-asm-managed -ojsonpath={.data.TRUST_DOMAIN} --ignore-not-found
   Running: kubectl get cm istio-istio-1611 -n istio-system -o yaml
   Running: kubectl replace -f -
   configmap/istio-istio-1611 replaced
   Running: kubectl patch -n istio-system istiooperators.install.istio.io istio-1-6-11-gke-0 --type=merge
   istiooperator.install.istio.io/istio-1-6-11-gke-0 patched
   Running: kubectl -n istio-system get secret istio-ca-secret -ojsonpath={.data.ca-cert\.pem}
   Running: kubectl -n istio-system patch secret istio-ca-secret
   secret/istio-ca-secret patched
   Running: kubectl patch deploy istiod-istio-1611 -n istio-system
   deployment.apps/istiod-istio-1611 patched
   Running: kubectl rollout status -w deployment/istiod-istio-1611 -n istio-system
   Waiting for deployment "istiod-istio-1611" rollout to finish: 1 old replicas are pending termination...
   deployment "istiod-istio-1611" successfully rolled out
   Running: kubectl apply -f - -n istio-system
   envoyfilter.networking.istio.io/trigger-root-cert created
   Waiting for proxies to pick up the new root certificate...
   Running: kubectl delete envoyfilter trigger-root-cert -n istio-system
   OK
   
   

   이 단계에서 Cloud Service Mesh 루트 인증서를 모든 네임스페이스에 배포하는 데 몇 분 정도 걸립니다. 스크립트가 OK 메시지로 끝날 때까지 기다립니다.

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

• 클러스터에 있는 모든 워크로드의 Cloud Service Mesh 인증 기관 신뢰할 수 있는 루트를 설치합니다.

• 컨트롤 플레인 배포 istio-pilot, istiod, istio-citadel의 구성을 변경하세요. 변경사항에는 다음이 포함됩니다.

  • 이미지를 최신 빌드로 업그레이드합니다.
  • PILOT_SKIP_VALIDATE_TRUST_DOMAIN=true를 설정하여 trust-domain 인증을 사용 중지합니다.
  • 모든 네임스페이스에 ConfigMap을 배포하기 위해 istio-citadel에 Cloud Service Mesh 인증 기관 신뢰 루트를 추가합니다.
  • 루트 인증서를 배포하기 위해 Cloud Service Mesh 인증 기관 신뢰 루트를 istio-ca-secret에 추가합니다.

• 이전 구성 매니페스트를 tmpdir에 저장합니다.

• 롤백 기능에 대한 단계를 안내합니다(뒷부분에서 설명).

Cloud Service Mesh에 워크로드 마이그레이션

이 섹션에서는 Istio on GKE에서 실행되는 워크로드를 Cloud Service Mesh로 마이그레이션합니다. 마이그레이션 후 올바른 사이드카 프록시(Cloud Service Mesh)가 모든 포드에 삽입되었고 애플리케이션이 예상대로 작동하는지 확인합니다.

기존 클러스터에서 이 프로시져를 수행하는 경우 마이그레이션할 네임스페이스를 선택합니다.

1. 네임스페이스를 변수로 정의합니다. 이 네임스페이스가 Cloud Service Mesh로 마이그레이션됩니다.

   export NAMESPACE=NAMESPACE_NAME
   

2. 워크로드를 Cloud Service Mesh로 마이그레이션하려면 Cloud Service Mesh의 네임스페이스 라벨을 다시 지정해야 합니다. 네임스페이스에 라벨을 지정하면 Cloud Service Mesh에서 사이드카를 자동으로 모든 워크로드에 삽입할 수 있습니다. 네임스페이스에 라벨을 지정하려면 다음 명령어를 실행하여 라벨을 asm-managed로 설정합니다.

   kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed istio-injection- --overwrite
   

3. 네임스페이스에서 모든 배포의 순차적 재시작을 수행합니다.

   kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
   

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

   deployment.apps/deploymentName1 restarted
   deployment.apps/deploymentName2 restarted
   ...
   

4. 모든 포드가 다시 시작되고 포드당 컨테이너 두 개로 실행 중인지 확인합니다.

   kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get pods
   

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

   NAME                        READY   STATUS    RESTARTS   AGE
   deploymentName1-PodName     2/2     Running   0          101s
   deploymentName2-PodName     2/2     Running   2          100s
   ...
   

   이 단계를 확인하는 좋은 방법은 포드의 AGE를 조사하는 것입니다. 값이 짧게 몇 분 정도인지 확인합니다.

5. 네임스페이스에 있는 모든 배포의 포드 중 하나에서 사이드카 Envoy 프록시 버전을 검사하여 Cloud Service Mesh Envoy 프록시가 배포되었는지 확인합니다.

   export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE
   kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'
   

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

   "gcr.io/gke-release/asm/proxyv2:1.11.5-asm.3"
   "appContainerImage"
   

6. 다시 시작 후 애플리케이션을 확인하고 테스트합니다.

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

7. (선택사항) Google에서 프록시 업그레이드를 관리하도록 하려면 Google 관리 데이터 영역을 사용 설정합니다.

마이그레이션 상태 보기

다음 명령어를 실행하여 마이그레이션 상태를 확인합니다.

kubectl get cm/asm-addon-migration-state -n istio-system -ojsonpath={.data}

출력에서 마이그레이션이 완료되었는지, 대기 중인지 또는 실패했는지를 나타냅니다.

{"migrationStatus":"SUCCESS"}

{"migrationStatus":"PENDING"}

{"migrationStatus":"MIGRATION_CONFIG_ERROR"}

{"migrationStatus":"CONTROLPLANE_PROVISION_ERROR"}

migrationStatus가 SUCCESS를 출력하면 컨트롤 플레인이 Cloud Service Mesh로 성공적으로 업그레이드된 것입니다. 데이터 영역을 수동으로 업데이트하려면 워크로드 마이그레이션의 단계를 완료하세요.

migrationStatus가 SUCCESS 외의 상태를 출력하는 경우, 다음 중 하나를 선택할 수 있습니다.

• 마이그레이션 오류가 기존 Istio on GKE 워크로드에 영향을 주지 않으면 추가 조치를 취하지 않아도 됩니다. 필요한 경우 롤백합니다.
• 클러스터에서 커스텀 구성을 업데이트하고 migrationStatus에 MIGRATION_CONFIG_ERROR가 표시되면 마이그레이션을 다시 실행합니다.

마이그레이션이 성공적으로 완료되면 측정항목 탐색기에서 컨트롤 플레인 측정항목을 볼 수 있습니다. verify_control_plane_metrics를 참조하세요.

Cloud Service Mesh 대시보드에 액세스

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

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

   Cloud Service Mesh로 이동

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

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

참고: Cloud Service Mesh 대시보드의 토폴로지와 테이블 뷰에 올바른 데이터가 표시되는 데 몇 분 정도 걸릴 수 있습니다.

성공적인 마이그레이션 완료

이 섹션에서는 Istio on GKE에서 Cloud Service Mesh로 마이그레이션을 마무리합니다. 이 섹션을 진행하기 전 Cloud Service Mesh로 이동할지 확인합니다. 이 섹션에서는 또한 Istio on GKE 아티팩트를 삭제합니다. Istio on GKE로 롤백하려면 다음 섹션으로 이동합니다.

1. istio-ingressgateway(표준 Istio on GKE의 일부)를 Google 관리 컨트롤 플레인 버전의 게이트웨이로 바꿉니다.

   ${WORKDIR}/migrate_addon -d tmpdir --command replace-gateway
   

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

   Replacing the ingress gateway with an Anthos Service Mesh gateway... Continue? [Y/n] Y
   Running: kubectl label namespace istio-system istio-injection- istio.io/rev- --overwrite
   label "istio.io/rev" not found.
   namespace/istio-system labeled
   Running: kubectl apply -f -
   serviceaccount/asm-ingressgateway created
   deployment.apps/asm-ingressgateway created
   role.rbac.authorization.k8s.io/asm-ingressgateway created
   rolebinding.rbac.authorization.k8s.io/asm-ingressgateway created
   Running: kubectl wait --for=condition=available --timeout=600s deployment/asm-ingressgateway -n istio-system
   deployment.apps/asm-ingressgateway condition met
   
   Scaling the Istio ingress gateway to zero replicas... Continue? [Y/n] Y
   Running: kubectl -n istio-system patch hpa istio-ingressgateway --patch {"spec":{"minReplicas":1}}
   horizontalpodautoscaler.autoscaling/istio-ingressgateway patched (no change)
   Running: kubectl -n istio-system scale deployment istio-ingressgateway --replicas=0
   deployment.apps/istio-ingressgateway scaled
   OK
   

2. Google 관리 컨트롤 플레인을 사용하도록 웹훅을 다시 구성합니다. 모든 워크로드는 Google 관리 컨트롤 플레인을 사용하여 시작합니다.

   ${WORKDIR}/migrate_addon -d tmpdir --command replace-webhook
   

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

   Configuring sidecar injection to use Anthos Service Mesh by default... Continue? [Y/n] Y
   Running: kubectl patch mutatingwebhookconfigurations istio-sidecar-injector --type=json -p=[{"op": "replace", "path": "/webhooks"}]
   mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector patched
   Revision tag "default" created, referencing control plane revision "asm-managed". To enable injection using this
   revision tag, use 'kubectl label namespace <NAMESPACE> istio.io/rev=default'
   OK
   

3. Cloud Service Mesh 라벨로 모든 네임스페이스에 라벨을 재지정하고, 모든 워크로드의 순차적 재시작을 수행하여 Google 관리 컨트롤 플레인에 가져옵니다.

   export NAMESPACE=NAMESPACE_NAME \
       kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE}
       istio.io/rev=asm-managed istio-injection- --overwrite`
   
       kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n
   ${NAMESPACE}
   

   출력에서 "istio-injection not found" 메시지는 무시해도 됩니다. 즉, 이전에는 네임스페이스에 istio-injection 라벨이 없었으므로 Cloud Service Mesh를 새로 설치하거나 새로 배포해야 합니다. 네임스페이스에 istio-injection과 버전 라벨이 모두 있는 경우 Istio on GKE 문서에 있는 모든 kubectl label 명령어에 istio-injection 라벨 삭제를 포함되기 때문입니다.

4. 다음 명령어를 실행하여 마이그레이션을 마무리합니다.

   ${WORKDIR}/migrate_addon -d tmpdir --command write-marker
   

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

   Current migration state: SUCCESS
   Running: kubectl apply -f -
   configmap/asm-addon-migration-state created
   OK
   
   

5. 다음 명령어를 실행하여 Istio on GKE를 사용 중지합니다.

   영역 클러스터

   gcloud beta container clusters update ${CLUSTER_1} \
       --project=$PROJECT_ID \
       --zone=${CLUSTER_1_LOCATION} \
       --update-addons=Istio=DISABLED
   

   리전 클러스터

   gcloud beta container clusters update ${CLUSTER_1} \
       --project=$PROJECT_ID \
       --region=${CLUSTER_1_LOCATION} \
       --update-addons=Istio=DISABLED
   

6. 다음 명령어를 실행하여 구성을 삭제합니다.

   ${WORKDIR}/migrate_addon -d tmpdir --command cleanup
   

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

   Cleaning up old resources...
   Running: kubectl get cm -n istio-system asm-addon-migration-state -ojsonpath={.data.migrationStatus}
   Will delete IstioOperator/istio-1-6-11-gke-0.istio-system
   Will delete ServiceAccount/istio-citadel-service-account.istio-system
   ...
   Will delete DestinationRule/istio-policy.istio-system
   Will delete DestinationRule/istio-telemetry.istio-system
   Will delete Secret/istio-ca-secret.istio-system
   
   Deleting resources previously listed... Continue? [Y/n] Y
   Running: kubectl delete IstioOperator istio-1-6-11-gke-0 -n istio-system --ignore-not-found
   istiooperator.install.istio.io "istio-1-6-11-gke-0" deleted
   Running: kubectl delete ServiceAccount istio-citadel-service-account -n istio-system --ignore-not-found
   serviceaccount "istio-citadel-service-account" deleted-ingressgateway -n istio-system --ignore-not-found
   ...
   Running: kubectl delete Secret istio-ca-secret -n istio-system --ignore-not-found
   secret "istio-ca-secret" deleted
   Running: kubectl delete -n istio-system jobs -lk8s-app=istio,app=security
   job.batch "istio-security-post-install-1.4.10-gke.8" deleted
   

7. Istio on GKE 배포 및 서비스가 클러스터에서 성공적으로 삭제되었는지 확인합니다.

   kubectl --context=${CLUSTER_1_CTX} -n istio-system get deployments,services
   

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

   NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/asm-ingressgateway   1/1     1            1           10m
   
   NAME                           TYPE           CLUSTER-IP    EXTERNAL-IP      AGE   PORT(S)
   service/istio-ingressgateway   LoadBalancer   10.64.5.208   34.139.100.237   95m   15020:31959/TCP,80:30971/TCP,443:31688/TCP,31400:31664/TCP,15029:32493/TCP,15030:31722/TCP,15031:30198/TCP,15032:31910/TCP,15443:31222/TCP
   
   

   Cloud Service Mesh 인그레스 게이트웨이 서비스 및 배포만 표시됩니다.

수고하셨습니다! Google 관리 컨트롤 플레인과 Cloud Service Mesh 인증 기관을 사용하여 애플리케이션의 다운타임 없이 Istio on GKE에서 Cloud Service Mesh으로 성공적으로 마이그레이션했습니다.

변경사항 롤백

Cloud Service Mesh로 이동하지 않으려는 경우 이 섹션에서 Cloud Service Mesh 변경사항을 롤백할 수 있습니다. 이 섹션을 완료한 후에는 워크로드가 Istio on GKE로 돌아갑니다.

1. 변형 웹훅 변경사항을 롤백합니다.

   ${WORKDIR}/migrate_addon -d tmpdir --command rollback-mutatingwebhook
   

2. 다음 명령어를 실행하여 Cloud Service Mesh 대신 Istio on GKE 사이드카 삽입에 사용할 네임스페이스의 라벨을 다시 지정합니다.

   버전 1.4 워크로드가 있는 네임스페이스의 경우:

   export NAMESPACE=NAMESPACE_NAME
   kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwrite
   

   버전 1.6 워크로드가 있는 네임스페이스의 경우:

   export NAMESPACE=NAMESPACE_NAME
   kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=istio-1611 --overwrite
   

3. 네임스페이스에서 모든 배포의 순차적 재시작을 수행합니다.

   kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
   

4. 몇 분 정도 기다린 후 모든 포드가 실행 중인지 확인합니다.

   kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get pods
   

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

   NAME                       READY   STATUS    RESTARTS   AGE
   deploymentName1-PodName    2/2     Running   0          101s
   deploymentName2-PodName    2/2     Running   2          100s
   ...
   
   

5. 포드 중 하나에서 사이드카 Envoy 프록시 버전을 검사하여 Istio on GKE v1.4 Envoy 프록시가 배포되었는지 확인합니다.

   export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE
   kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'
   

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

   "gke.gcr.io/istio/proxyv2:1.4.10-gke.8"
   "appContainerImage"
   

   또는

   "gke.gcr.io/istio/proxyv2:1.6.14-gke.4"
   "appContainerImage"
   

6. 다시 시작 후 애플리케이션을 확인하고 테스트합니다.

7. Cloud Service Mesh 인증 기관 변경사항을 롤백합니다.

   ${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-ca
   

8. Istio Galley 웹훅을 다시 사용 설정합니다.

   ${WORKDIR}/migrate_addon -d tmpdir --command enable-galley-webhook
   

이제 변경사항이 Istio on GKE로 롤백되었습니다.

Online Boutique 배포

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

애플리케이션에 기존 클러스터가 이미 있으면 새 네임스페이스 만들기와 Online Boutique 배포를 건너뛸 수 있습니다. Cloud Service Mesh에 워크로드 마이그레이션 섹션에서 모든 네임스페이스에 동일한 프로세스를 따를 수 있습니다.

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

   kpt pkg get \
   https://github.com/GoogleCloudPlatform/microservices-demo.git/release \
   online-boutique
   
   kubectl --context=${CLUSTER_1_CTX} create namespace online-boutique
   kubectl --context=${CLUSTER_1_CTX} label namespace online-boutique istio-injection=enabled
   
   kubectl --context=${CLUSTER_1_CTX} -n online-boutique apply -f online-boutique
   

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

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

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

   kubectl --context=${CLUSTER_1_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 on GKE 1.4 Envoy 프록시가 배포되었는지 확인할 수 있습니다.

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

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

   "gke.gcr.io/istio/proxyv2:1.4.10-gke.8"
   "gcr.io/google-samples/microservices-demo/frontend:v0.3.4"
   

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

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

자주 묻는 질문(FAQ)

이 섹션에서는 Istio on GKE에서 Cloud Service Mesh로 마이그레이션에 대해 자주 묻는 질문과 관련 답변을 설명합니다.

Istio on GKE에서 Cloud Service Mesh로 마이그레이션하는 이유는 무엇인가요?

Istio on Google Kubernetes Engine은 Google Kubernetes Engine(GKE) 클러스터에 Google 관리 Istio를 배포하는 베타 기능입니다. Istio on GKE는 지원되지 않는 버전(Istio 버전 1.4)을 배포합니다. 최신 서비스 메시 기능과 지원되는 서비스 메시 구현을 제공하기 위해 모든 Istio on GKE 사용자를 Cloud Service Mesh로 업그레이드합니다.

Cloud Service Mesh는 Istio API로 구동되는 Google 관리 및 지원 서비스 메시 제품입니다. Cloud Service Mesh와 Istio의 관계는 GKE와 Kubernetes의 관계와 같습니다. Cloud Service Mesh는 Istio API를 기반으로 하므로 Cloud Service Mesh로 마이그레이션할 때 Istio 구성을 계속 사용할 수 있습니다. 또한 독점 공급업체 종속 항목이 없습니다.

Cloud Service Mesh는 다음과 같은 이점을 제공합니다.

• Google에서 관리하는 Google 지원 서비스 메시
• 공급업체에 종속되지 않는 Istio API
• 추가 서드 파티 솔루션을 관리할 필요 없이 즉시 사용 가능한 원격 분석 대시보드 및 SLO 관리가 가능합니다.
• Google에서 호스팅하는 인증 기관 옵션
• Google Cloud Networking 및 IAP(Identity-Aware Proxy)와 통합
• 하이브리드 및 멀티 클라우드 플랫폼 지원

Cloud Service Mesh 기능에 대한 자세한 내용은 Google 관리 컨트롤 플레인 지원 기능을 참조하세요.

이 마이그레이션으로 인한 다운타임이 있나요?

마이그레이션 스크립트는 다운타임을 방지하도록 설계되었습니다. 이 스크립트에서는 기존 Istio 컨트롤 플레인과 함께 카나리아 컨트롤 플레인으로 Cloud Service Mesh를 설치합니다. istio-ingressgateway는 인플레이스(In-Place)로 업그레이드됩니다. 그런 다음 Cloud Service Mesh 인증 기관과 함께 Cloud Service Mesh를 사용하도록 Istio 지원 네임스페이스의 라벨을 다시 지정합니다.

애플리케이션 다운타임이 발생하지 않도록 애플리케이션에 PodDisruptionBudgets가 올바르게 구성되어 있는지 확인합니다. 다운타임을 방지할 수 있지만 이 마이그레이션을 직접 수행하는 경우 예정된 유지보수 기간 중에 이 마이그레이션을 수행하는 것이 좋습니다. Google 기반 마이그레이션은 GKE 유지보수 기간 중에 수행됩니다. GKE 클러스터에 유지보수 기간이 구성되었는지 확인합니다.

Cloud Service Mesh 사용과 관련된 비용이 있나요?

GKE에서 Cloud Service Mesh를 사용하는 방법에는 두 가지가 있습니다.

• GKE Enterprise 구독자라면 Cloud Service Mesh가 GKE Enterprise 구독의 일부로 포함됩니다.

• GKE Enterprise 구독자가 아니라면 Cloud Service Mesh를 Google Cloud의 GKE에서 독립형 제품으로 사용할 수 있습니다. 자세한 내용은 Cloud Service Mesh 가격 책정 세부정보를 참조하세요.

최신 버전의 Cloud Service Mesh에서 지원되지 않는 기능이나 구성이 있나요?

스크립트는 모든 Istio 구성을 확인하고 이를 최신 Cloud Service Mesh 버전으로 마이그레이션합니다. 특정 구성에는 Istio 버전 1.4에서 Cloud Service Mesh 버전 1.10으로 마이그레이션하기 위한 추가 단계가 필요할 수 있습니다. 스크립트는 구성 확인을 수행하고 구성에 추가 단계가 필요한지 알려줍니다.

마이그레이션하면 현재 Istio 구성이 변경되나요?

아니요. Istio 구성은 변경 없이 Cloud Service Mesh에서 작동합니다.

Cloud Service Mesh로 마이그레이션한 후 다시 Istio로 마이그레이션할 수 있나요?

예. Cloud Service Mesh를 사용하기 위한 약정은 없습니다. 언제든지 Cloud Service Mesh를 제거하고 Istio를 다시 설치할 수 있습니다.

마이그레이션에 실패하면 롤백할 수 있나요?

네, 스크립트를 사용하면 이전 Istio on GKE 버전으로 롤백할 수 있습니다.

이 스크립트를 사용하여 마이그레이션할 수 있는 Istio 버전은 무엇인가요?

이 스크립트는 Istio on GKE 버전 1.4에서 Cloud Service Mesh 버전 1.10으로 마이그레이션하는 데 도움이 됩니다. 스크립트는 마이그레이션 전 단계 중에 Istio 버전을 검증하고 Istio 버전을 마이그레이션할 수 있는지 여부를 알려줍니다.

마이그레이션과 관련하여 추가 도움을 받으려면 어떻게 해야 하나요?

지원팀이 기꺼이 도와드리겠습니다. Google Cloud 콘솔에서 지원 케이스를 열 수 있습니다. 자세한 내용은 지원 케이스 관리를 참조하세요.

Cloud Service Mesh로 마이그레이션하지 않으면 어떻게 되나요?

Istio 구성요소는 계속 작동하지만 Google은 더 이상 Istio 설치를 관리하지 않습니다. 더 이상 자동 업데이트를 받을 수 없으며 Kubernetes 클러스터 버전 업데이트로 설치가 보장되지 않습니다.

자세한 내용은 Istio 지원을 참조하세요.