Configuración de Traffic Director para Pods de Google Kubernetes Engine con 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.

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

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:

Crea el clúster de GKE

Crea un clúster de GKE llamado traffic-director-cluster en la zona us-central1-a.

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

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

Para configurar el inyector de sidecar, edita specs/01-configmap.yaml a fin de lograr los siguientes resultados:

  • 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

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

$ cat ./td-sidecar-injector-xdsv3/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:
           # GCP 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 GCP console.
           # If left empty, configuration will be attempted to be fetched for the GCP
           # 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"

           # GCP VPC network name for which the configuration is requested (This is the VPC
           # network name referenced in the forwarding rule in GCP 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: "YOUR_NETWORK_NAME_HERE"

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/istio/proxy/. Por ejemplo, el directorio /etc/istio/proxy/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.

  1. Crea el espacio de nombres en el que se debe crear el secreto de Kubernetes:

    kubectl apply -f specs/00-namespaces.yaml

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

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

  1. Implementa el inyector de sidecar.

    kubectl apply -f specs/

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

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

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": "NEG-NAME"}}}'
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
[..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
NEG-NAME           us-central1-a     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:

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

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

  6. Ve a la página Firewall en Google Cloud Console.
    Ir a la página Firewall

  7. Haz clic en Crear regla 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 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. 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 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 el NEG que creaste antes como un 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

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:

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

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.
  • Debido a que configuraste 0.0.0.0 como la VIP en el mapa de reglas de enrutamiento, Envoy inspeccionó el nombre de host de 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.

Próximos pasos

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. Para obtener más información sobre las reglas de reenvío y los mapas de URL, consulta los siguientes documentos: