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

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

Nota: gli esempi di configurazione sono a scopo dimostrativo. Potresti dover eseguire il deployment di componenti aggiuntivi in base al tuo ambiente e ai tuoi requisiti.

Prima di seguire le istruzioni riportate in questa guida, completa le attività preliminari descritte in Preparati per la configurazione delle API di routing dei servizi con Envoy e workload senza proxy.

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

Nota: questa guida supporta solo Cloud Service Mesh con le Google Cloud API e non supporta le API Istio. Per saperne di più, consulta la panoramica di Cloud Service Mesh. .

Configurare i cluster GKE/Kubernetes per Cloud Service Mesh

Questa sezione descrive i passaggi necessari per consentire ai cluster GKE/Kubernetes di funzionare con Cloud Service Mesh.

Creare il 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 Gruppi di endpoint di rete autonomi. La funzionalità NEG autonomi è in disponibilità generale per Cloud Service Mesh.
• Il 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 il account di servizio per accedere all'API Traffic Director.
  • Per informazioni sull'abilitazione dell'API Cloud Service Mesh, consulta Abilitare l'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.

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 Google Cloud console, segui questi passaggi:

1. Vai al menu Kubernetes Engine nella Google Cloud console.

   Vai al menu Google Kubernetes Engine

2. Fai clic su Crea cluster.

3. Completa i seguenti campi:

   • Nome: inserisci traffic-director-cluster.
   • Tipo di località: Zonal.
   • Zona: us-central1-a.

4. Nel riquadro di navigazione, in Pool di nodi, fai clic su default-pool.

5. 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 (ad esempio route firewall).

6. Nel riquadro di navigazione, in default-pool, fai clic su Nodi.

7. Il campo Tipo di macchina indica il tipo di macchina 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.

8. Nel riquadro di navigazione, in default-pool, fai clic su Sicurezza.

9. In Ambiti di accesso , fai clic su Consenti l'accesso completo a tutte le API Cloud.

10. Personalizza il cluster in base alle tue esigenze.

11. Fai clic su Crea.

Dopo aver creato un cluster nella Google Cloud console, devi configurare kubectl per interagire con il cluster. Per saperne di più, consulta Generare 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 del cluster GKE richiesti

Per GKE, passa al cluster(2) appena creato eseguendo il seguente comando. In questo modo, kubectl punta al cluster corretto.

gcloud container clusters get-credentials traffic-director-cluster \
    --zone us-central1-a

Configurare i servizi GKE/Kubernetes

Questa sezione mostra come preparare le specifiche di deployment di Kubernetes per funzionare con Cloud Service Mesh. Ciò comporta la configurazione dei servizi con i NEG e l'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

1. Vai alla pagina Policy del firewall nella Google Cloud console.
   Vai alla pagina Policy del firewall
2. Fai clic su Crea regole firewall.
3. Nella pagina Crea una regola firewall, fornisci le seguenti informazioni:
   • Nome: fornisci 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 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 di controllo di integrità.
   • Fai clic su Crea.

gcloud

1. Utilizza il seguente gcloud comando per creare una regola firewall denominata fw-allow-health-checks che consenta le connessioni in entrata alle istanze in rete con il tag allow-health-checks. Sostituisci NETWORK_NAME con il nome della 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 saperne di più, consulta Configurare la regola firewall per i controlli di integrità.

Configurare i servizi GKE / Kubernetes con i 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 riportato di seguito) in modo da poterlo trovare facilmente in un secondo momento. Ti serve il nome quando colleghi il NEG al servizio di backend Cloud Service Mesh. Per ulteriori informazioni sull'annotazione dei NEG, consulta Denominare i NEG.

Nota: Il pacchetto trafficdirector_service_sample.yaml fornito con questa guida alla configurazione utilizza il nome NEG service-test-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 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 pubblica il proprio 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

Che 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

Che restituisce:

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

Salvare il nome del NEG

Trova il NEG creato dall'esempio riportato sopra e registra il nome del NEG.

Console

Per visualizzare un elenco di gruppi di endpoint di rete, vai alla Network Endpoint Groups pagina nella Google Cloud console.
Vai alla pagina Gruppi di endpoint di rete

gcloud

gcloud compute network-endpoint-groups list

Che restituisce:

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}')

Nota: se hai assegnato un nome al NEG, come descritto in Configurare i servizi GKE con i NEG dovresti vedere che il nome del NEG corrisponde a quello fornito nella specifica del servizio Kubernetes. Se non hai assegnato un nome al NEG, ne viene generato automaticamente uno.

Configurare i componenti di bilanciamento del carico per Cloud Service Mesh Google Cloud

