Configura los Pods de Google Kubernetes Engine mediante la inserción manual de Envoy

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

Antes de seguir las instrucciones de esta guía, completa el requisito previo tareas descritas en Prepárate para configurar las APIs de Service Enrutamiento con Envoy y las 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 habilitar Clústeres de GKE o Kubernetes para trabajar con Cloud Service Mesh.

Crea el clúster de GKE

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

En el siguiente ejemplo, se muestra cómo crear un clúster de GKE llamado traffic-director-cluster en la zona us-central1-a.

Console

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. Haga 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 Cloud Service Mesh. Esto también consiste en configurar servicios con NEG como la inserción de proxies de sidecar en los Pods que requieran 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 lo que permite los rangos de direcciones IP del verificador de estado.

Console

  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 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 origen: 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. luego, marca tcp. TCP es el protocolo subyacente para todas las verificar los protocolos.
    • 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 se deben exponer a través de grupos de extremos de red (NEG) para que puedas configurarlos como backends de un backend de Cloud Service Mesh servicio. 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 para conectar el NEG al 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.

Console

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

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:

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.

Console

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

Console

  1. Ve a la página Cloud Service Mesh en la consola de Google Cloud.

    Ir a la página Cloud Service Mesh

  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 para crear la regla de enrutamiento, la regla de reenvío y las reglas Dirección IP 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.

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

    Ir a la página Cloud Service Mesh

  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, 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 un cliente y mantener la integridad de su aplicación.

Para demostrar la funcionalidad, puedes implementar un Pod de muestra que ejecute Purchasebox. 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 administrados por 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 se basa 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?