Anthos Service Mesh 설치

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

클러스터가 다른 프로젝트에 있는 멀티 클러스터 메시에 대해서는 GKE에 대한 멀티 클러스터/멀티 프로젝트 설치 및 마이그레이션을 참조하세요.

새로 설치하거나 구성이 다른 동일 버전을 재설치하는 Anthos Service Mesh 설치를 다룬 페이지입니다.

새 설치를 위한 스크립트 실행이 Istio에서 동일한 버전, 업그레이드, 마이그레이션을 다시 설치하는 것과 비슷하지만, 이러한 사용 사례에는 추가적인 계획이 포함됩니다. 자세한 내용은 다음을 참조하세요.

시작하기 전에

설치를 시작하기 전에 다음을 수행해야 합니다.

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

Anthos Service Mesh 설치

  1. 옵션을 설정하고 플래그를 지정하여 스크립트를 실행합니다. 항상 --project_id, --cluster_name, --cluster_location, --mode install 옵션을 포함합니다. Citadel을 CA로 사용하려면 Citadel을 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.

--only_validate 없이 스크립트를 실행할 때 사용 설정 플래그를 사용하여 스크립트를 실행해야 한다는 오류 메시지가 표시될 경우 오류 메시지의 특정 플래그 또는 --enable_all 플래그를 포함하면 됩니다. 원하는 경우 멀티 프로젝트 설치 가이드의 프로젝트 설정클러스터 설정 섹션에 설명된 대로, 스크립트를 실행하기 전에 프로젝트 및 클러스터를 직접 업데이트할 수 있습니다.

설치

다음 명령어는 신규 설치를 위해 스크립트를 실행하고 설치를 위한 기본 CA인 Mesh CA를 사용 설정하므로 이 경우에는 --ca 옵션이 필요하지 않습니다. --enable_all 플래그를 사용하면 스크립트가 필요한 Google API를 사용 설정하고, Identity and Access Management 권한을 설정하고, 클러스터에 필요한 업데이트를 적용할 수 있습니다. 여기에는 GKE 워크로드 아이덴티티 사용 설정이 포함됩니다.

Mesh CA를 사용하려는 경우 GKE 워크로드 아이덴티티 대신 Fleet 워크로드 아이덴티티 풀을 사용할 수 있습니다. 예시를 보려면 Fleet 워크로드 아이덴티티 풀로 Mesh CA 사용 설정을 참조하세요.

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

다음 항목을 포함할 수도 있습니다.

  • --output_dir DIR_PATH 유일한 검증 예시를 실행하지 않은 경우 이 옵션을 포함하여 스크립트가 asm 패키지 및 istioctl 샘플, 매니페스트를 포함하는 Anthos Service Mesh 설치 파일을 다운로드하는 기존 디렉터리를 지정합니다. 그렇지 않으면 스크립트가 asm 패키지 및 설치 파일을 임시 디렉터리에 다운로드합니다.

  • --enable-registration 이 플래그를 사용하면 스크립트에서 클러스터가 있는 프로젝트에 클러스터를 등록할 수 있습니다. 이 플래그를 포함하지 않는 경우에는 클러스터 등록의 단계에 따라 클러스터를 수동으로 등록합니다.

Citadel을 CA로 사용한 설치

이 섹션에서는 다음을 수행하는 방법을 설명합니다.

  • Anthos Service Mesh가 워크로드에 서명하는 데 사용하는 인증서와 키 생성
  • 설치 스크립트를 실행하고 Citadel을 CA로 사용 설정

커스텀 CA가 필요한 경우에만 Citadel을 CA로 사용하는 것이 좋습니다.

최고 수준의 보안을 위해 오프라인 루트 CA를 유지하고 하위 CA를 사용하여 각 클러스터의 CA를 발행하는 것이 좋습니다. 자세한 내용은 CA 인증서 플러그인을 참조하세요. 이 구성에서 서비스 메시의 모든 워크로드는 동일한 루트 CA를 사용합니다. 각 Anthos Service Mesh CA는 루트 CA에서 서명한 중간 CA 서명 키 및 인증서를 사용합니다. 하나의 메시 내에 여러 CA가 존재하는 경우 CA 간에 신뢰할 수 있는 계층 구조가 설정됩니다. 이 단계를 반복하여 여러 인증 기관의 인증서와 키를 프로비저닝할 수 있습니다.

  1. 인증서와 키의 디렉터리를 만듭니다.

    mkdir -p certs && \
    pushd certs
  2. 루트 인증서와 키를 생성합니다.

    make -f ../tools/certs/Makefile.selfsigned.mk root-ca
    

    그러면 다음 파일이 생성됩니다.

    • root-cert.pem: 루트 인증서
    • root-key.pem: 루트 키
    • root-ca.conf: 루트 인증서를 생성하기 위한 openssl 구성
    • root-cert.csr: 루트 인증서의 CSR
  3. 중간 인증서와 키를 생성합니다.

    make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts

    그러면 cluster1이라는 디렉터리에 이러한 파일이 생성됩니다.

    • ca-cert.pem: 중간 인증서
    • ca-key.pem: 중간 키
    • cert-chain.pem: istiod가 사용하는 인증서 체인
    • root-cert.pem: 루트 인증서

    오프라인 컴퓨터를 사용하여 이 단계를 수행하는 경우 생성된 디렉터리를 스크립트를 실행할 컴퓨터에 복사합니다.

  4. 스크립트를 실행하고 이전에 생성한 인증서 및 키에 대한 파일을 포함합니다.

    ./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_all \
  --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_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.8-asm asm

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

