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:
- 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.
- Las instancias de los nodos del clúster la cuenta de servicio debe tener permiso para acceder
la API de Cloud Service Mesh.
- Para obtener información sobre los permisos, 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
.
Console
Para crear un clúster con la consola de Google Cloud, sigue estos pasos:
Ve al menú de Kubernetes Engine en la consola de Google Cloud.
Haz clic en Crear clúster.
Completa los siguientes campos:
- Nombre: ingresa
traffic-director-cluster
. - Tipo de ubicación:
Zonal
. - Zona:
us-central1-a
.
- Nombre: ingresa
En el panel de navegación, en Grupos de nodos, haz clic en default-pool.
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).
En el panel de navegación, en default-pool, haz clic en Nodos.
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.
En el panel de navegación, en default-pool, haz clic en Seguridad.
En Permiso de acceso, haz clic en Permitir el acceso total a todas las API de Cloud.
Personaliza tu clúster según sea necesario.
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
- 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 - Haz clic en Crear reglas 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 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.
- Nombre: Proporciona un nombre para la regla. Para este ejemplo, usa
gcloud
Usa el siguiente comando de
gcloud
para crear una regla de firewall llamadafw-allow-health-checks
que permita las conexiones entrantes a instancias en tu red con la etiquetaallow-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:
- 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:
- Los NEG y todos los demás recursos se crean en la red
default
, con el modo automático, en la zonaus-central1-a
. - 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
- Ve a la página Verificaciones de estado en la consola de Google Cloud.
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.
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
Ve a la página Cloud Service Mesh en la consola de Google Cloud.
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 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).
Ve a la página Cloud Service Mesh en la consola de Google Cloud.
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 el servicio de backend.
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 (/*
).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
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, 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?
- 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.