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

이 페이지에서는 GKE(Google Kubernetes Engine)의 Anthos Service Mesh에 Compute Engine 가상 머신(VM)을 추가하는 방법에 대해 설명합니다. 이 페이지에는 VM을 추가하기 위해 클러스터를 준비하는 옵션과 함께 Anthos Service Mesh 1.11.8를 설치하는 방법이 나와있습니다.

  • Anthos Service Mesh 1.9 or a 1.10 patch release가 이미 설치된 경우 이 페이지에서는 VM 추가에 필요한 옵션과 함께 Anthos Service Mesh 1.11.8로 업그레이드하는 방법을 보여줍니다.

  • Anthos Service Mesh 1.9가 있고 업그레이드하지 않으려면 Anthos Service Mesh 1.9 가이드에서 Anthos Service Mesh 1.9에 VM 추가 안내를 참조하세요.

  • 이전 버전의 Anthos Service Mesh가 있으면 먼저 1.9 이상으로 Anthos Service Mesh를 업그레이드해야 합니다.

이 페이지에서는 클러스터 내 제어 영역 또는 Google 관리 제어 영역을 설치하기 위한 명령줄을 제공합니다.

소개

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

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

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

작동 방식

Anthos Service Mesh는 가상 머신 워크로드를 나타내기 위해 다음과 같이 두 가지 CRD(커스텀 리소스 정의)를 제공합니다.

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

각 Compute Engine 인스턴스 그룹에 대해 Compute Engine 인스턴스 템플릿을 만듭니다. 이 템플릿은 해당 그룹에 있는 각 Compute Engine 인스턴스에 대해 서비스 프록시 에이전트를 지정합니다. 설치 중 에이전트는 서비스 프록시를 부트스트랩하고, 트래픽 가로채기를 설정하고, Compute Engine 인스턴스의 수명 주기 동안 서비스 프록시 상태를 모니터링합니다. 프록시는 Anthos Service Mesh 제어 영역과 연결되고, 그런 후 각 Compute Engine 인스턴스를 해당 WorkloadGroup에 대한 WorkloadEntry로 자동으로 등록합니다. 이렇게 해서 클러스터의 Kubernetes 포드와 같이 Anthos Service Mesh가 각 인스턴스를 서비스 엔드포인트로 취급할 수 있습니다. 또한 Kubernetes 포드에서와 같이 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은 동일한 네트워크, 동일한 프로젝트에 있어야 하며, 단일 네트워크 인터페이스를 사용해야 합니다.
  • Anthos 구독 없이도 이 기능을 사용할 수 있지만 Google Cloud Console의 특정 UI 요소 및 기능은 Anthos 구독자에게만 제공됩니다. 구독자와 비구독자가 사용할 수 있는 항목에 대한 상세 설명은 Anthos 및 Anthos Service Mesh UI 차이점을 참조하세요.
  • Google 관리 제어 영역 및 Google 관리 데이터 영역을 모두 클러스터에 배포할 수 있지만 Google 관리 데이터 영역은 VM의 프록시를 관리하지 않습니다.

기본 요건

시작하기 전에 다음 사항을 확인하세요.

기본 요건에 설명된 Cloud 프로젝트, Anthos 라이선스, 일반 요구사항을 검토하세요.

클러스터 요구사항

계속하기 전에 클러스터가 GKE 요구사항을 충족하는지 확인합니다. 또한 Anthos Service Mesh VM 지원에는 다음이 필요합니다.

  • Anthos Service Mesh를 설치할 때 Mesh CA를 인증 기관(CA)으로 지정합니다.
  • 원격 분석을 위해 Stackdriver를 재정의하지 않습니다. Stackdriver는 Anthos Service Mesh를 설치할 때 기본적으로 구성됩니다.
  • 클러스터가 Fleet에 등록됩니다. 하지만 클러스터가 등록되지 않았으면 VM 설치 프로세스가 지정된 프로젝트에 클러스터를 등록합니다.

