에지에서 메시로: GKE 게이트웨이를 통해 서비스 메시 애플리케이션 배포

Last reviewed 2024-01-31 UTC

이 배포에서는 Cloud Service MeshCloud Load Balancing을 결합하여 서비스 메시의 애플리케이션을 인터넷 클라이언트에 노출하는 방법을 보여줍니다.

클라이언트 위치에 따라 여러 가지 방법으로 클라이언트에 애플리케이션을 노출할 수 있습니다. 이 배포에서는 부하 분산기를 서비스 메시에 통합하기 위해 Cloud Load Balancing을 Cloud Service Mesh와 결합하여 클라이언트에 애플리케이션을 노출하는 방법을 보여줍니다. 이 배포는 Cloud Service Mesh를 실행하는 고급 실무자를 대상으로 하지만 Google Kubernetes Engine의 Istio에도 적용됩니다.

아키텍처

다음 다이어그램은 메시 인그레스 게이트웨이를 사용하여 부하 분산기를 서비스 메시와 통합하는 방법을 보여줍니다.

외부 부하 분산기는 외부 클라이언트를 인그레스 게이트웨이 프록시를 통해 메시로 라우팅합니다.

클라우드 인그레스는 VPC 네트워크를 통해 메시에 대한 외부 트래픽의 게이트웨이 역할을 합니다.

앞의 다이어그램의 토폴로지에서 GKE 게이트웨이를 통해 프로그래밍된 클라우드 인그레스 레이어는 서비스 메시 외부에서 유입되는 트래픽을 수집하고 이 트래픽을 메시 인그레스 레이어로 전달합니다. 그러면 메시 인그레스 레이어가 메시에서 호스팅된 애플리케이션 백엔드로 트래픽을 전달합니다.

클라우드 인그레스에서 메시 인그레스의 상태를 확인하고 메시 인그레스는 애플리케이션 백엔드의 상태를 확인합니다.

위 토폴로지에서는 다음을 고려해야 합니다.

  • 클라우드 인그레스: 이 참조 아키텍처에서는 노출된 상태 확인 포트에서 메시 인그레스 프록시의 상태를 확인하도록 GKE 게이트웨이를 통해 Google Cloud 부하 분산기를 구성합니다.
  • 메시 인그레스: 메시 애플리케이션에서는 로컬로 부하 분산 및 트래픽 관리를 실행할 수 있도록 백엔드에서 직접 상태 검사를 수행합니다.

메시 외부의 관리형 인증서와 메시 내부의 내부 인증서를 사용하여 보안이 구현됩니다.

앞의 다이어그램은 클라이언트에서 Google Cloud 부하 분산기, 부하 분산기에서 메시 인그레스 프록시, 인그레스 프록시에서 사이드카 프록시로 HTTPS 암호화를 보여줍니다.

목표

  • Google Cloud에 Google Kubernetes Engine(GKE) 클러스터를 배포합니다.
  • GKE 클러스터에 Istio 기반 Cloud Service Mesh를 배포합니다.
  • 공개 HTTPS 트래픽을 종료한 후 이 트래픽이 서비스 메시에서 호스팅되는 애플리케이션으로 전달되도록 GKE 게이트웨이를 구성합니다.
  • 인터넷에서 클라이언트에 노출되는 GKE 클러스터에 Online Boutique 애플리케이션을 배포합니다.

비용 최적화

이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

시작하기 전에

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

  3. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    이 배포의 모든 터미널 명령어는 Cloud Shell에서 실행됩니다.

  4. Google Cloud CLI를 최신 버전으로 업그레이드합니다.

    gcloud components update
    
  5. 기본 Google Cloud 프로젝트를 설정합니다.

    export PROJECT=PROJECT
    export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT} --format="value(projectNumber)")
    gcloud config set project ${PROJECT}
    

    PROJECT를 이 배포에 사용할 프로젝트 ID로 바꿉니다.

  6. 작업 디렉터리를 만듭니다.

    mkdir -p ${HOME}/edge-to-mesh
    cd ${HOME}/edge-to-mesh
    export WORKDIR=`pwd`
    

    이 배포를 마치면 작업 디렉터리를 삭제할 수 있습니다.

