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

Panoramica

In un'architettura mesh di servizi, il codice dell'applicazione non deve conoscere la configurazione di rete. Le applicazioni comunicano invece tramite un piano dati, che viene configurato da un piano di controllo che gestisce la rete di servizi. In questa guida, Cloud Service Mesh è il tuo piano di controllo e i proxy sidecar Envoy sono il tuo piano dati.

L'iniettore di sidecar Envoy gestito da Google aggiunge proxy sidecar Envoy ai pod Google Kubernetes Engine. Quando l'iniettore sidecar Envoy aggiunge un proxy, lo configura anche per gestire il traffico delle applicazioni e connettersi a Cloud Service Mesh per la configurazione.

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

La procedura di configurazione prevede:

1. Crea un cluster GKE per i tuoi carichi di lavoro.
2. Installazione dell'iniettore sidecar Envoy e attivazione dell'iniezione.
3. Deployment di un client di esempio e verifica dell'iniezione.
4. Deployment di un servizio Kubernetes per i test.
5. Configurazione di Cloud Service Mesh con i componenti Cloud Load Balancing per instradare il traffico al servizio di test.
6. Verificare la configurazione inviando una richiesta dal client di esempio al servizio di test.

Prerequisiti

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.

Per informazioni sulla versione di Envoy supportata, consulta le note di rilascio di Cloud Service Mesh.

Prerequisiti aggiuntivi con VPC condiviso

Se stai configurando Cloud Service Mesh in un ambiente VPC condiviso, assicurati di quanto segue.

• Disponi delle autorizzazioni e dei ruoli corretti per VPC condiviso.
• Hai configurato i progetti e la fatturazione corretti.
• Hai attivato la fatturazione nei progetti.
• Hai attivato le API Cloud Service Mesh 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 subnet.
• Hai attivato la rete VPC condiviso.

Per ulteriori informazioni, consulta VPC condiviso.

Configura i ruoli IAM

Questo esempio di configurazione dei ruoli IAM presuppone che il progetto host per il VPC condiviso abbia due subnet e che nel VPC condiviso siano presenti due progetti di servizio.

1. In Cloud Shell, crea una cartella di lavoro (WORKDIR)) in cui creare i file associati a questa sezione:

   mkdir -p ~/td-shared-vpc
   cd ~/td-shared-vpc
   export WORKDIR=$(pwd)
   

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

   In questo passaggio, configuri 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. Assegna il ruolo IAM Utente della 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 sottorete.

   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 ogni progetto di servizio, devi concedere il ruolo IAM Utente agente di servizio host 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), utilizza l'account di servizio dell'host della macchina virtuale (VM) Compute Engine o dell'istanza del nodo GKE. L'account di servizio deve disporre dell'autorizzazione IAM a livello di progetto compute.globalForwardingRules.get. Per questo passaggio è sufficiente il ruolo Visualizzatore della rete Compute.

Configura le informazioni del progetto

Se non hai ancora creato il progetto Google Cloud o installato Google Cloud CLI, segui queste istruzioni. Se non hai ancora installato kubectl, segui queste istruzioni.

# The project that contains your GKE cluster.
export CLUSTER_PROJECT_ID=YOUR_CLUSTER_PROJECT_NUMBER_HERE
# The name of your GKE cluster.
export CLUSTER=YOUR_CLUSTER_NAME
# The channel of your GKE cluster. Eg: rapid, regular, stable. This channel
# should match the channel of your GKE cluster.
export CHANNEL=YOUR_CLUSTER_CHANNEL
# The location of your GKE cluster, Eg: us-central1 for regional GKE cluster,
# us-central1-a for zonal GKE cluster
export LOCATION=ZONE

# The network name of the traffic director load balancing API.
export MESH_NAME=default
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/global/networks/${MESH_NAME}

gcloud config set project ${CLUSTER_PROJECT_ID}

Se utilizzi le nuove API di routing dei servizi, segui le istruzioni riportate di seguito per impostare MESH_NAME, MESH_PROJECT_NUMBER e TARGET:

# The mesh name of the traffic director load balancing API.
export MESH_NAME=YOUR_MESH_NAME
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/locations/global/meshes/${MESH_NAME}

Nella maggior parte degli scenari, CLUSTER_PROJECT_ID e MESH_PROJECT_NUMBER fanno riferimento allo stesso progetto. Tuttavia, se configuri un progetto diverso, ad esempio quando utilizzi un VPC condiviso, CLUSTER_PROJECT_ID fa riferimento all'ID progetto che contiene il tuo cluster GKE e MESH_PROJECT_NUMBER fa riferimento al numero di progetto che contiene le risorse. Assicurati di aver configurato le autorizzazioni appropriate per consentire all'envoy iniettato di recuperare le configurazioni dal

Abilita l'API Mesh Config

Abilita la seguente API per iniziare a utilizzare l'iniettore sidecar gestito da Google.

gcloud services enable --project=${CLUSTER_PROJECT_ID} meshconfig.googleapis.com

Creare un cluster GKE per i tuoi carichi di lavoro