시작하기

시작하기의 단계에 따라 다음 작업을 수행하세요.

Anthos Service Mesh를 설치하지 않았으면 다음 섹션을 계속 진행합니다. 기존 Anthos Service Mesh 설치가 있으면 기존 설치의 단계를 따릅니다.

새 설치

Anthos Service Mesh 1.11 제어 영역을 준비하여 VM에 대해 Anthos Service Mesh 클러스터를 설정합니다. 실행하는 명령어는 클러스터에 설치하려는 Anthos Service Mesh 제어 영역 유형에 따라 달라집니다.

클러스터 내

다음 명령어는 VM을 추가할 수 있도록 제어 영역을 준비하는 --option vm으로 Anthos Service Mesh 클러스터 내 제어 영역을 설치하는 방법을 보여줍니다.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --option vm
  • --project_id, --cluster_name, --cluster_location: 클러스터가 있는 프로젝트 ID, 클러스터 이름, 클러스터 영역 또는 리전을 지정합니다.
  • --output_dir asmcli가 anthos-service-mesh 패키지를 다운로드하고 설치 파일을 추출하며, istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면 asmcli가 파일을 tmp 디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서 환경 변수 $PWD는 작동하지 않습니다.
  • --enable_all: 스크립트의 다음 작업을 허용합니다.
    • 필요한 IAM 권한을 부여합니다.
    • 필요한 Google API를 사용 설정합니다.
    • 메시를 식별하는 라벨을 클러스터에 설정합니다.
    • 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.

  • --ca mesh_ca: Mesh CA를 인증 기관으로 사용합니다. asmcli에서 Fleet 워크로드 아이덴티티를 사용하도록 Mesh CA를 구성합니다.
  • --option vm: VM을 서비스 메시에 포함할 클러스터를 준비합니다.

클러스터에서 기존 워크로드가 실행되고 있으면 워크로드를 다시 배포한 후 이 페이지로 돌아와서 VM을 추가합니다.

관리형 서비스 메시

다음 명령어는 VM을 추가할 수 있도록 제어 영역을 준비하는 --option vm으로 Anthos Service Mesh Google 관리 제어 영역을 배포하는 방법을 보여줍니다. 사용 가능한 다른 옵션에 대한 자세한 내용은 Google 관리 제어 영역 적용을 참조하세요. 관리형 Anthos Service Mesh 문서에 asmcli install 대신 install_asm 스크립트가 사용되지만 두 설치 스크립트 모두 동일한 방식으로 옵션을 지정합니다.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --option vm \
  --managed
  • --project_id, --cluster_name, --cluster_location: 클러스터가 있는 프로젝트 ID, 클러스터 이름, 클러스터 영역 또는 리전을 지정합니다.
  • --output_dir asmcli가 anthos-service-mesh 패키지를 다운로드하고 설치 파일을 추출하며, istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면 asmcli가 파일을 tmp 디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서 환경 변수 $PWD는 작동하지 않습니다.
  • --enable_all: 스크립트의 다음 작업을 허용합니다.
    • 필요한 IAM 권한을 부여합니다.
    • 필요한 Google API를 사용 설정합니다.
    • 메시를 식별하는 라벨을 클러스터에 설정합니다.
    • 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.

  • --ca mesh_ca: Mesh CA를 인증 기관으로 사용합니다. asmcli에서 Fleet 워크로드 아이덴티티를 사용하도록 Mesh CA를 구성합니다.
  • --option vm: VM을 서비스 메시에 포함할 클러스터를 준비합니다.
  • --managed: Google 관리 제어 영역을 배포합니다.

기존 설치

