Anthos Service Mesh를 최신 버전으로 업그레이드

이 페이지에서는 스크립트를 실행하여 동일한 Google Cloud 프로젝트에 있는 하나 이상의 클러스터가 포함된 메시의 GKE 클러스터에 모든 버전 및 패치 출시 버전 1.7.0 이상에서 Anthos Service Mesh 1.10.6으로 업그레이드하는 방법을 설명합니다.

다른 프로젝트에 있는 클러스터를 업그레이드하려면 GKE 멀티 프로젝트 가이드를 참조하세요.

이 페이지에서는 Anthos Service Mesh를 업그레이드할 수 있습니다. Istio에서 신규 설치 및 마이그레이션을 위한 스크립트 실행에 대한 자세한 내용은 다음을 참조하세요.

• Anthos Service Mesh 설치
• Istio에서 마이그레이션

시작하기 전에

업그레이드를 시작하기 전에 다음을 수행해야 합니다.

• 요구사항 검토
• 업그레이드 노트 읽기
• 클러스터 등록
• 필수 도구 설치
• 스크립트 다운로드

스크립트를 실행하려면 필요한 권한이 있거나 스크립트가 자동으로 권한을 사용 설정하도록 허용하는 --enable_all 플래그 또는 --enable_gcp_iam_roles 플래그를 포함해야 합니다. 마찬가지로 스크립트에서 필수 API를 사용 설정하고 클러스터를 업데이트하도록 하려면 --enable_all 플래그를 지정하거나 더욱 정교한 사용 설정 플래그를 지정합니다.

업그레이드 준비

이전 설치를 맞춤설정한 경우 새 Anthos Service Mesh 버전으로 업그레이드하거나 Istio에서 마이그레이션할 때 동일한 맞춤설정이 필요합니다. --set values 플래그를 istioctl install에 추가하여 설치를 맞춤설정한 경우 오버레이 파일이라고 부르는 IstioOperator YAML 파일에 이러한 설정을 추가해야 합니다. 스크립트를 실행할 때 해당 파일 이름으로 --custom_overlay 옵션을 사용해서 오버레이 파일을 지정합니다. 스크립트가 오버레이 파일을 istioctl install로 전달합니다.

주의: 오버레이 파일을 생략해도 설치가 성공합니다. 하지만 제어 영역 및 인그레스 게이트웨이가 다시 배포될 때 생략된 값이 기본값으로 재설정되기 때문에 서비스 메시에 의도한 것과 다른 구성이 포함됩니다.

참고: Anthos Service Mesh에서는 istioctl upgrade를 사용하는 인플레이스(In-Place) 업그레이드가 지원되지 않습니다.

스크립트는 버전 업그레이드 프로세스(Istio 문서에서 '카나리아' 업그레이드라고 부름)를 따릅니다. 버전 기반 업그레이드에서는 스크립트가 기존 제어 영역과 함께 제어 영역의 새 버전을 설치합니다. 새 버전을 설치할 때 스크립트에는 새 제어 영역을 식별하는 revision 라벨이 포함됩니다.

그런 후 새 Anthos Service Mesh 버전 및 구성이 사용되도록 워크로드에 동일한 revision 라벨을 설정하고 프록시를 다시 삽입하도록 연속 재시작을 수행하여 새 버전으로 마이그레이션합니다. 이 방식을 사용하면 일부 워크로드에서 업그레이드의 효과를 모니터링할 수 있습니다. 애플리케이션을 테스트한 후 모든 트래픽을 새 버전으로 마이그레이션할 수 있습니다. 이 방식은 새 제어 영역 구성요소가 이전 버전을 대체하는 인플레이스(In-Place) 업그레이드를 수행하는 것보다 훨씬 안전합니다.

Anthos Service Mesh 업그레이드

