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

Panoramica

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

Lo strumento di inserimento sidecar Envoy gestito da Google aggiunge proxy sidecar Envoy ai tuoi pod Google Kubernetes Engine. Quando l'iniettore sidecar Envoy aggiunge un proxy, lo configura anche per gestire il traffico dell'applicazione 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 anche utilizzare queste istruzioni se stai configurando Cloud Service Mesh con VPC condiviso.

La procedura di configurazione prevede:

1. Creazione di un cluster GKE per i tuoi carichi di lavoro.
2. Installazione dell'inserimento di sidecar Envoy e attivazione dell'inserimento.
3. Deployment di un client di esempio e verifica dell'inserimento.
4. Deployment di un servizio Kubernetes per il test.
5. Configurazione di Cloud Service Mesh con i componenti di 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.

Prerequisiti

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.

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

Prerequisiti aggiuntivi con il 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 il VPC condiviso.
• Hai configurato i progetti e la fatturazione corretti.
• Hai abilitato la fatturazione nei progetti.
• Hai abilitato 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 le relative subnet.
• Hai attivato il VPC condiviso.

Per saperne di più, 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 rete Compute (roles/compute.networkUser) sia all'account di servizio predefinito di Compute Engine sia all'account di servizio API in ogni progetto di servizio per ogni subnet. Google Cloud

   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 service agent host di Kubernetes Engine (roles/container.hostServiceAgentUser) al 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 al account di servizio GKE del progetto di servizio di utilizzare il account di servizio GKE del progetto host per configurare le risorse di rete condivise.

