Configura un mesh di servizi sidecar Envoy

Questa guida illustra come configurare un semplice mesh di servizi nel tuo parco risorse. La guida prevede i seguenti passaggi:

  • Deployment dell'iniettore sidecar Envoy nel cluster. L'iniettore inserisce il container proxy Envoy nei pod dell'applicazione.
  • Deployment di risorse dell'API Gateway che configurano il sidecar Envoy nel mesh di servizi per instradare le richieste a un servizio di esempio nello spazio dei nomi store.
  • Deployment di un client semplice per verificare il deployment.

Il seguente diagramma mostra il mesh di servizi configurato.

Un mesh di servizi collaterali Envoy in un parco risorse
Un mesh di servizi collaterali Envoy in un parco risorse (fai clic per ingrandire)

Puoi configurare un solo Mesh in un cluster, poiché il nome del mesh nella configurazione dell'iniettore sidecar e il nome della risorsa Mesh devono essere identici.

Esegui il deployment dell'iniettore sidecar Envoy

Per implementare l'iniettore sidecar, devi fornire due valori.

  • TRAFFICDIRECTOR_GCP_PROJECT_NUMBER. Sostituisci PROJECT_NUMBER con il numero del progetto per il cluster di configurazione. Il numero del progetto è l'identificatore numerico del progetto.

  • TRAFFICDIRECTOR_MESH_NAME. Assegna il valore come segue, dove MESH_NAME è il valore del campo metadata.name nella specifica della risorsa Mesh:

    gketd-MESH_NAME

    Ad esempio, se il valore di metadata.name nella risorsa Mesh è butterfly-mesh, imposta il valore di TRAFFICDIRECTOR_MESH_NAME come segue:

    TRAFFICDIRECTOR_MESH_NAME: "gketd-butterfly-mesh"

  • TRAFFICDIRECTOR_NETWORK_NAME. Assicurati che il valore di TRAFFICDIRECTOR_NETWORK_NAME sia impostato su vuoto:

    TRAFFICDIRECTOR_NETWORK_NAME=""

  1. Scarica il pacchetto iniettore sidecar:

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

  2. Nel file specs/01-configmap.yaml, compila i campi TRAFFICDIRECTOR_GCP_PROJECT_NUMBER e TRAFFICDIRECTOR_MESH_NAME e imposta TRAFFICDIRECTOR_NETWORK_NAME su vuoto.

       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.
         # This port is bound to 127.0.0.1.
         proxyAdminPort: 15000

         proxyMetadata:
           # Google Cloud Project number that your Fleet belongs to.
           # This is the numeric identifier of your project
           TRAFFICDIRECTOR_GCP_PROJECT_NUMBER: "PROJECT_NUMBER"

           # TRAFFICDIRECTOR_NETWORK_NAME must be empty when
           # TRAFFICDIRECTOR_MESH_NAME is set.
           TRAFFICDIRECTOR_NETWORK_NAME=""

           # The value of `metadata.name` in the `Mesh` resource. When a
           # sidecar requests configurations from Traffic Director,
           # Traffic Director will only return configurations for the
           # specified mesh.
           TRAFFICDIRECTOR_MESH_NAME: "gketd-td-mesh"

Dopo aver completato le istruzioni precedenti, segui questi passaggi per eseguire il deployment dell'iniettore sidecar nel cluster:

  1. Configurazione di TLS per iniettore sidecar.
  2. Installazione dell'iniettore sidecar nel cluster GKE.
  3. [Facoltativo] Apertura della porta richiesta in un cluster privato.
  4. Attiva l'inserimento del file collaterale.

Esegui il deployment del servizio store

In questa sezione eseguirai il deployment del servizio store nel mesh.

  1. Nel file store.yaml, salva il seguente manifest:

    kind: Namespace
apiVersion: v1
metadata:
  name: store
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: store
  namespace: store
spec:
  replicas: 2
  selector:
    matchLabels:
      app: store
      version: v1
  template:
    metadata:
      labels:
        app: store
        version: v1
    spec:
      containers:
      - name: whereami
        image: gcr.io/google-samples/whereami:v1.2.20
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: store
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080

  2. Applica il file manifest a gke-1:

    kubectl apply -f store.yaml

Crea un mesh di servizi

  1. Nel file mesh.yaml, salva il seguente file manifest di mesh. Il nome della risorsa mesh deve corrispondere al nome del mesh specificato nella mappa di configurazione dell'iniettore. In questa configurazione di esempio, il nome td-mesh viene utilizzato in entrambe le posizioni:

    apiVersion: net.gke.io/v1alpha1
kind: TDMesh
metadata:
  name: td-mesh
  namespace: default
