Da borda à malha: como expor aplicativos de malha de serviço por meio da Entrada do GKE

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

O Anthos Service Mesh é uma malha de serviço gerenciado e baseado no Istio. Ele oferece uma camada de comunicação padronizada, observável e de segurança aumentada para aplicativos. Não importa se você usa o Anthos Service Mesh, o Traffic Director ou o Istio, uma malha de serviço oferece uma plataforma de comunicação holística para os clientes que se comunicam na malha. No entanto, o desafio permanece em como conectar clientes que estão fora da malha aos aplicativos hospedados na malha.

É possível expor um aplicativo aos clientes de várias maneiras, dependendo de onde o cliente está. Neste tutorial, mostramos como expor um aplicativo aos clientes unindo o Cloud Load Balancing ao Anthos Service Mesh para integrar balanceadores de carga a uma malha de serviço. Este tutorial se destina a profissionais avançados que executam o Anthos Service Mesh. No entanto, ele também funciona para Istio no Google Kubernetes Engine.

Gateway de entrada da malha

O Istio 0.8 apresentou o gateway de entrada (em inglês) da malha que fornece um conjunto dedicado de proxies com portas que ficam expostas ao tráfego que vem de fora da malha de serviço. Esses proxies de entrada da malha permitem controlar o comportamento de exposição L4 separadamente do comportamento de roteamento de aplicativos. Os proxies também permitem aplicar o roteamento e a política ao tráfego externo da malha antes de chegar ao sidecar de um aplicativo. A entrada da malha define o tratamento de tráfego quando ele chega a um nó da malha. Antes, no entanto, os componentes externos precisam definir como o tráfego chega à malha.

Para gerenciar esse tráfego externo, você precisa de um balanceador de carga externo para a malha. Neste tutorial, o Google Cloud Load Balancing é provisionado por meio de recursos de entrada do GKE para automatizar a implantação. O exemplo canônico dessa configuração é um serviço de balanceamento de carga externo que, no caso do Google Cloud, implanta um balanceador de carga TCP/UDP público. Esse balanceador de carga aponta para os NodePorts de um cluster do GKE. Esses NodePorts expõem os pods de gateway de entrada do Istio, que roteiam o tráfego para proxies sidecar de malha downstream. O diagrama a seguir ilustra essa topologia. O balanceamento de carga do tráfego particular interno é semelhante a esta arquitetura, exceto pelo fato de que você implanta um balanceador de carga TCP/UDP interno.

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

O uso do balanceamento de carga transparente L4 com um gateway de entrada da malha oferece as seguintes vantagens:

  • Esta configuração simplifica a implantação do balanceador de carga.
  • O balanceador de carga fornece um IP virtual (VIP, na sigla em inglês) estável, uma verificação de integridade e uma distribuição de tráfego confiável quando ocorrem alterações no cluster, interrupções de nó ou de processo.
  • Todas as regras de roteamento, terminação TLS e política de tráfego são processadas em um único local no gateway de entrada da malha.

Entrada e serviços do GKE

Há várias maneiras de fornecer acesso a aplicativos àqueles clientes que estão fora do cluster. Veja na tabela a seguir os componentes primitivos do Kubernetes disponíveis para implantar balanceadores de carga no Google Cloud. O tipo de balanceador de carga que você usa para expor aplicativos aos clientes dependerá muito se eles forem externos ou internos, que tipo de suporte de protocolo é necessário e se a malha de serviço abrange vários clusters do GKE ou se estão em um único cluster.

Qualquer um dos tipos de balanceador de carga na tabela a seguir pode expor aplicativos hospedados em malha, dependendo do caso de uso.

Recurso do GKE Balanceador de carga baseado na nuvem Características
Entrada para balanceamento de carga de HTTP(S) externo Balanceador de carga HTTP(S) externo

Proxies L7 em pontos de presença (PoPs, na sigla em inglês) de extremidade do Google

VIP público

Escopo global

Cluster único

Entrada para balanceamento de carga de HTTP(S) interno Balanceador de carga HTTP(S) interno

Proxies L7 dentro da rede de nuvem privada virtual (VPC)

VIP particular

Escopo regional

Cluster único

Serviço LoadBalancer externo Balanceador de carga TCP/UDP externo

Passagem de L4 em PoPs de extremidade do Google

