Como criar uma malha de serviço de vários clusters no GKE usando arquitetura de várias redes de plano de controle primário

Last reviewed 2019-10-29 UTC

Neste tutorial, descrevemos como implantar aplicativos em vários clusters do Kubernetes usando uma malha de serviço de vários clusters do Istio (em inglês). Uma malha de serviços de vários clusters do Istio permite que os 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.

Este tutorial foi pensado para operadores que querem criar uma malha de serviço em vários clusters do GKE em várias redes. É preciso conhecer o básico do Kubernetes, como implantações, serviços, entradas, entre outros. Também é bom (mas não obrigatório) ter conhecimentos de Istio.

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 (em inglês) do Kubernetes para descobrir e criar automaticamente uma malha de serviços interconectados (ou microsserviços) em execução em vários clusters do GKE. O Istio usa proxies secundários Envoy (em inglês) executados em cada pod para gerenciar a segurança e o roteamento de tráfego entre pods e fornecer observabilidade para todos os microsserviços e cargas de trabalho em execução no cluster.

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 os 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:

Em uma configuração de plano de controle multi-primário, cada cluster tem sua própria instalação de plano de controle do Istio, e cada plano de controle gerencia sua própria malha de serviço local. Usando gateways do Istio, uma autoridade de certificação raiz (CA, na sigla em inglês) comum e descoberta automática de serviço em vários clusters do GKE, é possível configurar uma única malha de serviço lógica composta de microsserviços de participação em cada cluster. Com isso, cada cluster gerencia a própria malha de serviços de vários clusters, sendo que todo o acesso de entrada do cluster passa pelo gateway leste-oeste do Istio. Essa abordagem não tem requisitos especiais de rede, desde que os gateways leste-oeste do Istio possam ser acessados em todos os clusters.

Neste tutorial, você verá como implantar o Istio em dois clusters do GKE usando a arquitetura de planos de controle multi-primários. Partimos de um aplicativo de microsserviços de demonstração chamado Online Boutique, que é dividido em dois clusters do GKE. Para ver a linguagem de cada microsserviço, consulte a página README.

Crie esta arquitetura dentro de um projeto do Cloud:

Istio implantado em dois clusters do GKE usando a arquitetura de vários planos de controle.

Nesta arquitetura, você tem um cluster west e um cluster central em duas redes (ou VPCs) separadas, cada uma com um gateway leste-oeste do Istio. Os clusters se comunicam com vários microsserviços localmente (no mesmo cluster) e não localmente (no outro cluster).

Objetivos

  • Criar dois clusters do GKE, west e central, em duas regiões diferentes e duas VPCs diferentes.
  • Instalar o Istio no modo multi-primário nos dois clusters do GKE.
  • Instale o aplicativo Online Boutique dividido nos dois clusters.
  • Inspecione a malha de serviço nos dois clusters.

Custos

Neste documento, você usará 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 estar qualificados para uma avaliação gratuita.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.

Antes de começar

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

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

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Enable the GKE and Cloud Source Repositories APIs.

    Enable the APIs

    5.

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

    Go to project selector

  6. Make sure that billing is enabled for your Google Cloud project.

  7. Enable the GKE and Cloud Source Repositories APIs.

    Enable the APIs

    8.

Como configurar o ambiente

Todos os comandos do 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)

    Essa pasta pode ser excluída quando o tutorial terminar.

  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 de VPCs e do GKE

Nesta seção, você verá como criar duas VPCs (em inglês) e dois clusters do GKE, um em cada VPC. Ter duas VPCs diferentes ajuda a demonstrar que não são necessários outros requisitos de rede para a implementação multi-primária do Istio em várias redes. O tráfego de serviço a serviço entre clusters flui com segurança pela Internet. O roteamento do tráfego entre clusters pela Internet pública tem estas vantagens:

  • Suporte para sobreposição de endereços IP em clusters. Endereços IP de nó, pod e serviço podem se sobrepor em clusters.
  • Não ter a necessidade de outro tipo de conectividade entre clusters nem de peering, interconexão ou VPN entre redes de clusters.
  • Possibilitar que clusters existam em vários ambientes. Isso significa que os clusters podem existir no Google Cloud e em data centers locais. Nesses data centers, os operadores podem não ter controle sobre a rede ou os endereços IP, mas ainda assim precisar de conexão segura com microsserviços executados em clusters do Kubernetes.

