GKE에서 설치 및 마이그레이션

이 가이드에서는 동일한 프로젝트에 있는 GKE 클러스터를 하나 이상 포함하는 메시의 Anthos Service Mesh 1.6.14 버전을 설치 또는 마이그레이션하는 방법을 설명합니다. Google 제공 스크립트를 사용하여 프로젝트 및 클러스터를 구성한 후 Anthos Service Mesh를 설치합니다.

이 가이드는 다음과 같은 사용 사례에 사용할 수 있습니다.

• Anthos Service Mesh 신규 설치. 이전 버전의 Anthos Service Mesh가 설치되어 있는 경우 GKE에서 Anthos Service Mesh 업그레이드를 참조하세요. 1.6 스크립트는 업그레이드를 처리하지 않습니다.

• 오픈소스 Istio 1.6 버전에서 Anthos Service Mesh로 마이그레이션. 이전 버전의 Istio에서의 마이그레이션은 지원되지 않습니다. 1.7 버전의 스크립트는 Istio 1.6 또는 1.7에서 Anthos Service Mesh 1.7로의 마이그레이션을 지원합니다. 마이그레이션을 한다면 Anthos Service Mesh 1.7로 마이그레이션하는 것이 좋습니다.

• Istio on GKE 부가기능의 버전 1.6에서 Anthos Service Mesh로 마이그레이션 Anthos Service Mesh로 마이그레이션하려면 먼저 Operator를 사용하여 Istio 1.6으로 업그레이드해야 합니다. 부가기능의 전체 마이그레이션 단계는 Istio on GKE 문서의 Anthos Service Mesh로 마이그레이션을 참조하세요.

다음 사용 사례에는 GKE에서 고급 설치 및 마이그레이션 가이드를 사용해야 합니다.

• asm-gcp 프로필에서 설정을 재정의하도록 설치를 맞춤설정해야 하며 오버레이 IstioOperator YAML 파일이 2개 이상 있는 경우입니다. 스크립트를 사용하면 YAMl 파일을 하나만 지정할 수 있습니다.

• 클러스터가 다른 프로젝트에 있는 멀티 클러스터 메시의 경우

시작하기 전에

이 가이드에서는 다음 작업을 이미 완료했다고 가정합니다.

• Google Cloud 프로젝트.
• Cloud Billing 계정
• 요구사항을 충족하는 GKE 클러스터

Istio에서 마이그레이션하는 경우 Istio에서 마이그레이션 준비를 참조하세요.

Anthos 및 Anthos Service Mesh 차이점

• GKE Enterprise 구독자는 GKE Enterprise API를 사용 설정해야 합니다.

  API 사용 설정하기

• GKE Enterprise 구독자가 아니어도 Anthos Service Mesh를 설치할 수 있지만 GKE Enterprise 구독자만 Google Cloud 콘솔의 특정 UI 요소와 기능을 사용할 수 있습니다. 구독자와 비구독자가 사용할 수 있는 항목에 대한 자세한 내용은 GKE Enterprise 및 Anthos Service Mesh UI 차이점을 참조하세요. 비구독자의 Anthos Service Mesh 가격 책정에 대한 자세한 내용은 가격 책정을 참조하세요.

요구사항

• GKE 클러스터는 다음 요구사항을 충족해야 합니다.

  • vCPU가 4개 이상 있는 머신 유형(예: e2-standard-4). 클러스터의 머신 유형에 4개 미만의 vCPU가 있으면 여러 머신 유형에 워크로드 마이그레이션에 설명된 대로 머신 유형을 변경합니다.

  • 최소 노드 수는 머신 유형에 따라 다릅니다. Anthos Service Mesh에는 최소 8개의 vCPU가 필요합니다. 머신 유형에 vCPU가 4개 있는 경우 클러스터에는 노드가 2개 이상 있어야 합니다. 머신 유형에 vCPU가 8개 있는 경우 클러스터에는 노드가 1개만 필요합니다. 노드를 추가해야 하는 경우 클러스터 크기 조절을 참조하세요.

  • 이 스크립트는 클러스터에서 워크로드 아이덴티티를 사용 설정합니다. 워크로드 아이덴티티는 Google API 호출에 권장되는 방법입니다. 워크로드 아이덴티티를 사용 설정하면 워크로드 아이덴티티 제한사항의 설명대로 워크로드에서 Google API로 호출이 보호되는 방식이 변경됩니다.

  • 선택사항이지만 출시 채널에 클러스터를 등록하는 것이 좋습니다. 다른 채널은 Anthos Service Mesh 1.6.14에서 지원되지 않는 GKE 버전을 기반으로 하는 경우가 있으므로 일반 출시 채널에 등록하는 것이 좋습니다. 자세한 내용은 지원되는 환경을 참조하세요. 정적 GKE 버전이 있는 경우 출시 채널에 기존 클러스터 등록의 안내를 따릅니다.

