Como executar serviços distribuídos em clusters particulares do GKE usando o Cloud Service Mesh

Neste documento, mostramos como executar serviços distribuídos em vários clusters do Google Kubernetes Engine (GKE) no Google Cloud usando o Cloud Service Mesh. Neste documento, também mostramos como expor um serviço distribuído usando Entrada em vários clusters e o Cloud Service Mesh. É possível usar este documento para configurar clusters do GKE não particulares. O documento destaca a configuração que se destina estritamente a clusters particulares.

Este documento é destinado a administradores de plataformas e operadores de serviços que têm conhecimento básico sobre o Kubernetes. Alguns conhecimentos sobre malha de serviço são benéficos, embora não sejam obrigatórios. O Cloud Service Mesh é baseado na tecnologia de código aberto Istio. Para mais informações sobre a malha de serviço e o Istio, consulte istio.io (em inglês).

Um serviço distribuído é um serviço do Kubernetes que atua como um único serviço lógico. Os serviços distribuídos são mais resilientes que os serviços do Kubernetes porque são executados em vários clusters do Kubernetes no mesmo namespace. Um serviço distribuído permanece ativo mesmo que um ou mais clusters do GKE estejam inativos, desde que os clusters íntegros possam atender à carga desejada.

Os serviços do Kubernetes são conhecidos apenas pelo servidor da API Kubernetes do cluster em que são executados. Se o cluster do Kubernetes estiver inativo (por exemplo, durante uma manutenção programada), todos os serviços do Kubernetes em execução nesse cluster também estarão inativos. Executar serviços distribuídos facilita o gerenciamento do ciclo de vida do cluster, porque é possível removê-los para manutenção ou upgrades enquanto outros clusters atendem ao tráfego. Para criar um serviço distribuído, a funcionalidade da malha de serviço fornecida pelo Cloud Service Mesh é usada para vincular serviços em execução em vários clusters para atuar como um único serviço lógico.

Os clusters particulares do GKE permitem configurar os nós e o servidor da API como recursos privados disponíveis apenas na rede da nuvem privada virtual (VPC). A execução de serviços distribuídos em clusters particulares do GKE fornece às empresas serviços seguros e confiáveis.

Arquitetura

Neste tutorial, usamos a arquitetura mostrada no diagrama a seguir:

Arquitetura de serviços distribuídos em clusters particulares do GKE usando o Cloud Service Mesh

No diagrama anterior, a arquitetura inclui os seguintes clusters:

  • Dois clusters (gke-central-priv e gke-west-priv) atuam como clusters particulares do GKE idênticos em duas regiões diferentes.
  • Um cluster separado (ingress-config) atua como o cluster do plano de controle que configura a Entrada de vários clusters.

Neste tutorial, você implantará o aplicativo de amostra do Bank of Anthos em dois clusters particulares do GKE (gke-central-priv e gke-west-priv). O Bank of Anthos é um exemplo de aplicativo de microsserviços que consiste em vários microsserviços e bancos de dados SQL que simulam um app de Internet banking. O aplicativo consiste em um front-end da Web que os clientes podem acessar e vários serviços de back-end, como saldo, livro-razão e serviços de conta que simulam um banco.

O aplicativo inclui dois bancos de dados PostgreSQL instalados no Kubernetes como StatefulSets. Um banco de dados é usado para transações, enquanto o outro é usado para contas de usuário. Todos os serviços, exceto os dois, são executados como serviços distribuídos. Isso significa que os pods de todos os serviços são executados em ambos os clusters de aplicativos (no mesmo namespace) e o Cloud Service Mesh é configurado para que cada serviço apareça como um único serviço lógico.

Objetivos

  • Crie três clusters do GKE.
  • Configurar dois dos clusters do GKE como clusters particulares (gke-central-priv e gke-west-priv).
  • Configurar um cluster do GKE (ingress-config) como o cluster de configuração central. Esse cluster atua como um cluster de configuração para Entrada de vários clusters.
  • Configurar a rede (gateways NAT, Cloud Router e regras de firewall) para permitir tráfego entre clusters e de saída dos dois clusters GKE particulares.
  • Configurar redes autorizadas para permitir o acesso do serviço da API do Cloud Shell aos dois clusters particulares do GKE.
  • Implante e configure o Cloud Service Mesh de vários clusters nos dois clusters particulares no modo multiprimário. O modo multiprimário implanta um plano de controle do Cloud Service Mesh nos dois clusters.
  • Implante o aplicativo Bank of Anthos nos dois clusters particulares. Todos os serviços, exceto os bancos de dados, são implantados como serviços distribuídos (pods em execução nos dois clusters particulares).
  • Monitorar serviços usando o Cloud Service Mesh.
  • Configurar a Entrada de vários clusters nos serviços frontend do Bank of Anthos. Isso permite que clientes externos (por exemplo, seu navegador da Web) acessem um serviço distribuído em execução em uma frota de clusters GKE particulares.

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.

