Configura Pods de Google Kubernetes Engine mediante la inserción automática de Envoy

Descripción general

En una malla de servicios, el código de la aplicación no necesita conocer la configuración de red. En cambio, las aplicaciones se comunican a través de un plano de datos, que se configura mediante un plano de control que maneja las redes de los servicios. En esta guía, Cloud Service Mesh es tu plano de control y los proxies de sidecar de Envoy son tu plano de datos.

El inyector de sidecar de Envoy administrado por Google agrega proxies de sidecar de Envoy a tus Pods de Google Kubernetes Engine. Cuando el inyector de sidecar de Envoy agrega un proxy, también configura ese proxy para controlar el tráfico de la aplicación y conectarse a Cloud Service Mesh para la configuración.

En esta guía, se explica una configuración simple de Cloud Service Mesh con Google Kubernetes Engine. En estos pasos, se proporciona una base que se puede extender a casos de uso avanzados, como una malla de servicios que se extiende a múltiples clústeres de Google Kubernetes Engine y podría extenderse a VM de Compute Engine. También puedes usar estas instrucciones si configuras Cloud Service Mesh con VPC compartida.

El proceso de configuración implica las siguientes acciones:

  1. Crear un clúster de GKE para tus cargas de trabajo
  2. Instalar el inyector de sidecar de Envoy y habilitar la inserción
  3. Implementar un cliente de muestra y verificar la inserción
  4. Implementar un servicio de Kubernetes para realizar pruebas
  5. Configurar Cloud Service Mesh con componentes de Cloud Load Balancing para enrutar el tráfico al servicio de prueba
  6. Verificar la configuración mediante el envío de una solicitud del cliente de muestra al servicio de prueba
Descripción general de los componentes implementados como parte de esta guía de configuración (haz clic para ampliar)
Descripción general de los componentes implementados como parte de esta guía de configuración (haz clic para ampliar)

Requisitos previos

Antes de seguir las instrucciones de esta guía, completa las tareas de requisitos previos que se describen en Prepárate para configurar las APIs de enrutamiento de servicios con Envoy y cargas de trabajo sin proxy.

Para obtener información sobre la versión de Envoy compatible, consulta las notas de la versión de Cloud Service Mesh.

Requisitos previos adicionales con la VPC compartida

Si configuras Cloud Service Mesh en un entorno de VPC compartida, ten en cuenta lo siguiente:

  • Tienes los permisos y roles correctos para la VPC compartida.
  • Que hayas configurado los proyectos y la facturación correctos
  • Habilitaste la facturación en los proyectos.
  • Habilitaste las APIs de Cloud Service Mesh y GKE en cada proyecto, incluido el proyecto host.
  • Que configuraste las cuentas de servicio correctas para cada proyecto
  • Creaste una red de VPC y subredes.
  • Habilitaste la VPC compartida.

Para obtener más información, consulta VPC compartida.

Configura las funciones de IAM

En este ejemplo de configuración de roles de IAM, se supone que el proyecto host de la VPC compartida tiene dos subredes y que hay dos proyectos de servicio en la VPC compartida.

  1. En Cloud Shell, crea una carpeta de trabajo (WORKDIR) en la que crees los archivos asociados con esta sección:

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

  2. Configura los permisos de IAM en el proyecto host para que los proyectos de servicio puedan usar los recursos en la VPC compartida.

    En este paso, configuras los permisos de IAM para que el proyecto de servicio 1 pueda acceder a subnet-1 y el proyecto de servicio 2 pueda acceder a subnet-2. Debes asignar el rol de IAM de usuario de la red de Compute (roles/compute.networkUser) a la cuenta de servicio predeterminada de Compute Engine y a la cuenta de servicio de la API de Google Cloud en cada proyecto de servicio para cada subred.

    1. Para el proyecto de servicio 1, configura los permisos de IAM para 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. Para el proyecto de servicio 2, configura los permisos de IAM para 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. Para cada proyecto de servicio, debes otorgar la función de IAM de usuario del agente de servicios de host de Kubernetes Engine (roles/container.hostServiceAgentUser) a la cuenta de servicio de GKE en el proyecto 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

    Esta función permite que la cuenta de servicio de GKE del proyecto de servicio use la cuenta de servicio de GKE del proyecto host para configurar los recursos de la red compartida.

  4. Para cada proyecto de servicio, otorga a la cuenta de servicio predeterminada de Compute Engine la función de IAM de visualizador de red de Compute (roles/compute.networkViewer) en el proyecto 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

    Cuando el proxy de sidecar de Envoy se conecta al servicio xDS (API de Traffic Director), el proxy usa la cuenta de servicio del host de la máquina virtual (VM) de Compute Engine o de la instancia de nodo de GKE. La cuenta de servicio debe tener el permiso de IAM compute.globalForwardingRules.get a nivel de proyecto. La función de visualizador de red de Compute es suficiente para este paso.

