Kong Gateway en su versión Community nos permite proporcionar Alta Disponibilidad mediante la creación de un Cluster de Kong, que básicamente consiste en tener múltiples instancias de Kong, todas ellas compartiendo la misma base de datos de configuración (si obviamos el modo declarativo, que no usa base de datos, y tiene algunas restricciones, pero que también soporta Clustering). De esta forma podemos proporcionar escalabilidad horizontal en nuestras soluciones mediante el uso de Kong, de una forma muy sencilla, y balancear la carga a través de DNS (ej: round robin) o de cualquier servicio de balanceo.
Continuando con la serie de Posts acerca de Kong, en esta ocasión vamos a ver cómo crear un Cluster de Kong, para así proporcionar escalabilidad horizontal, consiguiente aguantar una mayor carga de trabajo mediante a adición de más nodos.
Si quieres seguir este Post paso a paso, te recomiendo que te apoyes en el Docker Compose que compartí en GitHub (GitHub – ElWillieES – kong-docker-lab) y que revises al menos el Post primero (Introducción a Kong Gateway y Kong Dashboard) para tener el contexto de qué es Kong (si no lo tienes), y que también explica el Docker Compose compartido en GitHub.
En nuestro caso de ejemplo, tenemos un Docker Compose con una instancia de Kong (kong), de tal modo, que para conseguir alta disponibilidad, lo que necesitamos es añadir una segunda instancia de Kong (kong2), como se muestra en la misma imagen. Al tratarse del mismo Docker Compose, no podemos utilizar los mismos puertos, por lo tanto, resta segunda instancia (kong2) utilizará el puerto 8010 en lugar del 8000, que para este laboratorio es suficiente, pero en un caso real debería utilizar el mismo puerto.
De este modo, con nuestro Docker Compose arrancado, podremos acceder al mismo servicio, a través de ambas instancias de Kong, de la que escucha en tcp-8000 y la del tcp-8010. No hay que hacer nada más, y no es necesario licencia Enterprise.
Lo habitual es tener algún servicio de balanceo por delante, por ejemplo, si estuviéramos en Azure podríamos tener un Application Gateway, que además de balancear el tráfico entre las diferentes instancias de Kong, nos permitiría habilitar un WAF para proteger mejor nuestra solución. También podíamos utilizar el servicio Load Balancer de Azure (más sencillo), o balancear mediante DNS utilizando round robin.
Hay más detalles que podemos necesitar conocer. Por ejemplo, Kong minimiza los accesos a la base de datos manteniendo cierta información en memoria, para así ser más eficiente, de tal modo que si por ejemplo eliminamos un Servicio de Kong puede tardar unos segundos en actualizarse en todos los nodos del Cluster. Asociado a esto hay configuraciones que podemos ajustar. Para más información, podemos consultar la documentación oficinal: Kong – Clustering Referencing
Despedida y Cierre
Hasta aquí llega este Post sobre Kong, donde hemos podido ver cómo configurar un Cluster de Kong para conseguir alta disponibilidad mediante escalabilidad horizontal, algo que podemos hacer con la versión Community, sin necesidad de licencia Enterprise.
Poco más por hoy, como siempre confío que la lectura resulte de interés.