Kubernetes y Helm: monitorizando con Prometheus y Grafana

Docker, Kubernetes y Helm para ser monitorizados con Prometheus y Grafana

Helm nace durante la conferencia Pycon del año 2013. Bueno, exactamente no fue Helm, fue Docker; al señor Solomon Hykes le tomó poco más de cinco minutos el cambiar por completo la historia de la informática. Vale, admito que es una barrabasada, no todos conocen -y usan- Docker y/o Kubernetes, pero existe un hecho que es innegable: Helm en noviembre de 2019 tuvo un millón de descargas y eso es algo importante. Ya veremos por qué.

Pensad en manadas, no en mascotas

Para poder presentar a Helm es necesario, de manera rápida pero ampliada, describir lo que es una máquina virtual y su ambiente. Si eres experto en informática lo que viene a continuación probablemente lo sabrás; si es así salta a la siguiente sección, por favor. Coloco varios enlaces a este vuestro blog; poned atención si deseáis ampliar información sobre algunos de los puntos, se os abrirá una nueva pestaña, leed y regresad por favor.

Una máquina virtual se ejecuta como un programa más en una máquina real y alberga un sistema operativo completo, el cual ignora que sus componentes (memoria, disco, etc.) son imaginarios. A la virtual se le denomina SO invitado y a la real SO anfitrión y el programa que ejecuta al SO invitado se le llama hipervisor. Tan extendido está el uso de hipervisores que probablemente vuestro ordenador, en su placa madre, tenga unos chips especialmente dedicados para mejorar el desempeño del hardware.

Mi hipervisor favorito es VirtualBox®, por su simplicidad y variedad de plataformas. De hecho, para los programadores que necesitamos una infraestructura inmutable podemos usar Vagrant para tener nuestros entornos de desarrollo de manera virtual con guiones que podemos reutilizar y modificar mediante control de versiones. Otros famosos hipervisores son: VMWare, Xen, hyperv y kvm.

De manera similar los administradores de red pueden -y deben- poner a nuestra disposición poderosas máquinas reales con sus hipervisores ya instalados por medio de la Administración de Configuración de Servidores o ACS. Luego con Vagrant, dentro de los dispositivos virtuales, instalaremos Puppet, Ansible, etc., para aprovisionar el resto del software virtual.

Aquí introduzco un concepto: pensad que trabajáis con «rebaños» de máquinas, no con vuestro ordenador en casa que es una querida -única e irreemplazable- «mascota». Con programas como Vagrant, Chef, Puppet, Ansible y más podemos reproducir, una y otra vez y de manera automatizada, todos y cada uno de nuestros servidores (siempre y cuando hagamos y atesoremos los ficheros con instrucciones para ello).

Pandora FMS tiene experiencia en monitorizar una variedad de soluciones virtualizadas, y para ello tiene un capítulo aparte dedicado en su manual de uso ( Amazon EC2®, VMware®, RHEV®, Nutanix®, XenServer®, OpenNebula®, IBM HMC®, HPVM® ).

Hasta aquí todo bien pero –siempre hay un pero– este esquema consume muchos recursos, así que estaremos bastantes limitados a la hora de ejecutar varios SO virtuales al mismo tiempo con nuestro hardware real.

Desde hace décadas GNU/Linux® impera en servidores y superordenadores, y como esto de las máquinas virtuales es bastante viejo en realidad (empresa IBM, años 1960), al SO del pingüinito no le es ajeno su uso. Pero aquí viene la genialidad del desarrollo de contenedores: reutilizar el kernel Linux para poder albergar más máquinas virtuales al mismo tiempo. De esta manera podemos fraccionar el uso de los componentes (mediante lxc y cgroups y otros componentes del kernel Linux ) e incluso probar varias distribuciones: pudiéramos en Ubuntu ejecutar un contenedor con CentOS, por ejemplo. ¡Pues para ello nació Docker® en 2013, tal como os dije al principio, para facilitar nuestro trabajo diario!

Si ese ahorro de recursos de hardware les pareció poco, hay más: ¿Qué tal si ese CentOS que descargamos lo tenemos como cimiento inamovible y sobre él «montamos» aplicaciones virtualizadas? Pues ya vamos a lo práctico: Pandora FMS puede ser ejecutado de esta manera y con multi-stage builds podemos mantener al mínimo el tamaño de las imágenes.

Docker® y su universo

Solomon Hykes funda la empresa dotcloud en 2010 y su gran éxito fue desarrollar Docker en 2013. Docker, como producto, creció tanto que hoy en día es una empresa como tal. Dotcloud -su tecnología y nombre- fue vendida a otra empresa llamada cloudControl, quienes declararon su bancarrota en 2016.

Es un caso raro llamado «empresa unicornio»: Docker como software es la joya de la corona y ha sido adoptado extensamente por personas y empresas. Una vez instalado por un usuario raíz o root user (usuario con derechos de administración) Docker permite a todos los demás usuarios sin derechos de administración el correr sus contenedores sin mayor limitación que la impuesta por la capacidad del hardware real.