Configura la información del proyecto

Si aún no creaste un proyecto de Google Cloud ni instalaste Google Cloud CLI, sigue estas instrucciones. Si aún no instalaste kubectl, sigue estas instrucciones.

# 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}

Si usas las nuevas APIs de enrutamiento de servicios, sigue estas instrucciones para configurar MESH_NAME, MESH_PROJECT_NUMBER y 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}

En la mayoría de los casos, CLUSTER_PROJECT_ID y MESH_PROJECT_NUMBER se refieren al mismo proyecto. Sin embargo, si configuras un proyecto diferente, como cuando usas una VPC compartida, CLUSTER_PROJECT_ID hace referencia al ID del proyecto que contiene tu clúster de GKE, y MESH_PROJECT_NUMBER hace referencia al número de proyecto que contiene los recursos. Asegúrate de haber configurado los permisos adecuados para permitir que el Envoy insertado recupere configuraciones del

Habilita la API de Mesh Config

Habilita la siguiente API para comenzar a usar el inyector de sidecar administrado por Google.

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

Crea un clúster de GKE para tus cargas de trabajo

Los clústeres de GKE deben cumplir con los siguientes requisitos para admitir Cloud Service Mesh:

Crea el clúster de GKE

Crea un clúster de GKE en tu zona preferida, por ejemplo, us-central1-a.

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

Apunta kubectl al clúster recién creado

Para cambiar el contexto actual de kubectl al clúster recién creado, ejecuta el siguiente comando:

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

Aplica las configuraciones para el webhook de mutación

En las siguientes secciones, se proporcionan instrucciones para aplicar MutatingWebhookConfiguration al clúster. Cuando se crea un pod, se invoca el controlador de admisión en el clúster. El controlador de admisión se comunica con el inyector de sidecar administrado para agregar el contenedor de Envoy al pod.

Aplica las siguientes configuraciones de webhooks de mutación a tu clúster.

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

Habilita la inserción de sidecar

El siguiente comando habilita la inserción para el espacio de nombres default. El inyector de sidecar inserta los contenedores de sidecar en los Pods creados en este espacio de nombres:

kubectl label namespace default td-injection=enabled

Para verificar que el espacio de nombres default esté habilitado de forma correcta, ejecuta lo siguiente:

kubectl get namespace -L td-injection

Se debería mostrar lo siguiente:

NAME              STATUS   AGE     TD-INJECTION
default           Active   7d16h   enabled

Si configuras la seguridad del servicio para Cloud Service Mesh con Envoy, vuelve a la sección Configura un servicio de prueba en esa guía de configuración.

Implementa un cliente de muestra y verifica la inserción

En esta sección, se muestra cómo implementar un Pod de muestra mediante la ejecución de Busybox, que proporciona una interfaz simple para alcanzar un servicio de prueba. En una implementación real, en cambio, implementas tu propia aplicación cliente.

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

El Pod de Busybox está formado por dos contenedores. El primer contenedor es el cliente basado en la imagen de Busybox y el segundo contenedor es el proxy de Envoy que inserta el inyector de sidecar. Para obtener más información sobre el Pod, ejecuta el siguiente comando:

kubectl describe pods -l run=client

Se debería mostrar lo siguiente:

…
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 de Cloud Service Mesh

