Google acaba de anunciar que, a partir del 31 de marzo del 2019, los clústeres desplegados en Google Kubernetes Engine (GKE), por defecto tendrán habilitado el modo VPC nativa (alias IPs), en vez de estar basados en rutas, como ahora. La plataforma utilizará alias IPs para entregar los paquetes a los pods destinatarios (backends).
¿Qué significa?
Al crear un clúster en GKE, se le asigna un rango de direcciones IP entre /19 y /14 (/14 por defecto) para los pods y los servicios que vayan a ser desplegados en el clúster. A su vez, ese rango se divide entre los nodos, y cada nodo recibe un rango de IP /24. Así que si un pod es desplegado en un nodo, recibirá una dirección IP del rango /24 asignado a ese nodo. Para los servicios se reserva el último rango /20.
Hasta el 31 de marzo del 2019, los clústeres creados en GKE, por defecto, tendrán especificaciones similares a las de la imagen 1. La VPC nativa está inhabilitada, y se asigna un intervalo de IPs a los pods y los servicios. La subred de la VPC se mantiene intacta.
A nivel de proyecto, se crean tantas rutas como nodos para redirigir el tráfico al nodo adecuado, dependiendo de la IP destinatario y, a nivel de nodo, se crean reglas de iptables. Es decir, si un paquete con destino hacía un pod llegara a la VPC, este (1) se enrutaría hacia el nodo que contiene el pod, y (2) se entregaría al pod gracias a las reglas de iptables. Esto está ilustrado en las imágenes 2 y 3.
A partir del 31 de marzo del 2019, al crear un clúster, las especificaciones serán más bien como las de la imagen 4. A nivel de máquina, la diferencia es casi nula, pero a nivel de VPC la diferencia es bastante importante.
Ya no se crearán rutas, sino que la VPC estará al tanto del rango de los pods. Si miramos la VPC, vemos que se han añadido los rangos de los pods y los servicios a la subred donde se encuentra el clúster [imagen 5].
¿Qué cambios conllevan los clústeres VPC nativa?
A nivel de rendimiento, esta implementación va a ser inapreciable. Va a ser notable a nivel de seguridad y usuario. Las ventajas a destacar son:
- Las IPs de los pods son enrutables por la VPC. Puesto que hace falta una ruta por nodo, los proyectos donde corran clústeres con cientos de nodos, ya no necesitarán ir incrementando la cuota de las rutas, a medida que va creciendo el clúster.
- El hecho de que las IPs ya estén en la VPC impide el solapamiento con otros recursos del compute.
- La capa de red estará capacitada para realizar las comprobaciones anti-spoofing, en vez de enrutar un paquete a ciegas.
- Las IPs alias pueden ser anunciadas por Cloud Router, por BGP.
- Las reglas de firewall se podrán aplicar a los paquetes destinados a los pods por separado de las reglas de sus nodos.
- Las IPs alias permiten a los pods acceder directamente a algunos servicios que hasta ahora había sido posible sólo a través de un NAT.
Restricciones
La implementación con IPs alias no tiene ninguna desventaja con respecto a la basada en rutas. Pero sí tiene algunas restricciones que se deberían de tener en cuenta:
- Un clúster con IPs alias no se puede migrar a uno basado en rutas, y viceversa.
- No se pueden utilizar redes legacy con clústeres VPC nativas.
- Las IPs de los pods y los servicios seguirán siendo privados, aunque sean parte de la VPC, accesibles sólo desde dentro del clúster. Para acceder a alguno de los servicios desde fuera del clúster, pero desde dentro de la VPC, se puede utilizar un balanceador de cargas interno.
¿Cómo me afecta este cambio?
Esto dependerá del caso de uso de cada uno, pero, grosso modo, se puede decir que este cambio no será tan significativo para los clústeres pequeños y medianos. La cuota de las rutas por defecto es de 250, así que no debería haber contratiempos como intentar aumentar el número de los nodos y no tener rutas suficientes.
Como se ha mencionado anteriormente, tampoco va a haber cambios notables de rendimiento. Al final, un paquete va a hacer casi el mismo recorrido para llegar a los backends.
Para clústeres grandes, este cambio puede ser significativo. El que tenga experiencia con Google Cloud Platform (GCP), sabe que si una solicitud de aumento de cuota es exageradamente grande y evitable, se le impondrá la alternativa. Así que si alguien prevé que el cluster puede crecer considerablemente, debería crear el clúster con VPC nativa, sin siquiera barajar la posibilidad de uno basado en rutas.
A nivel de seguridad, esto beneficia a todos (usuarios con clústeres pequeños, medianos y grandes). Ahora, hay que tener en cuenta que un proyecto de GCP, por defecto, ya está “envuelto” con la seguridad de Google, que ya es muy robusta. La probabilidad de que un paquete se cuele a la VPC, y la VPC sea la que tenga que evitar un desastre, es bastante pequeña.
Por último, a nivel de usuario, es más fácil construir soluciones con alias IPs, por los últimos tres puntos de las ventajas de esta implementación.
Conclusión
Los clústeres con alias IP, de entrada, son una mejora, puesto que el tráfico fluye con más lógica. Y, teniendo en cuenta que el trade off es nulo, los administradores de sistemas, a menos que tengan una razón de peso, deberían empezar a usarlos.
Puedes encontrar más información sobre los clústeres con VPC nativa en el blog de Google Cloud.
