Anthos Service Mesh에 Compute Engine 가상 머신 추가

소개

Anthos Service Mesh를 사용하면 메시의 Google Kubernetes Engine(GKE) 클러스터에서 실행되는 서비스와 함께 관리형 인스턴스 그룹(MIG)에서 실행되는 서비스를 관리, 관측, 보호할 수 있습니다. 이를 통해 메시에서 Compute Engine 인스턴스에 다음을 수행할 수 있습니다.

  • 트래픽을 관리합니다.
  • mTLS를 시행합니다.
  • 서비스 트래픽에 액세스 제어를 적용합니다.
  • Google Cloud 서비스에 안전하게 액세스합니다.
  • 측정항목, 로깅, 추적 데이터를 수집합니다.
  • Google Cloud Console을 사용하여 서비스를 모니터링합니다.

이렇게 하면 컨테이너화가 적합하지 않거나 준비되지 않은 기존 애플리케이션에서 Anthos Service Mesh 기능을 활용할 수 있으며, 해당 워크로드를 나머지 서비스와 통합할 수 있습니다.

작동 방식

ASM은 가상 머신 워크로드를 나타내기 위해 두 가지 관련된 커스텀 리소스 정의(CRD)를 제공합니다.

  • WorkloadGroup은 공통 속성을 공유하는 가상 머신 워크로드의 논리적 그룹을 나타냅니다. 이것은 Kubernetes의 배포와 비슷합니다.
  • WorkloadEntry는 가상 머신 워크로드의 단일 인스턴스를 나타냅니다. 이것은 Kubernetes의 Pod와 비슷합니다.
  • 그런 후 Service가 WorkloadGroup을 선택하고 ASM이 Pod와 비슷한 방식으로 VM 인스턴스에 트래픽을 라우팅하도록 지정할 수 있습니다. 이렇게 하면 VM이 메시의 다른 워크로드처럼 작동할 수 있습니다.

각 Compute Engine 인스턴스 그룹에 대해 Compute Engine 인스턴스 템플릿을 만듭니다. 이 템플릿은 해당 그룹에 있는 각 Compute Engine 인스턴스에 대해 서비스 프록시 에이전트를 지정합니다. 설치 중 에이전트는 서비스 프록시를 부트스트랩하고, 트래픽 가로채기를 설정하고, Compute Engine 인스턴스의 수명 주기 동안 서비스 프록시 상태를 모니터링합니다. 프록시는 Anthos Service Mesh 제어 영역과 연결되고, 그런 후 각 Compute Engine 인스턴스를 해당 WorkloadGroup에 대한 WorkloadEntry로 자동으로 등록합니다. 이렇게 해서 클러스터의 Kubernetes 포드와 같이 Anthos Service Mesh가 각 인스턴스를 서비스 엔드포인트로 취급할 수 있습니다. 또한 Kubernetes Pod에서와 같이 VM 워크로드에 대해 Kubernetes 서비스를 만들 수 있습니다.

최소 MIG 크기 0부터 시작하여 Compute Engine 인스턴스에서 워크로드 수를 확장하거나 축소하려면 인스턴스 그룹 자동 확장을 참조하세요.

서비스 프록시 에이전트는 VM Manager를 사용하여 에이전트가 MIG의 각 VM에 설치되었는지 확인합니다. 인스턴스 그룹 및 VM 관리에 대한 자세한 내용은 관리형 인스턴스 그룹(MIG) 및 VM Manager를 참조하세요.

지원되는 Linux 배포판

OS 버전 지원
Debian 10
Debian 9
Centos 8
Centos 7

OS 배포에 대한 자세한 내용은 Debian 지원 또는 CentOS 지원을 참조하세요.

제한사항

  • 메시 제어 영역은 Anthos Service Mesh 1.9 이상이어야 합니다.
  • Compute Engine 인스턴스 템플릿에서 생성된 Compute Engine 관리형 인스턴스 그룹만 지원됩니다.
  • 클러스터 및 VM은 동일한 네트워크, 동일한 프로젝트에 있어야 하며, 단일 네트워크 인터페이스를 사용해야 합니다.
  • GKE Enterprise를 구독하지 않고도 이 기능을 사용할 수 있지만 Google Cloud 콘솔의 특정 UI 요소와 기능은 GKE Enterprise 구독자에게만 제공됩니다. 구독자와 비구독자가 사용할 수 있는 항목에 대한 자세한 내용은 GKE Enterprise 및 Anthos Service Mesh UI 차이점을 참조하세요.

기본 요건

시작하기 전에 다음과 같은 기본 요건을 확인하세요.

클러스터

