Da mesh perimetrale a multi-cluster: esegui il deployment di applicazioni distribuite a livello globale tramite il gateway GKE e Cloud Service Mesh

Last reviewed 2024-06-30 UTC

Questo documento mostra come svolgere le seguenti attività:

• Esegui il deployment applicazioni distribuite a livello globale esposte tramite il gateway GKE e Cloud Service Mesh.
• Esponi un'applicazione a più client combinando Cloud Load Balancing con Cloud Service Mesh.
• Integra i bilanciatori del carico con un mesh di servizi di cui è stato eseguito il deployment in più Regioni di Google Cloud.

Questa guida all'implementazione è rivolta agli amministratori di piattaforma. È destinato anche ai professionisti avanzati che utilizzano Cloud Service Mesh. Le istruzioni funzionano anche per Istio su GKE.

Architettura

Il seguente diagramma mostra la topologia in entrata predefinita di un mesh di servizi: bilanciatore del carico TCP/UDP esterno che espone i proxy del gateway in entrata su una cluster singolo:

Questa guida al deployment utilizza le risorse del gateway di Google Kubernetes Engine (GKE). In particolare, utilizza una gateway multi-cluster per configurare il bilanciamento del carico multiregionale davanti a più regioni Pilota automatico distribuiti in due regioni.

Il diagramma precedente mostra come fluiscono i dati attraverso il traffico in entrata nel cloud e il mesh scenari in entrata. Per ulteriori informazioni, consulta la spiegazione diagramma dell'architettura nel documento sull'architettura di riferimento associata.

Obiettivi

• Esegui il deployment di un paio GKE Autopilot cluster su Google Cloud flotta.
• Esegui il deployment di un'istanza basata su Istio Cloud Service Mesh allo stesso parco risorse.
• Configurare un bilanciatore del carico utilizzando Gateway GKE per terminare il traffico HTTPS pubblico.
• Indirizza il traffico HTTPS pubblico alle applicazioni ospitate da Cloud Service Mesh il cui deployment viene eseguito tra cluster e regioni.
• Esegui il deployment dove di esempio in entrambi i cluster Autopilot.

Ottimizzazione dei costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

• Google Kubernetes Engine
• Cloud Load Balancing
• Cloud Service Mesh
• Multi Cluster Ingress
• Google Cloud Armor
• Certificate Manager
• Cloud Endpoints

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.

Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.

Prima di iniziare

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

2. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

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

   Activate Cloud Shell

   Esegui tutti i comandi del terminale per questo deployment da Cloud Shell.

4. Imposta il progetto Google Cloud predefinito:

   export PROJECT=YOUR_PROJECT
   export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")
   gcloud config set project PROJECT_ID
   

   Sostituisci PROJECT_ID con l'ID del progetto che da utilizzare per questo deployment.

5. Crea una directory di lavoro:

   mkdir -p ${HOME}/edge-to-mesh-multi-region
   cd ${HOME}/edge-to-mesh-multi-region
   export WORKDIR=`pwd`
   

crea cluster GKE

In questa sezione creerai dei cluster GKE per ospitare le applicazioni dell'infrastruttura di supporto, che creerai più avanti in questa guida al deployment.

1. In Cloud Shell, crea un nuovo file kubeconfig. Questo passaggio garantisce di non creare un conflitto con le query esistenti (impostazione predefinita) kubeconfig.

   touch edge2mesh_mr_kubeconfig
   export KUBECONFIG=${WORKDIR}/edge2mesh_mr_kubeconfig
   

2. Definisci le variabili di ambiente da utilizzare durante la creazione cluster GKE e le risorse al loro interno. Modifica la regione predefinita scelte più adatte ai tuoi scopi.

   export CLUSTER_1_NAME=edge-to-mesh-01
   export CLUSTER_2_NAME=edge-to-mesh-02
   export CLUSTER_1_REGION=us-central1
   export CLUSTER_2_REGION=us-east4
   export PUBLIC_ENDPOINT=frontend.endpoints.PROJECT_ID.cloud.goog
   

3. Abilita le API Google Cloud utilizzate in questa guida:

   gcloud services enable \
     container.googleapis.com \
     mesh.googleapis.com \
     gkehub.googleapis.com \
     multiclusterservicediscovery.googleapis.com \
     multiclusteringress.googleapis.com \
     trafficdirector.googleapis.com \
     certificatemanager.googleapis.com
   

4. Crea un cluster GKE Autopilot con nodi privati a CLUSTER_1_REGION. Usa il flag --async per evitare di attendere il primo cluster di cui eseguire il provisioning e la registrazione nel parco risorse:

   gcloud container clusters create-auto --async \
   ${CLUSTER_1_NAME} --region ${CLUSTER_1_REGION} \
   --release-channel rapid --labels mesh_id=proj-${PROJECT_NUMBER} \
   --enable-private-nodes --enable-fleet
   

5. Crea e registra un secondo cluster Autopilot in CLUSTER_2_REGION:

   gcloud container clusters create-auto \
   ${CLUSTER_2_NAME} --region ${CLUSTER_2_REGION} \
   --release-channel rapid --labels mesh_id=proj-${PROJECT_NUMBER} \
   --enable-private-nodes --enable-fleet
   

6. Assicurati che i cluster siano in esecuzione. L'operazione potrebbe richiedere fino a 20 minuti tutti i cluster sono in esecuzione:

   gcloud container clusters list
   

   L'output è simile al seguente:

   NAME             LOCATION     MASTER_VERSION  MASTER_IP       MACHINE_TYPE  NODE_VERSION    NUM_NODES  STATUS
   edge-to-mesh-01  us-central1  1.27.5-gke.200  34.27.171.241   e2-small      1.27.5-gke.200             RUNNING
   edge-to-mesh-02  us-east4     1.27.5-gke.200  35.236.204.156  e2-small      1.27.5-gke.200             RUNNING
   