Observe que, mesmo em clusters diferentes, é possível melhorar a proteção da comunicação de serviço a serviço entre os clusters usando conexões TLS mútuas (mTLS, na sigla em inglês). Ao verificar certificados válidos emitidos por Citadel, essas conexões evitam ataques do tipo man-in-the-middle (páginas em inglês).

A comunicação entre clusters pode ser feita com endereços IP privados. No entanto, essa abordagem requer outras considerações sobre design de rede. Por exemplo, seria possível incluir o endereçamento IP não sobreposto entre todos os clusters que participam da malha de vários clusters. Também seria possível garantir que todos os pods possam se comunicar pelo espaço de endereço privado RFC 1918 (em inglês), ou seja: regras de firewall adequadas em uma VPC global do Google Cloud ou em uma interconexão ou VPN, se a conexão for com redes que não são do Google Cloud. Neste tutorial, você fará a configuração de uma arquitetura focada na comunicação segura de serviço a serviço pela Internet pública, o que proporciona maior flexibilidade de rede.

  1. No Cloud Shell, crie as VPCs:

    gcloud compute networks create vpc-west --subnet-mode=auto
gcloud compute networks create vpc-central --subnet-mode=auto

  2. Defina a variável KUBECONFIG para usar um novo arquivo kubeconfig para este tutorial:

    export KUBECONFIG=${WORKDIR}/istio-kubeconfig

  3. Crie dois clusters do GKE, um chamado west na zona us-west2-a na rede vpc-west e um chamado central na zona us-central1-a na rede vpc-central:

    gcloud container clusters create west --zone us-west2-a \
    --machine-type "e2-standard-2" --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 "vpc-west" --async

gcloud container clusters create central --zone us-central1-a \
    --machine-type "e2-standard-2" --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 "vpc-central"

  4. Aguarde alguns minutos até que os dois clusters sejam criados. Verifique se o status de cada cluster é RUNNING:

    gcloud container clusters list

    A saída será assim:

    NAME     LOCATION       MASTER_VERSION    MASTER_IP        MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
central  us-central1-a  1.17.14-gke.1600  104.197.127.140  e2-standard-2  1.17.14-gke.1600  4          RUNNING
west     us-west2-a     1.17.14-gke.1600  34.94.217.4      e2-standard-2  1.17.14-gke.1600  4          RUNNING

  5. 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 west --zone us-west2-a --project ${PROJECT_ID}
gcloud container clusters get-credentials central --zone us-central1-a --project ${PROJECT_ID}

    Use o arquivo kubeconfig para criar a autenticação para os clusters com um usuário e um contexto para cada cluster. Depois de criar o arquivo kubeconfig, é possível alternar rapidamente o contexto entre os clusters.

  6. Use kubectx para renomear os contextos como preferir:

    kubectx west=gke_${PROJECT_ID}_us-west2-a_west
kubectx central=gke_${PROJECT_ID}_us-central1-a_central

  7. 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 west
kubectl create clusterrolebinding user-admin-binding \
    --clusterrole=cluster-admin --user=$(gcloud config get-value account) \
    --context central

    Esse papel permite executar tarefas administrativas nesses clusters.

Como configurar certificados nos dois clusters

No Istio, o Citadel (em inglês) é a autoridade de certificação (CA, na sigla em inglês) responsável por assinar e distribuir certificados para todos os proxies Envoy (proxies secundários de carga de trabalho e proxies gateway leste-oeste e de saída) na malha de serviço. Por padrão, o Citadel gera uma chave e um certificado raiz autoassinado (em inglês), usados para assinar os certificados de carga de trabalho. O Citadel também pode usar um certificado especificado pelo operador e uma chave para assinar certificados de carga de trabalho. Neste tutorial, os clusters west e central mantêm malhas de serviço distintas com serviços separados do Citadel que assinam as respectivas cargas de trabalho.