이 페이지에는 해당 단계 중에 Anthos Service Mesh를 설치하거나 Anthos Service Mesh가 이미 설치된 클러스터를 업데이트하기 위한 옵션이 포함되어 있습니다. 어느 경우에든 이러한 단계를 수행하기 위해서는 Anthos Service Mesh 1.9 이상 버전 및 요구사항을 충족하는 클러스터가 필요합니다. 또한 Anthos Service Mesh VM 지원을 위한 추가 요구사항은 다음과 같습니다.

  • 사용자가 제어하는 클러스터에 제어 영역을 설치해야 합니다. Google 관리 제어 영역은 지원되지 않습니다. 자세한 내용은 Google 관리 제어 영역을 참조하세요.
  • Mesh CA를 인증 기관으로 사용합니다.
  • 원격 분석을 위해 Stackdriver를 사용합니다.
  • 표준 서비스 배포를 사용 설정하여, Anthos Service Mesh 설치 프로세스에서 자동으로 사용 설정합니다.

클러스터를 제품군에 등록해야 합니다. 하지만 아직 등록되지 않았으면 VM 설치 프로세스가 지정된 프로젝트에 이를 등록할 수 있습니다.

GKE Enterprise 구독자인 경우 GKE Enterprise API를 사용 설정합니다.

API 사용 설정하기

CLI 도구

설치 프로세스에는 Google Cloud Shell을 사용하는 경우 이미 설치되어 있는 다음 도구가 필요합니다.

  • gcloud
  • kubectl
  • kpt
  • curl
  • jq
  • awk
  • printf
  • tr
  • grep
  • tail

스크립트 다운로드

이 섹션에서는 VM 온보딩을 위해 스크립트를 다운로드하는 방법을 설명합니다.

  1. Anthos Service Mesh 1.9.8를 위한 VM 스크립트를 현재 작업 디렉터리에 다운로드합니다.

    curl https://storage.googleapis.com/csm-artifacts/asm/asm_vm_1.9 > asm_vm

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

    curl https://storage.googleapis.com/csm-artifacts/asm/asm_vm_1.9.sha256 > asm_vm.sha256

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

    sha256sum -c --ignore-missing asm_vm.sha256

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

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

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

    chmod +x asm_vm

시작하기

이 섹션에서는 Compute Engine 인스턴스를 Anthos Service Mesh에 추가하기 위한 단계를 설명합니다.

환경 설정

  1. 아래의 일부 단계에서는 클러스터에서 직접 변경해야 하기 때문에 gcloud를 사용하여 지정한 클러스터를 가리키도록 kubectl 도구를 구성합니다.

    gcloud container clusters get-credentials CLUSTER_NAME --zone CLUSTER_LOCATION --project PROJECT_ID

클러스터 준비

Anthos Service Mesh 1.9 이상 버전 제어 영역을 준비하여 VM에 대해 Anthos Service Mesh 클러스터를 설정합니다.

Anthos Service Mesh 1.9 이상 버전이 클러스터에 이미 설치되었는지 여부에 따라 다음 단계를 선택합니다.

설치되지 않음

Anthos Service Mesh 1.9 이상 버전이 클러스터에 설치되지 않은 경우, 다음 예시는 vm 및 hub-meshca 옵션을 추가하여 GKE용 설치, 마이그레이션, 업그레이드에 설명된 일반적인 Anthos Service Mesh 설치 단계를 수정하는 방법을 보여줍니다. 또한 다음 예시에 사용된 install_asm 스크립트를 다운로드하는 방법을 설명합니다.

install_asm 스크립트를 다운로드한 후 --option hub-meshca, --option vm, --enable_all 플래그를 포함하여 클러스터에 Anthos Service Mesh를 설치할 수 있습니다. 자세한 내용은 제품군을 사용하여 Mesh CA 사용 설정 및 사용 설정 플래그를 참조하세요.

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

설치됨

Anthos Service Mesh 1.9 이상 버전이 이미 클러스터에 설치되어 있고 제품군을 사용하여 Mesh CA를 사용 설정한 경우 VM 기반 워크로드가 지원되도록 Anthos Service Mesh 제어 영역을 업데이트합니다. 또한 이 스크립트는 VM 워크로드에 대해 클러스터의 Anthos Service Mesh 설치가 준비되었는지 확인하는 데 도움이 됩니다. 특히 prepare_cluster 하위 명령어는 Anthos Service Mesh 1.9 이상의 모든 버전이 VM 워크로드를 지원하도록 업데이트합니다.

Anthos Service Mesh 1.9 이상 버전 설치 프로그램에 제품군을 사용하여 Mesh CA가 사용 설정되어 있지 않은 경우 install_asm 스크립트에 --option hub-meshca 및 --option vm 플래그를 포함하여 Anthos Service Mesh 1.9 설치 프로그램을 다시 설치하거나 업그레이드합니다.

./asm_vm prepare_cluster \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION

이전 단계에서 수행된 작업은 다음과 같습니다.

  1. VM 자동 등록 사용 설정: PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION 변수를 true로 설정하면 됩니다. 이 기능을 사용 설정하면 새 VM 인스턴스가 WorkloadGroup에 등록되고 트래픽을 VM으로 라우팅하기 위한 새 WorkloadEntry CR이 생성됩니다. install_asm에 설치되는 모든 Anthos Service Mesh 1.9 이상 버전 제어 영역에는 이 기능이 기본적으로 포함됩니다.

  2. 확장 게이트웨이 설치: 이 게이트웨이는 이름이 eastwest이고 Anthos Service Mesh 구성 패키지에 정의되어 있습니다. 또한 이렇게 하면 VM에 제어 영역이 노출됩니다.

  3. IdentityProvider CRD를 설치하고 VM이 Anthos Service Mesh 제어 영역에 인증을 수행하고 나머지 서비스 메시와 안전하게 통신할 수 있도록 Google IdentityProvider CR을 등록합니다.

  4. install_asm 스크립트에서 --enable_all 또는 --enable_registration을 사용하는 경우 클러스터를 제품군에 등록하고 워크로드 아이덴티티를 사용 설정합니다.

  5. 제품군 내에서 Service Mesh 기능을 사용 설정합니다. 이 기능은 VM이 메시와 안전하게 통신하도록 허용하는 데 필요한 정책을 관리합니다.

VM 추가

이 섹션에서는 asm_vm 스크립트로 만드는 인스턴스 템플릿을 기준으로 메시에 Compute Engine 인스턴스를 추가합니다. 이 스크립트는 서비스 프록시 에이전트에 필요한 구성만 생성합니다. 인스턴스 템플릿에서 구성을 더 포함하려면 소스 인스턴스 템플릿을 만들고 이를 스크립트에 추가합니다.

메시에 VM을 추가하려면 다음 단계를 따릅니다.

  1. 이후 단계에서 사용할 다음 환경 변수를 설정합니다. 각 VM 워크로드에 대해 다음 변수를 설정합니다.

    • WORKLOAD_NAME은 VM이 포함된 워크로드의 이름이며, 영숫자 소문자로 구성된 호환되는 DNS-1123 하위 도메인이어야 합니다.
    • WORKLOAD_VERSION은 VM이 포함된 워크로드의 버전입니다. 선택사항.
    • WORKLOAD_SERVICE_ACCOUNT는 VM이 실행되는 서비스 GCP 서비스 계정입니다.
    • WORKLOAD_NAMESPACE는 워크로드의 네임스페이스입니다.
    • ASM_INSTANCE_TEMPLATE은 만들 인스턴스 템플릿의 이름입니다. Compute Engine 인스턴스 템플릿 이름에는 밑줄이 허용되지 않습니다.
    • SOURCE_INSTANCE_TEMPLATE은 템플릿 생성의 기준으로 사용되는 템플릿 이름입니다. 선택사항.

  2. VM 워크로드의 네임스페이스가 아직 없으면 만듭니다.

    kubectl create ns WORKLOAD_NAMESPACE

  3. 네임스페이스에 제어 영역 버전을 라벨로 지정합니다. 다음 예시에서 REVISION으로 표시된 제어 영역 버전을 찾는 방법에 대한 예시는 워크로드 배포 및 다시 배포를 참조하세요.

    kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite

  4. 등록할 VM에 대해 WorkloadGroup을 만듭니다.

    kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
 name: WORKLOAD_NAME
 namespace: WORKLOAD_NAMESPACE
spec:
 metadata:
   labels:
     app.kubernetes.io/name: WORKLOAD_NAME
     app.kubernetes.io/version: WORKLOAD_VERSION
   annotations:
     security.cloud.google.com/IdentityProvider: google
 template:
   serviceAccount: WORKLOAD_SERVICE_ACCOUNT