7. Raccogli le credenziali per CLUSTER_1_NAME.Hai creato CLUSTER_1_NAMEin modo asincrono per poter eseguire altri comandi di cui è stato eseguito il provisioning del cluster.

   gcloud container clusters get-credentials ${CLUSTER_1_NAME} \
       --region ${CLUSTER_1_REGION}
   

8. Per chiarire i nomi dei contesti Kubernetes, rinominali in nomi dei cluster:

   kubectl config rename-context gke_PROJECT_ID_${CLUSTER_1_REGION}_${CLUSTER_1_NAME} ${CLUSTER_1_NAME}
   kubectl config rename-context gke_PROJECT_ID_${CLUSTER_2_REGION}_${CLUSTER_2_NAME} ${CLUSTER_2_NAME}
   

Installa un mesh di servizi

In questa sezione, configurerai Cloud Service Mesh gestito con l'API del parco risorse. L'utilizzo dell'API del parco risorse per abilitare Cloud Service Mesh fornisce un l'approccio dichiarativo al provisioning di un mesh di servizi.

1. In Cloud Shell, abilita Cloud Service Mesh nel parco risorse:

   gcloud container fleet mesh enable
   

2. Abilita la gestione automatica del piano di controllo e del piano dati:

   gcloud container fleet mesh update \
     --management automatic \
     --memberships ${CLUSTER_1_NAME},${CLUSTER_2_NAME}
   

3. Attendi circa 20 minuti. Poi verifica che lo stato del piano di controllo sia ACTIVE:

   gcloud container fleet mesh describe
   

   L'output è simile al seguente:

   createTime: '2023-11-30T19:23:21.713028916Z'
   membershipSpecs:
     projects/603904278888/locations/us-central1/memberships/edge-to-mesh-01:
       mesh:
         management: MANAGEMENT_AUTOMATIC
     projects/603904278888/locations/us-east4/memberships/edge-to-mesh-02:
       mesh:
         management: MANAGEMENT_AUTOMATIC
   membershipStates:
     projects/603904278888/locations/us-central1/memberships/edge-to-mesh-01:
       servicemesh:
         controlPlaneManagement:
           details:
           - code: REVISION_READY
             details: 'Ready: asm-managed-rapid'
           implementation: ISTIOD
           state: ACTIVE
         dataPlaneManagement:
           details:
           - code: OK
             details: Service is running.
           state: ACTIVE
       state:
        code: OK
         description: |-
           Revision ready for use: asm-managed-rapid.
           All Canonical Services have been reconciled successfully.
         updateTime: '2024-06-27T09:00:21.333579005Z'
     projects/603904278888/locations/us-east4/memberships/edge-to-mesh-02:
       servicemesh:
         controlPlaneManagement:
           details:
           - code: REVISION_READY
             details: 'Ready: asm-managed-rapid'
           implementation: ISTIOD
           state: ACTIVE
         dataPlaneManagement:
           details:
           - code: OK
             details: Service is running.
           state: ACTIVE
       state:
         code: OK
         description: |-
           Revision ready for use: asm-managed-rapid.
           All Canonical Services have been reconciled successfully.
         updateTime: '2024-06-27T09:00:24.674852751Z'
   name: projects/e2m-private-test-01/locations/global/features/servicemesh
   resourceState:
     state: ACTIVE
   spec: {}
   updateTime: '2024-06-04T17:16:28.730429993Z'
   

Esegui il deployment di un bilanciatore del carico delle applicazioni esterno e crea gateway in entrata

In questa sezione eseguirai il deployment di un bilanciatore del carico delle applicazioni esterno tramite Gateway GKE e crea gateway in entrata per entrambi cluster. Le risorse gateway e gatewayClass automatizzano il provisioning del bilanciatore del carico e del controllo di integrità del backend. Per fornire la terminazione TLS su al bilanciatore del carico, crei Gestore certificati e collegarle al bilanciatore del carico. Inoltre, puoi utilizzare Endpoint per eseguire automaticamente il provisioning di un nome DNS pubblico per l'applicazione.

Installa un gateway in entrata su entrambi i cluster

Come best practice per la sicurezza, ti consigliamo di eseguire il deployment del gateway in entrata in uno spazio dei nomi diverso dal piano di controllo mesh.

1. In Cloud Shell, crea uno spazio dei nomi asm-ingress dedicato in ogni cluster:

   kubectl --context=${CLUSTER_1_NAME} create namespace asm-ingress
   kubectl --context=${CLUSTER_2_NAME} create namespace asm-ingress
   

2. Aggiungi un'etichetta dello spazio dei nomi agli spazi dei nomi asm-ingress:

   kubectl --context=${CLUSTER_1_NAME} label namespace asm-ingress istio-injection=enabled
   kubectl --context=${CLUSTER_2_NAME} label namespace asm-ingress istio-injection=enabled
   

   L'output è simile al seguente:

   namespace/asm-ingress labeled
   

   Etichettatura degli spazi dei nomi asm-ingress con istio-injection=enabled indica a Cloud Service Mesh di inserire automaticamente il collaterale Envoy quando viene eseguito il deployment di un pod.

