Executar serviços distribuídos em clusters privados do GKE com o Cloud Service Mesh

Este documento mostra como executar serviços distribuídos em vários clusters do Google Kubernetes Engine (GKE) Google Cloud usando a malha de serviços na nuvem. Este documento também mostra como expor um serviço distribuído através do Multi Cluster Ingress e da Cloud Service Mesh. Pode usar este documento para configurar clusters do GKE não privados. O documento realça a configuração destinada estritamente a clusters privados.

Este documento destina-se a administradores de plataformas e operadores de serviços que tenham conhecimentos básicos do Kubernetes. Alguns conhecimentos sobre a malha de serviços são benéficos, embora não sejam obrigatórios. O Cloud Service Mesh baseia-se na tecnologia Istio de código aberto. Para mais informações sobre a malha de serviços e o Istio, consulte istio.io.

Um serviço distribuído é um serviço do Kubernetes que funciona como um único serviço lógico. Os serviços distribuídos são mais resilientes do que os serviços do Kubernetes porque são executados em vários clusters do Kubernetes no mesmo espaço de nomes. Um serviço distribuído permanece ativo mesmo que um ou mais clusters do GKE estejam inativos, desde que os clusters em bom estado de funcionamento consigam processar a carga desejada.

Os serviços Kubernetes só são conhecidos pelo servidor da API Kubernetes do cluster no qual são executados. Se o cluster do Kubernetes estiver inativo (por exemplo, durante uma manutenção agendada), todos os serviços do Kubernetes em execução nesse cluster também ficam inativos. A execução de serviços distribuídos facilita a gestão do ciclo de vida do cluster porque pode desativar clusters para manutenção ou atualizações enquanto outros clusters servem tráfego. Para criar um serviço distribuído, a funcionalidade de malha de serviços fornecida pela Cloud Service Mesh é usada para associar serviços em execução em vários clusters para atuarem como um único serviço lógico.

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

Arquitetura

Este tutorial usa a arquitetura apresentada no diagrama seguinte:

No diagrama anterior, a arquitetura inclui os seguintes clusters:

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

Neste tutorial, implementa a aplicação de exemplo Bank of Anthos em dois clusters privados do GKE (gke-central-priv e gke-west-priv). O Bank of Anthos é uma aplicação de microserviços de exemplo que consiste em vários microserviços e bases de dados SQL que simulam uma app de serviços bancários online. A aplicação consiste num front-end Web ao qual os clientes podem aceder e em vários serviços de back-end, como serviços de saldo, livro-razão e conta, que simulam um banco.

A aplicação inclui duas bases de dados PostgreSQL instaladas no Kubernetes como StatefulSets. É usada uma base de dados para as transações, enquanto a outra é usada para as contas de utilizador. Todos os serviços, exceto as duas bases de dados, são executados como serviços distribuídos. Isto significa que os agrupamentos para todos os serviços são executados em ambos os clusters de aplicações (no mesmo espaço de nomes) e o Cloud Service Mesh está configurado para que cada serviço apareça como um único serviço lógico.

Objetivos

• Crie três clusters do GKE.
• Configure dois dos clusters do GKE como clusters privados (gke-central-priv e gke-west-priv).
• Configure um cluster do GKE (ingress-config) como o cluster de configuração central. Este cluster funciona como um cluster de configuração para a entrada em vários clusters.
• Configure a rede (gateways NAT, Cloud Router e regras de firewall) para permitir o tráfego de saída e entre clusters dos dois clusters GKE privados.
• Configure redes autorizadas para permitir o acesso ao serviço de API a partir do Cloud Shell aos dois clusters privados do GKE.
• Implemente e configure a malha de serviços do Google Cloud em vários clusters nos dois clusters privados no modo de vários primários. O modo multiprimário implementa um plano de controlo do Cloud Service Mesh em ambos os clusters.
• Implemente a aplicação Bank of Anthos nos dois clusters privados. Todos os serviços, exceto as bases de dados, são implementados como serviços distribuídos (pods executados em clusters privados).
• Monitorize serviços através do Cloud Service Mesh.
• Configure o Multi Cluster Ingress nos serviços do Bank of Anthos frontend. Isto permite que os clientes externos (por exemplo, o seu navegador de Internet) acedam a um serviço distribuído executado numa frota de clusters privados do GKE.

Custos

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

• GKE
• Virtual Private Cloud networks
• Virtual Private Cloud load balancing

Para gerar uma estimativa de custos com base na sua utilização projetada, use a calculadora de preços.

Os novos Google Cloud utilizadores podem ser elegíveis para uma avaliação gratuita.

Antes de começar

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

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

2. Verify that billing is enabled for your Google Cloud project.

3. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   Executa todos os comandos neste tutorial a partir do Cloud Shell.

4. Defina as variáveis de ambiente que são usadas ao longo deste tutorial. As variáveis definem os nomes dos clusters, as regiões, as zonas, o endereçamento IP e as versões do Cloud Service Mesh que são usadas neste tutorial.

   1. Substitua YOUR_PROJECT_ID pelo ID do seu projeto:

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

   2. Defina as restantes variáveis de ambiente:

      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 seu 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 o seu projeto:

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

Prepare a rede para clusters privados do GKE

Nesta secção, prepara a rede para os clusters GKE privados que usa para executar serviços distribuídos.

Os nós do cluster do GKE privado não têm um endereço IP público atribuído. Todos os nós num cluster GKE privado têm atribuído um endereço IP de VPC privado (no espaço de endereços RFC 1918). Isto significa que os pods que precisam de aceder a recursos externos (fora da rede da VPC) requerem um gateway Cloud NAT. As gateways do Cloud NAT são gateways de NAT regionais que permitem que os pods com endereços IP internos comuniquem com a Internet. Neste tutorial, vai configurar um gateway Cloud NAT em cada uma das duas regiões. Vários clusters numa 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. Armazenar 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 de NAT da nuvem nas duas regiões dos clusters GKE privados:

   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 de pod para pod e de pod para servidor de API. A comunicação pod a pod permite que os serviços distribuídos comuniquem entre si nos clusters do GKE. A comunicação do pod para o servidor da API permite que o plano de controlo do Cloud Service Mesh consulte os clusters do GKE para a deteção 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á agora preparada. Neste tutorial, usa o intervalo de endereços IP 10.0.0.0/8 completo, que inclui todos os intervalos de pods. Recomendamos que crie uma regra de firewall mais rigorosa na produção, com base nas suas condições e requisitos.

Crie clusters privados do GKE

Nesta secção, vai criar os dois clusters privados do GKE onde a app de exemplo está implementada. Neste tutorial, os nós do cluster do GKE privado têm endereços IP privados e o servidor da API tem um ponto final público. No entanto, o acesso ao servidor da API está restrito através de redes autorizadas.

1. No Cloud Shell, crie dois clusters privados com redes autorizadas. Configure os clusters para permitir o acesso a partir do intervalo CIDR de IP do pod (para o plano de controlo da Cloud Service Mesh) e a partir do Cloud Shell, para que possa aceder aos clusters a partir do seu 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 \
     --labels=mesh_id=${MESH_ID} --async
   
   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 \
     --labels=mesh_id=${MESH_ID}
   

   As redes autorizadas contêm os endereços IP públicos nos gateways do Cloud NAT. Uma vez que o ponto final do servidor da API para um cluster privado é um ponto final público, os pods que são executados num cluster privado têm de usar um gateway Cloud NAT para aceder aos pontos finais do servidor da API pública.

   O endereço IP do Cloud Shell também faz parte das redes autorizadas, o que lhe permite aceder e gerir clusters a partir do terminal do Cloud Shell. Os endereços IP públicos do Cloud Shell são dinâmicos, pelo que, sempre que inicia o Cloud Shell, pode receber um endereço IP público diferente. Quando recebe um novo endereço IP, perde o acesso aos clusters porque o novo endereço IP não faz parte das redes autorizadas para os dois clusters.

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

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

   O resultado tem o seguinte aspeto:

   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. Ligue-se a ambos os clusters para gerar entradas no ficheiro 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 ficheiro kubeconfig para se autenticar em clusters criando um utilizador e um contexto para cada cluster. Depois de gerar entradas no ficheiro kubeconfig, pode alternar rapidamente o contexto entre clusters.

4. Mude o nome dos contextos de cluster para maior 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 ambos os contextos de cluster foram devidamente mudados de nome e configurados:

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

   O resultado tem o seguinte aspeto:

   gke-central-priv
   gke-west-priv
   

6. Registe os seus clusters numa 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
   

Agora, criou e mudou o nome dos seus clusters GKE privados.

Instale o Cloud Service Mesh

Nesta secção, instala o Cloud Service Mesh nos dois clusters do GKE e configura os clusters para a deteção de serviços entre clusters.

1. No Cloud Shell, instale o Cloud Service Mesh em ambos os clusters através do comando fleet API:

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

   Nota: este processo deve ser concluído no prazo de 10 minutos.

2. Depois de o Cloud Service Mesh gerido ser ativado nos clusters, defina uma observação para a instalação da malha:

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

