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, Traffic Director es tu plano de control y los proxies de sidecar de Envoy son tu plano de datos.

El inyector de sidecar de Envoy facilita la adición de 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 a fin de controlar el tráfico de la aplicación y conectarse a Traffic Director para la configuración.

En esta guía, se explica una configuración simple de Traffic Director 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 Traffic Director con una VPC compartida.

El proceso de configuración implica las siguientes acciones:

Crear un clúster de GKE para tus cargas de trabajo
Instalar el inyector de sidecar de Envoy y habilitar la inserción
Implementar un cliente de muestra y verificar la inserción
Implementar un servicio de Kubernetes para realizar pruebas
Configurar Traffic Director con componentes de Cloud Load Balancing para enrutar el tráfico al servicio de prueba
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)

Requisitos previos

Antes de seguir las instrucciones de esta guía, revisa Prepárate para la configuración de Traffic Director y asegúrate de que completaste las tareas de requisitos previos descritas en ese documento.

Para obtener información sobre la versión de Envoy compatible, consulta las notas de la versión de Traffic Director.

Requisitos previos adicionales con la VPC compartida

Si configuras Traffic Director en un entorno de VPC compartida, asegúrate de lo siguiente.

Tienes los permisos y roles correctos para la VPC compartida.
Configuraste los proyectos y la facturación correctos.
Habilitaste la facturación en los proyectos.
Habilitaste las APIs de Traffic Director y GKE en cada proyecto, incluido el proyecto host.
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 funciones de IAM, se supone que el proyecto host para la VPC compartida tiene dos subredes y que hay dos proyectos de servicio en la VPC compartida.

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)
```

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 la función 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 a cada proyecto de servicio para cada subred.

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}

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}

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

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

Los clústeres de GKE deben cumplir con los siguientes requisitos para admitir Traffic Director:

Se debe habilitar la compatibilidad con los grupos de extremos de red. Para obtener más información y ejemplos, consulta Grupos de extremos de red independientes.
La cuenta de servicio de tus nodos y Pods de GKE debe tener permiso para acceder a la API de Traffic Director. A fin de obtener más información sobre los permisos necesarios, consulta Habilita la cuenta de servicio para acceder a la API de Traffic Director.

Crea el clúster de GKE

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

gcloud container clusters create traffic-director-cluster \
  --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

Instala el inyector de sidecar de Envoy

En las siguientes secciones, se proporcionan instrucciones para instalar el inyector de sidecar de Envoy. Cuando el inyector de sidecar está habilitado, implementa de forma automática proxies de sidecar para cargas de trabajo nuevas y existentes de Google Kubernetes Engine. Debido a que el inyector de sidecar de Envoy se ejecuta dentro del clúster de GKE, debes instalarlo una vez en cada clúster si usas Traffic Director para admitir una malla de servicios de varios clústeres.

Descarga el inyector de sidecar

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

Configura el inyector de sidecar

Si usas las API anteriores, configura el inyector de sidecar mediante la edición del archivo specs/01-configmap.yaml de la siguiente manera:

Propagar TRAFFICDIRECTOR_GCP_PROJECT_NUMBER mediante el reemplazo de YOUR_PROJECT_NUMBER_HERE por el número de tu proyecto. El número de proyecto es un identificador numérico de tu proyecto. Para obtener información sobre cómo obtener una lista de todos tus proyectos, consulta Identifica proyectos
Propagar TRAFFICDIRECTOR_NETWORK_NAME mediante el reemplazo de YOUR_NETWORK_NAME_HERE por el nombre de red de la nube privada virtual de Google Cloud que deseas usar con Traffic Director. Toma nota de este nombre de red de VPC, porque lo necesitarás más adelante cuando configures Traffic Director

Si usas las API de enrutamiento de servicio nuevas, que actualmente se encuentran en vista previa, haz lo siguiente:

Propaga TRAFFICDIRECTOR_MESH_NAME mediante el reemplazo de "" por el nombre de la malla de servicios, a fin de obtener la configuración para una malla de servicios.
- Ten en cuenta que si configuras un Gateway, no usarás el inyector de sidecar. Implementa un proxy de Envoy como un Pod.

Por ejemplo, es posible que el archivo tenga el siguiente aspecto:

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

De manera opcional, también puedes habilitar el registro y el seguimiento para cada proxy que se inserte de forma automática. Si quieres obtener más información sobre estas opciones de configuración, consulta Configura atributos adicionales para proxies de sidecar. Cuando usas el inyector del sidecar, el valor de TRAFFICDIRECTOR_ACCESS_LOG_PATH solo se puede establecer en un archivo del directorio /etc/envoy/. Por ejemplo, el directorio /etc/envoy/access.log es una ubicación válida.

Ten en cuenta que TRAFFICDIRECTOR_INTERCEPTION_PORT no debe configurarse en este ConfigMap, porque ya lo configuró el inyector de sidecar.

Configura TLS para el inyector de sidecar

En esta sección, se muestra cómo configurar TLS para el inyector de sidecar.

El inyector de sidecar usa un webhook de admisión de mutación de Kubernetes para insertar proxies cuando se crean Pods nuevos. Este webhook es un extremo HTTPS, por lo que debes proporcionar una clave y un certificado para TLS.

Puedes crear una clave privada y un certificado autofirmado mediante openssl para proteger el inyector de sidecar.

De manera opcional, si tienes tu propia clave privada y un certificado firmado por una autoridad certificada (CA) de confianza, puedes omitir este paso.

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

Este comando openssl de ejemplo genera una clave RSA privada de 4096 bits en key.pem y un certificado autofirmado en formato X.509 en cert.pem. Debido a que el certificado es autofirmado, se lo copia en ca-cert.pem y también se lo considera el certificado que firmó la CA. El certificado es válido por 365 días y no requiere una frase de contraseña. Para obtener más información sobre la creación y firma de certificados, consulta la documentación de Kubernetes sobre solicitudes de firma de certificados.

Los pasos en esta sección se deben repetir de forma anual para regenerar y volver a aplicar claves y certificados nuevos antes de que venzan.

Una vez que tengas la clave y los certificados, debes crear un secreto de Kubernetes y actualizar el webhook de inyector de sidecar.

Crea el espacio de nombres en el que se debe crear el secreto de Kubernetes:
```
kubectl apply -f specs/00-namespaces.yaml
```

Crea el secreto para el inyector de sidecar.

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

Modifica el caBundle del webhook de inserción de sidecar llamado istio-sidecar-injector-istio-control en 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
```