1. 옵션을 설정하고 플래그를 지정하여 스크립트를 실행합니다. 항상 project_id, cluster_name, cluster_location, mode 옵션을 포함합니다.

   참고: 업그레이드에 --mode install을 사용할 수 있습니다. --mode upgrade 대신 --mode install을 사용하면 install_asm이 클러스터의 제어 영역 버전에 관계없이 업그레이드를 허용합니다. upgrade 플래그는 이전 부 버전 또는 이전 패치 버전의 업그레이드만 허용합니다. 업그레이드에 `--mode install`을 사용하는 경우 클러스터에 현재 사용 설정된 동일한 인증 기관(CA)을 지정해야 합니다. CA를 변경하면 다운타임이 발생합니다.

   다음 섹션에서는 스크립트를 실행하기 위한 일반적인 예시를 제공합니다. 예시 목록은 오른쪽 탐색 막대를 참조하세요. 스크립트 인수에 대한 자세한 설명은 옵션 및 플래그를 참조하세요.

2. Anthos Service Mesh 설정을 완료하려면 자동 사이드카 삽입을 사용 설정하고 워크로드를 배포 또는 다시 배포해야 합니다.

예시

이 섹션에서는 업그레이드를 위한 스크립트 실행 예시와 몇 가지 유용할 수 있는 추가 인수를 보여줍니다. 예시 목록은 오른쪽 탐색 막대를 참조하세요.

검증만

다음 예시는 --only_validate 옵션을 사용한 스크립트 실행을 보여줍니다. 이 옵션을 사용하면 스크립트가 프로젝트 또는 클러스터를 변경하지 않으며 Anthos Service Mesh를 설치하지 않습니다. --only_validate를 지정하는 경우 --enable_* 플래그 중 하나라도 포함되어 있으면 스크립트가 실패합니다.

이 스크립트는 다음을 검증합니다.

• 환경에 필요한 도구가 있습니다.
• 지정된 프로젝트에 대해 필요한 권한이 있습니다.
• 클러스터가 최소 요구사항을 충족하는지 확인합니다.
• 프로젝트에 필요한 모든 Google API가 사용 설정되어 있는지 확인합니다.

기본적으로 스크립트가 설치 파일을 다운로드 및 추출하고 GitHub에서 asm 구성 패키지를 임시 디렉터리에 다운로드합니다. 종료하기 전 스크립트가 임시 디렉터리 이름이 표시된 메시지를 출력합니다. --output_dir DIR_PATH 옵션을 사용하여 다운로드 디렉터리를 지정할 수 있습니다. --output_dir 옵션은 필요할 때 istioctl 명령줄 도구를 쉽게 사용할 수 있게 해줍니다. 또한 선택적인 기능을 사용 설정하기 위한 구성 파일이 asm/istio/options 디렉터리에 포함됩니다.

다음 명령어를 실행하여 구성을 검증하고 설치 파일 및 asm 패키지를 OUTPUT_DIR 디렉터리에 다운로드합니다.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --output_dir DIR_PATH \
  --only_validate

성공하면 스크립트가 다음을 출력합니다.

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

검증 테스트 중 하나가 실패하면 스크립트가 오류 메시지를 출력합니다. 예를 들어 프로젝트에 모든 필요한 Google API가 사용 설정되지 않았으면 다음 오류가 표시됩니다.

ERROR: One or more APIs are not enabled. Please enable them and retry, or run
the script with the '--enable_gcp_apis' flag to allow the script to enable them
on your behalf.

사용 설정 플래그로 스크립트를 실행해야 한다는 오류 메시지가 표시되는 경우 다음 중 필요한 조치를 취할 수 있습니다.

• 실제 설치를 수행하기 위해 스크립트를 실행할 때 오류 메시지의 특정 플래그 또는 --enable_all 플래그를 포함합니다(즉, --only_validate 제외).

• 원하는 경우 GKE에 Anthos Service Mesh 설치 설정에 설명된 대로 스크립트를 실행하기 전에 프로젝트 및 클러스터를 직접 업데이트할 수 있습니다.

install_asm은 --only_validate가 있는 사용 설정 플래그를 허용하지 않습니다.

업그레이드