VIP público

Escopo regional

Cluster único

Serviço LoadBalancer interno Balanceador de carga TCP/UDP interno

Passagem de L4 na rede de roteamento da VPC

VIP particular

Escopo regional

Cluster único

Entrada de vários clusters (vários clusters, entrada externa) Balanceador de carga HTTP(S) externo

Proxies L7 em PoPs de extremidade do Google

VIP público

Escopo global

Vários clusters

Embora o balanceador de carga padrão do Anthos Service Mesh seja o TCP/UDP externo, este tutorial se concentra no balanceador de carga HTTP(S) externo que você implanta usando o balanceamento de carga HTTP(S) externo. O balanceador de carga HTTP(S) externo oferece integração com serviços de extremidade, como o Identity-Aware Proxy (IAP), o Google Cloud Armor e o Cloud CDN, bem como uma rede distribuída globalmente de proxies de extremidade. Na próxima seção, descrevemos a arquitetura e as vantagens do uso de duas camadas de balanceamento de carga HTTP.

Entrada na nuvem e entrada da malha

A implantação do balanceamento de carga L7 externo fora da malha com uma camada de entrada da malha oferece vantagens significativas, especialmente para o tráfego da Internet. Mesmo que os gateways de entrada do Anthos Service Mesh e do Istio forneçam roteamento avançado e gerenciamento de tráfego na malha, algumas funções são melhor veiculadas na extremidade da rede. Aproveitar a rede na extremidade da Internet por meio do balanceamento de carga HTTP(S) externo do Google Cloud pode oferecer benefícios significativos de desempenho, confiabilidade ou segurança em relação à entrada da malha. Esses benefícios incluem:

Essa camada externa de balanceamento de carga L7 é chamada de entrada na nuvem porque ela é criada em balanceadores de carga gerenciados na nuvem, em vez de proxies auto-hospedados usados pela entrada da malha. A combinação de entrada na nuvem e entrada da malha utiliza recursos complementares da infraestrutura do Google Cloud e da malha. Veja no diagrama a seguir como combinar a entrada na nuvem e a entrada da malha para exibir na forma de duas camadas de balanceamento de carga no tráfego da Internet.

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

Nessa topologia, a camada de entrada na nuvem recebe tráfego de fora da malha de serviço e direciona esse tráfego à camada de entrada da malha. Em seguida, a camada de entrada da malha direciona o tráfego para os back-ends de aplicativos hospedados na malha.

Topologia de entrada na nuvem e da malha

Nesta seção, descrevemos os papéis complementares que cada camada de entrada ocupa quando são usados em conjunto. Esses papéis não são regras concretas, mas sim diretrizes que usam as vantagens de cada camada. É provável que as variações desse padrão sejam baseadas no seu caso de uso.

  • Entrada do Cloud: quando emparelhada com a entrada da malha, a camada de entrada na nuvem é melhor usada para segurança de extremidade e balanceamento de carga global. A camada de entrada na nuvem é integrada à proteção contra DDoS, firewalls de nuvem, autenticação e produtos de criptografia na extremidade. Por isso, essa camada se destaca em executar esses serviços fora da malha. A lógica de roteamento costuma ser objetiva nessa camada, mas ela pode ser mais complexa para ambientes multirregionais e com vários clusters. Devido à função crucial dos balanceadores de carga voltados para a Internet, a camada de entrada na nuvem é provavelmente gerenciada por uma equipe de infraestrutura que tem controle exclusivo sobre como os aplicativos são expostos e protegidos na Internet. Esse controle também torna essa camada menos flexível e dinâmica do que uma infraestrutura orientada por desenvolvedores, uma consideração que pode afetar a quem e como você fornece acesso administrativo a essa camada.
  • Entrada da malha: quando pareada com a entrada na nuvem, a camada de entrada da malha fornece um roteamento flexível parecido com o do aplicativo. Devido a essa flexibilidade, a entrada da malha é melhor que a entrada na nuvem, seguindo a lógica de roteamento complexa e a visibilidade no nível do aplicativo. A separação entre camadas de entrada também facilita aos proprietários de aplicativos na hora de controlar diretamente essa camada sem afetar outras equipes. Ao expor aplicativos da malha de serviço por meio de um balanceador de carga L4 em vez de L7, recomendamos que você encerre o TLS do cliente na camada de entrada dentro da malha para ajudar a proteger aplicativos.

