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.

    Se você ainda não tiver uma, inscreva-se.

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

    Acessar a página do 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 --username "admin" \
        --machine-type "n1-standard-2" --image-type "COS" --disk-size "100" \
        --scopes "https://www.googleapis.com/auth/compute","https://www.googleapis.com/auth/devstorage.read_only",\
    https://www.googleapis.com/auth/logging.write,"https://www.googleapis.com/auth/monitoring",\
    https://www.googleapis.com/auth/servicecontrol,"https://www.googleapis.com/auth/service.management.readonly",\
    https://www.googleapis.com/auth/trace.append \
        --num-nodes "4" --network "default" --enable-cloud-logging --enable-cloud-monitoring --enable-ip-alias --async
    
    gcloud container clusters create remote --zone us-central1-f --username "admin" \
        --machine-type "n1-standard-2" --image-type "COS" --disk-size "100" \
        --scopes "https://www.googleapis.com/auth/compute","https://www.googleapis.com/auth/devstorage.read_only",\
    https://www.googleapis.com/auth/logging.write,"https://www.googleapis.com/auth/monitoring",\
    https://www.googleapis.com/auth/servicecontrol,"https://www.googleapis.com/auth/service.management.readonly",\
    https://www.googleapis.com/auth/trace.append \
        --num-nodes "4" --network "default" --enable-cloud-logging --enable-cloud-monitoring --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.13.11-gke.14  35.194.7.52    n1-standard-2  1.13.11-gke.14  4          RUNNING
    control  us-west2-a     1.13.11-gke.14  34.94.177.118  n1-standard-2  1.13.11-gke.14  4          RUNNING
    
  3. Defina a variável KUBECONFIG para usar um novo arquivo kubeconfig para este tutorial:

    touch istiokubecfg
    export KUBECONFIG=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
    
  6. Atribua a si mesmo (seu usuário do Google) o papel cluster-admin dos dois clusters:

    kubectl create clusterrolebinding user-admin-binding \
        --clusterrole=cluster-admin --user=$(gcloud config get-value account) \
        --context control
    kubectl create clusterrolebinding user-admin-binding \
        --clusterrole=cluster-admin --user=$(gcloud config get-value account) \
        --context 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 resposta 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 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')
    
  3. Crie uma lista variável para ambos os intervalos de CIDR do pod:

    ALL_CLUSTER_CIDRS=$CONTROL_POD_CIDR,$REMOTE_POD_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-pods \
        --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 Helm 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:

    export ISTIO_VERSION=1.4.1
    wget https://github.com/istio/istio/releases/download/${ISTIO_VERSION}/istio-${ISTIO_VERSION}-linux.tar.gz
    tar -xzf istio-${ISTIO_VERSION}-linux.tar.gz
    rm -r istio-${ISTIO_VERSION}-linux.tar.gz
    

    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.

  2. Instale o plano de controle do Istio no cluster control:

    ./istio-${ISTIO_VERSION}/bin/istioctl --context control manifest apply \
        --set values.prometheus.enabled=true \
        --set values.grafana.enabled=true \
        --set values.kiali.enabled=true \
        --set values.kiali.createDemoSecret=true
    

    O Istio leva de dois a três minutos para ser instalado.

  3. 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
    grafana-f5585fb49-qwxpn                   1/1     Running   0          2m20s
    istio-citadel-6cb8844d5-wm6qz             1/1     Running   0          2m22s
    istio-galley-7bcbddd9cf-g9z8r             2/2     Running   0          2m22s
    istio-ingressgateway-59d89ccfb4-qmwkc     1/1     Running   0          2m22s
    istio-pilot-64446b85b5-dbkcm              2/2     Running   0          2m24s
    istio-policy-b8d8c95c9-mfvh9              2/2     Running   2          2m24s
    istio-sidecar-injector-7cf67d6b97-946lz   1/1     Running   0          2m20s
    istio-telemetry-6d4d8d75fb-4jlp7          2/2     Running   2          2m21s
    kiali-767f877b4-p566t                     1/1     Running   0          2m21s
    prometheus-5d56488ff6-txlzr               1/1     Running   0          2m21s
    
  4. Antes de instalar o Istio no cluster remote, é necessário ter os endereços IP do pod Pilot e do pod Política e Telemetria do cluster control. Esses endereços IP são configurados no cluster remote, que se conecta a um plano de controle do Istio compartilhado.

    Consiga os endereços IP dos pods Pilot, Política e Telemetria no cluster control:

    export PILOT_POD_IP=$(kubectl --context control -n istio-system get pod -l istio=pilot -o jsonpath='{.items[0].status.podIP}')
    export POLICY_POD_IP=$(kubectl --context control -n istio-system get pod -l istio=mixer -o jsonpath='{.items[0].status.podIP}')
    export TELEMETRY_POD_IP=$(kubectl --context control -n istio-system get pod -l istio-mixer-type=telemetry -o jsonpath='{.items[0].status.podIP}')
    
  5. Instale o Istio no cluster remote:

    ./istio-${ISTIO_VERSION}/bin/istioctl --context remote manifest apply \
        --set profile=remote \
        --set values.global.controlPlaneSecurityEnabled=false \
        --set values.global.remotePilotCreateSvcEndpoint=true \
        --set values.global.remotePilotAddress=${PILOT_POD_IP} \
        --set values.global.remotePolicyAddress=${POLICY_POD_IP} \
        --set values.global.remoteTelemetryAddress=${TELEMETRY_POD_IP} \
        --set gateways.enabled=false \
        --set autoInjection.enabled=true
    
  6. Inspecione a implantação do Istio no cluster remote:

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

    A saída será assim:

    NAME                                      READY   STATUS    RESTARTS   AGE
    istio-citadel-6cb8844d5-tzpxv             1/1     Running   0          29s
    istio-sidecar-injector-7cf67d6b97-nt9nh   1/1     Running   0          28s
    

    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.

  7. Exporte os valores necessários para gerar um arquivo kubeconfig:

    kubectx remote
    CLUSTER_NAME=$(kubectl config view --minify=true -o "jsonpath={.clusters[].name}")
    CLUSTER_NAME="${CLUSTER_NAME##*_}"
    export KUBECFG_FILE=${WORKDIR}/${CLUSTER_NAME}
    SERVER=$(kubectl config view --minify=true -o "jsonpath={.clusters[].cluster.server}")
    NAMESPACE=istio-system
    SERVICE_ACCOUNT=istio-reader-service-account
    SECRET_NAME=$(kubectl get sa ${SERVICE_ACCOUNT} -n ${NAMESPACE} -o jsonpath='{.secrets[].name}')
    CA_DATA=$(kubectl get secret ${SECRET_NAME} -n ${NAMESPACE} -o "jsonpath={.data['ca\.crt']}")
    TOKEN=$(kubectl get secret ${SECRET_NAME} -n ${NAMESPACE} -o "jsonpath={.data['token']}" | base64 --decode)
    
  8. Gere o arquivo kubeconfig:

    cat <<EOF > ${KUBECFG_FILE}
    apiVersion: v1
    clusters:
       - cluster:
           certificate-authority-data: ${CA_DATA}
           server: ${SERVER}
         name: ${CLUSTER_NAME}
    contexts:
       - context:
           cluster: ${CLUSTER_NAME}
           user: ${CLUSTER_NAME}
         name: ${CLUSTER_NAME}
    current-context: ${CLUSTER_NAME}
    kind: Config
    preferences: {}
    users:
       - name: ${CLUSTER_NAME}
         user:
           token: ${TOKEN}
    EOF
    
  9. Crie um secret no cluster control com o arquivo kubeconfig remoto. Você também precisa rotular o secret com o valor istio/multiCluster=true.

    kubectx control
    kubectl create secret generic ${CLUSTER_NAME} --from-file ${KUBECFG_FILE} -n ${NAMESPACE}
    kubectl label secret ${CLUSTER_NAME} istio/multiCluster=true -n ${NAMESPACE}
    

Como implantar o aplicativo Online Boutique

Nesta seção, veja como instalar o aplicativo Online Boutique (anteriormente conhecido como Hipster Shop) nos dois clusters.

  1. No Cloud Shell, crie o namespace hipster em ambos os clusters:

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

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

    Essa etapa garante que todos os pods criados no namespace hipster 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 hipster 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 hipster 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 hipster 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 hipster 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 Hipster

  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 instalada como parte da instalação do Istio.

  1. No Cloud Shell, exponha o Kiali no cluster control:

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

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

  4. No menu, selecione Graph.

  5. Na lista suspensa Select a namespace, selecione hipster.

  6. No menu em Graph, selecione Service graph.

  7. É possível também selecionar Traffic Animation no menu Display para ver loadgenerator gerando tráfego para o aplicativo.

    Animação de tráfego que mostra o "loadgenerator" gerando tráfego para o aplicativo.

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 ser cobrado 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 istiokubecfg
    

A seguir