El inyector de sidecar administrado usará la imagen de proxy de Cloud Service Mesh como proxy. El proxy de Cloud Service Mesh es un contenedor de sidecar responsable de iniciar un proxy de Envoy para instancias habilitadas para la malla. La imagen del proxy usa la imagen de Envoy de OSS junto con un agente de proxy responsable de iniciar el Envoy, proporcionar la configuración de inicio y realizar la verificación del estado del Envoy. Las versiones de las imágenes del proxy de Cloud Service Mesh se alinean con la versión de Envoy de OSS. Puedes hacer un seguimiento de las imágenes de proxy disponibles aquí: https://gcr.io/gke-release/asm/csm-mesh-proxy.

El proxy de malla de Cloud Service Mesh que se inyecta varía según el canal que el usuario eligió para el clúster de GKE. La versión de Envoy se actualiza periódicamente en función de las versiones actuales de Envoy de OSS y se prueba con la versión específica de GKE para garantizar la compatibilidad.

Versión del proxy de Cloud Service Mesh

En la siguiente tabla, se muestra el canal actual del clúster de GKE para la asignación de versiones del proxy de Cloud Service Mesh:

Canal Versión del proxy de Cloud Service Mesh
Rápido 1.29.9-gke.3
Normal 1.28.7-gke.3
Estable 1.27.7-gke.3

Actualización del proxy de Cloud Service Mesh

Se recomienda actualizar a la versión más reciente. Aunque la malla de servicios funciona bien cuando el plano de control y los proxies están en versiones diferentes, te recomendamos actualizar los proxies para que se configuren con la nueva versión de Cloud Service Mesh.

El inyector de sidecar administrado se encarga de la versión de Envoy, que siempre inserta la versión más reciente de Envoy calificada por Google. Si la versión del proxy de Cloud Service Mesh es más reciente que la versión del proxy, reinicia los proxies de tus servicios.

kubectl rollout restart deployment -n YOUR_NAMESPACE_HERE

Implementa un servicio de Kubernetes para realizar pruebas

En las siguientes secciones, se proporcionan instrucciones para configurar un servicio de prueba que usarás más adelante en esta guía a fin de proporcionar una verificación de extremo a extremo de tu configuración.

Configura servicios de GKE con NEG

Los servicios de GKE deben exponerse a través de grupos de extremos de red (NEG) para que puedas configurarlos como backends de un servicio de backend de Cloud Service Mesh. Agrega la anotación NEG a tu especificación de servicio de Kubernetes y elige un nombre (reemplaza NEG-NAME en la muestra a continuación) para que puedas encontrarlo con facilidad más adelante. Necesitas el nombre cuando adjuntas el NEG a tu servicio de backend de Cloud Service Mesh. Para obtener más información sobre la anotación NEG, consulta Nombra 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

Mediante esta anotación, se crea un NEG independiente que contiene extremos correspondientes a las direcciones IP y los puertos de los Pods del servicio. Para obtener más información y ejemplos, consulta Grupos de extremos de red independientes.

El siguiente servicio de muestra incluye la anotación de NEG. El servicio entrega el nombre de host en HTTP en el puerto 80. Usa el siguiente comando para obtener el servicio y, luego, implementarlo en el clúster de GKE.

wget -q -O - \
https://storage.googleapis.com/traffic-director/demo/trafficdirector_service_sample.yaml \
| kubectl apply -f -

Verifica que se cree el servicio nuevo y que el Pod de la aplicación esté en ejecución:

kubectl get svc

El resultado debería ser similar al ejemplo siguiente:

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service-test     ClusterIP   10.71.9.71   none          80/TCP    41m
[..skip..]

Verifica que el Pod de aplicación asociado con este servicio esté en ejecución:

kubectl get pods
El resultado es el siguiente: 
NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       2/2       Running   0          6m
busybox-5dcf86f4c7-jvvdd    2/2       Running   0          10m
[..skip..]

Guarda el nombre del NEG

Busca el NEG que se creó en el ejemplo anterior y registra su nombre para la configuración de Cloud Service Mesh en la siguiente sección.

gcloud compute network-endpoint-groups list

Esto muestra lo siguiente:

NAME                       LOCATION            ENDPOINT_TYPE       SIZE
service-test-neg           ZONE     GCE_VM_IP_PORT      1

Guarda el nombre del NEG en la variable NEG_NAME:

NEG_NAME=$(gcloud compute network-endpoint-groups list \
| grep service-test | awk '{print $1}')

Configura Cloud Service Mesh con componentes de Cloud Load Balancing