다음 명령어는 업그레이드할 스크립트를 실행합니다. 이 스크립트에서는 다른 CA로 변경이 허용되지 않으므로 ca 옵션을 포함할 필요가 없습니다.

주의: 이전 설치를 맞춤설정한 경우 --custom_overlay 옵션을 사용하여 하나 이상의 IstioOperator 구성 파일을 지정해야 합니다. 구성 파일을 생략하면 Anthos Service Mesh가 기본값으로 다시 재설정됩니다.

./install_asm \
  --project_id  PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_all

오버레이 파일로 업그레이드

오버레이 파일은 IstioOperator 커스텀 리소스(CR)를 포함하는 YAML 파일로 제어 영역을 구성하기 위해 install_asm에 전달합니다. 기본 제어 영역 구성을 재정의하고 YAML 파일을 install_asm에 전달하여 선택적 기능을 사용 설정할 수 있습니다. 오버레이를 더 많이 추가할 수 있으며 각 오버레이 파일은 이전 레이어의 구성을 재정의합니다.

YAML 파일에 둘 이상의 CR을 지정하면 install_asm은 파일을 여러 임시 YAML 파일(각 CR에 하나씩)로 분할합니다. istioctl install은 CR이 두 개 이상 포함된 YAML 파일에 첫 번째 CR만 적용하므로 스크립트는 CR을 여러 파일로 분할합니다.

다음 예시는 업그레이드를 수행하며 제어 영역 구성을 맞춤설정하는 오버레이 파일을 포함합니다. 다음 명령어에서 OVERLAY_FILE을 YAML 파일의 이름으로 변경합니다.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_all \
  --custom_overlay OVERLAY_FILE

옵션을 사용하여 업그레이드

다음 예시는 업그레이드를 수행하고 이그레스 게이트웨이를 사용 설정하는 anthos-service-mesh 패키지의 egressgateways.yaml 파일을 포함합니다. .yaml 확장 프로그램은 포함하지 않습니다. 이 스크립트는 asm 패키지를 먼저 다운로드할 필요가 없도록 파일을 가져옵니다.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_all \
  --option egressgateways

--option을 사용하여 선택적 기능을 사용 설정할 수 있습니다. asm 패키지의 asm/istio/options 디렉터리에서 파일을 수정해야 할 경우 asm 패키지를 다운로드하고, 항목을 변경한 후 --custom_overlay를 사용하여 파일을 포함합니다.

파일을 수정할 수 있도록 asm 패키지를 현재 작업 디렉터리에 다운로드하려면 다음 안내를 따르세요.

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.10-asm asm

--output_dir 옵션을 지정한 검증만 예시를 실행한 경우 구성 파일이 asm/istio/options 아래의 지정된 출력 디렉터리에 있습니다.

워크로드 배포 및 재배포

자동 사이드카 프록시 삽입(자동 삽입)을 사용 설정해야 설치가 완료됩니다. OSS Istio에서 마이그레이션 및 업그레이드는 버전 기반 업그레이드 프로세스(Istio 문서의 '카나리아 업그레이드')를 따릅니다. 버전 기반 업그레이드에서는 새 버전의 제어 영역이 기존 제어 영역과 함께 설치됩니다. 그런 후 일부 워크로드를 새 버전으로 이동하여, 모든 트래픽을 새 버전으로 마이그레이션 하기 전 워크로드 일부에서 업그레이드 효과를 모니터링합니다.

이 스크립트는 버전 라벨을 istio.io/rev=asm-1106-2 형식으로 istiod에 설정합니다. 자동 삽입을 사용 설정하려면 일치하는 버전 라벨을 네임스페이스에 추가합니다. 버전 라벨은 사이드카 인젝터 웹훅에서 삽입된 사이드카를 특정 istiod 버전과 연결하는 데 사용됩니다. 라벨을 추가한 후 사이드카를 삽입할 네임스페이스에서 pod를 다시 시작합니다.