EOF
    필드 설명
    name VM이 포함된 워크로드의 이름입니다.
    namespace 워크로드가 포함된 네임스페이스입니다.
    app.kubernetes.io/name Kubernetes 애플리케이션의 권장 라벨입니다. VM 워크로드에 사용자 고유 라벨을 사용할 수 있습니다.
    app.kubernetes.io/version Kubernetes 애플리케이션의 권장 라벨입니다. VM 워크로드에 사용자 고유 라벨을 사용할 수 있습니다.
    serviceAccount SPIFFE 형식으로 워크로드 ID 일부로 사용되는 VM 및 프로젝트에 사용되는 서비스 계정 ID입니다. 자세한 내용은 서비스 계정을 참조하세요.
    security.cloud.google.com/IdentityProvider VM에 사용할 ID 공급업체 제공자입니다. 클러스터에 등록되어 있어야 합니다. Compute Engine VM의 경우 google로 설정해야 합니다. 'IdentityProvider'는 VM의 사용자 인증 정보를 인증하는 방법과 VM의 서비스 계정을 추출할 위치를 제어 영역에 알려줍니다.

  5. 다음 옵션 및 플래그를 사용해서 asm_vm 스크립트를 실행하여 Anthos Service Mesh Compute Engine 인스턴스에 대해 인스턴스 템플릿을 만듭니다.

    이 스크립트는 클러스터 기본 요건을 확인하고, Anthos Service Mesh에 대해 VM 라벨을 추가하고, 서비스 프록시 에이전트에 대해 커스텀 메타데이터 구성을 생성하고, 새 인스턴스 템플릿을 만듭니다.

    스크립트의 기준으로 사용할 기존 인스턴스 템플릿이 있으면 --source_instance_template 옵션을 지정할 수 있습니다. 기본이 아닌 VM을 Anthos Service Mesh에 추가하려면 원하는 OS 배포판으로 인스턴스 템플릿을 만들고 이 템플릿을 asm_vm 스크립트의 --source_instance_template 플래그 값으로 사용합니다. 기존 인스턴스 템플릿에 네트워크 연결이 필요한 시작 스크립트가 포함된 경우 이 스크립트는 일시적인 네트워크 연결 문제에 대한 복원력이 우수해야 합니다. 일시적인 네트워크 장애에 대한 복원력을 추가하는 방법의 예시는 데모 애플리케이션을 참조하세요.

    ./asm_vm create_gce_instance_template \
ASM_INSTANCE_TEMPLATE \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name WORKLOAD_NAME \
--workload_namespace WORKLOAD_NAMESPACE \
--source_instance_template SOURCE_INSTANCE_TEMPLATE

    옵션

    옵션 설명
    -p|--project_id PROJECT_ID 클러스터가 생성된 프로젝트 ID입니다.
    -n|--cluster_name CLUSTER_NAME 클러스터의 이름입니다.
    -l|--cluster_location CLUSTER_LOCATION 클러스터가 생성된 영역(단일 영역 클러스터) 또는 리전(리전 클러스터)입니다.
    -w|--workload_name WORKLOAD_NAME Compute Engine 인스턴스가 나타내는 워크로드의 이름입니다.
    --workload_namespace WORKLOAD_NAMESPACE 선택사항. 워크로드의 네임스페이스입니다. 기본값은 'default'입니다.
    -s|--source_instance_template SOURCE_INSTANCE_TEMPLATE_NAME 선택사항. Anthos Service Mesh Compute Engine 인스턴스 템플릿의 기준으로 사용할 기존 인스턴스 템플릿입니다. 지정하지 않으면 기본값을 사용하여 인스턴스 템플릿이 생성됩니다.

    플래그

    플래그 설명
    -v|--verbose 실행 전 및 후에 명령어를 출력합니다.
    --dry_run 명령어를 출력하지만 이를 실행하지 않습니다.
    --only_validate 검증을 실행하지만 새 Compute Engine 인스턴스 템플릿을 만들지 않습니다.
    -h|--help 선택사항과 플래그를 설명하는 도움말 메시지를 표시하고 종료합니다.

  6. 만드는 각 MIG에 대해 다음 환경 변수를 설정합니다.

    • INSTANCE_GROUP_NAME은 만들려는 Compute Engine 인스턴스 그룹의 이름입니다.
    • ASM_INSTANCE_TEMPLATE은 만들 인스턴스 템플릿의 이름입니다. Compute Engine 인스턴스 템플릿 이름에는 밑줄이 허용되지 않습니다.
    • INSTANCE_GROUP_ZONE은 만들 Compute Engine 인스턴스 그룹의 영역입니다.
    • PROJECT_ID는 클러스터가 생성된 프로젝트 ID입니다.
    • SIZE는 만들 인스턴스 그룹의 크기입니다. 인스턴스 그룹이 생성된 후 변경할 수 있습니다.
    • WORKLOAD_NAME은 VM이 포함된 워크로드의 이름입니다.
    • WORKLOAD_NAMESPACE는 워크로드의 네임스페이스입니다.

  7. 이전 단계에서 만든 변수를 사용하여 VM 워크로드의 관리형 인스턴스 그룹을 만듭니다.

    gcloud compute instance-groups managed create \
