Da borda à malha: expor aplicativos de malha de serviço via gateway do GKE

Last reviewed 2024-01-31 UTC

Nesta implantação, você verá como combinar o Cloud Service Mesh com o Cloud Load Balancing para expor aplicativos em uma malha de serviço aos clientes da Internet.

É possível expor um aplicativo aos clientes de várias maneiras, dependendo de onde o cliente está. Nesta implantação, mostramos como expor um aplicativo aos clientes combinando o Cloud Load Balancing com o Cloud Service Mesh para integrar balanceadores de carga a uma malha de serviço. Esta implantação é destinada a profissionais avançados que executam o Cloud Service Mesh. No entanto, ela também funciona para Istio no Google Kubernetes Engine.

Arquitetura

O diagrama a seguir mostra como usar gateways de entrada da malha para integrar balanceadores de carga a uma malha de serviço:

Um balanceador de carga externo encaminha os clientes externos para a malha por meio de proxies de gateway de entrada.

A entrada do Cloud age como o gateway do tráfego externo para a malha por meio da rede VPC.

Na topologia do diagrama anterior, a camada de entrada na nuvem, que é programada pelo gateway do GKE, origina o tráfego de fora da malha de serviço e direciona esse tráfego para a camada de entrada na malha. Em seguida, a camada de entrada da malha direciona o tráfego para os back-ends de aplicativos hospedados na malha.

A entrada do Cloud verifica a integridade da entrada da malha. Por sua vez, a entrada da malha verifica a integridade dos back-ends do aplicativo.

A topologia anterior tem as seguintes considerações:

  • Entrada na nuvem: nesta arquitetura de referência, você configura o balanceador de carga do Google Cloud pelo gateway do GKE para verificar a integridade dos proxies de entrada na malha nas portas de verificação de integridade expostas.
  • Entrada da malha: no aplicativo de malha, você realiza verificações de integridade diretamente nos back-ends a fim de executar o balanceamento de carga e o gerenciamento de tráfego localmente.

A segurança é implementada usando certificados gerenciados fora da malha e certificados internos dentro da malha.

O diagrama anterior ilustra a criptografia HTTPS do cliente para o balanceador de carga do Google Cloud, do balanceador de carga para o proxy de entrada da malha e do proxy de entrada para o proxy sidecar.

Objetivos

  • Implantar um cluster do Google Kubernetes Engine (GKE) no Google Cloud.
  • Implantar o Cloud Service Mesh baseado no Istio no cluster do GKE.
  • Configurar o gateway do GKE para encerrar o tráfego HTTPS público e direcionar esse tráfego para aplicativos hospedados por malha de serviço.
  • Implantar o aplicativo Online Boutique no cluster do GKE que você expõe aos clientes na Internet.

Otimização de custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.

Antes de começar

  1. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar o seletor de projetos

  2. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

  3. No Console do Google Cloud, ative o Cloud Shell.

    Ativar o Cloud Shell

    Todos os comandos de terminal desta implantação são executados a partir do Cloud Shell.

  4. Faça upgrade para a versão mais recente do Google Cloud CLI:

    gcloud components update
    
  5. Defina seu projeto padrão do Google Cloud:

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

    Substitua PROJECT pelo ID do projeto que quer usar nesta implantação.

  6. Crie um diretório de trabalho:

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

    Depois de concluir a implantação, exclua o diretório de trabalho.

Criar clusters do GKE

Os recursos descritos nesta implantação exigem uma versão de cluster do GKE 1.16 ou mais recente.

  1. No Cloud Shell, crie um novo arquivo kubeconfig. Esta etapa garante que você não crie conflitos com seu arquivo kubeconfig (padrão) atual.

    touch edge2mesh_kubeconfig
    export KUBECONFIG=${WORKDIR}/edge2mesh_kubeconfig
    
  2. Defina as variáveis de ambiente no cluster do GKE:

    export CLUSTER_NAME=edge-to-mesh
    export CLUSTER_LOCATION=us-central1
    
  3. Ative a API Google Kubernetes Engine:

    gcloud services enable container.googleapis.com
    
  4. Crie um cluster do GKE Autopilot:

    gcloud container --project ${PROJECT} clusters create-auto 
    ${CLUSTER_NAME} --region ${CLUSTER_LOCATION} --release-channel rapid
    
  5. Certifique-se de que o cluster está em execução:

    gcloud container clusters list
    

    O resultado será assim:

    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
    

