Configurare i pod di Google Kubernetes Engine utilizzando l'inserimento automatico di Envoy

Panoramica

Nota: questa guida supporta Cloud Service Mesh solo con le API Google Cloud e non supporta le API Istio. Per ulteriori informazioni, vedi Panoramica di Cloud Service Mesh.

In un mesh di servizi, non è necessario che il codice dell'applicazione configurazione di rete. Le applicazioni comunicano invece su una rete dati configurato da un piano di controllo che gestisce il networking di servizi. In questa guida, Cloud Service Mesh è il tuo piano di controllo e il file collaterale di Envoy sono il tuo piano dati.

L'iniettore di sidecar Envoy semplifica l'aggiunta del sidecar Envoy ai tuoi pod di Google Kubernetes Engine. Quando l'iniettore di sidecar di Envoy aggiunge un proxy, oltre a configurare il proxy in modo che gestisca il traffico dell'applicazione e si connetta Cloud Service Mesh per la configurazione.

La guida ti accompagna attraverso una semplice configurazione di Cloud Service Mesh con Google Kubernetes Engine. Questi passaggi forniscono le basi che puoi estendere alle applicazioni casi d'uso, come un mesh di servizi che si estende su più Google Kubernetes Engine cluster e, potenzialmente, VM di Compute Engine. Puoi anche seguire queste istruzioni se configuri Cloud Service Mesh con un VPC condiviso.

La procedura di configurazione prevede:

1. Creazione di un cluster GKE per i carichi di lavoro.
2. Installazione dell'iniettore del sidecar Envoy e attivazione dell'iniezione in corso.
3. Deployment di un client di esempio e verifica dell'inserimento.
4. Deployment di un servizio Kubernetes per i test.
5. Configurazione di Cloud Service Mesh con Cloud Load Balancing per instradare il traffico al servizio di test.
6. Verifica la configurazione inviando una richiesta dal client di esempio a il servizio di test.

.

Panoramica dei componenti di cui è stato eseguito il deployment nell'ambito di questa guida alla configurazione (fai clic per ingrandire)

Prerequisiti

Prima di seguire le istruzioni di questa guida, consulta Preparazione per la configurazione di Cloud Service Mesh e di aver completato le attività preliminari descritte nel documento.

Per informazioni sulla versione di Envoy supportata, consulta il Note di rilascio di Cloud Service Mesh.

Nota: l'injector del sidecar e il proxy inserito si basano sul sidecar di Istio iniettore. Non installare l'iniettore sidecar di Envoy se hai già eseguito il deployment Istio per il tuo cluster GKE perché ciò potrebbe causare conflitti iniezione di codice.

Prerequisiti aggiuntivi con il VPC condiviso

Se configuri Cloud Service Mesh in un ambiente VPC condiviso, verifica quanto segue.

• Disponi delle autorizzazioni e dei ruoli corretti per il VPC condiviso.
• Hai configurato i progetti e la fatturazione corretti.
• Hai abilitato la fatturazione nei progetti.
• Hai abilitato le API Cloud Service Mesh e GKE in ciascun progetto host, anche il progetto host.
• Avere configurato gli account di servizio corretti per ogni progetto.
• Hai creato una rete VPC e delle subnet.
• Hai abilitato il VPC condiviso.

Per maggiori informazioni, vedi VPC condiviso.

Configura i ruoli IAM

Questo esempio di configurazione del ruolo IAM presuppone che l'host per il VPC condiviso ha due subnet e sono presenti in altri progetti nel VPC condiviso.

1. In Cloud Shell, crea una cartella di lavoro (WORKDIR) in cui crea i file associati a questa sezione:

   mkdir -p ~/td-shared-vpc
   cd ~/td-shared-vpc
   export WORKDIR=$(pwd)
   

