Kubernetes y Helm: monitorizando con Prometheus y Grafana

Helm nace durante la conferencia Pycon del año 2013. Bueno, exactamente no fue Helm, fue Docker y al señor Solomon Hykes le tomó poco más de cinco minutos el cambiar por completo la historia de la informática. Okey, admito que es una barrabasada, no todos y todas 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 que de manera rápida, pero ampliada, describir lo que es una máquina virtual y su ambiente. Si eres experto o experta en informática, lo que viene a continuación probablemente lo sabéis, si es así saltad a la siguiente sección por favor. Coloco varios enlaces a este vuestro blog, poned atención si deseáis ampliar 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.

Virtual machines schema,  Jens Lechtenbörger - Gitlab:  https://oer.gitlab.io/oer-on-oer-infrastructure/Docker.html#/slide-virtualization
Virtual machines schema, Jens Lechtenbörger – Gitlab: https://oer.gitlab.io/oer-on-oer-infrastructure/Docker.html#/slide-virtualization

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étera para aprovisionar el resto del software virtual.

Acá 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 acá 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!

Jens Lechtenbörger - GitLab https://oer.gitlab.io/oer-on-oer-infrastructure/Docker.html#/slide-containerization
Jens Lechtenbörger – GitLab https://oer.gitlab.io/oer-on-oer-infrastructure/Docker.html#/slide-containerization

Si ese ahorro de recursos de hardware les pareció poco, pues 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

«El futuro de los contenedores en Linux» por Solomon Hykes, año 2013 (vídeo vía dotcloud en YouTube).

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 somo software es la estrella 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, 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. 

Docker logo (Wikipedia https://commons.wikimedia.org/wiki/File:Docker_(container_engine)_logo.svg )
Docker logo (Wikipedia https://commons.wikimedia.org/wiki/File:Docker_(container_engine)_logo.svg )

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 nos 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 y 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 pues perderemos nuestras bases de datos, ficheros, etc que hallamos 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

Kubernetes logo (Wikipedia: https://commons.wikimedia.org/wiki/File:Kubernetes_logo.svg )
Kubernetes logo (Wikipedia: https://commons.wikimedia.org/wiki/File:Kubernetes_logo.svg )

¿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 «costo» es que necesita derechos de administrador y ya bien sabéis aquello que dicen, parafraseo: «una 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 a varios contenedores en una vaina -llamado 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. 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.

Minikube logo (Blog ochobitshacenunbyte https://www.ochobitshacenunbyte.com/2020/02/10/minikube-kubernetes-en-ubuntu-18-04/)
Minikube logo (Blog ochobitshacenunbyte https://www.ochobitshacenunbyte.com/2020/02/10/minikube-kubernetes-en-ubuntu-18-04/)

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.

Por favor, lea también   Alternativa Datadog ®:¡una muy interesante comparativa con Pandora FMS!

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 y diestras en esto podemos pasar a utilizar Helm, con rumbo a nuestro destino final: Prometheus y Grafana.

Helm

Helm logo (GitHub: https://github.com/cncf/artwork/blob/master/projects/helm/stacked/color/helm-stacked-color.png)
Helm logo (GitHub: https://github.com/cncf/artwork/blob/master/projects/helm/stacked/color/helm-stacked-color.png)

«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.

Para 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… ¡pues ya veis el recorrido para llegar hasta acá!

Desde el concepto de charts, agreguemos:

  1. Las charts tienen la información necesaria para instalar -se usa el término desplegar, más adecuado- nuestros servicios y aplicaciones.
  2. ¿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.
  3. 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 a 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 forma 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=<nuestro nombre> 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 como 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.

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í: https://pandorafms.com/es

Si cuentas con más de 100 dispositivos para monitorizar puedes contactar con nosotros a través del siguiente formulario: https://pandorafms.com/es/contactar/

Además, recuerda que si tus necesidades de monitorización son más limitadas tienes a tu disposición la versión OpenSource de Pandora FMS. Encuentra más información aquí: https://pandorafms.org/es/

No dudes en enviar tus consultas. ¡El equipazo de Pandora FMS estará encantado de atenderte!
TítuloEnlace
Monitorización como Código con Grafana en Kuberneteshttps://enmilocalfunciona.io/monitorizacion-como-codigo-con-grafana/
CNCF Project Spotlight: Helmhttps://www.cncf.io/blog/2020/06/08/cncf-project-spotlight-helm/
Helm Architecturehttps://helm.sh/docs/topics/architecture/
HelmFrequently Asked Questionshttps://helm.sh/docs/faq/
Despliega tus aplicaciones en Kubernetes con Helm (I)https://enmilocalfunciona.io/despliega-tu-aplicaciones-en-kubernetes-con-helm/
Despliega tus aplicaciones en Kubernetes con Helm (II): Monocular y Chart Museumhttps://enmilocalfunciona.io/despliega-tus-aplicaciones-en-kubernetes-con-helm-ii-monocular-chart-museum/
Despliega tus aplicaciones en Kubernetes con Helm (III): Crea tus propios Chartshttps://enmilocalfunciona.io/despliega-tus-aplicaciones-en-kubernetes-con-helm-iii-crea-tus-propios-charts/
docker-compose ficheros volumes crear replicahttp://pandorafms.org/forum/thread-14469-post-30266.html#pid30266
pandorafms/pandorafms-agent
https://hub.docker.com/r/pandorafms/pandorafms-agent/tags
Minikube: 5 ways IT teams can use ithttps://enterprisersproject.com/article/2019/4/minikube-how-to-use
Kubernetes - Secretshttps://www.tutorialspoint.com/kubernetes/kubernetes_secrets.htm
Kubernetes ConfigMaps and Secrets Part 2https://medium.com/google-cloud/kubernetes-configmaps-and-secrets-68d061f7ab5b
The History of the Projecthttps://helm.sh/docs/community/history/
Use multi-stage builds in Dockerhttps://docs.docker.com/develop/develop-images/multistage-build/
What even is a kubelet?http://kamalmarhubi.com/blog/2015/08/27/what-even-is-a-kubelet/
kubelet - kubernetes.comhttps://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/
Kubernetes ConfigMap: An Introductionhttps://www.bmc.com/blogs/kubernetes-configmap/
Step by step to install Prometheus in Kubernetes Cluster with Helmhttps://www.devopsart.com/2020/06/step-by-step-to-install-prometheus-in.html
Monitoring with Prometheus and Grafana in Kuberneteshttps://medium.com/faun/monitoring-with-prometheus-and-grafana-in-kubernetes-42727866562c
Using Helm in Kubernetes for Percona PMMhttps://www.percona.com/blog/2020/07/23/using-percona-kubernetes-operators-with-percona-monitoring-and-management/
TítuloEnlace