3. Genera un certificato autofirmato da utilizzare in futuro:

   openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 \
    -subj "/CN=frontend.endpoints.PROJECT_ID.cloud.goog/O=Edge2Mesh Inc" \
    -keyout ${WORKDIR}/frontend.endpoints.PROJECT_ID.cloud.goog.key \
    -out ${WORKDIR}/frontend.endpoints.PROJECT_ID.cloud.goog.crt
   

   Il certificato fornisce un ulteriore livello di crittografia il bilanciatore del carico e i gateway in entrata del mesh di servizi. Inoltre, consente per i protocolli basati su HTTP/2 come gRPC. Istruzioni su come di collegare il certificato autofirmato ai gateway in entrata forniti più avanti Crea un indirizzo IP esterno, un record DNS e risorse del certificato TLS.

   Per ulteriori informazioni sui requisiti del gateway in entrata vedi il certificato, vedi Crittografia dal bilanciatore del carico ai backend.

4. Crea un secret Kubernetes su ciascun cluster per archiviare l'oggetto autofirmato certificato:

   kubectl --context ${CLUSTER_1_NAME} -n asm-ingress create secret tls \
    edge2mesh-credential \
    --key=${WORKDIR}/frontend.endpoints.PROJECT_ID.cloud.goog.key \
    --cert=${WORKDIR}/frontend.endpoints.PROJECT_ID.cloud.goog.crt
   kubectl --context ${CLUSTER_2_NAME} -n asm-ingress create secret tls \
    edge2mesh-credential \
    --key=${WORKDIR}/frontend.endpoints.PROJECT_ID.cloud.goog.key \
    --cert=${WORKDIR}/frontend.endpoints.PROJECT_ID.cloud.goog.crt
   

5. Per l'integrazione con un bilanciatore del carico delle applicazioni esterno, crea un kustomize per configurare Risorse gateway in entrata:

   mkdir -p ${WORKDIR}/asm-ig/base
   
   cat <<EOF > ${WORKDIR}/asm-ig/base/kustomization.yaml
   resources:
     - github.com/GoogleCloudPlatform/anthos-service-mesh-samples/docs/ingress-gateway-asm-manifests/base
   EOF
   
   mkdir ${WORKDIR}/asm-ig/variant
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/role.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: asm-ingressgateway
     namespace: asm-ingress
   rules:
   - apiGroups: [""]
     resources: ["secrets"]
     verbs: ["get", "watch", "list"]
   EOF
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/rolebinding.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: asm-ingressgateway
     namespace: asm-ingress
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: asm-ingressgateway
   subjects:
     - kind: ServiceAccount
       name: asm-ingressgateway
   EOF
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/service-proto-type.yaml
   apiVersion: v1
   kind: Service
   metadata:
     name: asm-ingressgateway
     namespace: asm-ingress
   spec:
     ports:
     - name: status-port
       port: 15021
       protocol: TCP
       targetPort: 15021
     - name: http
       port: 80
       targetPort: 8080
       appProtocol: HTTP
     - name: https
       port: 443
       targetPort: 8443
       appProtocol: HTTP2
     type: ClusterIP
   EOF
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/gateway.yaml
   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     name: asm-ingressgateway
     namespace: asm-ingress
   spec:
    servers:
     - port:
         number: 443
         name: https
         protocol: HTTPS
       hosts:
       - "*" # IMPORTANT: Must use wildcard here when using SSL, as SNI isn't passed from GFE
       tls:
         mode: SIMPLE
         credentialName: edge2mesh-credential
   EOF
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/kustomization.yaml
   namespace: asm-ingress
   resources:
   - ../base
   - role.yaml
   - rolebinding.yaml
   patches:
   - path: service-proto-type.yaml
     target:
       kind: Service
   - path: gateway.yaml
     target:
       kind: Gateway
   EOF
   

6. Applica la configurazione del gateway in entrata a entrambi i cluster:

   kubectl --context ${CLUSTER_1_NAME} apply -k ${WORKDIR}/asm-ig/variant
   kubectl --context ${CLUSTER_2_NAME} apply -k ${WORKDIR}/asm-ig/variant
   

Esponi i pod del gateway in entrata al bilanciatore del carico utilizzando un servizio multi-cluster

In questa sezione esporterai i pod del gateway in entrata tramite un ServiceExport risorsa personalizzata. Devi esportare i pod del gateway in entrata tramite una risorsa personalizzata ServiceExport per i seguenti motivi:

• Consente al bilanciatore del carico di indirizzare i pod del gateway in entrata in più cluster.
• Consente ai pod del gateway in entrata di eseguire il proxy delle richieste ai servizi in esecuzione all'interno del mesh di servizi.

1. In Cloud Shell, abilita i servizi multi-cluster (MCS) per il parco risorse:

   gcloud container fleet multi-cluster-services enable
   

2. Concedi a MCS le autorizzazioni IAM richieste al progetto o al parco risorse:

   gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer]" \
    --role "roles/compute.networkViewer"
   

3. Crea il file YAML ServiceExport:

   cat <<EOF > ${WORKDIR}/svc_export.yaml
   kind: ServiceExport
   apiVersion: net.gke.io/v1
   metadata:
     name: asm-ingressgateway
     namespace: asm-ingress
   EOF
   

4. Applica il file YAML ServiceExport a entrambi i cluster:

   kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/svc_export.yaml
   kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/svc_export.yaml
   

   Se ricevi il seguente messaggio di errore, attendi qualche istante per le definizioni di risorse personalizzate (CRD) MCS da installare. Poi esegui nuovamente i comandi per applicare il file YAML ServiceExport a entrambi i cluster.

   error: resource mapping not found for name: "asm-ingressgateway" namespace: "asm-ingress" from "svc_export.yaml": no matches for kind "ServiceExport" in version "net.gke.io/v1"
   ensure CRDs are installed first
   

Crea risorse per indirizzi IP esterni, record DNS e certificati TLS

In questa sezione, creerai risorse di networking che supportano delle risorse di bilanciamento del carico create in un secondo momento in questo deployment.