Anthos Service Mesh가 클러스터에 이미 설치되어 있으면 다음 단계를 수행합니다.

  1. 아직 등록하지 않은 경우 Fleet에 클러스터를 등록합니다.

  2. 다음 명령어를 실행하여 Anthos Service Mesh 설치가 VM 워크로드에 사용할 준비가 되었는지 확인합니다. 클러스터 내 및 Google 관리 제어 영역 모두에 대해 동일한 명령어를 실행합니다.

    ./asmcli experimental vm prepare-cluster \
    --project_id PROJECT_ID \
    --cluster_name CLUSTER_NAME \
    --cluster_location CLUSTER_LOCATION

    성공하면 명령어가 다음을 출력합니다.

    The cluster is ready for adding VM workloads.
Please follow the Anthos Service Mesh for Compute Engine VM user guide to add
Compute Engine VMs to your mesh.

이 명령은 다음을 수행합니다.

클러스터 내

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

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

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

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

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

관리형 서비스 메시

  1. VM 자동 등록 사용 설정: 모든 Anthos Service Mesh Google 관리 제어 영역에 기본적으로 VM 자동 등록이 사용 설정됩니다.

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

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

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

인그레스 게이트웨이 설치

Anthos Service Mesh는 서비스 메시의 일부로 게이트웨이를 배포 및 관리하는 옵션을 제공합니다. 게이트웨이는 들어오거나 나가는 HTTP/TCP 연결을 수신하는 메시지의 에지에서 작동하는 부하 분산기를 설명합니다. 게이트웨이는 메시로 들어오고 나가는 트래픽을 미세하게 제어할 수 있는 Envoy 프록시입니다.

  1. 아직 없으면 인그레스 게이트웨이의 네임스페이스를 만듭니다. 게이트웨이는 사용자 워크로드입니다. 권장사항에 따라 제어 영역 네임스페이스에 배포하지 않아야 합니다. GATEWAY_NAMESPACE를 네임스페이스의 이름으로 바꿉니다.

    kubectl create namespace GATEWAY_NAMESPACE

  2. 게이트웨이 네임스페이스에서 버전 라벨을 적용하여 게이트웨이에서 자동 삽입을 사용 설정합니다. 버전 라벨은 사이드카 인젝터 웹훅에서 삽입된 프록시를 특정 제어 영역 버전과 연결하는 데 사용됩니다. 사용하는 라벨은 관리형 Anthos Service Mesh 또는 클러스터 내 제어 영역을 배포했는지에 따라 달라집니다.

    클러스터 내

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

      kubectl get deploy -n istio-system -l app=istiod -o \
  jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'

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

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

    관리형 서비스 메시

    네임스페이스에 asm-managed 버전 라벨을 적용합니다.

    kubectl label namespace GATEWAY_NAMESPACE \
  istio-injection- istio.io/rev=asm-managed --overwrite

    이 라벨은 Anthos Service Mesh 버전에 대한 현재 관리형 Anthos Service Mesh 출시 채널에 해당합니다.

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

  3. samples/gateways/istio-ingressgateway/ 디렉터리에 있는 예시 인그레스 게이트웨이 구성을 있는 그대로 배포하거나 필요에 따라 수정할 수 있습니다.

    kubectl apply -n GATEWAY_NAMESPACE \
  -f DIR_PATH/samples/gateways/istio-ingressgateway

게이트웨이 권장사항에 대해 자세히 알아보세요.

VM 추가

