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

이 가이드에서는 Anthos Boutique 샘플 애플리케이션을 설치하여 Anthos Service Mesh를 보여주는 방법을 설명합니다. Anthos 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
      

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

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

클러스터 내

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

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

   이 명령어는 Anthos Service Mesh 버전에 해당하는 버전 라벨을 출력합니다. 예: asm-1139-10

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

   참고: 기본 태그가 구성된 경우 istio.io/rev 대신 istio-injection=enabled 라벨을 사용할 수 있습니다. OUTPUT_DIR에서 istioctl으로 istioctl tag list를 실행하여 기본 태그가 있는지 확인합니다.

   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 라벨은 asmcli를 프로비저닝할 때 지정한 --channel의 값이어야 합니다.

   참고: 기본 태그가 구성된 경우 istio.io/rev 대신 istio-injection=enabled 라벨을 사용할 수 있습니다. OUTPUT_DIR에서 istioctl으로 istioctl tag list를 실행하여 기본 태그가 있는지 확인합니다.

   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. 프런트엔드 서비스에 Gateway 및 VirtualService를 배포합니다.

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

삭제

Online Boutique를 삭제하기 전에 Anthos 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
   

다음 단계

• Anthos Service Mesh 예시: mTLS