Antes de começar

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

    Acessar o seletor de projetos

  2. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

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

    Ativar o Cloud Shell

    Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.

    Execute todos os comandos deste tutorial no Cloud Shell.

  4. Defina as variáveis de ambiente usadas neste tutorial. As variáveis definem nomes de clusters, regiões, zonas, endereçamento IP e versões do Cloud Service Mesh usadas neste tutorial.

    1. Substitua YOUR_PROJECT_ID pelo código do projeto:

      export PROJECT_ID=YOUR_PROJECT_ID
gcloud config set project ${PROJECT_ID}

    2. Defina as variáveis de ambiente restantes:

      export CLUSTER_1=gke-west-priv
export CLUSTER_2=gke-central-priv
export CLUSTER_1_ZONE=us-west2-a
export CLUSTER_1_REGION=us-west2
export CLUSTER_1_MASTER_IPV4_CIDR=172.16.0.0/28
export CLUSTER_2_ZONE=us-central1-a
export CLUSTER_2_REGION=us-central1
export CLUSTER_2_MASTER_IPV4_CIDR=172.16.1.0/28
export CLUSTER_INGRESS=gke-ingress
export CLUSTER_INGRESS_ZONE=us-west1-a
export CLUSTER_INGRESS_REGION=us-west1
export CLUSTER_INGRESS_MASTER_IPV4_CIDR=172.16.2.0/28
export WORKLOAD_POOL=${PROJECT_ID}.svc.id.goog
export ASM_VERSION=1.10
export CLOUDSHELL_IP=$(dig +short myip.opendns.com @resolver1.opendns.com)

prepare o ambiente

  1. No Cloud Shell, ative as APIs:

    gcloud services enable \
  --project=${PROJECT_ID} \
  container.googleapis.com \
  mesh.googleapis.com \
  gkehub.googleapis.com

  2. Ative a frota do Cloud Service Mesh para seu projeto:

    gcloud container fleet mesh enable --project=${PROJECT_ID}

Preparar a rede para clusters particulares do GKE

Nesta seção, você prepara a rede para os clusters particulares do GKE usados para executar serviços distribuídos.

Os nós de cluster do GKE particulares não recebem um endereço IP público. Todos os nós em um cluster particular do GKE recebem um endereço IP VPC particular (no espaço de endereço RFC 1918). Isso significa que os pods que precisam acessar recursos externos (fora da rede VPC) exigem um gateway Cloud NAT. Os gateways NAT da nuvem são gateways NAT regionais que permitem que os pods com endereços IP internos se comuniquem com a Internet. Neste tutorial, você configura um gateway do Cloud NAT em cada uma das duas regiões. Vários clusters dentro de uma região podem usar o mesmo gateway NAT.

  1. No Cloud Shell, crie e reserve dois endereços IP externos para os dois gateways NAT:

    gcloud compute addresses create ${CLUSTER_1_REGION}-nat-ip \
  --project=${PROJECT_ID} \
  --region=${CLUSTER_1_REGION}

gcloud compute addresses create ${CLUSTER_2_REGION}-nat-ip \
  --project=${PROJECT_ID} \
  --region=${CLUSTER_2_REGION}

  2. Armazene o endereço IP e o nome dos endereços IP em variáveis:

    export NAT_REGION_1_IP_ADDR=$(gcloud compute addresses describe ${CLUSTER_1_REGION}-nat-ip \
  --project=${PROJECT_ID} \
  --region=${CLUSTER_1_REGION} \
  --format='value(address)')

export NAT_REGION_1_IP_NAME=$(gcloud compute addresses describe ${CLUSTER_1_REGION}-nat-ip \
  --project=${PROJECT_ID} \
  --region=${CLUSTER_1_REGION} \
  --format='value(name)')

export NAT_REGION_2_IP_ADDR=$(gcloud compute addresses describe ${CLUSTER_2_REGION}-nat-ip \
  --project=${PROJECT_ID} \
  --region=${CLUSTER_2_REGION} \
  --format='value(address)')

export NAT_REGION_2_IP_NAME=$(gcloud compute addresses describe ${CLUSTER_2_REGION}-nat-ip \
  --project=${PROJECT_ID} \
  --region=${CLUSTER_2_REGION} \
  --format='value(name)')

  3. Crie gateways do Cloud NAT nas duas regiões dos clusters particulares do Cloud GKE:

    gcloud compute routers create rtr-${CLUSTER_1_REGION} \
  --network=default \
  --region ${CLUSTER_1_REGION}

gcloud compute routers nats create nat-gw-${CLUSTER_1_REGION} \
  --router=rtr-${CLUSTER_1_REGION} \
  --region ${CLUSTER_1_REGION} \
  --nat-external-ip-pool=${NAT_REGION_1_IP_NAME} \
  --nat-all-subnet-ip-ranges \
  --enable-logging

gcloud compute routers create rtr-${CLUSTER_2_REGION} \
  --network=default \
  --region ${CLUSTER_2_REGION}

