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

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:

Observação: em aplicativos no Cloud Service Mesh, a implantação do balanceador de carga TCP/UDP externo é do tipo de exposição padrão. Implante o balanceador de carga por meio do serviço do Kubernetes, que seleciona os pods dos proxies de entrada da malha.

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 topologia anterior tem as seguintes considerações:

• Entrada na nuvem:nesta arquitetura de referência, você configura o balanceador de cargaGoogle 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.

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

Objetivos

• Implante um cluster do Google Kubernetes Engine (GKE) em 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ê vai usar os seguintes componentes faturáveis do Google Cloud:

• Google Kubernetes Engine
• Compute Engine
• Cloud Load Balancing
• Certificate Manager
• Cloud Service Mesh
• Google Cloud Armor
• Cloud Endpoints

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 um teste sem custo financeiro.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Para mais informações, consulte Limpeza.

Antes de começar

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

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

2. Verify that billing is enabled for your Google Cloud project.

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

   Activate 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 Google Cloud padrão:

   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'
           implementation: TRAFFIC_DIRECTOR
           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 ingress-gateway dedicado:

   kubectl create namespace ingress-gateway
   

2. Adicione um rótulo ao namespace ingress-gateway:

   kubectl label namespace ingress-gateway istio-injection=enabled
   

   O resultado será assim:

   namespace/ingress-gateway labeled
   

   Rotular o namespace ingress-gateway 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 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 ingress-gateway 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}/ingress-gateway/base
   cat <<EOF > ${WORKDIR}/ingress-gateway/base/kustomization.yaml
   resources:
     - github.com/GoogleCloudPlatform/anthos-service-mesh-samples/docs/ingress-gateway-asm-manifests/base
   EOF
   
   mkdir ${WORKDIR}/ingress-gateway/variant
   cat <<EOF > ${WORKDIR}/ingress-gateway/variant/role.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: asm-ingressgateway
   rules:
   - apiGroups: [""]
     resources: ["secrets"]
     verbs: ["get", "watch", "list"]
   EOF
   
   cat <<EOF > ${WORKDIR}/ingress-gateway/variant/rolebinding.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: asm-ingressgateway
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: asm-ingressgateway
   subjects:
     - kind: ServiceAccount
       name: asm-ingressgateway
   EOF
   
   cat <<EOF > ${WORKDIR}/ingress-gateway/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}/ingress-gateway/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, as SNI isn't passed from GFE
       tls:
         mode: SIMPLE
         credentialName: edge2mesh-credential
   EOF
   
   cat <<EOF > ${WORKDIR}/ingress-gateway/variant/kustomization.yaml
   namespace: ingress-gateway
   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}/ingress-gateway/variant
   

6. Verifique se todas as implantações estão funcionando:

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

   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, o balanceador de carga de aplicativo precisa estar configurado para executar verificações de integridade nos pods do gateway de entrada. Google Cloud 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: ingress-gateway
   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 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 de Entrada. 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: ingress-gateway
   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 cargaGoogle 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 seu projeto 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 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 Google Cloud usando o 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/v1
   metadata:
     name: external-http
     namespace: ingress-gateway
     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/v1
   kind: HTTPRoute
   metadata:
     name: default-httproute
     namespace: ingress-gateway
   spec:
     parentRefs:
     - name: external-http
       namespace: ingress-gateway
       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/v1
   metadata:
     name: http-to-https-redirect-httproute
     namespace: ingress-gateway
   spec:
     parentRefs:
     - name: external-http
       namespace: ingress-gateway
       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 ingress-gateway -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:
     - ingress-gateway/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.

   

   Observação: talvez você receba um erro ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Esse erro ocorre quando os certificados ainda não foram propagados para todos os front-ends do Google (GFEs) em nível global. Aguarde alguns minutos e tente acessar o link novamente.

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.

Limpar

Após concluir a 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

Cuidado: excluir um projeto tem os seguintes efeitos:
• Tudo no projeto é excluído. Se você tiver usado um projeto atual para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos nele.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um ID do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.
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.

Excluir recursos individuais

Se você quiser manter o projeto 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

• Saiba mais sobre mais recursos oferecidos pelo Entrada do GKE que podem ser usados com sua malha de serviço.
• Saiba mais sobre os diferentes tipos de balanceamento de carga na nuvem disponíveis para o GKE.
• Saiba mais sobre os recursos e as funcionalidades oferecidas pelo Cloud Service Mesh.
• Veja como implantar o Entrada em vários clusters do GKE para balanceamento de carga multirregional.
• Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.