1. In Cloud Shell, prenota un indirizzo IP esterno statico:

   gcloud compute addresses create mcg-ip --global
   

   Il gateway GKE utilizza un indirizzo IP statico risorsa. Questo permette all'indirizzo IP di rimanere invariato, anche se il carico esterno viene ricreato.

2. Ottieni l'indirizzo IP statico e archivialo come variabile di ambiente:

   export MCG_IP=$(gcloud compute addresses describe mcg-ip --global --format "value(address)")
   echo ${MCG_IP}
   

   Per creare una mappatura stabile e facile da usare all'indirizzo IP del gateway, devi avere un record DNS pubblico.

   Puoi utilizzare qualsiasi provider DNS e schema di automazione che preferisci. Questo Il deployment utilizza Endpoints invece di creare un DNS gestito zona di destinazione. Endpoints offre un servizio di DNS gestito da Google per un indirizzo IP esterno.

3. Esegui questo comando per creare un file YAML denominato dns-spec.yaml:

   cat <<EOF > ${WORKDIR}/dns-spec.yaml
   swagger: "2.0"
   info:
     description: "Cloud Endpoints DNS"
     title: "Cloud Endpoints DNS"
     version: "1.0.0"
   paths: {}
   host: "frontend.endpoints.PROJECT_ID.cloud.goog"
   x-google-endpoints:
   - name: "frontend.endpoints.PROJECT_ID.cloud.goog"
     target: "${MCG_IP}"
   EOF
   

   Il file dns-spec.yaml definisce il record DNS pubblico sotto forma di frontend.endpoints.PROJECT_ID.cloud.goog, dove PROJECT_ID è il tuo identificatore di progetto univoco.

4. Esegui il deployment del file dns-spec.yaml per creare la voce DNS. Questo processo richiede qualche minuto.

   gcloud endpoints services deploy ${WORKDIR}/dns-spec.yaml
   

5. Crea un utilizzando Certificate Manager per il nome della voce DNS che hai creato nel passaggio precedente:

   gcloud certificate-manager certificates create mcg-cert \
       --domains="frontend.endpoints.PROJECT_ID.cloud.goog"
   

   Un certificato TLS gestito da Google viene utilizzato per terminare il client in entrata richieste al bilanciatore del carico.

6. Crea un mappa certificati:

   gcloud certificate-manager maps create mcg-cert-map
   

   Il bilanciatore del carico fa riferimento al certificato tramite la mappa di certificati creata nel passaggio successivo.

7. Crea un voce della mappa dei certificati per il certificato che hai creato in precedenza in questa sezione:

   gcloud certificate-manager maps entries create mcg-cert-map-entry \
       --map="mcg-cert-map" \
       --certificates="mcg-cert" \
       --hostname="frontend.endpoints.PROJECT_ID.cloud.goog"
   

Crea criteri del servizio di backend e risorse del bilanciatore del carico

In questa sezione svolgerai le seguenti attività:

• Crea un criterio di sicurezza di Google Cloud Armor con regole.
• Crea un criterio che consenta al bilanciatore del carico di verificare la reattività dei i pod del gateway in entrata tramite il file YAML ServiceExport che hai creato in precedenza.
• Utilizza l'API GKE Gateway per creare un bilanciatore del carico risorsa.
• Utilizza la risorsa personalizzata GatewayClass per impostare il bilanciatore del carico specifico di testo.
• Abilita il bilanciamento del carico multi-cluster per il parco risorse e specifica uno dei dei cluster come di configurazione per il parco risorse.

1. In Cloud Shell, crea un criterio di sicurezza di Google Cloud Armor:

   gcloud compute security-policies create edge-fw-policy \
       --description "Block XSS attacks"
   

2. Crea una regola per il criterio di sicurezza:

   gcloud compute security-policies rules create 1000 \
       --security-policy edge-fw-policy \
       --expression "evaluatePreconfiguredExpr('xss-stable')" \
       --action "deny-403" \
       --description "XSS attack filtering"
   

3. Crea un file YAML per il criterio di sicurezza e fai riferimento al ServiceExport file YAML tramite un file YAML ServiceImport corrispondente:

   cat <<EOF > ${WORKDIR}/cloud-armor-backendpolicy.yaml
   apiVersion: networking.gke.io/v1
   kind: GCPBackendPolicy
   metadata:
     name: cloud-armor-backendpolicy
     namespace: asm-ingress
   spec:
     default:
       securityPolicy: edge-fw-policy
     targetRef:
       group: net.gke.io
       kind: ServiceImport
       name: asm-ingressgateway
   EOF
   

4. Applica il criterio Google Cloud Armor a entrambi i cluster:

   kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/cloud-armor-backendpolicy.yaml
   kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/cloud-armor-backendpolicy.yaml
   

5. Crea un file YAML personalizzato che consenta al bilanciatore del carico di eseguire l'integrità verifica rispetto all'endpoint di integrità di Envoy (porta 15021 sul percorso /healthz/ready) dei pod del gateway in entrata in entrambi i cluster:

   cat <<EOF > ${WORKDIR}/ingress-gateway-healthcheck.yaml
   apiVersion: networking.gke.io/v1
   kind: HealthCheckPolicy
   metadata:
     name: ingress-gateway-healthcheck
     namespace: asm-ingress
   spec:
     default:
       config:
         httpHealthCheck:
           port: 15021
           portSpecification: USE_FIXED_PORT
           requestPath: /healthz/ready
         type: HTTP
     targetRef:
       group: net.gke.io
       kind: ServiceImport
       name: asm-ingressgateway
   EOF
   

