[NSX ALB][vSphere with Tanzu] Usando markers para escoger una VIPnetwork del IPAM
[NSX ALB][vSphere with Tanzu] Usando markers para escoger una VIPnetwork del IPAM
Cuando desplegamos vSphere with Tanzu usando el NSX Advanced Load Balancer como balanceador de carga, podemos escoger nuestras redes de Workload, pero no podemos escoger nuestras redes de Frontend, pues estas se asignan directamente desde el IPAM Profile que tenemos configurado en nuestro ALB.
Pero, ¿Que pasa si estamos utilizando ALB para más de una finalidad y tenemos un IPAM con varias redes? Por ejemplo, tenemos una red destinada a Tanzu y otra a balancear servicios de VMs convencionales:
En despliegues standalone de AKO podemos utilizar el campo vipNetworkList para escoger cual queremos que sea nuestra red de frontend, pero esta opción no está disponible cuando desplegamos Vspehere with Tanzu usando NSX ALB como balanceador de carga, por lo que cuando despleguemos APIservers y publiquemos servicios desde nuestro cluster, se realizará un Round-Robin asignandose IPs aleatoriamente en aquellas redes que tengamos configuradas en nuestro IPAM.
Recientemente, se me dio un caso como éste en el que un cliente tenía esta problemática y no era capaz de darle solución, por lo que me puse manos a la obra y tras revisar la documentación de VMware y AVI Networks no me fue posible encontrar una respuesta a la problemática, por lo que decidí coger el código fuente de AKO (Github) y tratar de encontrar la respuesta por mi mismo:
Investigación
Cuando desplegaos vSphere with Tanzu con NSX ALB, se instala una instancia «especial» de AKO en el cluster supervisor, bajo el namespace «vmware-system-ako»
Como conectar al cluster supervisor (VMware)
Aquí encontramos un primer mensaje que nos da una pequeña pista sobre como conseguir nuestro acometido:
No Marker configurable usable networks found.
Lo cual nos indica que en esta instancia de AKO, que se despliega como «advancedL4» (no voy a entrar en detalle por no extenderme demasiado, pero si hay cualquier duda sentiros libres de comentar o contactarme por Linkedin), la red se escoge utilizando «Markers»
Los markers, son una forma de etiquetar objetos dentro del NSX ALB, algo similar a los tags de vSphere o los labels de k8s. Ahora bien ¿Que tenemos que etiquetar y donde? Pues en la GUI de NSX ALB no encuentro opcion para etiquetar la red:
Sin embargo, si accedemos por la shell de AVI (SSH al controller y posteriormente comando shell)
¡¡Existe una opción de markers, configurable con key y values!!
Genial, ya sabemos donde añadir los markers, ahora ¿Que hay que añadir? para ello descargamos el código fuente de AKO de Github y buscamos dentro de el por «Markers»
# grep -rnw . -e "Marker"
Como vemos dentro del archivo /internal/cache/controller_obj_cache.go, en la línea 3065 encontramos el mensaje que vemos en el AKO, por lo que vamos a echarle un vistazo y encontramos lo siguiente:
if len(network.Markers) == 1 && *network.Markers[0].Key == lib.ClusterNameLabelKey && len(network.Markers[0].Values) == 1 && network.Markers[0].Values[0] == clusterName { utils.AviLog.Infof("Marker configuration found in usable network. Using %s as vipNetworkList.", *network.Name) return nil, *network.Name
De este código deducimos que el valor de «key» que añadiremos como marker corresponde a una variable llamada «ClusterNameLabelKey» y el valor, corresponde a una variable llamada «clusterName»
Para la primera, si hacemos una pequeña investigación en google, encontramos en pkg.go.dev, un documento de constantes donde ésta está incluida:
Por lo cual ya hemos encontrado el valor de «key» que deberemos aplicar a la red, es «clustername«
Para la segunda, si revisamos el código del archivo «lib.go» encontramos lo siguiente:
Por lo cual, la variable clusterName es igual a la función «GetClusterID», la cual a su vez apunta a una variable de nuestro entorno k8s llamada «CLUSTER_ID». Si iniciamos un shell al pod de AKO dentro del cluster supervisor y lanzamos el comando «env»:
Eureka! Ya tenemos nuestro CLUSTER_ID, ¡por lo cual ya sabemos los «Markers» que hemos de añadir a nuestra red!
En mi caso:
- Key = clustername
- Value = domain-c37:ae737fff-26ce-4e93-9fdf-9d3cebc3e5ae
Solución
1. Accediendo al Cluster supervisor
Para poder seleccionar una VIPnetwork en nuestro entorno de VwTZ, en primer lugar debemos logarnos como root en el cluster supervisor.
Como conectar al cluster supervisor (VMware)
2. Obteniendo el CLUSTER_ID
Una vez dentro, listaremos los pods del namespace «vmware-system-ako» y tomaremos el nombre del pod:
A continuación lanzaremos un shell al pod con el siguiente comando:
# kubectl exec -it vmware-system-ako-ako-controller-manager-ID-DEL-POD -n vmware-system-ako /bin/bash
Una vez dentro obtenemos nuestro CLUSTER_ID lanzando el comando env | grep CLUSTER_ID, y lo anotamos:
Salimos del Pod pero no cerramos la sesión SSH, pues necesitaremos volver para reiniciar AKO más adelante.
3. Añadiendo el marker a la red
Accedemos por SSH a nuestro NSX ALB Controller, y una vez dentro lanzamos el comando «shell», volvemos a iniciar sesión:
A continuación lanzamos los comandos
# configure network nombredenuestrared # markers # key clustername values CLUSTER_ID # save # save
Verificamos que nuestro marker se ha añadido correctamente lanzando el comando:
# show network nombredenuestrared
4. Reiniciando el Pod de AKO y verificando funcionamiento
Volvemos a la sesión SSH abierta contra nuestro Cluster Supervisor, y reiniciamos AKO (Puede tener impacto en el servicio por lo que se recomienda realizar este paso en ventana)
# kubectl delete pod vmware-system-ako-ako-controller-manager-ID-DEL-POD -n vmware-system-ako
Esperamos unos segundos y un nuevo pod se desplegará, obtenemos logs de éste:
Eureka!! De aquí en adelante, nuestro entorno de vSphere with Tanzu solo escogerá esta red para publicación de VIPs, omitiendo cualquier otra que utilicemos para otra finalidad y tengamos en el IPAM
Como siempre, ¡Espero que os haya gustado! ¡Nos leemos pronto!