I cluster GKE devono soddisfare i seguenti requisiti per supportare Cloud Service Mesh:

• Il supporto dei gruppi di endpoint di rete deve essere abilitato. Per ulteriori informazioni e esempi, consulta Gruppi di endpoint di rete autonomi.
• L'account di servizio per i nodi/i pod GKE deve avere l'autorizzazione per accedere all'API Traffic Director. Per ulteriori informazioni sulle autorizzazioni richieste, consulta Abilitare l'account di servizio per accedere all'API Traffic Director.

Creazione del cluster GKE

Crea un cluster GKE nella tua zona preferita, ad esempious-central1-a.

gcloud container clusters create YOUR_CLUSTER_NAME \
  --zone ZONE \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

Indicare a kubectl il cluster appena creato

Modifica il contesto corrente per kubectl nel cluster appena creato emettendo il seguente comando:

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

Applica le configurazioni per il webhook con mutazioni

Le sezioni seguenti forniscono istruzioni per applicare MutatingWebhookConfiguration al cluster. Quando viene creato un pod, viene invocato il controller di ammissione nel cluster. Il controller di ammissione comunica con l'iniettore sidecar gestito per aggiungere il contenitore Envoy al pod.

Applica le seguenti configurazioni di webhook con mutazioni al tuo cluster.

cat <<EOF | kubectl apply -f -
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  labels:
    app: sidecar-injector
  name: td-mutating-webhook
webhooks:
- admissionReviewVersions:
  - v1beta1
  - v1
  clientConfig:
    url: https://meshconfig.googleapis.com/v1internal/projects/${CLUSTER_PROJECT_ID}/locations/${LOCATION}/clusters/${CLUSTER}/channels/${CHANNEL}/targets/${TARGET}:tdInject
  failurePolicy: Fail
  matchPolicy: Exact
  name: namespace.sidecar-injector.csm.io
  namespaceSelector:
    matchExpressions:
    - key: td-injection
      operator: Exists
  reinvocationPolicy: Never
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods
    scope: '*'
  sideEffects: None
  timeoutSeconds: 30
EOF

Attivazione dell'iniezione di sidecar

Il seguente comando attiva l'iniezione per lo spazio dei nomi default. L'iniettore sidecar inietta i container sidecar nei pod creati in questo spazio dei nomi:

kubectl label namespace default td-injection=enabled

Puoi verificare che lo spazio dei nomi default sia abilitato correttamente eseguendo il seguente comando:

kubectl get namespace -L td-injection

Dovresti visualizzare:

NAME              STATUS   AGE     TD-INJECTION
default           Active   7d16h   enabled

Se stai configurando la sicurezza dei servizi per Cloud Service Mesh con Envoy, riprendi dalla sezione Configurazione di un servizio di test nella guida alla configurazione.

Esegui il deployment di un client di esempio e verifica l'iniezione

Questa sezione mostra come eseguire il deployment di un pod di esempio che esegue Busybox, che fornisce un'interfaccia semplice per raggiungere un servizio di test. In un deployment reale, invece, eseguiresti il deployment della tua applicazione client.

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: client
  name: busybox
spec:
  replicas: 1
  selector:
    matchLabels:
      run: client
  template:
    metadata:
      labels:
        run: client
    spec:
      containers:
      - name: busybox
        image: busybox
        command:
        - sh
        - -c
        - while true; do sleep 1; done
EOF

Il pod Busybox è costituito da due container. Il primo contenitore è il client basato sull'immagine Busybox e il secondo contenitore è il proxy Envoy iniettato dall'iniettore sidecar. Per ulteriori informazioni sul pod, esegui il seguente comando:

kubectl describe pods -l run=client

Dovresti visualizzare:

…
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:
…

Proxy Cloud Service Mesh

L'iniettore di sidecar gestito utilizzerà l'immagine Cloud Service Mesh Proxy come proxy. Cloud Service Mesh Proxy è un container sidecar responsabile dell'avvio di un proxy Envoy per le istanze compatibili con il mesh. L'immagine proxy utilizza l'immagine di Envoy OSS insieme a un agente proxy responsabile dell'avvio di Envoy, della configurazione di bootstrap e del controllo dell'integrità di Envoy. Le versioni delle immagini del proxy Cloud Service Mesh sono in linea con la versione di Envoy OSS. Puoi monitorare le immagini proxy disponibili qui: https://gcr.io/gke-release/asm/csm-mesh-proxy

Il proxy mesh di Cloud Service Mesh che viene iniettato varia in base al canale scelto dall'utente per il cluster GKE. La versione di Envoy viene aggiornata regolarmente in base alle release di Envoy OSS correnti e viene testata con la release GKE specifica per garantire la compatibilità.

Versione di Cloud Service Mesh Proxy

La tabella seguente mostra la mappatura della versione del proxy Cloud Service Mesh al canale del cluster GKE corrente:

Upgrade di Cloud Service Mesh Proxy