1. istiod 및 istio-ingressgateway에 있는 버전 라벨을 가져옵니다.

   kubectl get pod -n istio-system -L istio.io/rev
   

   명령어 출력은 다음과 비슷합니다.

   NAME                                             READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-65d884685d-6hrdk            1/1     Running   0          67m
   istio-ingressgateway-65d884685d-94wgz            1/1     Running   0          67m
   istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-1106-2
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1106-2
   istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-198-3
   istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-198-3
   istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1106-2
   istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1106-2

   1. 출력의 REV 열에서 새 버전에 대한 버전 라벨 값을 확인합니다. 이 예시에서 값은 asm-1106-2입니다.

   2. 또한 이전 istiod 버전의 버전 라벨 값을 기록해 두세요. 워크로드를 새 버전으로 이동하고 나면 istiod의 이전 버전을 삭제할 때 필요합니다. 예시 출력에서 이전 버전의 버전 라벨 값은 asm-198-3입니다.

2. istio-ingressgateway를 새 버전으로 전환합니다. 다음 명령어에서 REVISION을 새 버전의 버전 라벨과 일치하는 값으로 변경합니다.

   kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'

   예상 출력: service/istio-ingressgateway patched

3. 네임스페이스에 버전 라벨을 추가하고 istio-injection 라벨을 삭제합니다(있는 경우). 다음 명령어에서 REVISION을 istiod의 새 버전과 일치하는 값으로 변경합니다.

   kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

   출력에 "istio-injection not found"가 표시되면 무시해도 됩니다. 이것은 이전에 네임스페이스에 istio-injection 라벨이 없음을 의미합니다. 네임스페이스에 istio-injection 및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든 kubectl label 명령어에는 istio-injection 라벨 삭제가 포함됩니다.

4. pod를 다시 시작하여 재삽입을 트리거합니다.

   kubectl rollout restart deployment -n NAMESPACE

5. pod가 새 버전의 istiod를 가리키도록 구성되었는지 확인합니다.

   kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION

6. 애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다.

7. 다른 네임스페이스에 워크로드가 있으면 단계를 반복하여 네임스페이스에 라벨을 지정하고 pod를 다시 시작합니다.

