 |
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. Prefacio
Ya existe un artículo independiente sobre la monitorización de K ubernetes en el que se describe la configuración de la monitorización de Kubernetes y sus distintas variantes. Sin embargo, dado que OpenShift en general y su configuración en particular funcionan de forma algo diferente, hemos decidido crear un artículo independiente para describir la configuración de la monitorización de OpenShift y de los clústeres de Kubernetes que se ejecutan en él. En el resto de este artículo, nos referiremos a estos mismos clústeres -por legibilidad y simplicidad- como clústeres OpenShift. La monitorización de los clústeres OpenShift sólo es posible con una de las ediciones comerciales de Checkmk.
2. Introducción
Checkmk te ayuda a monitorizar tus clústeres OpenShift. A partir de la versión 2.3.0, puedes utilizar cualquiera de nuestras ediciones comerciales para monitorizar los siguientes objetos:
Clústeres
Distribuciones
Nodos
Pods
DaemonSets
StatefulSets
CronJobs
Para obtener una lista completa de todos los check plugin disponibles para la monitorización de Kubernetes, consulta nuestro Catálogo de check plugin.
2.1. Configuración del entorno de monitorización
Como los clústeres de OpenShift también pueden sufrir cambios importantes muy rápidamente en cuanto al número y la ubicación de los componentes individuales, recomendamos crear un site Checkmk independiente para monitorizar un entorno de OpenShift. Éste puede conectarse al site central como de costumbre mediante el procedimiento de monitorización distribuida.
2.2. El proceso de monitorización de OpenShift en Checkmk
Checkmk monitoriza tus clústeres de OpenShift de dos formas:
Checkmk obtiene información básica directamente de tu clúster a través de la API de Kubernetes, que ya puede utilizarse para recuperar los estados de nodos y contenedores. La mayoría de los metadatos de tus pods y despliegues también se obtienen de esta forma. Sin embargo, para una monitorización exhaustiva, todavía falta algo. Las preguntas sobre cuánta carga, por ejemplo, está generando un despliegue concreto en la CPU, o cuánta memoria está ocupando actualmente un DaemonSet, no pueden responderse con este método.
Puesto que Prometheus ya está instalado por defecto en los clústeres de OpenShift, Checkmk puede consultar exactamente esta instancia de Prometheus dentro de tu entorno de OpenShift y preparar los datos resultantes para ti de la forma habitual de Checkmk. Para una monitorización totalmente completa de tu entorno de OpenShift, te recomendamos encarecidamente que configures esta conexión. Además, utilizar los dashboards de Kubernetes sólo es útil si se dispone de los datos de carga de trabajo adecuados.
3. Crear requisitos previos en el clúster
Para poder monitorizar el entorno de OpenShift en Checkmk, crea primero los requisitos previos en tu clúster.
3.1. Crear un namespace y una cuenta de servicio
En primer lugar, tienes que configurar un namespace y una cuenta de servicio para Checkmk en tu clúster de OpenShift. La forma más rápida de hacerlo es a través de la CLI de OpenShift (oc para abreviar).
En el siguiente ejemplo, llamaremos a este namespace checkmk-monitoring. Si quieres o necesitas elegir un nombre diferente, también tendrás que hacer este cambio al crear la cuenta de servicio.
user@host:~$ oc create namespace checkmk-monitoring
namespace/checkmk-monitoring createdLa cuenta de servicio con su rol asociado y el denominado RoleBinding puede crearse especificando nuestro archivo YAML ya preparado publicado en GitHub. Comprueba su contenido y, a continuación, ejecuta el siguiente comando:
user@host:~$ oc apply -f https://raw.githubusercontent.com/Checkmk/checkmk_kube_agent/checkmk_docs/deploy/kubernetes/checkmk-serviceaccount.yaml
serviceaccount/checkmk created
clusterrole.rbac.authorization.k8s.io/checkmk-metrics-reader created
clusterrolebinding.rbac.authorization.k8s.io/checkmk-metrics-reader-binding createdAlternativamente, puedes descargar primero este archivo YAML, personalizarlo según tus necesidades y, a continuación, aplicar oc apply -f a esta copia local del archivo.
3.2. Obtener los endpoints de la API, el token y el certificado
Con la herramienta de línea de comandos oc, ahora también puedes leer toda la información de tu clúster, que normalmente tendrás que especificar para configurar el agente especial. Si has cambiado el nombre del servicio o el namespace, debes editar esta información como se describe en los siguientes comandos.
Recuperar el endpoint de la API de Kubernetes
El endpoint de la API de Kubernetes se muestra en oc con el siguiente comando:
user@host:~$ oc cluster-info
Kubernetes control plane is running at https://api.myopenshift.example.com:6443Esta dirección, incluido el puerto especificado, se incluirá posteriormente en el campo API server connection > Endpoint de la regla de Kubernetes.
Recuperar el endpoint de la API Prometheus
Obtener la dirección del endpoint de la API de la instancia de Prometheus en tu clúster puede ser más fácil a través de la GUI de OpenShift. En el rol de administrador, puedes encontrar una lista más o menos larga a través de Networking > Routes. Aquí también deberías encontrar una ruta que probablemente tenga la palabra Prometheus en su nombre. Esto también depende simplemente de la configuración de tu clúster OpenShift. En Ubicación encontrarás entonces la propia URL que más tarde necesitarás para el campo Prometheus API endpoint.
También puedes obtener el FQDN en la línea de comandos con el siguiente comando.
user@host:~$ oc get routes --all-namespaces | grep prometheus
openshift-monitoring prometheus-k8s prometheus-k8s-openshift-monitoring.apps.myopenshift.example.com prometheus-k8s web reencrypt/Redirect NoneDespués sólo tendrás que poner el prefijo del protocolo a la cadena prometheus-k8s-openshift-monitoring.apps.myopenshift.example.com en el campo Prometheus API endpoint dentro de la regla Kubernetes.
Recuperar el token
Puedes utilizar el siguiente comando para leer el token, que suele ser el que más tarde tendrás que especificar para el agente especial en Checkmk:
user@host:~$ oc get secret $(oc describe sa checkmk -n checkmk-monitoring | grep 'Tokens' | awk '{ print $2 }') -n checkmk-monitoring -o=jsonpath='{.data.token}' | base64 --decode
eyJhbGciOiJSUzI1NiIsImtpZCI6IkxFbDdZb25t...Deja el intérprete de comandos abierto con esta información o copia el token en una ubicación a la que puedas acceder durante la siguiente configuración en Checkmk.
Recuperar el certificado
Puedes utilizar el siguiente comando para recuperar el certificado que más tarde tendrás que especificar en Global settings en Checkmk.
user@host:~$ oc get secret $(oc describe sa checkmk -n checkmk-monitoring | grep 'Tokens' | awk '{ print $2 }') -n checkmk-monitoring -o=jsonpath='{.data.ca\.crt}' | base64 --decodeDeja el intérprete de comandos abierto con esta información, o copia el certificado -incluidas las líneas BEGIN CERTIFICATE y END CERTIFICATE - en una ubicación a la que puedas acceder durante la siguiente configuración en Checkmk.
Si la salida aquí está vacía, se aplica el mismo consejo que en la sección anterior Recuperar el token.
4. 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:
4.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 el almacenamiento y el uso de la contraseña de forma organizada. Como alternativa, introduce la contraseña directamente en texto plano al crear la regla (ver más abajo).
Para añadir la contraseña al almacén de contraseñas de Checkmk, navega hasta Setup > General > Passwords > Add password. En nuestro ejemplo utilizamos My OpenShift Token como ID y título:
4.2. Importar el certificado de CA de una cuenta de servicio a Checkmk
Para que Checkmk confíe en la cadena de certificados de la cuenta de servicio, tendrás que almacenarla en Checkmk. Copia todo aquí -incluidas las líneas que contienen 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:
4.3. Crear el host origen piggyback
Crea un nuevo host en Checkmk de la forma habitual y llámalo myopenshiftclusterhost, por ejemplo. Como sugieren el título y el nombre del host, este host se utiliza para recoger los datos piggyback y también para mapear todos los servicios y métricas a nivel de clúster. Como este host recibe los datos exclusivamente a través del agente especial, en las propiedades del host asegúrate de establecer la opción IP address family en No IP. Confirma toda esta configuración pulsando el botón Save & view folder.
4.4. Establecer la configuración dinámica del host
Para garantizar la separación entre los objetos de los distintos clústeres de Kubernetes, suele ser conveniente 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 todos los hosts de un clúster automáticamente. Sin embargo, la creación y el uso de dicha carpeta es opcional.
A continuación, configura un conector para los datos piggyback entrantes. Para ello, navega hasta Setup > Hosts > Dynamic host management > Add connection.. Primero introduce un título y luego, en Connection Properties, haz clic en show more.
El siguiente paso, muy importante, es introducir el host origen piggyback creado previamente en Restrict source hosts.
A continuación, en Piggyback creation options haz clic en Add new element y en Create hosts in selecciona la carpeta creada anteriormente.
Puedes dejar los atributos predeterminados en Host attributes to set tal como están, para que Checkmk sólo acepte los datos piggyback de los host creados automáticamente y no intente hacer ping ni acceder a ellos a través de SNMP, por ejemplo.
En un entorno OpenShift en el que los objetos monitorizables y monitorizados entran y salen continuamente, suele recomendarse activar también 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.
Por último, activa la opción Discover services during creation.
La sección Connection Properties de este nuevo conector podría tener el siguiente aspecto:
4.5. 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 OpenShift, recomendamos crear una regla con la etiqueta cmk/kubernetes:yes para todos los host. Esto se debe a que cada host que representa objetos Kubernetes recibe automáticamente esta etiqueta de Checkmk.
En este caso, debes elegir un intervalo inferior a dos horas para el descubrimiento de servicios, y activar también la opción Automatically update service configuration. Los ajustes de la captura de pantalla siguiente son sólo ejemplos. Tendrás que decidir qué tiene sentido para tus clústeres caso por caso.
Para restringir esta regla a todos los host de tu clúster, en Host labels simplemente introduce cmk/kubernetes:yes en la Conditions. Sin embargo, si también quieres crear reglas diferentes para clústeres diferentes, simplemente utiliza aquí la etiqueta específica del clúster respectivo. Estas etiquetas siempre tienen la forma cmk/kubernetes/cluster:mycluster.
4.6. 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, que se encuentra 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 monitorizar. Este nombre se puede especificar libremente como se desee. Se utiliza para asignar un nombre único a todos los objetos que se originan en este clúster específico. Por ejemplo, si introduces aquí mycluster, los nombres de los hosts de todos los pods de este clúster comenzarán después por pod_mycluster. La siguiente parte del nombre del host será siempre el namespace en el que existe este objeto Kubernetes. Por ejemplo, el nombre del host de un pod podría ser entonces 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 pide ahora que introduzcas la URL a través de la cual se puede contactar con tu servidor API de Kubernetes. El puerto sólo es necesario si el servicio no se proporciona a través de un host virtual. Aquí, introduce la dirección que determinaste en la sección Recuperar el endpoint de la API de Kubernetes.
Si hasta ahora has seguido estas instrucciones paso a paso y has depositado-como se ha descrito anteriormente-el certificado CA de tu clúster en Checkmk, en SSL certificate verification selecciona Verify the certificate.
Activa la opción Enrich with usage data, selecciona Use data from OpenShift en el siguiente menú, e introduce el Prometheus API endpoint que determinaste en la sección Recuperar el endpoint de la API de Prometheus.
La lista bajo Collect information about… te permite seleccionar qué objetos de tu clúster deben ser monitorizados. Esta lista cubre los objetos más relevantes. Si también decides monitorizar el Pods of CronJobs, consulta la ayuda en línea para esta opción.
Las dos selecciones siguientes te permiten delimitar 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.
La opción Cluster resource aggregation te permite designar 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 tanto, por defecto excluimos los nodos control-plane y infra del cálculo.
Como última opción, puedes importar las denominadas anotaciones de Kubernetes. En Checkmk, estas anotaciones se convierten en host labels y, por tanto, pueden utilizarse posteriormente como condiciones en las reglas. Utiliza expresiones regulares para especificar qué anotaciones deben importarse. Vuelve a consultar la ayuda en línea detallada en este punto.
Nota: La opción Import all valid annotations se proporciona aquí sólo para completar. No recomendamos importar todas las anotaciones a la vez, porque 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 para este host. Los primeros servicios a nivel de clúster aparecerán inmediatamente aquí:
Ahora activa todos los cambios que has realizado y deja que la configuración dinámica del host haga el trabajo a partir de ahora. Esto generará todos los host para tus objetos Kubernetes en un breve periodo de tiempo.
5. Etiquetas para objetos Kubernetes
Checkmk genera automáticamente etiquetas para objetos como clústeres, despliegues o namespaces durante un descubrimiento de servicios. Todas las etiquetas para estos objetos que Checkmk genera automáticamente empiezan por cmk/kubernetes/. Por ejemplo, un pod siempre obtendrá una etiqueta del nodo (cmk/kubernetes/node:mynode), una etiqueta que identifique al objeto como 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.
6. Dashboards y vistas
6.1. Dashboards de Kubernetes
Las ediciones comerciales de Checkmk se suministran con seis dashboards integrados para Kubernetes. Para que estos dashboards tengan sentido, es necesario tener instalado y configurado nuestro Colector del clúster. En concreto, estos dashboards se denominan:
Kubernetes (Vista general)
Clúster Kubernetes
DaemonSet de Kubernetes
Despliegue de Kubernetes
Namespace de Kubernetes
StatefulSet de Kubernetes
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 monitorizados aparecen en la parte izquierda. Este listado de clústeres es también tu punto de entrada para profundizar en los dashboards. 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:
6.2. El inventario de hardware/software
La monitorización de OpenShift con Checkmk también admite el inventario de HW/SW. Por ejemplo, en el dashboard del clúster anterior, si haces clic en el nombre de ID del clúster (aquí: mycluster), accederás al inventario del clúster.
Del mismo modo, es decir, en los demás dashboards a través de las cajas con los nombres ID de los objetos, se puede visualizar el inventario de cada objeto respectivo. El siguiente ejemplo muestra el inventario de HW/SW de un pod:
7. Comprobar la instalación
En la GUI Checkmk puedes comprobar que la instalación y la configuración se han realizado correctamente.
Los servicios más importantes aquí son, sin duda, Kubernetes API y Cluster collector. Éstos deben estar presentes en el host de clúster que has creado y también deben mostrar información específica y real.
En Summary, el servicio Kubernetes API debería informar normalmente de Live, Ready, y si el Colector del clúster está configurado, lo ideal es que muestre Successfully queried usage data from Prometheus.
En el dashboard Kubernetes, puedes determinar muy pronto si el colector del clúster se está ejecutando y recopilando datos en un clúster. Si se ha configurado correctamente, el dashboard Kubernetes debería tener este aspecto:
Si ahora haces clic aquí en el nombre del clúster, aterrizarás en el dashboard Kubernetes Cluster del clúster correspondiente. Aquí las tres cajas Primary datasource, Cluster collector y API health deberían ser verdes y mostrar OK.
8. Eliminar componentes de monitorización de OpenShift
8.1. Eliminar la cuenta de servicio
Si has utilizado nuestro archivo YAML predeterminado para crear la cuenta de servicio, también puedes eliminarla como se indica a continuación:
user@host:~$ oc delete -f https://raw.githubusercontent.com/Checkmk/checkmk_kube_agent/checkmk_docs/deploy/kubernetes/checkmk-serviceaccount.yaml
serviceaccount "checkmk" deleted
clusterrole.rbac.authorization.k8s.io "checkmk-metrics-reader" deleted
clusterrolebinding.rbac.authorization.k8s.io "checkmk-metrics-reader-binding" deleted8.2. Eliminar el namespace, cuando sea necesario
user@host:~$ oc delete namespace checkmk-monitoring
namespace "checkmk-monitoring" deleted