3. Instale gateways de entrada do Cloud Service Mesh para ambos os 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 implementados:

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

   O resultado para ambos os clusters tem o seguinte aspeto:

   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 de o plano de controlo e os gateways de entrada do Cloud Service Mesh serem instalados para ambos os clusters, a deteção de serviços entre clusters é ativada com a API Fleet. A descoberta de serviços entre clusters permite que os dois clusters descubram pontos finais de serviços do cluster remoto. Os serviços distribuídos são executados em vários clusters no mesmo espaço de nomes.

   Para que os planos de controlo do Cloud Service Mesh descubram todos os pontos finais de um serviço distribuído, o Cloud Service Mesh tem de ter acesso a todos os clusters que estão a executar o serviço distribuído. Este exemplo usa dois clusters, pelo que ambos os clusters têm de poder consultar o cluster remoto para obter pontos finais de serviço. Com a malha de serviços na nuvem gerida ativada com a API Fleet, a deteção de pontos finais é configurada automaticamente.

Os clusters e a malha de serviço na nuvem estão agora configurados.

Implemente a aplicação 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. Crie e etiquete um espaço de nomes bank-of-anthos em ambos os clusters. A etiqueta permite a injeção automática dos proxies Envoy sidecar em todos os pods no namespace etiquetado.

   # 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. Implemente a aplicação Bank of Anthos em ambos os clusters no espaço de nomes 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 Kubernetes têm de estar em ambos os clusters para a deteção de serviços. Quando um serviço num dos clusters tenta fazer um pedido, primeiro, faz uma procura de DNS para o nome do anfitrião para obter o endereço IP. No GKE, o servidor kube-dns em execução no cluster processa esta pesquisa, pelo que é necessária uma definição de serviço configurada.

4. Elimine o StatefulSets de um cluster para que as duas bases de dados PostgreSQL existam apenas num 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. Certifique-se de que todos os pods estão em execução em ambos os clusters:

   1. Obtenha agrupamentos de cluster_1:

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

      O resultado tem o seguinte aspeto:

      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. Obtenha agrupamentos de cluster_2:

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

      O resultado tem o seguinte aspeto:

      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. Implemente as configurações do Cloud Service Mesh em ambos os clusters. Isto cria um Gateway no espaço de nomes asm-ingress e um VirtualService nos espaços de nomes bank-of-anthos para o serviço frontend, o que lhe permite encaminhar o tráfego para o serviço frontend.

   Gateways são geralmente propriedade dos administradores da plataforma ou da equipa de administradores da rede. Por conseguinte, o recurso Gateway é criado no espaço de nomes do gateway de entrada pertencente ao administrador da plataforma e pode ser usado noutros espaços de nomes através das suas próprias entradas VirtualService. Este é um modelo de "Gateway partilhado".

   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
   

Implementou a aplicação Bank of Anthos em dois clusters GKE privados. Todos os serviços são executados como serviços distribuídos, exceto a base de dados.

Inspecione os serviços distribuídos

Nesta secção, usa a ferramenta istioctl para inspecionar a configuração de proxy de qualquer um dos proxies. Ao fazê-lo, pode ver 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 de pontos finais de proxy-config no frontend pod 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
   

   O resultado tem o seguinte aspeto:

   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 ponto final. Estes são os endereços IP dos pods, um para cada cluster.

Access Bank of Anthos

Para aceder à aplicação Bank of Anthos, pode usar o asm-ingressgateway endereço IP público do serviço de qualquer um dos clusters.

1. Obtenha os endereços IP asm-ingressgateway de ambos os 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 tem o seguinte aspeto.

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

   Copie um dos endereços IP para usar no passo seguinte.

2. Abra um novo separador num navegador de Internet e aceda a qualquer um dos endereços IP do resultado anterior. O frontend do Bank of Anthos deve ser apresentado, o que lhe permite iniciar sessão, depositar fundos na sua conta e transferir fundos para outras contas. A aplicação deve ser totalmente funcional.

Visualize serviços distribuídos

Pode visualizar serviços distribuídos na malha de serviços do Google Cloud.

1. Para ver os seus serviços, aceda à página Anthos > Service Mesh na Google Cloud consola.

   Aceda à malha de serviços

   Pode ver os serviços na vista de tabela ou na vista de topologia. A vista predefinida é a vista de tabela, que mostra todos os seus serviços distribuídos em execução num formato tabular. Para alterar as vistas, clique na vista que quer apresentar.

2. Na vista Tabelas, clique em frontend distributed service. Quando clica num serviço individual, vê uma vista detalhada do serviço, juntamente com os serviços associados.

   Na vista de detalhes do serviço, pode criar SLOs e ver uma cronologia histórica do serviço clicando em Mostrar cronologia.

3. Para ver os sinais de ouro, no painel lateral, clique em Métricas.

