Stai visualizzando la documentazione legacy di Service Mesh della versione 1.19.

Versioni disponibili

Cloud Service Mesh
Archivio 1.22
Archivio 1.21
Archivio 1.20
Archivio 1.19
Archivio 1.18

Questa pagina è stata tradotta dall'API Cloud Translation.

Eseguire servizi distribuiti su cluster privati GKE utilizzando Cloud Service Mesh

Questo documento illustra come eseguire servizi distribuiti su più Cluster Google Kubernetes Engine (GKE) in Google Cloud che utilizzano Cloud Service Mesh. Questo documento mostra anche come esporre un servizio distribuito utilizzando Ingress multi cluster e Cloud Service Mesh. Puoi usare questo documento per configurare cluster GKE non privati; il documento evidenzia destinata esclusivamente ai cluster privati.

Questo documento è rivolto agli amministratori di piattaforma e agli operatori di servizi che hanno una conoscenza di base di Kubernetes. Alcune nozioni di mesh di servizi sono utili, anche se non obbligatorie. Cloud Service Mesh si basa su Istio open source tecnologia. Per ulteriori informazioni sul mesh di servizi e su Istio, consulta istio.io.

Un servizio distribuito è un servizio Kubernetes che agisce come un singolo servizio logico. I servizi distribuiti sono più resilienti rispetto ai servizi Kubernetes perché vengono eseguite su più cluster Kubernetes nello stesso spazio dei nomi. Un servizio distribuito rimane attivo anche se uno o più cluster GKE sono inattivi, purché i cluster in buono stato siano in grado di gestire il carico desiderato.

I servizi Kubernetes sono noti solo al server API Kubernetes del cluster su cui vengono eseguiti. Se il cluster Kubernetes non è attivo (ad esempio durante una manutenzione programmata), non sono attivi neanche tutti i servizi Kubernetes in esecuzione su quel cluster. L'esecuzione di servizi distribuiti semplifica la gestione del ciclo di vita dei cluster puoi disattivare i cluster per la manutenzione o gli upgrade, mentre e il traffico dei servizi. Per creare un servizio distribuito, la funzionalità del mesh di servizi fornita da Cloud Service Mesh viene utilizzata per collegare i servizi in esecuzione su più cluster in modo che agiscano come un unico servizio logico.

I cluster privati GKE ti consentono di configurare i nodi e il server API come risorse private disponibili solo sulla rete Virtual Private Cloud (VPC). Esecuzione di servizi distribuiti in GKE in privato offre alle aziende servizi sicuri e affidabili.

Architettura

Questo tutorial utilizza l'architettura mostrata nel seguente diagramma:

Architettura di servizi distribuiti su cluster privati GKE utilizzando Cloud Service Mesh

Nel diagramma precedente, l'architettura include i seguenti cluster:

Due cluster (gke-central-priv e gke-west-priv) agiscono come cluster privati GKE identici in due regioni diverse.
Un cluster separato (ingress-config) agisce da cluster del piano di controllo che configura Ingress multi-cluster.

In questo tutorial, eseguirai il deployment Banca di Anthos di esempio su due cluster privati GKE (gke-central-priv e gke-west-priv). Bank of Anthos è un esempio un'applicazione basata su microservizi costituita da più microservizi e che simulano un'app di online banking. L'applicazione consiste in un server web il frontend accessibile ai client e diversi servizi di backend come bilancia, registro e servizi di conto che simulano una banca.

L'applicazione include due database PostgreSQL installati di Kubernetes come StatefulSet. Un database viene utilizzato per le transazioni, mentre l'altro per gli account utente. Tutti i servizi tranne i due database vengono eseguiti come servizi distribuiti. Ciò significa che i pod per tutti i servizi vengono eseguiti in entrambi i cluster di applicazioni (nello stesso spazio dei nomi) e Cloud Service Mesh è configurato in modo che ogni servizio venga visualizzato come un singolo servizio logico.

Obiettivi

