Configuración de Traffic Director para pods de Google Kubernetes Engine con inserción manual de Envoy

En esta guía, se muestra cómo configurar los hosts de Pods de Kubernetes o Google Kubernetes Engine y los componentes del balanceo de cargas que requiere Traffic Director.

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 los requisitos previos.

Puedes configurar Traffic Director mediante el SDK de balanceo de cargas de Compute Engine o las API de REST. Consulta las referencias de gcloud y la API de balanceo de cargas.

Configura clústeres de GKE o Kubernetes para Traffic Director

En esta sección, se describen los pasos necesarios para permitir que los clústeres de GKE o Kubernetes funcionen con Traffic Director.

Crea el clúster de GKE

Los clústeres de GKE deben cumplir con los siguientes requisitos:

  • 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 función de NEG independientes se encuentra en la etapa de disponibilidad general para Traffic Director.
  • La cuenta de servicio de las instancias de nodos del clúster debe tener permiso para acceder a la API de Traffic Director. Si deseas obtener más información sobre los permisos necesarios, consulta Habilita la cuenta de servicio para acceder a la API de Traffic Director.
  • Los contenedores deben tener acceso a la API de Traffic Director con la protección de la autenticación de OAuth. Para obtener más información, consulta la configuración del host.

En el siguiente ejemplo, se muestra cómo crear un clúster de GKE llamado traffic-director-cluster en la zona us-central1-a.

Console

Para crear un clúster con Cloud Console, sigue estos pasos:

  1. Ve al menú de Kubernetes Engine en Cloud Console.

    Ir al menú de Google Kubernetes Engine

  2. Haz clic en Crear clúster.

  3. Completa los siguientes campos:

    • Nombre: ingresa traffic-director-cluster.
    • Tipo de ubicación: Zonal.
    • Zona: us-central1-a.
  4. En el panel de navegación, en Grupos de nodos, haz clic en default-pool.

  5. En el campo Tamaño, se indica la cantidad de nodos que se crearán en el clúster. Debes tener una cuota de recursos disponible para los nodos y sus recursos (como las rutas de firewall).

  6. En el panel de navegación, en default-pool, haz clic en Nodos.

  7. En el campo Tipo de máquina, se indica el tipo de máquina de Compute Engine que se usará para las instancias. Cada tipo de máquina se factura de manera diferente. Para obtener información sobre los precios de los tipos de máquinas, consulta la página de precios de Compute Engine.

  8. En el panel de navegación, en default-pool, haz clic en Seguridad.

  9. En Permiso de acceso, haz clic en Permitir el acceso total a todas las API de Cloud.

  10. Personaliza tu clúster según sea necesario.

  11. Haga clic en Crear.

Después de crear un clúster en Cloud Console, debes configurar kubectl para interactuar con el clúster. Para obtener más información, consulta Genera una entrada kubeconfig.

gcloud

gcloud container clusters create traffic-director-cluster \
  --zone us-central1-a \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

Obtén los privilegios necesarios del clúster de GKE

Para GKE, cambia al clúster(2) que acabas de crear mediante la emisión del siguiente comando. Esto permite que kubectl apunte al clúster correcto.

gcloud container clusters get-credentials traffic-director-cluster \
    --zone us-central1-a

Configura servicios de GKE o Kubernetes

En esta sección, se muestra cómo preparar las especificaciones de implementación de Kubernetes para trabajar con Traffic Director. Esto consta de la configuración de servicios con NEG y, también, la incorporación de proxies de sidecar en pods que requieren acceso a los servicios que administra Traffic Director.

Configura reglas de firewall

Para verificar que los pods de backend estén en ejecución, debes configurar una regla de firewall que permita los rangos de direcciones IP del verificador de estado.

Console

  1. Ve a la página Firewall en Google Cloud Console.
    Ir a la página Firewall
  2. Haz clic en Crear regla de firewall.
  3. 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 ingreso.
    • Acción en caso de coincidencia: elige Permitir.
    • Destinos: elige Todas las instancias de la red.
    • Filtro de fuente: elige Rangos de IP.
    • Rangos de IP de origen: 35.191.0.0/16,130.211.0.0/22
    • Protocolos y puertos permitidos: Usa tcp. TCP es el protocolo subyacente para todos los protocolos de verificación de estado.
    • Haz clic en Crear.