4. No gráfico Pedidos por segundo, clique em Discriminar por e, de seguida, selecione Localização.

   Os resultados apresentam os pedidos por segundo de ambos os clusters nas duas regiões. O serviço distribuído está em bom estado e ambos os pontos finais estão a publicar tráfego.

5. Para ver a topologia da sua malha de serviços, no painel lateral, clique em Anthos Service Mesh e, de seguida, em Vista de topologia.

6. Para ver dados adicionais, mantenha o ponteiro do rato sobre o serviço frontend. São apresentadas informações como pedidos por segundo para e a partir do frontend para outros serviços.

7. Para ver mais detalhes, clique em Expandir no serviço frontend. É apresentado um serviço e uma carga de trabalho. Pode expandir ainda mais a carga de trabalho em 2 implementações, expandir as implementações em ReplicaSets e expandir os ReplicaSets em pods. Quando expande todos os elementos, pode ver o serviço frontend distribuído, que é essencialmente um serviço e dois pods.

Configure a entrada em vários clusters

Nesta secção, cria um Multi Cluster Ingress que envia tráfego para os serviços Bank of GKE Enterprise frontend em execução em ambos os clusters. Usa o Cloud Load Balancing para criar um balanceador de carga que usa os serviços em ambos os clusters como back-ends.asm-ingressgateway Um cluster ingress-config é usado para orquestrar a configuração de entrada em vários clusters.

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

1. Ative as APIs GKE Enterprise, GKE Fleet e Multi Cluster Ingress necessárias:

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

2. Crie o cluster ingress-config. Pode usar qualquer cluster, mas recomendamos que crie um cluster separado para este fim.

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

3. Obtenha as credenciais do cluster e mude o nome do contexto para maior 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 entrada em vários clusters, registe todos os clusters participantes na frota do GKE Enterprise, incluindo o cluster de configuração:

5. Registe 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 registados na frota do GKE Enterprise:

   gcloud container fleet memberships list
   

   O resultado tem o seguinte aspeto:

   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 as funcionalidades de entrada em vários clusters no cluster ingress-config. Isto cria as MulticlusterService e as MulticlusterIngress CustomResourceDefinitions (CRDs) no cluster.

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

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

   gcloud container fleet ingress describe
   

   O resultado tem o seguinte aspeto:

   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 implementados no cluster ingress-config:

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

   O resultado tem o seguinte aspeto.

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

10. Crie o espaço de nomes asm-ingress no cluster ingress-config:

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

11. Crie 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. Crie 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 funcionamento:

    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 implementou no cluster de entrada cria um "sem cabeça" Service no cluster 1 e no cluster 2. Verifique se os Services "sem cabeçalho" foram criados:

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

    O resultado é semelhante ao seguinte:

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

    O resultado tem o seguinte aspeto:

    35.35.23.11
    

    Nota: este processo deve estar concluído no prazo de 5 minutos.

    Para sair do comando watch, prima Ctrl+C.

17. Navegue para o endereço IP do Cloud Load Balancing num navegador de Internet para aceder ao frontend do Bank of Anthos:

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

    Se receber um erro 404 (ou um erro 502), aguarde alguns minutos e, em seguida, atualize a página no navegador de Internet.

Limpar

Para evitar incorrer em cobranças na sua conta, elimine o projeto ou os clusters.

Elimine o projeto

A forma mais fácil de eliminar a faturação é eliminar o projeto que criou para o tutorial.

Atenção: a eliminação de um projeto tem os seguintes efeitos:

• Tudo no projeto é eliminado. Se usou um projeto existente para as tarefas neste documento, quando o elimina, também elimina qualquer outro trabalho que tenha feito no projeto.
• Os IDs dos projetos personalizados são perdidos. Quando criou este projeto, pode ter criado um ID do projeto personalizado que quer usar no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, elimine os recursos selecionados no projeto em vez de eliminar o projeto inteiro.

Se planeia explorar várias arquiteturas, tutoriais ou inícios rápidos, a reutilização de projetos pode ajudar a evitar exceder os limites de quota de projetos.

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.

Elimine os clusters

1. No Cloud Shell, anule o registo e elimine 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. Elimine o recurso MuticlusterIngress do cluster ingress-config:

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

   Esta ação elimina os recursos do Cloud Load Balancing do projeto.

3. Anule o registo e elimine 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 eliminados:

   gcloud container clusters list
   

   O resultado é o seguinte:

   <null>

5. Reponha o ficheiro kubeconfig:

   unset KUBECONFIG
   

O que se segue?

• Saiba mais sobre o Multi Cluster Ingress.
• Saiba como implementar o Multi Cluster Ingress em vários clusters.