 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introducción
Kubernetes es desde hace tiempo la herramienta más utilizada para la orquestación de contenedores. Checkmk te ayuda en la monitorización de tus entornos Kubernetes.
A partir de Checkmk 2.1.0, puedes utilizar Checkmk para monitorizar los siguientes objetos de Kubernetes:
Clústeres
Nodos
Distribuciones
Pods
DaemonSets
StatefulSets
Reclamaciones de Volumen Persistentes
CronJobs (a partir de la versión 2.2.0)
Para obtener una lista completa de todos los check plugin disponibles para la monitorización de Kubernetes, consulta nuestro Catálogo de check plugin.
1.1. Distribuciones y versiones compatibles
A partir de la versión 2.2.0, Checkmk es compatible con las siguientes distribuciones y servicios de Kubernetes:
Vanilla Kubernetes
Servicio Amazon Elastic Kubernetes (Amazon EKS)
Servicio Azure Kubernetes (AKS)
Google Kubernetes Engine (GKE) incl. modo Piloto Automático
Tanzu Kubernetes (a partir de Checkmk 2.2.0p9)
Nuestro objetivo es dar soporte a cada una de las 5 últimas versiones (menores) publicadas de Kubernetes. Por tanto, también damos soporte a versiones de Kubernetes que ya han quedado fuera del ciclo de vida (Vanilla) de Kubernetes. Sobre todo, garantizamos una cooperación fluida con los proveedores de la nube que también ofrecen periodos de soporte más largos para sus servicios 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 calendario- hasta que también sea totalmente compatible con Checkmk. Tan pronto como Checkmk pueda funcionar sin problemas con esta nueva versión, lo anunciaremos en un Werk (como el Werk #14584).
1.2. Introducción a la monitorización de Kubernetes
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 Kubernetes.
1.3. Estructura del entorno de monitorización
Dado que los clústeres Kubernetes pueden sufrir rápidamente cambios importantes en cuanto al número y la ubicación de los componentes individuales, te recomendamos que crees un site independiente para monitorizar tu entorno Kubernetes. A continuación, puedes conectar este site a tu site central como de costumbre mediante la monitorización distribuida.
1.4. El proceso de monitorización de Kubernetes en Checkmk
Checkmk monitoriza tus clústeres Kubernetes de dos formas:
El agente especial de Kubernetes simplemente recupera información básica a través del servidor API de tu clúster, que ya puede utilizarse para recuperar los estados de nodos y contenedores. La mayoría de los metadatos de tus pods y distribuciones también se obtienen de esta forma.
Sin embargo, para una monitorización exhaustiva, todavía falta algo: preguntas como cuánta carga genera un despliegue concreto en la CPU, o cuánta memoria está utilizando actualmente un DaemonSet, no pueden responderse de este modo.
Aquí es donde entran en juego nuestro Colector del nodo Checkmk y nuestro Colector del clúster Checkmk, que son una parte indispensable de la monitorización de Kubernetes dentro de Checkmk. Por tanto, una parte no despreciable de lo que sigue en este artículo trata también de su instalación y configuración. Además, el uso de los dashboards de Kubernetes en las ediciones comerciales sólo tiene sentido si los Colectores del nodo y del clúster pueden proporcionar datos sobre las cargas para ello.
1.5. Diferencias respecto a otras monitorizaciones en Checkmk
Al monitorizar pods y replica en tus clústeres Kubernetes, los cambios de estado o retrasos se producen a veces con mucha más frecuencia. Para tenerlo en cuenta, los checks de determinados estados de estos objetos sólo cambian de estado en Checkmk al cabo de 10 minutos.
1.6. Diferencias respecto a la monitorización de Kubernetes existente
La monitorización de Kubernetes en Checkmk se ha reescrito desde cero. El alcance de los datos que se pueden monitorizar ha crecido 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 o incluso reescribir los datos de monitorización anteriores de tus objetos Kubernetes.
2. Crear requisitos previos en el clúster
Para poder monitorizar tu clúster Kubernetes en Checkmk, crea primero los requisitos previos en tu clúster. Ante todo, indícale qué pods/contenedores distribuir y cómo configurarlos.
2.1. Configuración del repositorio Helm
La instalación de la monitorización de Kubernetes se realiza con la ayuda de la herramienta helm. Helm también es adecuada para usuarios menos experimentados 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 conseguirlo en el administrador de paquetes de tu distribución de Linux o en el sitio web del proyecto Helm.
Puedes utilizar Helm para incluir repositorios como fuentes y añadir fácilmente a tu clúster los Chart de Helm que contienen, del mismo modo que los paquetes. En primer lugar, identifica el repositorio. En el siguiente ejemplo, utilizamos el nombre checkmk-chart para facilitar el acceso posterior al repositorio. Por supuesto, también puedes utilizar cualquier otro nombre de tu elección:
user@host:~$ helm repo add checkmk-chart https://checkmk.github.io/checkmk_kube_agentActualizamos nuestros gráficos de Helm siempre que los nuevos desarrollos en Kubernetes lo requieren, por lo que merece la pena comprobar de vez en cuando si hay nuevas versiones disponibles en el repositorio. Si has llamado a tu copia local de nuestro repositorio checkmk-chart, como en el comando anterior, puedes utilizar el siguiente comando para mostrar todas las versiones de los gráficos disponibles en el repositorio:
user@host:~$ helm search repo checkmk-chart --versions
NAME CHART VERSION APP VERSION DESCRIPTION
checkmk-chart/checkmk 1.2.0 1.2.0 Helm chart for Checkmk - Your complete IT monit...
checkmk-chart/checkmk 1.1.0 1.1.0 Helm chart for Checkmk - Your complete IT monit...
checkmk-chart/checkmk 1.0.1 1.0.1 Helm chart for Checkmk - Your complete IT monit...
checkmk-chart/checkmk 1.0.0 1.0.0 Helm chart for Checkmk - Your complete IT monit...Si hay disponible una versión más reciente, puedes actualizarla con helm repo update.
2.2. Adaptar la configuración a tu entorno
Puesto que no podemos saber de antemano cómo está estructurado tu clúster Kubernetes, hemos elegido la variante más segura para el inicio de los Colectores del clúster: Por defecto, no proporciona ningún puerto al que se pueda acceder de forma remota. Para poder acceder a los colectores más adelante, tendrás que adaptar esta configuración a tu clúster particular.
Por defecto, admitimos dos rutas de comunicación: la consulta a través de Ingress y la consulta a través de NodePort, cuya configuración variará en función de la variante que admitas en tu clúster.
Para poder determinar tú mismo ciertos parámetros en todas las configuraciones, incluye un archivo de control, el llamado values.yaml.
Hay dos formas de crear un values.yaml de este tipo. Puedes extraer el archivo que te proporcionamos en las cartas de Helm y editarlo, 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 Chart de Helm que veremos más adelante en este artículo.
Crear tu propio values.yaml básico
Puedes crear un values.yaml en el que sólo introduzcas los valores que quieras modificar. En nuestro Chart de Helm, por ejemplo, el tipo de servicio del Colector del clúster está establecido por defecto en ClusterIP. Si ahora sólo quieres cambiar este tipo de servicio a NodePort y el puerto a 30035, basta con crear un values.yaml como el siguiente:
user@host:~$ echo 'clusterCollector: {service: {type: NodePort, nodePort: 30035}}' > values.yamlUna activación de Ingress podría tener este aspecto:
user@host:~$ echo 'clusterCollector: {ingress: { enabled: true }}' > values.yamlExtraer values.yaml de los Chart de Helm
El values.yaml completo que te hemos proporcionado se puede extraer fácilmente con el siguiente comando:
user@host:~$ helm show values checkmk-chart/checkmk > values.yamlAhora puedes adaptar el archivo creado de este modo a tus necesidades y pasarlo a helm con el parámetro -f values.yaml durante la instalación, o durante una actualización posterior.
Proporcionar comunicación a través de Ingress
Si utilizas Ingress para controlar el acceso a tus servicios, edita en consecuencia las partes ya preparadas en values.yaml. Para una mejor visión de conjunto, en el siguiente ejemplo abreviado sólo se muestra la parte relevante. Establece el parámetro enabled en true. Adapta el resto de parámetros en función de tu entorno:
ingress:
enabled: true
className: ""
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
hosts:
- host: checkmk-cluster-collector.local
paths:
- path: /
pathType: Prefix
tls: []
# - secretName: chart-example-tls
# hosts:
# - chart-example.localProporcionar comunicación a través de NodePort
También puedes proporcionar acceso a los servicios directamente a través de un puerto. Esto es necesario si no utilizas Ingress. En el siguiente ejemplo, sólo se muestra la sección relevante. Estableces el valor type en NodePort y eliminas el comentario para el valor nodePort:
service:
# if required specify "NodePort" here to expose the cluster-collector via the "nodePort" specified below
type: NodePort
port: 8080
nodePort: 30035Configurar el Colector del clúster para HTTPS
Si quieres cambiar la comunicación con y entre los Colectores del clúster a HTTPS, también debes hacer cambios en el archivo values.yaml.
A continuación se muestra la sección de nuestro values.yaml suministrado que debes editar para habilitar HTTPS:
tlsCommunication:
enabled: false
verifySsl: false
# clusterCollectorKey: |-
# -----BEGIN EC PRIVATE KEY-----
# XYZ
# -----END EC PRIVATE KEY-----
# clusterCollectorCert: |-
# -----BEGIN CERTIFICATE-----
# XYZ
# -----END CERTIFICATE-----
# checkmkCaCert: |-
# -----BEGIN CERTIFICATE-----
# XYZ
# -----END CERTIFICATE-----En las líneas que comienzan con enabled o verifySsl, debes sustituir false por true. A continuación, elimina las marcas de hash que aparecen antes de las tres secciones clusterCollectorKey, clusterCollectorCert y checkmkCaCert e inserta los datos correspondientes a continuación de éstas. Tu organización debe determinar si desea utilizar certificados autofirmados u obtener certificados de una Autoridad de Certificación (CA).
Ten en cuenta que los certificados deben cumplir los siguientes requisitos:
El certificado de la CA debe contener el nombre del host o el nombre del Ingress como FQDN.
Para el certificado del servidor, el FQDN debe corresponderse con el siguiente patrón:
<service_name>.<namespace>.cluster.local.En la sección
[ v3_ext ]del archivo de configuración para generar tu solicitud de firma de certificado, elsubjectAltNamedebe coincidir con el siguiente patrón:subjectAltName: DNS:<service_name>.<namespace>.cluster.local, IP:<service ip>
Utilizar tu propia cuenta de servicio
Utilizando nuestros Chart de Helm, se crearía por defecto una cuenta de servicio en tu clúster. Si ya tienes una cuenta de servicio adecuada, basta con añadirla en values.yaml y suprimir la creación de una nueva cuenta.
serviceAccount:
create: false
name: "myserviceaccount"Requisitos previos para la monitorización del Piloto Automático de GKE
Si operas tu clúster GKE (Google Kubernetes Engine) en modo Piloto Automático, también es posible su monitorización con Checkmk, ya que Checkmk es un socio del llamado Piloto Automático.
Sólo tienes que establecer var_run en readOnly en tu archivo values.yaml:
volumeMountPermissions:
var_run:
readOnly: trueConfigura el controlador de admisión Pod Security
Si utilizas Estándares de Seguridad Pod en tu clúster, debes configurar el Colector del clúster Checkmk para que tenga acceso sin restricciones en el namespace correspondiente. Lo ideal es crear un namespace con la siguiente especificación:
apiVersion: v1
kind: Namespace
metadata:
name: checkmk-monitoring
labels:
pod-security.kubernetes.io/enforce: privileged
pod-security.kubernetes.io/enforce-version: latestPuedes crear el namespace ejecutando, por ejemplo, kubectl apply -f namespace.yaml. Ten en cuenta que entonces no necesitarás utilizar la opción --create-namespace cuando ejecutes posteriormente el comando helm upgrade.
Si el Colector del clúster ya se está ejecutando o el namespace ya existe, también puedes establecer las etiquetas anteriores con el siguiente comando:
user@host:~$ kubectl label --overwrite ns checkmk-monitoring pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/enforce-version=latestPolíticas de seguridad de pods y políticas de red
Las políticas PodSecurityPolicy (abreviado PSP) y NetworkPolicy se incluyen en nuestro Chart de Helm principalmente por motivos de compatibilidad. Dado que las PSP se han eliminado por completo de Kubernetes a partir de v1.25, las hemos desactivado por defecto a partir de la versión 1.3.0 de nuestro Chart de Helm.
La sección correspondiente tiene ahora este aspecto:
rbac:
pspEnabled: falseSi aún utilizas el PSP en tu clúster, es necesario que configures esta opción en true en la página values.yaml:
rbac:
pspEnabled: trueSi más adelante descubrimos que esta entrada no se procesa correctamente aunque esté desactivada, la eliminaremos por completo.
Lo mismo se aplica a la NetworkPolicy. Si la utilizas en tu clúster, tendrás que cambiar la ubicación en values.yaml de enabled: false a enabled: true. En esta situación, consulta la siguiente documentación dentro de values.yaml para configurar correctamente la NetworkPolicy.
## ref: https://kubernetes.io/docs/concepts/services-networking/network-policies/
networkPolicy:
# keep in mind: your cluster network plugin has to support NetworkPolicies, otherwise they won't have any effect
enabled: false
# specify ipBlock cidrs here to allow ingress to the cluster-collector
# this is required for the checkmk servers to be able to scrape data from checkmk, so include the resprective ip range(s) here
allowIngressFromCIDRs: []
# - 127.0.0.1/32 # e.g. Checkmk Server
# - 127.0.0.1/24 # e.g. Metallb speakers
# the cluster-collector needs to be able to contact the kube-apiserver
# you have three options here to choose from, depending on your cluster setup:
# 1) if your apiserver resides outside the cluster, resp. you have a kubernetes endpoint available (check via "kubectl -n default get ep kubernetes")
# we can make use of helm lookup to automatically inject the endpoint (cidr + port) here.
# This is the most comfortable one, just note that helm lookup won't work on a "helm template" or "helm diff" command.
# (see also: https://helm.sh/docs/chart_template_guide/functions_and_pipelines/#using-the-lookup-function)
# 2) similar to 1) you can also specify the "ipBlockCidr" directly. Make sure to disable "enableCidrLookup", and also fill the "port".
# 3) if the apiserver resides inside the cluster, disable "enableCidrLookup", unset "ipBlockCidr", and fill the "labelSelectors" section
# with the name of the namespace where the kube-apiserver is availabe, and the label key and label value that defines your kube-apiserver pod.
egressKubeApiserver:
enableCidrLookup: true
# ipBlockCidr: 172.31.0.3/32
# port: 6443
# labelSelectors:
# namespace: kube-system
# key: app
# value: kube-apiserver2.3. Instalación de Chart de Helm
Tras personalizar values.yaml o crear los tuyos propios, utiliza el siguiente comando para instalar todos los componentes necesarios en tu clúster para poder monitorizarlo en Checkmk:
user@host:~$ helm upgrade --install --create-namespace -n checkmk-monitoring myrelease checkmk-chart/checkmk -f values.yamlComo este comando no se explica por sí mismo, a continuación te ofrecemos una explicación de cada una de las opciones:
| Elemento del comando | Descripción |
|---|---|
|
Esta parte es el comando básico para enviar la configuración al clúster Kubernetes. |
|
En Kubernetes, siempre se especifica a qué namespace debe añadirse la configuración. Necesitas esta opción si el namespace aún no existe. Helm lo creará en este caso. |
|
Esta opción especifica el namespace al que debe añadirse la configuración. |
|
Aquí, |
|
La primera parte de esta opción describe el repositorio que has creado previamente. La segunda parte -después de la barra- es el paquete que contiene la información necesaria para crear la configuración para tu monitorización de Kubernetes. |
|
Por último, introduce el archivo de configuración que creaste o adaptaste anteriormente. Contiene todas las personalizaciones que se incluirán en los archivos de configuración creados con |
Una vez que hayas ejecutado el comando, tu clúster de Kubernetes estará preparado para la monitorización con Checkmk. El clúster se encargará ahora de garantizar que los pods necesarios y los contenedores que contienen se están ejecutando y son accesibles.
Salida del Chart de Helm
Lo siguiente que hay que hacer es configurarlo en Checkmk. Para que esta configuración sea lo más sencilla posible, hemos dotado a la salida de nuestros gráficos de Helm de toda una serie de comandos. Esta salida también se ajusta automáticamente a los valores que hayas especificado en el archivo values.yaml. Si utilizas el NodePort, obtendrás los comandos para mostrar la IP y el puerto del NodePort, entre otras cosas. Si, en cambio, utilizas Ingress, la salida se adaptará en consecuencia. A continuación mostramos la salida -ligeramente abreviada- tras una instalación correcta cuando se utiliza el NodePort:
user@host:~$ helm upgrade --install --create-namespace -n checkmk-monitoring myrelease checkmk-chart/checkmk -f values.yaml Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Sat Dec 16 19:00:11 2022 NAMESPACE: checkmk-monitoring STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: You can access the checkmkmyrelease-checkmk-cluster-collector. checkmk-monitoringCon el token de la cuenta de servicio denominadacluster-collectorvia: NodePort: export NODE_PORT=$(kubectl get --namespace checkmk-monitoring -o jsonpath="{.spec.ports[0].nodePort}" services myrelease-checkmk-cluster-collector); export NODE_IP=$(kubectl get nodes --namespace checkmk-monitoring -o jsonpath="{.items[0].status.addresses[0].address}"); echo http://$NODE_IP:$NODE_PORT # Cluster-internal DNS ofcluster-collectormyrelease-checkmk-checkmken el namespacecheckmk-monitoring, ya puedes realizar consultas encluster-collector.Ejecuta lo siguiente para obtener su token y el certificado ca del clúster: export TOKEN=$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitoring -o=jsonpath='{.data.token}' | base64 --decode); export CA_CRT="$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitorización -o=jsonpath='{.data.ca\.crt}' | base64 --decode)"; # Nota: Cita la variable cuando echo'ing a preservar adecuada línea saltos:echo "$CA_CRT"Para comprobar el acceso puedes ejecutar: curl -H "Autorización: Bearer $TOKEN" http://$NODE_IP:$NODE_PORT/metadata | jq
A partir de esta salida, simplemente copia las líneas de color y ejecuta los comandos.
El primer bloque te muestra información sobre el PuertoNodo:
user@host:~$ export NODE_PORT=$(kubectl get --namespace checkmk-monitoring -o jsonpath="{.spec.ports[0].nodePort}" services myrelease-checkmk-cluster-collector);
user@host:~$ export NODE_IP=$(kubectl get nodes --namespace checkmk-monitoring -o jsonpath="{.items[0].status.addresses[0].address}");
user@host:~$ echo http://$NODE_IP:$NODE_PORT
http://10.184.38.103:30035Ésta es exactamente la dirección que tienes que introducir en Checkmk más adelante en la regla de Kubernetes, en el campo Collector NodePort / Ingress endpoint.
Con los comandos del siguiente bloque obtienes tanto el token como el certificado de la cuenta de servicio. Así, los datos se almacenan en las variables del entorno TOKEN y CA_CRT. Cuando emitas la variable CA_CRT, asegúrate de encerrarla entre comillas, pues de lo contrario se perderán los saltos de línea importantes del certificado.
user@host:~$ export TOKEN=$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitoring -o=jsonpath='{.data.token}' | base64 --decode);
user@host:~$ export CA_CRT="$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitoring -o=jsonpath='{.data.ca\.crt}' | base64 --decode)";
user@host:~$ echo $TOKEN
eyJhbGciOiJSUzI1NiIsImtpZCI6InR6VXhGSU ...
user@host:~$ echo "$CA_CRT"
-----BEGIN CERTIFICATE-----
MIIBdjCCAR2gAwIBAgIBADAKBggqhkjOPQQDAjAjMSEwHwYDVQQDDBhrM3Mtc2Vy
dmVyLWNhQDE2NjIxNDc5NTMwHhcNMjIwOTAyMTk0NTUzWhcNMzIwODMwMTk0NTUz
...
-----END CERTIFICATE-----Cuando realices la configuración en Checkmk, debes almacenar tanto el testigo como el certificado. Deja el intérprete de comandos abierto con esta información o copia el testigo y el certificado en una ubicación a la que puedas acceder durante la siguiente configuración en Checkmk.
Si has ejecutado los dos comandos de exportación anteriores, puedes utilizar el último comando para verificar que la configuración se ha realizado correctamente:
curl -H "Authorization: Bearer $TOKEN" http://$NODE_IP:$NODE_PORT/metadata | jq
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1815 100 1815 0 0 126k 0 --:--:-- --:--:-- --:--:-- 126k
{
"cluster_collector_metadata": {
"node": "mynode",
"host_name": "myrelease-checkmk-cluster-collector-58f97df9c9-mdhsw",
"container_platform": {
"os_name": "alpine",
"os_version": "3.15.4",
"python_version": "3.10.4",
"python_compiler": "GCC 10.3.1 20211027"
},
"checkmk_kube_agent": {
"project_version": "1.0.1"
}
}
...Al principio de la salida muy abreviada, por ejemplo, puedes ver la versión del Colector del clúster. Más abajo, aparecerían los metadatos de todos los nodos de este clúster.
3. Configuración de la monitorización en Checkmk
A continuación, en la GUI de Checkmk, pasamos a configurar el agente especial y una regla para crear automáticamente hosts para tus objetos Kubernetes. Sin embargo, para configurar el agente especial, primero hay que cumplir algunos requisitos previos:
3.1. Almacenar la contraseña (token) en Checkmk
Lo mejor es almacenar la contraseña (token) de la cuenta de servicio en el almacén de contraseñas de Checkmk. Ésta es la opción más segura, ya que puedes separar organizacionalmente 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). 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:
3.2. Importar el certificado CA de una cuenta de servicio a Checkmk.
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 está en la salida del Chart de Helm. Copia todo 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:
3.3. Crear un host de origen Piggyback
Crea un nuevo host en Checkmk de la forma habitual y llámalo, por ejemplo, mykubernetesclusterhost. Como sugieren el título y el nombre del host, este host se utiliza para recopilar los datos piggyback y también para mapear todos los servicios y métricas a nivel de clúster. Como este host sólo 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.
3.4. Establecer la configuración dinámica del host
Para garantizar la separación entre los objetos de distintos clústeres de Kubernetes, puede ser útil crear una carpeta por clúster a través de Setup > Hosts > Add folder, en la que la configuración dinámica del host pueda crear automáticamente todos los hosts de un clúster. Sin embargo, la creación o utilización de dicha carpeta es opcional.
A continuación, configura un conector 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 previamente en Create hosts in.
Deja los atributos predeterminados en Host attributes to set tal como están. Garantizan que Checkmk sólo se adhiera a los datos piggyback de los host creados automáticamente y no intente hacer ping ni llegar a ellos a través de SNMP, por ejemplo.
En un entorno Kubernetes en el que los objetos monitorizables y monitorizados van y vienen continuamente, también se recomienda activar la opción Automatically delete hosts without piggyback data. Lo que 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 configuración dinámica de hosts.
Ahora entra en el host de origen Piggyback creado anteriormente en Restrict source hosts y activa la opción Discover services during creation.
La sección Connection Properties de este nuevo conector podría tener el siguiente aspecto:
3.5. Procesar datos piggyback en Checkmk Raw
En Checkmk Raw 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 en un clúster Kubernetes, te recomendamos que utilices nuestro script find_piggy_orphans script en el directorio ~/share/doc/check_mk/treasures/ de tu site Checkmk.
3.6. Personalizar el descubrimiento periódico de servicios
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, recomendamos crear una regla para todos los hosts con la etiqueta cmk/kubernetes:yes.
Checkmk asigna automáticamente esta etiqueta a todos los host que representan objetos Kubernetes. Deberías seleccionar aquí un intervalo más corto para el descubrimiento de servicios, y activar también la opción Automatically update service configuration. Los ajustes de la siguiente captura de pantalla son sólo ejemplos. Tendrás que decidir qué tiene sentido para tus clusters caso por caso.
Para restringir esta regla a todos los host de tu clúster, basta con introducir cmk/kubernetes:yes en Conditions bajo Host labels. Sin embargo, si quieres crear reglas individuales para varios clústeres, simplemente utiliza aquí la etiqueta específica del clúster correspondiente. Estas etiquetas siempre tienen la forma cmk/kubernetes/cluster:mycluster.
3.7. Configurar el agente especial
Ahora que se han creado todos los requisitos previos en el clúster y en Checkmk, puedes dirigir tu atención a la configuración del agente especial. Puedes encontrarlo a través de 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 monitorizar. Puedes elegir este nombre libremente. Se utiliza para dar un nombre único a todos los objetos que procedan de este clúster concreto. Por ejemplo, si introduces aquí mycluster, los nombres de los hosts de todos los pods de este clúster empezarán después por pod_mycluster. La siguiente parte del nombre del host será siempre el namespace en el que existe este objeto Kubernetes. El nombre del host de un pod podría ser entonces pod_mycluster_kube-system_svclb-traefik-8bgw7, por ejemplo.
En Token, selecciona ahora la entrada creada anteriormente en el almacén de contraseñas de Checkmk.
En API server connection > Endpoint, Checkmk te pide ahora que introduzcas la URL (o dirección IP) a través de la cual se puede acceder a tu servidor API de Kubernetes. Sólo tendrás que introducir el puerto si el servicio no se presta a través de un host virtual. La forma más sencilla de averiguar esta dirección -si no la tienes ya a mano- dependerá de tu entorno Kubernetes. El siguiente comando te dará el endpoint del servidor API en la línea server:
user@host:~$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://DFE7A4191DCEC150F63F9DE2ECA1B407.mi6.eu-central-1.eks.amazonaws.com
name: xyz:aws:eks:eu-central-1:150143619628:cluster/my-kubernetesSin 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-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 Kubernetes con los datos de uso recogidos por el Colector del clúster de Checkmk. Lo repetimos una vez más aquí para subrayar su importancia:la configuración del Colector del clúster es absolutamente esencial para una monitorización completa de tus clústeres.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.
Para ello, activa la opción Enrich with usage data from Checkmk Cluster Collector y especifica el endpoint del NodePort o Ingress. La forma de volver a mostrar este endpoint es en la salida del Chart de Helm.
Con las opciones Collect information about…, ahora puedes seleccionar qué objetos de tu clúster se van a monitorizar. Nuestra preselección cubre los objetos más relevantes. Si decides monitorizar también el 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 a monitorizar. Si sólo te interesan los objetos de determinados namespaces, configúralo en Monitor namespaces. Aquí puedes introducir namespaces individuales a monitorizar o excluir explícitamente de la monitorización namespaces individuales.
Con la opción Cluster resource aggregation, puedes especificar nodos que no proporcionen recursos para la carga de trabajo de tu clúster. Estos nodos deben excluirse del cálculo de los recursos disponibles, ya que de lo contrario existe el riesgo de que no se detecten los cuellos de botella de capacidad. Por tanto, por defecto, excluimos de la evaluación los nodos control-plane y infra.
Como última opción, puedes importar las denominadas anotaciones de Kubernetes. En Checkmk, estas anotaciones se convierten en host label y, por tanto, pueden utilizarse como condiciones en las reglas. Puedes especificar qué anotaciones deben importarse utilizando expresiones regulares. De nuevo, consulta la ayuda en línea detallada en este punto.
Nota: La opción Import all valid annotations se proporciona aquí sólo para completar la información. No recomendamos importar a ciegas todas las anotaciones, ya que esto puede crear una montaña muy grande 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. Inmediatamente verás aquí los primeros servicios a nivel de clúster:
Activa ahora todos los cambios que has realizado y deja que la configuración dinámica del host haga el trabajo por ti. Esto creará todos los hosts para tus objetos Kubernetes en un breve espacio de tiempo.
4. Etiquetas para objetos Kubernetes
Checkmk genera automáticamente etiquetas para objetos Kubernetes como clústeres, despliegues o namespaces durante un descubrimiento de servicios. Todas las etiquetas para objetos Kubernetes que Checkmk genera automáticamente empiezan por cmk/kubernetes/. Por ejemplo, un pod siempre recibe una etiqueta para el nodo (cmk/kubernetes/node:mynode), una etiqueta que muestra que este objeto es un pod (cmk/kubernetes/object:pod) y una etiqueta para el namespace (cmk/kubernetes/namespace:mynamespace). Esto facilita mucho la creación de filtros y reglas para todos los objetos del mismo tipo o en el mismo namespace.
5. Dashboards y vistas
5.1. Dashboards de Kubernetes
Las ediciones comerciales de Checkmk se suministran con seis dashboards integrados para Kubernetes. Para utilizar estos dashboards de forma práctica, es necesario instalar y configurar nuestro Colector del clúster. En concreto, estos seis dashboards se denominan:
Kubernetes
Clúster Kubernetes
DaemonSet de Kubernetes
Despliegue de Kubernetes
Kubernetes Namespace
Kubernetes StatefulSet
El punto de entrada es siempre el dashboard Kubernetes, al que puedes acceder a través de Monitor > Applications > Kubernetes:
En el dashboard Kubernetes, todos tus clústeres Kubernetes en monitorización aparecerán listados en la parte izquierda. Este listado de clústeres es también tu punto de entrada para profundizar en los dashboards de Kubernetes. Si haces clic en el nombre de un clúster, accederás al dashboard Kubernetes Cluster del clúster seleccionado. En el dashboard Kubernetes Cluster, si haces clic en el nombre correspondiente, accederás a los demás dashboards dependientes del contexto:
5.2. El inventario de hardware/software
La monitorización de Checkmk Kubernetes 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, saltarás al inventario del clúster.
Del mismo modo, es decir, a través de las cajas con los nombres primarios de los objetos, también llegarás al inventario del objeto correspondiente en los demás dashboards. El siguiente ejemplo muestra el inventario de HW/SW de un pod:
6. Check de la instalación
En la sección de salida del Chart de Helm, ya has aprendido el primer método para comprobar que los componentes para una monitorización completa de Kubernetes se han instalado correctamente. En la GUI de Checkmk también puedes comprobar que la instalación y la configuración se han realizado correctamente en varios lugares.
Los servicios más importantes aquí son, sin duda, Kubernetes API y Cluster Collector. Estos deben estar presentes en el host de clúster que has creado y también deben mostrar cierta información.
El servicio Kubernetes API debe informar normalmente de Live, Ready bajo Summary. El servicio Cluster Collector debe mostrar el número de versión del Colector del clúster instalado. Si no es el caso de uno u otro, debes comprobar la instalación de los gráficos de Helm y la configuración del agente especial.
En los dashboards de clúster de las ediciones comerciales hay más posibilidades de check.
En el dashboard Kubernetes, puedes ver muy pronto si el Colector del clúster se está ejecutando en un clúster y recopilando datos. Si las columnas CPU resources y Memory resources no contienen ningún dato, esto ya es un fuerte indicador de que el Colector del clúster no se está ejecutando correctamente. Si se ha configurado correctamente, el dashboard Kubernetes debería tener un aspecto parecido al siguiente:
Si ahora haces clic en el nombre del clúster en esta ventana, aterrizarás en Kubernetes Cluster en el dashboard del clúster respectivo. Aquí las tres cajas Primary datasource, Cluster collector y API health deberían ser verdes y mostrar OK.
7. Eliminar componentes de monitorización de un clúster
Si has distribuido Checkmk en tu clúster utilizando nuestros diagramas de Helm, puedes eliminar las cuentas, servicios, pods y puertos de nodo creados con la misma facilidad con la que los configuraste. Para ello, sólo tienes que desinstalar la versión que se instaló utilizando nuestros diagramas.
Si no estás seguro del nombre de la versión, muestra primero todas las versiones de Helm en todos los namespace:
user@host:~$ helm list --all-namespaces
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
myrelease checkmk-monitoring 1 2022-08-15 19:00:42.318666784 +0200 CEST deployed checkmk-1.0.1 1.0.1Como en el ejemplo anterior, deberías encontrar una versión que contenga una referencia a Checkmk en la columna CHART.
Elimina esta versión con el siguiente comando, especificando el namespace correcto:
user@host:~$ helm uninstall myrelease -n checkmk-monitoring
release "myrelease" uninstalled