Instalar uma malha de serviço

Nesta seção, você configurará o Cloud Service Mesh gerenciado com a API de frota.

  1. No Cloud Shell, ative as APIs necessárias:

    gcloud services enable mesh.googleapis.com
    
  2. Ative o Cloud Service Mesh na frota:

    gcloud container fleet mesh enable
    
  3. Registre o cluster na frota:

    gcloud container fleet memberships register ${CLUSTER_NAME} \
      --gke-cluster ${CLUSTER_LOCATION}/${CLUSTER_NAME}
    
  4. Aplique o rótulo mesh_id ao cluster edge-to-mesh:

    gcloud container clusters update ${CLUSTER_NAME} --project ${PROJECT} --region ${CLUSTER_LOCATION} --update-labels mesh_id=proj-${PROJECT_NUMBER}
    
  5. Ative o gerenciamento automático do plano de controle e o plano de dados gerenciado:

    gcloud container fleet mesh update \
      --management automatic \
      --memberships ${CLUSTER_NAME}
    
  6. Após alguns minutos, verifique se o status no plano de controle é ACTIVE:

    gcloud container fleet mesh describe
    

    O resultado será assim:

    ...
    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
    ...
    

Implantar o gateway do GKE

Nas etapas a seguir, implante o balanceador de carga de aplicativo externo pelo GKE Gateway Controller. O recurso de gateway do GKE automatiza o provisionamento do balanceador de carga e da verificação de integridade do back-end. Além disso, é possível usar o Gerenciador de certificados para provisionar e gerenciar um certificado TLS e o Endpoints para provisionar automaticamente um nome DNS público para o aplicativo.

Instalar um gateway de entrada da malha de serviço

Como prática recomendada de segurança, recomendamos que você implante o gateway de entrada em um namespace diferente do plano de controle.

  1. No Cloud Shell, crie um namespace asm-ingress dedicado:

    kubectl create namespace asm-ingress
    
  2. Adicione um rótulo ao namespace asm-ingress:

    kubectl label namespace asm-ingress istio-injection=enabled
    

    O resultado será assim:

    namespace/asm-ingress labeled
    

    Rotular o namespace asm-ingress com istio-injection=enabled instrui o Cloud Service Mesh a injetar automaticamente os proxies sidecar do Envoy quando um aplicativo é implantado.

  3. Crie um certificado autoassinado usado pelo gateway de entrada para encerrar conexões TLS entre o balanceador de carga do Google Cloud (a ser configurado posteriormente pelo GKE Gateway Controller) e o gateway de entrada e armazene esse certificado como um secret do 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
    

    Para mais detalhes sobre os requisitos do certificado do gateway de entrada, consulte o guia de considerações do protocolo de back-end seguro.

  4. Execute os seguintes comandos para criar o YAML do recurso do gateway de entrada:

    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. Aplique as CRDs do gateway de entrada:

    kubectl apply -k ${WORKDIR}/asm-ig/variant
    
  6. Verifique se todas as implantações estão funcionando:

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

    O resultado será assim:

    deployment.apps/asm-ingressgateway condition met
    

Aplicar uma verificação de integridade do gateway de entrada da malha de serviço

Ao integrar um gateway de entrada da malha de serviço a um balanceador de carga de aplicativo do Google Cloud, o balanceador de carga de aplicativo precisa estar configurado para executar verificações de integridade nos pods do gateway de entrada. A CRD HealthCheckPolicy fornece uma API para configurar essa verificação de integridade.

  1. No Cloud Shell, crie o arquivo 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. Aplique o HealthCheckPolicy:

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

Definir políticas de segurança