Ti consigliamo vivamente di eseguire l'upgrade alla versione più recente. Anche se il servizio mesh funziona correttamente quando il piano di controllo e i proxy sono in versioni diverse, consigliamo di aggiornare i proxy in modo che siano configurati con la nuova versione di Cloud Service Mesh.

L'iniettore sidecar gestito si occupa della versione di Envoy, che inietta sempre la versione più recente di Envoy qualificata da Google. Se la versione di Cloud Service Mesh Proxy è più recente della versione del proxy, riavvia i proxy per i tuoi servizi.

kubectl rollout restart deployment -n YOUR_NAMESPACE_HERE

Eseguire il deployment di un servizio Kubernetes per i test

Le sezioni seguenti forniscono istruzioni per configurare un servizio di test che utilizzerai più avanti in questa guida per eseguire 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 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 NEG, consulta Nominare i NEG.

...
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 e esempi, consulta la sezione Gruppi autonomi di endpoint di rete.

Il seguente servizio di esempio include l'annotazione NEG. Il servizio pubblica il nome host tramite HTTP sulla porta 80. Utilizza il seguente comando per recuperare il servizio ed eseguirlo 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

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 del NEG

Individua il NEG creato dall'esempio precedente e annota il nome per la configurazione di Cloud Service Mesh nella sezione successiva.

gcloud compute network-endpoint-groups list

Viene restituito 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 Cloud Service Mesh con i componenti di Cloud Load Balancing

Questa sezione configura Cloud Service Mesh 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 Cloud Service Mesh. Le richieste in uscita del client di esempio vengono gestite dal proxy sidecar e instradate al servizio di test.

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 mappa di regole di routing. Ciò include la creazione di una regola di forwarding, un proxy HTTP di destinazione e una mappa URL. Per saperne di più, consulta Utilizzare le regole di inoltro per Cloud Service Mesh, Utilizzare i proxy target per Cloud Service Mesh e Utilizzare le mappe URL.

Creazione del controllo di integrità e della regola firewall

Segui le istruzioni riportate di seguito per creare un controllo di integrità e la regola firewall necessaria per i controlli di integrità. Per ulteriori informazioni, consulta Regole firewall per i controlli di integrità.

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 viene impostato in modo implicito. Aggiungi il controllo di integrità al servizio di backend.

Creazione della mappa di regole di routing

La mappa delle regole di routing definisce il modo in cui Cloud Service Mesh instrada il traffico nel tuo mesh. Nell'ambito della mappa delle regole di routing, configuri un indirizzo IP virtuale (VIP) e un insieme di regole di gestione del traffico associate, ad esempio il routing basato sull'host. Quando un'applicazione invia una richiesta al VIP, il proxy sidecar Envoy collegato esegue le seguenti operazioni:

1. Intercetta la richiesta.
2. Lo valuta in base alle regole di gestione del traffico nella mappa URL.
3. Seleziona un servizio di backend in base al nome host nella richiesta.
4. Scegli un backend o un endpoint associato al servizio di backend selezionato.
5. Invia traffico a quel backend o endpoint.

A questo punto, Cloud Service Mesh configura i proxy sidecar per inoltrare le richieste che specificano il nome host service-test ai backend di td-gke-service. In questo caso, questi 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 Busybox di esempio venga instradato al servizio Kubernetes service-test. Per inviare una richiesta di test, puoi accedere a una shell su uno dei contenitori ed eseguire il seguente comando di verifica. Un pod service-test deve restituire il nome host del pod di pubblicazione.

# 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 che è stato iniettato dall'iniettore sidecar Envoy.
• Il proxy sidecar ha intercettato la richiesta.
• Utilizzando la mappa URL, Envoy ha associato il nome host service-test al servizio Cloud Service Mesh td-gke-service.
• 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.

Come eseguire la migrazione a Managed Sidecar Injector

Questo tutorial descrive la procedura per eseguire la migrazione di un'applicazione dall'iniettore sidecar Cloud Service Mesh precedente su GKE (con un iniettore sidecar in-cluster) a un iniettore sidecar gestito.

Disabilitazione dell'iniezione di sidecar all'interno del cluster

I seguenti comandi disattivano l'iniettatore sidecar in-cluster precedente per lo spazio dei nomi predefinito

kubectl label namespace default istio-injection-

Pulisci l'iniettore sidecar in-cluster

Scarica ed estrai l'iniettore di sidecar Envoy precedente.

wget https://storage.googleapis.com/traffic-director/td-sidecar-injector-xdsv3.tgz
tar -xzvf td-sidecar-injector-xdsv3.tgz
cd td-sidecar-injector-xdsv3

Eliminare le risorse di iniettori sidecar all'interno del cluster

kubectl delete -f specs/

Passaggi successivi

• Scopri di più sulla gestione avanzata del traffico
• Scopri di più sulla sicurezza del servizio Cloud Service Mesh.
• Scopri come configurare l'osservabilità con Envoy.
• Scopri come risolvere i problemi di deployment di Cloud Service Mesh.
• Scopri le opzioni per la configurazione del pod di Google Kubernetes Engine con inserimento Envoy automatico.