gcloud compute routers nats create nat-gw-${CLUSTER_2_REGION} \
  --router=rtr-${CLUSTER_2_REGION} \
  --region ${CLUSTER_2_REGION} \
  --nat-external-ip-pool=${NAT_REGION_2_IP_NAME} \
  --nat-all-subnet-ip-ranges \
  --enable-logging

  4. Crie uma regra de firewall que permita a comunicação entre pods e a comunicação entre servidores. A comunicação entre pods permite que os serviços distribuídos se comuniquem entre si nos clusters do GKE. A comunicação do pod para o servidor de API permite que o plano de controle do Cloud Service Mesh consulte clusters do GKE para descoberta de serviços.

    gcloud compute firewall-rules create all-pods-and-master-ipv4-cidrs \
  --project ${PROJECT_ID} \
  --network default \
  --allow all \
  --direction INGRESS \
  --source-ranges 10.0.0.0/8,${CLUSTER_1_MASTER_IPV4_CIDR},${CLUSTER_2_MASTER_IPV4_CIDR},${CLUSTER_INGRESS_MASTER_IPV4_CIDR}

A rede está preparada. Neste tutorial, você usará todo o intervalo de endereços IP 10.0.0.0/8, que inclui todos os intervalos de pods. Recomendamos que você crie uma regra de firewall mais rígida na produção, com base em suas condições e requisitos.

Criar clusters particulares do GKE

Nesta seção, você cria os dois clusters particulares do GKE em que o aplicativo de amostra é implantado. Neste tutorial, os nós do cluster particulares do GKE têm endereços IP privados, e o servidor da API tem um endpoint público. No entanto, o acesso ao servidor de API é restrito por meio de redes autorizadas.

  1. No Cloud Shell, crie dois clusters particulares que tenham redes autorizadas. Configure os clusters para permitir o acesso do intervalo CIDR de IP do pod (para o plano de controle do Cloud Service Mesh) e do Cloud Shell para que seja possível acessar os clusters a partir do terminal.

    gcloud container clusters create ${CLUSTER_1} \
  --project ${PROJECT_ID} \
  --zone=${CLUSTER_1_ZONE} \
  --machine-type "e2-standard-4" \
  --num-nodes "3" --min-nodes "3" --max-nodes "5" \
  --enable-ip-alias --enable-autoscaling \
  --workload-pool=${WORKLOAD_POOL} \
  --enable-private-nodes \
  --master-ipv4-cidr=${CLUSTER_1_MASTER_IPV4_CIDR} \
  --enable-master-authorized-networks \
  --master-authorized-networks $NAT_REGION_1_IP_ADDR/32,$NAT_REGION_2_IP_ADDR/32,$CLOUDSHELL_IP/32

gcloud container clusters create ${CLUSTER_2} \
  --project ${PROJECT_ID} \
  --zone=${CLUSTER_2_ZONE} \
  --machine-type "e2-standard-4" \
  --num-nodes "3" --min-nodes "3" --max-nodes "5" \
  --enable-ip-alias --enable-autoscaling \
  --workload-pool=${WORKLOAD_POOL} \
  --enable-private-nodes \
  --master-ipv4-cidr=${CLUSTER_2_MASTER_IPV4_CIDR} \
  --enable-master-authorized-networks \
  --master-authorized-networks $NAT_REGION_1_IP_ADDR/32,$NAT_REGION_2_IP_ADDR/32,$CLOUDSHELL_IP/32

    As redes autorizadas contêm os endereços IP públicos nos gateways do Cloud NAT. Como o endpoint do servidor da API para um cluster particular é um endpoint público, os pods executados em um cluster particular precisam usar um gateway do Cloud NAT para acessar os endpoints do servidor da API pública.

    O endereço IP do Cloud Shell também faz parte das redes autorizadas, que permite acessar e gerenciar clusters do seu terminal do Cloud Shell. Os endereços IP públicos do Cloud Shell são dinâmicos. Portanto, sempre que você iniciar o Cloud Shell, poderá receber um endereço IP público diferente. Ao receber um novo endereço IP, você perde o acesso aos clusters porque o novo endereço IP não faz parte das redes autorizadas para os dois clusters.

    Se você perder o acesso aos clusters, atualize as redes autorizadas dos clusters para incluir o novo endereço IP do Cloud Shell:

    1. Receba o endereço IP público atualizado do Cloud Shell:

      export CLOUDSHELL_IP=$(dig +short myip.opendns.com @resolver1.opendns.com)

    2. Atualize as redes autorizadas para os dois clusters:

      gcloud container clusters update ${CLUSTER_1} \
  --zone=${CLUSTER_1_ZONE} \
  --enable-master-authorized-networks \
  --master-authorized-networks $NAT_REGION_1_IP_ADDR/32,$NAT_REGION_2_IP_ADDR/32,$CLOUDSHELL_IP/32

gcloud container clusters update ${CLUSTER_2} \
  --zone=${CLUSTER_2_ZONE} \
  --enable-master-authorized-networks \
  --master-authorized-networks $NAT_REGION_1_IP_ADDR/32,$NAT_REGION_2_IP_ADDR/32,$CLOUDSHELL_IP/32

  2. Verifique se todos os clusters estão em execução:

    gcloud container clusters list

    A saída será assim:

    NAME              LOCATION       MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