• 서비스 메시에 포함하려면 서비스 포트의 이름이 지정되어야 하며 이름은 name: protocol[-suffix] 구문에서 포트 프로토콜을 포함해야 합니다. 여기서 대괄호는 대시로 시작해야 하는 선택적 서픽스를 나타냅니다. 자세한 내용은 서비스 포트 이름 지정을 참조하세요.

• 비공개 클러스터에 Anthos Service Mesh를 설치하는 경우 자동 사이드카 삽입과 함께 사용되는 웹훅을 가져오려면 방화벽에서 포트 15017을 열어야 제대로 작동합니다. 자세한 내용은 비공개 클러스터에서 포트 열기를 참조하세요.

• 조직에서 서비스 경계를 만든 경우 경계에 Mesh CA 서비스를 추가해야 할 수도 있습니다. 자세한 내용은 서비스 경계에 Mesh CA 추가를 참조하세요.

• 마이그레이션의 경우 일반적으로 istiod가 istio-system 네임스페이스에 설치되어 있어야 합니다.

제한사항

Google Cloud 프로젝트에는 하나의 메시만 연결할 수 있습니다.

인증 기관 선택

신규 설치 및 마이그레이션의 경우 Anthos Service Mesh 인증 기관(Mesh CA) 또는 Citadel(현재 istiod에 통합됨)을 상호 TLS(mTLS) 인증서를 발급하는 인증 기관(CA)으로 사용할 수 있습니다.

일반적으로 다음과 같은 이유로 Mesh CA를 사용하는 것이 좋습니다.

• Mesh CA는 Google Cloud에서 동적으로 확장되는 워크로드에 최적화된 안정성과 확장성이 뛰어난 서비스입니다.
• Google은 Mesh CA를 사용하여 CA 백엔드의 보안과 가용성을 관리합니다.
• Mesh CA를 사용하면 여러 클러스터에서 신뢰할 수 있는 단일 루트를 사용할 수 있습니다.

Anthos Service Mesh를 새로 설치하는 경우 기본적으로 스크립트에서 Mesh CA를 사용 설정합니다.

하지만 다음과 같은 경우에는 Citadel을 사용하는 것이 좋을 수도 있습니다.

• 커스텀 CA가 있는 경우

• Istio 또는 GKE 부가기능의 Istio에서 마이그레이션하는 경우

  Citadel을 선택하면 마이그레이션 중에 mTLS 트래픽이 중단되지 않으므로 다운타임이 발생하지 않습니다. Mesh CA를 선택하면 모든 네임스페이스에서 모든 Pod를 다시 시작할 때까지 mTLS 트래픽이 실패하므로 마이그레이션의 다운타임을 예약해야 합니다.

Mesh CA의 인증서에는 애플리케이션 서비스에 대한 다음 데이터가 포함됩니다.

• Google Cloud 프로젝트 ID
• GKE 네임스페이스
• GKE 서비스 계정 이름

중요: Mesh CA에서 발급한 인증서는 서비스 메시 내에서 보안 서비스 간 통신을 사용 설정하는 데만 사용해야 하며 다른 용도로 사용되지 않아야 합니다. 이러한 인증서는 서비스가 상호 TLS를 사용하여 서로 통신하려고 시도할 때마다 전송됩니다. 서비스 메시 외부에서 통신할 때는 이러한 인증서를 사용하여 기밀 정보를 실수로 노출하지 않도록 해야 합니다.

필수 도구 설치

Cloud Shell 또는 Linux나 macOS를 실행하는 로컬 머신에서 스크립트를 실행할 수 있습니다. Cloud Shell은 모든 필수 도구를 사전 설치합니다.