Creare tre cluster GKE.
Configura due dei cluster GKE come cluster privati (gke-central-priv e gke-west-priv).
Configura un cluster GKE (ingress-config) come cluster di configurazione centrale. Questo cluster funge da cluster di configurazione per Ingress multi-cluster.
Configura il networking (gateway NAT, router Cloud e regole firewall) per consentire il traffico tra cluster e in uscita dai due cluster cluster GKE.
Configura le reti autorizzate per consentire l'accesso ai servizi API da Cloud Shell ai due cluster GKE privati.
Esegui il deployment e la configurazione di Cloud Service Mesh multi-cluster sui due servizi di cluster privati in modalità multi-primaria. La modalità multi-principale esegue il deployment Cloud Service Mesh in entrambi i cluster.
Esegui il deployment dell'applicazione Bank of Anthos sui due servizi cluster. Il deployment di tutti i servizi, ad eccezione dei database, viene eseguito (pod in esecuzione su entrambi i cluster privati).
Monitorare i servizi utilizzando Cloud Service Mesh.
Configura Ingress multi-cluster sulla Bank of Anthos frontend servizi. In questo modo, i client esterni (ad esempio il browser web) possono accedere a un servizio distribuito in esecuzione su un parco di cluster GKE privati.

Costi

In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Prima di iniziare

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.

Esegui tutti i comandi di questo tutorial da Cloud Shell.

Definisci le variabili di ambiente utilizzate in questo tutorial. Le variabili definiscono i nomi dei cluster, le regioni, le zone, gli indirizzi IP Versioni di Cloud Service Mesh utilizzate in questo tutorial.

Sostituisci YOUR_PROJECT_ID con l'ID progetto:

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

Imposta le variabili di ambiente rimanenti:

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)

prepara l'ambiente

In Cloud Shell, abilita le API:

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

Attiva il Cloud Service Mesh Fleet per il tuo progetto:

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

Prepara il networking per i cluster GKE privati

In questa sezione, preparerai il networking per l'ambiente Cluster GKE utilizzati per eseguire servizi distribuiti.

Ai nodi dei cluster GKE privati non viene assegnato un IP pubblico . A tutti i nodi di un cluster GKE privato viene assegnato Indirizzo IP VPC privato (nello spazio di indirizzi RFC 1918). Ciò significa che i pod che devono accedere a risorse esterne (al di fuori della rete VPC) richiedono Gateway Cloud NAT. I gateway Cloud NAT sono gateway NAT regionali che consentono ai pod con indirizzi IP interni di comunicare con internet. In questo tutorial, configuri un gateway Cloud NAT in ciascuna delle due regioni. Più cluster all'interno di una regione puoi usare lo stesso gateway NAT.

In Cloud Shell, crea e prenota due indirizzi IP esterni per i due gateway 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}

Memorizza l'indirizzo IP e il nome degli indirizzi IP nelle variabili:

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

Crea gateway Cloud NAT nelle due regioni dei cluster GKE privati:

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

Crea una regola firewall che consenta la comunicazione tra pod e la comunicazione tra pod e il server API. La comunicazione tra pod consente ai servizi distribuiti di comunicare tra loro nei cluster GKE. La comunicazione tra i pod tra i server API consente a Cloud Service Mesh eseguire query sui cluster GKE del piano di controllo per il Service Discovery.
```
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}
```

Il networking è ora pronto. In questo tutorial utilizzerai l'intero 10.0.0.0/8 intervallo di indirizzi IP, che include tutti gli intervalli di pod. È consigliabile si crea una regola firewall più restrittiva in produzione, in base alle condizioni e i tuoi requisiti.

Creare cluster GKE privati

In questa sezione creerai i due cluster GKE privati in cui viene eseguito il deployment dell'app di esempio. In questo tutorial, le I nodi dei cluster GKE hanno indirizzi IP privati e l'API un server web ha un endpoint pubblico. Tuttavia, l'accesso al server API è limitato utilizzando reti autorizzate.

In Cloud Shell, crea due cluster privati autorizzati reti. Configura i cluster in modo da consentire l'accesso dall'intervallo CIDR IP del pod (per il piano di controllo di Cloud Service Mesh) e da Cloud Shell in modo da poter accedere ai cluster dal terminale.

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}

Le reti autorizzate contengono gli indirizzi IP pubblici i gateway Cloud NAT. Poiché l'endpoint del server API per un cluster privato è un endpoint pubblico, i pod in esecuzione in un cluster privato devono utilizzare un gateway Cloud NAT per accedere agli endpoint pubblici del server API.

Anche l'indirizzo IP di Cloud Shell fa parte della che ti consente di accedere ai cluster e gestirli nel terminale Cloud Shell. Gli indirizzi IP rivolti al pubblico di Cloud Shell sono dinamici, quindi ogni volta che avvii Cloud Shell potresti ricevere un indirizzo IP pubblico diverso. Quando ricevi un nuovo indirizzo IP, perdi l'accesso ai cluster perché il nuovo indirizzo IP non fa parte delle reti autorizzate per i due cluster.