Para estabelecer a confiança entre microsserviços em clusters diferentes, os certificados de CA de assinatura do Citadel precisam ser assinados por uma autoridade de certificação raiz comum (CA raiz). Também é preciso que as cargas de trabalho tenham um arquivo de cadeia de certificados (em inglês) para verificar a cadeia de confiança de todas as CAs intermediárias entre o certificado de assinatura Citadel e a CA raiz. Essa configuração é feita com um secret (em inglês) do cluster do Kubernetes. Os arquivos de certificado são fornecidos como parte deste tutorial. Em seu ambiente de produção, é possível usar certificados gerados pela equipe de segurança ou pelos sistemas PKI. Por exemplo, é possível atuar como seu próprio CA (em inglês). O secret criado é usado pelo Citadel e tem as seguintes propriedades:

  • O secret é nomeado como cacert.
  • O secret é criado com base em quatro arquivos de certificado (fornecidos pelo código do Istio deste tutorial), que são nomeados assim:
    • root-cert.pem contém a CA raiz. Esse arquivo é o mesmo para os serviços do Citadel nos clusters west e central. Os dois certificados do Citadel são assinados por essa CA raiz.
    • ca-cert.pem e ca-key.pem são o certificado de CA de assinatura e a chave privada do serviço Citadel. Os dois certificados do Citadel precisam ser assinados pela CA raiz (root-cert.pem). ca-cert.pem é usado para assinar as cargas de trabalho em cada cluster.
    • cert-chain.pem é a cadeia de confiança entre os certificados de carga de trabalho e a CA raiz. Neste exemplo, cert-chain.pem contém apenas o certificado ca-cert.pem. Por isso, esses arquivos são idênticos. Esse arquivo estabelece a confiança entre microsserviços executados em clusters diferentes.

Na instalação padrão do Citadel, as opções de linha de comando (em inglês) configuram o local de certificados e chaves com base no secret predefinido e nos nomes de arquivo usados no comando. Ou seja: um secret chamado cacert, um certificado raiz em um arquivo chamado root-cert.pem, uma chave do Citadel em ca-key.pem e assim por diante.

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

    cd ${WORKDIR}
export ISTIO_VERSION=1.9.0
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} TARGET_ARCH=x86_64 sh -
cd istio-${ISTIO_VERSION}
export PATH=$PWD/bin:$PATH

  2. No Cloud Shell, crie o secret usando os arquivos de certificado adequados:

    for cluster in $(kubectx)
do
  kubectl --context $cluster create namespace istio-system
  kubectl --context $cluster create secret generic cacerts -n istio-system \
    --from-file=${WORKDIR}/istio-${ISTIO_VERSION}/samples/certs/ca-cert.pem \
    --from-file=${WORKDIR}/istio-${ISTIO_VERSION}/samples/certs/ca-key.pem \
    --from-file=${WORKDIR}/istio-${ISTIO_VERSION}/samples/certs/root-cert.pem \
    --from-file=${WORKDIR}/istio-${ISTIO_VERSION}/samples/certs/cert-chain.pem;
  done

Como instalar o Istio

Nesta seção, você instalará o Istio nos clusters west e central.

  1. No Cloud Shell, defina a rede padrão do cluster west.

    kubectl --context=west label namespace istio-system topology.istio.io/network=network1

  2. Crie a configuração do Istio para o cluster west com um gateway leste-oeste dedicado:

    cd ${WORKDIR}
cat <<EOF > istio-west.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    global:
      meshID: mesh1
      multiCluster:
        clusterName: west
      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
          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. Aplique a configuração ao cluster west:

    istioctl install --context=west -f istio-west.yaml

    Pressione y para continuar.

  4. Inspecione as implantações no namespace istio-system.

    kubectl --context=west -n istio-system get deployments

    A saída será assim:

    NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
