Configurare i pod di Google Kubernetes Engine utilizzando l'inserimento automatico di Envoy
Panoramica
In un mesh di servizi, non è necessario che il codice dell'applicazione sia a conoscenza della configurazione di rete. Le applicazioni comunicano invece su un piano dati, che è configurato da un piano di controllo che gestisce il networking di servizi. In questa guida, Cloud Service Mesh è il tuo piano di controllo e i proxy sidecar di Envoy sono il tuo piano dati.
L'injector sidecar di Envoy semplifica l'aggiunta di proxy sidecar di Envoy ai pod di Google Kubernetes Engine. Quando l'iniettore collaterale di Envoy aggiunge un proxy, lo imposta anche per gestire il traffico delle applicazioni e connettersi a Cloud Service Mesh per la configurazione.
Questa guida ti accompagna attraverso una semplice configurazione di Cloud Service Mesh con Google Kubernetes Engine. Questi passaggi forniscono le basi che puoi estendere a casi d'uso avanzati, ad esempio un mesh di servizi che si estende su più cluster di Google Kubernetes Engine e, potenzialmente, VM di Compute Engine. Puoi usare queste istruzioni anche se stai configurando Cloud Service Mesh con un VPC condiviso.
La procedura di configurazione prevede:
- Creazione di un cluster GKE per i carichi di lavoro.
- Installazione dell'iniettore del sidecar Envoy e attivazione dell'iniezione in corso.
- Deployment di un client di esempio e verifica dell'inserimento.
- Deployment di un servizio Kubernetes per i test.
- configurare Cloud Service Mesh con i componenti di Cloud Load Balancing per instradare il traffico al servizio di test.
- Verifica la configurazione inviando una richiesta dal client di esempio al servizio di test.
Prerequisiti
Prima di seguire le istruzioni di questa guida, consulta Preparazione per la configurazione di Cloud Service Mesh e assicurati di aver completato le attività preliminari descritte nel documento.
Per informazioni sulla versione di Envoy supportata, consulta le note di rilascio di Cloud Service Mesh.
Prerequisiti aggiuntivi con il VPC condiviso
Se stai configurando 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 ogni progetto, incluso quello 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 il progetto host per il VPC condiviso abbia due subnet e che nel VPC condiviso esistano due progetti di servizio.
In Cloud Shell, crea una cartella di lavoro (
WORKDIR)
in cui crei i file associati a questa sezione:mkdir -p ~/td-shared-vpc cd ~/td-shared-vpc export WORKDIR=$(pwd)
Configura le autorizzazioni IAM nel progetto host in modo che i progetti di servizio possano utilizzare le risorse nel VPC condiviso.
In questo passaggio, configurerai le autorizzazioni IAM in modo che
subnet-1
sia accessibile dal progetto di servizio 1 esubnet-2
sia accessibile dal progetto di servizio 2. Assegnerai il ruolo IAM Utente di rete Compute (roles/compute.networkUser
) sia all'account di servizio predefinito Compute Engine di Compute Engine sia all'account di servizio API Google Cloud in ciascun progetto di servizio per ogni subnet.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}
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}
Per ogni progetto di servizio, devi concedere il ruolo IAM Utente Agente di servizio host Kubernetes Engine (
roles/container.hostServiceAgentUser
) all'account di servizio 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 progetto di servizio di utilizzare l'account di servizio GKE del progetto host per configurare risorse di rete condivise.
Per ogni progetto di servizio, concedi all'account di servizio predefinito di Compute Engine 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 servizio xDS (API Traffic Director), utilizza l'account di servizio dell'host della macchina virtuale (VM) Compute Engine o dell'istanza del nodo GKE. L'account di servizio deve disporre dell'autorizzazione IAM a livello di progetto
compute.globalForwardingRules.get
. Il ruolo Visualizzatore di rete Compute è sufficiente per questo passaggio.
Creazione di un cluster GKE per i carichi di lavoro
Per supportare Cloud Service Mesh, i cluster GKE devono soddisfare i seguenti requisiti:
- 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 nodi/pod GKE deve avere l'autorizzazione per accedere all'API Cloud Service Mesh. Per ulteriori informazioni sulle autorizzazioni richieste, consulta la pagina relativa all'abilitazione dell'account di servizio per l'accesso 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
Il comando kubectl punta 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 dell'iniettore collaterale di Envoy. Quando l'injector sidecar è abilitato, esegue automaticamente il deployment dei proxy sidecar per i carichi di lavoro di Google Kubernetes Engine nuovi ed esistenti. Poiché l'injector collaterale di Envoy viene eseguito all'interno del tuo cluster GKE, devi installarlo una volta in ciascun cluster se utilizzi Cloud Service Mesh per supportare un mesh di servizi multi-cluster.
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'injector collaterale modificando il file specs/01-configmap.yaml
in:
- Per compilare
TRAFFICDIRECTOR_GCP_PROJECT_NUMBER
, sostituisciYOUR_PROJECT_NUMBER_HERE
con il numero di progetto del tuo progetto. Il numero del progetto è un identificatore numerico del progetto. Per informazioni su come ottenere un elenco di tutti i progetti, consulta Identificazione dei progetti. - Compila
TRAFFICDIRECTOR_NETWORK_NAME
sostituendoYOUR_NETWORK_NAME_HERE
con il nome della rete Virtual Private Cloud di Google Cloud che vuoi utilizzare con Cloud Service Mesh. Prendi nota del nome di questa rete VPC, perché ne avrai bisogno durante la configurazione di Cloud Service Mesh.
Se utilizzi le nuove API di routing dei servizi, attualmente in anteprima:
- Compila
TRAFFICDIRECTOR_MESH_NAME
sostituendo "" con il nome del mesh di servizi per ottenere la configurazione per un mesh di servizi.- Tieni presente che se stai configurando un
Gateway
, non utilizzare l'iniettore collaterale. Esegui il deployment di un proxy Envoy come pod.
- Tieni presente che se stai configurando un
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"
Facoltativamente, puoi anche abilitare il logging e il tracciamento per ogni proxy inserito automaticamente. Per saperne di più su queste configurazioni, consulta Configurare attributi aggiuntivi per i proxy sidecar.
Quando utilizzi l'injector collaterale, il valore di 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 questo
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'injector collaterale utilizza un webhook di ammissione mutante di Kubernetes per inserire i proxy quando vengono creati nuovi pod. Questo webhook è un endpoint HTTPS, quindi devi fornire una chiave e un certificato per TLS.
Puoi creare una chiave privata e un certificato autofirmato utilizzando openssl
per proteggere l'iniettore collaterale.
Facoltativamente, se hai la tua chiave privata e un certificato firmato da un'autorità di certificazione (CA) attendibile, 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 privata a 4096 bit in key.pem
e un certificato autofirmato in formato X.509 in cert.pem
. Poiché il certificato è autofirmato, viene copiato in ca-cert.pem
e considerato anche il certificato della CA di firma. Il certificato rimane valido per 365 giorni e non richiede una passphrase. Per ulteriori informazioni sulla creazione e sulla firma dei certificati, consulta la documentazione di Kubernetes sulle richieste di firma del certificato.
I passaggi in questa sezione devono essere ripetuti ogni anno per rigenerare e applicare nuovamente nuove chiavi e certificati prima che scadano.
Dopo aver ottenuto la chiave e i certificati, devi creare un secret Kubernetes e aggiornare il webhook dell'iniettore collaterale.
Crea lo spazio dei nomi in cui deve essere creato il secret Kubernetes:
kubectl apply -f specs/00-namespaces.yaml
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
Modifica
caBundle
del webhook di inserimento del file collaterale denominatoistio-sidecar-injector-istio-control
inspecs/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 del sidecar injector nel cluster GKE in corso...
Esegui il deployment dell'iniettore del sidecar.
kubectl apply -f specs/
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
Apertura della porta richiesta su un cluster privato in corso...
Se stai seguendo le istruzioni in Configurare la sicurezza del servizio Cloud Service Mesh con Envoy, puoi saltare questa sezione e passare alla sezione successiva, Attivare l'inserimento di file collaterali.
Se installi l'injector del sidecar Envoy su un cluster privato, devi aprire la porta TCP 9443 nella regola del firewall nei nodi master affinché il webhook funzioni correttamente.
I passaggi seguenti spiegano come aggiornare la regola firewall richiesta. Tieni presente che il comando update
sostituisce la regola firewall esistente, quindi devi assicurarti di includere le porte predefinite 443 (HTTPS
) e 10250 (kubelet
), nonché la nuova porta che vuoi aprire.
Trova l'intervallo di origine (
master-ipv4-cidr
) del cluster. Nel comando seguente, sostituisciCLUSTER_NAME
con il nome del tuo cluster, ad esempiotraffic-director-cluster
:FIREWALL_RULE_NAME=$(gcloud compute firewall-rules list \ --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master" \ --format="value(name)")
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
. L'injector collaterale inserisce i container collaterali nei pod creati in questo spazio dei nomi:
kubectl label namespace default istio-injection=enabled
Puoi verificare che lo spazio dei nomi default
sia abilitato correttamente eseguendo questo 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 del servizio 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, che fornisce un'interfaccia semplice per raggiungere un servizio di test. In un deployment reale, eseguirai 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'injector del sidecar. Puoi ottenere maggiori informazioni sul pod eseguendo il comando seguente:
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 utilizzerai più avanti nella 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 servizio di backend Cloud Service Mesh. Aggiungi l'annotazione NEG alla specifica del servizio Kubernetes e scegli un nome (sostituendo NEG-NAME
nell'esempio di seguito) in modo da poterla trovare facilmente in seguito. Devi avere il nome quando colleghi il NEG al servizio di backend Cloud Service Mesh. Per ulteriori informazioni sull'annotazione dei NEG, consulta
Denominazione dei 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 agli indirizzi IP e alle porte dei pod del servizio. Per ulteriori informazioni ed esempi, consulta Gruppi di endpoint di rete autonomi.
Il seguente servizio di esempio include l'annotazione NEG. Il servizio gestisce il nome host su HTTP sulla porta 80
. Usa questo comando per recuperare il 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 podsViene restituito:
NAME READY STATUS RESTARTS AGE app1-6db459dcb9-zvfg2 2/2 Running 0 6m busybox-5dcf86f4c7-jvvdd 2/2 Running 0 10m [..skip..]
Salvataggio del nome del NEG
Trova il NEG creato dall'esempio precedente e registrane il nome per la configurazione di Cloud Service Mesh nella sezione successiva.
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}')
Configurazione di Cloud Service Mesh con i componenti di Cloud Load Balancing
Questa sezione configura Cloud Service Mesh utilizzando le risorse di bilanciamento del carico di Compute Engine. Ciò consente al proxy sidecar del client di esempio di ricevere la configurazione da Cloud Service Mesh. Le richieste in uscita dal client di esempio vengono gestite dal proxy sidecar e instradate al servizio di test.
Devi configurare i seguenti componenti:
- Un controllo di integrità. Per maggiori informazioni sui controlli di integrità, leggi 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. Ciò include la creazione di una regola di forwarding, un proxy HTTP di destinazione e una mappa URL. Per ulteriori informazioni, consulta Utilizzo delle regole di forwarding per Cloud Service Mesh, Utilizzo dei proxy di destinazione per Cloud Service Mesh e Utilizzo delle mappe URL.
Creazione del controllo di integrità e della regola firewall in corso...
Utilizza le istruzioni riportate di seguito per creare un controllo di integrità e la regola firewall necessari per i probe del controllo di integrità. Per maggiori informazioni, consulta Regole firewall per i controlli di integrità.
Console
- Vai alla pagina Controlli di integrità nella console Google Cloud.
Vai alla pagina Controlli di integrità - Fai clic su Crea controllo di integrità.
- Come nome, inserisci
td-gke-health-check
. - Come protocollo, seleziona HTTP.
Fai clic su Crea.
Vai alla pagina Criteri firewall nella console Google Cloud.
Vai alla pagina Criteri firewallFai clic su Crea regole firewall.
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ù alte. Assicurati che la regola firewall abbia una priorità più alta 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 seleziona
tcp
. TCP è il protocollo sottostante per tutti i protocolli per il controllo di integrità. - Fai clic su Crea.
- Nome: specifica un nome per la regola. Per questo esempio, utilizza
gcloud
Crea il controllo di integrità.
gcloud compute health-checks create http td-gke-health-check \ --use-serving-port
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
Crea un servizio di backend globale con uno schema di bilanciamento del carico di INTERNAL_SELF_MANAGED
. Nella console Google Cloud, lo schema di bilanciamento del carico è impostato in modo implicito. Aggiungi il controllo di integrità al servizio di backend.
Console
Vai alla pagina Cloud Service Mesh nella console Google Cloud.
Nella scheda Servizi, fai clic su Crea servizio.
Fai clic su Continua.
Come nome del servizio, inserisci
td-gke-service
.Seleziona Rete che hai configurato nel ConfigMap di Cloud Service Mesh.
In Tipo di backend, seleziona Gruppi di endpoint di rete.
Seleziona il gruppo di endpoint di rete che hai creato.
Imposta Numero massimo di RPS su
5
.Imposta Modalità di bilanciamento su Tariffa.
Fai clic su Fine.
In Controllo di integrità, seleziona
td-gke-health-check
, ovvero il controllo di integrità che hai creato.Fai clic su Continua.
gcloud
Creare il servizio di backend e associare il controllo di integrità al servizio di backend.
gcloud compute backend-services create td-gke-service \ --global \ --health-checks td-gke-health-check \ --load-balancing-scheme INTERNAL_SELF_MANAGED
Aggiungi il NEG creato in precedenza come backend del servizio di backend. Se configuri Cloud Service Mesh con un proxy TCP di destinazione, devi utilizzare la modalità di bilanciamento
UTILIZATION
. Se utilizzi 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 nella tua 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 proxy sidecar Envoy collegato esegue queste operazioni:
- Intercetta la richiesta.
- La valuta in base alle regole di gestione del traffico nella mappa URL.
- Seleziona un servizio di backend in base al nome host nella richiesta.
- Sceglie un backend o un endpoint associato al servizio di backend selezionato.
- 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 crea automaticamente un proxy HTTP di destinazione e lo collega 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).
Vai alla pagina Cloud Service Mesh nella console Google Cloud.
Fai clic su Mappe di regole di routing
Fai clic su Crea regola di routing.
Inserisci
td-gke-url-map
come Nome della mappa URL.Fai clic su Aggiungi regola di forwarding.
Come nome della regola di forwarding, inserisci
td-gke-forwarding-rule
.Seleziona la tua rete.
Seleziona il tuo IP interno.
Fai clic su Salva.
Se vuoi, puoi aggiungere regole host e percorso personalizzate o lasciare le regole del percorso come predefinite.
Imposta l'host su
service-test
.Fai clic su Salva.
gcloud
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
Crea un matcher del percorso della mappa degli URL e una regola host per instradare il traffico verso il tuo servizio in base al nome host e a un percorso. Questo esempio utilizza
service-test
come nome del servizio e un matcher di percorso predefinito che corrisponde a tutte le richieste di percorso per 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
Crea il proxy HTTP di destinazione.
gcloud compute target-http-proxies create td-gke-proxy \ --url-map td-gke-url-map
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 tuoi proxy sidecar per instradare richieste che specificano il nome host service-test
ai backend di td-gke-service
. In questo caso, questi backend sono endpoint nel gruppo di endpoint di rete associato al servizio di test Kubernetes di cui hai eseguito il deployment in precedenza.
Verifica della configurazione in corso...
Questa sezione mostra come verificare che il traffico inviato dal client Busybox di esempio venga instradato al tuo servizio Kubernetes service-test
. Per inviare una richiesta di test, puoi accedere a una shell su uno dei container ed eseguire questo comando di verifica. Un pod service-test
dovrebbe restituire il nome host
del pod in uso.
# 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 dall'iniettore sidecar di Envoy.
- Il proxy sidecar ha intercettato la richiesta.
- Utilizzando la mappa URL, Envoy ha abbinato il nome host
service-test
al servizio Cloud Service Mesh ditd-gke-service
. - 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 al servizio Kubernetes
service-test
.
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.