2. Configura le autorizzazioni IAM nel progetto host in modo che il servizio i progetti possono utilizzare le risorse nel VPC condiviso.

   In questo passaggio, configurerai le autorizzazioni IAM in modo che subnet-1 è accessibile dal progetto di servizio 1, mentre subnet-2 è accessibile in base al progetto di servizio 2. Devi assegnare Ruolo IAM Utente di rete Compute (roles/compute.networkUser) alle interfacce di Compute Engine l'account di servizio predefinito e l'account di servizio API Google Cloud ogni progetto di servizio per ogni subnet.

   1. Per il progetto di servizio 1, configura le autorizzazioni IAM per subnet-1:

      export SUBNET_1_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-1 --project ${HOST_PROJECT} --region ${REGION_1} --format=json | jq -r '.etag')
      
      cat > subnet-1-policy.yaml <<EOF
      bindings:
      - members:
        - serviceAccount:${SVC_PROJECT_1_API_SA}
        - serviceAccount:${SVC_PROJECT_1_GKE_SA}
        role: roles/compute.networkUser
      etag: ${SUBNET_1_ETAG}
      EOF
      
      gcloud beta compute networks subnets set-iam-policy subnet-1 \
      subnet-1-policy.yaml \
          --project ${HOST_PROJECT} \
          --region ${REGION_1}
      

   2. Per il progetto di servizio 2, configura le autorizzazioni IAM per subnet-2:

      export SUBNET_2_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-2 --project ${HOST_PROJECT} --region ${REGION_2} --format=json | jq -r '.etag')
      
      cat > subnet-2-policy.yaml <<EOF
      bindings:
      - members:
        - serviceAccount:${SVC_PROJECT_2_API_SA}
        - serviceAccount:${SVC_PROJECT_2_GKE_SA}
        role: roles/compute.networkUser
      etag: ${SUBNET_2_ETAG}
      EOF
      
      gcloud beta compute networks subnets set-iam-policy subnet-2 \
      subnet-2-policy.yaml \
          --project ${HOST_PROJECT} \
          --region ${REGION_2}
      

3. Per ogni progetto di servizio, devi concedere Ruolo IAM Utente agente di servizio host Kubernetes Engine (roles/container.hostServiceAgentUser) a GKE nel progetto host:

   gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
       --member serviceAccount:${SVC_PROJECT_1_GKE_SA} \
       --role roles/container.hostServiceAgentUser
   
   gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
       --member serviceAccount:${SVC_PROJECT_2_GKE_SA} \
       --role roles/container.hostServiceAgentUser
   

   Questo ruolo consente all'account di servizio GKE del servizio utilizza l'account di servizio GKE del progetto host per configurare le risorse di rete condivise.

4. Per ogni progetto di servizio, concedi il servizio predefinito di Compute Engine account il Ruolo IAM Visualizzatore di rete Compute (roles/compute.networkViewer) nel progetto host.

   gcloud projects add-iam-policy-binding ${SVC_PROJECT_1} \
       --member serviceAccount:${SVC_PROJECT_1_COMPUTE_SA} \
       --role roles/compute.networkViewer
   
   gcloud projects add-iam-policy-binding ${SVC_PROJECT_2} \
       --member serviceAccount:${SVC_PROJECT_2_COMPUTE_SA} \
       --role roles/compute.networkViewer
   

   Quando il proxy sidecar di Envoy si connette al server xDS (API Traffic Director), il proxy utilizza l'account di servizio del dell'host della macchina virtuale (VM) Compute Engine del nodo GKE. L'account di servizio deve avere IAM a livello di progetto compute.globalForwardingRules.get autorizzazione. Il ruolo Visualizzatore di rete Compute è sufficiente per questo passaggio.

Creazione di un cluster GKE per i carichi di lavoro

I cluster GKE devono soddisfare i seguenti requisiti per supportare Cloud Service Mesh:

• Il supporto dei gruppi di endpoint di rete deve essere abilitato. Per ulteriori informazioni ed esempi, consulta Gruppi di endpoint di rete autonomi.
• L'account di servizio per i nodi/pod GKE deve disporre dell'autorizzazione per accede all'API Cloud Service Mesh. Per ulteriori informazioni sui autorizzazioni, fai riferimento Abilitare l'account di servizio per accedere all'API Cloud Service Mesh.

Creazione del cluster GKE

Crea un cluster GKE denominato traffic-director-cluster nella tua zona preferita, ad esempio us-central1-a.

gcloud container clusters create traffic-director-cluster \
  --zone ZONE \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

