Como criar uma malha de serviço de vários clusters no GKE com arquitetura de VPC única e plano de controle compartilhado

Veja neste tutorial como implantar aplicativos em vários clusters do Kubernetes com uma malha de serviço de vários clusters do Istio. Malha de serviço de vários clusters do Istio Uma malha de serviço de vários clusters do Istio permite que serviços executados em vários clusters do Kubernetes se comuniquem com segurança uns com os outros. Os clusters do Kubernetes podem estar em execução em qualquer lugar, mesmo em diferentes plataformas de nuvem. Por exemplo: clusters do Google Kubernetes Engine (GKE) em execução no Google Cloud ou um cluster do Kubernetes em execução em um data center no local.

O Istio é uma implementação de código aberto de uma malha de serviço que permite descobrir e criar rotas dinâmicas e conexão segura com os serviços executados em clusters do Kubernetes. O Istio também fornece um framework orientado por políticas para roteamento, balanceamento de carga, limitação, telemetria, quebras de circuito, autenticação e autorização de chamadas de serviço na malha com pouca ou nenhuma alteração no código do aplicativo. Quando o Istio é instalado em um cluster do Kubernetes, ele usa o Registro de serviço do Kubernetes para descobrir e criar automaticamente uma malha de serviços interconectados (ou microsserviços) em execução no cluster.

Os componentes do Istio podem ser descritos em termos de um plano de dados e um plano de controle. O plano de dados é responsável por transportar o tráfego de rede na malha, e o plano de controle é responsável por configurar e gerenciar a malha:

  • Plano de dados: o Istio participa da comunicação do serviço injetando um contêiner de arquivo secundário para executar um proxy em cada um dos pods dos Serviços na malha. O arquivo secundário executa um proxy inteligente chamado Envoy para fornecer roteamento, segurança e observabilidade para os Serviços.
  • Plano de controle: um componente chamado Pilot é responsável por fornecer a configuração para os arquivos secundários do Envoy. Os certificados são atribuídos a cada Serviço por um componente chamado Citadel.

Pode ser preciso estabelecer a comunicação dos microsserviços executados em um cluster do Kubernetes com aqueles em outros clusters do Kubernetes. Por exemplo: pode ser preciso estabelecer a comunicação de microsserviços entre regiões, e os proprietários de microsserviços ou ambientes podem manter seus próprios clusters do Kubernetes. Com o Istio, é possível criar uma malha de serviço além de um único cluster do Kubernetes para incluir microsserviços em execução em clusters remotos e até microsserviços externos em execução em VMs, fora do Kubernetes.

O Istio tem duas configurações principais para implantações de vários clusters:

A configuração compartilhada do plano de controle do Istio usa um plano de controle do Istio em execução em um dos clusters. O Pilot do plano de controle gerencia a configuração do Serviço nos clusters locais e remotos e configura os arquivos secundários do Envoy para todos os clusters. Essa configuração resulta em uma única malha de serviço do Istio que engloba os Serviços em execução em vários clusters do Kubernetes. Em uma configuração de plano de controle compartilhado, o Pilot em execução no cluster de plano de controle do Istio precisa ter acesso de endereço IP a todos os pods em execução em cada cluster.

É possível conseguir a conectividade de endereço IP de pod para pod entre clusters de duas maneiras:

  1. Você cria todos os clusters em uma rede plana, por exemplo, uma única VPC, com regras de firewall que permitem a conectividade de endereços IP de pod para pod entre clusters. Os clusters também podem existir em redes conectadas à VPN. Em ambos os casos, o pod Pilot no cluster de controle pode acessar todos os pods em clusters remotos diretamente pelos endereços IP do pod.
  2. Seus clusters não estão em uma única rede e dependem de um mecanismo diferente para que o pod Pilot no cluster de controle alcance pods em clusters remotos. Nesse cenário, o pod Pilot não pode acessar outros pods diretamente com IPs de pod. É por isso que os gateways de entrada do Istio são usados para conseguir conectividade de rede entre clusters em redes diferentes.