Verificação de integridade

Uma das complexidades do uso de duas camadas do balanceamento de carga L7 é a verificação de integridade. Você precisa configurar cada balanceador de carga para verificar a integridade da próxima camada a fim de garantir que ela possa receber tráfego. A topologia do diagrama a seguir mostra como a entrada na nuvem verifica a integridade dos proxies de entrada da malha. Em contrapartida, a malha verifica a integridade dos back-ends do aplicativo.

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.

Essa topologia tem as seguintes considerações:

  • Entrada do Cloud: neste tutorial, você configura o balanceador de carga do Google Cloud por meio da entrada para verificar a integridade dos proxies de entrada da malha nas portas expostas da verificação de integridade. Se um proxy de malha estiver inativo ou se o cluster, a malha ou a região não estiverem disponíveis, o balanceador de carga do Google Cloud detectará essa condição e não enviará tráfego ao proxy da malha.
  • 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.

Segurança

A topologia anterior envolve diversos elementos de segurança. Um dos elementos mais importantes é a forma de configurar a criptografia e implantar certificados. O Entrada para balanceamento de carga HTTP(S) externo tem ampla integração com certificados gerenciados pelo Google. Essa integração provisiona automaticamente certificados públicos, anexa-os a um balanceador de carga e renova e alterna certificados por meio da interface declarativa do Entrada do GKE. Os clientes da Internet se autenticam nos certificados públicos e se conectam ao balanceador de carga externo como o primeiro salto na nuvem privada virtual (VPC).

O próximo salto, que fica entre o Google Front End (GFE) e o proxy de entrada da malha, é criptografado por padrão. A criptografia no nível da rede entre os GFEs e respectivos back-ends é aplicada automaticamente. No entanto, se os seus requisitos de segurança ditam que o proprietário da plataforma retém a propriedade das chaves de criptografia, será possível ativar HTTPS entre a entrada do cluster (o GFE) e a entrada da malha (a instância de proxy envoy). Quando você ativa HTTPs para esse caminho, é possível usar um certificado autoassinado ou público para criptografar o tráfego. O GFE não faz a autenticação nele. Para evitar o mau uso de certificados, não use o certificado público do balanceador de carga público em outro lugar. Em vez disso, recomendamos usar certificados diferentes na malha de serviço.

Se a malha de serviço exigir TLS, todo o tráfego será criptografado entre proxies sidecar e a entrada da malha. Neste tutorial, não ativaremos HTTPS entre os GFEs e a camada de entrada da malha, embora essa arquitetura possa ser aplicável ao seu ambiente. O diagrama a seguir 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.

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

Objetivos

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

Custos

Neste tutorial, usamos 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 ser qualificados para uma avaliação gratuita.

Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Para mais informações, consulte Como fazer a 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 o faturamento está ativado para seu projeto na nuvem. Saiba como confirmar se o faturamento está ativado para o projeto.

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

    Ativar o Cloud Shell

    Todos os comandos de terminal deste tutorial são executados a partir do Cloud Shell.

  4. Defina seu projeto padrão do Google Cloud:

    export PROJECT=$(gcloud info --format='value(config.project)')
    export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT} --format="value(projectNumber)")
    gcloud config set project ${PROJECT}
    
  5. Clone o repositório de código para acessar os arquivos deste tutorial e crie um diretório de trabalho:

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

    Depois de concluir o tutorial, é possível excluir o diretório de trabalho.

Como criar clusters do GKE

Os recursos descritos neste tutorial 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-west1-a
    
  3. Crie um cluster do GKE.

    gcloud container clusters create ${CLUSTER_NAME} \
        --machine-type=e2-standard-4 \
        --num-nodes=4 \
        --zone ${CLUSTER_LOCATION} \
        --enable-stackdriver-kubernetes \
        --enable-ip-alias \
        --workload-pool=${PROJECT}.svc.id.goog \
        --release-channel rapid
    
  4. Certifique-se de que o cluster está em execução:

    gcloud container clusters list
    

    A resposta será semelhante a:

    NAME          LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
    edge-to-mesh  us-west1-a  v1.19.9-gke.1400  34.83.193.134  e2-standard-4  v1.19.9-gke.1400  4          RUNNING
    
  5. Conecte-se ao cluster:

    gcloud container clusters get-credentials ${CLUSTER_NAME} --zone ${CLUSTER_LOCATION} --project ${PROJECT}
    