제품군을 사용하여 Mesh CA 사용 설정

제품군을 사용하는 Mesh CA 미리보기는 GKE 기반 Anthos Service Mesh의 신규 설치로 제한됩니다. 미리보기 중에는 업그레이드와 마이그레이션이 지원되지 않습니다.

이 예시에서는 제품군 워크로드 아이덴티티 풀을 사용하도록 Mesh CA를 사용 설정하는 방법을 보여줍니다. 제품군을 사용하는 Mesh CA를 사용하면 개별 Google Cloud 프로젝트의 클러스터를 제품군에 해당하는 단일 트러스트 도메인에 조인할 수 있습니다.

제품군을 사용하여 Mesh CA를 사용 설정하려면 다음 안내를 따르세요.

클러스터 등록을 아직 완료하지 않았으면 다음 예시와 같이 --enable-registration 플래그를 포함합니다.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_all \
  --enable-registration \
  --option hub-meshca

이 명령어는 신규 설치에 대한 스크립트를 실행하고 Anthos Service Mesh에서 필요한 옵션으로 프로젝트와 클러스터를 구성하고 클러스터가 있는 프로젝트에 클러스터를 등록하고 제품군 워크로드 아이덴티티 풀을 사용하도록 Mesh CA를 구성합니다.

워크로드 배포 및 재배포

Anthos Service Mesh는 사이드카 프록시를 사용하여 네트워크 보안, 안정성, 관측 가능성을 개선합니다. Anthos Service Mesh를 사용하면 이러한 함수가 애플리케이션의 기본 컨테이너에서 추상화되고 동일한 포드에서 별도의 컨테이너로 제공되는 공용 프로세스 외부 프록시로 구현됩니다.

자동 사이드카 프록시 삽입(자동 삽입)을 사용 설정하고 Anthos Service Mesh를 설치하기 전에 클러스터에서 실행 중이었던 모든 워크로드의 포드를 다시 시작해야 설치가 완료됩니다.

자동 삽입을 사용 설정하려면 Anthos Service Mesh를 설치할 때 istiod에 설정한 버전 라벨을 네임스페이스에 지정합니다. 버전 라벨은 사이드카 인젝터 웹훅에서 삽입된 사이드카를 특정 istiod 버전과 연결하는 데 사용됩니다. 라벨을 추가한 후 사이드카를 삽입하려면 네임스페이스의 기존 포드를 다시 시작해야 합니다.

새 네임스페이스에 새 워크로드를 배포하기 전에 자동 삽입을 구성해야 Anthos Service Mesh가 트래픽을 모니터링하고 보호할 수 있습니다.

자동 삽입을 사용 설정하려면 다음을 실행하세요.

  1. 다음 명령어를 사용하여 istiod에서 버전 라벨을 찾습니다.

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

    출력은 다음과 유사합니다.

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    istiod-asm-186-8-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-186-8,istio=istiod,pod-template-hash=5788d57586
    istiod-asm-186-8-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-186-8,istio=istiod,pod-template-hash=5788d57586

    출력의 LABELS 열 아래에서 istio.io/rev= 프리픽스 다음에 있는 istiod 버전 라벨의 값을 확인합니다. 이 예시에서 값은 asm-186-8입니다.

  2. 버전 라벨을 적용하고 istio-injection 라벨이 있는 경우 삭제합니다. 다음 명령어에서 NAMESPACE는 자동 삽입을 사용 설정할 네임스페이스의 이름이며 REVISION은 이전 단계에서 표시된 버전 라벨입니다.

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

    출력에서 "istio-injection not found" 메시지는 무시해도 됩니다. 즉, 네임스페이스에 이전에 istio-injection 라벨이 사용되지 않았으며, Anthos Service Mesh를 새로 설치하거나 새로 배포해야 합니다. 네임스페이스에 istio-injection 및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든 kubectl label 명령어에는 istio-injection 라벨 삭제가 포함됩니다.

  3. Anthos Service Mesh를 설치하기 전에 클러스터에서 워크로드를 실행 중인 경우 포드를 다시 시작하여 재삽입을 트리거합니다.

    포드를 다시 시작하는 방법은 애플리케이션과 클러스터가 있는 환경에 따라 달라집니다. 예를 들어 스테이징 환경에서 모든 포드를 간단히 삭제하면 다시 시작됩니다. 하지만 프로덕션 환경에서는 트래픽 중단을 방지하기 위해 포드를 안전하게 다시 시작할 수 있도록 블루-그린 배포를 구현하는 프로세스가 있을 수 있습니다.

    kubectl를 사용하여 순차적 재시작을 수행할 수 있습니다.

    kubectl rollout restart deployment -n NAMESPACE
    
  4. pod가 새 버전의 istiod를 가리키도록 구성되었는지 확인합니다.

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

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 측정항목을 참조하세요.

다음 단계