GKE 클러스터 만들기

이 배포에서 설명하는 기능에는 GKE 클러스터 버전 1.16 이상이 필요합니다.

  1. Cloud Shell에서 새 kubeconfig 파일을 만듭니다. 이 단계를 수행하면 기존의 기본 kubeconfig 파일과 충돌이 발생하지 않습니다.

    touch edge2mesh_kubeconfig
    export KUBECONFIG=${WORKDIR}/edge2mesh_kubeconfig
    
  2. GKE 클러스터의 환경 변수를 정의합니다.

    export CLUSTER_NAME=edge-to-mesh
    export CLUSTER_LOCATION=us-central1
    
  3. Google Kubernetes Engine API를 사용 설정합니다.

    gcloud services enable container.googleapis.com
    
  4. GKE Autopilot 클러스터를 만듭니다.

    gcloud container --project ${PROJECT} clusters create-auto 
    ${CLUSTER_NAME} --region ${CLUSTER_LOCATION} --release-channel rapid
    
  5. 클러스터가 실행 중인지 확인합니다.

    gcloud container clusters list
    

    출력은 다음과 비슷합니다.

    NAME          LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
    edge-to-mesh  us-central1  1.27.3-gke.1700   34.122.84.52  e2-medium  1.27.3-gke.1700   3          RUNNING
    

서비스 메시 설치

이 섹션에서는 Fleet API로 관리형 Cloud Service Mesh를 구성합니다.

  1. Cloud Shell에서 필요한 API를 사용 설정합니다.

    gcloud services enable mesh.googleapis.com
    
  2. Fleet에서 Cloud Service Mesh를 사용 설정합니다.

    gcloud container fleet mesh enable
    
  3. Fleet에 클러스터를 등록합니다.

    gcloud container fleet memberships register ${CLUSTER_NAME} \
      --gke-cluster ${CLUSTER_LOCATION}/${CLUSTER_NAME}
    
  4. edge-to-mesh 클러스터에 mesh_id 라벨을 적용합니다.

    gcloud container clusters update ${CLUSTER_NAME} --project ${PROJECT} --region ${CLUSTER_LOCATION} --update-labels mesh_id=proj-${PROJECT_NUMBER}
    
  5. 자동 제어 영역 관리 및 관리형 데이터 영역을 사용 설정합니다.

    gcloud container fleet mesh update \
      --management automatic \
      --memberships ${CLUSTER_NAME}
    
  6. 몇 분 후 제어 영역 상태가 ACTIVE인지 확인합니다.

    gcloud container fleet mesh describe
    

    출력은 다음과 비슷합니다.

    ...
    membershipSpecs:
      projects/892585880385/locations/us-central1/memberships/edge-to-mesh:
        mesh:
          management: MANAGEMENT_AUTOMATIC
    membershipStates:
      projects/892585880385/locations/us-central1/memberships/edge-to-mesh:
        servicemesh:
          controlPlaneManagement:
            details:
            - code: REVISION_READY
              details: 'Ready: asm-managed-rapid'
            state: ACTIVE
          dataPlaneManagement:
            details:
            - code: OK
              details: Service is running.
            state: ACTIVE
        state:
          code: OK
          description: 'Revision(s) ready for use: asm-managed-rapid.'
          updateTime: '2023-08-04T02:54:39.495937877Z'
    name: projects/e2m-doc-01/locations/global/features/servicemesh
    resourceState:
      state: ACTIVE
    ...
    

GKE 게이트웨이 배포

