이 가이드에서는 동일한 프로젝트에 있는 GKE 클러스터를 하나 이상 포함하는 메시에 대해 Anthos Service Mesh 1.7.8 버전을 설치, 마이그레이션 또는 업그레이드하는 방법을 설명합니다. Google 제공 스크립트를 사용하여 프로젝트 및 클러스터를 구성한 후 Anthos Service Mesh를 설치합니다.
이 가이드와 다음 사용 사례를 위한 스크립트를 사용할 수 있습니다.
Anthos Service Mesh 신규 설치
Anthos Service Mesh 1.6 또는 1.7 패치 버전에서 업그레이드. 이전 버전에서의 업그레이드는 지원되지 않습니다.
오픈소스 Istio 1.6 또는 1.7에서 Anthos Service Mesh로 마이그레이션. 이전 버전의 Istio에서의 마이그레이션은 지원되지 않습니다.
Istio on GKE 부가기능의 버전 1.6에서 Anthos Service Mesh로 마이그레이션. Anthos Service Mesh로 마이그레이션하려면 먼저 Operator를 사용하여 Istio 1.6으로 업그레이드해야 합니다. 부가기능의 전체 마이그레이션 단계는 Istio on GKE 문서의 Anthos Service Mesh로 마이그레이션을 참조하세요.
클러스터가 다른 프로젝트에 있는 멀티 클러스터 메시에 대해서는 GKE에 대한 멀티 클러스터/멀티 프로젝트 설치 및 마이그레이션을 참조하세요.
시작하기 전에
이 가이드에서는 다음 항목이 있다고 가정합니다.
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 가격 책정에 대한 자세한 내용은 가격 책정을 참조하세요.
이 스크립트는 다른 모든 필수 Google API를 사용 설정합니다.
요구사항
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.7.8에서 지원되지 않는 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에서 마이그레이션하는 경우
Citadel을 선택하면 마이그레이션 중에 mTLS 트래픽이 중단되지 않으므로 다운타임이 발생하지 않습니다. Mesh CA를 선택하는 경우 신뢰할 수 있는 루트가 Citadel에서 Mesh CA로 변경되므로 마이그레이션을 위한 다운타임을 예약해야 합니다. Mesh CA 신뢰할 수 있는 루트로 마이그레이션을 완료하려면 모든 네임스페이스의 모든 pod를 다시 시작해야 합니다. 이 프로세스 중에는 이전 pod가 새 pod와 mTLS 연결을 설정할 수 없습니다.
Mesh CA의 인증서에는 애플리케이션 서비스에 대한 다음 데이터가 포함됩니다.
- Google Cloud 프로젝트 ID
- GKE 네임스페이스
- GKE 서비스 계정 이름
마이그레이션 또는 업그레이드 준비
Istio에서 마이그레이션하는 경우 Istio에서 마이그레이션 준비를 참조하세요.
이전 설치를 맞춤설정한 경우 Anthos Service Mesh를 마이그레이션하거나 업그레이드할 때 동일한 맞춤설정이 필요합니다. --set values 플래그를 추가하여 설치를 맞춤설정한 경우 해당 설정을 IstioOperator 구성 파일에 추가하는 것이 좋습니다. 스크립트를 실행할 때 구성 파일에 --custom_overlay를 사용하여 구성 파일을 지정합니다.
필수 도구 설치
이 스크립트는 Cloud Shell 또는 Linux를 실행하는 로컬 머신에서 실행할 수 있습니다.
스크립트를 로컬로 실행하려면 다음 안내를 따르세요.
다음 도구가 설치되었는지 확인합니다.
- Google Cloud CLI
- 표준 명령줄 도구:
awk,curl,grep,sed,sha256sum,tr - git
- kubectl
- jq
gcloud CLI로 인증합니다.
gcloud auth login구성요소를 업데이트합니다.
gcloud components updatekpt가 찾을 수 있도록git가 경로에 있는지 확인합니다.
스크립트 실행
이 섹션에서는 스크립트를 다운로드하고, 필수 및 선택 매개변수를 설정하고, 스크립트를 실행하는 방법을 설명합니다. 스크립트의 기능에 대한 자세한 내용은 스크립트 이해를 참조하세요.
Anthos Service Mesh 1.7.8를 현재 작업 디렉터리에 설치하는 스크립트 버전을 다운로드합니다.
curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.7 > install_asm보안 Cloud Source Repositories 위치에서 스크립트를 다운로드하지만 GitHub의 anthos-service-mesh-packages 저장소에서도 제공되므로, 다운로드하기 전 해당 기능을 확인할 수 있습니다.
release-1.7-asm분기의install_asm스크립트 버전은 Anthos Service Mesh 1.7.8를 설치합니다.파일의 SHA-256을 현재 작업 디렉터리에 다운로드합니다.
curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.7.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,upgrade입니다.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/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 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
Citadel을 CA로 사용하여 설치
이 섹션에서는 다음을 수행하는 방법을 설명합니다.
- Anthos Service Mesh가 워크로드에 서명하는 데 사용하는 인증서와 키 생성
- 설치 스크립트를 실행하고 Citadel을 CA로 사용 설정
커스텀 CA가 필요한 경우에만 Citadel을 CA로 사용하는 것이 좋습니다.
최고 수준의 보안을 위해 오프라인 루트 CA를 유지하고 하위 CA를 사용하여 각 클러스터의 CA를 발행하는 것이 좋습니다. 자세한 내용은 CA 인증서 플러그인을 참조하세요. 이 구성에서 서비스 메시의 모든 워크로드는 동일한 루트 CA를 사용합니다. 각 Anthos Service Mesh CA는 루트 CA에서 서명한 중간 CA 서명 키 및 인증서를 사용합니다. 하나의 메시 내에 여러 CA가 존재하는 경우 CA 간에 신뢰할 수 있는 계층 구조가 설정됩니다. 이 단계를 반복하여 여러 인증 기관의 인증서와 키를 프로비저닝할 수 있습니다.
인증서와 키의 디렉터리를 만듭니다.
mkdir -p certs && \ pushd certs
루트 인증서와 키를 생성합니다.
make -f ../tools/certs/Makefile.selfsigned.mk root-ca
그러면 다음 파일이 생성됩니다.
- root-cert.pem: 루트 인증서
- root-key.pem: 루트 키
- root-ca.conf: 루트 인증서를 생성하기 위한 openssl 구성
- root-cert.csr: 루트 인증서의 CSR
중간 인증서와 키를 생성합니다.
make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts
그러면
cluster1이라는 디렉터리에 이러한 파일이 생성됩니다.- ca-cert.pem: 중간 인증서
- ca-key.pem: 중간 키
- cert-chain.pem: istiod가 사용하는 인증서 체인
- root-cert.pem: 루트 인증서
오프라인 컴퓨터를 사용하여 이 단계를 수행하는 경우 생성된 디렉터리를 스크립트를 실행할 컴퓨터에 복사합니다.
스크립트를 실행하고 이전에 생성한 인증서 및 키에 대한 파일을 포함합니다.
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode install \ --ca citadel \ --ca_cert FILE_PATH \ --ca_key FILE_PATH \ --root_cert FILE_PATH \ --cert_chain FILE_PATH \ --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_apis \ --custom_overlay OVERLAY_FILE
옵션을 사용한 설치
다음 예시는 설치를 수행하고 이그레스 게이트웨이를 사용 설정하는 asm 패키지의 egressgateways.yaml 파일을 포함합니다. .yaml 확장 프로그램은 포함하지 않습니다. 이 스크립트는 asm 패키지를 먼저 다운로드할 필요가 없도록 파일을 가져옵니다.
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode install \ --enable_apis \ --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.7-asm asm
--output_dir 옵션을 지정한 검증만 예시를 실행한 경우 구성 파일이 asm/istio/options 아래의 지정된 출력 디렉터리에 있습니다.
Istio에서 마이그레이션
Citadel을 CA로 사용하여 Istio에서 마이그레이션하는 경우 Anthos Service Mesh로 마이그레이션한 후에도 계속 Citadel을 사용할 수 있습니다. 다음 명령어는 마이그레이션에 필요한 스크립트를 실행하고 Citadel을 CA로 사용 설정합니다. 이 마이그레이션은 제어 영역만 배포합니다. 루트 CA를 변경하지 않고 기존 워크로드를 중지하지 않습니다.
./install_asm \ -p PROJECT_ID \ -n CLUSTER_NAME \ -l CLUSTER_LOCATION \ -m migrate \ -c citadel \ --enable_apis
오버레이 파일을 사용하여 마이그레이션
오버레이 파일은 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 migrate \ --ca citadel \ --enable_all \ --custom_overlay OVERLAY_FILE
업그레이드
다음 명령어는 업그레이드할 스크립트를 실행합니다. 이 스크립트에서는 다른 CA로 변경이 허용되지 않으므로 ca 옵션을 포함할 필요가 없습니다.
./install_asm \ -p PROJECT_ID \ -n CLUSTER_NAME \ -l CLUSTER_LOCATION \ -m upgrade \ --enable_apis
오버레이 파일을 사용하여 업그레이드
오버레이 파일은 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 upgrade \ --enable_all \ --custom_overlay OVERLAY_FILE
옵션 및 플래그
이 섹션에서는 스크립트에 사용 가능한 인수를 설명합니다.
옵션
-p|--project_id CLUSTER_PROJECT_ID- 클러스터가 생성된 프로젝트의 프로젝트 ID입니다.
-n|--cluster_name CLUSTER_NAME- 클러스터의 이름입니다.
-l|--cluster_location CLUSTER_LOCATION- 클러스터가 생성된 영역(단일 영역 클러스터) 또는 리전(리전 클러스터용)입니다.
-m|--mode {install|migrate|upgrade}- Anthos Service Mesh를 설치하려면
install를 입력합니다. Istio에서 마이그레이션하는 경우migrate를 입력합니다. 기존 Anthos Service Mesh 설치를 새 버전으로 업그레이드하려면upgrade를 입력합니다. -c|--ca {mesh_ca|citadel}- 설치의 경우 Mesh CA를 사용하려면 스크립트가 기본적으로 Mesh CA로 설정되므로 이 옵션을 포함할 필요가 없습니다. 업그레이드의 경우 스크립트에서 CA 변경이 허용되지 않으므로 이 옵션을 포함할 필요가 없습니다. 마이그레이션의 경우에는
citadel또는mesh_ca를 지정합니다. 마이그레이션을 위한 다운타임을 예약할 수 있는 경우mesh_ca를 사용하는 것이 좋습니다. 사용할 CA에 대한 자세한 내용은 인증 기관 선택을 참조하세요. Citadel을 사용할 때 지정해야 하는 추가 옵션은 Citadel의 커스텀 인증서 옵션을 참조하세요. --co|--custom_overlay YAML_FILE- 기본적으로 사용 설정되지 않은 기능을 사용 설정하기 위한
IstioOperator커스텀 리소스(CR) YAML 파일의 이름입니다. 스크립트가 YAML 파일을 찾을 수 있어야 합니다. 따라서 파일이 스크립트와 동일한 디렉터리에 있어야 하거나, 상대 경로를 지정할 수도 있습니다. 여러 파일을 추가하려면--co|--custom_overlay및 파일 이름을 지정합니다(예:--co overlay_file1.yaml --co overlay_file2.yaml --co overlay_file3.yaml). -o|--option OPTION_FILEIstioOperatorCR이 포함된anthos-service-mesh패키지의 YAML 파일 이름으로서 선택적 기능을 사용 설정하는 데 사용됩니다. 이러한 파일 중 하나를 포함할 때는anthos-service-mesh패키지를 먼저 다운로드할 필요가 없으며.yaml확장 프로그램을 지정하지 않습니다. 파일을 수정해야 하면anthos-service-mesh패키지를 다운로드하고, 항목을 변경하고,--custom_overlay옵션을 사용합니다. 여러 파일을 추가하려면-o|--option및 파일 이름을 지정합니다(예:-o option_file1 -o option_file2 -o option_file3).-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.7.8-asm.10하위 디렉터리가 포함됩니다.asm디렉터리에는 설치 구성이 포함됩니다.istio-1.7.8-asm.10디렉터리에는istioctl, 샘플, 매니페스트를 비롯한 설치 파일에서 추출한 콘텐츠가 포함됩니다.
플래그
-e|--enable_apis- 스크립트가 Anthos Service Mesh에서 필요한 Google API를 사용 설정하도록 허용합니다. 이 플래그가 없는 경우 필수 API가 아직 사용 설정되지 않았으면 스크립트가 종료됩니다. 스크립트에서 사용 설정되는 API 목록은 set_up_project를 참조하세요.
-v|--verbose- 명령어 실행 이전 및 이후를 출력합니다.
--dry_run- 명령어를 출력하지만 실행하지는 않습니다.
--only_validate- 유효성 검증을 실행하지만 Anthos Service Mesh를 설치하지 않습니다.
--print_config- Anthos Service Mesh를 설치하는 대신 모든 컴파일된 YAML을 표준 출력(stdout)으로 출력합니다. 다른 모든 출력은 일반적으로 stdout으로 이동하더라도 표준 오류(stderr)에 기록됩니다. 이 플래그를 지정하면 스크립트는 모든 검증 및 설정을 건너 뜁니다.
--disable_canonical_service- 기본적으로 이 스크립트는 표준 서비스 컨트롤러를 클러스터에 배포합니다. 스크립트에서 컨트롤러를 배포하지 않으려면
--disable_canonical_service를 지정합니다. 자세한 내용은 표준 서비스 컨트롤러 사용 설정 및 중지를 참조하세요. -h|--help- 선택사항과 플래그를 설명하는 도움말 메시지를 표시하고 종료합니다.
--versioninstall_asm버전을 인쇄하고 종료합니다. 명령어가 버전을 출력하지 않으면 최신 버전의install_asm_1.7을 다운로드하세요.
Citadel의 커스텀 인증서 옵션
citadel을 지정했고 커스텀 CA를 사용하는 경우, 다음 옵션을 포함합니다.
--ca_cert FILE_PATH: 중간 인증서--ca_key FILE_PATH: 중간 인증서의 키--root_cert FILE_PATH: 루트 인증서--cert_chain FILE_PATH: 인증서 체인
자세한 내용은 기존 CA 인증서 연결을 참조하세요.
워크로드 배포 및 재배포
자동 사이드카 프록시 삽입(자동 삽입)을 사용 설정해야 설치가 완료됩니다.
신규 설치의 경우 자동 삽입을 사용 설정하고 Anthos Service Mesh 설치 전 클러스터에서 실행 중이던 워크로드에 대해 pod를 다시 시작해야 합니다.
마이그레이션 및 업그레이드는 이중 제어 영역 업그레이드 프로세스(Istio 문서에서 '카나리아 업그레이드'라고 부름)를 따릅니다. 이중 제어 영역 업그레이드의 경우 스크립트가 기존
istiod와 함께 새 버전의istiod를 설치합니다. 그런 후 워크로드 일부를 새 버전으로 이동합니다. 이 프로세스를 사용하면 모든 트래픽을 새 버전으로 마이그레이션하기 전 워크로드 일부로 새 버전의 효과를 모니터링할 수 있습니다.새 워크로드를 배포하기 전에 자동 삽입을 사용 설정해야 Anthos Service Mesh가 트래픽을 모니터링하고 보호할 수 있습니다.
자동 주입을 사용 설정하려면 스크립트가 istiod에 적용된 버전 라벨을 가져오고 네임스페이스에 버전 라벨을 지정합니다. 다음 섹션에서는 자세한 내용을 설명합니다.
버전 라벨 가져오기
스크립트는 istio.io/rev=asm-178-10 형식으로 istiod에 버전 라벨을 추가합니다. 자동 삽입을 사용 설정하려면 일치하는 버전 라벨을 네임스페이스에 추가합니다. 버전 라벨은 사이드카 인젝터 웹훅에서 삽입된 사이드카를 특정 istiod 버전과 연결하는 데 사용됩니다. 라벨을 추가한 후 사이드카를 삽입하려면 네임스페이스의 기존 pod를 다시 시작해야 합니다.
kubectl의 현재 컨텍스트를 설정합니다.gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_IDistiod에 라벨을 표시하여 스크립트가 설정한 버전 라벨을 가져옵니다.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-178-10-85d86774f7-flrt2 1/1 Running 0 26m app=istiod,istio.io/rev=asm-178-10,istio=istiod,pod-template-hash=85d86774f7 istiod-asm-178-10-85d86774f7-tcwtn 1/1 Running 0 26m app=istiod,istio.io/rev=asm-178-10,istio=istiod,pod-template-hash=85d86774f7
출력의
LABELS열 아래에서istio.io/rev=프리픽스 다음에 있는istiod버전 라벨의 값을 확인합니다. 이 예시에서는 값이 asm-178-10이지만 다른 값을 사용할 수 있습니다.업그레이드 및 마이그레이션의 경우에는 버전 라벨에서 이전
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에 자동 주입을 사용 설정하려면 네임스페이스의 라벨을 다시 지정합니다. 이전 버전에 버전 라벨을 사용했는지,istio-injection=enabled를 사용했는지에 따라 다른 명령어를 사용합니다.자동 삽입을 위해 버전 라벨을 사용한 경우:
kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwriteistio-injection=enabled를 사용한 경우: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플래그가 포함되지 않았으면 스크립트는 표준 서비스 컨트롤러를 사용 설정합니다. 표준 서비스 컨트롤러 사용 설정 및 중지의 단계를 따라 중지합니다.
동일한 버전 재설치
install_asm 스크립트는 istioctl install을 호출하여 설치, 업그레이드, Istio 마이그레이션을 위한 Anthos Service Mesh 제어 영역 구성요소(istiod 및 istio-ingressgateway)를 배포합니다. 스크립트에서 istioctl install을 사용하기 때문에 Anthos Service Mesh를 맞춤설정하여 선택적 기능을 사용 설정해야 하는 경우 새 구성으로 제어 영역을 다시 설치해야 합니다.
동일한 버전의 Anthos Service Mesh를 다시 설치할 수 있도록 install_asm 스크립트에 변경사항이 적용되었습니다. 선택적 기능을 사용 설정하기 위해 동일한 버전을 다시 설치하면 기존 제어 영역 구성을 덮어씁니다.
따라서 기존 설치를 맞춤설정한 경우 이전 설치와 동일한 --option 또는 --custom_overlay 옵션과 사용 설정하고 싶은 새 기능의 --option 또는 --custom_overlay 옵션을 포함해야 합니다.
Cloud Trace를 사용 설정하거나 추적 설정을 변경하는 경우 업데이트된 제어 영역 구성을 포함한 사이드카 프록시가 다시 삽입되도록 워크로드를 다시 배포해야 합니다.
동일한 버전을 다시 설치할 때는 설치와 마찬가지로 --mode install을 지정합니다. 스크립트를 사용하여 설치하는 방법에 대한 자세한 내용은 Anthos Service Mesh 설치를 참조하세요.
YAML 파일에 둘 이상의 IstioOperator 커스텀 리소스(CR)를 지정하면 install_asm은 파일을 여러 임시 YAML 파일(각 CR에 하나씩)로 분할합니다. istioctl install은 CR이 두 개 이상 포함된 YAML 파일에 첫 번째 CR만 적용하므로 스크립트는 CR을 여러 파일로 분할합니다.
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 설치 시 수동으로 수행하는 모든 단계를 자동화합니다.
Anthos Service Mesh 1.7.8에서 release-1.7-asm 분기에 install_asm 스크립트의 버전을 사용합니다. 버전 관리 및 출시 프로세스에 대한 설명은 버전 관리/출시를 참조하세요.
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-178-10과 같은 라벨을 설정합니다.스크립트를 실행하는 GCP 사용자 또는 서비스 계정을 클러스터의 cluster-admin 역할에 결합합니다.
install_asm
install_asm 함수는 다음을 수행합니다.
kpt패키지를 임시 디렉터리에 다운로드합니다.kptsetter를 실행하여istio-operator.yaml파일을 구성합니다.- Anthos Service Mesh를 설치합니다.