Monitorización de Kubernetes

A partir de la versión 2.2.0, Checkmk es compatible con las siguientes distribuciones y servicios de Kubernetes:

Nuestro objetivo es dar soporte a cada una de las últimas 5 versiones (menores) lanzadas de Kubernetes. Por lo tanto, también damos soporte a versiones de Kubernetes que ya han quedado fuera del ciclo de vida de Kubernetes (Vanilla). Por encima de todo, garantizamos una colaboración fluida con aquellos proveedores de nube que también ofrecen períodos de soporte más largos para sus servicios de Kubernetes. Inmediatamente después del lanzamiento de una nueva versión de Kubernetes, puede pasar un tiempo —dependiendo del alcance de las nuevas funciones y del momento— hasta que también sea totalmente compatible con Checkmk. En cuanto Checkmk pueda funcionar sin problemas con esta nueva versión, lo anunciaremos en un Werk (como el Werk #14584).

Para una introducción a la nueva monitorización de Kubernetes, te recomendamos nuestros dos vídeos: «Monitorización de Kubernetes con Checkmk» y «Detección de problemas y configuración de alertas para clústeres de Kubernetes».

Dado que los clústeres de Kubernetes pueden sufrir cambios importantes rápidamente en cuanto al número y la ubicación de los componentes individuales, te recomendamos crear un sitio independiente para monitorizar tu entorno de Kubernetes. A continuación, puedes conectar este sitio a tu site central como de costumbre mediante la monitorización distribuida.

Checkmk realiza la monitorización de tus clústeres de Kubernetes de dos maneras:

El agente especial de Kubernetes simplemente recupera información básica a través del servidor API de tu clúster. Esto ya permite recuperar los estados de los nodos y los contenedores. La mayor parte de los metadatos de tus pods y despliegues también se obtienen de esta manera.

Sin embargo, para una monitorización completa, todavía falta algo en este punto. Preguntas como cuánta carga genera una implementación concreta en la CPU, o cuánta memoria está utilizando actualmente un DaemonSet, no pueden responderse de esta manera.

Aquí es donde entran en juego nuestro Checkmk Colector de nodo y nuestro Checkmk Colector del clúster. Son una parte indispensable de la monitorización de Kubernetes dentro de Checkmk. Por lo tanto, una parte nada desdeñable de lo que sigue en este artículo trata también sobre su instalación y configuración. Además, el uso de los dashboards de Kubernetes en las ediciones comerciales solo tiene sentido si los Colectores de nodo y del clúster pueden proporcionar datos sobre las cargas para ello.

Al realizar la monitorización de pods y réplicas en tus clústeres de Kubernetes, a veces se producen cambios de estado o retrasos con mucha más frecuencia. Para tenerlo en cuenta, las comprobaciones de ciertos estados de estos objetos solo cambian su estado en Checkmk tras 10 minutos.

La monitorización de Kubernetes en Checkmk se ha reescrito desde cero. El alcance de los datos que se pueden monitorizar ha aumentado considerablemente. Dado que la base técnica de la monitorización de Kubernetes en Checkmk 2.1.0 es fundamentalmente diferente, no es posible transferir ni reescribir datos de monitorización anteriores de tus objetos de Kubernetes.

La instalación de la monitorización de Kubernetes se realiza con la ayuda de la herramienta helm. Helm también es adecuado para usuarios con menos experiencia y estandariza la gestión de las configuraciones. Helm es una especie de administrador de paquetes para Kubernetes. Si aún no utilizas Helm, normalmente puedes obtenerlo desde el administrador de paquetes de tu distribución de Linux o desde el sitio web del proyecto Helm.

Puedes usar Helm para incluir repositorios como fuentes y añadir fácilmente los Charts de Helm que contienen a tu clúster, del mismo modo que los paquetes. En primer lugar, identifica el repositorio. En el siguiente ejemplo, usamos el nombre checkmk-chart para facilitar el acceso al repositorio más adelante. Por supuesto, también puedes usar cualquier otro nombre que prefieras:

Actualizamos nuestros gráficos de Helm cada vez que los nuevos avances en Kubernetes lo requieren. Por lo tanto, vale la pena checkear de vez en cuando si hay nuevas versiones disponibles en el repositorio. Si has nombrado tu copia local de nuestro repositorio checkmk-chart, como en el comando anterior, puedes usar el siguiente comando para mostrar todas las versiones de los gráficos disponibles en el repositorio:

Si hay una versión más reciente disponible, puedes actualizarla con helm repo update.

Como no podemos saber de antemano cómo está estructurado tu clúster de Kubernetes, hemos elegido la variante más segura para el inicio de los Colectores del clúster: Por defecto, no se proporciona ningún puerto al que se pueda acceder de forma remota. Para poder acceder a los Colectores del clúster más adelante, tendrás que adaptar estos ajustes a tu clúster en particular.

Admitimos dos rutas de comunicación por defecto: la consulta a través de Ingress y la consulta a través de NodePort. La configuración de estas variará dependiendo de la variante que admita tu clúster.

Para poder determinar tú mismo ciertos parámetros en todas las configuraciones, debes incluir un archivo de control, el llamado «values.yaml».

Hay dos formas de crear dicho archivo «values.yaml». Puedes extraer el archivo que te proporcionamos en los Charts de Helm y realizar su edición, o simplemente crear tú mismo una versión mínima.

Siempre que quieras distribuir cambios en este archivo en tu clúster, puedes volver a utilizar el comando de instalación de los Chartes de Helm que veremos más adelante en este artículo.

Después de personalizar values.yaml o crear tu propio Helm chart, usa el siguiente comando para instalar todos los componentes necesarios en tu clúster y poder realizar la monitorización en Checkmk:

Dado que este comando no se explica por sí mismo, a continuación te ofrecemos una explicación de las opciones individuales:

Una vez que hayas ejecutado el comando, tu clúster de Kubernetes estará listo para la monitorización con Checkmk. El clúster se encargará ahora de garantizar que los pods necesarios y los contenedores que contienen estén en ejecución y sean accesibles.

Lo mejor es guardar la contraseña (token) de la cuenta de servicio en el almacén de contraseñas de Checkmk. Esta es la opción más segura, ya que te permite separar organizativamente el almacenamiento y el uso de la contraseña. Como alternativa, introduce la contraseña directamente en texto sin formato al crear la regla (ver más abajo). Para obtener información sobre cómo mostrar la contraseña requerida, consulta la salida del Chart de Helm. Añade la contraseña al almacén de contraseñas de Checkmk con Setup > General > Passwords > Add password, por ejemplo, bajo el ID y el título My Kubernetes Token:

Para que Checkmk confíe en la Autoridad de Certificación (CA) de la cuenta de servicio, debes almacenar el certificado CA en Checkmk. La forma de mostrar el certificado necesario también se encuentra en la salida del Chart de Helm. Copia todo lo que hay aquí, incluidas las líneas BEGIN CERTIFICATE y END CERTIFICATE, y añade el certificado en el Menú de configuración, en «Setup > General > Global settings > Site management > Trusted certificate authorities for SSL» (Configurar > Certificados de CA):

Crea un nuevo host en Checkmk como de costumbre y asígnale un nombre, por ejemplo, «mykubernetesclusterhost». Tal y como sugieren el título y el nombre del host, este host se utiliza para recopilar los datos piggyback y también para realizar el mapeo de todos los servicios y métricas a nivel de clúster. Dado que este host solo recibe datos a través del agente especial, asegúrate de configurar la opción «IP address family» en «No IP» en las propiedades del host.

Para garantizar la separación entre los objetos de diferentes clústeres de Kubernetes, puede ser útil crear una carpeta por clúster mediante Setup > Hosts > Add folder, en la que la administración dinámica del host pueda crear automáticamente todos los hosts de un clúster. Sin embargo, crear o usar dicha carpeta es opcional.

A continuación, configura una conexión en las ediciones comerciales para los datos piggyback entrantes: con Setup > Hosts > Dynamic host management > Add connection. Primero introduce un título y luego haz clic en show more en Connection Properties.

A continuación, haz clic en «Add new element» y selecciona la carpeta creada anteriormente en «Create hosts in».

Deja los atributos predeterminados en «Host attributes to set» tal y como están. Estos garantizan que Checkmk solo se limite a los datos piggyback de los hosts creados automáticamente y no intente hacerles ping ni contactarlos vía SNMP, por ejemplo.

En un entorno de Kubernetes, donde los objetos monitorizables y monitorizados van y vienen continuamente, también se recomienda activar la opción «Automatically delete hosts without piggyback data». Qué hace exactamente esta opción y en qué circunstancias se eliminan realmente los hosts se explica en el capítulo «Eliminación automática de hosts» del artículo sobre administración dinámica del host.

Ahora introduce el host piggyback creado anteriormente en «Restrict source hosts» y activa la opción «Discover services during creation».

La sección «Connection Properties» de esta nueva conexión podría tener este aspecto:

En Checkmk Community tendrás que crear manualmente los hosts para los datos piggyback acumulados. Dado que es probable que surja un gran número de hosts piggyback aquí en un clúster de Kubernetes, te recomendamos usar el comando «cmk-piggyback list orphans».

Por defecto, Checkmk realiza un descubrimiento de servicios cada dos horas y muestra el resultado de este descubrimiento en el servicio «Check_MK Discovery». Puedes encontrar esta configuración en el conjunto de reglas «Periodic service discovery». En el contexto de Kubernetes, te recomendamos crear una regla para todos los hosts con la etiqueta «cmk/kubernetes:yes». Checkmk asigna automáticamente esta etiqueta a todos los hosts que representan objetos de Kubernetes. Aquí debes seleccionar un intervalo más corto para el descubrimiento de servicios y activar también la opción «Automatically update service configuration». La configuración de la siguiente captura de pantalla es solo un ejemplo. Tendrás que decidir qué es lo más adecuado para tus clústeres en cada caso concreto.

Para restringir esta regla a todos los hosts de tu clúster, basta con introducir cmk/kubernetes:yes en el campo «Conditions» (Label de host) en «Host labels» (Configuración de reglas). Sin embargo, si quieres crear reglas individuales para varios clústeres, simplemente utiliza aquí la etiqueta específica de cada clúster. Estas etiquetas siempre tienen el formato cmk/kubernetes/cluster:mycluster.

Ahora que ya se han creado todos los requisitos previos en el clúster y en Checkmk, puedes centrarte en la configuración del agente especial. Puedes encontrarlo en Setup > Agents > VM, cloud, container > Kubernetes. Crea una nueva regla con Add rule.

En primer lugar, debes asignar un nombre al clúster que se va a realizar la monitorización. Puedes elegir este nombre libremente. Se utiliza para dar un nombre único a todos los objetos que provienen de este clúster en particular. Por ejemplo, si introduces aquí mycluster, los nombres de los hosts de todos los pods de este clúster comenzarán más adelante por pod_mycluster. La siguiente parte del nombre del host será siempre el namespace en el que existe este objeto de Kubernetes. El nombre del host de un pod podría ser, por ejemplo, pod_mycluster_kube-system_svclb-traefik-8bgw7.

En Token, selecciona ahora la entrada creada anteriormente en el almacén de contraseñas de Checkmk.

En API server connection > Endpoint, Checkmk te pedirá ahora que introduzcas la URL (o dirección IP) a través de la cual se puede acceder a tu servidor API de Kubernetes. Solo tienes que introducir el puerto si el servicio no se proporciona a través de un host virtual. La forma más fácil de averiguar esta dirección —si aún no la tienes a mano— dependerá de tu entorno de Kubernetes. El siguiente comando te dará el endpoint del servidor API en la línea «server»:

Sin embargo, la salida real de kubectl config view varía mucho. Si aquí también se especifica un puerto en la línea server, asegúrate de incluirlo también en la regla.

Si hasta ahora has seguido estas instrucciones paso a paso y has depositado el certificado CA de tu clúster —tal y como se ha descrito anteriormente— en Checkmk, selecciona en «SSL certificate verification» la entrada «Verify the certificate».

A continuación, tienes la oportunidad de enriquecer la monitorización de tu clúster de Kubernetes con datos de uso recopilados por el Checkmk Colector del clúster. Lo repetimos una vez más aquí para enfatizar su importancia: la configuración del Colector del clúster es absolutamente esencial para una monitorización totalmente completa de tus clústeres. Esta es la única forma de obtener datos importantes, como la carga de la CPU y la memoria, y de recibir información sobre los sistemas de archivos utilizados por los componentes individuales.

Así que activa la opción «Enrich with usage data from Checkmk Cluster Collector» y especifica el endpoint del NodePort o Ingress. En la salida del Chart de Helm se indica cómo volver a mostrar este endpoint.

Con las opciones de «Collect information about…​», ahora puedes seleccionar qué objetos de tu clúster se van a realizar la monitorización. Nuestra preselección cubre los objetos más relevantes. Si decides realizar la monitorización también del «Pods of CronJobs», consulta la ayuda en línea sobre este punto.

Con las dos opciones siguientes, puedes limitar aún más los objetos que se van a someter a monitorización. Si solo te interesan los objetos de determinados espacios de nombres, configúralo en consecuencia en «Monitor namespaces». Aquí puedes introducir espacios de nombres individuales que se vayan a someter a monitorización o excluir explícitamente espacios de nombres individuales de la monitorización.

Con la opción «Cluster resource aggregation», puedes especificar los nodos que no proporcionan recursos para la carga de trabajo de tu clúster. Estos nodos deben excluirse del cálculo de los recursos disponibles; de lo contrario, existe el riesgo de que no se detecten los cuellos de botella de capacidad. Por defecto, excluimos de la evaluación los nodos control-plane y infra.

Como última opción, puedes importar las llamadas anotaciones de Kubernetes. En Checkmk, estas anotaciones se convierten en host labels y, por lo tanto, pueden utilizarse como condiciones en las reglas. Puedes especificar qué anotaciones se deben importar utilizando expresiones regulares. Una vez más, consulta la ayuda en línea en este punto.

Nota: La opción Import all valid annotations se incluye aquí solo para completar la información. No recomendamos importar ciegamente todas las anotaciones, ya que esto puede generar una gran cantidad de etiquetas inútiles en Checkmk.

Importante: En «Conditions > Explicit hosts» debes introducir ahora el host creado anteriormente:

A continuación, guarda la regla y realiza un descubrimiento de servicios en este host. Verás inmediatamente aquí los primeros servicios a nivel de clúster:

Ahora activa todos los cambios que has realizado y deja que la administración dinámica del host haga el trabajo por ti. Esto creará todos los hosts para tus objetos de Kubernetes en muy poco tiempo.

Las ediciones comerciales de Checkmk vienen con seis dashboards integrados para Kubernetes. Para poder usar estos dashboards de forma práctica, es necesario instalar y configurar nuestro Colector del clúster. En concreto, estos seis dashboards se llaman:

El punto de entrada es siempre el dashboard de Kubernetes, al que puedes acceder a través de Monitor > Applications > Kubernetes:

En el panel de control de Kubernetes, todos tus clústeres de Kubernetes que están en proceso de monitorización aparecerán en la parte izquierda. Esta lista de clústeres es también tu punto de entrada para profundizar en los dashboards de Kubernetes. Al hacer clic en el nombre de un clúster, accederás al dashboard de Kubernetes Cluster del clúster seleccionado. En el dashboard de Kubernetes Cluster, al hacer clic en el nombre correspondiente, accederás a los demás dashboards dependientes del contexto:

La monitorización de Kubernetes de Checkmk también admite el inventario de HW/SW. Por ejemplo, si haces clic en el nombre principal del clúster (aquí: mycluster) en el dashboard del clúster anterior, pasarás al inventario del clúster.

De la misma manera, es decir, a través de las cajas con los nombres principales de los objetos, también accederás al inventario del objeto correspondiente en los demás dashboards. El siguiente ejemplo muestra el inventario de HW/SW de un pod: