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

Questa guida mostra come configurare gli host Google Kubernetes Engine o Kubernetes Pod e i componenti di bilanciamento del carico richiesti da Cloud Service Mesh.

Prima di seguire le istruzioni riportate in questa guida, completa le attività preliminari descritte in Prepararsi alla configurazione delle API di routing dei servizi con Envoy e carichi di lavoro senza proxy.

Puoi configurare Cloud Service Mesh utilizzando l'SDK o le API REST per il bilanciamento del carico di Compute Engine. Consulta i riferimenti all'API di bilanciamento del carico e a gcloud.

Configurazione dei cluster GKE/Kubernetes per Cloud Service Mesh

Questa sezione descrive i passaggi necessari per abilitare i cluster GKE/Kubernetes a funzionare 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 e esempi, consulta la sezione Gruppi di endpoint di rete autonomi. La funzionalità NEG autonoma è 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 Abilitare l'account di servizio per accedere all'API Traffic Director.
  • Per informazioni sull'abilitazione dell'API Cloud Service Mesh, consulta Abilitazione dell'API Cloud Service Mesh.
• I container devono avere accesso all'API Cloud Service Mesh, protetta dall'autenticazione OAuth. Per ulteriori informazioni, consulta la configurazione dell'host.

Il seguente esempio mostra come creare un cluster GKE chiamato traffic-director-cluster nella zona us-central1-a.

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 del cluster GKE richiesti

Per GKE, passa al cluster(2) appena creato emettendo il seguente comando. In questo modo, kubectl viene indirizzato 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 di deployment di Kubernetes per il funzionamento con Cloud Service Mesh. Consiste nella configurazione dei servizi con NEG e nell'iniezione 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à.

Per ulteriori informazioni, consulta configurare la regola firewall per i controlli di integrità.

Configurazione dei 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 poterlo trovare facilemente in un secondo momento. Il nome è necessario quando colleghi il NEG al servizio di backend Cloud Service Mesh. Per ulteriori informazioni sull'annotazione dei gruppi di esclusione di nome, consulta Nominare i gruppi di esclusione di nome.

...
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 gli endpoint che sono gli indirizzi IP e le 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 serve il suo nome host tramite HTTP sulla porta 80:

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

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

kubectl get svc

Restituisce:

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

kubectl get pods

Restituisce:

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       1/1       Running   0          6m
[..skip..]

Salvataggio del nome del NEG

Individua il gruppo NEG creato dall'esempio riportato sopra e registra il nome.

gcloud compute network-endpoint-groups list

NAME                 LOCATION          ENDPOINT_TYPE      SIZE
NEG-NAME           us-central1-a     GCE_VM_IP_PORT      1

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 riportate in questa sezione assicurano che i servizi GKE siano accessibili sull'indirizzo VIP del servizio bilanciato in base al carico da Cloud Service Mesh, utilizzando una configurazione di bilanciamento del carico simile ad altri prodotti Cloud Load Balancing di Google Cloud.

Devi configurare i seguenti componenti:

• Un controllo di integrità. Per ulteriori informazioni sui controlli di integrità, consulta Concetti dei controlli di integrità e Creazione di controlli di integrità.
• Un servizio di backend. Per saperne di più sui servizi di backend, consulta Servizi di backend.
• Una regola di route. Sono incluse la creazione di una regola di forwarding e di una mappa URL. Per ulteriori informazioni, leggi Utilizzare le regole di inoltro e Utilizzare le mappe URL.

L'esempio di configurazione di Cloud Service Mesh che segue fa queste ipotesi:

1. I NEG e tutte le altre risorse vengono creati nella rete default, con modalità automatica, nella zona us-central1-a.
2. Il nome del NEG per il cluster è memorizzato nella variabile ${NEG_NAME}.

Creazione del controllo di integrità

Crea il controllo di integrità.

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 INTERNAL_SELF_MANAGED. Nella console Google Cloud, lo schema di bilanciamento del carico viene impostato in modo implicito. Aggiungi il controllo di integrità al servizio di backend.

Creazione della mappa di regole di routing

Segui queste istruzioni per creare la regola di routing, 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 configurati nella mappa URL, indipendentemente dall'indirizzo IP effettivo a cui viene risolto il nome host. In questo caso, gli URL (nome host più percorso dell'URL) dei tuoi servizi, come configurati nelle regole host, devono essere univoci all'interno della configurazione del tuo mesh di servizi. In altre parole, 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 attivare il routing in base alla destinazione VIP effettiva del servizio. Se configuri l'IP virtuale del tuo servizio come parametro address della regola di forwarding, solo le richieste destinate a questo indirizzo IP vengono instradate in base ai parametri HTTP specificati nella mappa URL.

A questo punto, Cloud Service Mesh è configurato per bilanciare il carico del traffico per i servizi specificati nella mappa URL tra i backend nel gruppo di endpoint di rete.

A seconda di come i microservizi sono distribuiti sulla rete, potresti dover aggiungere altre regole di inoltro o altre regole host e percorso alla mappa URL.

Verifica della configurazione tramite il deployment di un client di esempio per i test

Questa sezione mostra come raggiungere i backend di 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 il traffico bilanciato in base al carico da Cloud Service Mesh.

Inserimento 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 contenitori init aggiunti al deployment utilizzando la specifica di riferimento.

Se utilizzi le API precedenti, sostituisci le variabili PROJECT_NUMBER e NETWORK_NAME con il numero del 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 instradamento dei servizi, attualmente in anteprima, sostituisci le variabili PROJECT_NUMBER e MESH_NAME con il numero e il nome del progetto 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 contenitore è il client basato sull'immagine Busybox e il secondo contenitore è il proxy Envoy iniettato come sidecar. Puoi ottenere ulteriori informazioni sul pod eseguendo il seguente comando:

kubectl describe pods -l run=client

Accesso al servizio di backend

Una volta configurate, le applicazioni sui 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 contenitori.

Se hai utilizzato la configurazione di prova fornita in questa guida, puoi eseguire il seguente comando di verifica per assicurarti che venga restituito il nome host del pod di pubblicazione.

# 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 sottoposta a proxy dal proxy sidecar.

Questa applicazione di dimostrazione utilizza il proxy Envoy. Per questo motivo, il client visualizza "server: envoy" nell'intestazione delle risposte del server.

Per confermare, 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, hai creato una regola di forwarding utilizzando l'indirizzo VIP 0.0.0.0. Ciò significa che Cloud Service Mesh inoltra le richieste al backend unicamente in base all'intestazione Host. In questo caso, l'indirizzo IP di destinazione può essere qualsiasi indirizzo, purché l'intestazione dell'host della richiesta corrisponda all'host definito nella mappa URL service-test.

Per confermare, esegui i seguenti comandi di test:

# 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 di deployment di Cloud Service Mesh.
• Scopri come configurare l'osservabilità con Envoy.