El tópico de interés en la organizaciones que desarrollan software es que todos sus nuevos servicios sean «nativos de nube» para que estos puedan aprovechar al máximo las capacidades que les brindan las nubes como facil despliegue, automatización y junto con ello la capacidad de poder poner componentes de estos nuevos servicios en diferentes lugares.
En el desarrollo de servicios o aplicaciones nativos de nube, buscando tener más resiliencia de nuestros servicios los separamos de acuerdo a como deseamos que nuestros servicios escalen.Buscamos que nuestros servicios de frontend se encuentren separados del backend. Esto permite que el frontend se despliegue cerca de los usuarios; los backends se escalen para manejar la cargas de trabajo bajo demanda; y los datos se mantengan seguros dentro de la red privada.
Una estrategia de multinube también puede crear importantes desafíos en la creación de redes. Por ejemplo, con un enfoque de nube única, suena muy sencillo ya que solo necesita gestionar una conexión entre la red en su datacenter y una plataforma de nube. Pero que sucede con un sistema multinube, ahora debe preocuparnos la coordinación de conexiones entre múltiples plataformas y su red en su datacenter, y potencialmente entre las propias plataformas de la nube donde este desplegando su aplicación.
Con base en lo anterior existen retos importantes a considerar y uno de ellos es como haremos la comunicación de los servicios separados en diferentes zonas de disponibilidad o en datacenters dispersos por el mundo, es ahí donde pensamos que la mejor solución es utilizar una «VPN» para asegurar la conectividad del datacenter a la nube, entonces ahora nos encontramos que también hay que tener dispositivos específicos para que sean compatibles y además reglas muy puntuales de firewall para permitir la conectividad.
Pero esa es solo una posible solución al esquema de comunicación multinube, existen otras opciones que pueden ser más sencillas una de ellas son las Virtual Application Networks.
Virtual Application Network (VAN)
Una Virtual Application Network (VAN) es una red de capa de aplicación que se superpone a la basada en TCP/IP. Una VAN puede ser tan pequeña como un simple portátil o tan grande como una red global que abarca zonas horarias y continentes. Una VAN puede ser configurada rápidamente por un desarrollador no privilegiado y su topología puede ser añadida y cambiada con la misma facilidad. Las aplicaciones escritas para usar protocolos existentes como HTTP, gRPC, AMQP, o cualquier cosa que corra sobre TCP o UDP puede correr en una VAN sin modificación.
Una VAN se establece desplegando un router VAN en cada sitio que será parte de la aplicación distribuida y estableciendo conexiones seguras entre pares de sitios. Un sitio puede ser una LAN en un centro de datos, un único host o un namespace en un clúster de Kubernetes
Skupper: VAN para tus clústeres de Kubernetes
El Proyecto Skupper es una implementación libre y de código abierto de una VAN construida para Kubernetes
¿Qué es Skupper?, el mismo proyecto se define como:
«Skupper is a layer seven service interconnect. It enables secure communication across Kubernetes clusters with no VPNs or special firewall rules.«
En pocas palabras Skupper permite que tus aplicaciones desplegadas en diferentes sitios o nubes sobre Kubernetes se comuniquen como si estuviesen desplegadas en un mismo sitio.
Ventajas de usar skupper para comunicar tus aplicaciones en un entorno multinube:
- Permite comunicar tus servicios sin necesidad de exponerlos al público.
- Permite un nivel de seguridad usando mutualTLS.
- Permite al desarrollador poder habilitar los canales de comunicación sin privilegios de administración de k8s.
- No necesitas VPN para comunicar tus diferentes servicios de nube.
- Debido a que la comunicación simula estar en el mismo clúster no requiere modificar su aplicación.
Ahora probemos skupper
En el siguiente ejemplo estaremos desplegando una base de datos Postgresql dentro de un clúster local en minikube que simulara el centro de datos del cliente y en otro clúster con Red Hat Openshift desplegado en AWS desplegaremos un servicio que consumirá la información dentro de la mencionada Base de Datos
Los archivos necesarios para ejecutar la demo se encuentran en https://github.com/mikeintoch/skupper-example.git
Para poder utilizar skupper lo primero que debemos de hacer es instalar el CLI el cual puedes descargar desde aquí.
Paso 1: Crear los namespace correspondientes
minikube $ kubectl create namespace customer-database
minikube $ kubectl config set-context --current --namespace customer-databaseOpenshift $ kubectl create namespace customer-service
Openshift $ kubectl config set-context --current --namespace customer-servicePaso 2: Despliegue de Virtual Application Network (VAN)
minikube $ skupper init --site-name private-cloud
Skupper is now installed in namespace 'customer-database'. Use 'skupper status' to get more information.Openshift $ skupper init --site-name public-cloud
Skupper is now installed in namespace 'customer-service'. Use 'skupper status' to get more information.Verificar la instalación
Verificar el estado del servicio de skupper en cada namespace
minikube $ skupper status
Skupper is enabled for namespace "customer-database" in interior mode. It is not connected to any other sites. It has no exposed services.Openshift $ skupper status
Skupper is enabled for namespace "customer-service" in interior mode. It is not connected to any other sites. It has no exposed services.Paso 3. Conectar los namespaces
Los namespaces están listos con los servicios que aprovisiona skupper pero aún no se encuentran conectados es necesario ejecutar un token de conexión para confianza entre los dos namespaces.
Genera un nuevo token
Openshift $ skupper connection-token $HOME/public-token.yamlUtiliza el token para crear una conexión entre los dos namespaces
minikube $ skupper connect $HOME/public-token.yaml
Skupper configured to connect to "<SKUPPER_ROUTER_HOSTNAME>":443 (name=conn1)Verificar el estado de la conexión
minikube $ skupper status
Skupper is enabled for namespace "customer-database" in interior mode. It is connected to 1 other site. It has no exposed services.Openshift $ skupper status
Skupper is enabled for namespace "customer-service" in interior mode. It is connected to 1 other site. It has no exposed services.Paso 4. Despliegue del servicio de base de datos de Postgresql
minikube $ kubectl apply -f deployment-postgresql-svc.yamlPaso 5. Exponer el servicio de PostgreSQL en la Virtual Application Network
minikube $ skupper expose deployment customer-database --address customer-database --port 5432 --protocol tcp --target-port 5432Como resultado veremos un nuevo servicio creado en ambos namespaces llamado customer-database
minikube $ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
customer-database ClusterIP 10.96.175.18 <none> 5432/TCP 5m30sOpenshift $ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
customer-database ClusterIP 172.30.150.205 <none> 5432/TCP 5m20sPaso 6. Despliegue del Servicio consumidor de la Base de Datos
Openshift $ kubectl create deployment customer-service --image ghcr.io/mikeintoch/skupper-demo/customer-rest-json:1.0.0Ahora probemos que la aplicación funcione
Openshift $ kubectl expose deployment customer-service --port 8080 --type LoadBalancerMediante «curl» probaremos que nuestro servicio funcione correctamente:
Openshift $ curl $(kubectl get service customer-service -o jsonpath='http://{.status.loadBalancer.ingress[0].hostname}:8080/api/customer') | jq
[
{
"id": 1,
"accountId": "C00001",
"balance": 336.36,
"lastName": "Perez",
"name": "Pedro"
},
... ...También podemos probar usando el frontend disponible en la aplicación
Openshift $ firefox $(kubectl get service customer-service -o jsonpath='http://{.status.loadBalancer.ingress[0].hostname}:8080')
Resumen
Nuestra sencilla aplicación tiene dos servicios (base de datos y un servicio java). Desplegamos cada servicio a un cluster de Kubernetes diferente.
Normalmente, un despliegue multicluster de este tipo significa que los servicios no tienen forma de comunicarse a menos que estén expuestos a internet.
Al introducir Skupper en cada namespace, pudimos crear una virtual application network que conecta los servicios a través de los límites del clúster.
Uno de los mejores atributos de una VAN es que es una tecnología de espacio de usuario. Una VAN puede ser puesta en marcha por un desarrollador de forma rápida y fácil sin privilegios de administración. Mientras el desarrollador tenga acceso a un conjunto de espacios de nombres de Kubernetes, esos espacios de nombres pueden participar en una VAN.