Neste tutorial, veja como implantar o Istio em dois clusters do GKE usando uma arquitetura de plano de controle compartilhado em uma única rede VPC. O pod Pilot no cluster do plano de controle do Istio terá conectividade de endereço IP direto com pods em execução no cluster remoto. Para este tutorial, você usará um aplicativo de microsserviços de demonstração de dez níveis chamado Online Boutique dividido em dois clusters do GKE. Os microsserviços são escritos em linguagens de programação diferentes. Para ver a linguagem de cada microsserviço, consulte a página README.

Crie a arquitetura a seguir dentro de um projeto do Google Cloud.

Arquitetura que implanta 10 microsserviços em dois clusters.

Nesta arquitetura, você tem um cluster control e um cluster remote. O plano de controle do Istio é implantado no cluster control. Os clusters se comunicam com vários microsserviços localmente (no mesmo cluster) e não localmente (no outro cluster).

Objetivos

  • Crie dois clusters do GKE, control e remote, em uma única VPC.
  • Instale o Istio no modo de vários clusters nos dois clusters do GKE e implante o plano de controle do Istio no cluster control.
  • Instale o aplicativo Online Boutique dividido nos dois clusters.
  • Observe a malha de serviço expandido nos dois clusters.

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. Faça login na sua conta do Google Cloud. Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho de nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.
  2. 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

  3. Verifique se o faturamento está ativado para seu projeto na nuvem. Saiba como confirmar se o faturamento está ativado para o projeto.

  4. Ative as APIs GKE and Cloud Source Repositories.

    Ative as APIs

Como configurar o ambiente

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

  1. No Console do Google Cloud, abra o Cloud Shell:

    ABRIR o Cloud Shell

  2. Faça o download dos arquivos necessários para este tutorial clonando o seguinte repositório do GitHub:

    cd $HOME
    git clone https://github.com/GoogleCloudPlatform/istio-multicluster-gke.git
    
  3. Transforme a pasta do repositório na pasta $WORKDIR e execute nela todas as tarefas relacionadas a este tutorial:

    cd $HOME/istio-multicluster-gke
    WORKDIR=$(pwd)
    

    Será possível excluir a pasta quando o tutorial for concluído.

  4. Instale kubectx/kubens (em inglês):

    git clone https://github.com/ahmetb/kubectx $WORKDIR/kubectx
    export PATH=$PATH:$WORKDIR/kubectx
    

    Essas ferramentas facilitam o trabalho com vários clusters do Kubernetes porque alteram os contextos ou namespaces.

Como criar clusters do GKE

Nesta seção, você verá como criar dois clusters do GKE na VPC padrão com endereços IP de alias ativados. Com os intervalos de IP de alias, os clusters do GKE podem alocar endereços IP de um bloco CIDR conhecido pelo Google Cloud. Essa configuração faz com que os endereços IP do pod sejam nativamente roteáveis na VPC, o que permite que os pods em diferentes clusters tenham conectividade de endereço IP direta.

  1. No Cloud Shell, crie dois clusters do GKE: um cluster chamado control em que o plano de controle do Istio está instalado e um segundo cluster chamado remote para ser adicionado à malha de serviço de vários clusters do Istio. Você cria os dois clusters na VPC padrão, mas em regiões diferentes.

    gcloud container clusters create control --zone us-west2-a \
        --machine-type "e2-standard-4" --disk-size "100" \
        --num-nodes "4" --network "default" --enable-ip-alias --async
    
    gcloud container clusters create remote --zone us-central1-f \
        --machine-type "e2-standard-4" --disk-size "100" \
        --num-nodes "4" --network "default" --enable-ip-alias
    
  2. Aguarde alguns minutos até que os dois clusters sejam criados. Verifique se o status de cada cluster é RUNNING:

    gcloud container clusters list
    

    A resposta será semelhante a:

    NAME     LOCATION       MASTER_VERSION   MASTER_IP      MACHINE_TYPE   NODE_VERSION     NUM_NODES  STATUS
    remote   us-central1-f  1.19.9-gke.1400  34.70.12.109   e2-standard-4  1.19.9-gke.1400  4          RUNNING
    control  us-west2-a     1.19.9-gke.1400  34.94.220.232  e2-standard-4  1.19.9-gke.1400  4          RUNNING
    
  3. Defina a variável KUBECONFIG para usar um novo arquivo kubeconfig para este tutorial:

    touch ${WORKDIR}/istiokubecfg
    export KUBECONFIG=${WORKDIR}/istiokubecfg
    
  4. Conecte-se aos dois clusters para gerar entradas no arquivo kubeconfig:

    export PROJECT_ID=$(gcloud info --format='value(config.project)')
    gcloud container clusters get-credentials control --zone us-west2-a --project ${PROJECT_ID}
    gcloud container clusters get-credentials remote --zone us-central1-f --project ${PROJECT_ID}
    

    Um arquivo kubeconfig é usado para autenticação em clusters. Depois de criar o arquivo kubeconfig, é possível alternar rapidamente o contexto entre os clusters.

  5. Use kubectx para renomear os contextos como preferir:

    kubectx control=gke_${PROJECT_ID}_us-west2-a_control
    kubectx remote=gke_${PROJECT_ID}_us-central1-f_remote
    

