kubeconfig con direnv, múltiples clusters de Kubernetes.

kubeconfig con direnv, múltiples clusters de Kubernetes.

Desde la documentación de Kubernetes:

Utilice los archivos kubeconfig para organizar la información acerca de los clústeres, los usuarios, los Namespaces y los mecanismos de autenticación. La herramienta de línea de comandos kubectl utiliza los archivos kubeconfig para hallar la información que necesita para escoger un clúster y comunicarse con el servidor API de un clúster.

Nota: Un archivo utilizado para configurar el acceso a los clústeres se denomina archivo kubeconfig. Esta es una forma genérica de referirse a los archivos de configuración. Esto no significa que exista un archivo llamado kubeconfig.

Por defecto, kubectl busca un archivo llamado config en el directorio $HOME/.kube. Puedes especificar otros archivos kubeconfig mediante la configuración de la variable de entorno KUBECONFIG o mediante la configuración del flag –kubeconfig.

Cuando contamos con un solo cluster de k8s, es bastante fácil conectarse a el usando kubectl con solo colocar el archivo config en .kube (como dice el texto anterior). ¿Pero que pasa cuando tenemos varios servidores de k8s con los cuales queremos interactuar para realizar ciertas tareas?

Debemos hacer uso de los contextos (context) y movernos de un cluster a otro, esto implica que en archivo config antes mencionado, tenemos la información de mas de un cluster. Para facilitar esta operación tenemos disponibles varios plugins, uno de estos es ctx que se puede instalar con Krew. Yo personalmente me encuentro tedioso mantener el archivo config (se que también existen plugins para esto.) y muchas veces termino con configuración de acceso a cluster que ya no existen y que en su momento fueron usados para alguna prueba de configuración. ¿A donde quiero llegar con esto? Creo que hay una forma mas fácil, por lo menos para mi.

Tenemos disponible una herramienta llamada direnv, esta herramienta permite cargar variables de entorno al momento de entrar a un directorio, inmediatamente hacemos cd dentro de un directorio que cuente con un archivo de direnv (.envrc), tendremos disponibles variables de entorno para usar y una de esas variables que podemos configurar es kubeconfig.

Desde hace unos días estoy estructurando el acceso a varios clusters que tengo de la siguiente manera.

  1. Un directorio con todos los cluster que deseo acceder o tengo acceso a ellos.
  2. En este directorio cada cluster es otro directorio, por ejemplo “ansible” es un cluster de k8s que tiene AWX instalado.
  3. Dentro de “ansible” esta el archivo config, .envrc y archivos de deploymento ha sean Helm o Kustomize.

Dejo una captura de pantalla con la estructura del directorio.

En lo adelante cuando siga provisionando cluster, solo tengo que crear un nuevo directorio, colocar el archivo config y crear un nuevo .envrc con la información necesaria.

El contenido de .envrc es:

export KUBECONFIG=/home/ariel/Documents/kubeclusters/ansible/config

importante saber que aquí podemos colocar todo tipo de acciones iguales a las que normalmente usamos en nuestro profile, por ejemplo, aliases e incluso un prompt diferente.

Al ejecutar kubectl get nodes, podemos ver que no tenemos respuesta ya que en ese momento kubeconfig esta configurado con un config no funcional, cuando entramos al directorio ansible, se ve que direnv habilita un nuevo valor que sobre-escribe a kubeconfig con el nuevo config del cluster de AWX.

direnv tiene mucho potencial para aquellos usuarios que amamos la terminal!

homelab – update – 2023:02:01

Ya no recuerdo cuando inicie con esto de operar un homelab, y en realidad ya es algo que forma parte de como aprendo nuevas tecnologías y por mas que exista la “nube”, es muy costoso para los productos/soluciones que pruebo en los equipos que tengo en mi casa.

En este update verán como he dejado de usar los Dell R420 y me he pasado a equipos con menos consumo.

pathvector – herramienta para configurar BIRD!

pathvector – herramienta para configurar BIRD!

Hace tiempo que estoy usando BIRD para convertir esos servidores Linux en routers con BGP/OSPF y tener enrutamiento dinámico. Uno de los obstáculos iniciales con BIRD era la sintaxis, muy diferente a Cisco y a Quagga (Ahora FRR), sentirme a gusto me tomo tiempo, pero se logro.

De ese cambio ya hace mucho tiempo, el segundo paso luego de usar BIRD es lo fácil que se puede automatizar su configuración, algo que hice en los primeros días era tener los archivos de configuración en Git para así poder versionarlos, luego usaba un contenedor Docker el cual generaba las configuraciones finales, lamentablemente cada herramienta o metodología tenia sus propios problemas y terminaba haciendo configuraciones manuales fuera de la herramienta que intentaba adoptar.

Continuar leyendo «pathvector – herramienta para configurar BIRD!»

LACNIC35 – mi experiencia como presentador en el FTL.

LACNIC35 – mi experiencia como presentador en el FTL.

Hace ya unas semanas fue le entrega de la versión 35 de LACNIC (LACNIC35), esta vez me anime a participar y proponer una presentación que más adelante fue aceptada. La experiencia de participar en dicho evento me ha dejado con ganas de mas y espero que esta sea la primera de muchas otras participaciones por venir.

Personalmente creo que en mi país (Republica Dominicana) la participación en las comunidades relacionadas directamente a LACNIC y otras tales como LACNOG es baja, desconozco las razones. Contando con que, en el 2019, Republica Dominica fue sede de la versión 31 (LACNIC31), se esperaría que en las siguientes entregas la participación fuese mayor o por lo menos igual, este no es el caso.

Aquí les dejo los enlaces de todas las presentaciones del FTL.

https://www.lacnic.net/5220/61/evento/foro-tecnico-de-lacnic

mi presentación: https://www.lacnic.net/innovaportal/file/5220/1/automatizando-bird.pdf