Puntare kubectl al cluster appena creato

Cambia il contesto attuale per kubectl nel cluster appena creato inviando il seguente comando:

gcloud container clusters get-credentials traffic-director-cluster \
    --zone ZONE

Installazione dell'iniettore del sidecar Envoy

Le sezioni seguenti forniscono istruzioni per l'installazione del file collaterale di Envoy iniettore. Quando l'injector collaterale è abilitato, esegue automaticamente il deployment del file collaterale per i carichi di lavoro nuovi ed esistenti di Google Kubernetes Engine. Dato che Envoy injector viene eseguito all'interno del cluster GKE, devi installarlo una volta in ogni cluster se utilizzi Cloud Service Mesh per supportare un cluster multi-cluster mesh di servizi.

Download dell'iniettore collaterale in corso...

Scarica ed estrai l'iniettore del sidecar di Envoy.

wget https://storage.googleapis.com/traffic-director/td-sidecar-injector-xdsv3.tgz
tar -xzvf td-sidecar-injector-xdsv3.tgz
cd td-sidecar-injector-xdsv3

Configurazione dell'iniettore collaterale

Se utilizzi le API precedenti, configura l'iniettore collaterale modificando il file specs/01-configmap.yaml per:

• Compila TRAFFICDIRECTOR_GCP_PROJECT_NUMBER sostituendo YOUR_PROJECT_NUMBER_HERE con il numero del progetto. La il numero di progetto è un identificatore numerico del progetto. Per informazioni su come ottenere un elenco di tutti i tuoi progetti, consulta Identificazione dei progetti.
• Compila TRAFFICDIRECTOR_NETWORK_NAME sostituendo YOUR_NETWORK_NAME_HERE con il nome della rete Virtual Private Cloud di Google Cloud che vuoi utilizzare Cloud Service Mesh. Prendi nota del nome di questa rete VPC, perché ne avrai bisogno in seguito, durante la configurazione di Cloud Service Mesh.

Se utilizzi le nuove API di routing dei servizi, che sono attualmente in anteprima:

• Compila TRAFFICDIRECTOR_MESH_NAME sostituendo "" con il nome mesh di servizi, per ottenere la configurazione di un mesh di servizi.
  • Tieni presente che se stai configurando un Gateway, non utilizzare il file collaterale iniettore. Esegui il deployment di un proxy Envoy come pod.

Ad esempio, il file potrebbe avere il seguente aspetto:

$ cat specs/01-configmap.yaml

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: injector-mesh
     namespace: istio-control
   data:
     mesh: |-
       defaultConfig:
         discoveryAddress: trafficdirector.googleapis.com:443

         # Envoy proxy port to listen on for the admin interface.
         proxyAdminPort: 15000

         proxyMetadata:
           # Google Cloud Project number where Cloud Service Mesh resources are configured.
           # This is a numeric identifier of your project (e.g. "111222333444").
           # You can get a list of all your projects with their corresponding numbers by
           # using "gcloud projects list" command or looking it up under "Project info"
           # section of your Google Cloud console.
           # If left empty, configuration will be attempted to be fetched for the Google Cloud
           # project associated with service credentials.
           # Leaving empty is not recommended as it is not guaranteed to work in future
           # releases.
           TRAFFICDIRECTOR_GCP_PROJECT_NUMBER: "YOUR_PROJECT_NUMBER_HERE"

           # Google Cloud VPC network name for which the configuration is requested (This is the VPC
           # network name referenced in the forwarding rule in Google Cloud API). If left empty,
           # configuration will be attempted to be fetched for the VPC network over which
           # the request to Cloud Service Mesh (trafficdirector.googleapis.com) is sent out.
           # Leaving empty is not recommended as it is not guaranteed to work in future
           # releases.
           TRAFFICDIRECTOR_NETWORK_NAME: "default"

Nota: se disponi di una configurazione di un VPC condiviso, sostituisci TRAFFICDIRECTOR_NETWORK_NAME con il nome della rete configurata il progetto host.