6. Applica il file YAML personalizzato che hai creato nel passaggio precedente a entrambi cluster:

   kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/ingress-gateway-healthcheck.yaml
   kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/ingress-gateway-healthcheck.yaml
   

7. Abilita il bilanciamento del carico multi-cluster per il parco risorse e specifica CLUSTER_1_NAME come cluster di configurazione:

   gcloud container fleet ingress enable \
     --config-membership=${CLUSTER_1_NAME} \
     --location=${CLUSTER_1_REGION}
   

8. Concedi le autorizzazioni IAM per il controller gateway nel parco risorse:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member "serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-multiclusteringress.iam.gserviceaccount.com" \
       --role "roles/container.admin"
   

9. Crea il file YAML del bilanciatore del carico tramite una risorsa personalizzata del gateway che fa riferimento a gke-l7-global-external-managed-mc gatewayClass e l'indirizzo IP statico che hai creato in precedenza:

   cat <<EOF > ${WORKDIR}/frontend-gateway.yaml
   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
     namespace: asm-ingress
     annotations:
       networking.gke.io/certmap: mcg-cert-map
   spec:
     gatewayClassName: gke-l7-global-external-managed-mc
     listeners:
     - name: http # list the port only so we can redirect any incoming http requests to https
       protocol: HTTP
       port: 80
     - name: https
       protocol: HTTPS
       port: 443
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
     addresses:
     - type: NamedAddress
       value: mcg-ip
   EOF
   

10. Applica il file YAML frontend-gateway a entrambi i cluster. Solo CLUSTER_1_NAME è autorevole, a meno che non specifichi una di configurazione di Compute Engine come autorevole:

    kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/frontend-gateway.yaml
    kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/frontend-gateway.yaml
    

11. Crea un file YAML HTTPRoute denominato default-httproute.yaml che indica alla risorsa Gateway di inviare richieste ai gateway in entrata:

    cat << EOF > ${WORKDIR}/default-httproute.yaml
    apiVersion: gateway.networking.k8s.io/v1beta1
    kind: HTTPRoute
    metadata:
      name: default-httproute
      namespace: asm-ingress
    spec:
      parentRefs:
      - name: external-http
        namespace: asm-ingress
        sectionName: https
      rules:
      - backendRefs:
        - group: net.gke.io
          kind: ServiceImport
          name: asm-ingressgateway
          port: 443
    EOF
    

12. Applica il file YAML HTTPRoute che hai creato nel passaggio precedente a in entrambi i cluster:

    kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/default-httproute.yaml
    kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/default-httproute.yaml
    

13. Per eseguire reindirizzamenti da HTTP a HTTP(S), crea un elemento HTTPRoute aggiuntivo File YAML denominato default-httproute-redirect.yaml:

    cat << EOF > ${WORKDIR}/default-httproute-redirect.yaml
    kind: HTTPRoute
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
      name: http-to-https-redirect-httproute
      namespace: asm-ingress
    spec:
      parentRefs:
      - name: external-http
        namespace: asm-ingress
        sectionName: http
      rules:
      - filters:
        - type: RequestRedirect
          requestRedirect:
            scheme: https
            statusCode: 301
    EOF
    

14. Applica il file YAML HTTPRoute di reindirizzamento a entrambi i cluster:

    kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/default-httproute-redirect.yaml
    kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/default-httproute-redirect.yaml
    

15. Esamina la risorsa gateway per verificare l'avanzamento del bilanciatore del carico deployment:

    kubectl --context=${CLUSTER_1_NAME} describe gateway external-http -n asm-ingress
    

    L'output mostra le informazioni inserite in questa sezione.

Esegui il deployment dell'applicazione di esempio whereami

Questa guida utilizza dove come applicazione di esempio per fornire un feedback diretto su quali cluster rispondendo alle richieste. La sezione seguente configura due deployment separati in cui in entrambi i cluster: un deployment frontend e un backend e deployment continuo.

Il deployment frontend è il primo carico di lavoro a ricevere la richiesta. Poi chiama il deployment backend.

Questo modello viene utilizzato per dimostrare un'architettura di applicazioni multiservizio. Viene eseguito il deployment di entrambi i servizi frontend e backend in entrambi i cluster.

1. In Cloud Shell, crea gli spazi dei nomi per frontend e backend in entrambi i cluster e abilita inserimento dello spazio dei nomi:

   kubectl --context=${CLUSTER_1_NAME} create ns frontend
   kubectl --context=${CLUSTER_1_NAME} label namespace frontend istio-injection=enabled
   kubectl --context=${CLUSTER_1_NAME} create ns backend
   kubectl --context=${CLUSTER_1_NAME} label namespace backend istio-injection=enabled
   kubectl --context=${CLUSTER_2_NAME} create ns frontend
   kubectl --context=${CLUSTER_2_NAME} label namespace frontend istio-injection=enabled
   kubectl --context=${CLUSTER_2_NAME} create ns backend
   kubectl --context=${CLUSTER_2_NAME} label namespace backend istio-injection=enabled
   

2. Crea una variante kustomize per il luogo backend:

   mkdir -p ${WORKDIR}/whereami-backend/base
   
   cat <<EOF > ${WORKDIR}/whereami-backend/base/kustomization.yaml
   resources:
     - github.com/GoogleCloudPlatform/kubernetes-engine-samples/quickstarts/whereami/k8s
   EOF
   
   mkdir ${WORKDIR}/whereami-backend/variant
   
   cat <<EOF > ${WORKDIR}/whereami-backend/variant/cm-flag.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: whereami
   data:
     BACKEND_ENABLED: "False" # assuming you don't want a chain of backend calls
     METADATA:        "backend"
   EOF
   
   cat <<EOF > ${WORKDIR}/whereami-backend/variant/service-type.yaml
   apiVersion: "v1"
   kind: "Service"
   metadata:
     name: "whereami"
   spec:
     type: ClusterIP
   EOF
   
   cat <<EOF > ${WORKDIR}/whereami-backend/variant/kustomization.yaml
   nameSuffix: "-backend"
   namespace: backend
   commonLabels:
     app: whereami-backend
   resources:
   - ../base
   patches:
   - path: cm-flag.yaml
     target:
       kind: ConfigMap
   - path: service-type.yaml
     target:
       kind: Service
   EOF
   