gke-central-priv  us-central1-a  1.16.15-gke.6000  35.238.99.104  e2-standard-4  1.16.15-gke.6000  3          RUNNING
gke-west-priv     us-west2-a     1.16.15-gke.6000  34.94.188.180  e2-standard-4  1.16.15-gke.6000  3          RUNNING

  3. Conecte-se aos dois clusters para gerar entradas no arquivo kubeconfig:

    touch ~/asm-kubeconfig && export KUBECONFIG=~/asm-kubeconfig
gcloud container clusters get-credentials ${CLUSTER_1} --zone ${CLUSTER_1_ZONE}
gcloud container clusters get-credentials ${CLUSTER_2} --zone ${CLUSTER_2_ZONE}

    Use o arquivo kubeconfig para autenticar clusters criando um usuário e contexto para cada cluster. Depois de gerar entradas no arquivo kubeconfig, é possível alternar rapidamente o contexto entre clusters.

  4. Renomeie os contextos de cluster para conveniência:

    kubectl config rename-context \
gke_${PROJECT_ID}_${CLUSTER_1_ZONE}_${CLUSTER_1} ${CLUSTER_1}

kubectl config rename-context \
gke_${PROJECT_ID}_${CLUSTER_2_ZONE}_${CLUSTER_2} ${CLUSTER_2}

  5. Confirme se os dois contextos de cluster foram renomeados e configurados corretamente

    kubectl config get-contexts --output="name"

    A saída será assim:

    gke-central-priv
gke-west-priv

  6. Registre os clusters em uma frota.

    gcloud container fleet memberships register ${CLUSTER_1} --gke-cluster=${CLUSTER_1_ZONE}/${CLUSTER_1} --enable-workload-identity
gcloud container fleet memberships register ${CLUSTER_2} --gke-cluster=${CLUSTER_2_ZONE}/${CLUSTER_2} --enable-workload-identity

Você criou e renomeou seus clusters particulares do GKE.

Instalar o Cloud Service Mesh

Nesta seção, você vai instalar o Cloud Service Mesh nos dois clusters do GKE e configurar os clusters para descoberta de serviços entre clusters.

  1. No Cloud Shell, instale o Cloud Service Mesh nos dois clusters usando fleet API:

    gcloud container fleet mesh update --management automatic --memberships ${CLUSTER_1},${CLUSTER_2}

  2. Depois que o Cloud Service Mesh gerenciado for ativado nos clusters, defina um relógio para instalar a malha:

    watch -g "gcloud container fleet mesh describe | grep 'code: REVISION_READY'"

  3. Instale gateways de entrada do Cloud Service Mesh para os dois clusters:

    kubectl --context=${CLUSTER_1} create namespace asm-ingress
kubectl --context=${CLUSTER_1} label namespace asm-ingress istio-injection=enabled --overwrite
kubectl --context=${CLUSTER_2} create namespace asm-ingress
kubectl --context=${CLUSTER_2} label namespace asm-ingress istio-injection=enabled --overwrite

cat <<'EOF' > asm-ingress.yaml
apiVersion: v1
kind: Service
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
spec:
  type: LoadBalancer
  selector:
    asm: ingressgateway
  ports:
  - port: 80
    name: http
  - port: 443
    name: https
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
spec:
  selector:
    matchLabels:
      asm: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Anthos Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        asm: ingressgateway
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: asm-ingressgateway-sds
  namespace: asm-ingress
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: asm-ingressgateway-sds
  namespace: asm-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: asm-ingressgateway-sds
subjects:
- kind: ServiceAccount
  name: default
EOF

kubectl --context=${CLUSTER_1} apply -f asm-ingress.yaml
kubectl --context=${CLUSTER_2} apply -f asm-ingress.yaml

  4. Verifique se os gateways de entrada do Cloud Service Mesh estão implantados:

    kubectl --context=${CLUSTER_1} get pod,service -n asm-ingress
kubectl --context=${CLUSTER_2} get pod,service -n asm-ingress

    A saída dos dois clusters será semelhante a esta:

    NAME                                        READY   STATUS    RESTARTS   AGE
pod/asm-ingressgateway-5894744dbd-zxlgc   1/1     Running   0          84s

NAME                           TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)                      AGE
service/asm-ingressgateway   LoadBalancer   10.16.2.131   34.102.100.138   80:30432/TCP,443:30537/TCP   92s

    Depois que o plano de controle do Cloud Service Mesh e os gateways de entrada forem instalados nos dois clusters, a descoberta de serviços entre clusters será ativada com a API da frota. A descoberta de serviços entre clusters permite que os dois clusters descubram endpoints do serviço do cluster remoto. Os serviços distribuídos são executados em vários clusters no mesmo namespace.

    Para que os planos de controle do Cloud Service Mesh descubram todos os endpoints de um serviço distribuído, o Cloud Service Mesh precisa ter acesso a todos os clusters que estejam executando o serviço distribuído. Neste exemplo, usamos dois clusters, portanto, os dois clusters precisam ser capazes de consultar o cluster remoto para encontrar os endpoints do serviço. Com o Cloud Service Mesh gerenciado ativado com a API frota, a descoberta de endpoints é configurada automaticamente.