Como instalar uma malha de serviço

  1. No Cloud Shell, faça o download do arquivo de instalação do Anthos Service Mesh.

    Crie um arquivo de sobreposição personalizado para configurar o IstioOperator com a anotação do NEG:

    cat <<EOF > ingress-backendconfig-operator.yaml
    ---
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    spec:
      components:
        ingressGateways:
          - name: istio-ingressgateway
            enabled: true
            k8s:
              service:
                type: ClusterIP
              serviceAnnotations:
                cloud.google.com/backend-config: '{"default": "ingress-backendconfig"}'
                cloud.google.com/neg: '{"ingress": true}'
    EOF
    

    Essa sobreposição personalizada corrige o serviço istio-ingressgateway com anotações personalizadas usadas pela entrada do GKE.

    Esse serviço tem as seguintes anotações que definem parâmetros do balanceador de carga do Entrada quando ele é implantado:

    • cloud.google.com/backend-config refere-se ao nome de um recurso personalizado chamado BackendConfig. O controlador Entrada usa BackendConfig para definir parâmetros no recurso BackendService do Google Cloud. Use esse recurso na próxima etapa para definir parâmetros personalizados da verificação de integridade do Google Cloud.
    • cloud.google.com/neg: '{"ingress": true}' ativa os back-ends de Entrada (os proxies de entrada da malha, neste caso) para balanceamento de carga nativo de contêiner. Para um balanceamento de carga mais eficiente e estável, esses back-ends usam grupos de endpoints da rede (NEGs, na sigla em inglês) em vez de grupos de instâncias.

    Siga as etapas em Como instalar o Anthos Service Mesh no GKE para usar um script fornecido pelo Google para instalar o Anthos Service Mesh. Ao executar o script, inclua a seguinte opção:

    --custom_overlay ingress-backendconfig-operator.yaml
    

    Exemplo:

    ./install_asm \
        --project_id ${PROJECT} \
        --cluster_name ${CLUSTER_NAME} \
        --cluster_location ${CLUSTER_LOCATION} \
        --mode install \
        --enable_all \
        --custom_overlay ingress-backendconfig-operator.yaml
    
  2. Verifique se todas as implantações estão funcionando:

    kubectl wait --for=condition=available --timeout=600s deployment --all -n istio-system
    

    A resposta será semelhante a:

    deployment.apps/istio-ingressgateway condition met
    deployment.apps/istiod-asm-193-2 condition met
    

Como instalar o aplicativo de exemplo Online Boutique

  1. No Cloud Shell, adicione um rótulo ao namespace default:

    kubectl label namespace default istio-injection- istio.io/rev=asm-193-2 --overwrite
    

    Rotular o namespace namespace instrui o Istio a injetar automaticamente proxies sidecar do Envoy quando um aplicativo é implantado. A resposta será semelhante a:

    namespace/default labeled
    
  2. Faça o download dos arquivos YAML do Kubernetes e do Istio para o aplicativo de exemplo Online Boutique:

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

    kubectl apply -f kubernetes-manifests.yaml
    

    A saída será assim:

    deployment.apps/frontend created
    service/frontend created
    service/frontend-external created
    ...
    
  4. Verifique se todas as implantações estão funcionando:

    kubectl get pods
    

    A saída será assim:

    NAME                                     READY   STATUS    RESTARTS   AGE
    adservice-d854d8786-fjb7q                2/2     Running   0          3m
    cartservice-85b5d5b4ff-8qn7g             2/2     Running   0          2m59s
    checkoutservice-5f9bf659b8-sxhsq         2/2     Running   0          3m1s
    ...
    
  5. Implante os manifestos do Istio:

    kubectl apply -f istio-manifests.yaml
    

    A saída será assim:

    virtualservice.networking.istio.io/frontend created
    gateway.networking.istio.io/frontend-gateway created
    virtualservice.networking.istio.io/frontend-ingress created
    serviceentry.networking.istio.io/allow-egress-googleapis created
    serviceentry.networking.istio.io/allow-egress-google-metadata created
    