INSTANCE_GROUP_NAME \
--template ASM_INSTANCE_TEMPLATE \
--zone=INSTANCE_GROUP_ZONE \
--project=PROJECT_ID \
--size=SIZE

    영역 또는 리전 MIG 크기 0부터 시작하여 Compute Engine 인스턴스에서 워크로드 수를 확장하거나 축소하려면 인스턴스 그룹 자동 확장을 참조하세요. 그룹 만들기에 대한 자세한 내용은 gcloud compute instance-groups managed create를 참조하세요.

    인스턴스가 시작되면 클러스터에서 Anthos Service Mesh 제어 영역에 자동으로 인증을 수행하고 제어 영역이 각 VM을 WorkloadEntry로 등록합니다.

  8. MIG의 VM 인스턴스 시작이 완료되면 다음 명령어를 사용하여 워크로드 네임스페이스에서 등록된 VM을 볼 수 있습니다.

       kubectl get workloadentry -n WORKLOAD_NAMESPACE

  9. 위에서 추가한 VM 워크로드를 노출시키기 위해 Kubernetes 서비스를 추가합니다. 올바른 트래픽 라우팅을 위해서는 위에서 등록된 VM WorkloadGroup에서 서비스가 해당 라벨을 선택하도록 해야 합니다.

    다음 예시에서는 WORKLOAD_NAMESPACE 네임스페이스에서 HTTP 포트 80을 사용해서app.kubernetes.io/name: WORKLOAD_NAME 라벨로 VM 워크로드를 노출하는 WORKLOAD_NAME이라는 Kubernetes 서비스를 만듭니다.

    kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
 name: WORKLOAD_NAME
 namespace: WORKLOAD_NAMESPACE
 labels:
   asm_resource_type: VM
spec:
 ports:
 - port: 80
   name: http
 selector:
   app.kubernetes.io/name: WORKLOAD_NAME
EOF

    Kubernetes 서비스를 만드는 방법에 대한 자세한 내용은 https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service를 참조하세요.

  10. VM에서 샘플 애플리케이션을 사용하려면 샘플 애플리케이션 배포를 참조하세요.

Anthos Service Mesh 제어 영역 업그레이드

Anthos Service Mesh를 최신 버전으로 업그레이드의 안내에 따라 Anthos Service Mesh 제어 영역을 새 버전으로 업그레이드합니다. 새 버전의 Anthos Service Mesh 제어 영역을 설치한 후 워크로드 배포 및 다시 배포의 안내에 따라 Kubernetes 워크로드를 다시 배포합니다.

VM 워크로드에 대해 새 인스턴스 템플릿을 만들고 MIG에서 VM에 대해 순차적 업데이트를 수행합니다.

  1. 다음 명령어를 사용하여 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-198-6-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-198-6-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=85d86774f7

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

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

  2. 네임스페이스에 버전 라벨을 추가하고 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 라벨 삭제가 포함됩니다.

  3. asm_vm 스크립트를 사용하여 새 인스턴스 템플릿을 만듭니다. 새 인스턴스 템플릿 이름을 사용하고 동일한 워크로드에 동일한 항목이 있으면 동일한 소스 인스턴스 템플릿을 포함해야 합니다.

    ./asm_vm create_gce_instance_template \
NEW_ASM_INSTANCE_TEMPLATE \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name WORKLOAD_NAME \
--workload_namespace WORKLOAD_NAMESPACE \
--source_instance_template SOURCE_INSTANCE_TEMPLATE

  4. 워크로드의 기존 MIG에 대해 순차적 업데이트를 수행합니다.

    자세한 내용은 기본 순차적 업데이트 시작을 참조하세요.

    gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
--version=template=NEW_ASM_INSTANCE_TEMPLATE \
--zone=INSTANCE_GROUP_ZONE

  5. VM 워크로드를 테스트하여 예상대로 작동하는지 확인합니다.

VM 애플리케이션 업그레이드

WorkloadGroup 변경사항 또는 소스 인스턴스 변경사항을 포함하여 애플리케이션이 업데이트된 경우 VM 워크로드의 MIG를 업데이트하기 위해 새 인스턴스 템플릿이 필요합니다.

WorkloadGroup 변경이 적용되거나 새 소스 인스턴스 템플릿이 생성되면 Anthos Service Mesh에 대해 새 인스턴스 템플릿을 만들고 MIG의 VM에 대해 순차적 업데이트를 수행합니다.

  1. asm_vm 스크립트를 사용하여 새 인스턴스 템플릿을 만듭니다. 애플리케이션 업데이트에 대해 항목을 하나 만들었으면 새 인스턴스 템플릿 이름을 사용하고 새 소스 인스턴스 템플릿을 포함해야 합니다.

    ./asm_vm create_gce_instance_template \
NEW_ASM_INSTANCE_TEMPLATE \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name WORKLOAD_NAME \
--workload_namespace WORKLOAD_NAMESPACE \
--source_instance_template NEW_SOURCE_INSTANCE_TEMPLATE

  2. 워크로드의 기존 MIG에 대해 순차적 업데이트를 수행합니다. MIG 순차적 업데이트를 사용하는 방법은 기본 순차적 업데이트 시작을 참조하세요.

    gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
--version=template=NEW_ASM_INSTANCE_TEMPLATE \
--zone=INSTANCE_GROUP_ZONE

  3. VM 워크로드를 테스트하여 예상대로 작동하는지 확인합니다.