Instala el inyector de sidecar en tu clúster de GKE

Implementa el inyector de sidecar.
```
kubectl apply -f specs/
```

Verifica que el inyector de sidecar esté en ejecución.

kubectl get pods -A | grep sidecar-injector

Esto muestra un resultado similar al que se muestra a continuación:

istio-control   istio-sidecar-injector-6b475bfdf9-79965  1/1 Running   0   11s
istio-control   istio-sidecar-injector-6b475bfdf9-vntjd  1/1 Running   0   11s

Abre un puerto requerido en un clúster privado

Si sigues las instrucciones deConfigura la seguridad del servicio de Traffic Director con Envoy , puedes omitir esta sección y pasar a la siguiente sección: Cómo habilitar la inyección de archivo adicional.

Si instalas el inyector de sidecar de Envoy en un clúster privado, debes abrir el puerto TCP 9443 en la regla de firewall en los nodos principales para que el webhook funcione correctamente.

En los siguientes pasos, se describe cómo actualizar la regla de firewall requerida. Ten en cuenta que el comando update reemplaza la regla de firewall existente, por lo que debes asegurarte de incluir los puertos predeterminados 443 (HTTPS) y 10250 (kubelet), así como el puerto nuevo que deseas abrir.

Busca el rango de origen (master-ipv4-cidr) del clúster. En el siguiente comando, reemplaza CLUSTER_NAME por el nombre de tu clúster, es decir, traffic-director-cluster:
```
FIREWALL_RULE_NAME=$(gcloud compute firewall-rules list \
 --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master" \
 --format="value(name)")
```
Actualiza la regla de firewall para abrir el puerto TCP 9443 a fin de habilitar la inyección automática:
```
gcloud compute firewall-rules update ${FIREWALL_RULE_NAME} \
 --allow tcp:10250,tcp:443,tcp:9443
```

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 istio-injection=enabled

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