En esta sección, se configura Cloud Service Mesh con recursos de balanceo de cargas de Compute Engine. Esto permite que el proxy de sidecar del cliente de muestra reciba la configuración de Cloud Service Mesh. El proxy de sidecar se encarga de las solicitudes salientes del cliente de muestra y las enruta al servicio de prueba.

Debes configurar los siguientes componentes:

Crea la verificación de estado y la regla de firewall

Usa las siguientes instrucciones para crear una verificación de estado y la regla de firewall necesaria para los sondeos de verificación de estado. SI quieres obtener más información, consulta las Reglas de firewall para las verificaciones de estado.

Console

  1. Ve a la página Verificaciones de estado en la consola de Google Cloud.
    Ir a la página Verificaciones de estado
  2. Haz clic en Crear verificación de estado.
  3. En el nombre, ingresa td-gke-health-check.
  4. En el protocolo, selecciona HTTP.

  5. Haz clic en Crear.

  6. Ve a la página de políticas de firewall en la consola de Google Cloud.
    Ir a la página Políticas de firewall

  7. Haz clic en Crear reglas de firewall.

  8. En la página Crear una regla de firewall, proporciona la información siguiente:

    • Nombre: Proporciona un nombre para la regla. Para este ejemplo, usa fw-allow-health-checks.
    • Red: Elige una red de VPC.
    • Prioridad: ingresa un número para la prioridad. Los números más bajos tienen prioridades más altas. Asegúrate de que la regla de firewall tenga una prioridad mayor que otras normas que podrían denegar el tráfico de entrada.
    • Dirección del tráfico: Elige Entrada.
    • Acción en caso de coincidencia: Elige Permitir.
    • Destinos: elige Todas las instancias de la red.
    • Filtro de origen: Elige el tipo de rango de IP correcto.
    • Rangos de IP de origen: 35.191.0.0/16,130.211.0.0/22
    • Filtro de destino: Selecciona el tipo de IP.
    • Protocolos y puertos: Haz clic en Protocolos y puertos especificados y, luego, marca tcp. TCP es el protocolo subyacente para todos los protocolos de verificación de estado.
    • Haga clic en Crear.

gcloud

  1. Crea la verificación de estado.

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

  2. Crea la regla de firewall para permitir los rangos de direcciones IP del verificador de estado.

    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

Crea el servicio de backend

Crea un servicio de backend global con un esquema de balanceo de cargas de INTERNAL_SELF_MANAGED. En la consola de Google Cloud, el esquema de balanceo de cargas se establece de forma implícita. Agrega la verificación de estado al servicio de backend.

Console

  1. Ve a la página Cloud Service Mesh en la consola de Google Cloud.

    Ir a la página Cloud Service Mesh

  2. En la pestaña Servicios, haz clic en Crear servicio.

  3. Haz clic en Continuar.

  4. Para el nombre del servicio, ingresa td-gke-service.

  5. Selecciona Network, que configuraste en el ConfigMap de Cloud Service Mesh.

  6. En Tipo de backend, selecciona Grupos de extremos de red.

  7. Selecciona el grupo de extremos de red que creaste.

  8. Establece el Máximo de RPS en 5.

  9. Establece el Modo de balanceo en Tasa.

  10. Haz clic en Listo.

  11. En Verificación de estado, selecciona td-gke-health-check, que es la verificación de estado que creaste.

  12. Haz clic en Continuar.

gcloud

  1. Crea el servicio de backend y asocia la verificación de estado con este.

    gcloud compute backend-services create td-gke-service \
 --global \
 --health-checks td-gke-health-check \
 --load-balancing-scheme INTERNAL_SELF_MANAGED

  2. Agrega el NEG que creaste antes como un backend al servicio de backend. Si configuras Cloud Service Mesh con un proxy TCP de destino, debes usar el modo de balanceo UTILIZATION. Si usas un proxy de destino HTTP o HTTPS, puedes usar el modo 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

Crea el mapa de reglas de enrutamiento