Como implantar a Entrada do GKE

Nas etapas a seguir, você implantará o balanceador de carga HTTP(S) externo por meio do controlador Entrada do GKE. O recurso Entrada automatiza o provisionamento do balanceador de carga, os certificados TLS e a verificação de integridade do back-end. Além disso, use o Cloud Endpoints para provisionar automaticamente um nome DNS público ao aplicativo.

Aplicar configurações do serviço de back-end

  1. No Cloud Shell, consulte o Serviço istio-ingressgateway para ver como ele é implantado antes de aplicar as personalizações:

    kubectl get svc -n istio-system istio-ingressgateway
    

    O resultado exibe as anotações de Serviço da instalação padrão.

    NAME                   TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)                                        AGE
    istio-ingressgateway   ClusterIP   10.44.15.44   <none>        15021/TCP,80/TCP,443/TCP,31400/TCP,15443/TCP   5m57s
    

    Anteriormente neste tutorial, você usou os perfis de instalação do Anthos Service Mesh ou do Istio para implantar o istio-ingressgateway como um Serviço ClusterIP. Esse perfil personalizado não implanta um balanceador de carga TCP/UDP como parte da implantação da malha de serviço porque este tutorial expõe aplicativos por meio de recursos de Entrada baseados em HTTP. Neste ponto do tutorial, o aplicativo não pode ser acessado de fora do cluster por não estar exposto.

  2. Salve o seguinte manifesto BackendConfig como ingress-backendconfig.yaml:

    cat <<EOF > ingress-backendconfig.yaml
    apiVersion: cloud.google.com/v1
    kind: BackendConfig
    metadata:
      name: ingress-backendconfig
      namespace: istio-system
    spec:
      healthCheck:
        requestPath: /healthz/ready
        port: 15021
        type: HTTP
      securityPolicy:
        name: edge-fw-policy
    EOF
    

    BackendConfig é uma definição de recurso personalizada (CRD, na sigla em inglês) que define os parâmetros de back-end do balanceamento de carga do Entrada. Para uma lista completa dos parâmetros de back-end e front-end que podem ser configurados por meio do Entrada do GKE, consulte Recursos do Entrada.

    Neste tutorial, o manifesto BackendConfig especifica verificações de integridade personalizadas para os proxies de entrada da malha. O Anthos Service Mesh e o Istio expõem as verificações de integridade do proxy sidecar na porta 15021 no caminho /healthz/ready. Os parâmetros de verificação de integridade personalizados são necessários porque a porta de exibição (80) dos proxies de entrada da malha é diferente da porta de verificação de integridade (15021). O Entrada do GKE usa os parâmetros de verificação de integridade a seguir em BackendConfig para configurar as verificações de integridade do balanceador de carga do Google Cloud. A política de segurança que ajuda a proteger o tráfego de balanceamento de carga contra diferentes tipos de ataques de rede também é referenciada.

    • healthCheck.port define a porta que recebe uma verificação de integridade pelo balanceador de carga do Google Cloud no endereço IP de cada pod.
    • healthCheck.requestPath define o caminho HTTP que recebe uma verificação de integridade na porta especificada.
    • type define o protocolo da verificação de integridade (neste caso, HTTP).
    • securityPolicy.name refere-se ao nome de uma política de segurança do Cloud Armor.
  3. Implante ingress-backendconfig.yaml no cluster para criar o recurso BackendConfig:

    kubectl apply -f ingress-backendconfig.yaml
    

    A saída será assim:

    backendconfig.cloud.google.com/ingress-backendconfig created
    

    Os parâmetros BackendConfig e as anotações do Serviço istio-ingressgateway não são aplicados a um balanceador de carga do Google Cloud até que o recurso Entrada seja implantado. A implantação do Entrada vincula todos esses recursos.

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

O edge-fw-policy foi referenciado por ingress-backendconfig na seção anterior. Quando o recurso Entrada é implantado, ele vincula essa política de segurança ao balanceador de carga para ajudar a proteger os back-ends do Serviço istio-ingressgateway.