스크립트를 로컬로 실행하려면 다음 안내를 따르세요.

1. 다음 도구가 설치되었는지 확인합니다.

   • Google Cloud CLI
   • 표준 명령줄 도구: awk, curl, grep, sed, sha256sum, tr
   • git
   • kpt
   • kubectl
   • jq

2. gcloud CLI로 인증합니다.

   gcloud auth login
   

3. 구성요소를 업데이트합니다.

   gcloud components update
   

4. kpt가 찾을 수 있도록 git가 경로에 있는지 확인합니다.

스크립트 실행

이 섹션에서는 스크립트를 다운로드하고, 필수 및 선택 매개변수를 설정하고, 스크립트를 실행하는 방법을 설명합니다. 스크립트의 기능에 대한 자세한 내용은 스크립트 이해를 참조하세요.

1. 스크립트를 현재 작업 디렉터리에 다운로드합니다.

   curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.6 > install_asm
   

2. 파일의 SHA-256을 현재 작업 디렉터리에 다운로드합니다.

   curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.6.sha256 > install_asm.sha256
   

3. 같은 디렉터리의 두 파일을 모두 사용하여 다운로드를 확인합니다.

   sha256sum -c --ignore-missing install_asm.sha256
   

   확인이 성공하면 명령어가 install_asm: OK를 출력합니다.

   호환성을 위해 install_asm.sha256 파일에는 모든 버전의 스크립트 이름을 install_asm으로 바꿀 수 있게 해주는 체크섬이 두 배로 포함됩니다. --ignore-missing이 없다는 오류가 발생하면 --ignore-missing 플래그를 사용하지 않고 이전 명령어를 다시 실행합니다.

4. 스크립트를 실행 가능하게 만듭니다.

   chmod +x install_asm
   

5. 옵션을 설정하고 플래그를 지정하여 스크립트를 실행합니다. 항상 project_id, cluster_name, cluster_location, mode 옵션을 포함합니다. mode에 따라 ca 옵션을 포함해야 할 수 있습니다.

   • project_id, cluster_name, cluster_location 옵션은 Anthos Service Mesh를 설치할 클러스터를 식별합니다.
   • mode는 install 또는 migrate 입니다.
   • ca는 인증 기관을 mesh_ca 또는 citadel로 지정합니다.

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

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

예시

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

검증만

다음 예시는 --only_validate 옵션을 사용한 스크립트 실행을 보여줍니다. 이 옵션을 사용하면 스크립트가 클러스터를 변경하지 않으며, Anthos Service Mesh를 설치하지 않습니다. 이 스크립트는 다음을 검증합니다.

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

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

1. asm-packages 디렉터리를 만듭니다.

   mkdir asm-packages
   

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

   ./install_asm \
   --project_id PROJECT_ID \
   --cluster_name CLUSTER_NAME \
   --cluster_location CLUSTER_LOCATION \
   --mode install \
   --output_dir ./asm-packages \
   --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
re-run the script with the '--enable_apis' flag to allow the script to enable
them on your behalf.

새 설치

다음 명령어는 새 설치를 위해 스크립트를 실행하고 Mesh CA(새 설치를 위한 기본 CA로 이 경우 ca 옵션이 필요하지 않음)를 사용 설정하며, 스크립트에서 필요한 Google API를 사용 설정할 수 있게 해줍니다.

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

오버레이 파일을 사용한 새 설치

다음 예시에서는 새 설치를 수행하고 선택적 기능을 사용 설정하는 YAML 파일을 포함합니다.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis \
  --operator_overlay egressgateways.yaml

Istio에서 마이그레이션

오픈소스 Istio에서 마이그레이션하는 경우 Citadel을 CA로 사용합니다. 다음 명령어는 Anthos Service Mesh로 마이그레이션하기 위한 스크립트를 실행하고 Citadel을 CA로 사용 설정합니다. 이 마이그레이션은 제어 영역만 배포합니다. 루트 CA는 변경되지 않으며 기존 워크로드에 지장을 주지 않습니다.

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

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m migrate \
  -c citadel \
  --enable_apis

옵션 및 플래그

옵션