kubectl get namespace -L istio-injection

Se debería mostrar lo siguiente:

NAME              STATUS   AGE     ISTIO-INJECTION
default           Active   7d16h   enabled
istio-control     Active   7d15h
istio-system      Active   7d15h

Si configuras la seguridad del servicio para Traffic Director con Envoy, regresa 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.

kubectl create -f demo/client_sample.yaml

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

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 Traffic Director. 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 Traffic Director. 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 Traffic Director 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 Traffic Director con componentes de Cloud Load Balancing

En esta sección, se configura Traffic Director mediante recursos de balanceo de cargas de Compute Engine. Esto permite que el proxy de sidecar del cliente de muestra reciba la configuración de Traffic Director. 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:

Una verificación de estado. Para obtener más información sobre las verificaciones de estado, consulta Conceptos de la verificación de estado y Crea verificaciones de estado.
Un servicio de backend. Para obtener más información sobre los servicios de backend, consulta Servicios de backend.
Un mapa de reglas de enrutamiento. Esto incluye crear una regla de reenvío, un proxy HTTP de destino y un mapa de URL. Si deseas obtener más información, consulta Usa reglas de reenvío para Traffic Director, Usa proxies de destino para Traffic Director y Usa mapas de URL.

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

Ve a la página Verificaciones de estado en la consola de Google Cloud.
Ir a la página Verificaciones de estado
Haz clic en Crear verificación de estado.
En el nombre, ingresa td-gke-health-check.
En el protocolo, selecciona HTTP.
Haz clic en Crear.
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
Haz clic en Crear reglas de firewall.
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 fuente: 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 Puertos y protocolos especificados y, luego, marca tcp. TCP es el protocolo subyacente para todos los protocolos de verificación de estado.
- Haz clic en Crear.

gcloud

Crea la verificación de estado.

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

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

Ve a la página de Traffic Director en la consola de Google Cloud.
Ir a la página de Traffic Director
En la pestaña Servicios, haz clic en Crear servicio.
Haz clic en Continuar.
Para el nombre del servicio, ingresa td-gke-service.
Selecciona Network, que configuraste en el ConfigMap de Traffic Director.
En Tipo de backend, selecciona Grupos de extremos de red.
Selecciona el grupo de extremos de red que creaste.
Establece el Máximo de RPS en 5.
Configura el Modo de balanceo en Velocidad.
Haz clic en Listo.
En Verificación de estado, selecciona td-gke-health-check, que es la verificación de estado que creaste.
Haz clic en Continuar.

gcloud

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

Agrega el NEG que creaste antes como un backend al servicio de backend. Si configuras Traffic Director 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 la forma en que Traffic Director 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:

Intercepta la solicitud.
La evalúa según las reglas de administración de tráfico en el mapa de URL.
Selecciona un servicio de backend basado en el nombre de host de la solicitud.
Elige un backend o extremo asociado con el servicio de backend que se seleccionó.
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).

Ve a la página de Traffic Director en la consola de Google Cloud.
Ir a la página de Traffic Director
Haz clic en Mapas de reglas de enrutamiento.
Haz clic en Crear regla de enrutamiento.
Ingresa td-gke-url-map como el Nombre del mapa de URL.
Haz clic en Agregar una regla de reenvío.
Para el nombre de la regla de reenvío, ingresa td-gke-forwarding-rule.
Selecciona tu red.
Selecciona tu IP interna.
Haz clic en Guardar.
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.
Establece el host en service-test.
Haz clic en Guardar.

gcloud

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

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
```

Crea el proxy HTTP de destino.

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

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, Traffic Director 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 Traffic Director td-gke-service.
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.

¿Qué sigue?

Obtén información sobre la administración avanzada del tráfico.
Obtén información sobre la seguridad del servicio de Traffic Director.
Obtén información sobre cómo configurar la observabilidad con Envoy.
Aprende a solucionar problemas de implementaciones de Traffic Director.
Obtén más información sobre las opciones para la configuración de Pods de Google Kubernetes Engine con inserción automática de Envoy.