Configurar o endereçamento IP e o DNS

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

    gcloud compute addresses create ingress-ip --global
    

    Esse IP estático é usado pelo recurso Entrada e permite que o IP permaneça igual, mesmo se o balanceador de carga externo for alterado.

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

    export GCLB_IP=$(gcloud compute addresses describe ingress-ip --global --format=json | jq -r '.address')
    echo ${GCLB_IP}
    

    Para criar um mapeamento estável e legível para o IP de Entrada, é preciso ter um registro DNS público. Use o provedor de DNS e a automação que quiser. Neste tutorial, o Endpoints é usado em vez da criação de uma zona de DNS gerenciada. O Endpoints fornece gratuitamente um registro DNS gerenciado pelo Google para um IP público.

  3. Salve a seguinte especificação YAML em um arquivo chamado dns-spec.yaml:

    cat <<EOF > 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 número exclusivo do projeto.

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

    gcloud endpoints services deploy dns-spec.yaml
    

    A resposta será semelhante a:

    Operation finished successfully. The following command can describe the Operation details:
     gcloud endpoints operations describe operations/rollouts.frontend.endpoints.edge2mesh.cloud.goog:442b2b38-4aee-4c60-b9fc-28731657ee08
    
    Service Configuration [2020-04-28r0] uploaded for service [frontend.endpoints.edge2mesh.cloud.goog]
    

    Agora que o IP e o DNS estão configurados, é possível gerar um certificado público para proteger o front-end do Entrada. O Entrada do GKE é compatível com certificados gerenciados pelo Google como recursos do Kubernetes, o que permite que você os provisione por meios declarativos.