다음 단계에서는 GKE Gateway Controller를 통해 외부 애플리케이션 부하 분산기를 배포합니다. GKE 게이트웨이 리소스는 부하 분산기 및 백엔드 상태 점검의 프로비저닝을 자동화합니다. 또한 인증서 관리자를 사용하여 TLS 인증서를 프로비저닝 및 관리하고 Endpoints를 사용하여 애플리케이션의 공개 DNS 이름을 자동으로 프로비저닝합니다.

서비스 메시 인그레스 게이트웨이 설치

보안 권장사항으로 제어 영역과 다른 네임스페이스에 인그레스 게이트웨이를 배포하는 것이 좋습니다.

  1. Cloud Shell에서 전용 asm-ingress 네임스페이스를 만듭니다.

    kubectl create namespace asm-ingress
    
  2. 네임스페이스 라벨을 asm-ingress 네임스페이스에 추가합니다.

    kubectl label namespace asm-ingress istio-injection=enabled
    

    출력은 다음과 비슷합니다.

    namespace/asm-ingress labeled
    

    asm-ingress 네임스페이스에 istio-injection=enabled 라벨을 지정하면 애플리케이션이 배포될 때 Cloud Service Mesh가 Envoy 사이드카 프록시를 자동으로 삽입합니다.

  3. Google Cloud 부하 분산기(나중에 GKE Gateway Controller를 통해 구성됨)와 인그레스 게이트웨이 간의 TLS 연결을 종료하기 위해 인그레스 게이트웨이에서 사용되는 자체 서명 인증서를 만들고 이 자체 서명 인증서를 Kubernetes 보안 비밀로 저장합니다.

    openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 \
     -subj "/CN=frontend.endpoints.${PROJECT}.cloud.goog/O=Edge2Mesh Inc" \
     -keyout frontend.endpoints.${PROJECT}.cloud.goog.key \
     -out frontend.endpoints.${PROJECT}.cloud.goog.crt
    
    kubectl -n asm-ingress create secret tls edge2mesh-credential \
     --key=frontend.endpoints.${PROJECT}.cloud.goog.key \
     --cert=frontend.endpoints.${PROJECT}.cloud.goog.crt
    

    인그레스 게이트웨이 인증서 요구사항에 대한 자세한 내용은 보안 백엔드 프로토콜 고려사항 가이드를 참조하세요.

  4. 다음 명령어를 실행하여 인그레스 게이트웨이 리소스 YAML을 만듭니다.

    mkdir -p ${WORKDIR}/asm-ig/base
    cat <<EOF > ${WORKDIR}/asm-ig/base/kustomization.yaml
    resources:
      - github.com/GoogleCloudPlatform/anthos-service-mesh-samples/docs/ingress-gateway-asm-manifests/base
    EOF
    
    mkdir ${WORKDIR}/asm-ig/variant
    cat <<EOF > ${WORKDIR}/asm-ig/variant/role.yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: asm-ingressgateway
      namespace: asm-ingress
    rules:
    - apiGroups: [""]
      resources: ["secrets"]
      verbs: ["get", "watch", "list"]
    EOF
    
    cat <<EOF > ${WORKDIR}/asm-ig/variant/rolebinding.yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: asm-ingressgateway
      namespace: asm-ingress
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: asm-ingressgateway
    subjects:
      - kind: ServiceAccount
        name: asm-ingressgateway
    EOF
    
    cat <<EOF > ${WORKDIR}/asm-ig/variant/service-proto-type.yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: asm-ingressgateway
    spec:
      ports:
      - name: status-port
        port: 15021
        protocol: TCP
        targetPort: 15021
      - name: http
        port: 80
        targetPort: 8080
      - name: https
        port: 443
        targetPort: 8443
        appProtocol: HTTP2
      type: ClusterIP
    EOF
    
    cat <<EOF > ${WORKDIR}/asm-ig/variant/gateway.yaml
    apiVersion: networking.istio.io/v1beta1
    kind: Gateway
    metadata:
      name: asm-ingressgateway
    spec:
      servers:
      - port:
          number: 443
          name: https
          protocol: HTTPS
        hosts:
        - "*" # IMPORTANT: Must use wildcard here when using SSL, see note below
        tls:
          mode: SIMPLE
          credentialName: edge2mesh-credential
    EOF
    
    cat <<EOF > ${WORKDIR}/asm-ig/variant/kustomization.yaml
    namespace: asm-ingress
    resources:
    - ../base
    - role.yaml
    - rolebinding.yaml
    patches:
    - path: service-proto-type.yaml
      target:
        kind: Service
    - path: gateway.yaml
      target:
        kind: Gateway
    EOF
    
  5. 인그레스 게이트웨이 CRD를 적용합니다.

    kubectl apply -k ${WORKDIR}/asm-ig/variant
    
  6. 모든 배포가 실행 중인지 확인합니다.

    kubectl wait --for=condition=available --timeout=600s deployment --all -n asm-ingress
    

    출력은 다음과 비슷합니다.

    deployment.apps/asm-ingressgateway condition met
    