O Google Cloud Armor fornece proteção contra DDoS e políticas de segurança personalizáveis que podem ser anexadas a um balanceador de carga por meio de recursos do Ingress. Nas etapas a seguir, você criará uma política de segurança que usa regras pré-configuradas para bloquear ataques de scripting em vários locais (XSS). Essa regra ajuda a bloquear o tráfego que corresponde a assinaturas de ataque conhecidas, mas permite qualquer outro tráfego. Seu ambiente pode usar regras diferentes dependendo da carga de trabalho.

  1. No Cloud Shell, crie uma política de segurança chamada edge-fw-policy:

    gcloud compute security-policies create edge-fw-policy \
      --description "Block XSS attacks"
    
  2. Crie uma regra de política de segurança que use os filtros XSS pré-configurados:

    gcloud compute security-policies rules create 1000 \
        --security-policy edge-fw-policy \
        --expression "evaluatePreconfiguredExpr('xss-stable')" \
        --action "deny-403" \
        --description "XSS attack filtering"
    
  3. Crie o arquivo GCPBackendPolicy.yaml para anexar ao serviço do gateway de entrada:

    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. Aplique o arquivo GCPBackendPolicy.yaml:

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

Configurar o endereçamento IP e o DNS

  1. No Cloud Shell, crie um endereço IP estático global para o balanceador de carga do Google Cloud:

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

    Esse endereço IP estático é usado pelo recurso do gateway do GKE e permite que o endereço IP permaneça igual, mesmo que o balanceador de carga externo seja alterado.

  2. Consiga o endereço IP estático:

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

    Para criar um mapeamento estável e legível para o endereço IP estático do balanceador de carga de aplicativo, é necessário ter um registro DNS público. Use o provedor de DNS e a automação que quiser. Nesta implantação, usamos o Endpoints em vez de criar uma zona de DNS gerenciada. O Endpoints fornece gratuitamente um registro DNS gerenciado pelo Google para um endereço IP público.

  3. Execute o seguinte comando para criar o arquivo de especificação YAML chamado dns-spec.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
    

    A especificação YAML define o registro DNS público no formato frontend.endpoints.${PROJECT}.cloud.goog, em que ${PROJECT} é o identificador exclusivo do projeto.

  4. Implante o arquivo dns-spec.yaml no projeto do Google Cloud:

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

    O resultado será assim:

    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]
    

    Agora que o endereço IP e o DNS estão configurados, é possível gerar um certificado público para proteger o front-end. Para fazer a integração com o gateway do GKE, use os certificados TLS do Gerenciador de certificados.

Provisionar um certificado TLS

Nesta seção, crie um certificado TLS usando o Gerenciador de certificados e associe-o a um mapa de certificados usando uma entrada desse mapa. O balanceador de carga de aplicativo configurado pelo gateway do GKE usa o certificado para fornecer comunicações seguras entre o cliente e o Google Cloud. Após a criação, a entrada do mapa de certificados é referenciada pelo recurso do gateway do GKE.

  1. No Cloud Shell, ative a API Certificate Manager:

    gcloud services enable certificatemanager.googleapis.com --project=${PROJECT}
    
  2. Crie o certificado TLS:

    gcloud --project=${PROJECT} certificate-manager certificates create edge2mesh-cert \
        --domains="frontend.endpoints.${PROJECT}.cloud.goog"
    
  3. Crie o mapa de certificados:

    gcloud --project=${PROJECT} certificate-manager maps create edge2mesh-cert-map
    
  4. Anexe o certificado ao mapa de certificados com uma entrada desse mapa:

    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"
    

Implante os recursos do gateway do GKE e HTTPRoute

Nesta seção, configure o recurso do gateway do GKE que provisiona o balanceador de carga de aplicativo do Google Cloud usando gke-l7-global-external-managed gatewayClass. Além disso, configure os recursos HTTPRoute que encaminham solicitações para o aplicativo e executam redirecionamentos HTTP para HTTP(S).

  1. No Cloud Shell, execute o seguinte comando para criar o manifesto Gateway como 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. Aplique o manifesto Gateway para criar um Gateway chamado external-http:

    kubectl apply -f ${WORKDIR}/gke-gateway.yaml
    
  3. Crie o arquivo HTTPRoute.yaml padrão:

    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. Aplique o HTTPRoute padrão:

    kubectl apply -f ${WORKDIR}/default-httproute.yaml
    
  5. Crie mais um arquivo HTTPRoute.yaml para executar redirecionamentos HTTP para 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. Aplique o HTTPRoute de redirecionamento:

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

    A reconciliação leva tempo. Use o seguinte comando até programmed=true:

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