Configurar rede

Nesta seção, veja como configurar rotas de VPC para permitir que os pods em ambos os clusters tenham conectividade de endereço IP direta. Quando você ativa intervalos de IP de alias para clusters do GKE, duas sub-redes secundárias são criadas para cada cluster. A sub-rede primária é usada para endereços IP de nós, e as duas redes secundárias são usadas para endereços IP de Serviço e CIDR do pod.

  1. No Cloud Shell, inspecione os endereços IP secundários em ambos os clusters:

    gcloud compute networks subnets describe default --region=us-west2 --format=json | jq '.secondaryIpRanges[]'
    gcloud compute networks subnets describe default --region=us-central1 --format=json | jq '.secondaryIpRanges[]'
    

    Para o cluster control, a saída será assim:

    {
      "ipCidrRange": "10.56.0.0/14",
      "rangeName": "gke-control-pods-47496b0c"
    }
    {
      "ipCidrRange": "10.0.0.0/20",
      "rangeName": "gke-control-services-47496b0c"
    }
    

    Para o cluster remote, a saída será assim:

    {
      "ipCidrRange": "10.0.16.0/20",
      "rangeName": "gke-remote-services-66101313"
    }
    {
      "ipCidrRange": "10.60.0.0/14",
      "rangeName": "gke-remote-pods-66101313"
    }
    
  2. Armazene o intervalo de IP de pods dos clusters e o intervalo de endereços IP primário em variáveis para uso posterior:

    CONTROL_POD_CIDR=$(gcloud container clusters describe control --zone us-west2-a --format=json | jq -r '.clusterIpv4Cidr')
    REMOTE_POD_CIDR=$(gcloud container clusters describe remote --zone us-central1-f --format=json | jq -r '.clusterIpv4Cidr')
    CONTROL_PRIMARY_CIDR=$(gcloud compute networks subnets describe default --region=us-west2 --format=json | jq -r '.ipCidrRange')
    REMOTE_PRIMARY_CIDR=$(gcloud compute networks subnets describe default --region=us-central1 --format=json | jq -r '.ipCidrRange')
    
  3. Crie uma variável de lista para todos os intervalos de CIDR de IP:

    ALL_CLUSTER_CIDRS=$CONTROL_POD_CIDR,$REMOTE_POD_CIDR,$CONTROL_PRIMARY_CIDR,$REMOTE_PRIMARY_CIDR
    

    Todos os nós são necessários para que seja possível a comunicação entre eles e entre os intervalos de CIDR do pod.

  4. Armazene as tags de rede dos nós do cluster em uma variável:

    ALL_CLUSTER_NETTAGS=$(gcloud compute instances list --format=json | jq -r '.[].tags.items[0]' | uniq | awk -vORS=, '{ print $1 }' | sed 's/,$/\n/')
    

    Elas serão usadas posteriormente em regras de firewall.

  5. Crie uma regra de firewall que permita o tráfego entre os intervalos e nós de CIDR do pod dos clusters:

    gcloud compute firewall-rules create istio-multicluster-rule \
        --allow=tcp,udp,icmp,esp,ah,sctp \
        --direction=INGRESS \
        --priority=900 \
        --source-ranges="${ALL_CLUSTER_CIDRS}" \
        --target-tags="${ALL_CLUSTER_NETTAGS}" --quiet
    

