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 Cloud Service Mesh.

Antes de seguir las instrucciones de esta guía, completa las tareas de requisitos previos que se describen en Prepárate para configurar las APIs de enrutamiento de servicios con Envoy y cargas de trabajo sin proxy.

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

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

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

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 Cloud Service Mesh.
• La cuenta de servicio de las instancias de nodos del clúster debe tener permiso para acceder a la API de Cloud Service Mesh.
  • 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 Cloud Service Mesh, consulta Habilita la API de Cloud Service Mesh.
• Los contenedores deben tener acceso a la API de Cloud Service Mesh, protegida por 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.

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 Cloud Service Mesh. 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 Cloud Service Mesh.

Cómo configurar la regla 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.

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 Cloud Service Mesh. 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 Cloud Service Mesh. 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

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.

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}')

Configura los componentes del balanceo de cargas de Google Cloud para Cloud Service Mesh

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 Cloud Service Mesh, 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 Cloud Service Mesh 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.

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.

Crea el mapa de reglas de enrutamiento

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

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.

En este punto, Cloud Service Mesh 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 Cloud Service Mesh 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 la malla de servicios de Cloud.

Incorpora un proxy de sidecar en Pods de GKE o Kubernetes

Para acceder a un servicio administrado por Cloud Service Mesh, 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 Cloud Service Mesh. 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 Cloud Service Mesh reenvía las solicitudes al backend solo en función del 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.
• Obtén información para solucionar problemas de implementaciones de Service Mesh de Cloud.
• Obtén información sobre cómo configurar la observabilidad con Envoy.