서비스 메시 인그레스 게이트웨이 상태 점검 적용

서비스 메시 인그레스 게이트웨이를 Google Cloud 애플리케이션 부하 분산기에 통합할 때는 인그레스 게이트웨이 포드에 대한 상태 점검을 수행하도록 애플리케이션 부하 분산기를 구성해야 합니다. HealthCheckPolicy CRD는 상태 점검을 구성하는 API를 제공합니다.

  1. Cloud Shell에서 HealthCheckPolicy.yaml 파일을 만듭니다.

    cat <<EOF >${WORKDIR}/ingress-gateway-healthcheck.yaml
    apiVersion: networking.gke.io/v1
    kind: HealthCheckPolicy
    metadata:
      name: ingress-gateway-healthcheck
      namespace: asm-ingress
    spec:
      default:
        checkIntervalSec: 20
        timeoutSec: 5
        #healthyThreshold: HEALTHY_THRESHOLD
        #unhealthyThreshold: UNHEALTHY_THRESHOLD
        logConfig:
          enabled: True
        config:
          type: HTTP
          httpHealthCheck:
            #portSpecification: USE_NAMED_PORT
            port: 15021
            portName: status-port
            #host: HOST
            requestPath: /healthz/ready
            #response: RESPONSE
            #proxyHeader: PROXY_HEADER
        #requestPath: /healthz/ready
        #port: 15021
      targetRef:
        group: ""
        kind: Service
        name: asm-ingressgateway
    EOF
    
  2. HealthCheckPolicy:를 적용합니다.

    kubectl apply -f ${WORKDIR}/ingress-gateway-healthcheck.yaml
    

보안 정책 정의

Google Cloud Armor는 인그레스 리소스를 통해 부하 분산기에 연결할 수 있는 DDoS 방어 및 맞춤설정 가능한 보안 정책을 제공합니다. 다음 단계에서는 사전 구성된 규칙을 사용하여 교차 사이트 스크립팅(XSS) 공격을 차단하는 보안 정책을 만듭니다. 이 규칙은 알려진 공격 서명과 일치하지만 다른 모든 트래픽을 허용하는 트래픽을 차단합니다. 환경에 적용되는 규칙은 워크로드에 따라 달라질 수 있습니다.

  1. Cloud Shell에서 edge-fw-policy라는 보안 정책을 만듭니다.

    gcloud compute security-policies create edge-fw-policy \
      --description "Block XSS attacks"
    
  2. 사전 구성된 XSS 필터를 사용하는 보안 정책 규칙을 만듭니다.

    gcloud compute security-policies rules create 1000 \
        --security-policy edge-fw-policy \
        --expression "evaluatePreconfiguredExpr('xss-stable')" \
        --action "deny-403" \
        --description "XSS attack filtering"
    
  3. 인그레스 게이트웨이 서비스에 연결할 GCPBackendPolicy.yaml 파일을 만듭니다.

    cat <<EOF > ${WORKDIR}/cloud-armor-backendpolicy.yaml
    apiVersion: networking.gke.io/v1
    kind: GCPBackendPolicy
    metadata:
      name: cloud-armor-backendpolicy
      namespace: asm-ingress
    spec:
      default:
        securityPolicy: edge-fw-policy
      targetRef:
        group: ""
        kind: Service
        name: asm-ingressgateway
    EOF
    
  4. GCPBackendPolicy.yaml 파일을 적용합니다.

    kubectl apply -f ${WORKDIR}/cloud-armor-backendpolicy.yaml
    

