O Anthos Service Mesh e o Traffic Director agora são Cloud Service Mesh. Para mais informações, consulte a Visão geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

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

Este documento mostra como executar serviços distribuídos em vários Clusters do Google Kubernetes Engine (GKE) no Google Cloud usando o Cloud Service Mesh. Este documento também mostra como expor um serviço distribuído usando Entrada em vários clusters e 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 do 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 malha de serviço a funcionalidade 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ê vai implantar a Banco do Anthos aplicativo de amostra em dois clusters particulares do GKE (gke-central-priv e gke-west-priv). O Bank of Anthos é um exemplo aplicativo de microsserviços que consiste em vários microsserviços e SQL bancos de dados que simulam um app de banco on-line. O aplicativo consiste em um conjunto front-end que os clientes podem acessar e vários serviços de back-end, como balanceamento, 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 nos dois clusters de aplicativos (no mesmo namespace) e que 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.
Implantar e configurar o Cloud Service Mesh com vários clusters nos dois clusters particulares no modo multiprimário. O modo multiprimário implanta uma 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

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

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
Make sure that billing is enabled for your Google Cloud project.
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

Execute todos os comandos deste tutorial no Cloud Shell.

Defina as variáveis de ambiente usadas neste tutorial. Elas definem nomes de clusters, regiões, zonas, endereços IP e Versões do Cloud Service Mesh usadas neste tutorial.

Substitua YOUR_PROJECT_ID pelo código do projeto:

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

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

No Cloud Shell, ative as APIs:

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

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.

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}

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

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

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 servidor pod para a API permite que o plano de controle do Cloud Service Mesh consulte os 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.

No Cloud Shell, crie dois clusters particulares que tenham redes autorizadas. Configure os clusters para permitir o acesso do intervalo de CIDR de IP do pod (para o plano de controle do Cloud Service Mesh) e do Cloud Shell para que você possa acessar os clusters 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

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:

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

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

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

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

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.

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}

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

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ê instala o Cloud Service Mesh nos dois clusters do GKE e configura os clusters para descoberta de serviços entre clusters.

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}
```
Observação: esse processo leva 10 minutos.
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'"
```

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

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 e os gateways de entrada do Cloud Service Mesh forem instalados para os dois clusters, a descoberta de serviços entre clusters será ativada com a API Fleet. 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.

Nos dois planos de controle do Cloud Service Mesh, descubra todos os endpoints da um serviço distribuído, o Cloud Service Mesh precisa ter acesso a todos os clusters que executam 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 Fleet, a descoberta de endpoints é configurada automaticamente.

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

Implante o aplicativo do Bank of Anthos

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

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

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.

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

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

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

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

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, que permite a entrada de tráfego 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.

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.

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.

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.

Para conferir seus serviços, acesse a página Service Mesh 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.
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.
Para ver os indicadores dourados, no painel lateral, clique em Métricas.
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.
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.
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.
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 usa os serviços asm-ingressgateway em ambos os 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.

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

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}

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}

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

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

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

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

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'

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

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

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

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

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

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

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

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 saída é 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

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
```
Observação: esse processo leva cinco minutos.

Para sair do comando "watch", pressione Ctrl+C.
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.

Excluir o projeto

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

Cuidado: excluir um projeto tem os seguintes efeitos:

Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Excluir os clusters

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

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.

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

Verifique se todos os clusters foram excluídos:
```
gcloud container clusters list
```
A saída é esta:
```
<null>
```
Redefinir o arquivo kubeconfig:
```
unset KUBECONFIG
```

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

Arquitetura

Objetivos

Custos

Antes de começar

prepare o ambiente

Preparar a rede para clusters particulares do GKE

Criar clusters particulares do GKE

Instalar o Cloud Service Mesh

Implante o aplicativo do Bank of Anthos

Inspecionar serviços distribuídos

Acessar o Bank of Anthos

Visualizar os serviços distribuídos

Configurar o Ingress de vários clusters

Limpar

Excluir o projeto

Excluir os clusters

A seguir