Configurare i pod di Google Kubernetes Engine con l'inserimento manuale di Envoy
Questa guida mostra come configurare gli host di Google Kubernetes Engine o di pod Kubernetes e i componenti di bilanciamento del carico richiesti da Cloud Service Mesh.
Prima di seguire le istruzioni di questa guida, consulta Preparazione per la configurazione di Cloud Service Mesh e assicurati di aver completato i prerequisiti.
Puoi configurare Cloud Service Mesh utilizzando l'SDK di bilanciamento del carico di Compute Engine o le API REST. Consulta i riferimenti di gcloud e API di bilanciamento del carico.
Configurazione di cluster GKE/Kubernetes per Cloud Service Mesh
Questa sezione descrive i passaggi necessari per abilitare il funzionamento dei cluster GKE/Kubernetes con Cloud Service Mesh.
Creazione del cluster GKE
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 la pagina relativa ai gruppi di endpoint di rete autonomi. La funzionalità NEG standalone è disponibile in disponibilità generale per Cloud Service Mesh.
- L'account di servizio delle istanze dei nodi del cluster deve disporre dell'autorizzazione per accedere all'API Cloud Service Mesh.
- Per informazioni sulle autorizzazioni richieste, consulta Abilitazione dell'account di servizio per l'accesso all'API Cloud Service Mesh.
- Per informazioni sull'abilitazione dell'API Cloud Service Mesh, consulta Attivazione dell'API Cloud Service Mesh.
- I container devono avere accesso all'API Cloud Service Mesh, protetti dall'autenticazione OAuth. Per saperne di più, consulta l'articolo sulla configurazione dell'host.
L'esempio seguente mostra come creare un cluster GKE denominato traffic-director-cluster
nella zona us-central1-a
.
Console
Per creare un cluster utilizzando la console Google Cloud, esegui questi passaggi:
Vai al menu Kubernetes Engine nella console Google Cloud.
Fai clic su Crea cluster.
Completa i seguenti campi:
- Nome: inserisci
traffic-director-cluster
. - Tipo di posizione:
Zonal
. - Zona:
us-central1-a
.
- Nome: inserisci
Nel riquadro di navigazione, in Pool di nodi, fai clic su default-pool.
Il campo Dimensioni indica il numero di nodi da creare nel cluster. Devi disporre di una quota di risorse disponibile per i nodi e le relative risorse (come le route del firewall).
Nel riquadro di navigazione, in default-pool, fai clic su Nodi.
Il campo Tipo di macchina indica il tipo di macchina di Compute Engine da utilizzare per le istanze. Ogni tipo di macchina viene fatturato in modo diverso. Per informazioni sui prezzi dei tipo di macchina, consulta la pagina dei prezzi di Compute Engine.
Nel riquadro di navigazione, in default-pool, fai clic su Security (Sicurezza).
In Ambiti di accesso, fai clic su Consenti l'accesso completo a tutte le API Cloud.
Personalizza il cluster in base alle tue esigenze.
Fai clic su Crea.
Dopo aver creato un cluster nella console Google Cloud, devi configurare kubectl
per interagire con il cluster. Per ulteriori informazioni, consulta Generazione di una voce kubeconfig
.
gcloud
gcloud container clusters create traffic-director-cluster \ --zone us-central1-a \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --enable-ip-alias
Ottenere i privilegi necessari per il cluster GKE
Per GKE, passa al cluster(2) che hai appena creato inviando questo comando. Questo punta kubectl al cluster corretto.
gcloud container clusters get-credentials traffic-director-cluster \ --zone us-central1-a
Configurazione dei servizi GKE/Kubernetes
Questa sezione mostra come preparare le specifiche del deployment Kubernetes per funzionare con Cloud Service Mesh. Consiste nella configurazione dei servizi con NEG e nell'inserimento di proxy sidecar nei pod che richiedono l'accesso ai servizi gestiti da Cloud Service Mesh.
Configura la regola firewall
Per verificare che i pod di backend siano in esecuzione, devi configurare una regola firewall che consenta gli intervalli di indirizzi IP del controllo di integrità.
Console
- Vai alla pagina Criteri firewall nella console Google Cloud.
Vai alla pagina Criteri firewall - Fai 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: scegli 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
Utilizza il seguente comando
gcloud
per creare una regola firewall denominatafw-allow-health-checks
che consente le connessioni in entrata alle istanze nella tua rete con il tagallow-health-checks
. Sostituisci NETWORK_NAME con il nome della tua rete.gcloud compute firewall-rules create fw-allow-health-checks \ --network NETWORK_NAME \ --action ALLOW \ --direction INGRESS \ --source-ranges 35.191.0.0/16,130.211.0.0/22 \ --rules tcp
Per ulteriori informazioni, consulta Configurare la regola firewall per i controlli di integrità.
Configurazione di servizi GKE / Kubernetes 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": "NEG-NAME"}}}' spec: ports: - port: 80 name: service-test protocol: TCP targetPort: 8000
Per ogni servizio, viene creato un NEG autonomo contenente endpoint che corrispondono agli indirizzi IP e alle porte del pod. Per ulteriori informazioni ed esempi, consulta Gruppi di endpoint di rete autonomi.
A scopo dimostrativo, puoi eseguire il deployment di un servizio di esempio che gestisce il proprio host su HTTP sulla porta 80:
wget -q -O - \ https://storage.googleapis.com/traffic-director/demo/trafficdirector_service_sample.yaml \ | kubectl apply -f -
Verifica che sia stato creato il nuovo nome host del servizio e che il pod dell'applicazione sia in esecuzione:
kubectl get svc
Vengono visualizzati:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service-test ClusterIP 10.71.9.71 none 80/TCP 41m [..skip..]
kubectl get pods
Vengono visualizzati:
NAME READY STATUS RESTARTS AGE app1-6db459dcb9-zvfg2 1/1 Running 0 6m [..skip..]
Salvataggio del nome del NEG
Trova il NEG creato dall'esempio precedente e registra il nome del NEG.
Console
Per visualizzare un elenco di gruppi di endpoint di rete, vai alla pagina Gruppi di endpoint di rete nella console Google Cloud.
Vai alla pagina Gruppi di endpoint di rete
gcloud
gcloud compute network-endpoint-groups list
Viene restituito quanto segue:
NAME LOCATION ENDPOINT_TYPE SIZE NEG-NAME us-central1-a GCE_VM_IP_PORT 1
Salva il nome del NEG nella variabile NEG_NAME
, ad esempio:
NEG_NAME=$(gcloud compute network-endpoint-groups list \ | grep service-test | awk '{print $1}')
Configurazione dei componenti di bilanciamento del carico di Google Cloud per Cloud Service Mesh
Le istruzioni in questa sezione assicurano che i servizi GKE siano accessibili sul carico VIP del servizio con bilanciamento del carico da Cloud Service Mesh, utilizzando una configurazione di bilanciamento del carico simile ad altri prodotti di Google Cloud Load Balancing.
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 regola di route. Ciò include la creazione di una regola di forwarding e di una mappa URL. Per ulteriori informazioni, consulta Utilizzo delle regole di forwarding e Utilizzo delle mappe URL.
L'esempio di configurazione di Cloud Service Mesh che segue fa queste ipotesi:
- I NEG e tutte le altre risorse vengono creati nella rete
default
, con modalità automatica, nella zonaus-central1-a
. - Il nome del NEG per il cluster è archiviato nella variabile
${NEG_NAME}
.
Creazione del controllo di integrità
Crea il controllo 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.
gcloud
gcloud compute health-checks create http td-gke-health-check \ --use-serving-port
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
.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
.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 i NEG di backend al servizio di backend.
gcloud compute backend-services add-backend td-gke-service \ --global \ --network-endpoint-group ${NEG_NAME} \ --network-endpoint-group-zone us-central1-a \ --balancing-mode RATE \ --max-rate-per-endpoint 5
Creazione della mappa di regole di routing
Utilizza queste istruzioni per creare la regola di route, la regola di forwarding e l'indirizzo IP interno per la configurazione di Cloud Service Mesh.
Il traffico inviato all'indirizzo IP interno viene intercettato dal proxy Envoy e inviato al servizio appropriato in base alle regole host e percorso.
La regola di forwarding viene creata come regola di forwarding globale con
load-balancing-scheme
impostato su INTERNAL_SELF_MANAGED
.
Puoi impostare l'indirizzo della regola di forwarding su 0.0.0.0
. In questo caso, il traffico viene indirizzato in base al nome host HTTP e alle informazioni sul percorso configurate nella mappa degli URL, a prescindere dall'indirizzo IP effettivo a cui viene restituito il nome host.
In questo caso, gli URL (nome host più percorso dell'URL) dei servizi, come configurato nelle regole dell'host, devono essere univoci all'interno della configurazione del mesh di servizi. Vale a dire che non puoi avere due servizi diversi, con set di backend diversi, che utilizzano entrambi la stessa combinazione di nome host e percorso.
In alternativa, puoi abilitare il routing in base al VIP di destinazione effettivo del servizio. Se configuri il VIP del tuo servizio come parametro address
della regola di forwarding, vengono instradate solo le richieste destinate a questo indirizzo IP in base ai parametri HTTP specificati nella mappa URL.
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
Creare una mappa URL che utilizzi il servizio di backend.
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. In questo esempio viene utilizzato
service-test
come nome del servizio e un matcher di percorso predefinito che soddisfa tutte le richieste di percorso per questo host (/*
).service-test
è anche il nome configurato del servizio Kubernetes utilizzato nella configurazione di esempio riportata sopra.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 è configurato per bilanciare il carico del traffico per i servizi specificati nella mappa URL tra i backend del gruppo di endpoint di rete.
A seconda di come i microservizi sono distribuiti sulla rete, potrebbe essere necessario aggiungere altre regole di forwarding o più regole di host e percorso alla mappa URL.
Verifica della configurazione mediante il deployment di un client di esempio per i test
Questa sezione mostra come raggiungere i backend Cloud Service Mesh da un'applicazione client.
Per dimostrare la funzionalità, puoi eseguire il deployment di un pod di esempio che esegue Busybox. Il pod ha accesso a service-test
, creato nella sezione precedente, e riceve traffico con bilanciamento del carico da Cloud Service Mesh.
Iniezione di un proxy sidecar nei pod GKE / Kubernetes
Per accedere a un servizio gestito da Cloud Service Mesh, in un pod deve essere installato un proxy sidecar compatibile con l'API xDS.
In questo esempio, esegui il deployment di un client Busybox con un sidecar Istio-proxy e i container init vengono aggiunti al deployment utilizzando la specifica di riferimento.
Se utilizzi le API precedenti, sostituisci le variabili PROJECT_NUMBER e NETWORK_NAME con il numero di progetto e il nome della rete:
wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_sample_xdsv3.yaml sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_sample_xdsv3.yaml sed -i "s/NETWORK_NAME/NETWORK_NAME/g" trafficdirector_client_sample_xdsv3.yaml kubectl apply -f trafficdirector_client_sample_xdsv3.yaml
Se utilizzi le nuove API di routing dei servizi, attualmente in anteprima, sostituisci le variabili PROJECT_NUMBER e MESH_NAME con il numero del progetto e il nome Mesh
:
wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_new_api_sample_xdsv3.yaml sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_new_api_sample_xdsv3.yaml sed -i "s/MESH_NAME/MESH_NAME/g" trafficdirector_client_new_api_sample_xdsv3.yaml kubectl apply -f trafficdirector_client_new_api_sample_xdsv3.yaml
Il pod Busybox ha due container in esecuzione. Il primo container è il client basato sull'immagine Busybox e il secondo container è il proxy Envoy inserito come file collaterale. Per ottenere maggiori informazioni sul pod, esegui il comando seguente:
kubectl describe pods -l run=client
Raggiungere il servizio di backend
Una volta configurate, le applicazioni nei pod in cui è stato inserito un proxy sidecar possono accedere ai servizi gestiti dai servizi Cloud Service Mesh. Per verificare la configurazione, puoi accedere a una shell su uno dei container.
Se hai utilizzato la configurazione demo fornita in questa guida, puoi eseguire il seguente comando di verifica per assicurarti che venga restituito il nome host del pod di gestione.
# Get name of the Pod with 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. TEST_CMD="wget -q -O - service-test; echo" # Execute the test command on the Pod . kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"
Informazioni sull'intercettazione del traffico da parte del proxy sidecar
Tieni presente che, in questo esempio, quando il client Busybox invia richieste al servizio di backend, ogni richiesta viene inviata tramite proxy dal proxy sidecar.
Questa applicazione dimostrativa utilizza il proxy Envoy. Per questo motivo, il client vede "server: envoy" nell'intestazione delle risposte del server.
Per verificarlo, utilizza i seguenti comandi:
# Get the name of the Pod with Busybox. BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}') # Command to send a request to service-test and output server response headers. TEST_CMD="wget -S --spider service-test; echo" # Execute the test command on the Pod . kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"
In questo esempio, è stata creata una regola di forwarding utilizzando l'indirizzo VIP 0.0.0.0.
Ciò significa che Cloud Service Mesh inoltra le richieste al backend solo in base all'intestazione Host
. In questo caso, l'indirizzo IP di destinazione può essere qualsiasi indirizzo, purché l'intestazione host della richiesta corrisponda all'host definito nella mappa URL service-test
.
Per verificarlo, esegui questi comandi di prova:
# Get name of the Pod with Busybox. BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}') # Command to send a request to service-test setting the Host header and using a random IP address. TEST_CMD="wget -q --header 'Host: service-test' -O - 1.2.3.4; echo" # Execute the test command on the Pod . kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"
Passaggi successivi
- Scopri di più sulla gestione avanzata del traffico.
- Scopri come risolvere i problemi dei deployment di Cloud Service Mesh.
- Scopri come configurare l'osservabilità con Envoy.