Facoltativamente, puoi anche abilitare il logging e il tracciamento per ciascun proxy viene inserito automaticamente. Per ulteriori informazioni su queste configurazioni, consulta Configurazione di attributi aggiuntivi per i proxy sidecar. Quando utilizzi l'iniettore collaterale, il valore TRAFFICDIRECTOR_ACCESS_LOG_PATH può essere impostato solo su un file nella directory /etc/envoy/. Ad esempio: la directory /etc/envoy/access.log è una posizione valida.

Tieni presente che TRAFFICDIRECTOR_INTERCEPTION_PORT non deve essere configurato in questa ConfigMap, perché è già configurato dall'iniettore collaterale.

Configurazione di TLS per l'iniettore sidecar

Questa sezione mostra come configurare TLS per l'iniettore collaterale.

L'iniettore collaterale utilizza un'ammissione mutante di Kubernetes webhook per inserire i proxy quando vengono è stato creato. Questo webhook è un endpoint HTTPS, quindi devi fornire una chiave per TLS.

Puoi creare una chiave privata e un certificato autofirmato utilizzando openssl per fissare l'iniettore del sidecar.

Facoltativamente, se hai la tua chiave privata e un certificato firmato da un l'autorità di certificazione (CA) puoi saltare questo passaggio successivo.

CN=istio-sidecar-injector.istio-control.svc

openssl req \
  -x509 \
  -newkey rsa:4096 \
  -keyout key.pem \
  -out cert.pem \
  -days 365 \
  -nodes \
  -subj "/CN=${CN}" \
  -addext "subjectAltName=DNS:${CN}"

cp cert.pem ca-cert.pem

Questo comando openssl di esempio restituisce una chiave RSA a 4096 bit di esempio in key.pem e un certificato autofirmato in formato X.509 in cert.pem. Poiché il certificato è autofirmato, il certificato viene copiato in ca-cert.pem e considerata anche il certificato della CA di firma. Il certificato rimane è valido per 365 giorni e non richiede una passphrase. Per ulteriori informazioni per la creazione e la firma dei certificati, consulta la documentazione di Kubernetes Richieste di firma del certificato.

I passaggi in questa sezione devono essere ripetuti ogni anno per rigenerare e riapplicare le nuove chiavi e i nuovi certificati prima che scadano.

Dopo aver ottenuto la chiave e i certificati, devi creare un secret Kubernetes e aggiorna il webhook dell'iniettore collaterale.

1. Crea lo spazio dei nomi in cui deve essere creato il secret Kubernetes:

   kubectl apply -f specs/00-namespaces.yaml
   

2. Crea il secret per l'iniettore collaterale.

   kubectl create secret generic istio-sidecar-injector -n istio-control \
     --from-file=key.pem \
     --from-file=cert.pem \
     --from-file=ca-cert.pem
   

3. Modifica caBundle del webhook di inserimento del file collaterale denominato istio-sidecar-injector-istio-control a specs/02-injector.yaml:

   CA_BUNDLE=$(cat cert.pem | base64 | tr -d '\n')
   sed -i "s/caBundle:.*/caBundle:\ ${CA_BUNDLE}/g" specs/02-injector.yaml
   

Installazione dell'injector collaterale nel cluster GKE

1. Esegui il deployment dell'iniettore del sidecar.

   kubectl apply -f specs/
   

2. Verifica che l'iniettore collaterale sia in esecuzione.

   kubectl get pods -A | grep sidecar-injector
   

   In questo modo viene restituito un output simile al seguente:

   istio-control   istio-sidecar-injector-6b475bfdf9-79965  1/1 Running   0   11s
   istio-control   istio-sidecar-injector-6b475bfdf9-vntjd  1/1 Running   0   11s
   

Nota: sia l'injector che il proxy inserito si basano sulla configurazione in modo che i componenti basati su Istio siano presenti nei tuoi cluster. Non è necessario installare altri componenti Istio. Tutti la configurazione necessaria per Cloud Service Mesh è illustrata in questa guida.

Apertura della porta richiesta su un cluster privato in corso...

Per seguire le istruzioni riportate in Configurazione della sicurezza del servizio Cloud Service Mesh con Envoy, puoi saltare questa sezione e passare alla sezione successiva. Attivazione dell'inserimento di file collaterali.