4. Per ogni progetto di servizio, concedi al service account predefinito di Compute Engine il ruolo IAM Compute Network Viewer (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 il account di servizio dell'host della macchina virtuale (VM) Compute Engine o dell'istanza del nodo GKE. Il account di servizio deve disporre dell'autorizzazione IAM a livello di progetto compute.globalForwardingRules.get. Per questo passaggio è sufficiente il ruolo Compute Network Viewer.

Configurare le informazioni del progetto

Se non hai ancora creato Google Cloud Project 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_ID_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 correspond to the channel for your GKE cluster. If your GKE cluster
# does not have a specified channel, please use unspecified in this field.
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_MESH_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, per la risorsa mesh, segui queste istruzioni 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_MESH_PROJECT_NUMBER_HERE

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

Per la risorsa gateway, utilizza le seguenti istruzioni per impostare SCOPE_NAME, SCOPE_PROJECT_NUMBER e TARGET:

# The gateway scope name of the traffic director load balancing API.
export SCOPE_NAME=YOUR_SCOPE_NAME
# The project that holds the gateway resources.
export SCOPE_PROJECT_NUMBER=YOUR_GATEWAY_PROJECT_NUMBER_HERE

export TARGET=projects/${SCOPE_PROJECT_NUMBER}/locations/global/gatewayScopes/${SCOPE_NAME}

Nella maggior parte degli scenari, CLUSTER_PROJECT_ID e MESH_PROJECT_NUMBER si riferiscono allo stesso progetto. Tuttavia, se configuri il progetto diverso, ad esempio quando utilizzi un VPC condiviso, CLUSTER_PROJECT_ID si riferisce all'ID progetto che contiene il cluster GKE e MESH_PROJECT_NUMBER si riferisce al numero di progetto che contiene le risorse. Assicurati di aver configurato le autorizzazioni appropriate per consentire a Envoy inserito di recuperare le configurazioni da

Abilita l'API Mesh Config

Abilita la seguente API per iniziare a utilizzare lo strumento di inserimento di sidecar gestito da Google.

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

Creazione di 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 ed esempi, consulta Gruppi di endpoint di rete autonomi.
• Il account di servizio per i nodi/pod GKE deve disporre dell'autorizzazione per accedere all'API Traffic Director. Per ulteriori informazioni sulle autorizzazioni richieste, consulta Abilitare il account di servizio per accedere all'API Traffic Director.

Creazione del cluster GKE

Crea un cluster GKE nella zona che preferisci, ad esempio us-central1-a.

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

Puntare kubectl al cluster appena creato

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

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

Applica le configurazioni per il webhook di mutazione

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

Applica le seguenti configurazioni di webhook di mutazione 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'inserimento di sidecar

Il seguente comando abilita l'inserimento per lo spazio dei nomi default. Lo strumento di inserimento sidecar inserisce 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

La query dovrebbe restituire:

NAME              STATUS   AGE     TD-INJECTION
default           Active   7d16h   enabled

Se stai configurando la sicurezza del servizio per Cloud Service Mesh con Envoy, torna alla sezione Configurazione di un servizio di test in questa 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 esegue Busybox, che fornisce un'interfaccia semplice per raggiungere un servizio di test. In un deployment reale, devi eseguire 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 container è il client basato sull'immagine Busybox e il secondo container è il proxy Envoy inserito dall'iniettore sidecar. Puoi ottenere ulteriori informazioni sul pod eseguendo il seguente comando:

kubectl describe pods -l run=client

La query dovrebbe restituire:

…
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 sidecar gestito utilizzerà l'immagine del proxy Cloud Service Mesh come proxy. Il proxy Cloud Service Mesh è un container sidecar responsabile dell'avvio di un proxy Envoy per le istanze abilitate per il mesh. L'immagine proxy utilizza l'immagine OSS Envoy insieme a un agente proxy responsabile dell'avvio di Envoy, della fornitura della configurazione di bootstrap e del controllo dell'integrità di Envoy. Le versioni dell'immagine del proxy Cloud Service Mesh sono allineate alla versione di OSS Envoy. Puoi monitorare le immagini proxy disponibili qui: https://gcr.io/gke-release/csm/csm-mesh-proxy. Ti consigliamo di utilizzare l'ultima versione del proxy.

Upgrade del proxy Cloud Service Mesh

È vivamente consigliato eseguire l'upgrade all'ultima versione. Sebbene il service mesh funzioni correttamente quando il control plane e i proxy hanno versioni diverse, ti 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 inserisce sempre l'ultima versione di Envoy qualificata da Google. Se la versione del proxy Cloud Service Mesh è più recente della versione del proxy, riavvia i proxy per i tuoi servizi.

kubectl rollout restart deployment -n YOUR_NAMESPACE_HERE

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 fornire la verifica end-to-end della configurazione.

Configurazione dei servizi GKE 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 tuo servizio di backend Cloud Service Mesh. Per saperne di più sull'annotazione dei NEG, consulta Denominazione dei 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 ed esempi, consulta Gruppi di endpoint di rete autonomi.

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 ottenere il servizio ed eseguirne il deployment nel 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

Trova il NEG creato dall'esempio precedente e annota il suo 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 dal client di esempio vengono gestite dal proxy sidecar e instradate al servizio di test.

Devi configurare i seguenti componenti:

• Un controllo di integrità. Per saperne di più sui controlli di integrità, leggi Concetti dei controlli di integrità e Creazione di controlli di integrità.
• Un servizio di backend. Per saperne di più sui servizi di backend, leggi 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ù, leggi Utilizzo delle regole di forwarding per Cloud Service Mesh, Utilizzo dei proxy di destinazione per Cloud Service Mesh e Utilizzo delle mappe URL.

Creazione del controllo di integrità e della regola firewall

Segui queste istruzioni per creare un controllo di integrità e la regola firewall necessaria per i probe del controllo di integrità. Per saperne di più, 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 è 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 nella tua 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 allegato 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. Sceglie un backend o un endpoint associato al servizio di backend selezionato.
5. Invia il traffico a questo backend o endpoint.

A questo punto, Cloud Service Mesh configura i proxy sidecar per instradare le richieste che specificano il nome host service-test ai backend di td-gke-service. In questo caso, i 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 container ed eseguire il seguente comando di verifica. Un pod service-test dovrebbe 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 inserito 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.
• L'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 ti guida nella migrazione di un'applicazione dal sidecar injector Traffic Director legacy su GKE (con un sidecar injector in-cluster) a uno che utilizza un sidecar injector gestito.

Disabilitazione dell'inserimento di sidecar in-cluster

I seguenti comandi disabilitano l'inserimento di sidecar in-cluster legacy per lo spazio dei nomi predefinito

kubectl label namespace default istio-injection-

Pulizia dell'inserimento sidecar in-cluster

Scarica ed estrai l'injector sidecar Envoy legacy.

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

Elimina le risorse di inserimento di sidecar in-cluster

kubectl delete -f specs/

Passaggi successivi

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