Os clusters e o Cloud Service Mesh já estão configurados.

Implante o aplicativo do Bank of Anthos

  1. No Cloud Shell, clone o repositório do GitHub do Bank of Anthos:

    git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git ${HOME}/bank-of-anthos

  2. Criar e rotular um namespace bank-of-anthos em ambos os clusters. O rótulo permite a injeção automática dos proxies sidecar Envoy em cada pod dentro do namespace rotulado.

    # cluster_1
kubectl create --context=${CLUSTER_1} namespace bank-of-anthos
kubectl label --context=${CLUSTER_1} namespace bank-of-anthos istio-injection=enabled

# cluster_2
kubectl create --context=${CLUSTER_2} namespace bank-of-anthos
kubectl label --context=${CLUSTER_2} namespace bank-of-anthos istio-injection=enabled

  3. Implante o aplicativo Bank of Anthos nos dois clusters no namespace bank-of-anthos.

    # The following secret is used for user account creation and authentication
kubectl --context=$CLUSTER_1 -n bank-of-anthos apply -f ${HOME}/bank-of-anthos/extras/jwt/jwt-secret.yaml
kubectl --context=$CLUSTER_2 -n bank-of-anthos apply -f ${HOME}/bank-of-anthos/extras/jwt/jwt-secret.yaml

# Deploy all manifests to both clusters
kubectl --context=$CLUSTER_1 -n bank-of-anthos apply -f ${HOME}/bank-of-anthos/kubernetes-manifests
kubectl --context=$CLUSTER_2 -n bank-of-anthos apply -f ${HOME}/bank-of-anthos/kubernetes-manifests

    Os serviços do Kubernetes precisam estar nos dois clusters para a descoberta de serviços. Quando um serviço em um dos clusters tenta fazer uma solicitação, primeiro ele executa uma pesquisa de DNS para o nome do host para receber o endereço IP. No GKE, o servidor kube-dns em execução no cluster processa essa pesquisa. Portanto, é necessária uma definição de serviço configurada.

  4. Exclua o StatefulSets de um cluster para que os dois bancos de dados do PostgreSQL existam em apenas um dos clusters:

    # Delete the two DB statefulSets from Cluster2
kubectl --context=$CLUSTER_2 -n bank-of-anthos delete statefulset accounts-db
kubectl --context=$CLUSTER_2 -n bank-of-anthos delete statefulset ledger-db

  5. Verifique se todos os pods estão sendo executados nos dois clusters:

    1. Receber pods de cluster_1:

      kubectl --context=${CLUSTER_1} -n bank-of-anthos get pod

      A saída será assim:

      NAME                                  READY   STATUS    RESTARTS   AGE
accounts-db-0                         2/2     Running   0          9m54s
balancereader-c5d664b4c-xmkrr         2/2     Running   0          9m54s
contacts-7fd8c5fb6-wg9xn              2/2     Running   1          9m53s
frontend-7b7fb9b665-m7cw7             2/2     Running   1          9m53s
ledger-db-0                           2/2     Running   0          9m53s
ledgerwriter-7b5b6db66f-xhbp4         2/2     Running   0          9m53s
loadgenerator-7fb54d57f8-g5lz5        2/2     Running   0          9m52s
transactionhistory-7fdb998c5f-vqh5w   2/2     Running   1          9m52s
userservice-76996974f5-4wlpf          2/2     Running   1          9m52s

    2. Receber pods de cluster_2:

      kubectl --context=${CLUSTER_2} -n bank-of-anthos get pod

      A saída será assim:

      NAME                                  READY   STATUS    RESTARTS   AGE
balancereader-c5d664b4c-bn2pl         2/2     Running   0          9m54s
contacts-7fd8c5fb6-kv8cp              2/2     Running   0          9m53s
frontend-7b7fb9b665-bdpp4             2/2     Running   0          9m53s
ledgerwriter-7b5b6db66f-297c2         2/2     Running   0          9m52s
loadgenerator-7fb54d57f8-tj44v        2/2     Running   0          9m52s
transactionhistory-7fdb998c5f-xvmtn   2/2     Running   0          9m52s
userservice-76996974f5-mg7t6          2/2     Running   0          9m51s

  6. Implantar as configurações do Cloud Service Mesh nos dois clusters. Isso cria um gateway no namespace asm-ingress e o VirtualService nos namespaces bank-of-anthos para o serviço frontend, o que permite o tráfego de entrada para o serviço frontend.

    Os Gateways geralmente são de propriedade dos administradores da plataforma ou da equipe de administradores de rede. Portanto, o recurso Gateway é criado no namespace do gateway de entrada de propriedade do administrador da plataforma e pode ser usado em outros namespaces por meio das próprias entradas VirtualService. Este é um modelo de "gateway compartilhado".

    cat <<'EOF' > asm-vs-gateway.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
spec:
  selector:
    asm: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: frontend
  namespace: bank-of-anthos
spec:
  hosts:
  - "*"
  gateways:
  - asm-ingress/asm-ingressgateway
  http:
  - route:
    - destination:
        host: frontend
        port:
          number: 80
EOF