Se installi l'injector sidecar di Envoy su un cluster privato, devi per aprire la porta TCP 9443 nella regola firewall verso i nodi master per il webhook funzionino correttamente.

I passaggi seguenti spiegano come aggiornare la regola firewall richiesta. Tieni presente che il comando update sostituisce la regola firewall esistente, quindi devi apportare assicurati di includere le porte predefinite 443 (HTTPS) e 10250 (kubelet), nonché la nuova porta che vuoi aprire.

1. Trova l'intervallo di origine (master-ipv4-cidr) del cluster. Nel seguente sostituisci CLUSTER_NAME con il nome del tuo cluster, ad esempio traffic-director-cluster:

   FIREWALL_RULE_NAME=$(gcloud compute firewall-rules list \
    --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master" \
    --format="value(name)")
   

2. Aggiorna la regola firewall per aprire la porta TCP 9443 per abilitare l'inserimento automatico:

   gcloud compute firewall-rules update ${FIREWALL_RULE_NAME} \
    --allow tcp:10250,tcp:443,tcp:9443
   

Attivazione dell'inserimento di file collaterali

Il seguente comando abilita l'inserimento per lo spazio dei nomi default. La l'injector collaterale inserisce i container collaterali nei pod creati in base a questo spazio dei nomi:

kubectl label namespace default istio-injection=enabled

Puoi verificare che lo spazio dei nomi default sia abilitato correttamente eseguendo il seguente comando:

kubectl get namespace -L istio-injection

Dovrebbe essere restituito:

NAME              STATUS   AGE     ISTIO-INJECTION
default           Active   7d16h   enabled
istio-control     Active   7d15h
istio-system      Active   7d15h

Se stai configurando la sicurezza dei servizi per Cloud Service Mesh con Envoy, torna alla sezione Configurazione di un servizio di test nella guida alla configurazione.

Deployment di un client di esempio e verifica dell'inserimento

Questa sezione mostra come eseguire il deployment di un pod di esempio che esegue Busybox, a un'interfaccia semplice per raggiungere un servizio di test. In un deployment reale, il deployment della tua applicazione client.

kubectl create -f demo/client_sample.yaml

Il pod Busybox è composto da due container. Il primo container è il client basato sull'immagine Busybox e il secondo container è il proxy Envoy inserito dall'iniettore del sidecar. Puoi ottenere maggiori informazioni sul pod eseguendo il seguente comando:

kubectl describe pods -l run=client

Dovrebbe essere restituito:

…
Init Containers:
# Istio-init sets up traffic interception for the pod.
  Istio-init:
…
Containers:
# busybox is the client container that runs application code.
  busybox:
…
# Envoy is the container that runs the injected Envoy proxy.
  envoy:
…

Deployment di un servizio Kubernetes per i test

Le sezioni seguenti forniscono istruzioni per configurare un servizio di test che che utilizzerai più avanti in questa guida per fornire la verifica end-to-end della tua configurazione.

Configurazione di servizi GKE con NEG

I servizi GKE devono essere esposti tramite gruppi di endpoint di rete (NEG) in modo da poterli configurare come backend di un backend Cloud Service Mesh completamente gestito di Google Cloud. Aggiungi l'annotazione NEG alla specifica del servizio Kubernetes e scegli un nome (sostituendo NEG-NAME nell'esempio di seguito) in modo che tu possa trovare in un secondo momento. Devi avere il nome quando colleghi il NEG al tuo Servizio di backend Cloud Service Mesh. Per ulteriori informazioni sull'annotazione dei NEG, consulta Denominazione dei NEG.

Nota: il pacchetto trafficdirector_service_sample.yaml fornito con questo utilizza il nome del NEG service-test-neg.

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "service-test-neg"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

Questa annotazione crea un NEG autonomo contenente endpoint corrispondenti con gli indirizzi IP e le porte dei pod del servizio. Per ulteriori informazioni e consulta gli esempi Gruppi di endpoint di rete autonomi.

Il seguente servizio di esempio include l'annotazione NEG. Il servizio offre il nome host su HTTP sulla porta 80. Utilizza il seguente comando per ottenere di servizio ed eseguirne il deployment nel cluster GKE.