gcloud

  1. Usa el siguiente comando de gcloud para crear una regla de firewall llamada fw-allow-health-checks que permita las conexiones entrantes a instancias en tu red con la etiqueta allow-health-checks. Reemplaza NETWORK_NAME por el nombre de la red.

    gcloud compute firewall-rules create fw-allow-health-checks \
        --network NETWORK_NAME \
        --action ALLOW \
        --direction INGRESS \
        --source-ranges 35.191.0.0/16,130.211.0.0/22 \
        --rules tcp

A fin de obtener más información, consulta Configura la regla de firewall para las verificaciones de estado.

Configura servicios de GKE o Kubernetes con NEG

El primer paso para configurar los servicios de GKE o Kubernetes con NEG es exponer los servicios que necesitan la administración de Traffic Director. Para exponerse a través de NEG, cada especificación debe tener la siguiente anotación que coincida con el puerto que deseas exponer.

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"80":{}}}'

Para cada servicio, se crea un NEG independiente que contiene extremos que son los puertos y las direcciones IP del pod. Para obtener más información y ejemplos, consulta Grupos de extremos de red independientes.

A modo de demostración, puedes implementar un servicio de muestra que entregue su nombre de host a través de HTTP en el puerto 80:

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

Verifica que se cree el nombre de host del servicio nuevo y que el pod de la aplicación esté en ejecución:

kubectl get svc

El resultado es el siguiente:

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

kubectl get pods

El resultado es el siguiente:

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       1/1       Running   0          6m
[..skip..]

Registra el nombre del NEG

Busca el NEG que se creó en el ejemplo anterior y registra su nombre.

Console

Para ver una lista de grupos de extremos de red, ve a la página Grupos de extremos de red en Google Cloud Console.
Ir a la página Grupos de extremos de red

gcloud

gcloud beta compute network-endpoint-groups list

El resultado es el siguiente:

NAME                                           LOCATION       ENDPOINT_TYPE   SIZE
k8s1-7e91271e-default-service-test-80-a652810c  us-central1-a  GCE_VM_IP_PORT  1

Guarda el nombre del NEG en la variable NEG_NAME, por ejemplo:

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

Configura los componentes del balanceo de cargas de Google Cloud para Traffic Director

En las instrucciones de esta sección, se garantiza que se pueda acceder a los servicios de GKE en la VIP del servicio, cuyas cargas se balancean con Traffic Director, mediante una configuración de balanceo de cargas similar a la de otros productos de Google Cloud Load Balancing.

Debes configurar los siguientes componentes:

En el ejemplo de configuración de Traffic Director que aparece a continuación, se supone lo siguiente:

  1. Los NEG y todos los demás recursos se crean en la red default, con el modo automático, en la zona us-central1-a.
  2. El nombre del NEG para el clúster se almacena en la variable ${NEG_NAME}.

Crea la verificación de estado

Crea la verificación de estado.

Console

  1. Ve a la página Verificaciones de estado en Google Cloud Console.
    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.

gcloud

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

Crea el servicio de backend

Crea un servicio de backend global con un esquema de balanceo de cargas de INTERNAL_SELF_MANAGED. En Cloud Console, 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 de Traffic Director en Cloud Console.

    Ir a la página de Traffic Director

  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. En Tipo de backend, selecciona Grupos de extremos de red.

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

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

  8. Haz clic en Listo.

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

  10. 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 los NEG de backend al servicio de backend.

    gcloud compute backend-services add-backend td-gke-service \
     --global \
     --network-endpoint-group ${NEG_NAME} \
     --network-endpoint-group-zone us-central1-a \
     --balancing-mode RATE \
     --max-rate-per-endpoint 5
    

Crea el mapa de reglas de enrutamiento

Usa estas instrucciones a fin de crear la regla de enrutamiento, la regla de reenvío y la dirección IP interna para la configuración de Traffic Director.

El proxy de Envoy intercepta el tráfico que se envía a la dirección IP interna y lo envía al servicio correspondiente, de acuerdo con las reglas de host y de ruta de acceso.

La regla de reenvío se crea como una regla de reenvío global con load-balancing-scheme configurado como INTERNAL_SELF_MANAGED.

