Perfecto, ya tenemos nuestro producto en producción pero el nuevo arquitecto viene con otras ideas y preconiza que
el monolito nos va a ralentizar por lo que debemos evolucionar a una arquitectura microservicios. Perfecto (estoy
de acuerdo con él) así que mientras los programadores empiezan a crear nuevos servicios nosotros vamos a ir
implementando un API Gateway que sirva para consumir sus endpoints (como ya hemos dicho sabemos que un simple
proxy a los servicios no será suficiente)
Existen varias formas de instalar Apisix en nuestro cluster pero nosotros vamos a usar la más fácil (no por ello
incompleta) usando el chart de Helm disponible
values.yml
gateway:
type: NodePort
ingress-controller:
enabled: true
config:
apisix:
serviceNamespace: apisix
Con este fichero le vamos a decir a Helm que nos instale Apisix "en modo NodePort" (necesario para que k3d luego
pueda acceder a él sin problemas) y que también nos instale su controller para ingress. Este será el encargado
de que podamos crear rutas y reglas en apisix usando ficheros de kubernetes de forma fácil (y versionada)
- INFO
-
voy a usar el namespace apisix donde desplegar todos los artefactos relacionados con apisix, pero le puedes
dar otro nombre o incluso usar el default, aunque lo veo un poco "guarro"
Básicamente ejecutaremos estos 3 comandos
helm repo add apisix https://charts.apiseven.com
helm repo update
helm install apisix apisix/apisix --create-namespace --namespace apisix -f values.yml
(Fíjate que indico el fichero "-f values.yml" que es como he llamado al fichero de configuración de helm para
ajustar la ínstalación de Apisix a mi medida)
Si todo va bien, Apisix va a necesitar un minuto aprox para inicializar todas sus cosas. Vamos a utilizar k9s para
comprobarlo. Ejecutamos en un terminal k9s
y deberíamos ver todos los pods del cluster:
Según vayan terminando de inicializarse cada componente iremos viendo que pasan de rojo a azul (en mi terminal al menos)
Una vez comprobado que todos han inicializado bien saldremos con …. síiiiii "dos puntos q", al más puro estilo de vi
- INFO
-
Lo que ha hecho helm ha sido crear un montón de recursos nuevos en nuestro cluster, además de crearnos el
namespace y desplegar en él los diferentes componentes.
A grandes rasgos la arquitectura de Apisix se divide:
-
componente stateful que guarda la configuración (etcd)
-
componente admin que gestiona esta configuración
-
componente gateway el encargado de gestionar las peticiones
-
ingress controller, un operador que "convierte" nuestros recursos k8s en configuración apisix
Lo bueno de Apisix es que con esta arquitectura NO necesitas ninguna base de datos
Comprobamos que nuestro "monolito" sigue funcionando (pues en principio no hemos hecho nada que le afecte)
curl localhost:8881/sigo/vivo
Hostname: whoami-deployment-5d4fc76b57-2h8pl
IP: 127.0.0.1
IP: ::1
IP: 10.42.0.9
IP: fe80::6cc5:9aff:fe51:9a19
RemoteAddr: 10.42.0.8:40276
GET /sigo/vivo HTTP/1.1
Host: localhost:8881
User-Agent: curl/7.81.0
Accept: */*
Accept-Encoding: gzip
X-Forwarded-For: 10.42.0.1
X-Forwarded-Host: localhost:8881
X-Forwarded-Port: 8881
X-Forwarded-Proto: http
X-Forwarded-Server: traefik-7cd4fcff68-9ksw7
X-Real-Ip: 10.42.0.1