Provisionar um certificado TLS

  1. No Cloud Shell, salve o seguinte manifesto YAML como managed-cert.yaml:

    cat <<EOF > managed-cert.yaml
    apiVersion: networking.gke.io/v1beta2
    kind: ManagedCertificate
    metadata:
      name: gke-ingress-cert
      namespace: istio-system
    spec:
      domains:
        - "frontend.endpoints.${PROJECT}.cloud.goog"
    EOF
    

    Esse arquivo YAML especifica que o nome DNS criado por meio do Endpoints é usado para provisionar um certificado público. Como o Google gerencia totalmente o ciclo de vida desses certificados públicos, eles são gerados e alternados regularmente, sem intervenção direta do usuário.

  2. Implante o arquivo managed-cert.yaml no cluster do GKE:

    kubectl apply -f managed-cert.yaml
    

    A saída será assim:

    managedcertificate.networking.gke.io/gke-ingress-cert created
    
  3. Inspecione o recurso ManagedCertificate para verificar o progresso da geração do certificado:

    kubectl describe managedcertificate gke-ingress-cert -n istio-system
    

    A saída será assim:

    Name:         gke-ingress-cert
    Namespace:    istio-system
    Labels:       <none>
    Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                    {"apiVersion":"networking.gke.io/v1beta2","kind":"ManagedCertificate","metadata":{"annotations":{},"name":"gke-ingress-cert","namespace":"...
    API Version:  networking.gke.io/v1beta2
    Kind:         ManagedCertificate
    Metadata:
      Creation Timestamp:  2020-08-05T20:44:49Z
      Generation:          2
      Resource Version:    1389781
      Self Link:           /apis/networking.gke.io/v1beta2/namespaces/istio-system/managedcertificates/gke-ingress-cert
      UID:                 d74ec346-ced9-47a8-988a-6e6e9ddc4019
    Spec:
      Domains:
        frontend.endpoints.edge2mesh.cloud.goog
    Status:
      Certificate Name:    mcrt-306c779e-8439-408a-9634-163664ca6ced
      Certificate Status:  Provisioning
      Domain Status:
        Domain:  frontend.endpoints.edge2mesh.cloud.goog
        Status:  Provisioning
    Events:
      Type    Reason  Age   From                            Message
      ----    ------  ----  ----                            -------
      Normal  Create  44s   managed-certificate-controller  Create SslCertificate mcrt-306c779e-8439-408a-9634-163664ca6ced
    

    Quando o certificado estiver pronto, o Certificate Status será Active.

Implantar o recurso Entrada

  1. No Cloud Shell, salve o seguinte manifesto do Entrada como ingress.yaml:

    cat <<EOF > ingress.yaml
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: gke-ingress
      namespace: istio-system
      annotations:
        kubernetes.io/ingress.allow-http: "false"
        kubernetes.io/ingress.global-static-ip-name: "ingress-ip"
        networking.gke.io/managed-certificates: "gke-ingress-cert"
    spec:
      rules:
      - host: frontend.endpoints.${PROJECT}.cloud.goog
        http:
          paths:
          - backend:
              serviceName: istio-ingressgateway
              servicePort: 80
    EOF
    

    Esse manifesto define um recurso Entrada que une todos os recursos anteriores. O manifesto especifica os seguintes campos:

    • kubernetes.io/ingress.allow-http: "false" desativa o tráfego HTTP na porta 80 do balanceador de carga do Google Cloud. Isso impede efetivamente que os clientes se conectem com o tráfego não criptografado porque a porta 443 detecta somente HTTPS, e a porta 80 está desativada.
    • kubernetes.io/ingress.global-static-ip-name: "${GCLB_IP}" vincula o endereço IP criado anteriormente ao balanceador de carga. Esse link permite que o endereço IP seja criado separadamente do balanceador de carga. Assim, o endereço IP poderá ser reutilizado separadamente do ciclo de vida do balanceador de carga.
    • networking.gke.io/managed-certificates: "gke-ingress-cert" vincula esse balanceador de carga ao recurso de certificado SSL gerenciado pelo Google criado anteriormente.
    • host: frontend.endpoints.${project}.cloud.google.com especifica o cabeçalho do host HTTP que está detectando o IP do balanceador de carga. Ele usa o nome DNS que você utiliza para anunciar o aplicativo.
  2. Implante ingress.yaml no cluster:

    kubectl apply -f ingress.yaml
    
  3. Inspecione o recurso Entrada para verificar o progresso da implantação do balanceador de carga:

    kubectl describe ingress gke-ingress -n istio-system
    

    A saída será assim:

    ...
    Annotations:
      ingress.kubernetes.io/https-forwarding-rule:       k8s2-fs-fq3ng2uk-istio-system-gke-ingress-qm3qqdor
      ingress.kubernetes.io/ssl-cert:                    mcrt-306c779e-8439-408a-9634-163664ca6ced
      networking.gke.io/managed-certificates:            gke-ingress-cert
      kubernetes.io/ingress.global-static-ip-name:  ingress-ip
      ingress.gcp.kubernetes.io/pre-shared-cert:    mcrt-306c779e-8439-408a-9634-163664ca6ced
      ingress.kubernetes.io/backends:               {"k8s-be-31610--07bdde06b914144a":"HEALTHY","k8s1-07bdde06-istio-system-istio-ingressgateway-443-228c1881":"HEALTHY"}
      ingress.kubernetes.io/forwarding-rule:        k8s2-fr-fq3ng2uk-istio-system-gke-ingress-qm3qqdor
      ingress.kubernetes.io/https-target-proxy:     k8s2-ts-fq3ng2uk-istio-system-gke-ingress-qm3qqdor
      ingress.kubernetes.io/target-proxy:           k8s2-tp-fq3ng2uk-istio-system-gke-ingress-qm3qqdor
      ingress.kubernetes.io/url-map:                k8s2-um-fq3ng2uk-istio-system-gke-ingress-qm3qqdor
    ...
    

    O recurso Entrada está pronto quando as anotações ingress.kubernetes.io/backends indicam que os back-ends são HEALTHY. As anotações também mostram os nomes de diferentes recursos do Google Cloud provisionados, incluindo serviços de back-end, certificados SSL e proxies de destino HTTPS.

    Depois que o certificado for provisionado e o Entrada estiver pronto, o aplicativo estará acessível.

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

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

Como fazer a limpeza

Após concluir este tutorial, é 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 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 Cloud usado neste tutorial, exclua os recursos individuais:

  1. Exclua o recurso Entrada:

    kubectl delete -f gke-ingress.yaml
    
  2. Exclua o certificado gerenciado:

    kubectl delete -f managed-cert.yaml
    
  3. Exclua a entrada DNS do Endpoints:

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

    A saída 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.
    
  4. Quando for solicitado continuar, digite Y.

    A saída 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
    
  5. Exclua o endereço IP estático:

    gcloud compute addresses delete ingress-ip --global
    

    A saída será assim:

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

    A saída será assim:

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

    gcloud container clusters delete $CLUSTER_NAME --zone $CLUSTER_LOCATION
    

A seguir