En nuestro caso, en el campo de la monitorización, generó nuevos retos y éxitos para Pandora FMS.

En el campo de la seguridad fue presentado Docker Bench, ya que, a nuevos problemas, nuevas soluciones.

A mí me fascina la línea de comandos y Docker es tan complaciente en ello que frecuentemente, cuando pasamos variables de entorno para nuestras aplicaciones, se torna largo y no práctico. Por ello usaremos un archivo Docker o Dockerfile para ello. Tomad nota que también nuestras aplicaciones deben estar programadas teniendo esto en cuenta, así podremos desplegar muchos contenedores con diferentes características de acuerdo a esas variables.

También podemos -o más bien debemos- usar Docker-compose en formato YAML para instrucciones más complejas y estructuradas, para su mejor comprensión de nosotros, los humanos, y que las máquinas también pueden leer e interpretar.

Pronto Docker se vio desbordado en su uso y demanda, y surgió la necesidad de orquestar grandes grupos de contenedores; para ello desarrollaron Docker Swarm, predecesor -considero yo- de Kubernetes.

¡Atención!
Los datos de un contenedor son volátiles. Al finalizar o reiniciar nuestro equipo real perderemos nuestras bases de datos, ficheros, etc., que hayamos agregado. Para evitar esto, Docker ofrece métodos de persistencia (volúmenes locales o conexión a volúmenes remotos); en el caso de las bases de datos también podemos alojarlas en máquinas reales y permitir a Docker el conectarse a ellas.

Kubernetes

¿Qué podía ser más revolucionario que Docker? ¡Pues eliminar al mismo Docker! Dicho de manera brusca: Kubernetes (desarrollado por Google) saca de la jugada a Docker y se comunica directamente con containerd 1.1, de binario a binario y con una poderosa API que facilita y automatiza su administración. El «coste» es que necesita derechos de administrador, y ya bien sabéis aquello que dicen, parafraseo: “Un gran poder conlleva una gran responsabilidad”. La nueva alternativa que también busca sustituir a Docker es Podman.

La unidad fundamental de Kubernetes es el kubelet, que se encarga de agrupar y administrar varios contenedores en una vaina -llamada pod– en miles de racimos o clusters que pueden ser orquestados con mayor facilidad por nosotros.

Mi consejo para toda empresa es que comencemos con Docker y «nos ensuciemos las manos» sustituyendo servicios uno a uno, guardando todos nuestros progresos con control de versiones. Y que luego pasemos a Minikube, que bien puede utilizar Docker (entre otros) y VirtualBox (entre otros) para virtualizar de manera local un Kubernete. Minikube tiene muchas ventajas, pero destaco: usamos exactamente la última versión de Kubernetes con todas sus características y con una curva de rápido aprendizaje basado en ensayo y error.

Nunca perdamos de vista que cuando vayamos en grande siempre debemos contar con un equipo de personas bien comunicadas, que corrobore y compruebe nuestros guiones y despliegues (método científico, emule resultados en pequeño, «pruebas de concepto») y que documente y organice todo para lograr una versión estable; luego el ciclo se repite de nuevo.

Kubernetes dispone de mapas de configuración o configmaps que contienen instrucciones para formar volúmenes y espacios de nombres de manera dinámica. Siempre es importante nombrar, o más bien etiquetar (establecer y aplicar tags), nuestros mapas de configuración, ya que Grafana hará uso de ellos. ¿Recuerdan las variables de entorno? Con los mapas de configuración también podremos hacer lo mismo que en Docker y, además, en cualquier momento en el transcurso de vida de los contenedores. Con Kubernetes Secrets haremos otro tanto con nombres de usuario, contraseñas, etc., de manera cifrada y segura, también de forma dinámica a todos los nodos que tengamos desplegados.

Una vez estemos diestros en esto podemos pasar a utilizar Helm, con rumbo a nuestro destino final: Prometheus y Grafana.

Helm

«Helm» es la abreviatura (en desuso) de «helmet» o casco en idioma inglés. Actualmente significa timón y su nombre viene a cuento porque se utiliza para buscar y administrar paquetes en Kubernetes, cuyo logotipo también es un timón (todo esto viene del concepto de contenedores o containers para el transporte marítimo por puertos o dockers… sí, el mundo geek es un tanto extraño).

Helm nace en la conferencia KubeCon del año 2015; en realidad se denominó Helm Classic y no tuvieron empacho alguno en tener inspiración de Homebrew, el popular controlador de paquetes en el sistema operativo MacOS.

Me detengo aquí de manera breve: homebrew es el proceso de realizar en casa nuestra propia cerveza y denota un método puramente artesanal pero con un alto nivel de calidad. Los usuarios -más bien fanáticos- de MacOS se distinguen por tener todo en orden y tal como ellos quieren y/o necesitan: cuando reemplazan un ordenador o teléfono móvil en muy poco tiempo tienen todo a punto de nuevo y reanudan su trabajo y producción.