3. Applica la variante "dove" backend" a entrambi i cluster:

   kubectl --context=${CLUSTER_1_NAME} apply -k ${WORKDIR}/whereami-backend/variant
   kubectl --context=${CLUSTER_2_NAME} apply -k ${WORKDIR}/whereami-backend/variant
   

4. Crea una variante kustomize per il luogo frontend:

   mkdir -p ${WORKDIR}/whereami-frontend/base
   
   cat <<EOF > ${WORKDIR}/whereami-frontend/base/kustomization.yaml
   resources:
     - github.com/GoogleCloudPlatform/kubernetes-engine-samples/quickstarts/whereami/k8s
   EOF
   
   mkdir whereami-frontend/variant
   
   cat <<EOF > ${WORKDIR}/whereami-frontend/variant/cm-flag.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: whereami
   data:
     BACKEND_ENABLED: "True"
     BACKEND_SERVICE: "http://whereami-backend.backend.svc.cluster.local"
   EOF
   
   cat <<EOF > ${WORKDIR}/whereami-frontend/variant/service-type.yaml
   apiVersion: "v1"
   kind: "Service"
   metadata:
     name: "whereami"
   spec:
     type: ClusterIP
   EOF
   
   cat <<EOF > ${WORKDIR}/whereami-frontend/variant/kustomization.yaml
   nameSuffix: "-frontend"
   namespace: frontend
   commonLabels:
     app: whereami-frontend
   resources:
   - ../base
   patches:
    path: cm-flag.yaml
     target:
       kind: ConfigMap
   - path: service-type.yaml
     target:
       kind: Service
   EOF
   

5. Applica la variante "dove" frontend" a entrambi i cluster:

   kubectl --context=${CLUSTER_1_NAME} apply -k ${WORKDIR}/whereami-frontend/variant
   kubectl --context=${CLUSTER_2_NAME} apply -k ${WORKDIR}/whereami-frontend/variant
   

6. Crea un VirtualService File YAML per instradare le richieste alla posizione frontend:

   cat << EOF > ${WORKDIR}/frontend-vs.yaml
   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: whereami-vs
     namespace: frontend
   spec:
     gateways:
     - asm-ingress/asm-ingressgateway
     hosts:
     - 'frontend.endpoints.PROJECT_ID.cloud.goog'
     http:
     - route:
       - destination:
           host: whereami-frontend
           port:
             number: 80
   EOF
   

7. Applica il file YAML frontend-vs a entrambi i cluster:

   kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/frontend-vs.yaml
   kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/frontend-vs.yaml
   

8. Ora che hai eseguito il deployment di frontend-vs.yaml in entrambi i cluster, prova per chiamare l'endpoint pubblico per i tuoi cluster:

   curl -s https://frontend.endpoints.PROJECT_ID.cloud.goog | jq
   

   L'output è simile al seguente:

   {
     "backend_result": {
       "cluster_name": "edge-to-mesh-02",
       "gce_instance_id": "8396338201253702608",
       "gce_service_account": "e2m-mcg-01.svc.id.goog",
       "host_header": "whereami-backend.backend.svc.cluster.local",
       "metadata": "backend",
       "node_name": "gk3-edge-to-mesh-02-pool-2-675f6abf-645h",
       "pod_ip": "10.124.0.199",
       "pod_name": "whereami-backend-7cbdfd788-8mmnq",
       "pod_name_emoji": "📸",
       "pod_namespace": "backend",
       "pod_service_account": "whereami-backend",
       "project_id": "e2m-mcg-01",
       "timestamp": "2023-12-01T03:46:24",
       "zone": "us-east4-b"
     },
     "cluster_name": "edge-to-mesh-01",
     "gce_instance_id": "1047264075324910451",
     "gce_service_account": "e2m-mcg-01.svc.id.goog",
     "host_header": "frontend.endpoints.e2m-mcg-01.cloud.goog",
     "metadata": "frontend",
     "node_name": "gk3-edge-to-mesh-01-pool-2-d687e3c0-5kf2",
     "pod_ip": "10.54.1.71",
     "pod_name": "whereami-frontend-69c4c867cb-dgg8t",
     "pod_name_emoji": "🪴",
     "pod_namespace": "frontend",
     "pod_service_account": "whereami-frontend",
     "project_id": "e2m-mcg-01",
     "timestamp": "2023-12-01T03:46:24",
     "zone": "us-central1-c"
   }
   

Nota: il provisioning del certificato richiede circa 20 minuti. Se non ricevi risposta, usa il flag -v nel comando curl in questo passaggio per verificare se sono correlati a errori TLS.

Se esegui il comando curl alcune volte, vedrai che le risposte (entrambe da frontend e backend) provengono da regioni diverse. Nella sua risposta, il bilanciatore del carico fornisce il geo-routing. Ciò significa il bilanciatore del carico instrada le richieste dal client al cluster attivo più vicino, ma le richieste arrivano comunque a caso. Quando occasionalmente le richieste da una regione all'altra, aumenta latenza e costi.

Nella sezione successiva implementerai il bilanciamento del carico per località nel mesh di servizi per mantenere le richieste locali.