-p|--project_id CLUSTER_PROJECT_ID

클러스터가 생성된 프로젝트의 프로젝트 ID입니다.

-n|--cluster_name CLUSTER_NAME

클러스터의 이름입니다.

-l|--cluster_location CLUSTER_LOCATION

클러스터가 생성된 영역(단일 영역 클러스터) 또는 리전(리전 클러스터용)입니다.

-m|--mode {install|migrate}

Anthos Service Mesh를 새로 설치하려면 install을 입력합니다. Istio 또는 Istio on GKE 부가기능에서 Anthos Service Mesh로 마이그레이션하려면 migrate를 입력합니다.

-c|--ca {mesh_ca|citadel}

신규 설치하는 경우 이 매개변수 기본값은 Mesh CA로 설정되며 개발자가 이 매개변수를 포함하지 않아도 됩니다. Istio에서 마이그레이션하는 경우 citadel 또는 mesh_ca를 지정해야 합니다. 마이그레이션 다운타임을 예약할 수 있는 경우 mesh_ca를 사용하는 것이 좋습니다. 마이그레이션 다운타임을 예약할 수 없으면 citadel을 사용합니다.

-o|--operator_overlay YAML_FILE

asm-gcp 프로필에서 사용 설정되지 않은 기능을 사용 설정하기 위한 YAML 파일의 이름입니다. 스크립트가 YAML 파일을 찾을 수 있어야 합니다. 따라서 파일은 스크립트와 같은 디렉터리에 있거나 ../manifests/asm-features.yaml와 같은 상대 경로를 지정할 수 있습니다.

-s|--service_account ACCOUNT

Anthos Service Mesh를 설치하는 데 사용되는 서비스 계정의 이름입니다. 지정하지 않으면 현재 gcloud 구성의 활성 사용자 계정이 사용됩니다. 활성 사용자 계정을 변경해야 하는 경우 gcloud auth login을 실행합니다.

-k|--key_file FILE PATH

서비스 계정의 키 파일입니다. 서비스 계정을 사용하지 않으면 이 옵션을 생략합니다.

-D|--output_dir DIR_PATH

지정하지 않으면, 스크립트가 Anthos Service Mesh 설치에 필요한 파일 및 구성을 다운로드할 임시 디렉터리를 만듭니다. 대신 사용할 기존 디렉터리를 지정하려면 --output-dir 플래그를 지정합니다. 완료되면 지정된 디렉터리에 asm 및 istio-1.6.14-asm.2 하위 디렉터리가 포함됩니다. asm 디렉터리에는 설치 구성이 포함됩니다. istio-1.6.14-asm.2 디렉터리에는 istioctl, 샘플, 매니페스트를 비롯한 설치 파일에서 추출한 콘텐츠가 포함됩니다.

플래그

-e|--enable_apis

스크립트가 Anthos Service Mesh에서 필요한 Google API를 사용 설정하도록 허용합니다. 이 플래그가 없는 경우 필수 API가 아직 사용 설정되지 않았으면 스크립트가 종료됩니다. 스크립트에서 사용 설정되는 API 목록은 set_up_project를 참조하세요.

-v|--verbose

명령어 실행 이전 및 이후를 출력합니다.

--dry_run

명령어를 출력하지만 실행하지는 않습니다.

--only_validate

유효성 검사를 실행하지만 Anthos Service Mesh를 설치하지 않습니다.

--disable_canonical_service

기본적으로 이 스크립트는 표준 서비스 컨트롤러를 클러스터에 배포합니다. 스크립트에서 컨트롤러를 배포하지 않으려면 --disable_canonical_service를 지정합니다. 자세한 내용은 표준 서비스 컨트롤러 사용 설정 및 중지를 참조하세요.

-h|--help

선택사항과 플래그를 설명하는 도움말 메시지를 표시하고 종료합니다.

워크로드 배포 및 재배포

자동 사이드카 프록시 삽입(자동 삽입)을 사용 설정해야 설치가 완료됩니다.

• 신규 설치의 경우 Anthos Service Mesh를 설치하기 전에 클러스터에서 실행 중인 모든 워크로드에 대해 자동 삽입을 사용 설정하고 pod를 다시 시작해야 합니다.