IP 주소 지정 및 DNS 구성

  1. Cloud Shell에서 Google Cloud 부하 분산기의 전역 고정 IP 주소를 만듭니다.

    gcloud compute addresses create e2m-gclb-ip --global
    

    이 고정 IP 주소는 GKE 게이트웨이 리소스에서 사용되며 외부 부하 분산기가 변경되더라도 IP 주소가 동일하게 유지됩니다.

  2. 고정 IP 주소를 가져옵니다.

    export GCLB_IP=$(gcloud compute addresses describe e2m-gclb-ip 
    --global --format "value(address)")
    echo ${GCLB_IP}
    

    애플리케이션 부하 분산기의 고정 IP 주소에 대해 사용자 친화적이고 안정적인 매핑을 만들려면 공개 DNS 레코드가 있어야 합니다. 원하는 DNS 제공업체 및 자동화를 사용할 수 있습니다. 이 배포에서는 관리형 DNS 영역을 만드는 대신 Endpoints를 사용합니다. Endpoints는 공개 IP 주소에 무료 Google 관리 DNS 레코드를 제공합니다.

  3. 다음 명령어를 실행하여 dns-spec.yaml이라는 YAML 사양 파일을 만듭니다.

    cat <<EOF > ${WORKDIR}/dns-spec.yaml
    swagger: "2.0"
    info:
      description: "Cloud Endpoints DNS"
      title: "Cloud Endpoints DNS"
      version: "1.0.0"
    paths: {}
    host: "frontend.endpoints.${PROJECT}.cloud.goog"
    x-google-endpoints:
    - name: "frontend.endpoints.${PROJECT}.cloud.goog"
      target: "${GCLB_IP}"
    EOF
    

    YAML 사양은 공개 DNS 레코드를 frontend.endpoints.${PROJECT}.cloud.goog 형식으로 정의합니다. 여기서 ${PROJECT}는 고유한 프로젝트 식별자입니다.

  4. Google Cloud 프로젝트에 dns-spec.yaml 파일을 배포합니다.

    gcloud endpoints services deploy ${WORKDIR}/dns-spec.yaml
    

    출력은 다음과 비슷합니다.

    project [e2m-doc-01]...
    Operation "operations/acat.p2-892585880385-fb4a01ad-821d-4e22-bfa1-a0df6e0bf589" finished successfully.
    
    Service Configuration [2023-08-04r0] uploaded for service [frontend.endpoints.e2m-doc-01.cloud.goog]
    

    이제 IP 주소와 DNS가 구성되었으므로 공개 인증서를 생성하여 프런트엔드를 보호할 수 있습니다. GKE 게이트웨이와 통합하려면 인증서 관리자 TLS 인증서를 사용합니다.

TLS 인증서 프로비저닝