8. 애플리케이션이 예상대로 만족스럽게 작동한다면 계속해서 남은 단계를 진행하여 istiod의 새 버전으로의 전환합니다. 애플리케이션에 문제가 있는 경우 롤백 단계를 따르세요.

   전환 완료

   애플리케이션이 예상 대로 작동하여 만족스러우면 이전 제어 영역을 삭제하여 새 버전으로의 변환을 완료합니다.

   1. anthos-service-mesh GitHub 저장소의 파일이 있는 디렉터리로 변경합니다.

   2. 새 제어 영역을 사용하도록 검증 웹훅을 구성합니다.

      kubectl apply -f asm/istio/istiod-service.yaml
      

   3. 이전 istio-ingressgateway 배포를 삭제합니다. 실행하는 명령어는 Istio에서 마이그레이션하는지 또는 이전 버전의 Anthos Service Mesh에서 업그레이드하는지에 따라 달라집니다.

      마이그레이션

      Istio에서 마이그레이션한 경우 이전 istio-ingressgateway에는 버전 라벨이 없습니다.

      kubectl delete deploy/istio-ingressgateway -n istio-system
      

      업그레이드

      이전 Anthos Service Mesh 버전에서 업그레이드한 경우 다음 명령어에서 OLD_REVISION을 이전 버전의 istio-ingressgateway에 대한 버전 라벨로 바꿉니다.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
      

   4. istiod의 이전 버전을 삭제합니다. 사용하는 명령어는 Istio에서 마이그레이션하는지 또는 이전 버전의 Anthos Service Mesh에서 업그레이드하는지에 따라 다릅니다.

      마이그레이션

      Istio에서 마이그레이션한 경우 이전 istio-ingressgateway에는 버전 라벨이 없습니다.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
      

      업그레이드

      이전 Anthos Service Mesh 버전에서 업그레이드한 경우 다음 명령어에서 OLD_REVISION이 이전 버전의 istiod에 대한 버전 라벨과 일치하는지 확인합니다.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
      

   5. IstioOperator 구성의 이전 버전을 삭제합니다.

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
      

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

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

   롤백

   istiod의 새 버전으로 애플리케이션을 테스트할 때 문제가 발생하면 다음 안내에 따라 이전 버전으로 롤백하세요.

   1. istio-ingressgateway의 이전 버전으로 다시 전환합니다. 다음 명령어에서 OLD_REVISION을 이전 버전으로 바꿉니다.

      kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
      

   2. 이전 버전의 istiod에 자동 삽입을 사용 설정하려면 네임스페이스의 라벨을 다시 지정합니다. 이전 버전에 버전 라벨을 사용했는지, istio-injection=enabled를 사용했는지에 따라 다른 명령어를 사용합니다.

      • 자동 삽입을 위해 버전 라벨을 사용한 경우:

        kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
        

      • istio-injection=enabled를 사용한 경우:

        kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
        

      예상 출력:

      namespace/NAMESPACE labeled

   3. 네임스페이스의 버전 라벨이 이전 버전 istiod의 버전 라벨과 일치하는지 확인합니다.

      kubectl get ns NAMESPACE --show-labels
      

   4. 프록시에 이전 버전이 지정되도록 재삽입을 트리거하는 포드를 다시 시작합니다.

      kubectl rollout restart deployment -n NAMESPACE
      

   5. 새로운 istio-ingressgateway 배포를 삭제합니다. 다음 명령어의 REVISION 값이 올바른지 확인합니다.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
      

   6. istiod의 새 버전을 삭제합니다. 다음 명령어의 REVISION 값이 올바른지 확인합니다.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
      

   7. IstioOperator 구성의 새 버전을 삭제합니다.

      kubectl delete IstioOperator installed-state-REVISION -n istio-system
      

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

      istiooperator.install.istio.io "installed-state-REVISION" deleted

   8. --disable_canonical_service 플래그가 포함되지 않았으면 스크립트는 표준 서비스 컨트롤러를 사용 설정합니다. 사용 설정 상태로 두는 것이 좋지만 사용 중지해야 하는 경우 표준 서비스 컨트롤러 사용 설정 및 중지를 참조하세요.

Anthos Service Mesh 대시보드 보기

사이드카 프록시가 삽입된 클러스터에 워크로드가 배포되면 Google Cloud Console의 Anthos Service Mesh 페이지에서 Anthos Service Mesh에서 제공하는 모든 관측 가능성 기능을 볼 수 있습니다. 워크로드를 배포한 후 Google Cloud 콘솔에 원격 분석 데이터가 표시되는 데 약 1~2분 정도가 걸립니다.

Google Cloud 콘솔에서 Anthos Service Mesh에 대한 액세스는 Identity and Access Management(IAM)로 제어됩니다. Anthos Service Mesh 페이지에 액세스하려면 프로젝트 소유자가 사용자에게 프로젝트 편집자 또는 뷰어 역할이나 Google Cloud 콘솔에서 Anthos Service Mesh에 대한 액세스 제어에 설명된 더 제한적인 역할을 부여해야 합니다.

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

   Anthos Service Mesh로 이동

2. 메뉴 바의 드롭다운 목록에서 Google Cloud 프로젝트를 선택합니다.

3. 서비스 메시가 2개 이상 있으면 Service Mesh 드롭다운 목록에서 해당 메시를 선택합니다.

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

Anthos Service Mesh 페이지 외에도 서비스와 관련된 측정항목(예: 특정 서비스에서 수신한 요청 수)이 Cloud Monitoring으로 전송되어 측정항목 탐색기에 표시됩니다.

측정항목을 보려면 다음 안내를 따르세요.

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

   모니터링으로 이동

2. 리소스 > 측정항목 탐색기를 선택합니다.

측정항목의 전체 목록은 Cloud Monitoring 문서의 Istio 측정항목을 참조하세요.

다음 단계

• Online Boutique 샘플 애플리케이션 배포
• 멀티 클러스터 메시 설정