kubectl --context=$CLUSTER_1 apply -f asm-vs-gateway.yaml

kubectl --context=$CLUSTER_2 apply -f asm-vs-gateway.yaml

Você agora implantou o aplicativo Bank of Anthos em dois clusters particulares do GKE. Todos os serviços são executados como serviços distribuídos, exceto o banco de dados.

Inspecionar serviços distribuídos

Nesta seção, você usará a ferramenta istioctl para inspecionar a configuração de proxy de qualquer um dos proxies. Isso permite que você veja que os proxies sidecar veem dois pods para cada serviço, com um pod em execução em cada cluster.

  1. No Cloud Shell, inspecione a lista do Endpoints "config-config" no pod frontend em cluster_1:

    export FRONTEND1=$(kubectl get pod -n bank-of-anthos -l app=frontend \
  --context=${CLUSTER_1} -o jsonpath='{.items[0].metadata.name}')
istioctl proxy-config endpoints \
--context $CLUSTER_1 -n bank-of-anthos $FRONTEND1 | grep bank-of-anthos

    A saída será assim:

    10.12.0.6:5432                   HEALTHY     OK                outbound|5432||accounts-db.bank-of-anthos.svc.cluster.local
10.12.0.7:8080                   HEALTHY     OK                outbound|8080||balancereader.bank-of-anthos.svc.cluster.local
10.12.0.8:8080                   HEALTHY     OK                outbound|8080||transactionhistory.bank-of-anthos.svc.cluster.local
10.12.0.9:8080                   HEALTHY     OK                outbound|8080||userservice.bank-of-anthos.svc.cluster.local
10.12.1.10:8080                  HEALTHY     OK                outbound|8080||ledgerwriter.bank-of-anthos.svc.cluster.local
10.12.1.9:8080                   HEALTHY     OK                outbound|8080||contacts.bank-of-anthos.svc.cluster.local
10.12.2.11:5432                  HEALTHY     OK                outbound|5432||ledger-db.bank-of-anthos.svc.cluster.local
10.12.2.13:8080                  HEALTHY     OK                outbound|80||frontend.bank-of-anthos.svc.cluster.local
10.76.1.10:8080                  HEALTHY     OK                outbound|8080||transactionhistory.bank-of-anthos.svc.cluster.local
10.76.1.8:8080                   HEALTHY     OK                outbound|8080||balancereader.bank-of-anthos.svc.cluster.local
10.76.1.9:8080                   HEALTHY     OK                outbound|80||frontend.bank-of-anthos.svc.cluster.local
10.76.2.10:8080                  HEALTHY     OK                outbound|8080||userservice.bank-of-anthos.svc.cluster.local
10.76.2.8:8080                   HEALTHY     OK                outbound|8080||contacts.bank-of-anthos.svc.cluster.local
10.76.2.9:8080                   HEALTHY     OK                outbound|8080||ledgerwriter.bank-of-anthos.svc.cluster.local

    Na saída anterior, cada serviço distribuído tem dois endereços IP de endpoint. Esses são os endereços IP do pod, um para cada cluster.

Acessar o Bank of Anthos

Para acessar o aplicativo Bank of Anthos, use o endereço IP público do Serviço asm-ingressgateway de qualquer um dos clusters.

  1. Conseguir endereços IP asm-ingressgateway dos dois clusters:

    kubectl --context ${CLUSTER_1} \
--namespace asm-ingress get svc asm-ingressgateway -o jsonpath='{.status.loadBalancer}' | grep "ingress"

kubectl --context ${CLUSTER_2} \
--namespace asm-ingress get svc asm-ingressgateway -o jsonpath='{.status.loadBalancer}' | grep "ingress"

    O resultado será semelhante ao mostrado a seguir.

    {"ingress":[{"ip":"35.236.4.18"}]}
{"ingress":[{"ip":"34.68.94.81"}]}

    Copie um dos endereços IP para usar na próxima etapa.

  2. Abra uma nova guia em um navegador da Web e acesse o endereço IP da saída anterior. O front-end do Banco do Anthos será exibido, o que permite fazer login, depositar fundos na conta e transferir fundos para outras contas. O aplicativo deve ser totalmente funcional.

Visualizar os serviços distribuídos

É possível visualizar serviços distribuídos no Cloud Service Mesh.

  1. Para visualizar seus serviços, acesse a página Anthos > Malha de serviço no console do Google Cloud.

    Acessar o Service Mesh

    É possível visualizar serviços na visualização de tabela ou em topologia. A visualização padrão é a visualização em tabela, que mostra todos os serviços distribuídos em execução em um formato tabular. Para mudar as visualizações, clique naquela que você quer exibir.

  2. Na visualização Tabelas, clique em frontend distributed service. Ao clicar em um serviço individual, você vê uma visão detalhada do serviço junto com os serviços conectados.

    Na visualização de detalhes do serviço, é possível criar SLOs e ver um cronograma histórico do serviço clicando em Mostrar linha do tempo.

  3. Para ver os indicadores dourados, no painel lateral, clique em Métricas.

  4. No gráfico Solicitações por segundo, clique em Detalhamento por e selecione Local.

    Os resultados exibem as solicitações por segundo dos dois clusters nas duas regiões. O serviço distribuído está íntegro e os dois endpoints estão disponibilizando tráfego.

  5. Para ver a topologia da malha de serviço, no painel lateral, clique em Anthos Service Mesh e, em seguida, clique em Visualização de topologia.

  6. Para ver mais dados, mantenha o ponteiro do mouse sobre o serviço frontend. Isso exibe informações como solicitações por segundo de e para o front-end e outros serviços.

  7. Para ver mais detalhes, clique em Expandir no serviço frontend. Um Serviço e uma Carga de trabalho serão exibidos. É possível expandir ainda mais a carga de trabalho em duas implantações, expandir as implantações em ReplicaSets e expandir os ReplicaSets em pods. Ao expandir todos os elementos, é possível ver o serviço frontend distribuído, que é basicamente um serviço e dois pods.