샘플 애플리케이션 배포

새 메시 구성이 올바르게 작동하는지 시연하기 위해 Bookinfo 샘플 애플리케이션을 설치할 수 있습니다. 이 예시에서는 VM에서 MySQL 데이터베이스를 실행하고 등급 서비스가 데이터베이스에서 등급 값을 읽습니다.

클러스터에 Bookinfo 설치

다음 단계를 따라 각 서비스와 함께 사이드카 프록시가 삽입된 BookInfo 애플리케이션 서비스를 배포합니다. BookInfo 애플리케이션은 default 네임스페이스에 배포됩니다.

  1. Anthos Service Mesh를 설치한 컴퓨터의 명령줄에서 스크립트 다운로드 단계 중에 만든 Anthos Service Mesh 설치 디렉터리의 루트로 이동합니다.

  2. 자동 사이드카 주입을 사용 설정하려면 다음 명령어를 사용하여 istiod에서 이후 단계에서 사용할 버전 라벨 값을 포함하는 라벨을 찾습니다.

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

    결과는 다음과 유사합니다.

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

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

  3. default 네임스페이스에 버전 라벨을 적용합니다. 다음 명령어에서 REVISION은 이전 단계에서 확인한 istiod 버전 라벨의 값입니다.

    kubectl label namespace default 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 라벨 삭제가 포함됩니다.

  4. kubectl을 사용하여 애플리케이션을 기본 네임스페이스에 배포합니다.

    kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml

  5. 다음 명령어를 실행하여 애플리케이션이 올바르게 배포되었는지 확인합니다.

    kubectl get services

    예상 출력:

    NAME                       CLUSTER-IP   EXTERNAL-IP   PORT(S)              AGE
details                    10.0.0.31    <none>        9080/TCP             6m
kubernetes                 10.0.0.1     <none>        443/TCP              7d
productpage                10.0.0.120   <none>        9080/TCP             6m
ratings                    10.0.0.15    <none>        9080/TCP             6m
reviews                    10.0.0.170   <none>        9080/TCP             6m

    및

    kubectl get pod

    예상 출력:

    NAME                                        READY     STATUS    RESTARTS   AGE
details-v1-1520924117-48z17                 2/2       Running   0          6m
productpage-v1-560495357-jk1lz              2/2       Running   0          6m
ratings-v1-734492171-rnr5l                  2/2       Running   0          6m
reviews-v1-874083890-f0qf0                  2/2       Running   0          6m
reviews-v2-1343845940-b34q5                 2/2       Running   0          6m
reviews-v3-1813607990-8ch52                 2/2       Running   0          6m

  6. 마지막으로 애플리케이션에 대해 인그레스 게이트웨이 라우팅을 정의합니다.

    kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml

    예상 출력:

    gateway.networking.istio.io/bookinfo-gateway created
virtualservice.networking.istio.io/bookinfo created

  7. 제품 페이지에 액세스할 수 있는지 확인합니다.

    export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
export GATEWAY_URL="${INGRESS_HOST}:${INGRESS_PORT}"
curl -s "http://${GATEWAY_URL}/productpage" | grep -o "<title>.*</title>"

    예상 출력:

    <title>Simple Bookstore App</title>

Compute Engine 인스턴스 만들기 및 MySQL 설치

이 단계에서는 VM에서 실행되는 MySQL 인스턴스에 대해 Compute Engine 인스턴스 템플릿을 만듭니다. 자세한 단계는 가상 머신을 사용하는 Bookinfo를 참조하세요.

  1. MySQL을 설치하고 시작 시 등급 데이터베이스를 추가하기 위해 시작 스크립트가 포함된 Compute Engine 인스턴스 템플릿을 만듭니다. CentOS를 사용하는 경우 mariadb-server가 준비되는 데 최대 10분이 걸립니다.

    Debian

    cat << "EOF" > init-mysql
#!/bin/bash

# Wait until Envoy is ready before installing mysql
while true; do
  rt=$(curl -s 127.0.0.1:15000/ready)
  if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then
    echo "envoy is ready"
    break
  fi
  sleep 1
done

sudo apt-get update && sudo apt-get install -y mariadb-server

sudo sed -i '/bind-address/c\bind-address  = 0.0.0.0' /etc/mysql/mariadb.conf.d/50-server.cnf

cat <<EOD | sudo mysql
# Grant access to root
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;

# Grant root access to other IPs
CREATE USER 'root'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;
quit
EOD

sudo systemctl restart mysql

curl -LO https://raw.githubusercontent.com/istio/istio/release-1.9/samples/bookinfo/src/mysql/mysqldb-init.sql

mysql -u root -ppassword < mysqldb-init.sql
EOF