• Istio에서의 마이크레이션은 이중 제어 영역 업그레이드 프로세스(Istio 문서에서 '카나리아 업그레이드'라고 부름)를 따릅니다. 이중 제어 영역 업그레이드의 경우 스크립트가 기존 istiod와 함께 새 버전의 istiod를 설치합니다. 그런 후 워크로드 일부를 새 버전으로 이동합니다. 이 프로세스를 사용하면 모든 트래픽을 새 버전으로 마이그레이션하기 전 워크로드 일부로 새 버전의 효과를 모니터링할 수 있습니다.

• 새 워크로드를 배포하기 전에 자동 삽입을 사용 설정해야 Anthos Service Mesh가 트래픽을 모니터링하고 보호할 수 있습니다.

자동 주입을 사용 설정하려면 스크립트가 istiod에 적용된 버전 라벨을 가져오고 네임스페이스에 버전 라벨을 지정합니다. 다음 섹션에서는 자세한 내용을 설명합니다.

버전 라벨 가져오기

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

1. kubectl의 현재 컨텍스트를 설정합니다.

   gcloud container clusters get-credentials CLUSTER_NAME \
       --project=PROJECT_ID
   

   참고: 기본 영역 또는 리전을 설정하지 않았으면 명령어에 리전(--region=REGION) 또는 영역(--zone=ZONE)을 제공해야 합니다.

2. istiod에 라벨을 표시하여 스크립트가 설정한 버전 라벨을 가져옵니다.

   kubectl -n istio-system get pods -l app=istiod --show-labels
   

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

   NAME                                READY   STATUS    RESTARTS   AGE   LABELS
   istiod-7744bc8dd7-qhlss             1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
   istiod-asm-1614-2-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1614-2,istio=istiod,pod-template-hash=85d86774f7
   istiod-asm-1614-2-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1614-2,istio=istiod,pod-template-hash=85d86774f7

   출력의 LABELS 열 아래에서 istio.io/rev= 프리픽스 다음에 있는 istiod 버전 라벨의 값을 확인합니다. 이 예시에서는 값이 asm-1614-2이지만 다른 값을 사용할 수 있습니다.

   마이그레이션의 경우 이전 istiod 버전의 버전 라벨 값도 기록합니다. 마이그레이션을 완료할 때 istiod의 이전 버전을 삭제해야 합니다. 예시 출력에서는 버전 라벨에 있는 istiod의 이전 버전에 대한 값이 default이지만, 다른 값을 사용할 수 있습니다.

자동 삽입 사용 설정

자동 삽입을 사용 설정하려면 새 설치 및 마이그레이션에 다음 단계를 따르세요.

1. istiod에 대해 버전 라벨의 값을 가져옵니다.

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

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

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

   kubectl rollout restart deployment -n NAMESPACE

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

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

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

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

마이그레이션의 경우:

• 애플리케이션이 예상 대로 작동하여 만족스러우면 다음 섹션을 계속하여 istiod의 새 버전으로 변환을 완료합니다.

• 애플리케이션에 문제가 있으면 이전 버전으로 롤백 단계를 따릅니다.

전환 완료

마이그레이션의 경우 istiod의 이전 버전을 삭제해야 합니다. 애플리케이션이 예상대로 작동한다고 판단되면 이전 제어 영역을 삭제하여 새 버전으로의 전환을 완료합니다.

1. istiod의 이전 버전에 대해 버전 라벨의 값을 가져옵니다.

2. istiod의 이전 버전을 삭제합니다. 다음 명령어에서 OLD_REVISION을 이전 단계의 버전으로 바꿉니다.

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

   중요: Istio on GKE 부가기능에서 마이그레이션한 경우 클러스터에서 부가기능을 사용 설정된 상태로 유지해야 합니다. 부가기능을 사용 중지하면 istio-system 네임스페이스 및 그 안의 모든 리소스가 삭제됩니다.

이전 버전으로 롤백

마이그레이션의 경우 istiod의 새 버전으로 애플리케이션을 테스트할 때 문제가 발생하면 다음 단계에 따라 이전 버전으로 롤백합니다.

1. istiod의 이전 버전으로 삽입할 워크로드를 업데이트합니다.

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

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

   kubectl rollout restart deployment -n NAMESPACE

