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:

Malha de serviços com vários clusters com um plano de controle compartilhado
Malha de serviço de vários clusters com planos de controle replicados

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:

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

Faça login na sua conta do Google.
Se você ainda não tiver uma, inscreva-se.

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

Observação: se você não pretende manter os recursos criados neste procedimento, crie um projeto novo em vez de selecionar um que já existe. Depois de concluir essas etapas, é possível excluir o projeto. Para fazer isso, basta remover todos os recursos associados a ele.

Acessar a página do seletor de projetos

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

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.

No Console do Google Cloud, abra o Cloud Shell:

ABRIR o Cloud Shell
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
```
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.
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.

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

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

Defina a variável KUBECONFIG para usar um novo arquivo kubeconfig para este tutorial:
```
touch istiokubecfg
export KUBECONFIG=istiokubecfg
```

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.

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

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.

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

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')

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.

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.

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.

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.

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.

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

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}')

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

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.

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)

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

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.

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

for cluster in $(kubectx);
do
    kubectx $cluster;
    kubectl create namespace hipster;
done

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.

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

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

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

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

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

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.

No Cloud Shell, exponha o Kiali no cluster control:

kubectl port-forward svc/kiali 8080:20001 -n istio-system --context control >> /dev/null &

Abra a interface da Web do Kiali no cluster control. Selecione Web Preview e depois Preview on port 8080.
No prompt de login do Kiali, faça login com o nome de usuário admin e a senha admin.
No menu, selecione Graph.
Na lista suspensa Select a namespace, selecione hipster.
No menu em Graph, selecione Service graph.
É possível também selecionar Traffic Animation no menu Display para ver 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

No Console do Cloud, acesse a página Gerenciar recursos:
Acessar "Gerenciar recursos"
Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
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

Saiba mais sobre o Istio no Google Cloud.
Saiba mais sobre como criar uma malha de serviço de vários clusters no GKE usando a arquitetura do plano de controle replicado.
Leia o blog A era da malha de serviço: o papel do Istio no futuro da nuvem híbrida (em inglês).
Teste outros recursos do Google Cloud. Veja nossos tutoriais.