gcloud compute \
--project=PROJECT_ID \
instance-templates create mysql-instance-template \
--machine-type=e2-medium \
--metadata-from-file=startup-script=init-mysql \
--image=debian-10-buster-v20201014 \
--image-project=debian-cloud \
--boot-disk-size=10GB

    CentOS

    cat << "EOF" > init-mysql
#!/bin/bash

# Wait until Envoy is ready before installing mysql
while true; do
  rt=$(curl -s 127.0.0.1:15000/ready)
  if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then
    echo "envoy is ready"
    break
  fi
  sleep 1
done

sudo yum update -y && sudo yum install -y mariadb-server

# Wait until mysql is ready
while true; do
  rt=$(which mysql)
  if [[ ! -z "${rt}" ]]; then
    echo "mysql is ready"
    break
  fi
  sleep 1
done

sudo sed -i '/bind-address/c\bind-address  = 0.0.0.0' /etc/my.cnf.d/mariadb-server.cnf

sudo systemctl restart mariadb

cat > grantaccess.sql << EOD

GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;

CREATE USER 'root'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;
EOD

until sudo mysql < grantaccess.sql; do
   sleep 1
done

sudo systemctl restart mariadb

curl -LO https://raw.githubusercontent.com/istio/istio/release-1.9/samples/bookinfo/src/mysql/mysqldb-init.sql

mysql -u root -ppassword < mysqldb-init.sql
EOF

gcloud compute \
--project=PROJECT_ID \
instance-templates create mysql-instance-template \
--machine-type=e2-medium \
--metadata-from-file=startup-script=init-mysql \
--image-project=centos-cloud \
--image-family=centos-8 \
--boot-disk-size=30GB

  2. MySQL 워크로드에 대해 WorkloadGroup을 만듭니다.

    kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
 name: mysql
 namespace: default
spec:
 metadata:
   labels:
     app.kubernetes.io/name: mysql
   annotations:
     security.cloud.google.com/IdentityProvider: google
 template:
   serviceAccount: WORKLOAD_SERVICE_ACCOUNT
EOF

  3. 위의 VM 스크립트를 사용해서 새 인스턴스 템플릿을 만들어 메시에 대해 인스턴스를 준비합니다.

    ./asm_vm create_gce_instance_template \
asm-mysql-instance-template \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name mysql \
--source_instance_template mysql-instance-template

  4. 새로 생성된 인스턴스 템플릿을 사용하여 Compute Engine MIG를 만듭니다.

    gcloud compute instance-groups managed create mysql-instance \
--template asm-mysql-instance-template \
--zone=us-central1-c \
--project=PROJECT_ID \
--size=1

서비스 만들기

MySQL 서비스에 대해 Kubernetes 서비스를 만듭니다.

  1. 다음 명령어를 사용하여 Kubernetes 서비스를 만듭니다.

    kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
 name: mysql
 namespace: default
 labels:
   asm_resource_type: VM
spec:
 ports:
 - name: mysql
   port: 3306
   protocol: TCP
   targetPort: 3306
 selector:
   app.kubernetes.io/name: mysql
EOF

Anthos UI 대시보드 사용

생성된 새 VM 기반 서비스를 보려면 왼쪽의 기본 탐색 메뉴에서 Anthos > 서비스 메시를 클릭합니다. 그러면 메시에서 실행되는 서비스의 테이블이 표시됩니다. 추가한 서비스가 VM의 Type 값 및 일부 고급 측정항목과 함께 테이블에 표시됩니다. VM 기반 서비스에서 더 많은 원격 분석을 보려면 서비스 이름을 클릭하여 서비스 수준 대시보드를 표시합니다.

Anthos UI 대시보드 사용 방법에 대한 자세한 내용은 Cloud 콘솔에서 Anthos Service Mesh 탐색을 참조하세요.

VM 워크로드 트래픽 관리

VM에서 트래픽이 들어오고 나가는 방법을 제어하는 네트워킹 규칙을 변경할 수 있습니다.

새 등급 서비스 트래픽 제어(Pod-VM)

Bookinfo에서 위에서 생성된 MySQL 인스턴스를 데이터 소스로 사용하는 다른 등급 서비스를 만들고 검토 서비스가 새 등급 서비스를 사용하도록 강제하는 라우팅 규칙을 지정합니다.

  1. MySQL 인스턴스를 사용하도록 새 등급 서비스를 만듭니다.

    kubectl apply -f - << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
 name: ratings-v2-mysql-vm
 labels:
   app: ratings
   version: v2-mysql-vm