wget -q -O - \
https://storage.googleapis.com/traffic-director/demo/trafficdirector_service_sample.yaml \
| kubectl apply -f -

Verifica che il nuovo servizio sia stato creato e che il pod dell'applicazione sia in esecuzione:

kubectl get svc

L'output dovrebbe essere simile al seguente:

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service-test     ClusterIP   10.71.9.71   none          80/TCP    41m
[..skip..]

Verifica che il pod dell'applicazione associato a questo servizio sia in esecuzione:

kubectl get pods

che restituisce:

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       2/2       Running   0          6m
busybox-5dcf86f4c7-jvvdd    2/2       Running   0          10m
[..skip..]

Nota :poiché l'injector collaterale è abilitato nello spazio dei nomi predefinito, vengono inseriti anche i proxy nel pod di servizio di test al momento della creazione. La injector sidecar configura solo l'intercettazione per il traffico in uscita, quindi il test proxy sidecar del servizio non è coinvolto nella gestione del traffico in entrata dal di esempio.

Salvataggio del nome del NEG

Trova il NEG creato dall'esempio precedente e registra il suo nome per Configurazione di Cloud Service Mesh nella prossima sezione.

gcloud compute network-endpoint-groups list

Viene restituito quanto segue:

NAME                       LOCATION            ENDPOINT_TYPE       SIZE
service-test-neg           ZONE     GCE_VM_IP_PORT      1

Salva il nome del NEG nella variabile NEG_NAME:

NEG_NAME=$(gcloud compute network-endpoint-groups list \
| grep service-test | awk '{print $1}')

Nota: se hai assegnato un nome al NEG, come descritto in Configurazione di servizi GKE con NEG dovresti vedere che il nome del NEG corrisponde a quello fornito in Kubernetes la specifica del servizio. Se non hai assegnato un nome al NEG, questo viene generato automaticamente per te.

Configurazione di Cloud Service Mesh con i componenti di Cloud Load Balancing

Questa sezione configura Cloud Service Mesh utilizzando il carico di Compute Engine e il bilanciamento delle risorse. Ciò consente al proxy sidecar del client di esempio di ricevere configurazione da Cloud Service Mesh. Richieste in uscita dal client di esempio vengono gestiti dal proxy sidecar e instradati al servizio di test.

Devi configurare i seguenti componenti:

• Un controllo di integrità. Per ulteriori informazioni sui controlli di integrità, consulta Concetti sul controllo di integrità e Creazione di controlli di integrità.
• Un servizio di backend. Per ulteriori informazioni sui servizi di backend, consulta Servizi di backend.
• Una mappa di regole di routing. È inclusa la creazione di una regola di forwarding, di un HTTP di destinazione proxy e una mappa URL. Per ulteriori informazioni, consulta Utilizzando le regole di forwarding per Cloud Service Mesh, Usando proxy di destinazione per Cloud Service Mesh, e Utilizzo delle mappe URL.

Creazione del controllo di integrità e della regola firewall in corso...

Segui queste istruzioni per creare un controllo di integrità e la regola firewall. necessario per i probe del controllo di integrità. Per ulteriori informazioni, vedi Regole firewall per i controlli di integrità.

Console

1. Vai alla pagina Controlli di integrità nella console Google Cloud.
   Vai alla pagina Controlli di integrità
2. Fai clic su Crea controllo di integrità.
3. Come nome, inserisci td-gke-health-check.
4. Come protocollo, seleziona HTTP.

5. Fai clic su Crea.

6. Vai alla pagina Criteri firewall nella console Google Cloud.
   Vai alla pagina Criteri firewall

7. Fai clic su Crea regole firewall.