En 2016 Helm 2 forma parte formal de Kubernetes y fue evolucionando y fusionando con otros proyectos, como Monocular, Helm Chart Repo, Chart Museum, para luego llegar a Helm Hub en 2018. Actualmente contamos con Helm 3 desde noviembre de 2019 con unas modificaciones importantes que lo acercaron a su origen, Helm Classic.

Ya entrando de lleno en Helm, el concepto clave es el uso de cartas de trabajo o Charts que abarcan una carga de trabajo o workload dentro de Kubernetes (instalar un servidor web, una base de datos, etc., como también puede ser un servicio). Aunque suena sencillo… ¡ya veis el recorrido para llegar hasta aquí!

Desde el concepto de charts, agreguemos:

• Las charts tienen la información necesaria para instalar -se usa el término desplegar, más adecuado- nuestros servicios y aplicaciones.
• ¿Recuerdan los configmaps y Kubernetes Secrets? Helm necesita un config con esos datos y personalizaciones para fusionarlo en una o varias charts para luego desplegar en racimos de Kubernetes.
• Un lanzamiento o release es una chart y un config que se ejecutan en Kubernetes. Helm cuidará de su nacimiento, vida y muerte por nosotros. Nosotros indicaremos si mientras viva se debe modificar, sin detener su funcionamiento, y que estos cambios queden almacenados para los siguientes «nacimientos de nuestros rebaños».

¿Qué les parece? ¡Maravilloso! Trabajar con Helm y Kubernetes es como tener granjeros y granjas a nuestra disposición que se encargan de todos los aspectos pero siguiendo de manera muy pulcra y detallada cada una de nuestras ideas e instrucciones.

Prometheus y Grafana

Prometheus aparece en 2012 de la mano de la empresa SoundCloud® que necesitaba un software de monitorización muy especial (lástima, ellos no conocían Pandora FMS). Para 2015 la versión estuvo lista para trabajar y al año siguiente la Cloud Native Computing Foundation®, un proyecto de la Fundación Linux®, sumó a Kubernetes® 1.0 (su proyecto, que también debutó en 2015) para labores de monitorización. A partir de este momento Prometheus fue orientado hacia la virtualización, aunque no deja de ser parte de otros software tales como Percona PMM.

Grafana, por otra parte, es el músculo gráfico y nativo de Prometheus, además de que tiene de manera preconfigurada una gran cantidad de tableros o pizarras electrónicas (dashboards) para mostrar de manera formal los valores.

El software de alerta de Prometheus es el AlertManager.

Monitorización de Kubernetes

Una vez conocido todo esto, debemos instalar Helm y clonar con git el repositorio que contiene la chart para Prometheus y la chart para Grafana con valores por defecto, etiquetas o tags necesarias incluidas para poder monitorizar Kubernetes; llegamos entonces al punto más importante:

helm install stable/prometheus
helm install stable/grafana

Si agregamos el parámetro – – name= correspondiente a ambas órdenes, desde ya iniciaremos nuestro nuevo control de versiones; con kubectl get svc obtendremos la lista de servicios en ejecución con dirección IP y puertos para poder acceder a la interfaz web.

Para personalizar nuestros valores debemos modificar el YAML de Prometheus: prestad atención al Control de Acceso Basado en Roles (RBC); volúmenes persistentes y bases de datos persistentes, puertos expuestos, balanceo de carga, etc., y volved a desplegar con Helm para observar cómo se adaptan los cambios de manera dinámica. En la comunidad de Grafana existen muchos más dashboards disponibles, a la larga podremos modificar o incluso crear los nuestros, ¡y compartirlos!

Con esto podemos iniciar así nuestro proceso de aprendizaje en pos de aplicarlos a Pandora FMS, ya bien sea:

• Crear y desplegar nuestros servidores y consolas de Pandora FMS.
• Crear y desplegar servidores satélites de Pandora FMS.
• Instalar agentes software de Pandora FMS en uno o varios cluster de Kubernetes establecidos por terceros que nos hayan contratado para ello.

Nota: Nada de lo que expreso y explico aquí es la posición oficial de la empresa Pandora FMS o de su equipo de desarrollo, todo esto es puramente conceptual. En este enlace podréis leer la hoja de ruta oficial de Pandora FMS.

Antes de despedirnos, recuerda que Pandora FMS es un software de monitorización flexible, capaz de monitorizar dispositivos, infraestructuras, aplicaciones, servicios y procesos de negocio.

¿Quieres conocer mejor qué es lo que Pandora FMS puede ofrecerte? Descúbrelo entrando aquí.

Si tienes que monitorizar más de 100 dispositivos también puedes disfrutar de una DEMO GRATUITA de 30 días de Pandora FMS Enterprise. Consíguela aquí.

Por último, recuerda que si cuentas con un número reducido de dispositivos para monitorizar puedes utilizar la versión OpenSource de Pandora FMS. Encuentra más información aquí.

No dudes en enviar tus consultas. ¡El equipo de Pandora FMS estará encantado de atenderte!