Configurar o Ingress de vários clusters

Nesta seção, você cria um Ingress de vários clusters que envia tráfego aos serviços frontend do Bank of GKE Enterprise em execução nos dois clusters. Use o Cloud Load Balancing para criar um balanceador de carga que use os serviços asm-ingressgateway nos dois clusters como back-ends. Um cluster ingress-config é usado para orquestrar a configuração da Entrada de vários clusters.

Para criar o balanceador de carga, use um MultiClusterIngress e um ou mais MultiClusterServices. Os objetos MultiClusterIngress e MultiClusterService são análogos de vários clusters dos recursos existentes Ingress e Service do Kubernetes usados no contexto de cluster único.

  1. Ative as APIs necessárias do GKE Enterprise, da frota do GKE e do Ingress em vários clusters:

    gcloud services enable \
  anthos.googleapis.com \
  multiclusterservicediscovery.googleapis.com \
  multiclusteringress.googleapis.com

  2. Crie o cluster ingress-config Use qualquer cluster, mas recomendamos que você crie um cluster separado para essa finalidade.

    gcloud container clusters create ${CLUSTER_INGRESS} \
  --zone ${CLUSTER_INGRESS_ZONE} \
  --num-nodes=1 \
  --enable-ip-alias \
  --workload-pool=${WORKLOAD_POOL}

  3. Receba as credenciais do cluster e renomeie o contexto para conveniência:

    gcloud container clusters get-credentials ${CLUSTER_INGRESS} \
  --zone ${CLUSTER_INGRESS_ZONE} --project ${PROJECT_ID}

kubectl config rename-context \
  gke_${PROJECT_ID}_${CLUSTER_INGRESS_ZONE}_${CLUSTER_INGRESS} ${CLUSTER_INGRESS}

  4. Para usar a Ingress de vários clusters, registre todos os clusters participantes na frota do GKE Enterprise, incluindo o cluster de configuração:

  5. Registre o cluster de configuração:

    gcloud container fleet memberships register ${CLUSTER_INGRESS} \
  --project=${PROJECT_ID} \
  --gke-cluster=${CLUSTER_INGRESS_ZONE}/${CLUSTER_INGRESS} \
  --enable-workload-identity

  6. Verifique se todos os clusters estão registrados na frota do GKE Enterprise:

    gcloud container fleet memberships list

    A saída será assim:

    NAME            EXTERNAL_ID
gke-west        7fe5b7ce-50d0-4e64-a9af-55d37b3dd3fa
gke-central     6f1f6bb2-a3f6-4e9c-be52-6907d9d258cd
gke-ingress     3574ee0f-b7e6-11ea-9787-42010a8a019c

  7. Ative os recursos da Entrada de vários clusters no cluster ingress-config. Isso cria os CRDs do MulticlusterService e MulticlusterIngress personalizados no cluster.

    gcloud container fleet ingress enable \
  --config-membership=projects/${PROJECT_ID}/locations/global/memberships/${CLUSTER_INGRESS}

  8. Verifique se a Entrada de vários clusters está ativada no cluster ingress-config:

    gcloud container fleet ingress describe

    A saída será assim:

    membershipStates:
  projects/986443280307/locations/global/memberships/gke-central-priv:
    state:
      code: OK
      updateTime: '2022-09-29T13:57:02.972748202Z'
  projects/986443280307/locations/global/memberships/gke-ingress:
    state:
      code: OK
      updateTime: '2022-09-29T13:57:02.972744692Z'
  projects/986443280307/locations/global/memberships/gke-west-priv:
    state:
      code: OK
      updateTime: '2022-09-29T13:57:02.972746497Z'

  9. Verifique se os dois CRDs estão implantados no cluster ingress-config:

    kubectl --context=${CLUSTER_INGRESS} get crd | grep multicluster

    O resultado será semelhante ao mostrado a seguir.

    multiclusteringresses.networking.gke.io     2020-10-29T17:32:50Z
multiclusterservices.networking.gke.io      2020-10-29T17:32:50Z

  10. Crie o namespace asm-ingress no cluster ingress-config:

    kubectl --context ${CLUSTER_INGRESS} create namespace asm-ingress

  11. Criar o recurso MultiClusterIngress:

    cat <<EOF > ${HOME}/mci.yaml