Se perdi l'accesso ai cluster, aggiorna le reti autorizzate dei cluster in modo da includere il nuovo indirizzo IP di Cloud Shell:

Ottieni l'indirizzo IP pubblico aggiornato di Cloud Shell:

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

Aggiorna le reti autorizzate per i due cluster:

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

Verifica che tutti i cluster siano in esecuzione:

gcloud container clusters list

L'output è il seguente:

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

Connettiti a entrambi i cluster per generare voci nel file 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}
```
Potrai utilizzare il file kubeconfig per l'autenticazione sui cluster creando un e contesto per ciascun cluster. Dopo aver generato le voci nel file kubeconfig, puoi passare rapidamente da un contesto all'altro tra i cluster.

Rinomina i contesti del cluster per praticità:

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}

Verifica che entrambi i contesti del cluster siano stati rinominati e configurati correttamente:
```
kubectl config get-contexts --output="name"
```
L'output è il seguente:
```
gke-central-priv
gke-west-priv
```

Registra i cluster in un parco risorse:

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

Ora hai creato e rinominato il tuo GKE privato cluster.

Installa Cloud Service Mesh

In questa sezione, installi Cloud Service Mesh sui due cluster GKE e li configuri per il rilevamento dei servizi tra i cluster.

In Cloud Shell, installa Cloud Service Mesh su entrambi i cluster utilizzando fleet API:
```
gcloud container fleet mesh update --management automatic --memberships ${CLUSTER_1},${CLUSTER_2}
```
Nota: questa procedura dovrebbe essere completata entro 10 minuti.
Dopo aver attivato Cloud Service Mesh gestito sui cluster, imposta una sorveglianza per l'installazione del mesh:
```
watch -g "gcloud container fleet mesh describe | grep 'code: REVISION_READY'"
```

Installa i gateway di ingresso Cloud Service Mesh per entrambi i cluster:

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

Verifica che sia stato eseguito il deployment dei gateway in entrata di Cloud Service Mesh:
```
kubectl --context=${CLUSTER_1} get pod,service -n asm-ingress
kubectl --context=${CLUSTER_2} get pod,service -n asm-ingress
```
L'output per entrambi i cluster è simile al seguente:
```
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
```
Dopo aver installato il control plane e i gateway di ingresso di Cloud Service Mesh per entrambi i cluster, viene abilitato il rilevamento dei servizi tra cluster con l'API fleet. Il rilevamento del servizio tra cluster consente ai due cluster di rilevare gli endpoint di servizio dal cluster remoto. I servizi distribuiti vengono eseguiti su più cluster nel stesso spazio dei nomi.

Affinché entrambi i piani di controllo di Cloud Service Mesh rilevino tutti gli endpoint di un servizio distribuito, Cloud Service Mesh deve avere accesso a tutti i cluster su cui è in esecuzione il servizio distribuito. Questo esempio utilizza due cluster, quindi entrambi i cluster devono essere in grado di eseguire query sul cluster remoto per endpoint. Con Cloud Service Mesh gestito abilitato con l'API fleet, il rilevamento degli endpoint viene configurato automaticamente.

I cluster e Cloud Service Mesh sono ora configurati.

Esegui il deployment dell'applicazione Bank of Anthos

In Cloud Shell, clona il repository GitHub di Bank of Anthos:

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

Crea ed etichetta uno spazio dei nomi bank-of-anthos in entrambi i cluster. La consente l'inserimento automatico dei proxy Envoy collaterali in ogni pod all'interno dello spazio dei nomi etichettato.

# 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

Esegui il deployment dell'applicazione Bank of Anthos su entrambi i cluster 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

I servizi Kubernetes devono essere presenti in entrambi i cluster per il rilevamento dei servizi. Quando un servizio in uno dei cluster tenta di effettuare una richiesta, esegue prima una ricerca DNS per il nome host per ottenere l'indirizzo IP. In GKE, il server kube-dns in esecuzione nel cluster gestisce questa ricerca, pertanto è necessaria una definizione di servizio configurata.

Elimina StatefulSets da un cluster in modo che i due PostgreSQL esistono solo in uno dei cluster:

# 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

Assicurati che tutti i pod siano in esecuzione in entrambi i cluster:

Recupera i pod da cluster_1:

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

L'output è simile al seguente:

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

Recupera i pod da cluster_2:

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

L'output è il seguente:

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

Esegui il deployment delle configurazioni di Cloud Service Mesh in entrambi i cluster. Questo crea un Gateway nello spazio dei nomi asm-ingress VirtualService negli spazi dei nomi bank-of-anthos per il servizio frontend, che ti consente di penetrare il traffico verso frontend completamente gestito di Google Cloud.

I Gateways sono generalmente di proprietà degli amministratori della piattaforma o della rete dell'IA. Di conseguenza, nel gateway di Ingress viene creata la risorsa Gateway di proprietà dell'amministratore della piattaforma e potrebbe essere utilizzato in altri spazi dei nomi tramite le proprie voci VirtualService. Si tratta di un modello "Shared Gateway".

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

Hai eseguito il deployment dell'applicazione Bank of Anthos su due cluster GKE. Tutti i servizi vengono eseguiti come servizi distribuiti, tranne il database.

Ispeziona i servizi distribuiti

In questa sezione utilizzerai lo strumento istioctl per ispezionare la configurazione proxy di uno qualsiasi dei proxy. In questo modo puoi vedere che i proxy sidecar vedono due pod per ogni servizio, con un pod in esecuzione in ogni cluster.

In Cloud Shell, controlla l'elenco di endpoint proxy-config nella frontend pod in 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

L'output è il seguente:

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

Nell'output precedente, ogni servizio distribuito ha due IP endpoint indirizzi IP esterni. Questi sono gli indirizzi IP dei pod, uno per ogni cluster.

Accedi a Bank of Anthos

Per accedere all'applicazione Bank of Anthos, puoi utilizzare asm-ingressgateway Specifica l'indirizzo IP pubblico del servizio da entrambi i cluster.

Ottieni gli indirizzi IP asm-ingressgateway di entrambi i cluster:

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"

L'output è simile al seguente.

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

Copia uno degli indirizzi IP da utilizzare nel passaggio successivo.

Apri una nuova scheda in un browser web e vai a uno degli indirizzi IP dell'output precedente. Dovrebbe essere visualizzato il frontend di Bank of Anthos, che ti consente di accedere, depositare fondi sul tuo account e trasferire fondi ad altri . L'applicazione dovrebbe essere completamente funzionale.

Visualizzare i servizi distribuiti

Puoi visualizzare i servizi distribuiti in Cloud Service Mesh.

Per visualizzare i servizi, vai alla pagina Anthos > Service Mesh nella console Google Cloud.

Vai al mesh di servizi

Puoi visualizzare i servizi nella visualizzazione Table o in una visualizzazione Topology. La visualizzazione predefinita è la visualizzazione tabella, che mostra tutti i servizi distribuiti in esecuzione tabulare. Per cambiare visualizzazione, fai clic sulla visualizzazione che vuoi visualizzare.
Nella visualizzazione Tabelle, fai clic su frontend distributed service. Quando fai clic su un singolo servizio, viene visualizzata una visualizzazione dettagliata del servizio insieme ai servizi collegati.

Nella visualizzazione dei dettagli del servizio, puoi creare SLO e visualizzare una cronologia cronologia del servizio facendo clic su Mostra Spostamenti.
Per visualizzare gli indicatori ideali, fai clic su Metriche nel riquadro laterale.
Nel grafico Richieste al secondo, fai clic su Suddivisione per e poi su Località.

I risultati mostrano le richieste al secondo di entrambi i cluster nelle due regioni. Il servizio distribuito è integro ed entrambi gli endpoint stanno gestendo per via del traffico.
Per visualizzare la topologia del tuo mesh di servizi, nel riquadro laterale fai clic su Anthos Service Mesh, quindi fai clic su Visualizzazione topologia.
Per visualizzare altri dati, tieni il puntatore del mouse sopra l'icona frontend completamente gestito di Google Cloud. Vengono visualizzate informazioni come le richieste al secondo verso e dal frontend ad altri servizi.
Per visualizzare ulteriori dettagli, fai clic su Espandi nel servizio frontend. Vengono visualizzati un servizio e un carico di lavoro. Puoi espandere ulteriormente il carico di lavoro in due deployment, espandere i deployment in ReplicaSet ed espandere i ReplicaSet in pod. Quando espandi tutti gli elementi, puoi vedere distribuito frontend, che è essenzialmente un servizio e due pod.

Configura Ingress multi-cluster

In questa sezione creerai un Ingress multi-cluster che invia traffico alla banca. di servizi GKE Enterprise frontend in esecuzione in entrambi i cluster. Utilizzi Cloud Load Balancing per creare un bilanciatore del carico che utilizzi i servizi asm-ingressgateway in di cluster come backend. Un cluster ingress-config viene utilizzato per orchestrare la configurazione di Ingress multi-cluster.

Per creare il bilanciatore del carico, utilizza MultiClusterIngress e uno o più MultiClusterServices. Gli oggetti MultiClusterIngress e MultiClusterService sono analoghi multi-cluster per le risorse Kubernetes Ingress e Service esistenti utilizzate nel contesto del singolo cluster.

Abilita le API GKE Enterprise, GKE Fleet e Ingress multi-cluster richieste:

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

Crea il cluster ingress-config. Puoi utilizzare qualsiasi cluster, ma di creare un cluster separato a questo scopo.

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

Ottieni le credenziali del cluster e rinomina il contesto per comodità:

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}

Per utilizzare Ingress multi-cluster, registra tutti i cluster partecipanti per Parco risorse GKE Enterprise, incluso il cluster di configurazione:

Registra il cluster di configurazione:

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

Verifica che tutti i cluster siano registrati nel parco risorse GKE Enterprise:

gcloud container fleet memberships list

L'output è simile al seguente:

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

Abilita le funzionalità Ingress multi-cluster sul cluster ingress-config. Verranno creati MulticlusterService e MulticlusterIngress CustomResourceDefinitions (CRD) sul cluster.
```
gcloud container fleet ingress enable \
  --config-membership=projects/${PROJECT_ID}/locations/global/memberships/${CLUSTER_INGRESS}
