Lo que debes saber al usar más de una interfaz de red en Google Cloud
El Load Balancer de Google Cloud, con una única IP global y un montón de servicios de backend (VMs, pods de K8s, instancias de Cloud Functions, etc.), es hoy la forma más habitual de exponer tu aplicación a la World Wide Web. Sobre todo si lo único que necesitas es un buen HTTP(S) de toda la vida. Una sola dirección IP para gobernarlas a todas suele bastar.
Sin embargo, de vez en cuando aparece una configuración especial, o llamémosla tradicional, en la que necesitas que una VM acepte tráfico en varias IPs. En la mayoría de los casos sería sobre el protocolo TCP, aunque enseguida viene a la mente el clásico ejemplo del HTTP virtual hosting basado en IP.
Lo anterior se reduce, en esencia, a "¿Cómo puedo tener una VM de GCP con varias IPs?". Buscar en la web seguramente te llevará a la ruta de "VM de GCP con varias interfaces de red". Este enfoque funciona tal como se describe: vincular una IP externa a cada Network Interface Card (NIC) de la VM. Sin embargo, hay varias limitaciones que conviene tener en cuenta:
- Cada Network Interface Card (NIC) requiere una red VPC distinta. No es un problema en sí mismo, pero sí implica algo de trabajo de DevOps: no se trata solo de crear una VPC y definir sus rangos de IP de forma que no se superpongan, sino también de crear reglas de FW para cada VPC.
- Puedes tener hasta 8 NICs por VM. Puede que te alcance, o puede que no.
- NO puedes cambiar la cantidad de NICs de una VM después de crearla. Si empiezas con 5 IPs y luego quieres añadir otra, tendrás que recrear la VM.
- El número de vCPUs de la VM debe ser, como mínimo, igual al número de NICs. Aquí es donde la cosa puede salir cara rápido. Con 1–2 vCPUs te alcanza para servir todo tu tráfico, pero igual tendrás que pagar máquinas de 8 vCPUs si quieres 8 IPs.
Hay un truco que puedo compartirte: crea una VM de 8 vCPUs con 8 NICs, luego deténla, baja el tipo de máquina y vuelve a iniciarla. Hazlo con cuidado, porque GCP podría cerrar este atajo en cualquier momento.
Reglas de forwarding
El camino más barato y directo son las reglas de forwarding. Toda la red de GCP está definida por software, así que tu VM no puede simplemente tomar IPs y anunciarlas mediante respuestas ARP: en realidad casi no hay ARP. Es localhost o el gateway predeterminado para todo lo demás. Incluso el tráfico hacia tu VM "vecina" en la misma VPC pasa por el gateway predeterminado.
me@my-vm:~$ ip route showdefault via 10.128.0.1 dev ens410.128.0.1 dev ens4 scope linkPor eso necesitamos "explicarle" a GCP que queremos más IPs para aceptar tráfico, y la forma de "explicárselo" es a través de las reglas de forwarding.
Una regla de forwarding en GCP es muy flexible. Puede escuchar cualquier combinación de IP, puertos, protocolos, hosts y rutas HTTP, y reenviar el tráfico que coincida a un destino, que puede ser una VM, un pool de VMs, un bucket de Cloud Storage, una Cloud Function, un servicio de K8s, etc.
Las reglas de forwarding cuestan dinero. Más sobre esto en un momento.
En nuestro caso solo necesitamos la forma más simple: escuchar en tcp:dirección:puerto y reenviar todo el tráfico a una sola instancia de destino.
Reglas de forwarding en su forma más simple
La documentación de GCP tiene un artículo muy bueno y muy extenso sobre cómo configurarlo. A este enfoque lo llaman Protocol Forwarding. Prácticamente no hay soporte para esto en la consola UI de GCP. Si quieres configurarlo en una región distinta a la predeterminada, debes prestar especial atención a anotar las regiones y zonas correctas para cada uno de los comandos (déjame saber en los comentarios si quieres más detalles al respecto).
Por suerte, existe una manera más sencilla de hacerlo desde la UI.
Empecemos por asignar varias IPs:
NOTA: Asegúrate de que tus IPs sean regionales y estén en la misma región que tu VM de destino.
La UI te advierte que las IPs externas estáticas sin usar tienen Precios más altos que las que sí están en uso, pero lo resolveremos en un momento.
A continuación, crea una VM: llamémosla "au-vm" en la región australia-southeast1. Asegúrate de marcar "Allow HTTP traffic" o de configurar las reglas de firewall para permitir el puerto en cuestión sobre TCP.
Ahora pasemos a las reglas de forwarding. En el menú Network Services selecciona Load Balancing y luego inicia la configuración del nuevo balanceador de carga TCP. Los valores predeterminados "From Internet to my VMs", "Single region only" y "Target Pool or Target Instance" son exactamente lo que necesitamos.
Dale un nombre a tu balanceador de carga y, en la sección Backend configuration, selecciona tu instancia au-vm existente.
Listo con la parte del destino. Ahora haz clic en "Frontend configuration" para trabajar en la parte de "escucha" y añade todas las IPs que reservaste.
Aquí añadí todas las IPs que ya había asignado para que escucharan en el puerto 80
Haz clic en "Create" — ¡y listo! Dale un par de minutos para que se active y, desde ese momento, tu VM podrá aceptar tráfico en las tres IPs anteriores. Si no funciona, verifica que tengas reglas de firewall que permitan los puertos necesarios.
Puedes editar tu balanceador de carga para añadir o quitar IPs en cualquier momento.
Los procesos en tu VM pueden incluso hacer bind a la dirección IP de destino deseada, aunque esa dirección no aparezca configurada en ninguna interfaz de red de Linux (según ip address show). En este ejemplo, lo siguiente funcionará:
nc -s 34.87.204.138 -l -p 80El secreto detrás de esta magia son los daemons de GCP que corren en tu máquina y configuran rutas de Linux para aceptar paquetes destinados a las direcciones en cuestión:
me@au-vm:~$ ip route show table all...local 34.87.204.138 dev ens4 table local proto 66 scope hostlocal 34.87.228.28 dev ens4 table local proto 66 scope hostlocal 34.116.108.163 dev ens4 table local proto 66 scope host...Hablemos del dinero
Las reglas de forwarding funcionan de maravilla y resultan una respuesta más natural al problema. Sin embargo, no son gratis.
Google te cobra un precio fijo de $0.025/hora por las primeras cinco reglas, es decir, pagas el mismo total de $0.025/hora sin importar si tienes 1 o 5. Por cada regla de forwarding adicional, el precio es de $0.01/hora. Así, tener 10 IPs en una VM durante un mes completo te costaría $55/mes, solo por las reglas de forwarding.
Lamentablemente, eso no es todo. No hace mucho, GCP empezó a cobrar por las IPs externas, incluso por las que están en uso (y da igual si las usan VMs o reglas de forwarding). Su precio de $0.004/h por IP puede parecer insignificante, pero son $0.004*730h = $2.92/mes y, multiplicado por 10 IPs en nuestro caso, eleva el costo total de tener 10 IPs ruteadas a nuestra VM a:
$55 + $29.2 ~= $85/mes — solo por las IPs, antes de pagar la VM
Si esto es caro o no, te lo dejo a ti :-)
¡Gracias por leer! Para seguir en contacto, síguenos en el DoiT Engineering Blog , el canal de DoiT en LinkedIn y el canal de DoiT en Twitter . Para explorar oportunidades laborales, visita https://careers.doit.com .