8. Nella pagina Crea una regola firewall, fornisci le seguenti informazioni:

   • Nome: specifica un nome per la regola. Per questo esempio, utilizza fw-allow-health-checks.
   • Rete: scegli una rete VPC.
   • Priorità: inserisci un numero per la priorità. I numeri più bassi hanno priorità più elevate. Assicurati che la regola firewall abbia un principale rispetto ad altre regole che potrebbero negare il traffico in entrata.
   • Direzione del traffico: scegli In entrata.
   • Azione in caso di corrispondenza: seleziona Consenti.
   • Destinazioni: scegli Tutte le istanze nella rete.
   • Filtro di origine: scegli il tipo di intervallo IP corretto.
   • Intervalli IP di origine: 35.191.0.0/16,130.211.0.0/22
   • Filtro di destinazione: seleziona il tipo di IP.
   • Protocolli e porte: fai clic su Porte e protocolli specificati. quindi controlla tcp. TCP è la parte per tutti i protocolli di controllo di integrità.
   • Fai clic su Crea.

gcloud

1. Crea il controllo di integrità.

   gcloud compute health-checks create http td-gke-health-check \
     --use-serving-port
   

2. Crea la regola firewall per consentire gli intervalli di indirizzi IP del controllo di integrità.

   gcloud compute firewall-rules create fw-allow-health-checks \
     --action ALLOW \
     --direction INGRESS \
     --source-ranges 35.191.0.0/16,130.211.0.0/22 \
     --rules tcp
   

Creazione del servizio di backend

Creare un servizio di backend globale con uno schema di bilanciamento del carico di INTERNAL_SELF_MANAGED. Nella Nella console Google Cloud, lo schema di bilanciamento del carico è impostato in modo implicito. Aggiungi il parametro un controllo di integrità al servizio di backend.

Console

1. Vai alla pagina Cloud Service Mesh nella console Google Cloud.

   Vai alla pagina di Cloud Service Mesh

2. Nella scheda Servizi, fai clic su Crea servizio.

3. Fai clic su Continua.

4. Come nome del servizio, inserisci td-gke-service.

5. Seleziona Rete che hai configurato nel ConfigMap di Cloud Service Mesh.

6. In Tipo di backend, seleziona Gruppi di endpoint di rete.

7. Seleziona il gruppo di endpoint di rete che hai creato.

8. Imposta Numero massimo di RPS su 5.

9. Imposta Modalità di bilanciamento su Tariffa.

10. Fai clic su Fine.

11. In Controllo di integrità, seleziona td-gke-health-check, ovvero l'integrità che hai creato.

12. Fai clic su Continua.

gcloud

1. Crea il servizio di backend e associa il controllo di integrità al di servizio di backend.

   gcloud compute backend-services create td-gke-service \
    --global \
    --health-checks td-gke-health-check \
    --load-balancing-scheme INTERNAL_SELF_MANAGED
   

2. Aggiungi il NEG creato in precedenza come backend del servizio di backend. Se configuri Cloud Service Mesh con un proxy TCP di destinazione, deve utilizzare la modalità di bilanciamento UTILIZATION. Se utilizzando un proxy di destinazione HTTP o HTTPS, puoi utilizzare la modalità RATE.

   gcloud compute backend-services add-backend td-gke-service \
    --global \
    --network-endpoint-group ${NEG_NAME} \
    --network-endpoint-group-zone ZONE \
    --balancing-mode [RATE | UTILIZATION] \
    --max-rate-per-endpoint 5
   

Creazione della mappa di regole di routing

La mappa di regole di routing definisce il modo in cui Cloud Service Mesh instrada il traffico nel tuo mesh. Nell'ambito della mappa di regole di routing, devi configurare un indirizzo IP virtuale (VIP) e un insieme di regole di gestione del traffico associate, ad esempio il routing basato su host. Quando un'applicazione invia una richiesta al VIP, il file collaterale Envoy allegato il proxy svolge le seguenti operazioni:

1. Intercetta la richiesta.
2. La valuta in base alle regole di gestione del traffico nella mappa URL.
3. Seleziona un servizio di backend in base al nome host nella richiesta.
4. Sceglie un backend o un endpoint associato al servizio di backend selezionato.
5. Invia il traffico al backend o all'endpoint.

Console

Nella console, il proxy di destinazione è combinato con la regola di forwarding. Quando crei la regola di forwarding, Google Cloud automaticamente crea un proxy HTTP di destinazione e lo allega alla mappa URL.

La regola di route è composta dalla regola di forwarding e dalle regole relative a host e percorso (nota anche come mappa URL).