El mapa de reglas de enrutamiento define cómo Cloud Service Mesh enruta el tráfico en tu malla. Como parte del mapa de reglas de enrutamiento, configura una dirección IP virtual (VIP) y un conjunto de reglas de administración de tráfico asociadas, como el enrutamiento basado en el host. Cuando una aplicación envía una solicitud a la VIP, el proxy de sidecar de Envoy conectado realiza las siguientes acciones:

  1. Intercepta la solicitud.
  2. La evalúa según las reglas de administración de tráfico en el mapa de URL.
  3. Selecciona un servicio de backend basado en el nombre de host de la solicitud.
  4. Elige un backend o extremo asociado con el servicio de backend que se seleccionó.
  5. Envía tráfico a ese backend o extremo.

Console

En la consola, el proxy de destino se combina con la regla de reenvío. Cuando creas la regla de reenvío, Google Cloud crea de forma automática un proxy HTTP de destino y lo adjunta al mapa de URL.

La regla de enrutamiento consta de la regla de reenvío y las reglas de host y ruta de acceso (también conocida como mapa de URL).

  1. Ve a la página Cloud Service Mesh en la consola de Google Cloud.

    Ir a la página Cloud Service Mesh

  2. Haz clic en Mapas de reglas de enrutamiento.

  3. Haz clic en Crear regla de enrutamiento.

  4. Ingresa td-gke-url-map como el Nombre del mapa de URL.

  5. Haz clic en Agregar una regla de reenvío.

  6. Para el nombre de la regla de reenvío, ingresa td-gke-forwarding-rule.

  7. Selecciona tu red.

  8. Selecciona tu IP interna.

  9. Haz clic en Guardar.

  10. De manera opcional, puedes agregar reglas de host y de ruta de acceso personalizadas, o dejar las reglas de ruta de acceso según la configuración predeterminada.

  11. Establece el host en service-test.

  12. Haz clic en Guardar.

gcloud

  1. Crea un mapa de URL que use td-gke-service como el servicio de backend predeterminado.

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

  2. Crea un comparador de rutas de acceso de mapa de URL y una regla de host para enrutar el tráfico del servicio según el nombre de host y una ruta de acceso. En este ejemplo, se usa service-test como el nombre del servicio y un comparador de rutas de acceso predeterminado que hace coincidir todas las solicitudes de ruta de acceso para este 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 el proxy HTTP de destino.

    gcloud compute target-http-proxies create td-gke-proxy \
   --url-map td-gke-url-map

  4. Crea la regla de reenvío.

    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

En este punto, Cloud Service Mesh configura los proxies de sidecar para enrutar solicitudes que especifican el nombre de host service-test a los backends de td-gke-service. En este caso, esos backends son extremos en el grupo de extremos de red asociado con el servicio de prueba de Kubernetes que implementaste antes.

Verifica la configuración

En esta sección, se muestra cómo verificar que el tráfico enviado del cliente de Busybox de muestra se enrute al servicio de Kubernetes service-test. Para enviar una solicitud de prueba, puedes acceder a una shell en uno de los contenedores y ejecutar el siguiente comando de verificación. Un Pod service-test debe mostrar el nombre de host del Pod de entrega.

# 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"

A continuación, se muestra cómo se verifica la configuración:

  • El cliente de muestra envió una solicitud que especificó el nombre de host service-test.
  • El cliente de muestra tiene un proxy de sidecar de Envoy que se insertó mediante el inyector de sidecar de Envoy.
  • El proxy de sidecar intercepta la solicitud.
  • Mediante el mapa de URL, Envoy hizo coincidir el nombre de host service-test con el servicio de td-gke-service Cloud Service Mesh.
  • Envoy eligió un extremo del grupo de extremos de red asociado con td-gke-service.
  • Envoy envió la solicitud a un Pod asociado al servicio de Kubernetes service-test.

Cómo migrar al inyector de sidecar administrado

En este instructivo, se te guiará para migrar una aplicación del inyector de contenedor secundario de Cloud Service Mesh heredado en GKE (con un inyector de contenedor secundario en el clúster) a uno que usa un inyector de contenedor secundario administrado.

Inhabilita la inserción de sidecar en el clúster

Los siguientes comandos inhabilitan el inyector de sidecar heredado en el clúster para el espacio de nombres predeterminado.

kubectl label namespace default istio-injection-

Limpia el inyector de sidecar en el clúster

Descarga y extrae el inyector de sidecar heredado de 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

Borra los recursos del inyector de sidecar en el clúster

kubectl delete -f specs/

¿Qué sigue?