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: 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: “true” generateTLS: “true” kubernetes: ingressEndpoint: publishedService: “kube-system/traefik” metrics: prometheus: enabled: “true” Esta configuración es muy parecida a la que despliega K3s y a la hemos añadido el dashboard donde podremos revisar el estado de […]
Categoría: Series
Series de artículos explicativos sobre un tema tecnológico con un objetivo común.
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: 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 representa una mayor complejidad). Usando Helm Una vez dispuesto nuestro cluster Kubernetes (ver Kubernetes: Crear un entorno mínimo para demos o K3s: Kubernetes más simple) procedemos a descargar en el nodo master el binario de Helm con: Y ya está, no hay que instalar nada y podemos instalar los paquetes que necesitemos directamente, eso si, hay que tener en cuenta que no crea automáticamente los espacios de nombres (namespaces) ya que se considera que eso no es una tarea de despliegue sino de gestión de la infraestructura.. En el caso de Powerdns, que tiene como dependencia una base de datos mariadb y al que podemos acoplar opcionalmente un dashboard con PowerDNS-Admin vamos a requerir este tipo de paquetes, porque son útiles si queremos que los clientes dispongan de su propio servidor DNS gestionado por ellos mismos. En próximos artículos veremos que además este servidor es integrable con External-DNS, que nos permitirá publicar en PowerDNS las modificaciones en los proxy de entrada de Kubernetes (por ejemplo un Ingress con Traefik). Para crear un paquete con la estructura mínima hacemos: […]
PowerDNS sobre Docker o Podman, fácil y rápido
Que es PowerDNS y DNS como servicio crítico PowerDNS es un servidor DNS, siendo este un servicio especialmente crítico en cualquier infraestructura que deseemos desplegar, ya que es el principal punto de conexión entre servicios y operadores. Si de todas las opciones que nos encontramos cuando buscamos un servidor DNS (podemos ver una larga lista en https://en.wikipedia.org/wiki/Comparison_of_DNS_server_software) buscamos las tres siguientes condiciones: que se pueda gestionar fácilmente, despliegue sencillo y OpenSource nos vamos a quedar en una solo opción: PowerDNS y para su gestión PowerDNS-admin. PowerDNS ( cuyo desarrollo se puede ver en https://github.com/PowerDNS/pdns y tiene más de 1800 estrellas) es un potente servidor DNS cuya características más interesantes para la gestión son disponer de un servicio web con una potente API y ser capaz de almacenar la información en bases de datos, como MySQL. Y seleccionamos PowerDNS-Admin por dos razones: Está activamente mantenido (https://github.com/ngoduykhanh/PowerDNS-Admin, más de 750 estrellas) y visualmente es un entorno más amigable al tener un formato parecido al que las herramientas de RedHat están usando actualmente. ¿Porqué PowerDNS con PowerDNS-Admin? Porque conforman un potente paquete donde tenemos las siguientes ventajas: Fácil de instalar Fácil de mantener Interfaz intuitivo Todo está guardado en una base de datos (lo que facilita replicación, copias de seguridad, alta disponibilidad, etc). No requiere configuración especial del navegador (como es el caso de RedHat IDM que requiere instalar el certificado del servidor). Para la gestión de los operadores dispone de autenticación contra múltiples fuentes (LDAP, AD, SAML, Github, Google, etc). Dispone de control sobre los permisos de acceso a los dominios A estas ventajas hay que unirles la existencia de múltiples contenedores que facilitan sobremanera como desplegar y actualizar está solución. Desplegar PowerDNS con Docker-Composer La solución con PowerDNS consta de tres partes: el servidor dns, para el cual haremos uso de contenedor pschiffe/pdns-mysql:alpine (https://github.com/pschiffe/docker-pdns/tree/master/pdns), el servidor de base de datos mariadb a través del contenedor yobasystems/alpine-mariadb(https://github.com/yobasystems/alpine-mariadb) y el contenedor aescanero/powerdns-admin que hemos explicado en un post anterior (Docker: Reducir el tamaño de un contenedor). Es importante indicar que los tres contenedores tienen un mantenimiento activo y son de reducido tamaño, lo que permite un rápido despliegue. Los puertos 53/UDP y 9191/TCP deben de estar disponibles en la máquina que ejecute los contenedores. Para poder dotar de espacio de almacenamiento en la base de datos se le ha añadido un volumen a la base de datos mariadb, para obtener de esa manera […]
Kubernetes: aventuras y desventuras de parchear (kubectl patch).
Kubernetes es una potente herramienta de orquestación de contenedores donde se ejecutan muchos y diferentes objetos que en algún momento nos va a interesar modificar. Para ello Kubernetes nos ofrece un interesante mecanismo: patch que vamos a explicar y veremos que está lejos de ser una herramienta lo bastante potente como sería deseable. Operaciones de parcheo (sustitución) en Kubernetes Según la documentación de Kubernetes y las normas de la API de Kubernetes se definen tres tipos (con –type): Strategic Es el tipo de parche que usa Kubernetes por defecto y es un tipo nativo, definido en el SIG, sigue la estructura del objeto original pero indicando los cambios (por defecto unir: merge, por eso se conoce por strategic merge patch) en un fichero yaml. Por ejemplo si tenemos el siguiente servicio (en el fichero service.yml): Vamos a utilizar el comando kubectl patch -f service.yml –type=”strategic” -p “$(cat patch.yml)” –dry-run -o yaml que nos va a permitir realizar pruebas sobre los objetos sin el peligro de modificar su contenido en el cluster Kubernetes. Si queremos que dicho servicio escuche por un puerto adicional utilizaremos la estrategia “merge” y aplicaremos el siguiente parche (patch.yml): Como vemos, el parche solo sigue el objeto servicio hasta donde queremos realizar el cambio (el array “ports”) y al ser un cambio de tipo “strategic merge” se dedicará a añadirlo a la lista como se ve en el volcado del comando: Pero si en vez de “merge” utilizamos “replace” lo que hacemos es eliminar todo el contenido del subárbol donde estamos al indicar la etiqueta “$patch: replace” y en su lugar pone directamente el contenido del parche. Por ejemplo para cambiar el contenido del array usamos como “patch.yml”: En este ejemplo se elimina todo el contenido de “ports:” y en su lugar se deja el objeto definido después de la etiqueta “$patch: replace”, aunque el orden no es importante, la etiqueta puede ir detrás y tiene el mismo efecto. El resultado del anterior es: Por último “delete” que se indica con “$patch: delete” elimina el contenido del subárbol, aunque se le añada contenido este no es añadido. El resultado será el contenido de spec vacío: Merge Este tipo de parche es un cambio radical frente a “strategic” ya que requiere la utilización de JSON Merge Patch (RFC7386), se puede aplicar como yaml o json y se basa en un procedimiento de aplicación de cambios con a partir […]
K3s: Kubernetes más simple
K3s para demos, muchas ventajas sobre Kubernetes por despliegue y tamaño.
Kubernetes: Crear un entorno mínimo para demos
Crear un entorno mínimo para demos de Kubernetes