Instalar o app de exemplo Online Boutique

  1. No Cloud Shell, crie um namespace onlineboutique dedicado:

    kubectl create namespace onlineboutique
    
  2. Adicione um rótulo ao namespace onlineboutique:

    kubectl label namespace onlineboutique istio-injection=enabled
    

    Rotular o namespace onlineboutique com istio-injection=enabled instrui o Cloud Service Mesh a injetar automaticamente os proxies sidecar do Envoy quando um aplicativo é implantado.

  3. Faça o download dos arquivos YAML do Kubernetes para o aplicativo de exemplo Online Boutique:

    curl -LO \
    https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/main/release/kubernetes-manifests.yaml
    
  4. Implante o aplicativo do Online Boutique:

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

    A saída é semelhante a esta (incluindo avisos sobre como definir solicitações e limites de recursos padrão do 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. Verifique se todas as implantações estão funcionando:

    kubectl get pods -n onlineboutique
    

    O resultado será assim:

    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
    ...
    

    Aguarde alguns minutos para que o cluster do GKE Autopilot provisione a infraestrutura de computação necessária para permitir o aplicativo.

  6. Execute o seguinte comando para criar o manifesto VirtualService como 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
    

    O VirtualService é criado no namespace do aplicativo (onlineboutique). Em geral, o proprietário do aplicativo decide e configura como e qual tráfego será roteado para o aplicativo frontend para que o VirtualService seja implantado pelo proprietário do aplicativo.

  7. Implante frontend-virtualservice.yaml no cluster:

    kubectl apply -f frontend-virtualservice.yaml
    
  8. Acesse o seguinte link:

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

    Seu front-end do Online Boutique é exibido.

    Produtos mostrados na página inicial da Online Boutique.

  9. Para exibir os detalhes do certificado, clique em Ver informações do site na barra de endereço do seu navegador e, depois, clique em Certificado (válido).

    O visualizador de certificados exibe detalhes do certificado gerenciado, incluindo a data de validade e quem emitiu o certificado.

Agora você tem um balanceador de carga HTTPS global que serve como front-end para seu aplicativo hospedado pela malha de serviço.

Limpeza

Após concluir esta implantação, é possível limpar os recursos que você criou no Google Cloud para que não sejam faturados no futuro. É possível excluir todo o projeto ou remover recursos do cluster e, depois, excluir o cluster.

Excluir o projeto

  1. No Console do Google Cloud, acesse a página Gerenciar recursos.

    Acessar "Gerenciar recursos"

  2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
  3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Excluir recursos individuais

Se você quiser manter o projeto do Google Cloud usado nesta implantação, exclua os recursos individuais:

  1. No Cloud Shell, exclua os recursos HTTPRoute:

    kubectl delete -f ${WORKDIR}/default-httproute-redirect.yaml
    kubectl delete -f ${WORKDIR}/default-httproute.yaml
    
  2. Exclua o recurso do gateway do GKE:

    kubectl delete -f ${WORKDIR}/gke-gateway.yaml
    
  3. Exclua os recursos do certificado TLS (incluindo a entrada do mapa de certificados e o respectivo mapa de certificados pai):

    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. Exclua a entrada DNS do Endpoints:

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

    O resultado será assim:

    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. Quando for solicitado continuar, digite Y.

    O resultado será assim:

    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. Exclua o endereço IP estático:

    gcloud compute addresses delete ingress-ip --global
    

    O resultado será assim:

    The following global addresses will be deleted:
    
     - [ingress-ip]
    
  7. Quando for solicitado continuar, digite Y.

    O resultado será assim:

    Deleted
    [https://www.googleapis.com/compute/v1/projects/edge2mesh/global/addresses/ingress-ip].
    
  8. Exclua o cluster do GKE:

    gcloud container clusters delete $CLUSTER_NAME --zone $CLUSTER_LOCATION
    

    O resultado será assim:

    The following clusters will be deleted.
    - [edge-to-mesh] in [us-central1]
    
  9. Quando for solicitado continuar, digite Y.

    Após alguns minutos, a saída será semelhante a esta:

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

A seguir