이 섹션에서는 gcloud로 만드는 인스턴스 템플릿을 기준으로 메시에 Compute Engine 인스턴스를 추가합니다. gcloud는 서비스 프록시 에이전트에 필요한 구성만 생성합니다. 인스턴스 템플릿에 구성을 더 포함하려면 gcloud 참조 가이드에서 자세한 내용을 참조하세요

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

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

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

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

    kubectl create ns WORKLOAD_NAMESPACE

  3. 네임스페이스에 제어 영역 버전을 라벨로 지정합니다.

    클러스터 내

    다음 예시에서 REVISION으로 표시된 제어 영역 버전을 찾는 방법에 대한 예시는 워크로드 배포 및 다시 배포를 참조하세요.

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

    관리형 서비스 메시

    다음 예시에서 asm-managed 버전을 설정하는 방법에 대한 예시는 애플리케이션 배포를 참조하세요.

    kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=asm-managed --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. --mesh 플래그와 함께 gcloud beta compute instance-templates create 명령어를 사용하여 Anthos Service Mesh Compute Engine 인스턴스에 대해 인스턴스 템플릿을 만듭니다.

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

    인스턴스 템플릿에 네트워크 연결이 필요한 시작 스크립트가 포함된 경우 이 스크립트는 일시적인 네트워크 연결 문제에 대한 복원력이 우수해야 합니다. 일시적인 네트워크 장애에 대한 복원력을 추가하는 방법의 예시는 데모 애플리케이션을 참조하세요.

    인스턴스 템플릿 만들기에 대한 자세한 내용은 인스턴스 템플릿 만들기를 참조하세요.

    gcloud beta compute instance-templates create \
ASM_INSTANCE_TEMPLATE \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
--project PROJECT_ID

  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를 업그레이드하고 워크로드가 클러스터에서 실행되는 경우에는 이를 새 제어 영역으로 전환합니다.

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-1118-4-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-1118-4-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=85d86774f7

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

    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. gcloud를 사용하여 새 인스턴스 템플릿을 만듭니다. 동일한 워크로드에 대해 인스턴스 템플릿이 있으면 동일한 구성을 포함해야 합니다.

    gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
--project PROJECT_ID

  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. gcloud를 사용하여 새 인스턴스 템플릿을 만듭니다.

    gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
--project PROJECT_ID

  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. 자동 사이드카 삽입을 사용 설정하려면 Anthos Service Mesh 제어 영역 유형에 따라 아래의 안내를 선택합니다.

    클러스터 내

    다음 명령어를 사용하여 istiod에서 이후 단계에서 사용할 버전 라벨 값을 포함하는 라벨을 찾습니다.

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

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

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

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

    관리형 서비스 메시

    asm-managed 리비전을 사용하여 VM을 추가합니다.

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

    관리형 서비스 메시

    kubectl label namespace default istio-injection- istio.io/rev=asm-managed --overwrite

  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. 제품 페이지에 액세스할 수 있는지 확인합니다. 다음 명령어에서 GATEWAY_NAMESPACE는 Istio 게이트웨이의 네임스페이스입니다.

    export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
export INGRESS_PORT=$(kubectl -n GATEWAY_NAMESPACE 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을 설치하고 시작 시 평점 데이터베이스를 추가하도록 시작 스크립트를 만듭니다. 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

# Wait until DNS is ready before installing mysql
while true; do
  curl -I productpage.default.svc:9080
  if [[ $? -eq 0 ]]; then
    echo "dns 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.11/samples/bookinfo/src/mysql/mysqldb-init.sql

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

    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

# Wait until DNS is ready before installing mysql
while true; do
  curl -I productpage.default.svc:9080
  if [[ $? -eq 0 ]]; then
    echo "dns 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.11/samples/bookinfo/src/mysql/mysqldb-init.sql

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

  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. gcloud를 사용하여 메시의 인스턴스를 준비하고 위에 만든 시작 스크립트를 포함하는 새 인스턴스 템플릿을 만듭니다.

    Debian

    gcloud beta compute instance-templates create asm-mysql-instance-template \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \
--project PROJECT_ID \
--metadata-from-file=startup-script=init-mysql \
--image-project=debian-cloud --image-family=debian-10 --boot-disk-size=10GB

    CentOS

    gcloud beta compute instance-templates create asm-mysql-instance-template \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \
--project PROJECT_ID \
--metadata-from-file=startup-script=init-mysql \
--image-project=centos-cloud --image-family=centos-8 --boot-disk-size=20GB

  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 서비스를 만듭니다.

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 Console에서 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 GATEWAY_NAMESPACE

    출력:

    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 지원 문제 해결을 참조하세요.