spec:
  gatewayClassName: gke-td
  allowedRoutes:
    namespaces:
      from: All

  2. Applica il manifest mesh a gke-1, in modo da creare un mesh logico con il nome td-mesh:

    kubectl apply -f mesh.yaml

  3. Nel file store-route.yaml, salva il seguente file manifest HTTPRoute. Il file manifest definisce una risorsa HTTPRoute che instrada il traffico HTTP specificando il nome host example.com a un servizio Kubernetes store nello spazio dei nomi store:

    apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: store-route
  namespace: store
spec:
  parentRefs:
  - name: td-mesh
    namespace: default
    group: net.gke.io
    kind: TDMesh
  hostnames:
  - "example.com"
  rules:
  - backendRefs:
    - name: store
      namespace: store
      port: 8080

  4. Applica il manifest del percorso a gke-1:

    kubectl apply -f store-route.yaml

Convalida il deployment

  1. Controlla lo stato e gli eventi Mesh per verificare che il deployment delle risorse Mesh e HTTPRoute sia stato eseguito correttamente:

    kubectl describe tdmesh td-mesh

    L'output è simile al seguente:

    ...

Status:
  Conditions:
    Last Transition Time:  2022-04-14T22:08:39Z
    Message:
    Reason:                MeshReady
    Status:                True
    Type:                  Ready
    Last Transition Time:  2022-04-14T22:08:28Z
    Message:
    Reason:                Scheduled
    Status:                True
    Type:                  Scheduled
Events:
  Type    Reason  Age   From                Message
  ----    ------  ----  ----                -------
  Normal  ADD     36s   mc-mesh-controller  Processing mesh default/td-mesh
  Normal  UPDATE  35s   mc-mesh-controller  Processing mesh default/td-mesh
  Normal  SYNC    24s   mc-mesh-controller  SYNC on default/td-mesh was a success

  2. Per assicurarti che l'inserimento di sidecar sia abilitato nello spazio dei nomi predefinito, esegui questo comando:

    kubectl get namespace default --show-labels

    Se l'inserimento dei file collaterali è abilitato, nell'output verrà visualizzato quanto segue:

    istio-injection=enabled

    Se l'inserimento dei file collaterali non è attivo, consulta Abilitare le iniezioni di sidecar.

  3. Per verificare il deployment, esegui il deployment di un pod client che funge da client nel servizio store definito in precedenza. Nel file client.yaml, salva quanto segue:

    apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: client
  name: client
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      run: client
  template:
    metadata:
      labels:
        run: client
    spec:
      containers:
      - name: client
        image: curlimages/curl
        command:
        - sh
        - -c
        - while true; do sleep 1; done

  4. Esegui il deployment della specifica:

    kubectl apply -f client.yaml

    L'iniettore sidecar in esecuzione nel cluster inserisce automaticamente un container Envoy nel pod client.

  5. Per verificare che il container Envoy sia stato inserito, esegui questo comando:

    kubectl describe pods -l run=client

    L'output è simile al seguente:

    ...
Init Containers:
  # Istio-init sets up traffic interception for the Pod.
  istio-init:
...
  # td-bootstrap-writer generates the Envoy bootstrap file for the Envoy container
  td-bootstrap-writer:
...
Containers:
# client is the client container that runs application code.
  client:
...
# Envoy is the container that runs the injected Envoy proxy.
  envoy:
...

Una volta eseguito il provisioning del pod client, invia una richiesta dal pod client al servizio store.

  1. Ottieni il nome del pod client:

    CLIENT_POD=$(kubectl get pod -l run=client -o=jsonpath='{.items[0].metadata.name}')

# The VIP where the following request will be sent. Because all requests
# from the client container are redirected to the Envoy proxy sidecar, you
# can use any IP address, including 10.0.0.2, 192.168.0.1, and others.
VIP='10.0.0.1'

  2. Invia una richiesta per archiviare il servizio e visualizzare le intestazioni della risposta:

    TEST_CMD="curl -v -H 'host: example.com' $VIP"

  3. Esegui il comando di test nel container client:

    kubectl exec -it $CLIENT_POD -c client -- /bin/sh -c "$TEST_CMD"

    L'output è simile al seguente:

    < Trying 10.0.0.1:80...
< Connected to 10.0.0.1 (10.0.0.1) port 80 (#0)
< GET / HTTP/1.1
< Host: example.com
< User-Agent: curl/7.82.0-DEV
< Accept: */*
<
< Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< content-type: application/json
< content-length: 318
< access-control-allow-origin: *
< server: envoy
< date: Tue, 12 Apr 2022 22:30:13 GMT
<
{
  "cluster_name": "gke-1",
  "zone": "us-west1-a",
  "host_header": "example.com",
  ...
}

Passaggi successivi