1. Vai alla pagina Cloud Service Mesh nella console Google Cloud.

   Vai alla pagina di Cloud Service Mesh

2. Fai clic su Mappe di regole di routing

3. Fai clic su Crea regola di routing.

4. Inserisci td-gke-url-map come Nome della mappa URL.

5. Fai clic su Aggiungi regola di forwarding.

6. Come nome della regola di forwarding, inserisci td-gke-forwarding-rule.

7. Seleziona la tua rete.

8. Seleziona il tuo IP interno.

9. Fai clic su Salva.

10. Se vuoi, aggiungi regole host e percorso personalizzate o lascia le regole del percorso invariate i valori predefiniti.

11. Imposta l'host su service-test.

12. Fai clic su Salva.

gcloud

1. Crea una mappa URL che utilizzi td-gke-service come servizio di backend predefinito.

   gcloud compute url-maps create td-gke-url-map \
      --default-service td-gke-service
   

2. Crea un matcher del percorso della mappa degli URL e una regola host per instradare il traffico verso il tuo basato sul nome host e su un percorso. In questo esempio viene utilizzato service-test come nome del servizio e un matcher di percorso predefinito che corrisponde a tutte le richieste di percorso questo host (/*).

   gcloud compute url-maps add-path-matcher td-gke-url-map \
      --default-service td-gke-service \
      --path-matcher-name td-gke-path-matcher
   
   gcloud compute url-maps add-host-rule td-gke-url-map \
      --hosts service-test \
      --path-matcher-name td-gke-path-matcher
   

3. Crea il proxy HTTP di destinazione.

   gcloud compute target-http-proxies create td-gke-proxy \
      --url-map td-gke-url-map
   

4. Crea la regola di forwarding.

   gcloud compute forwarding-rules create td-gke-forwarding-rule \
     --global \
     --load-balancing-scheme=INTERNAL_SELF_MANAGED \
     --address=0.0.0.0 \
     --target-http-proxy=td-gke-proxy \
     --ports 80 --network default
   

A questo punto, Cloud Service Mesh configura i proxy sidecar per il routing richieste che specificano il nome host service-test per i backend di td-gke-service. In questo caso, i backend sono endpoint nella rete gruppo di endpoint associato al servizio di test Kubernetes di cui hai eseguito il deployment in precedenza.

Nota: perché hai configurato un servizio predefinito (td-gke-service) per l'URL mappa, qualsiasi richiesta in uscita gestita da un proxy sidecar viene indirizzata backend associati a questo servizio predefinito.

Verifica della configurazione in corso...

Questa sezione mostra come verificare che il traffico inviato dalla Busybox di esempio viene instradato al tuo servizio Kubernetes service-test. Per inviare un test puoi accedere a una shell su uno dei container ed eseguire successivo al comando di verifica. Un pod service-test deve restituire il nome host del pod di pubblicazione.

# Get the name of the pod running Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test at
# the VIP 10.0.0.1. Because 0.0.0.0 is configured in the forwarding rule, this
# can be any VIP.
TEST_CMD="wget -q -O - 10.0.0.1; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

Ecco come viene verificata la configurazione:

• Il client di esempio ha inviato una richiesta che specificava il nome host service-test.
• Il client di esempio ha un proxy sidecar Envoy inserito da Envoy iniettore Sidecar.
• Il proxy sidecar ha intercettato la richiesta.
• Utilizzando la mappa degli URL, Envoy ha abbinato il nome host service-test al td-gke-service Servizio Cloud Service Mesh.
• Envoy ha scelto un endpoint dal gruppo di endpoint di rete associato a td-gke-service.
• Envoy ha inviato la richiesta a un pod associato a service-test completamente gestito di Kubernetes.

Passaggi successivi

• Scopri di più sulla gestione avanzata del traffico.
• Scopri di più sulla sicurezza del servizio Cloud Service Mesh.
• Scopri come configurare l'osservabilità con Envoy.
• Scopri come risolvere i problemi dei deployment di Cloud Service Mesh.
• Scopri di più sulle opzioni di configurazione dei pod di Google Kubernetes Engine con inserimento Envoy automatico.