```

Verifica che Ingress multi-cluster sia abilitato sul cluster ingress-config:

gcloud container fleet ingress describe

L'output è il seguente:

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'

Verifica che sia stato eseguito il deployment dei due CRD nel cluster ingress-config:

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

L'output è simile al seguente.

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

Crea lo spazio dei nomi asm-ingress nel cluster ingress-config:

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

Crea la risorsa 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

Crea la risorsa 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

Crea la risorsa BackendConfig per i controlli di integrità:

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

Applica i manifest 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

Il MultiClusterService di cui hai eseguito il deployment nel cluster di ingressi creerà un Service "senza interfaccia" nel cluster 1 e nel cluster 2. Verifica che l'elemento "headless" Sono state create Services:

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

L'output è simile a questo:

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

Esegui questo comando e attendi finché non ricevi un Indirizzo IP di Cloud Load Balancing:
```
watch kubectl --context ${CLUSTER_INGRESS} -n asm-ingress get multiclusteringress \
  -o jsonpath="{.items[].status.VIP}"
```
L'output è simile al seguente:
```
35.35.23.11
```
Nota: questa procedura dovrebbe essere completata entro 5 minuti.

Per uscire dal comando dello smartwatch, premi Ctrl+C.
Vai all'indirizzo IP di Cloud Load Balancing in un browser web per accedere al frontend di Bank of Anthos:
```
kubectl --context ${CLUSTER_INGRESS} \
  -n asm-ingress get multiclusteringress \
  -o jsonpath="{.items[].status.VIP}"