Abilita e testa il bilanciamento del carico delle località per dove

In questa sezione implementerai bilanciamento del carico delle località nel mesh di servizi per mantenere le richieste locali. Esegui anche alcuni test per vedere il modo in cui doveami gestisce i vari scenari di errore.

Quando effettui una richiesta al servizio whereami frontend, il bilanciatore del carico invia la richiesta al cluster con la latenza più bassa rispetto di alto profilo. Ciò significa che i pod del gateway in entrata all'interno del carico della rete mesh bilanciare le richieste a cui frontend pod in entrambi i cluster. Questa sezione per risolvere il problema abilitando il bilanciamento del carico per le località all'interno della rete mesh.

Nota: gli esempi DestinationRule nella sezione seguente impostano un valore per il failover a livello di regione e un valore artificiosamente basso. Quando adatti questi campioni per i tuoi scopi, testa a fondo per verificare di aver trovato i valore più appropriato per le tue esigenze.

1. In Cloud Shell, crea un'istanza DestinationRule File YAML che consente il failover a livello di regione del bilanciamento del carico per le località Servizio frontend:

   cat << EOF > ${WORKDIR}/frontend-dr.yaml
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: frontend
     namespace: frontend
   spec:
     host: whereami-frontend.frontend.svc.cluster.local
     trafficPolicy:
       connectionPool:
         http:
           maxRequestsPerConnection: 0
       loadBalancer:
         simple: LEAST_REQUEST
         localityLbSetting:
           enabled: true
       outlierDetection:
         consecutive5xxErrors: 1
         interval: 1s
         baseEjectionTime: 1m
   EOF
   

   L'esempio di codice precedente abilita il routing locale solo per frontend completamente gestito di Google Cloud. È necessaria anche una configurazione aggiuntiva che gestisca il backend.

2. Applica il file YAML frontend-dr a entrambi i cluster:

   kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/frontend-dr.yaml
   kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/frontend-dr.yaml
   

3. Crea un file YAML DestinationRule che consenta il caricamento delle località Bilancia il failover a livello di regione al servizio backend:

   cat << EOF > ${WORKDIR}/backend-dr.yaml
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
   n    ame: backend
     namespace: backend
   spec:
     host: whereami-backend.backend.svc.cluster.local
     trafficPolicy:
       connectionPool:
         http:
           maxRequestsPerConnection: 0
       loadBalancer:
         simple: LEAST_REQUEST
         localityLbSetting:
           enabled: true
       outlierDetection:
         consecutive5xxErrors: 1
         interval: 1s
         baseEjectionTime: 1m
   EOF
   

4. Applica il file YAML backend-dr a entrambi i cluster:

   kubectl --context=${CLUSTER_1_NAME} apply -f ${WORKDIR}/backend-dr.yaml
   kubectl --context=${CLUSTER_2_NAME} apply -f ${WORKDIR}/backend-dr.yaml
   

   Dopo aver applicato entrambi i set di file YAML DestinationRule a entrambi i cluster, rimangono locali nel cluster a cui viene instradata la richiesta.

   Per testare il failover per il servizio frontend, riduci il numero di di repliche per il gateway in entrata nel cluster principale.

   Dal punto di vista del bilanciatore del carico multiregionale, questa azione simula un errore del cluster. provoca un errore di caricamento del cluster di integrità dei bilanciatori del carico. Questo esempio utilizza il cluster in CLUSTER_1_REGION. Dovresti vedere solo le risposte del cluster in CLUSTER_2_REGION.

5. Riduci il numero di repliche per il gateway in entrata nella tua istanza principale il cluster su zero e chiamare l'endpoint pubblico per verificare che le richieste non siano riuscite nell'altro cluster:

   kubectl --context=${CLUSTER_1_NAME} -n asm-ingress scale --replicas=0 deployment/asm-ingressgateway
   

   Nota: sebbene sia presente una HorizontalPodAutoscaler configurato con minReplicas:3 per il deployment asm-ingressgateway, la scalabilità è temporaneamente disattivata quando il numero di repliche del deployment impostato su 0. Per ulteriori informazioni, vedi Scalabilità automatica orizzontale dei pod - Disattivazione implicita in modalità di manutenzione.

   L'output dovrebbe essere simile al seguente:

   $ curl -s https://frontend.endpoints.PROJECT_ID.cloud.goog | jq
   {
     "backend_result": {
       "cluster_name": "edge-to-mesh-02",
       "gce_instance_id": "2717459599837162415",
       "gce_service_account": "e2m-mcg-01.svc.id.goog",
       "host_header": "whereami-backend.backend.svc.cluster.local",
       "metadata": "backend",
       "node_name": "gk3-edge-to-mesh-02-pool-2-675f6abf-dxs2",
       "pod_ip": "10.124.1.7",
       "pod_name": "whereami-backend-7cbdfd788-mp8zv",
       "pod_name_emoji": "🏌🏽‍♀",
       "pod_namespace": "backend",
       "pod_service_account": "whereami-backend",
       "project_id": "e2m-mcg-01",
       "timestamp": "2023-12-01T05:41:18",
       "zone": "us-east4-b"
     },
     "cluster_name": "edge-to-mesh-02",
     "gce_instance_id": "6983018919754001204",
     "gce_service_account": "e2m-mcg-01.svc.id.goog",
     "host_header": "frontend.endpoints.e2m-mcg-01.cloud.goog",
     "metadata": "frontend",
     "node_name": "gk3-edge-to-mesh-02-pool-3-d42ddfbf-qmkn",
     "pod_ip": "10.124.1.142",
     "pod_name": "whereami-frontend-69c4c867cb-xf8db",
     "pod_name_emoji": "🏴",
     "pod_namespace": "frontend",
     "pod_service_account": "whereami-frontend",
     "project_id": "e2m-mcg-01",
     "timestamp": "2023-12-01T05:41:18",
     "zone": "us-east4-b"
   }
   

