Online Boutique 샘플 애플리케이션 배포

이 가이드에서는 Online Boutique 샘플 애플리케이션을 설치하여 Cloud Service Mesh를 보여주는 방법을 설명합니다. Cloud Service Mesh를 설치하지 않은 경우 설치 가이드를 참조하세요.

샘플 다운로드 및 배포

애플리케이션을 배포하려면 먼저 kpt를 사용하여 anthos-service-mesh-packages 리포지토리에서 Online Boutique 매니페스트를 다운로드해야 합니다. anthos-service-mesh-packages 리포지토리의 Online Boutique 샘플 애플리케이션은 microservices-demo 리포지토리의 원래 매니페스트 세트에서 수정됩니다. 권장사항에 따라 각 서비스는 고유한 서비스 계정을 사용하여 별도의 네임스페이스에 배포됩니다.

  1. 아직 설치하지 않았다면 kpt를 설치합니다.

    gcloud components install kpt
    
  2. kpt를 사용하여 샘플을 다운로드합니다.

    kpt pkg get \
      https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/samples/online-boutique \
      online-boutique
    

    예상 출력

    Package "online-boutique":
    Fetching https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages@main
    From https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages
    * branch            main       -> FETCH_HEAD
    Adding package "samples/online-boutique".
    Fetched 1 package(s).
    
  3. online-boutique 디렉터리로 이동합니다.

    cd online-boutique
    
  4. 애플리케이션의 네임스페이스를 만듭니다.

    kubectl apply -f kubernetes-manifests/namespaces
    

    예상 출력:

    namespace/ad created
    namespace/cart created
    namespace/checkout created
    namespace/currency created
    namespace/email created
    namespace/frontend created
    namespace/loadgenerator created
    namespace/payment created
    namespace/product-catalog created
    namespace/recommendation created
    namespace/shipping created
    
  5. 클러스터에 샘플을 배포합니다.

    1. 서비스 계정 및 배포 생성:

      kubectl apply -f kubernetes-manifests/deployments
      

      예상 출력:

      serviceaccount/ad created
      deployment.apps/adservice created
      serviceaccount/cart created
      deployment.apps/cartservice created
      serviceaccount/checkout created
      deployment.apps/checkoutservice created
      serviceaccount/currency created
      deployment.apps/currencyservice created
      serviceaccount/email created
      deployment.apps/emailservice created
      serviceaccount/frontend created
      deployment.apps/frontend created
      serviceaccount/loadgenerator created
      deployment.apps/loadgenerator created
      serviceaccount/payment created
      deployment.apps/paymentservice created
      serviceaccount/product-catalog created
      deployment.apps/productcatalogservice created
      serviceaccount/recommendation created
      deployment.apps/recommendationservice created
      serviceaccount/shipping created
      deployment.apps/shippingservice created
      
    2. 서비스 생성:

      kubectl apply -f kubernetes-manifests/services
      

      예상 출력:

      service/adservice created
      service/cartservice created
      service/checkoutservice created
      service/currencyservice created
      service/emailservice created
      service/frontend created
      service/frontend-external created
      service/paymentservice created
      service/productcatalogservice created
      service/recommendationservice created
      service/shippingservice created
      
    3. 서비스 항목 생성:

      kubectl apply -f istio-manifests/allow-egress-googleapis.yaml
      

      예상 출력:

      serviceentry.networking.istio.io/allow-egress-googleapis created
      serviceentry.networking.istio.io/allow-egress-google-metadata created
      

사이드카 자동 삽입 사용 설정

자동 삽입을 사용 설정하려면 네임스페이스에 기본 삽입 라벨을 지정하거나(기본 태그가 설정되어 있는 경우), 버전 라벨을 네임스페이스에 지정합니다. 또한 추가하는 라벨은 관리형 Cloud Service Mesh를 배포했거나 클러스터 내 컨트롤 플레인을 설치했는지 여부에 따라 달라집니다. 라벨은 사이드카 인젝터 웹훅에서 삽입된 사이드카를 특정 컨트롤 플레인 버전과 연결하는 데 사용됩니다.

클러스터 내

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

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

    이 명령어는 Cloud Service Mesh 버전에 해당하는 버전 라벨을 출력합니다(예: asm-1187-26).

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

    for ns in ad cart checkout currency email frontend loadgenerator \
      payment product-catalog recommendation shipping; do
        kubectl label namespace $ns istio.io/rev=REVISION --overwrite
    done;
    

    예상 출력:

    namespace/ad labeled
    namespace/cart labeled
    namespace/checkout labeled
    namespace/currency labeled
    namespace/email labeled
    namespace/frontend labeled
    namespace/loadgenerator labeled
    namespace/payment labeled
    namespace/product-catalog labeled
    namespace/recommendation labeled
    namespace/shipping labeled
    
  3. 포드 재시작:

    for ns in ad cart checkout currency email frontend loadgenerator \
      payment product-catalog recommendation shipping; do
        kubectl rollout restart deployment -n ${ns}
    done;
    

    예상 출력:

    deployment.apps/adservice restarted
    deployment.apps/cartservice restarted
    deployment.apps/checkoutservice restarted
    deployment.apps/currencyservice restarted
    deployment.apps/emailservice restarted
    deployment.apps/frontend restarted
    deployment.apps/loadgenerator restarted
    deployment.apps/paymentservice restarted
    deployment.apps/productcatalogservice restarted
    deployment.apps/recommendationservice restarted
    deployment.apps/shippingservice restarted
    