이 섹션에서는 인증서 관리자를 사용하여 TLS 인증서를 만들고 인증서 맵 항목을 통해 인증서 맵과 연결합니다. GKE 게이트웨이를 통해 구성된 애플리케이션 부하 분산기는 인증서를 사용하여 클라이언트와 Google Cloud 간의 보안 통신을 제공합니다. 생성된 인증서 맵 항목은 GKE 게이트웨이 리소스에서 참조됩니다.

  1. Cloud Shell에서 Certificate Manager API를 사용 설정합니다.

    gcloud services enable certificatemanager.googleapis.com --project=${PROJECT}
    
  2. TLS 인증서를 만듭니다.

    gcloud --project=${PROJECT} certificate-manager certificates create edge2mesh-cert \
        --domains="frontend.endpoints.${PROJECT}.cloud.goog"
    
  3. 인증서 맵을 만듭니다.

    gcloud --project=${PROJECT} certificate-manager maps create edge2mesh-cert-map
    
  4. 인증서 맵 항목을 사용하여 인증서 맵에 인증서를 연결합니다.

    gcloud --project=${PROJECT} certificate-manager maps entries create edge2mesh-cert-map-entry \
        --map="edge2mesh-cert-map" \
        --certificates="edge2mesh-cert" \
        --hostname="frontend.endpoints.${PROJECT}.cloud.goog"
    

GKE 게이트웨이 및 HTTPRoute 리소스 배포

이 섹션에서는 gke-l7-global-external-managed gatewayClass를 사용하여 Google Cloud 애플리케이션 부하 분산기를 프로비저닝하는 GKE 게이트웨이 리소스를 구성합니다. 또한 요청을 애플리케이션으로 라우팅하고 HTTP에서 HTTP(S)로 리디렉션을 수행하는 HTTPRoute 리소스를 구성합니다.

  1. Cloud Shell에서 다음 명령어를 실행하여 Gateway 매니페스트를 gke-gateway.yaml로 만듭니다.

    cat <<EOF > ${WORKDIR}/gke-gateway.yaml
    kind: Gateway
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
      name: external-http
      namespace: asm-ingress
      annotations:
        networking.gke.io/certmap: edge2mesh-cert-map
    spec:
      gatewayClassName: gke-l7-global-external-managed # gke-l7-gxlb
      listeners:
      - name: http # list the port only so we can redirect any incoming http requests to https
        protocol: HTTP
        port: 80
      - name: https
        protocol: HTTPS
        port: 443
      addresses:
      - type: NamedAddress
        value: e2m-gclb-ip # reference the static IP created earlier
    EOF
    
  2. Gateway 매니페스트를 적용하여 external-http라는 Gateway를 만듭니다.

    kubectl apply -f ${WORKDIR}/gke-gateway.yaml
    
  3. 기본 HTTPRoute.yaml 파일을 만듭니다.

    cat << EOF > ${WORKDIR}/default-httproute.yaml
    apiVersion: gateway.networking.k8s.io/v1beta1
    kind: HTTPRoute
    metadata:
      name: default-httproute
      namespace: asm-ingress
    spec:
      parentRefs:
      - name: external-http
        namespace: asm-ingress
        sectionName: https
      rules:
      - matches:
        - path:
            value: /
        backendRefs:
        - name: asm-ingressgateway
          port: 443
    EOF
    
  4. 기본 HTTPRoute를 적용합니다.

    kubectl apply -f ${WORKDIR}/default-httproute.yaml
    
  5. 추가 HTTPRoute.yaml 파일을 만들어 HTTP를 HTTP(S)로 리디렉션합니다.

    cat << EOF > ${WORKDIR}/default-httproute-redirect.yaml
    kind: HTTPRoute
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
      name: http-to-https-redirect-httproute
      namespace: asm-ingress
    spec:
      parentRefs:
      - name: external-http
        namespace: asm-ingress
        sectionName: http
      rules:
      - filters:
        - type: RequestRedirect
          requestRedirect:
            scheme: https
            statusCode: 301
    EOF
    
  6. 리디렉션 HTTPRoute를 적용합니다.

    kubectl apply -f ${WORKDIR}/default-httproute-redirect.yaml
    

    조정에는 시간이 걸립니다. programmed=true까지 다음 명령어를 사용합니다.

    kubectl get gateway external-http -n asm-ingress -w
    