3. istio-ingressgateway의 이전 버전을 다시 배포합니다.

   kubectl -n istio-system rollout undo deploy istio-ingressgateway
   

4. 새 istiod를 삭제합니다.

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

5. --disable_canonical_service 플래그가 포함되지 않았으면 스크립트는 표준 서비스 컨트롤러를 사용 설정합니다. 표준 서비스 컨트롤러 사용 설정 및 중지의 단계를 따라 중지합니다.

Anthos Service Mesh 대시보드 보기

이 섹션은 asm-gcp 구성 프로필로 Anthos Service Mesh를 설치한 경우에만 적용됩니다. asm-gcp-multiproject 프로필을 사용하여 Anthos Service Mesh를 설치한 경우 Google Cloud 콘솔의 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 측정항목을 참조하세요.

클러스터 등록

Google Cloud 콘솔에서 통합 사용자 인터페이스에 액세스하려면 프로젝트 Fleet에 클러스터를 등록해야 합니다. Fleet에서는 Google Cloud 외부의 클러스터를 포함하여 클러스터와 워크로드를 통합된 방식으로 보고 관리할 수 있습니다.

클러스터 등록에 대한 자세한 내용은 Fleet에 클러스터 등록을 참조하세요.

스크립트 이해

안전한 Cloud Source Repositories 위치에서 스크립트를 다운로드하더라도 해당 스크립트는 GitHub에서도 사용할 수 있기 때문에 다운로드하기 전에 스크립트의 기능을 확인할 수 있습니다. 스크립트는 클러스터가 요구사항을 충족하는지 확인하고 GKE에 Anthos Service Mesh 설치 시 수동으로 수행하는 모든 단계를 자동화합니다.

validate_args 및 validate_dependencies