spec:
 replicas: 1
 selector:
   matchLabels:
     app: ratings
     version: v2-mysql-vm
 template:
   metadata:
     labels:
       app: ratings
       version: v2-mysql-vm
   spec:
     serviceAccountName: bookinfo-ratings
     containers:
     - name: ratings
       image: docker.io/istio/examples-bookinfo-ratings-v2:1.16.2
       imagePullPolicy: IfNotPresent
       env:
         - name: DB_TYPE
           value: "mysql"
         - name: MYSQL_DB_HOST
           value: mysql.default.svc.cluster.local
         - name: MYSQL_DB_PORT
           value: "3306"
         - name: MYSQL_DB_USER
           value: root
         - name: MYSQL_DB_PASSWORD
           value: password
       ports:
       - containerPort: 9080
EOF

  2. 라우팅 규칙을 만듭니다.

    kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: reviews
spec:
 hosts:
 - reviews
 http:
 - route:
   - destination:
       host: reviews
       subset: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: ratings
spec:
 hosts:
 - ratings
 http:
 - route:
   - destination:
       host: ratings
       subset: v2-mysql-vm
EOF

  3. 생성된 서비스에 대해 대상 규칙을 적용합니다.

    kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
 name: reviews
spec:
 host: reviews
 subsets:
 - name: v1
   labels:
     version: v1
 - name: v2
   labels:
     version: v2
 - name: v3
   labels:
     version: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
 name: ratings
spec:
 host: ratings
 subsets:
 - name: v1
   labels:
     version: v1
 - name: v2
   labels:
     version: v2
 - name: v2-mysql
   labels:
     version: v2-mysql
 - name: v2-mysql-vm
   labels:
     version: v2-mysql-vm
EOF

애플리케이션 배포 검증

BookInfo 애플리케이션이 작동하는지 확인하려면 인그레스 게이트웨이로 트래픽을 보내야 합니다.

  • GKE에 Anthos Service Mesh를 설치한 경우 이전 단계에서 만든 인그레스 게이트웨이의 외부 IP 주소를 가져옵니다.

    kubectl get svc istio-ingressgateway -n istio-system

    출력:

    NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
istio-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m

    이 예시에서 인그레스 서비스의 IP 주소는 35.239.7.64입니다.

애플리케이션 시험 사용

  1. curl을 사용하여 BookInfo 앱이 실행되는지 확인합니다.

    curl -I http://EXTERNAL_IP/productpage

    응답에 200이 표시되면 애플리케이션이 Anthos Service Mesh와 함께 올바르게 작동되고 있음을 나타냅니다.

  2. BookInfo 웹페이지를 보려면 브라우저에 다음 주소를 입력합니다.

    http://EXTERNAL_IP/productpage

  3. Bookinfo 애플리케이션 홈페이지에서 Reviewer1로부터 별 5개를 표시하고 Reviewer2로부터 별 4개를 표시하는지 확인합니다.

VM 워크로드에 보안 적용

VM 워크로드에 보안을 적용하는 것은 Kubernetes 워크로드에 보안을 적용하는 것과 동일합니다. 자세한 내용은 Istio 보안을 참조하세요.

이전 단계를 완료한 후 Compute Engine VM에 Google에서 발급한 워크로드 인증서가 포함됩니다. 인증서에서 SubjectAlternativeName 값은 spiffe://<workload_identity_pool>/ns/WORKLOAD_NAMESPACE/sa/WORKLOAD_SERVICE_ACCOUNT 형식의 VM의 Anthos 워크로드 아이덴티티를 표시합니다.

자세한 내용은 워크로드 아이덴티티 풀을 참조하세요.

메시에 mTLS의 엄격한 모드 사용 설정

다음 YAML을 적용하여 엄격한 mTLS를 메시 전체에 적용합니다.

kubectl apply -f - << EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
EOF

서비스 간 트래픽 승인

AuthorizationPolicy를 사용하여 Compute Engine VM의 애플리케이션과 다른 메시 워크로드(예: GKE 클러스터의 항목) 사이의 액세스를 제어합니다.

예시: Kubernetes 워크로드의 Compute Engine VM 액세스 거부

다음 승인 정책은 Kubernetes 워크로드 ratings가 ratings MySQL 서버를 제공하는 Compute Engine VM 워크로드에 액세스하는 것을 거부합니다.

kubectl apply -f - << EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: mysql-deny
  namespace: default
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: mysql
  action: DENY
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/bookinfo-ratings"]
EOF

AuthorizationPolicy 예시를 적용한 후에는 제품 페이지의 도서 리뷰 섹션에 Ratings service is currently unavailable 오류 메시지가 표시됩니다.

Cloud Monitoring 에이전트 설치

Cloud Monitoring 에이전트를 설치하여 VM 인스턴스에서 시스템 및 애플리케이션 측정항목을 수집하고 모니터링할 수 있습니다. 이를 통해 에이전트의 CPU 및 메모리 사용 예시와 같은 주요 측정항목을 모니터링할 수 있습니다.

자세한 내용은 Cloud Monitoring 에이전트 문서를 참조하세요.

문제 해결

문제 해결 팁은 VM 지원 문제 해결을 참조하세요.