Configurare i pod di Google Kubernetes Engine utilizzando l'iniezione automatica di Envoy

Panoramica

In un mesh di servizi, il codice dell'applicazione non ha bisogno di conoscere la configurazione di rete. Le tue applicazioni comunicano, invece, tramite un piano dati, configurato da un piano di controllo che gestisce il networking di servizi. In questa guida, Traffic Director è il tuo piano di controllo e i proxy sidecar Envoy sono il tuo piano dati.

L'iniettore del sidecar Envoy semplifica l'aggiunta dei proxy sidecar Envoy ai pod di Google Kubernetes Engine. Quando l'iniettore sidecar Envoy aggiunge un proxy, lo imposta anche per gestire il traffico delle applicazioni e connettersi a Traffic Director per la configurazione.

La guida illustra una semplice configurazione di Traffic Director con Google Kubernetes Engine. Questi passaggi forniscono le basi che puoi estendere ai casi d'uso avanzati, ad esempio un mesh di servizi che si estende su più cluster Google Kubernetes Engine e, potenzialmente, le VM di Compute Engine. Puoi utilizzare queste istruzioni anche se stai configurando Traffic Director con VPC condiviso.

La procedura di configurazione prevede:

  1. Creazione di un cluster GKE per i carichi di lavoro.
  2. Installazione dell'iniettore sidecar Envoy e abilitazione dell'iniezione.
  3. Deployment di un client di esempio e verifica dell'inserimento.
  4. Deployment di un servizio Kubernetes per i test.
  5. Configurazione di Traffic Director con componenti Cloud Load Balancing per instradare il traffico al servizio di test.
  6. Verifica della configurazione inviando una richiesta dal client di esempio al servizio di test.
Panoramica dei componenti di cui è stato eseguito il deployment come parte di questa guida alla configurazione (fai clic per ingrandire)
Panoramica dei componenti di cui è stato eseguito il deployment nell'ambito di questa guida alla configurazione (fai clic per ingrandire)

Prerequisiti

Prima di seguire le istruzioni in questa guida, consulta la pagina Preparazione alla configurazione di Traffic Director e assicurati di aver completato le attività preliminari descritte nel documento.

Per informazioni sulla versione di Envoy supportata, consulta le note di rilascio di Traffic Director.

Prerequisiti aggiuntivi con VPC condiviso

Se stai configurando Traffic Director in un ambiente VPC condiviso, assicurati di quanto segue.

  • Disponi delle autorizzazioni e dei ruoli corretti per un VPC condiviso.
  • Hai configurato i progetti e la fatturazione corretti.
  • Hai abilitato la fatturazione nei progetti.
  • Hai abilitato le API Traffic Director e GKE in ogni progetto, incluso il progetto host.
  • Hai configurato gli account di servizio corretti per ogni progetto.
  • Hai creato una rete VPC e delle subnet.
  • Hai abilitato la rete VPC condiviso.

Per saperne di più, consulta VPC condiviso.

Configura i ruoli IAM

Questo esempio di configurazione del ruolo IAM presuppone che il progetto host per VPC condiviso abbia due subnet e che ci siano due progetti di servizio nel VPC condiviso.

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

  2. Configurare le autorizzazioni IAM nel progetto host in modo che i progetti di servizio possano utilizzare le risorse nel VPC condiviso.

    In questo passaggio devi configurare le autorizzazioni IAM in modo che subnet-1 sia accessibile dal progetto di servizio 1 e subnet-2 sia accessibile dal progetto di servizio 2. Assegni il ruolo IAM Utente di rete Compute (roles/compute.networkUser) sia all'account di servizio predefinito di Compute Engine sia all'account di servizio dell'API Google Cloud in ogni progetto di servizio per ogni subnet.

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

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

  3. Per ciascun progetto di servizio, devi concedere il ruolo IAM Utente agente di servizio host di 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 le risorse di rete condivise.

  4. Per ogni progetto di servizio, concedi all'account di servizio predefinito di Compute Engine il ruolo IAM Visualizzatore 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 Envoy si connette al servizio xDS (API Traffic Director), il proxy utilizza l'account di servizio dell'host della macchina virtuale (VM) Compute Engine o dell'istanza del nodo GKE. L'account di servizio deve avere l'autorizzazione IAM a livello di progetto compute.globalForwardingRules.get. Per questo passaggio è sufficiente il ruolo Visualizzatore di rete Compute.

Creazione di un cluster GKE per i carichi di lavoro

I cluster GKE devono soddisfare i seguenti requisiti per supportare Traffic Director:

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

Puntando kubectl al cluster appena creato

Modifica il contesto attuale per kubectl nel cluster appena creato eseguendo il comando seguente:

gcloud container clusters get-credentials traffic-director-cluster \
    --zone ZONE

Installazione dell'iniettore sidecar Envoy

Le seguenti sezioni forniscono le istruzioni per l'installazione dell'iniettore sidecar Envoy. Quando l'iniettore sidecar è abilitato, esegue automaticamente il deployment dei proxy sidecar per i carichi di lavoro Google Kubernetes Engine nuovi ed esistenti. Poiché l'iniettore sidecar Envoy viene eseguito all'interno del cluster GKE, devi installarlo una volta per ciascun cluster se utilizzi Traffic Director per supportare un mesh di servizi multi-cluster.

Download dell'iniettore del sidecar

Scarica ed estrai l'iniettore sidecar 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 sidecar

Se utilizzi le API meno recenti, configura l'iniettore sidecar modificando il file specs/01-configmap.yaml in:

  • Completa TRAFFICDIRECTOR_GCP_PROJECT_NUMBER sostituendo YOUR_PROJECT_NUMBER_HERE con il numero del tuo progetto. Il numero di progetto è un identificatore numerico per il tuo progetto. Per informazioni su come ottenere un elenco di tutti i progetti, consulta Identificazione dei progetti.
  • Completa TRAFFICDIRECTOR_NETWORK_NAME sostituendo YOUR_NETWORK_NAME_HERE con il nome della rete Virtual Private Cloud di Google Cloud che vuoi utilizzare con Traffic Director. Prendi nota di questo nome di rete VPC, perché ti servirà in seguito durante la configurazione di Traffic Director.

