Configurar pods de Google Kubernetes Engine con inserción manual de Envoy

En esta guía se muestra cómo configurar los hosts de Google Kubernetes Engine o de Kubernetes Pod y los componentes de balanceo de carga que requiere Cloud Service Mesh.

Antes de seguir las instrucciones de esta guía, completa las tareas previas que se describen en Preparar la configuración de las APIs de enrutamiento de servicios con Envoy y cargas de trabajo sin proxy.

Puedes configurar Cloud Service Mesh mediante el SDK de balanceo de carga de Compute Engine o las APIs REST. Consulta las referencias de la API de balanceo de carga y de gcloud.

Configurar clústeres de GKE o Kubernetes para Cloud Service Mesh

En esta sección se describen los pasos necesarios para habilitar los clústeres de GKE o Kubernetes para que funcionen con Cloud Service Mesh.

Crear el clúster de GKE

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

• Se debe habilitar la compatibilidad con grupos de puntos finales de red. Para obtener más información y ejemplos, consulta Grupos de puntos finales de red independientes. La función de NEG independiente está disponible para todos los usuarios de Cloud Service Mesh.
• La cuenta de servicio de las instancias de los nodos del clúster debe tener permiso para acceder a la API Cloud Service Mesh.
  • Para obtener información sobre los permisos necesarios, consulta Habilitar la cuenta de servicio para acceder a la API Traffic Director.
  • Para obtener información sobre cómo habilitar la API Cloud Service Mesh, consulta el artículo Habilitar la API Cloud Service Mesh.
• Los contenedores deben tener acceso a la API Cloud Service Mesh, protegida por la autenticación 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.

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

Obtener los privilegios de clúster de GKE necesarios

En GKE, cambia al clúster que acabas de crear ejecutando el siguiente comando. De esta forma, kubectl apunta al clúster correcto.

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

Configurar servicios de GKE o Kubernetes

En esta sección se muestra cómo preparar las especificaciones de implementación de Kubernetes para que funcionen con Cloud Service Mesh. Esto consiste en configurar servicios con NEGs, así como en insertar proxies sidecar en los pods que requieran acceso a los servicios gestionados por Cloud Service Mesh.

Configurar la regla de cortafuegos

Para verificar que los pods de backend se están ejecutando, debe configurar una regla de cortafuegos que permita los intervalos de direcciones IP del comprobador de estado.

Para obtener más información, consulta el artículo sobre cómo configurar reglas de cortafuegos para comprobaciones del estado.

Configurar servicios de GKE o Kubernetes con NEGs

Los servicios de GKE deben exponerse a través de grupos de puntos finales de red (NEGs) para que puedas configurarlos como backends de un servicio de backend de Cloud Service Mesh. Añade la anotación NEG a la especificación de tu servicio de Kubernetes y elige un nombre (sustituyendo NEG-NAME en el ejemplo de abajo) para que puedas encontrarlo fácilmente más adelante. Necesitarás el nombre cuando adjuntes el NEG a tu servicio de backend de Cloud Service Mesh. Para obtener más información sobre cómo anotar NEGs, consulta Asignar nombres a NEGs.

...
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 los puntos finales que son las direcciones IP y los puertos del pod. Para obtener más información y ejemplos, consulta Grupos de puntos finales de red independientes.

Para hacer una demostración, puedes implementar un servicio de ejemplo que sirva 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 haya creado el nuevo nombre de host del servicio y que el pod de la aplicación se esté ejecutando:

kubectl get svc

Devuelve lo 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

Devuelve lo siguiente:

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

Guardar el nombre de la NEG

Busca el NEG creado en el ejemplo anterior y anota su nombre.

gcloud compute network-endpoint-groups list

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

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

Configurar Google Cloud componentes de balanceo de carga para Cloud Service Mesh

Las instrucciones de esta sección aseguran que se pueda acceder a los servicios de GKE en el VIP de servicio con balanceo de carga de Cloud Service Mesh mediante una configuración de balanceo de carga similar a la de otros productos de Google Cloud Load Balancing.

Debes configurar los siguientes componentes:

• Una comprobación del estado. Para obtener más información sobre las comprobaciones del estado, consulta los artículos Conceptos de comprobación del estado y Crear comprobaciones del estado.
• Un servicio de backend. Para obtener más información sobre los servicios backend, consulta Servicios backend.
• Una regla de ruta. Esto incluye la creación de una regla de reenvío y un mapa de URLs. Para obtener más información, consulta los artículos sobre cómo usar reglas de reenvío y usar mapas de URLs.

