Como publicar Kubernetes con External DNS, MetalLB y Traefik.

Kubernetes con External DNS, MetalLB y Traefik nos van a servir para que las aplicaciones web (en un entorno o no de microservicios) se publiquen, ya que los requisitos básicos son resolver por DNS el nombre del equipo y la ruta web que lleva a la aplicación. El gran mapa Tras los pasos realizados en K3s: Kubernetes más simple y Helm v3 para desplegar PowerDNS sobre Kubernetes vamos a darle forma a una solución Kubernetes más completa para que pueda publicar servicios bajo su propio dominio y ruta y que a su vez sea accesible desde el exterior. Y siempre usando los mínimos recursos en esta tarea. MetalLB MetalLB que nos permitirá emular la potencia de los balanceadores de los entornos Cloud, los requisitos de está solución son una versión de Kubernetes 1.13 o superior, que no exista otro balanceador de red operativo y que el controlador de red esté soportado en la lista indicada en https://metallb.universe.tf/installation/network-addons/, debemos tener en cuenta que K3s incluye flannel que está soportado y que en el caso de otros como Weave se requieren una serie de modificaciones. Para instalar MetalLB solo es necesario aplicar el archivo “yaml” que despliega todos los elementos: Y para activar MetalLB le creamos una configuración (archivo pool.xml) que tendrá la forma: Que al aplicar con k3s kubectl apply -f pool.yml configurará MetalLB para que en el caso de que existan servicios con loadBalancer utilicen una de las IPs definidas en el rango especificado (en este caso 192.168.9.240/28). MetalLB es una gran ventaja sobre otros tipos de soluciones locales, ya que no requiere del uso de SDN (como es el caso de Kubernetes sobre VMware NSX) o de servidores específicos para la publicación (como el caso de OpenShift, que ademas de SDN requiere de maquinas especificas para publicar servicios). Traefik Traefik es un servicio enrutador con múltiples características como son: Enrutador Edge Descubrimientos de servicios Balanceador de carga en capa 7 Terminador TLS y soporte Let’s Encrypt (ACME) Dispone de un Kubernetes Ingress Controller Dispone de un CRD IngressRoute Permite Canary Deployments Trazas, métricas y registro Con K3s se despliega de forma automática Traefik al iniciar el nodo master, en el caso de Kubernetes se va a hacer a través de Helm y para la configuración necesitamos un archivo yaml como el siguiente: dashboard: enabled: “true” domain: “traefik-dashboard.DOMINIO” auth: basic: admin: $apr1$zjjGWKW4$W2JIcu4m26WzOzzESDF0W/ rbac: enabled: “true” ssl: enabled: “true” mtls: enabled: “true” optional: […]

Helm v3 para desplegar PowerDNS sobre Kubernetes

En el artículo PowerDNS sobre Docker o Podman, fácil y rápido dejamos un punto pendiente sobre Kubernetes, esto es así porque la estructura de servicios de Kubernetes es mucho más compleja que la de Docker o Podman y por tanto hay que hacer un planteamiento completamente diferente. Empaquetar con Helm v3 Lo primero que debemos tener en mente es empaquetar aplicaciones para que su despliegue no requiera de amplios conocimientos sobre Kubernetes (hacer la vida al usuario más fácil) y lo segundo es que podemos tener muchos usuarios sobre el mismo entorno deseando querer la misma aplicación y no podemos crear un paquete para cada uno, debemos poder reutilizar el paquete creado. En Kubernetes el estándar de paquetes es Helm que nos va a permitir gestionar despliegues de forma fácil y siendo reutilizables por usuario, proyecto, etc. El paquete Helm está formado por: Chart.yaml: Que es la metainformación sobre el propio paquete. templates: Carpeta donde vamos a definir los objetos que van a ser desplegados en Kubernetes, pero que van a tener ciertas modificaciones para que sean flexibles. values.yaml: En los objetos a desplegar existirán una serie de variables que habrán de definirse (p.e. servidores a los que acceder, claves de acceso, bases de datos en un servidor, etc), en este fichero se definen los valores predefinidos de cada variable, para que posteriormente el usuario que lance el paquete pueda ajustarlo a su gusto. NOTES.txt: Dentro de “templates” se coloca este archivo que contendrá un mensaje sobre el resultado de la instalación del paquete, como puede ser como obtener la IP o URL de acceso. _helpers.tpl: Este archivo que también encontraremos dentro de la carpeta “templates” contiene definiciones de variables que podremos usar en las objetos, como es por ejemplo el nombre del paquete correctamente definido y que nos permitirá realizar múltiples despliegues de la misma aplicación en el mismo espacio de nombres simplemente cambiando el nombre de versión del despliegue. Helm v3 es la versión en desarrollo de Helm (en el momento de escribir estas lineas Helm va por la versión v3 beta3) pero que dispone de capacidades tan interesantes como gestión del ciclo de vida o no requerir de servicios integrados en Kubernetes para desplegar paquetes (para realizar algo parecido en la versión 2 ver Como lanzar un esquema (Chart) de Helm sin instalar Helm, que requiere de un job y un pod lanzador con Tiller, lo que […]

Volver arriba