Se utilizzi le nuove API di routing dei servizi, attualmente in anteprima:

  • Completa TRAFFICDIRECTOR_MESH_NAME sostituendo "" con il nome del mesh di servizi, per ottenere la configurazione di un mesh di servizi.
    • Tieni presente che se stai configurando un Gateway, non utilizzare l'iniettore sidecar. Esegui il deployment di un proxy Envoy come pod.

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 Traffic Director 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 Traffic Director (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 abilitare il logging e il tracciamento per ogni proxy inserito automaticamente. Per ulteriori informazioni su queste configurazioni, consulta la pagina Configurare attributi aggiuntivi per i proxy sidecar. Quando utilizzi l'iniettore sidecar, il valore 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 sidecar.

Configurazione di TLS per l'iniettore sidecar

Questa sezione mostra come configurare TLS per l'iniettore sidecar.

L'iniettore sidecar utilizza un hook di ammissione mutante 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 del sidecar.

Facoltativamente, se hai la tua chiave privata e il tuo 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 di esempio di openssl restituisce una chiave RSA privata a 4096 bit in key.pem e un certificato autofirmato in formato X.509 a cert.pem. Poiché il certificato è autofirmato, il certificato 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 scoprire di più sulla creazione e sulla firma dei certificati, consulta la documentazione di Kubernetes sulle richieste di firma dei certificati.

I passaggi in questa sezione devono essere ripetuti ogni anno per rigenerare e applicare nuovamente le nuove chiavi e i nuovi certificati prima della loro scadenza.

Dopo aver trovato la chiave e i certificati, devi creare un secret Kubernetes e aggiornare il webhook dell'iniettore sidecar.

  1. Crea lo spazio dei nomi in cui deve essere creato il secret di Kubernetes:

    kubectl apply -f specs/00-namespaces.yaml

  2. Crea il secret per l'iniettore sidecar.

    kubectl create secret generic istio-sidecar-injector -n istio-control \
  --from-file=key.pem \
  --from-file=cert.pem \
  --from-file=ca-cert.pem

  3. Modifica il caBundle del webhook di iniezione sidecar denominato istio-sidecar-injector-istio-control in specs/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 dell'iniettore sidecar nel cluster GKE in corso...

  1. Esegui il deployment dell'iniettore sidecar.

    kubectl apply -f specs/

  2. Verifica che l'iniettore del sidecar sia in esecuzione.

    kubectl get pods -A | grep sidecar-injector

    L'output restituito è 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

Se stai seguendo le istruzioni per configurare la sicurezza dei servizi di Traffic Director con Envoy, puoi saltare questa sezione e passare a quella successiva, Attivare l'inserimento di sidecar.

Se stai installando l'iniettore sidecar Envoy su un cluster privato, per consentire il corretto funzionamento del webhook, devi aprire la porta TCP 9443 nella regola firewall nei nodi master.

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) e la nuova porta che vuoi aprire.

  1. Trova l'intervallo di origine (master-ipv4-cidr) del cluster. Nel comando seguente, sostituisci CLUSTER_NAME con il nome del tuo cluster, ad esempio traffic-director-cluster:

    FIREWALL_RULE_NAME=$(gcloud compute firewall-rules list \
 --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master" \
 --format="value(name)")

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

Abilitazione dell'iniezione di sidecar

Il seguente comando consente l'inserimento per lo spazio dei nomi default. L'iniettore sidecar inserisce i container sidecar 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 il comando seguente:

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 dei servizi per Traffic Director 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 esegueOcebox, che fornisce un'interfaccia semplice per raggiungere un servizio di test. In un deployment reale, dovresti invece eseguire il deployment della tua applicazione client.

kubectl create -f demo/client_sample.yaml

Il pod Workloadbox è costituito da due container. Il primo container è il client basato sull'immagine occupata e il secondo container è il proxy Envoy inserito dall'iniettore sidecar. Puoi ottenere maggiori informazioni sul pod eseguendo questo comando:

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 seguenti sezioni forniscono le istruzioni per configurare un servizio di test che utilizzerai più avanti in questa guida per fornire la verifica end-to-end della configurazione.

Configurazione dei 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 Traffic Director. 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 facilmente in un secondo momento. È necessario il nome quando colleghi il NEG al servizio di backend Traffic Director. Per ulteriori informazioni sull'annotazione dei NEG, consulta i NEG per l'assegnazione di nomi.

...
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 la pagina Gruppi di endpoint di rete autonomi.

Il seguente servizio di esempio include l'annotazione NEG. Il servizio gestisce il nome host tramite HTTP sulla porta 80. Utilizza il comando seguente per ottenere il servizio e eseguirne il deployment nel tuo 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 pods
Questo restituisce: 
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 NEG in corso

Trova il NEG creato nell'esempio precedente e registra il nome per la configurazione di Traffic Director nella sezione successiva.

gcloud compute network-endpoint-groups list

che restituisce 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 Traffic Director con i componenti di Cloud Load Balancing

Questa sezione configura Traffic Director utilizzando le risorse di bilanciamento del carico di Compute Engine. In questo modo, il proxy sidecar del client di esempio può ricevere la configurazione da Traffic Director. Le richieste in uscita dal client di esempio vengono gestite dal proxy sidecar e indirizzate al servizio di test.

Devi configurare i seguenti componenti:

Creazione del controllo di integrità e della regola firewall

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. Per il protocollo, seleziona HTTP.

  5. Fai clic su Crea.

  6. Vai alla pagina Firewall nella console Google Cloud.
    Vai alla pagina Firewall

  7. Fai clic su Crea regola firewall.

  8. Nella pagina Crea una regola firewall, fornisci le seguenti informazioni:

    • Nome: specifica un nome per la regola. In questo esempio, utilizza fw-allow-health-checks.
    • Rete: scegli una rete VPC.
    • Priorità: inserisci un numero per la priorità. Un numero inferiore ha priorità più elevate. Assicurati che la regola firewall abbia una priorità superiore rispetto alle altre che potrebbero rifiutare il traffico in entrata.
    • Direzione del traffico: seleziona in entrata.
    • Azione in caso di corrispondenza: scegli consenti.
    • Destinazioni: scegli Tutte le istanze nella rete.
    • Filtro di origine: scegli Intervalli IP.
    • Intervalli IP di origine: 35.191.0.0/16,130.211.0.0/22
    • Protocolli e porte consentiti: usa tcp. TCP è il protocollo sottostante per tutti i protocolli di controllo di integrità.
    • Fai clic su Crea.

gcloud

  1. Crea il controllo di integrità.

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

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

Console

  1. Vai alla pagina Traffic Director nella console Google Cloud.

    Vai alla pagina Traffic Director

  2. Nella scheda Servizi, fai clic su Crea servizio.

  3. Fai clic su Continua.

  4. Come nome del servizio, inserisci td-gke-service.

  5. Seleziona Network, che hai configurato in ConfigMap di Traffic Director.

  6. In Tipo di backend, seleziona Gruppi di endpoint di rete.

  7. Seleziona il gruppo di endpoint di rete creato.

  8. Imposta il valore RPS massimo su 5.

  9. Imposta la modalità di bilanciamento su Tariffa.

  10. Fai clic su Fine.

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

  12. Fai clic su Continua.

gcloud

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

  2. Aggiungi il NEG creato in precedenza come backend al servizio di backend. Se stai configurando Traffic Director 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 Traffic Director instrada il traffico nel tuo mesh. Nell'ambito della mappa di regole di routing, configuri un indirizzo IP virtuale (VIP) e un insieme di regole di gestione del traffico associate, come il routing basato su host. Quando un'applicazione invia una richiesta al VIP, il proxy sidecar Envoy collegato esegue le seguenti operazioni:

  1. Intercetta la richiesta.
  2. Valuta i risultati in base alle regole di gestione del traffico presenti nella mappa URL.
  3. Seleziona un servizio di backend in base al nome host nella richiesta.
  4. Sceglie un backend o un endpoint associato al servizio di backend selezionato.
  5. Invia il traffico a tale backend o endpoint.

Console

Nella console, il proxy di destinazione viene 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 routing è composta dalla regola di forwarding e dalle regole host e percorso (note anche come mappe URL).

  1. Vai alla pagina Traffic Director nella console Google Cloud.

    Vai alla pagina Traffic Director

  2. Fai clic su Mappe delle 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. Inserisci td-gke-forwarding-rule per il nome della regola di forwarding.

  7. Seleziona la rete.

  8. Seleziona il tuo IP interno.

  9. Fai clic su Salva.

  10. Facoltativamente, aggiungi regole personalizzate per l'host e il percorso oppure lasciale impostate come predefinite.

  11. Imposta l'host su service-test.

  12. Fai clic su Salva.

gcloud

  1. Crea una mappa URL che utilizza td-gke-service come servizio di backend predefinito.

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

  2. Creare un matcher percorso mappa di URL e una regola host per instradare il traffico per il 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 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

  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, Traffic Director configura i proxy sidecar per instradare le richieste che specificano il nome host service-test ai backend di td-gke-service. In questo caso, tali 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

Questa sezione mostra come verificare che il traffico inviato dal client Stackdriver (ad esempio) sia instradato al servizio Kubernetes service-test. Per inviare una richiesta di test, puoi accedere a una shell su uno dei container ed eseguire il seguente comando di verifica. Un pod service-test dovrebbe restituire il nome host del pod di gestione.

# 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 Envoy.
  • Il proxy sidecar ha intercettato la richiesta.
  • Mediante la mappa URL, Envoy ha associato il nome host service-test al servizio td-gke-service Traffic Director.
  • 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