관리형 서비스 메시

  1. 애플리케이션 네임스페이스에 버전 라벨을 적용합니다. 다음 명령어에서 REVISION 라벨은 관리형 Cloud Service Mesh 출시 채널의 값이어야 합니다(일반 채널의 경우 asm-managed, 신속 채널의 경우 asm-managed-rapid, 공개 버전 채널의 경우 asm-managed-stable).

    for ns in ad cart checkout currency email frontend loadgenerator \
      payment product-catalog recommendation shipping; do
        kubectl label namespace $ns istio.io/rev=REVISION --overwrite
    done;
    

    예상 출력:

    namespace/ad labeled
    namespace/cart labeled
    namespace/checkout labeled
    namespace/currency labeled
    namespace/email labeled
    namespace/frontend labeled
    namespace/loadgenerator labeled
    namespace/payment labeled
    namespace/product-catalog labeled
    namespace/recommendation labeled
    namespace/shipping labeled
    
  2. 선택적 관리형 데이터 영역도 배포한 경우 다음과 같이 애플리케이션 네임스페이스에 주석을 추가합니다.

    for ns in ad cart checkout currency email frontend loadgenerator \
      payment product-catalog recommendation shipping; do
        kubectl annotate --overwrite namespace $ns mesh.cloud.google.com/proxy='{"managed":"true"}'
    done;
    
  3. 포드 재시작:

    for ns in ad cart checkout currency email frontend loadgenerator \
      payment product-catalog recommendation shipping; do
        kubectl rollout restart deployment -n ${ns}
    done;
    

    예상 출력:

    deployment.apps/adservice restarted
    deployment.apps/cartservice restarted
    deployment.apps/checkoutservice restarted
    deployment.apps/currencyservice restarted
    deployment.apps/emailservice restarted
    deployment.apps/frontend restarted
    deployment.apps/loadgenerator restarted
    deployment.apps/paymentservice restarted
    deployment.apps/productcatalogservice restarted
    deployment.apps/recommendationservice restarted
    deployment.apps/shippingservice restarted
    

애플리케이션 노출 및 액세스

메시 외부에 애플리케이션을 노출하는 방법은 인그레스 게이트웨이를 배포했는지 여부에 따라 다릅니다. istio 인그레스 게이트웨이를 사용하거나 Kubernetes 서비스를 사용하여 애플리케이션을 노출하도록 선택할 수 있습니다.

인그레스 게이트웨이 사용

기본 요건에 지정된 대로 클러스터에 인그레스 게이트웨이를 배포한 경우 다음 단계를 수행하여 게이트웨이를 사용하여 애플리케이션을 노출합니다.

  1. 프런트엔드 서비스에 GatewayVirtualService를 배포합니다.

    kubectl apply -f istio-manifests/frontend-gateway.yaml
    

    예상 출력:

    gateway.networking.istio.io/frontend-gateway created
    virtualservice.networking.istio.io/frontend-ingress created
    
  2. 인그레스 게이트웨이의 외부 IP 주소를 가져옵니다. 자리표시자를 다음 정보로 바꿉니다.

    • GATEWAY_SERVICE_NAME: 인그레스 게이트웨이 서비스의 이름입니다. 샘플 게이트웨이를 수정하지 않고 배포한 경우 또는 기본 인그레스 게이트웨이를 배포한 경우 이름은 istio-ingressgateway입니다.

    • GATEWAY_NAMESPACE: 인그레스 게이트웨이를 배포한 네임스페이스입니다. 기본 인그레스 게이트웨이를 배포한 경우 네임스페이스는 istio-system입니다.

    kubectl get service GATEWAY_SERVICE_NAME  -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입니다.

  3. 브라우저에서 애플리케이션을 방문하여 설치를 확인합니다.

    http://EXTERNAL_IP/
    

인그레스 게이트웨이 없음

인그레스 게이트웨이를 배포하지 않았거나 Kubernetes 서비스를 사용하여 애플리케이션을 노출하도록 선택한 경우 다음 단계를 수행하십시오.

  1. LoadBalancer 유형의 서비스를 배포하여 프런트엔드 서비스 노출

    kubectl apply -f frontend-external.yaml
    
  2. frontend-external 서비스의 외부 IP 주소를 찾습니다.

    kubectl get service frontend-external -n frontend
    
  3. 브라우저에서 애플리케이션을 방문하여 설치를 확인합니다.

    http://EXTERNAL_IP/
    

Google Cloud 콘솔에서 Cloud Service Mesh 관측 가능성 기능을 탐색할 수 있습니다. 토폴로지 그래프가 메시에 서비스를 표시하는 데 최대 10분이 걸릴 수 있습니다.

삭제

Online Boutique를 삭제하기 전에 샘플을 사용하는 Cloud Service Mesh 예시: mTLS를 통해 작업하는 것이 좋습니다. 탐색이 완료되었으면 다음 명령어를 사용하여 Online Boutique 샘플을 제거합니다.

  1. 애플리케이션 네임스페이스를 삭제합니다.

    kubectl delete -f kubernetes-manifests/namespaces
    

    예상 출력:

    namespace "ad" deleted
    namespace "cart" deleted
    namespace "checkout" deleted
    namespace "currency" deleted
    namespace "email" deleted
    namespace "frontend" deleted
    namespace "loadgenerator" deleted
    namespace "payment" deleted
    namespace "product-catalog" deleted
    namespace "recommendation" deleted
    namespace "shipping" deleted
    
  2. 서비스 항목을 삭제합니다.

    kubectl delete -f istio-manifests/allow-egress-googleapis.yaml
    

    예상 출력:

    serviceentry.networking.istio.io "allow-egress-googleapis" deleted
    serviceentry.networking.istio.io "allow-egress-google-metadata" deleted
    

다음 단계