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 […]

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 […]

Como lanzar un paquete (Chart) de Helm sin instalar Tiller

Uno de los detalles más interesantes que me he encontrado al usar K3s (https://k3s.io/) es la manera de desplegar Traefik, en el cual utiliza un esquema (chart) de Helm (nota: en Kubernetes el comando a ejecutar es sudo kubectl, pero en k3s kubectl está integrado para que use menos recursos).. Nos encontramos que helm no está instalado, pero si vemos un job que ejecuta el cliente de helm para que podamos disponer de su potencia sin la necesidad de tener corriendo tiller (el servidor de helm) que por supuesto utiliza recursos y de esta manera nos los ahorramos, pero ¿Como funciona? Klipper Helm Lo primero que vemos es el uso de un job (tarea que habitualmente se ejecuta una única vez en forma de contenedor) basado en la imagen “rancher/klipper-helm” (https://github.com/rancher/klipper-helm) que ejecuta un entorno helm con solamente descargarlo y ejecutar un único script: https://raw.githubusercontent.com/rancher/klipper-helm/master/entry Como requisito si va a requerir una cuenta de sistema con permisos de administrador en el espacio de kube-system, para traefik es: Lo que debemos tener en cuenta es la necesidad de crear la cuenta de servicio y al terminar la tarea de instalación con helm eliminarla ya que no será necesaria hasta otra operación de eliminación o actualización.Como ejemplo vamos a crear una tarea para instalar un servicio weave-scope utilizando el chart helm (https://github.com/helm/charts/tree/master/stable/weave-scope) Creación del servicio Creamos un espacio de trabajo para aislar el nuevo servicio (namespace en kubernetes, proyecto en Openshift) que llamaremos helm-weave-scope: Creamos una nueva cuenta de sistema y le asignamos los permisos de administrado: Nuestro siguiente paso es crear la tarea, para ello la creamos en el fichero tarea.yml: La ejecución Y lo lanzamos con: Lo que va a lanzar todos los procesos que el chart tenga: El resultado Podemos observar la correcta instalación de la aplicación sin la necesidad de instalar Helm ni tiller corriendo en el sistema: Actualización Con la llegada de Helm v3 no se hace necesario Tiller y su uso es mucho más sencillo. Para explicar su funcionamiento, se explica como se hizo un Chart para PowerDNS en Helm v3 para desplegar PowerDNS sobre Kubernetes, esto también evita el uso de Klipper evitando jobs no requeridos.

Volver arriba