Puedes configurar la dirección de la regla de reenvío como 0.0.0.0. Si lo haces, el tráfico se enruta según la información de ruta de acceso y el nombre de host HTTP configurada en el mapa de URL, sin importar la dirección IP real en la que se resuelve el nombre de host. En este caso, las URL (el nombre de host más la ruta de URL) de tus servicios, como se configuran en las reglas del host, deben ser únicas dentro de la configuración de la malla de servicios. Es decir, no puedes tener dos servicios diferentes con un conjunto diferente de backends, y que ambos usen la misma combinación de nombre de host y ruta de acceso.

Como alternativa, puedes habilitar el enrutamiento según la VIP de destino real del servicio. Si configuras la VIP del servicio como un parámetro address de la regla de reenvío, solo las solicitudes dirigidas a esta dirección IP se enrutan según los parámetros HTTP especificados en el mapa de URL.

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 de Traffic Director en Cloud Console.

    Ir a la página de Traffic Director

  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 el servicio de backend.

    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 (/*). service-test también es el nombre configurado del servicio de Kubernetes que se usa en la configuración de muestra anterior.

    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, Traffic Director está configurado para balancear las cargas del tráfico de los servicios especificados en el mapa de URL en los backends del grupo de extremos de red.

Según la distribución de los microservicios en la red, es posible que debas agregar más reglas de reenvío o más reglas de host y ruta de acceso al mapa de URL.

Verifica la configuración mediante la implementación de un cliente de muestra para las pruebas

En esta sección, se muestra cómo llegar a los backends de Traffic Director desde una aplicación cliente.

Para demostrar la funcionalidad, puedes implementar un pod de muestra que ejecute Busybox. El pod tiene acceso a service-test, que se creó en la sección anterior, y recibe el tráfico cuyas cargas se balancean con Traffic Director.

Incorpora un proxy de sidecar en pods de GKE o Kubernetes

Para acceder a un servicio administrado mediante Traffic Director, un Pod debe tener instalado un proxy de sidecar compatible con la API de xDS.

En este ejemplo, implementarás un cliente de Busybox con un sidecar de proxy de Istio y contenedores init que se agregaron a la implementación mediante la especificación de referencia:

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

El pod de Busybox tiene dos contenedores en ejecución. El primer contenedor es el cliente basado en la imagen de Busybox, y el segundo contenedor es el proxy de Envoy que se incorpora como un sidecar. Para obtener más información sobre el pod, ejecuta el siguiente comando:

kubectl describe pods -l run=client

Llega al servicio de backend

Una vez configuradas, las aplicaciones en los pods que tienen un proxy de sidecar incorporado pueden acceder a los servicios que administran los servicios de Traffic Director. Para verificar la configuración, puedes acceder a una shell en uno de los contenedores.

Si usaste la configuración de demostración que se proporciona en esta guía, puedes ejecutar el siguiente comando de verificación para asegurarte de que se muestre el nombre de host del pod de entrega.

# Get name of the pod with 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.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

Información sobre la interceptación de tráfico mediante el proxy de sidecar

Ten en cuenta que, en este ejemplo, cuando el cliente de Busybox realiza solicitudes al servicio de backend, cada solicitud se envía a través del proxy de sidecar.

Esta aplicación de demostración usa el proxy de Envoy. Debido a eso, el cliente ve “server: envoy” en el encabezado de las respuestas del servidor.

Para confirmarlo, usa los siguientes comandos:

# Get the name of the pod with Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to send a request to service-test and output server response headers.
TEST_CMD="wget -S --spider service-test; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

En este ejemplo, creaste una regla de reenvío con la dirección VIP 0.0.0.0. Esto significa que Traffic Director basa el reenvío de solicitudes al backend solo en el encabezado Host. En este caso, la dirección IP de destino puede ser cualquier dirección, siempre y cuando el encabezado de la solicitud coincida con el host definido en el mapa de URL service-test.

Para confirmarlo, ejecuta los siguientes comandos de prueba:

# Get name of the pod with Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to send a request to service-test setting the Host header and using a random IP address.
TEST_CMD="wget -q --header 'Host: service-test' -O - 1.2.3.4; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"