Le istruzioni riportate in questa sezione assicurano che i servizi GKE siano accessibili sul VIP del servizio con bilanciamento del carico da Cloud Service Mesh, utilizzando una configurazione di bilanciamento del carico simile ad altri prodotti Google Cloud Load Balancing.

Devi configurare i seguenti componenti:

• Un controllo di integrità. Per ulteriori informazioni sui controlli di integrità, consulta Concetti dei controlli di integrità e Creare 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 saperne di più, consulta Utilizzare le regole di forwarding e Utilizzare le mappe URL.

L'esempio di configurazione di Cloud Service Mesh riportato di seguito presuppone quanto segue:

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

Creare il controllo di integrità

Crea il controllo di integrità.

Console

1. Vai alla pagina Controlli di integrità nella Google Cloud console.
   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.

gcloud

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

Creare il servizio di backend

Crea un servizio di backend globale con uno schema di bilanciamento del carico INTERNAL_SELF_MANAGED. Nella Google Cloud console, lo schema di bilanciamento del carico viene impostato implicitamente. Aggiungi il controllo di integrità al servizio di backend.

Console

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

   Vai alla pagina 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. In Tipo di backend, seleziona Gruppi di endpoint di rete.

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

7. Imposta RPS massimo su 5.

8. Fai clic su Fine.

9. In Controllo di integrità, seleziona td-gke-health-check, ovvero il controllo di integrità che hai creato.

10. Fai clic su Continua.

gcloud

1. Crea il servizio di backend e associa 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
   

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

Creare la 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 diretto 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 instradato in base alle informazioni sul nome host e sul percorso HTTP configurate nella mappa URL, indipendentemente dall'indirizzo IP effettivo a cui il nome host viene risolto. In questo caso, gli URL (nome host più percorso URL) dei tuoi servizi, come configurati nelle regole host, devono essere univoci all'interno della configurazione del mesh di servizi. Ciò significa che non puoi avere due servizi diversi, con un insieme di backend diversi, che utilizzano 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, solo le richieste destinate a questo indirizzo IP vengono instradate in base ai parametri HTTP specificati nella mappa URL.

Nota: indipendentemente dal metodo selezionato, il traffico verso l'indirizzo VIP a cui il nome host del servizio viene risolto deve essere intercettato dal proxy sidecar sull'host client che deve accedere al servizio. Per informazioni dettagliate sulla configurazione dell'host, consulta Configurare una singola VM Compute Engine per Cloud Service Mesh.

Nota: ogni regola di forwarding in una rete VPC deve avere una combinazione univoca di indirizzo IP e porta per rete VPC, incluso l'indirizzo 0.0.0.0. Se crei più di una regola di forwarding con lo stesso indirizzo IP e la stessa porta in una determinata rete VPC, solo la prima regola di forwarding è valida. Le altre vengono ignorate.

Console

Nella console, il proxy di destinazione viene combinato con la regola di forwarding. Quando crei la regola di forwarding, Google Cloud viene creato automaticamente un proxy HTTP di destinazione e viene collegato alla mappa URL.

La regola di route è costituita dalla regola di forwarding e dalle regole host e percorso (note anche come mappa URL).

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

   Vai alla pagina 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. (Facoltativo) Aggiungi regole host e percorso personalizzate o lascia le regole di percorso come predefinite.

11. Imposta l'host su service-test.

12. Fai clic su Salva.

gcloud

1. Crea una mappa URL che utilizzi il servizio di backend.

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

2. Crea un matcher percorso della mappa URL e una regola host per instradare il traffico per il tuo servizio in base al nome host e a un percorso. Questo esempio utilizza service-test come nome del servizio e un matcher percorso predefinito che corrisponde a 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
   

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 è 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 della distribuzione dei microservizi sulla rete, potresti dover aggiungere altre regole di forwarding o altre regole host e percorso alla mappa URL.

Verificare la configurazione eseguendo 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 con bilanciamento del carico da Cloud Service Mesh.

Inserire un proxy sidecar nei pod GKE / Kubernetes

Per accedere a un servizio gestito da Cloud Service Mesh, un pod deve avere 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 container di inizializzazione 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 PROJECT_NUMBER e MESH_NAME variabili con il numero di 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 sidecar. Puoi ottenere ulteriori informazioni sul pod eseguendo il seguente comando:

kubectl describe pods -l run=client

Raggiungere il 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 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 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"

Comprendere l'intercettazione del traffico da parte del proxy sidecar

Tieni presente che, in questo esempio, quando il client Busybox effettua richieste al servizio di backend, ogni richiesta viene sottoposta a 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, 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 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 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 relativi ai deployment di Cloud Service Mesh.
• Scopri come configurare l'osservabilità con Envoy.