En el ejemplo de configuración de Cloud Service Mesh que se muestra a continuación se dan por supuestos los siguientes aspectos:

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 del clúster se almacena en la variable ${NEG_NAME}.

Crear la comprobación del estado

Crea la comprobación del estado.

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

Crear el servicio de backend

Crea un servicio de backend global con el esquema de balanceo de carga INTERNAL_SELF_MANAGED. En la consola de Google Cloud , el esquema de balanceo de carga se define de forma implícita. Añade la comprobación del estado al servicio de backend.

Crear el mapa de reglas de enrutamiento

Sigue estas instrucciones para crear la regla de ruta, la regla de reenvío y la dirección IP interna de tu configuración de Cloud Service Mesh.

El proxy Envoy intercepta el tráfico enviado a la dirección IP interna y lo envía al servicio correspondiente según las reglas de host y ruta.

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

Puedes definir la dirección de tu regla de reenvío como 0.0.0.0. Si lo hace, el tráfico se enruta en función del nombre de host HTTP y de la información de la ruta configurados en el mapa de URLs, independientemente de la dirección IP real a la que se resuelva el nombre de host. En este caso, las URLs (nombre de host más ruta de URL) de tus servicios, tal como se hayan configurado en las reglas de host, deben ser únicas en la configuración de tu malla de servicios. Es decir, no puedes tener dos servicios diferentes, con conjuntos de backend distintos, que usen la misma combinación de nombre de host y ruta.

También puedes habilitar el enrutamiento en función del VIP de destino real del servicio. Si configuras la IP virtual de tu servicio como parámetro address de la regla de reenvío, solo se enrutarán las solicitudes destinadas a esta dirección IP en función de los parámetros HTTP especificados en el mapa de URLs.

En este punto, Cloud Service Mesh está configurado para balancear la carga del tráfico de los servicios especificados en el mapa de URLs entre los backends del grupo de endpoints de red.

En función de cómo se distribuyan tus microservicios en tu red, es posible que tengas que añadir más reglas de reenvío o más reglas de host y ruta al mapa de URLs.

Verificar la configuración implementando un cliente de muestra para las pruebas

En esta sección se muestra cómo acceder a los back-ends de Cloud Service Mesh desde una aplicación cliente.

Para demostrar la funcionalidad, puedes desplegar un Pod de ejemplo que ejecute Busybox. El pod tiene acceso a service-test, que se creó en la sección anterior y recibe tráfico balanceado por Cloud Service Mesh.

Inyectar un proxy de sidecar en pods de GKE o Kubernetes

Para acceder a un servicio gestionado por Cloud Service Mesh, un pod debe tener instalado un proxy sidecar compatible con la API xDS.

En este ejemplo, se implementa un cliente de Busybox con un sidecar de Istio-proxy y contenedores init añadidos a la implementación mediante la especificación de referencia.

Si usas las APIs antiguas, sustituye las variables PROJECT_NUMBER y NETWORK_NAME por el número de tu 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 APIs de enrutamiento de servicios, que están en versión preliminar, sustituye las variables PROJECT_NUMBER y MESH_NAME por el número de proyecto y el nombre 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 Busybox tiene dos contenedores en ejecución. El primer contenedor es el cliente basado en la imagen de Busybox y el segundo es el proxy de Envoy insertado como sidecar. Para obtener más información sobre el pod, ejecuta el siguiente comando:

kubectl describe pods -l run=client

Acceder al servicio de backend

Una vez configuradas, las aplicaciones de los pods que tienen un proxy sidecar insertado pueden acceder a los servicios gestionados por los servicios de Cloud Service Mesh. Para verificar la configuración, puedes acceder a una shell en uno de los contenedores.

Si has usado 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 devuelve el nombre de host del pod de servicio.

# 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 intercepción del tráfico por parte del proxy de sidecar

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

Esta aplicación de demostración usa el proxy Envoy. Por 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, has creado una regla de reenvío con la dirección VIP 0.0.0.0. Esto significa que Cloud Service Mesh reenvía las solicitudes al backend basándose únicamente en el encabezado Host. En este caso, la dirección IP de destino puede ser cualquier dirección, siempre que la cabecera de host de la solicitud coincida con el host definido en el mapa de URLs 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"

Siguientes pasos

• Consulta información sobre la gestión avanzada del tráfico.
• Consulta cómo solucionar problemas de implementaciones de Cloud Service Mesh.
• Consulta cómo configurar la observabilidad con Envoy.