Online Boutique 샘플 앱 설치

  1. Cloud Shell에서 전용 onlineboutique 네임스페이스를 만듭니다.

    kubectl create namespace onlineboutique
    
  2. onlineboutique 네임스페이스에 라벨을 추가합니다.

    kubectl label namespace onlineboutique istio-injection=enabled
    

    onlineboutique 네임스페이스에 istio-injection=enabled 라벨을 지정하면 애플리케이션이 배포될 때 Cloud Service Mesh가 Envoy 사이드카 프록시를 자동으로 삽입합니다.

  3. Online Boutique 샘플 앱의 Kubernetes YAML 파일을 다운로드합니다.

    curl -LO \
    https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/main/release/kubernetes-manifests.yaml
    
  4. Online Boutique 앱을 배포합니다.

    kubectl apply -f kubernetes-manifests.yaml -n onlineboutique
    

    출력은 다음과 비슷합니다(GKE Autopilot 기본 리소스 요청 및 한도 설정에 대한 경고 포함).

    Warning: autopilot-default-resources-mutator:Autopilot updated Deployment onlineboutique/emailservice: adjusted resources to meet requirements for containers [server] (see http://g.co/gke/autopilot-resources)
    deployment.apps/emailservice created
    service/emailservice created
    Warning: autopilot-default-resources-mutator:Autopilot updated Deployment onlineboutique/checkoutservice: adjusted resources to meet requirements for containers [server] (see http://g.co/gke/autopilot-resources)
    deployment.apps/checkoutservice created
    service/checkoutservice created
    Warning: autopilot-default-resources-mutator:Autopilot updated Deployment onlineboutique/recommendationservice: adjusted resources to meet requirements for containers [server] (see http://g.co/gke/autopilot-resources)
    deployment.apps/recommendationservice created
    service/recommendationservice created
    ...
    
  5. 모든 배포가 실행 중인지 확인합니다.

    kubectl get pods -n onlineboutique
    

    출력은 다음과 비슷합니다.

    NAME                                     READY   STATUS    RESTARTS   AGE
    adservice-64d8dbcf59-krrj9               2/2     Running   0          2m59s
    cartservice-6b77b89c9b-9qptn             2/2     Running   0          2m59s
    checkoutservice-7668b7fc99-5bnd9         2/2     Running   0          2m58s
    ...
    

    GKE Autopilot 클러스터가 애플리케이션을 지원하는 데 필요한 컴퓨팅 인프라를 프로비저닝할 때까지 몇 분 정도 기다립니다.

  6. 다음 명령어를 실행하여 VirtualService 매니페스트를 frontend-virtualservice.yaml로 만듭니다.

    cat <<EOF > frontend-virtualservice.yaml
    apiVersion: networking.istio.io/v1beta1
    kind: VirtualService
    metadata:
      name: frontend-ingress
      namespace: onlineboutique
    spec:
      hosts:
      - "frontend.endpoints.${PROJECT}.cloud.goog"
      gateways:
      - asm-ingress/asm-ingressgateway
      http:
      - route:
        - destination:
            host: frontend
            port:
              number: 80
    EOF
    

    VirtualService는 애플리케이션 네임스페이스(onlineboutique)에 생성됩니다. 일반적으로 애플리케이션 소유자는 앱 소유자가 VirtualService를 배포하도록 트래픽이 frontend 애플리케이션으로 라우팅되는 양과 방법을 결정하고 구성합니다.

  7. 클러스터에 frontend-virtualservice.yaml을 배포합니다.

    kubectl apply -f frontend-virtualservice.yaml
    
  8. 다음 링크에 액세스합니다.

    echo "https://frontend.endpoints.${PROJECT}.cloud.goog"
    

    Online Boutique 프런트엔드가 표시됩니다.

    Online Boutique 홈페이지에 표시되는 제품

  9. 인증서의 세부정보를 표시하려면 브라우저의 주소 표시줄에서 사이트 정보 보기를 클릭하고 인증서(유효)를 클릭합니다.

    인증서 뷰어에 유효 기간과 인증서 발급자를 포함한 관리형 인증서의 세부정보가 표시됩니다.

이제 서비스 메시에서 호스팅된 애플리케이션의 프런트엔드 역할을 하는 전역 HTTPS 부하 분산기가 준비되었습니다.

삭제

배포를 완료한 후에는 이후에 요금이 청구되지 않도록 Google Cloud에서 만든 리소스를 삭제할 수 있습니다. 프로젝트를 완전히 삭제하거나 클러스터 리소스를 삭제한 다음 클러스터를 삭제할 수 있습니다.

프로젝트 삭제

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

개별 리소스 삭제

이 배포에서 사용된 Google Cloud 프로젝트를 유지하려면 개별 리소스를 삭제합니다.

  1. Cloud Shell에서 HTTPRoute 리소스를 삭제합니다.

    kubectl delete -f ${WORKDIR}/default-httproute-redirect.yaml
    kubectl delete -f ${WORKDIR}/default-httproute.yaml
    
  2. GKE 게이트웨이 리소스를 삭제합니다.

    kubectl delete -f ${WORKDIR}/gke-gateway.yaml
    
  3. TLS 인증서 리소스(인증서 맵 항목 및 상위 인증서 맵 포함)를 삭제합니다.

    gcloud --project=${PROJECT} certificate-manager maps entries delete edge2mesh-cert-map-entry --map="edge2mesh-cert-map" --quiet
    gcloud --project=${PROJECT} certificate-manager maps delete edge2mesh-cert-map --quiet
    gcloud --project=${PROJECT} certificate-manager certificates delete edge2mesh-cert --quiet
    
  4. Endpoints DNS 항목을 삭제합니다.

    gcloud endpoints services delete "frontend.endpoints.${PROJECT}.cloud.goog"
    

    출력은 다음과 비슷합니다.

    Are you sure? This will set the service configuration to be deleted, along
    with all of the associated consumer information. Note: This does not
    immediately delete the service configuration or data and can be undone using
    the undelete command for 30 days. Only after 30 days will the service be
    purged from the system.
    
  5. 계속할지 묻는 메시지가 표시되면 Y를 입력합니다.

    출력은 다음과 비슷합니다.

    Waiting for async operation operations/services.frontend.endpoints.edge2mesh.cloud.goog-5 to complete...
    Operation finished successfully. The following command can describe the Operation details:
     gcloud endpoints operations describe operations/services.frontend.endpoints.edge2mesh.cloud.goog-5
    
  6. 고정 IP 주소를 삭제합니다.

    gcloud compute addresses delete ingress-ip --global
    

    출력은 다음과 비슷합니다.

    The following global addresses will be deleted:
    
     - [ingress-ip]
    
  7. 계속할지 묻는 메시지가 표시되면 Y를 입력합니다.

    출력은 다음과 비슷합니다.

    Deleted
    [https://www.googleapis.com/compute/v1/projects/edge2mesh/global/addresses/ingress-ip].
    
  8. GKE 클러스터를 삭제합니다.

    gcloud container clusters delete $CLUSTER_NAME --zone $CLUSTER_LOCATION
    

    출력은 다음과 비슷합니다.

    The following clusters will be deleted.
    - [edge-to-mesh] in [us-central1]
    
  9. 계속할지 묻는 메시지가 표시되면 Y를 입력합니다.

    몇 분이 지나면 출력은 다음과 비슷합니다.

    Deleting cluster edge-to-mesh...done.
    Deleted
    [https://container.googleapis.com/v1/projects/e2m-doc-01/zones/us-central1/clusters/edge-to-mesh].
    

다음 단계