Configura los Pods de Google Kubernetes Engine mediante la 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.

Nota: Los ejemplos de configuración son para fines de demostración. Es posible que debas implementar componentes adicionales según el entorno y los requisitos.

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.
  • Para obtener información sobre los permisos necesarios, consulta Habilita la cuenta de servicio para acceder a la API de Traffic Director.
  • Para obtener información sobre cómo habilitar la API de Traffic Director, consulta Habilita 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.

Consola

Para crear un clúster con la consola de Google Cloud, sigue estos pasos:

1. Ve al menú de Kubernetes Engine en la consola de Google Cloud.

   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. Haz clic en Crear.

Después de crear un clúster en la consola de Google Cloud, 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.

Cómo configurar la regla de firewall

Para verificar que los Pods del backend se estén ejecutando, debes configurar una regla de firewall que permita los rangos de direcciones IP del verificador de estado.

Consola

1. 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
2. Haz clic en Crear reglas de firewall.
3. En la página Crear una regla de firewall, proporciona la siguiente información:
   • 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 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

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

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.

Nota: El paquete trafficdirector_service_sample.yaml proporcionado con esta guía de configuración usa el nombre de NEG service-test-neg.

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG-NAME"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

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

Guarda el nombre del NEG

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

Consola

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

gcloud

gcloud compute network-endpoint-groups list

Esto muestra lo siguiente:

NAME                 LOCATION          ENDPOINT_TYPE      SIZE
NEG-NAME           us-central1-a     GCE_VM_IP_PORT      1

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

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

Nota: Si nombras tu NEG, como se describe en Configura servicios de GKE con NEG, deberías ver que el nombre de NEG coincide con el nombre que proporcionaste en la especificación del servicio de Kubernetes. Si no le asignaste un nombre al NEG, se genera automáticamente un nombre por ti.

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:

• 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.
• Una regla de enrutamiento. Esto incluye la creación de una regla de reenvío y un mapa de URL. Para obtener más información, consulta Usa reglas de reenvío y Usa mapas de URL.

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.

Consola

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.

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

Consola

1. Ve a la página de Traffic Director en la consola de Google Cloud.

   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.

Nota: Sin importar el método seleccionado, el proxy de sidecar debe interceptar el tráfico a la dirección VIP en la que se resuelve el nombre de host del servicio en el host cliente que necesita acceso al servicio. Consulta Configura una sola VM de Compute Engine para Traffic Director a fin de conocer los detalles completos de la configuración del host.

Nota: Cada regla de reenvío en una red de VPC debe tener una combinación única de dirección IP y puerto por red de VPC, incluida la dirección 0.0.0.0. Si creas más de una regla de reenvío con la misma dirección IP y puerto en una red de VPC en particular, solo la primera regla de reenvío es válida. Las demás se ignoran.

Consola

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 la consola de Google Cloud.

   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 por 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 archivo adicional de proxy de Istio y contenedores init que se agregaron a la implementación mediante la especificación de referencia:

Si usas las API anteriores, reemplaza las variables PROJECT_NUMBER y NETWORK_NAME por el número del proyecto y el nombre de la red:

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_sample_xdsv3.yaml
sed -i "s/NETWORK_NAME/NETWORK_NAME/g" trafficdirector_client_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_sample_xdsv3.yaml

Si usas las nuevas API de enrutamiento de servicios, que ahora están en vista previa, reemplaza las variables PROJECT_NUMBER y MESH_NAME por el número del proyecto y el nombre de la Mesh:

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/MESH_NAME/MESH_NAME/g" trafficdirector_client_new_api_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_new_api_sample_xdsv3.yaml

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"

¿Qué sigue?

• Obtén información sobre la administración avanzada del tráfico.
• Aprende a solucionar problemas de implementaciones de Traffic Director.
• Obtén información sobre cómo configurar la observabilidad con Envoy.