apiVersion: networking.gke.io/v1beta1
kind: MultiClusterIngress
metadata:
  name: asm-ingressgateway-multicluster-ingress
spec:
  template:
    spec:
      backend:
       serviceName: asm-ingressgateway-multicluster-svc
       servicePort: 80
EOF

  12. Criar o recurso MultiClusterService:

    cat <<'EOF' > $HOME/mcs.yaml
apiVersion: networking.gke.io/v1beta1
kind: MultiClusterService
metadata:
  name: asm-ingressgateway-multicluster-svc
  annotations:
    beta.cloud.google.com/backend-config: '{"ports": {"80":"gke-ingress-config"}}'
spec:
  template:
    spec:
      selector:
        asm: ingressgateway
      ports:
      - name: frontend
        protocol: TCP
        port: 80 # servicePort defined in Multi Cluster Ingress
  clusters:
  - link: "us-west2-a/gke-west-priv"
  - link: "us-central1-a/gke-central-priv"
EOF

  13. Crie o recurso BackendConfig para verificações de integridade:

    cat <<EOF > $HOME/backendconfig.yaml
apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: gke-ingress-config
spec:
  healthCheck:
    type: HTTP
    port: 15021
    requestPath: /healthz/ready
EOF

  14. Aplique os manifestos BackendConfig, MultiClusterService e MultiClusterIngress:

    kubectl --context ${CLUSTER_INGRESS} -n asm-ingress apply -f ${HOME}/backendconfig.yaml
kubectl --context ${CLUSTER_INGRESS} -n asm-ingress apply -f ${HOME}/mci.yaml
kubectl --context ${CLUSTER_INGRESS} -n asm-ingress apply -f ${HOME}/mcs.yaml

  15. O MultiClusterService que você implantou no cluster de entrada criará um Service "sem comando" no cluster 1 e no cluster 2. Verifique se o Services "headless" foi criado:

    kubectl --context=${CLUSTER_1} -n asm-ingress \
  get services | grep multicluster-svc
kubectl --context=${CLUSTER_2} -n asm-ingress \
  get services | grep multicluster-svc

    A resposta é semelhante a: 

    mci-frontend-multi-cluster-service-svc-f7rcyqry22iq8nmw   ClusterIP      None          <none>          80/TCP         77s
mci-frontend-multi-cluster-service-svc-f7rcyqry22iq8nmw   ClusterIP      None          <none>          80/TCP         78s

  16. Execute o seguinte comando e aguarde até receber um endereço IP do Cloud Load Balancing:

    watch kubectl --context ${CLUSTER_INGRESS} -n asm-ingress get multiclusteringress \
  -o jsonpath="{.items[].status.VIP}"

    A saída será assim:

    35.35.23.11

    Para sair do comando "watch", pressione Ctrl+C.

  17. Navegue até o endereço IP do Cloud Load Balancing em um navegador da Web para acessar o front-end do Banco do Anthos:

    kubectl --context ${CLUSTER_INGRESS} \
  -n asm-ingress get multiclusteringress \
  -o jsonpath="{.items[].status.VIP}"

    Se você receber um erro 404 (ou um erro 502), aguarde alguns minutos e atualize a página no navegador da Web.

Limpar

Para evitar cobranças na sua conta, exclua o projeto ou os clusters.

Exclua o projeto

A maneira mais fácil de eliminar o faturamento é excluir o projeto criado para o tutorial.

  1. No Console do Google Cloud, acesse a página Gerenciar recursos.

    Acessar "Gerenciar recursos"

  2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
  3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Excluir os clusters

  1. No Cloud Shell, cancele o registro e exclua os clusters blue e green:

    gcloud container fleet memberships unregister ${CLUSTER_1} \
  --project=${PROJECT} \
  --gke-uri=${CLUSTER_1_URI}
gcloud container clusters delete ${CLUSTER_1} \
  --zone ${CLUSTER_1_ZONE} \
  --quiet

gcloud container fleet memberships unregister ${CLUSTER_2} \
  --project=${PROJECT} \
  --gke-uri=${CLUSTER_2_URI}
gcloud container clusters delete ${CLUSTER_2} \
  --zone ${CLUSTER_2_ZONE} \
  --quiet

  2. Exclua o recurso MuticlusterIngress do cluster ingress-config:

    kubectl --context ${CLUSTER_INGRESS} -n istio-system delete -f $HOME/mci.yaml

    Esse comando exclui os recursos do Cloud Load Balancing do projeto.

  3. Cancelar o registro e excluir o cluster ingress-config:

    gcloud container fleet memberships unregister ${CLUSTER_INGRESS} \
  --project=${PROJECT} \
  --gke-uri=${CLUSTER_INGRESS_URI}
gcloud container clusters delete ${CLUSTER_INGRESS} \
  --zone ${CLUSTER_INGRESS_ZONE} \
  --quiet

  4. Verifique se todos os clusters foram excluídos:

    gcloud container clusters list

    A saída é esta:

    <null>

  5. Redefinir o arquivo kubeconfig:

    unset KUBECONFIG

A seguir