[k8s][vSphere with Tanzu] spec.loadbalancerclass. Qué es y para que puede resultar útil
[k8s][vSphere with Tanzu] spec.loadbalancerclass. Qué es y para que puede resultar útil
Cuando desplegamos nuestro entorno con vSphere with Tanzu, uno de los pasos para habilitar Workload Management es especificar cual es nuestro balanceador de carga.
Este puede ser el balanceador estandar de NSX, el balanceador de carga avanzado de NSX (AVI) o HAProxy, y será el balanceador por el que expondrán servicios todos los clusters que creemos desde vSphere with Tanzu independientemente del namespace en el que se encuentren, de forma transparente para el cluster y sin necesidad de instalar ningún add-on.
Pero, ¿Que pasa si queremos utilizar un balanceador de carga on-demand en nuestro cluster? Imaginemos que por cualquier razón queremos exponer ciertos servicios por un balanceador diferente al que utilizamos para configurar «Workload Management», por ejemplo una instancia diferente de NSX ALB (AVI) conectado a unas redes diferentes en un entorno aislado, o un load balancer de un third party.
En ese caso, instalaremos el controller correspondiente a nuestro balanceador dentro del cluster, pero… ¿cual será la sorpresa llegado el momento de exponer? El default load balancer seguirá funcionando junto al controller recién instalado, de manera que tendremos servicios duplicados ya que se expondrán en ambos a la vez como muestro en el siguiente ejemplo:
Tal y como se aprecia en el pantallazo de arriba, el LB configurado en mi cloud de vWTZ se encuentra en la IP 172.25.2.179, además se encuentra configurado para exponer servicios por la red de prod (172.25.251.0/24)
Mientras que en mi cluster, he desplegado AKO y lo he conectado a una instancia diferente de AVI desplegada en la IP 172.25.2.194 para publicar en una red de frontend de un entorno de DMZ diferente a la configurada en el primero, que es producción.
Pero, ¿Qué sucede cuando tratamos de exponer un servicio?
Vamos a crear un pod de apache y expongamoslo:
Como veis, el pod se ha expuesto por el LB provisto por la cloud en lugar de por el instalado on-premises. Pero… ¿Esto es realmente así? revisemos:
¿Pero que pasa con nuestra segunda instancia de balanceador de carga?
Para evitar esta problemática, tras bucear en la documentación de Kubernetes.io, di con la funcionalidad «spec.LoadBalancerClass» que parecía acotar mi problema y ser una posible solución:
Sin embargo, para que esta característica funcione, es necesario tener habilitado el feature-gate «ServiceLoadBalancerClass» en nuestro kube-apiserver. Este feature gate se introdujo con kubernetes 1.21 y su default en esta versión es deshabilitado al ser un alpha, desde kubernetes 1.22 en adelante, viene habilitado por defecto.
En mi caso, como mi cluster corre kubernetes 1.21, necesito habilitar el feature gate para poder utilizar la característica. (Esto no está soportado oficialmente por Tanzu, por lo que no se debe realizar en entornos productivos)
Si en tu caso tu implementación es superior a k8s 1.22, puedes saltar esta sección.
- Conectarse al control-plane del cluster usando el siguiente procedimiento (Site oficial de VMware)
- Una vez dentro, editar el archivo /etc/kubernetes/manifests/kube-apiserver.yaml con vi (requiere sudo) y justo debajo de «- kube-apiserver» introduciremos «- –feature-gates=ServiceLoadBalancerClass=true»
- Salimos y guardamos, nuestro kube-apiserver se redesplegará automáticamente, por lo que perderemos la gestión del cluster durante unos 45 segundos, una vez que vuelva, la feature estará habilitada
Pongamos a prueba la característica, tratando de exponer el mismo servicio que antes, pero usando una loadBalancerClass, en mi caso, al estar utilizando AVI, mi class es «ako.vmware.com/avi-lb»
Como veis, en este caso, el servicio se ha expuesto únicamente por el LB on-premises y no ha sido duplicado por el LB dado por el cloud, de manera que con esta característica podemos escoger hacia que LB queremos que se expongan los servicios.
Como siempre, espero que os haya sido de utilidad y lo hayáis disfrutado tanto como yo. ¡No dudéis en comentar cualquier sugerencia o cuestión.!