Como instalar o Istio nos dois clusters do GKE

Nesta seção, veja como usar o Operador do Istio para instalar e configurar o Istio em uma configuração de vários clusters nos dois clusters do GKE.

  1. No Cloud Shell, faça o download do Istio:

    cd ${WORKDIR}
    export ISTIO_VER=1.9.5
    curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VER} TARGET_ARCH=x86_64 sh -
    

    Na produção, recomendamos que você codifique a versão do aplicativo para garantir um comportamento consistente. Ou seja, use o número de uma versão conhecida e testada.

Uma implantação de malha de serviço de vários clusters requer que você estabeleça confiança entre todos os clusters da malha. Use uma autoridade de certificação (CA, na sigla em inglês) raiz comum para gerar certificados intermediários para vários clusters. Por padrão, todos os clusters criam certificados autoassinados. Uma CA raiz é usada por todas as cargas de trabalho em uma malha como a raiz da confiança. Cada Istio CA usa uma chave de assinatura CA e um certificado intermediários, assinados pela CA raiz. Quando houver várias CAs do Istio em uma malha, uma hierarquia de confiança entre as CAs será estabelecida. O repositório do Istio é fornecido com exemplos de certificados que você pode usar apenas para fins educacionais. Dentro de cada cluster, você cria o namespace istio-system e um secret chamado cacrts com os certificados de cluster apropriados que você criou anteriormente.

  1. Crie um namespace istio-system e um secret cacerts nos dois clusters do GKE:

    kubectl --context control create namespace istio-system
    kubectl --context control create secret generic cacerts -n istio-system \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-cert.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-key.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/root-cert.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/cert-chain.pem
    kubectl --context remote create namespace istio-system
    kubectl --context remote create secret generic cacerts -n istio-system \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-cert.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-key.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/root-cert.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/cert-chain.pem
    
  2. Crie a configuração do istio para o cluster control:

    cat <<EOF > ${WORKDIR}/istio_control.yaml
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    metadata:
      name: istio-control
    spec:
      values:
        global:
          meshID: mesh1
          multiCluster:
            clusterName: control
          network: network1
      components:
        ingressGateways:
          - name: istio-eastwestgateway
            label:
              istio: eastwestgateway
              app: istio-eastwestgateway
              topology.istio.io/network: network1
            enabled: true
            k8s:
              env:
                # sni-dnat adds the clusters required for AUTO_PASSTHROUGH mode
                - name: ISTIO_META_ROUTER_MODE
                  value: "sni-dnat"
                # traffic through this gateway should be routed inside the network
                - name: ISTIO_META_REQUESTED_NETWORK_VIEW
                  value: network1
              serviceAnnotations:
                cloud.google.com/load-balancer-type: "Internal"
                networking.gke.io/internal-load-balancer-allow-global-access: "true"
              service:
                ports:
                  - name: status-port
                    port: 15021
                    targetPort: 15021
                  - name: tls
                    port: 15443
                    targetPort: 15443
                  - name: tls-istiod
                    port: 15012
                    targetPort: 15012
                  - name: tls-webhook
                    port: 15017
                    targetPort: 15017
    EOF
    
  3. Instale o plano de controle do Istio no cluster control:

    ${WORKDIR}/istio-${ISTIO_VER}/bin/istioctl install --context control -f ${WORKDIR}/istio_control.yaml
    

    Digite y para continuar a instalação. O Istio leva de dois a três minutos para ser instalado.

  4. Verifique se todas as implantações do Istio estão em execução:

    kubectl --context control get pods -n istio-system
    

    O Istio estará pronto para uso quando todos os pods estiverem em execução ou concluídos.

    A resposta será semelhante a:

    NAME                                     READY   STATUS    RESTARTS   AGE
    istio-eastwestgateway-69b49b9785-f5msp   1/1     Running   0          9m11s
    istio-ingressgateway-5c65f88f66-rdd2r    1/1     Running   0          52m
    istiod-6c56d9cbd8-k9klt                  1/1     Running   0          52m
    
  5. Aguarde até que o serviço istio-eastwestgateway seja atribuído a um endereço IP externo. Inspecione o endereço IP externo de istio-eastwestgateway:

    kubectl --context control get svc istio-eastwestgateway -n istio-system
    

    A resposta será semelhante a:

    NAME                    TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)                                                           AGE
    istio-eastwestgateway   LoadBalancer   10.60.7.19   10.168.0.6    15021:31557/TCP,15443:30306/TCP,15012:31791/TCP,15017:32341/TCP   14m
    

    Observe que o endereço IP externo é um endereço IP do balanceador de carga interno. Você precisa de um balanceador de carga interno porque os dois clusters estão na mesma VPC e podem se comunicar por meio de um balanceador de carga interno.

  6. Exponha o serviço istiod no especificador control usando o gateway istio-eastwestgateway e um VirtualService. Os proxies do Envoy do cluster remote precisam ser capazes de se comunicar com o serviço istiod no cluster control. Crie o Gateway e o VirtualService executando o seguinte comando:

    kubectl --context control apply -f ${WORKDIR}/istio-"${ISTIO_VER}"/samples/multicluster/expose-istiod.yaml
    

    A resposta será semelhante a:

    gateway.networking.istio.io/istiod-gateway created
    virtualservice.networking.istio.io/istiod-vs created
    

    Conceda ao plano de controle do Istio no cluster control acesso ao servidor da API de cluster remote. Isso permite o seguinte:

    1. Permite que o plano de controle autentique solicitações de conexão de cargas de trabalho em execução no cluster remote. Sem o acesso ao servidor da API, o plano de controle rejeitará as solicitações.
    2. Permite a descoberta de endpoints de serviço em execução no cluster remote.
  7. Execute o comando a seguir para conceder acesso ao plano de controle do Istio no cluster control ao servidor da API de cluster remote.

    ${WORKDIR}/istio-${ISTIO_VER}/bin/istioctl x create-remote-secret \
    --context=remote \
    --name=remote | \
    kubectl apply -f - --context=control
    

    A resposta será semelhante a:

    secret/istio-remote-secret-remote created
    

    Nas próximas etapas, veja como configurar o cluster control com permissões para acessar recursos no cluster remote.

    O plano de controle do Istio requer acesso a todos os clusters na malha para descobrir atributos de Serviços, endpoints e pod. Para receber esse acesso, crie um arquivo kubeconfig para o cluster remote adicionado como um secret no cluster control. O gráfico Helm istio-remote cria uma conta de serviço do Kubernetes chamada istio-multi no cluster remote com o mínimo necessário de controle de acesso baseado em papel (RBAC, na sigla em inglês). As etapas a seguir geram o arquivo kubeconfig do cluster remote usando as credenciais da conta de serviço istio-multi.

  8. Receba o endereço ILB istio-eastwestgateway:

    export DISCOVERY_ADDRESS=$(kubectl --context control -n istio-system get svc istio-eastwestgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    

    Esse endereço é usado pelos proxies sidecar do Envoy em execução no cluster remote para se conectar a istiod no cluster control.

  9. Crie a configuração do istio para o cluster remote:

    cat <<EOF > ${WORKDIR}/istio_remote.yaml
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    spec:
      profile: remote
      values:
        global:
          meshID: mesh1
          multiCluster:
            clusterName: remote
          network: network1
          remotePilotAddress: ${DISCOVERY_ADDRESS}
    EOF
    
  10. Instale o Istio no cluster remote:

    ${WORKDIR}/istio-${ISTIO_VER}/bin/istioctl install --context=remote -f ${WORKDIR}/istio_remote.yaml
    

    Digite y para continuar a instalação. O Istio leva de dois a três minutos para ser instalado.

  11. Inspecione a implantação do Istio no cluster remote:

    kubectl --context remote -n istio-system get pods
    

    A resposta será semelhante a:

    NAME                                   READY   STATUS    RESTARTS   AGE
    istio-ingressgateway-c68779485-4fpmm   1/1     Running   0          3m50s
    istiod-866555cf49-w6qsx                1/1     Running   0          3m57s
    

    Os dois clusters agora estão configurados com o cluster control, fornecendo o plano de controle do Istio ao cluster remote. Na próxima seção, você implantará um aplicativo de amostra dividido entre os dois clusters.

Como implantar o aplicativo Online Boutique

Nesta seção, você instalará o aplicativo Online Boutique nos dois clusters.

  1. No Cloud Shell, crie o namespace online-boutique em ambos os clusters:

    for cluster in $(kubectx);
    do
        kubectx $cluster;
        kubectl create namespace online-boutique;
    done
    
  2. Rotule o namespace online-boutique em ambos os clusters da injeção automática de proxy sidecar do Istio:

    for cluster in $(kubectx);
    do
        kubectx $cluster;
        kubectl label namespace online-boutique istio-injection=enabled
    done
    

    Essa etapa garante que todos os pods criados no namespace online-boutique tenham o contêiner de arquivo secundário do Envoy implantado.

  3. Instale os recursos do aplicativo Online Boutique no cluster control:

    kubectl --context control -n online-boutique apply -f $WORKDIR/istio-single-controlplane/single-network/control
    

    A saída será assim:

    deployment.apps/emailservice created
    deployment.apps/checkoutservice created
    deployment.apps/frontend created
    deployment.apps/paymentservice created
    deployment.apps/productcatalogservice created
    deployment.apps/currencyservice created
    deployment.apps/shippingservice created
    deployment.apps/adservice created
    gateway.networking.istio.io/frontend-gateway created
    virtualservice.networking.istio.io/frontend-ingress created
    serviceentry.networking.istio.io/currency-provider-external created
    virtualservice.networking.istio.io/frontend created
    serviceentry.networking.istio.io/whitelist-egress-googleapis created
    service/emailservice created
    service/checkoutservice created
    service/recommendationservice created
    service/frontend created
    service/paymentservice created
    service/productcatalogservice created
    service/cartservice created
    service/currencyservice created
    service/shippingservice created
    service/redis-cart created
    service/adservice created
    
  4. Instale os recursos do aplicativo Online Boutique no cluster remote:

    kubectl --context remote -n online-boutique apply -f $WORKDIR/istio-single-controlplane/single-network/remote
    

    A saída será assim:

    deployment.apps/loadgenerator created
    deployment.apps/cartservice created
    deployment.apps/recommendationservice created
    service/emailservice created
    service/checkoutservice created
    service/recommendationservice created
    service/frontend created
    service/paymentservice created
    service/productcatalogservice created
    service/cartservice created
    service/currencyservice created
    service/shippingservice created
    service/redis-cart created
    service/adservice created
    
  5. Verifique se todas as cargas de trabalho estão em execução no cluster control:

    kubectl --context control -n online-boutique get pods
    

    A saída será assim:

    NAME                                     READY   STATUS    RESTARTS   AGE
    adservice-5db678b487-zs6g9               2/2     Running   0          69s
    checkoutservice-b5b8858c7-djnzk          2/2     Running   0          70s
    currencyservice-954d8c5f-mv7kh           2/2     Running   0          70s
    emailservice-5c5555556b-9jk59            2/2     Running   0          71s
    frontend-6fbb48ffc6-gmnsv                2/2     Running   0          70s
    paymentservice-5684b97df7-l9ccn          2/2     Running   0          70s
    productcatalogservice-55479b967c-vqw6w   2/2     Running   0          70s
    shippingservice-59bd8c7b8c-wln4v         2/2     Running   0          69s
    
  6. Verifique se todas as cargas de trabalho estão em execução no cluster remote:

    kubectl --context remote -n online-boutique get pods
    

    A saída será assim:

    NAME                                     READY   STATUS    RESTARTS   AGE
    cartservice-5db5d5c5f9-vvwgx             2/2     Running   0          63s
    loadgenerator-8bcfd68db-gmlfk            2/2     Running   0          63s
    recommendationservice-859c7c66d5-f2x9m   2/2     Running   0          63s
    

A saída nas duas etapas anteriores mostra que os microsserviços do aplicativo Online Boutique estão divididos entre os clusters control e remote.

Como acessar o aplicativo Online Boutique

  1. No Cloud Shell, consiga o endereço IP do gateway de entrada do Istio para o cluster control:

    kubectl --context control get -n istio-system service istio-ingressgateway -o json | jq -r '.status.loadBalancer.ingress[0].ip'
    

    A saída mostra o endereço IP do gateway de entrada do Istio.

  2. Copie e cole o endereço IP do gateway de entrada do Istio em uma guia do navegador da Web e atualize a página. Você verá a página inicial do Online Boutique.

    Página inicial do Online Boutique mostrando fotos de vários produtos, como bicicletas, câmeras, máquinas de escrever etc.

    Navegue pelo aplicativo e pelos produtos, coloque-os no seu carrinho, finalize a compra e assim por diante.

    Você verá que o aplicativo Online Boutique é totalmente funcional e executado em dois clusters do Kubernetes em dois ambientes.

Como monitorar a malha de serviço

É possível usar o Kiali para visualizar a malha de serviço. O Kiali é uma ferramenta de observabilidade de malha de serviço. Para usar o Kiali, você deve instalar o Prometheus e o Kiali no cluster control.

  1. Implante os complementos do Prometheus e do Kiali no cluster control:

    kubectl --context control apply -f https://raw.githubusercontent.com/istio/istio/release-${ISTIO_VER:0:3}/samples/addons/prometheus.yaml
    kubectl --context control apply -f https://raw.githubusercontent.com/istio/istio/release-${ISTIO_VER:0:3}/samples/addons/kiali.yaml
    

    Se a instalação do Kiali falhar com erros, tente executar o mesmo comando novamente. Pode haver alguns problemas de tempo que serão resolvidos quando o comando for executado novamente.

  2. Verifique se os pods do Prometheus e do Kiali estão em execução:

    kubectl --context control get pods -n istio-system
    

    A resposta será semelhante a:

    kiali-cb9fb9554-x2r5z                    1/1     Running   0          7m46s
    prometheus-6d87d85c88-zv8cr              2/2     Running   0          3m57s
    
  3. No Cloud Shell, exponha o Kiali no cluster control:

    kubectl --context control port-forward svc/kiali 8080:20001 -n istio-system --context control >> /dev/null &
    
  4. Abra a interface da Web do Kiali no cluster control. Selecione Web Preview e depois Preview on port 8080.

  5. No prompt de login do Kiali, faça login com o nome de usuário admin e a senha admin.

  6. No menu, selecione Graph.

  7. Na lista suspensa Selecionar um namespace, selecione online-boutique.

  8. No menu em Graph, selecione Service graph.

  9. Como opção, no menu Exibir, selecione Caixas de cluster e Animação de tráfego para ver loadgenerator gerando tráfego para seu aplicativo.

    Animação de tráfego que mostra o &quot;loadgenerator&quot; que gera tráfego para seu app.

A imagem anterior mostra uma malha de serviço do Istio compartilhada para microsserviços distribuídos em dois clusters. Independentemente do cluster, à medida que novos microsserviços são adicionados, eles são descobertos e adicionados automaticamente à malha. A conectividade de rede plana permite a flexibilidade de ter vários clusters e, ao mesmo tempo, facilita o comando de todos os microsserviços por meio de um plano de controle compartilhado.

Limpeza

Depois de concluir o tutorial, limpe os recursos que você criou no Google Cloud para não receber cobranças por eles no futuro. Nas seções a seguir, descrevemos como excluir esses recursos.

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.

Redefinir o kubeconfig

  • Desmarque a variável KUBECONFIG:

    unset KUBECONFIG
    rm ${WORKDIR}/istiokubecfg
    

A seguir