validate_args() {
  if [[ "${MODE}" == "install" && -z "${CA}" ]]; then
    CA="mesh_ca"
  fi

  local MISSING_ARGS=0
  while read -r REQUIRED_ARG; do
    if [[ -z "${!REQUIRED_ARG}" ]]; then
      MISSING_ARGS=1
      warn "Missing value for ${REQUIRED_ARG}"
    fi
    readonly "${REQUIRED_ARG}"
  done <<EOF

validate_dependencies() {
  validate_cli_dependencies

  validate_gcp_resources
  # configure kubectl does have side effects but we've generated a temprorary
  # kubeconfig so we're not breaking the promise that --only_validate gives
  configure_kubectl
  validate_expected_control_plane
  if [[ "${MODE}" = "migrate" ]]; then
    validate_istio_version
  fi
  if [[ "${ENABLE_APIS}" -eq 0 || "${ONLY_VALIDATE}" -eq 1 ]]; then
    exit_if_apis_not_enabled
  fi
}

validate_args 및 validate_dependencies 함수는 다음을 수행합니다.

• 모든 필수 도구가 설치되어 있는지 확인합니다.
• 매개변수 값으로 입력한 프로젝트 ID, 클러스터 이름, 클러스터 위치가 유효한지 확인합니다.
• 클러스터가 최소 필수 머신 유형과 노드 수를 충족하는지 확인합니다.

set_up_project

--enable_apis 플래그를 포함한 경우 set_up_project 함수가 필수 API를 사용 설정합니다.

required_apis() {
    cat << EOF
container.googleapis.com
compute.googleapis.com
monitoring.googleapis.com
logging.googleapis.com
cloudtrace.googleapis.com
meshca.googleapis.com
meshtelemetry.googleapis.com
meshconfig.googleapis.com
iamcredentials.googleapis.com
gkeconnect.googleapis.com
gkehub.googleapis.com
cloudresourcemanager.googleapis.com
EOF
}

set_up_cluster

set_up_cluster(){
  add_cluster_labels
  enable_workload_identity

  # this is project scope but requires workload identity
  if [[ "${CA}" = "mesh_ca" ]]; then
    init_meshca
  fi

  enable_stackdriver_kubernetes
  bind_user_to_cluster_admin
  ensure_istio_namespace_exists
}

set_up_cluster 함수는 클러스터를 다음과 같이 업데이트합니다.

• GKE 애플리케이션에서 Google Cloud 서비스에 안전하게 액세스하는 데 권장되는 워크로드 아이덴티티를 사용 설정합니다.

• GKE에서 Cloud Monitoring 및 Cloud Logging을 사용 설정합니다.

• Google Cloud 콘솔의 Anthos Service Mesh 페이지에 측정항목을 표시하는 데 필요한 mesh_id 라벨을 클러스터에서 설정합니다.

• 스크립트가 클러스터를 수정했는지 확인할 수 있도록 asmv=asm-1614-2과 같은 라벨을 설정합니다.

• 스크립트를 실행하는 GCP 사용자 또는 서비스 계정을 클러스터의 cluster-admin 역할에 결합합니다.

install_asm

install_asm(){

  local CA_OPT
  CA_OPT=""
  if [[ "${CA}" = "citadel" ]]; then
    CA_OPT="-citadel"
  fi

  info "Configuring kpt package..."
  run kpt cfg set asm gcloud.container.cluster "${CLUSTER_NAME}"
  run kpt cfg set asm gcloud.core.project "${PROJECT_ID}"
  run kpt cfg set asm gcloud.project.environProjectNumber "${PROJECT_NUMBER}"
  run kpt cfg set asm gcloud.compute.location "${CLUSTER_LOCATION}"
  run kpt cfg set asm anthos.servicemesh.rev "${REVISION_LABEL}"
  if [[ -n "${_CI_ASM_IMAGE_LOCATION}" ]]; then
    run kpt cfg set asm anthos.servicemesh.hub "${_CI_ASM_IMAGE_LOCATION}"
    run kpt cfg set asm anthos.servicemesh.tag "${RELEASE}"
  fi

  local PARAMS
  PARAMS="-f ${OPERATOR_MANIFEST}"
  if [[  -f "$CUSTOM_OVERLAY" ]]; then
    PARAMS="${PARAMS} -f ${CUSTOM_OVERLAY}"
  fi
  PARAMS="${PARAMS} --set revision=${REVISION_LABEL}"
  PARAMS="${PARAMS} -c ${KUBECONFIG}"

  info "Installing ASM control plane..."
  # shellcheck disable=SC2086
  retry 5 run ./"${ISTIOCTL_REL_PATH}" install $PARAMS

  # Prevent the stderr buffer from ^ messing up the terminal output below
  sleep 1
  info "...done!"

  if ! does_istiod_exist; then
    info "Installing validation webhook fix..."
    retry 3 run kubectl apply -f "${VALIDATION_FIX_SERVICE}"
  fi

  if [[ "$DISABLE_CANONICAL_SERVICE" -ne 1 ]]; then
    info "Installing ASM CanonicalService controller in asm-system namespace..."
    retry 3 run kubectl apply -f asm/canonical-service/controller.yaml
    info "Waiting for deployment..."
    retry 3 run kubectl wait --for=condition=available --timeout=600s \
        deployment/canonical-service-controller-manager -n asm-system
    info "...done!"
  fi

  outro
}

install_asm 함수는 다음을 수행합니다.

• kpt 패키지를 임시 디렉터리에 다운로드합니다.
• kpt setter를 실행하여 istio-operator.yaml 파일을 구성합니다.
• Anthos Service Mesh를 설치합니다.

1.7 스크립트와의 차이점

1.7 스크립트	1.6 스크립트
업그레이드를 지원합니다.	업그레이드를 하지 않습니다.
Istio 1.6 및 Istio 1.7에서의 마이그레이션을 지원합니다.	Istio 1.6에서의 마이그레이션을 지원합니다.
--print_config install_asm 스크립트를 사용하여 설치했을 때 사용한 구성을 제공합니다. 이 플래그를 사용하면 더욱 손쉽게 이전에 설치 시 사용한 구성과 동일한 구성으로 동일한 Anthos Service Mesh 버전을 다시 설치(스크립트가 허용하지 않음)할 수 있습니다.	해당 사항 없음
--custom_overlay 여러 오버레이 파일을 허용합니다.	--custom_overlay 하나의 오버레이 파일만 허용합니다.
--option GitHub의 asm 패키지에서 오버레이 파일을 가져옵니다.	없음
다음 옵션으로 커스텀 CA를 지원합니다. --ca_cert --ca_key --root_cert --cert_chain	없음