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 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 di aver completato i prerequisiti.

Puoi configurare Cloud Service Mesh utilizzando il bilanciamento del carico di Compute Engine l'SDK 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 attivare Cluster GKE/Kubernetes per l'uso con Cloud Service Mesh.

Creazione del cluster GKE

I cluster GKE devono soddisfare i seguenti requisiti:

L'esempio seguente mostra come creare un cluster GKE chiamata traffic-director-cluster nella zona us-central1-a.

Console

Per creare un cluster utilizzando la console Google Cloud, esegui queste operazioni: passaggi:

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

    Vai al menu Google Kubernetes Engine

  2. Fai clic su Crea cluster.

  3. Completa i seguenti campi:

    • Nome: inserisci traffic-director-cluster.
    • Tipo di posizione: 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 in un cluster Kubernetes. Devi avere una quota di risorse disponibile per i nodi e le relative risorse (ad esempio le route del firewall).

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

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

  8. Nel riquadro di navigazione, in default-pool, fai clic su Security (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 console Google Cloud, devi configurare kubectl per interagire con il cluster. Per saperne di più, consulta: Generazione di una voce kubeconfig in corso...

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 utilizzando il seguente 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 al funzionamento con Cloud Service Mesh. Ciò consiste nella configurazione dei servizi anche con NEG inserendo proxy sidecar nei pod che richiedono l'accesso ai servizi gestite da Cloud Service Mesh.

Configura la regola firewall

Per verificare che i pod di backend siano in esecuzione, devi configurare una regola firewall consentendo agli intervalli di indirizzi IP del controllo di integrità.

Console

  1. Vai alla pagina Criteri firewall nella console Google Cloud.
    Vai alla pagina Criteri firewall
  2. Fai clic su Crea regole firewall.
  3. 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: 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 controlla tcp. TCP è il protocollo sottostante per tutta l'integrità e controllare i protocolli.
    • Fai clic su Crea.

gcloud

  1. Utilizza il seguente comando gcloud per creare una regola firewall denominata fw-allow-health-checks che consente le connessioni in entrata alle istanze in la tua rete con il tag allow-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, vedi configurare una 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 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.

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

Per ciascun servizio, viene creato un NEG autonomo contenente gli endpoint 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 nome 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

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

Salvataggio del nome del NEG

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

Console

Per visualizzare un elenco dei gruppi di endpoint di rete, vai a 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 GKE sono accessibili con il carico VIP del servizio bilanciato da Cloud Service Mesh, utilizzando una configurazione di bilanciamento del carico simile ad altre Google Cloud Load Balancing.

Devi configurare i seguenti componenti:

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

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

Creazione del controllo di integrità

Crea il controllo 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.

gcloud 

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

Creazione del servizio di backend

Crea un account servizio di backend 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 l'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. In Tipo di backend, seleziona Gruppi di endpoint di rete.

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

  7. Imposta Numero massimo di RPS 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 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 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 Indirizzo IP per la configurazione di Cloud Service Mesh.

Il traffico inviato all'indirizzo IP interno viene intercettato dal proxy Envoy e inviati al servizio appropriato in base alle regole dell'host e del percorso.

La regola di forwarding viene creata come regola di forwarding globale con il load-balancing-scheme impostato su INTERNAL_SELF_MANAGED.

Puoi impostare l'indirizzo della regola di forwarding su 0.0.0.0. Se sì, il traffico viene instradato in base al nome host HTTP e alle informazioni sul percorso configurate in la mappa URL, a prescindere dall'indirizzo IP effettivo in cui viene risolto il nome host. In questo caso, gli URL (nome host più percorso URL) dei tuoi servizi, come configurato nelle regole dell'host, devono essere univoci all'interno della configurazione del mesh di servizi. Questo è che non puoi avere due servizi diversi, con set diversi di backend, che utilizzano la stessa combinazione di nome host e percorso.

In alternativa, puoi abilitare il routing in base al VIP di destinazione effettivo del completamente gestito di Google Cloud. Se configuri il VIP del 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 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. Creare 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 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 il nome del servizio e un matcher di percorso predefinito che corrisponde a tutti richieste per questo host (/*). Anche service-test è il tipo configurato nome del servizio Kubernetes utilizzato nell'esempio configurazione precedente.

    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 specificati nella mappa URL tra i backend nel gruppo di endpoint di rete.

A seconda di come i microservizi sono distribuiti sulla tua rete, devi aggiungere altre regole di forwarding o più regole 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 client un'applicazione.

Per dimostrare la funzionalità, puoi eseguire il deployment di un pod di esempio che esegue Busybox. La il pod ha accesso a service-test, che è stato creato nella sezione precedente e riceve traffico bilanciato da Cloud Service Mesh.

Iniezione di un proxy sidecar nei pod GKE / Kubernetes

Per accedere a un servizio gestito da Cloud Service Mesh, un pod deve avere un Proxy sidecar compatibile con l'API xDS installato.

In questo esempio, esegui il deployment di un client Busybox con un sidecar Istio-proxy e di container init aggiunti al deployment usando 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 la Variabili PROJECT_NUMBER e MESH_NAME con il progetto numero e 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 è basato sull'immagine Busybox e il secondo container è il proxy Envoy viene inserito come collaterale. Per ottenere ulteriori informazioni sul pod, esegui questo 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 a servizi gestiti dai servizi Cloud Service Mesh. Per verificare il puoi accedere a una shell su uno dei container.

Se hai utilizzato la configurazione demo fornita in questa guida, puoi eseguire il successivo al comando di verifica per assicurarti che il nome host del pod viene restituito.

# 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 alla servizio di backend, ogni richiesta viene inviata tramite proxy dal proxy sidecar.

Questa applicazione dimostrativa utilizza il proxy Envoy. Per questo motivo, il cliente 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 dell'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