6. Per riprendere il routing del traffico tipico, ripristina le repliche del gateway in entrata al valore originale nel cluster:

   kubectl --context=${CLUSTER_1_NAME} -n asm-ingress scale --replicas=3 deployment/asm-ingressgateway
   

7. Simula un errore per il servizio backend, riducendo il numero di di repliche nella regione principale a 0:

   kubectl --context=${CLUSTER_1_NAME} -n backend scale --replicas=0 deployment/whereami-backend
   

   Verifica che le risposte del servizio frontend provengano dal us-central1 regione principale tramite il bilanciatore del carico e le risposte del servizio backend provengono dalla regione secondaria us-east4.

   L'output deve includere anche una risposta per il servizio frontend da la regione principale (us-central1) e una risposta per il servizio backend dalla regione secondaria (us-east4), come previsto.

8. Ripristina il valore originale delle repliche del servizio di backend per riprendere tipico routing del traffico:

   kubectl --context=${CLUSTER_1_NAME} -n backend scale --replicas=3 deployment/whereami-backend
   

Ora hai un bilanciatore del carico HTTP(S) globale che funge da frontend un'applicazione multiregionale ospitata su una rete mesh di servizi.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse usati in questo deployment, elimina il progetto che contiene le risorse o mantenere il progetto ed eliminare le singole risorse.

Elimina il progetto

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à in questo documento, quando lo elimini elimini anche qualsiasi altro 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 URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

   Vai a Gestisci risorse

2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Elimina le singole risorse

Se vuoi mantenere il progetto Google Cloud utilizzato in questo deployment, elimina le singole risorse:

1. In Cloud Shell, elimina le risorse HTTPRoute:

   kubectl --context=${CLUSTER_1_NAME} delete -f ${WORKDIR}/default-httproute-redirect.yaml
   kubectl --context=${CLUSTER_2_NAME} delete -f ${WORKDIR}/default-httproute-redirect.yaml
   kubectl --context=${CLUSTER_1_NAME} delete -f ${WORKDIR}/default-httproute.yaml
   kubectl --context=${CLUSTER_2_NAME} delete -f ${WORKDIR}/default-httproute.yaml
   

2. Elimina le risorse del gateway GKE:

   kubectl --context=${CLUSTER_1_NAME} delete -f ${WORKDIR}/frontend-gateway.yaml
   kubectl --context=${CLUSTER_2_NAME} delete -f ${WORKDIR}/frontend-gateway.yaml
   

3. Elimina i criteri:

   kubectl --context=${CLUSTER_1_NAME} delete -f ${WORKDIR}/ingress-gateway-healthcheck.yaml
   kubectl --context=${CLUSTER_2_NAME} delete -f ${WORKDIR}/ingress-gateway-healthcheck.yaml
   kubectl --context=${CLUSTER_1_NAME} delete -f ${WORKDIR}/cloud-armor-backendpolicy.yaml
   kubectl --context=${CLUSTER_2_NAME} delete -f ${WORKDIR}/cloud-armor-backendpolicy.yaml
   

4. Elimina le esportazioni dei servizi:

   kubectl --context=${CLUSTER_1_NAME} delete -f ${WORKDIR}/svc_export.yaml
   kubectl --context=${CLUSTER_2_NAME} delete -f ${WORKDIR}/svc_export.yaml
   

5. Elimina le risorse Google Cloud Armor:

   gcloud --project=PROJECT_ID compute security-policies rules delete 1000 --security-policy edge-fw-policy --quiet
   gcloud --project=PROJECT_ID compute security-policies delete edge-fw-policy --quiet
   

6. Elimina le risorse del Gestore certificati:

   gcloud --project=PROJECT_ID certificate-manager maps entries delete mcg-cert-map-entry --map="mcg-cert-map" --quiet
   gcloud --project=PROJECT_ID certificate-manager maps delete mcg-cert-map --quiet
   gcloud --project=PROJECT_ID certificate-manager certificates delete mcg-cert --quiet
   

7. Elimina la voce DNS Endpoints:

   gcloud --project=PROJECT_ID endpoints services delete "frontend.endpoints.PROJECT_ID.cloud.goog" --quiet
   

8. Elimina l'indirizzo IP statico:

   gcloud --project=PROJECT_ID compute addresses delete mcg-ip --global --quiet
   

9. Elimina i cluster GKE Autopilot. Questo passaggio richiede diversi minuti.

   gcloud --project=PROJECT_ID container clusters delete ${CLUSTER_1_NAME} --region ${CLUSTER_1_REGION} --quiet
   gcloud --project=PROJECT_ID container clusters delete ${CLUSTER_2_NAME} --region ${CLUSTER_2_REGION} --quiet
   

Passaggi successivi

• Informazioni su più funzionalità offerte dal gateway GKE che puoi utilizzare con il tuo mesh di servizi.
• Informazioni su i diversi tipi di Cloud Load Balancing disponibili per GKE.
• Informazioni su le caratteristiche e le funzioni offerte da Cloud Service Mesh.
• Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.

Collaboratori

Autori:

• Andrea Rossi | Ingegnere specializzato in applicazioni
• Mark Chilvers | Ingegnere specializzato in applicazioni

Altri collaboratori:

• Abdelfettah Sghiouar | Consulente per gli sviluppatori cloud
• Greg Bray | Customer Engineer
• Paul Revello | Cloud Solutions Architect
• Valavan Rajakumar | Key Enterprise Architect