```
Se ricevi un errore 404 (o 502), attendi qualche minuto e poi aggiorna la pagina nel browser web.

Esegui la pulizia

Per evitare che al tuo account vengano addebitati costi, elimina il progetto o i cluster.

Elimina il progetto

Il modo più semplice per eliminare la fatturazione è quello di eliminare il progetto che hai creato per il tutorial.

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività descritte in questo documento, quando lo elimini elimini anche tutto il lavoro svolto nel progetto.
Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un appspot.com URL, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, il riuso dei progetti può aiutarti a non superare i limiti di quota.

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.

Elimina i cluster

In Cloud Shell, annulla la registrazione ed elimina blue e green clusters:

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

Elimina la risorsa MuticlusterIngress dal cluster ingress-config:
```
kubectl --context ${CLUSTER_INGRESS} -n istio-system delete -f $HOME/mci.yaml
```
Le risorse Cloud Load Balancing vengono eliminate dal progetto.

Annulla la registrazione ed elimina il 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

Verifica che tutti i cluster siano stati eliminati:
```
gcloud container clusters list
```
L'output è il seguente:
```
<null>
```
Reimposta il file kubeconfig:
```
unset KUBECONFIG
```

Passaggi successivi

Scopri di più su Ingress multi-cluster.
Scopri come eseguire il deployment di Ingress multi-cluster in più cluster.