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:
- 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
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:
- 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 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.tgz tar -xzvf td-sidecar-injector.tgz cd td-sidecar-injector
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 deyour-project-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 deyour-network-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
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.
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}" 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 llamadoistio-sidecar-injector-istio-control
enspecs/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
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: … # Istio-proxy is the container that runs the injected Envoy proxy. Istio-proxy: …
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 Traffic Director.
... metadata: annotations: cloud.google.com/neg: '{"exposed_ports":{"80":{}}}'
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 podsEl 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
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:
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
Console
- Ve a la página Verificaciones de estado en Google Cloud Console.
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.
Haga clic en Crear.
Ve a la página Firewall en Google Cloud Console.
Ir a la página FirewallHaz clic en Crear regla 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 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.
- Nombre: Proporciona un nombre para la regla. Para este ejemplo, usa
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 \ --target-tags td-http-server \ --rules tcp:80
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
Ve a la página de Traffic Director en Cloud Console.
En la pestaña Servicios, haz clic en Crear servicio.
Haz clic en Continuar.
Para el nombre del servicio, ingresa
td-gke-service
.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
.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.
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:
- 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 Cloud Console.
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. 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 Directortd-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:
- Usa reglas de reenvío
- Recurso de REST de las reglas de reenvío
- Recurso de REST de las reglas de reenvío globales
- Usa mapas de URL
- Recurso de REST del mapa de URL
- Si deseas ver más opciones de configuración del inyector de sidecar, consulta Opciones para la configuración de Pods de Google Kubernetes Engine con la inserción automática de Envoy.