istio-eastwestgateway   1/1     1            1           2m11s
istio-ingressgateway    1/1     1            1           8m43s
istiod                  1/1     1            1           8m56s

  5. Aguarde até que o gateway leste-oeste seja atribuído a um endereço IP externo:

    kubectl --context=west get svc istio-eastwestgateway -n istio-system

    A saída será assim:

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                                           AGE
istio-eastwestgateway   LoadBalancer   10.3.241.43   34.94.214.249   15021:30369/TCP,15443:30988/TCP,15012:31358/TCP,15017:32625/TCP   3m42s

  6. Como os clusters estão em redes separadas, é necessário expor todos os serviços (*.local) no gateway leste-oeste em ambos os clusters. Como o gateway leste-oeste é público na Internet, os serviços por trás dele só podem ser acessados por serviços com um certificado mTLS confiável e um ID de carga de trabalho, como se estivessem na mesma rede.

    kubectl --context=west apply -n istio-system -f \
${WORKDIR}/istio-${ISTIO_VERSION}/samples/multicluster/expose-services.yaml

  7. Defina a rede padrão do cluster central.

    kubectl --context=central label namespace istio-system topology.istio.io/network=network2

  8. Crie a configuração do Istio para o cluster central com um gateway leste-oeste dedicado:

    cd ${WORKDIR}
cat <<EOF > istio-central.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    global:
      meshID: mesh1
      multiCluster:
        clusterName: central
      network: network2
  components:
    ingressGateways:
      - name: istio-eastwestgateway
        label:
          istio: eastwestgateway
          app: istio-eastwestgateway
          topology.istio.io/network: network2
        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: network2
          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

  9. Aplique a configuração ao cluster central:

    istioctl install --context=central -f istio-central.yaml

    Pressione y para continuar.

  10. Inspecione as implantações no namespace istio-system.

    kubectl --context=central -n istio-system get deployments

    A saída será assim:

    NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
istio-eastwestgateway   1/1     1            1           2m11s
istio-ingressgateway    1/1     1            1           8m43s
istiod                  1/1     1            1           8m56s

  11. Aguarde até que o gateway leste-oeste seja atribuído a um endereço IP externo:

    kubectl --context=central get svc istio-eastwestgateway -n istio-system

    A saída será assim:

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                                           AGE
istio-eastwestgateway   LoadBalancer   10.3.250.201   35.232.125.62   15021:30810/TCP,15443:31125/TCP,15012:30519/TCP,15017:30743/TCP   37s

  12. Expor todos os serviços (*.local) no gateway leste-oeste no cluster central.

    kubectl --context=central apply -n istio-system -f \
${WORKDIR}/istio-${ISTIO_VERSION}/samples/multicluster/expose-services.yaml

Como ativar a descoberta de endpoints

  1. Instale um secret remoto no cluster west que fornece acesso ao servidor da API do cluster central.

    istioctl x create-remote-secret \
--context=central \
--name=central | \
kubectl apply -f - --context=west

  2. Instale um secret remoto no cluster central que fornece acesso ao servidor da API do cluster west.

    istioctl x create-remote-secret \
--context=west \
--name=west | \
kubectl apply -f - --context=central

Como implantar o aplicativo Online Boutique

Nesta seção, você instalará o aplicativo Online Boutique nos dois clusters. O Online Boutique consiste em 10 microsserviços escritos em diferentes linguagens de programação. Esses microsserviços são divididos entre os clusters central e west, conforme mostrado na arquitetura a seguir.

Os microsserviços são divididos entre os clusters `central` e `west`, com malhas de serviço sobrepostas. No diagrama, o serviço A

  1. Crie namespaces para o aplicativo Online Boutique nos dois clusters:

    kubectl --context central create namespace online-boutique
kubectl --context west create namespace online-boutique

  2. Rotule os namespaces da injeção automática de proxy secundário do Istio (em inglês):

    kubectl --context central label namespace online-boutique istio-injection=enabled
kubectl --context west label namespace online-boutique istio-injection=enabled

  3. Implante o aplicativo Online Boutique nos clusters west e central:

    kubectl --context central -n online-boutique apply -f $WORKDIR/istio-multi-primary/central
kubectl --context west -n online-boutique apply -f $WORKDIR/istio-multi-primary/west

    O aplicativo Online Boutique leva alguns minutos para que todas as implantações estejam ativas.

  4. Aguarde até que todas as implantações estejam disponíveis nos dois clusters.

    # In central cluster
kubectl --context=central -n online-boutique wait --for=condition=available deployment emailservice --timeout=5m
kubectl --context=central -n online-boutique wait --for=condition=available deployment checkoutservice --timeout=5m
kubectl --context=central -n online-boutique wait --for=condition=available deployment shippingservice --timeout=5m
kubectl --context=central -n online-boutique wait --for=condition=available deployment paymentservice --timeout=5m
kubectl --context=central -n online-boutique wait --for=condition=available deployment adservice --timeout=5m
kubectl --context=central -n online-boutique wait --for=condition=available deployment currencyservice --timeout=5m

# In west cluster
kubectl --context=west -n online-boutique wait --for=condition=available deployment frontend --timeout=5m
kubectl --context=west -n online-boutique wait --for=condition=available deployment recommendationservice --timeout=5m
kubectl --context=west -n online-boutique wait --for=condition=available deployment productcatalogservice --timeout=5m
kubectl --context=west -n online-boutique wait --for=condition=available deployment cartservice --timeout=5m
kubectl --context=west -n online-boutique wait --for=condition=available deployment redis-cart --timeout=5m
kubectl --context=west -n online-boutique wait --for=condition=available deployment loadgenerator --timeout=5m

    O resultado de todas as implantações é semelhante a este:

    deployment.apps/frontend condition met

Como acessar o aplicativo Online Boutique

É possível acessar o aplicativo Online Boutique no endereço IP público istio-ingressgatway de qualquer cluster.

  1. Consiga o endereço IP público do serviço istio-ingressgateway dos dois clusters.

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

    A saída mostra o endereço IP externo.

  2. Copie e cole o endereço IP do gateway de entrada do Istio de um cluster 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 aplicativo Hipster com fotos de vários produtos, como bicicletas, câmeras, máquinas de escrever, entre outros.

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

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

Como monitorar a malha de serviço

O Kiali pode ser usado para monitorar e 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. Implante o Prometheus e o Kiali no cluster west.

    kubectl --context west apply -f https://raw.githubusercontent.com/istio/istio/release-${ISTIO_VERSION:0:3}/samples/addons/prometheus.yaml
kubectl --context west apply -f https://raw.githubusercontent.com/istio/istio/release-${ISTIO_VERSION: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 west get pods -n istio-system

    A saída será assim:

    kiali-6d5c4bbb64-wpsqx                   1/1     Running   0          72s
prometheus-6d87d85c88-h2cwl              2/2     Running   0          92s

  3. No Cloud Shell, exponha o Kiali no cluster west:

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

  4. Abra a interface da Web do Kiali no cluster west. No Cloud Shell, selecione Visualização na Web e, em seguida, selecione Visualizar na porta 8080.

  5. No menu esquerdo, selecione Graph.

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

  7. No menu em Graph, selecione Service graph.

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

    Captura de tela que mostra uma entrada interna de serviço com o símbolo de um cadeado próximo a ela.

Você instalou um aplicativo dividido em vários clusters. Os microsserviços estão se comunicando com segurança entre os clusters usando o gateway leste-oeste do Istio com mTLS. Cada cluster mantém e controla seu próprio plano de controle do Istio, evitando pontos únicos de falha.

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. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Redefinir o kubeconfig

  1. Redefina o arquivo kubeconfig:

    unset KUBECONFIG
rm istio-kubeconfig

A seguir