이 가이드에서는 동일한 프로젝트에 있는 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 파일을 하나만 지정할 수 있습니다.클러스터가 다른 프로젝트에 있는 멀티 클러스터 메시의 경우
시작하기 전에
이 가이드에서는 다음 작업을 이미 완료했다고 가정합니다.
Istio에서 마이그레이션하는 경우 Istio에서 마이그레이션 준비를 참조하세요.
Anthos 및 Anthos Service Mesh 차이점
GKE Enterprise 구독자는 GKE Enterprise 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를 사용하면 여러 클러스터에서 신뢰할 수 있는 단일 루트를 사용할 수 있습니다.
하지만 다음과 같은 경우에는 Citadel을 사용하는 것이 좋을 수도 있습니다.
- 커스텀 CA가 있는 경우
Istio 또는 GKE 부가기능의 Istio에서 마이그레이션하는 경우
Citadel을 선택하면 마이그레이션 중에 mTLS 트래픽이 중단되지 않으므로 다운타임이 발생하지 않습니다. Mesh CA를 선택하면 모든 네임스페이스에서 모든 Pod를 다시 시작할 때까지 mTLS 트래픽이 실패하므로 마이그레이션의 다운타임을 예약해야 합니다.
Mesh CA의 인증서에는 애플리케이션 서비스에 대한 다음 데이터가 포함됩니다.
- Google Cloud 프로젝트 ID
- GKE 네임스페이스
- GKE 서비스 계정 이름
필수 도구 설치
Cloud Shell 또는 Linux나 macOS를 실행하는 로컬 머신에서 스크립트를 실행할 수 있습니다. Cloud Shell은 모든 필수 도구를 사전 설치합니다.
스크립트를 로컬로 실행하려면 다음 안내를 따르세요.
다음 도구가 설치되었는지 확인합니다.
- Google Cloud CLI
- 표준 명령줄 도구:
awk
,curl
,grep
,sed
,sha256sum
,tr
- git
- kpt
- kubectl
- jq
gcloud CLI로 인증합니다.
gcloud auth login
구성요소를 업데이트합니다.
gcloud components update
kpt
가 찾을 수 있도록git
가 경로에 있는지 확인합니다.
스크립트 실행
이 섹션에서는 스크립트를 다운로드하고, 필수 및 선택 매개변수를 설정하고, 스크립트를 실행하는 방법을 설명합니다. 스크립트의 기능에 대한 자세한 내용은 스크립트 이해를 참조하세요.
스크립트를 현재 작업 디렉터리에 다운로드합니다.
curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.6 > install_asm
파일의 SHA-256을 현재 작업 디렉터리에 다운로드합니다.
curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.6.sha256 > install_asm.sha256
같은 디렉터리의 두 파일을 모두 사용하여 다운로드를 확인합니다.
sha256sum -c --ignore-missing install_asm.sha256
확인이 성공하면 명령어가
install_asm: OK
를 출력합니다.호환성을 위해
install_asm.sha256
파일에는 모든 버전의 스크립트 이름을install_asm
으로 바꿀 수 있게 해주는 체크섬이 두 배로 포함됩니다.--ignore-missing
이 없다는 오류가 발생하면--ignore-missing
플래그를 사용하지 않고 이전 명령어를 다시 실행합니다.스크립트를 실행 가능하게 만듭니다.
chmod +x install_asm
옵션을 설정하고 플래그를 지정하여 스크립트를 실행합니다. 항상
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
로 지정합니다.
다음 섹션에서는 스크립트를 실행하기 위한 일반적인 예시를 제공합니다. 스크립트 인수에 대한 자세한 설명은 옵션 및 플래그를 참조하세요.
Anthos Service Mesh 설정을 완료하려면 자동 사이드카 삽입을 사용 설정하고 워크로드를 배포 또는 다시 배포해야 합니다.
예시
이 섹션에서는 각 mode
에서 스크립트를 실행하는 예시와 유용할 수 있는 몇 가지 추가 인수를 보여줍니다. 예시 목록은 오른쪽 탐색 막대를 참조하세요.
검증만
다음 예시는 --only_validate
옵션을 사용한 스크립트 실행을 보여줍니다. 이 옵션을 사용하면 스크립트가 클러스터를 변경하지 않으며, Anthos Service Mesh를 설치하지 않습니다. 이 스크립트는 다음을 검증합니다.
- 환경에 필요한 도구가 있습니다.
- 지정된 프로젝트에 대해 필요한 권한이 있습니다.
- 클러스터가 최소 요구사항을 충족하는지 확인합니다.
- 프로젝트에 필요한 모든 Google API가 사용 설정되어 있는지 확인합니다.
기본적으로 스크립트가 설치 파일을 다운로드 및 추출하고 GitHub에서 asm
구성 패키지를 임시 디렉터리에 다운로드합니다. 종료하기 전 스크립트가 임시 디렉터리 이름이 표시된 메시지를 출력합니다.
--output_dir DIR_PATH
옵션을 사용하면 다운로드에 사용할 기존 디렉터리를 지정할 수 있습니다. --output_dir
옵션은 필요할 때 istioctl
명령줄 도구를 쉽게 사용할 수 있게 해줍니다.
asm-packages
디렉터리를 만듭니다.mkdir asm-packages
다음 명령어를 실행하여 구성을 검사하고 설치 파일 및
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는 변경되지 않으며 기존 워크로드에 지장을 주지 않습니다.
./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를 다시 시작해야 합니다.
kubectl
의 현재 컨텍스트를 설정합니다.gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID
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
이지만, 다른 값을 사용할 수 있습니다.
자동 삽입 사용 설정
자동 삽입을 사용 설정하려면 새 설치 및 마이그레이션에 다음 단계를 따르세요.
istiod
에 대해 버전 라벨의 값을 가져옵니다.버전 라벨을 네임스페이스에 추가하고
istio-injection
라벨을 삭제합니다. 다음 명령어에서REVISION
을istiod
의 버전과 일치하는 값으로 변경합니다.kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
pod를 다시 시작하여 재삽입을 트리거합니다.
kubectl rollout restart deployment -n NAMESPACE
pod가 새 버전의
istiod
를 가리키도록 구성되었는지 확인합니다.kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다.
다른 네임스페이스에 워크로드가 있으면 단계를 반복하여 네임스페이스에 라벨을 지정하고 Pod를 다시 시작합니다.
마이그레이션의 경우:
애플리케이션이 예상 대로 작동하여 만족스러우면 다음 섹션을 계속하여
istiod
의 새 버전으로 변환을 완료합니다.애플리케이션에 문제가 있으면 이전 버전으로 롤백 단계를 따릅니다.
전환 완료
마이그레이션의 경우 istiod
의 이전 버전을 삭제해야 합니다. 애플리케이션이 예상대로 작동한다고 판단되면 이전 제어 영역을 삭제하여 새 버전으로의 전환을 완료합니다.
istiod
의 이전 버전에 대해 버전 라벨의 값을 가져옵니다.istiod
의 이전 버전을 삭제합니다. 다음 명령어에서OLD_REVISION
을 이전 단계의 버전으로 바꿉니다.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
이전 버전으로 롤백
마이그레이션의 경우 istiod
의 새 버전으로 애플리케이션을 테스트할 때 문제가 발생하면 다음 단계에 따라 이전 버전으로 롤백합니다.
istiod
의 이전 버전으로 삽입할 워크로드를 업데이트합니다.kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
프록시에 이전 버전이 지정되도록 재삽입을 트리거하는 pod를 다시 시작합니다.
kubectl rollout restart deployment -n NAMESPACE
istio-ingressgateway
의 이전 버전을 다시 배포합니다.kubectl -n istio-system rollout undo deploy istio-ingressgateway
새
istiod
를 삭제합니다.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
--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에 대한 액세스 제어에 설명된 더 제한적인 역할을 부여해야 합니다.
Google Cloud 콘솔에서 Anthos Service Mesh로 이동합니다.
메뉴 바의 드롭다운 목록에서 Google Cloud 프로젝트를 선택합니다.
서비스 메시가 2개 이상 있으면 Service Mesh 드롭다운 목록에서 해당 메시를 선택합니다.
자세한 내용은 Google Cloud 콘솔에서 Anthos Service Mesh 탐색을 참조하세요.
Anthos Service Mesh 페이지 외에도 서비스와 관련된 측정항목(예: 특정 서비스에서 수신한 요청 수)이 Cloud Monitoring으로 전송되어 측정항목 탐색기에 표시됩니다.
측정항목을 보려면 다음 안내를 따르세요.
Google Cloud 콘솔에서 Monitoring 페이지로 이동합니다.
리소스 > 측정항목 탐색기를 선택합니다.
측정항목의 전체 목록은 Cloud Monitoring 문서의 Istio 측정항목을 참조하세요.
클러스터 등록
Google Cloud 콘솔에서 통합 사용자 인터페이스에 액세스하려면 프로젝트 Fleet에 클러스터를 등록해야 합니다. Fleet에서는 Google Cloud 외부의 클러스터를 포함하여 클러스터와 워크로드를 통합된 방식으로 보고 관리할 수 있습니다.
클러스터 등록에 대한 자세한 내용은 Fleet에 클러스터 등록을 참조하세요.
스크립트 이해
안전한 Cloud Source Repositories 위치에서 스크립트를 다운로드하더라도 해당 스크립트는 GitHub에서도 사용할 수 있기 때문에 다운로드하기 전에 스크립트의 기능을 확인할 수 있습니다. 스크립트는 클러스터가 요구사항을 충족하는지 확인하고 GKE에 Anthos Service Mesh 설치 시 수동으로 수행하는 모든 단계를 자동화합니다.
validate_args
및 validate_dependencies
validate_args
및 validate_dependencies
함수는 다음을 수행합니다.
- 모든 필수 도구가 설치되어 있는지 확인합니다.
- 매개변수 값으로 입력한 프로젝트 ID, 클러스터 이름, 클러스터 위치가 유효한지 확인합니다.
- 클러스터가 최소 필수 머신 유형과 노드 수를 충족하는지 확인합니다.
set_up_project
--enable_apis
플래그를 포함한 경우 set_up_project
함수가 필수 API를 사용 설정합니다.
set_up_cluster
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
함수는 다음을 수행합니다.
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를 지원합니다.
|
없음 |