¿Qué ofrece la Monitorización básica de Plataforma?
- Onesait Platform
Introducción
Cuando un sistema entra en operación es importante que el sistema esté monitorizado. Será el equipo de Operación el que se encargue de esto, y la Plataforma de suministrar los mecanismos para que se pueda monitorizar.
Para esto esto la Plataforma ofrece 2 componentes, lo que llamamos Monitorización básica y la Monitorización avanzada (ver ¿Qué ofrece la Monitorización avanzada de Onesait Platform? )
Tecnologías
La monitorización se Plataforma permite monitorizar tanto las máquinas del clúster como los componentes de Kubernetes, Pods, servicios, etc… y se basa en las siguientes tecnologías:
Prometheus: Es una herramienta que permite la recolección de métricas de Kubernetes, tanto de los componentes propios de k8s (Control Plane, Scheduler, etcd) y de sistema, así como de los pods desplegados de Plataforma además de métricas básicas de los nodos que forman parte del clúster.
Grafana: Permite visualizar, una vez configurado el Datasource, las métricas almacenadas tanto por Prometheus como por InfluxDB
Además el CaaS (Rancher 2 u OpenShift) integra la monitorización con Prometheus+Grafana de modo que desde su consola de administración se pueden acceder a los distintos dashboards del clúster.
Despliegue en Rancher
Para desplegar el combo Grafana+Prometheus que nos ofrece Rancher 2 hay que hacer clic sobre la pestaña Tools>Monitoring
Esto abrirá una nueva ventana donde se podrá cambiar la configuración por defecto del despliegue de estas herramientas.
Al hacer clic sobre deploy, Rancher2 ejecutará un chart de Helm que al cabo de unos minutos dejará lista la monitorización de los elementos que conforman el cluster.
Cómo acceder a la Monitorización en Rancher
Para acceder a la monitorización del cluster y/o de los componentes o microservicios desplegados en los distintos namespaces tendremos que logarnos en la consola de Rancher 2:
Una vez dentro accederemos al cluster que queramos monitorizar, en este caso onesaitplatform
Se nos abrirá un dashboard en el que se muestra la capacidad porcentual de CPU, memoria y POD’s desplegados en el cluster. Además de un enlace directo a un dashboard específico para cada componente de Kubernetes: etcd, ControlPlane, Scheduler y Nodes.
Cómo acceder a la Monitorización de los componentes de Plataforma
De la misma manera que hemos accedido a la monitorización del clúster (componente de k8s y nodos en los que despliega) podremos acceder a la monitorización de cada uno de los componentes de Plataforma, para ello tendremos que acceder al namespace que nos interese desde la consola de Rancher 2.
Dentro del namespace accederemos a los workloads o recursos desplegados, en este caso Deployments y Pods:
En el listado de Deployments elegiremos el que queramos monitorizar:
Se nos mostrarán las métricas del workload junto a un enlace al dashboard si clickamos en el icono de Grafana.
Dentro de Grafana podremos examinar los dashboard de cualquier Deployment del namespace, para ello bastará con elegirlo mediante el deplegable Deployment:
Podremos incluso inspeccionar los dashboards de otros namespaces sin necesidad de volver a la consola de Rancher 2.
Nuevo Sistema de Monitorización en Rancher >= 2.5
La monitorización usando el Cluster Manager está deprecada a partir de la versión v2.5.0 de Rancher. La versión actualizada se instala desde el Marketplace de Cluster Explorer.
Desplegando la Monitorización desde Cluster Explorer
Abrir Cluster Explorer:
Abrir el marketplace:
Configurar la aplicación de monitorización. El despliegue se realiza con Helm 3. Se puede usar el formularo para configurar la instalación, pero también directamente desde el fichero YAML.
Seleccionar el proyecto donde se desplegarán los recursos.
Seleccionar el tipo de cluster:
Seleccionar la política de retención para Prometheus:
Elegir si se quiere persistir los datos. Para configurar la persistencia se necesita crear y configurar varios recursos adicionales dependiendo del proveedor cloud. Los siguientes pasos son necesarios si se está en un entorno on premise sin proveedor de disco.
Elegir el tamaño adecuado teniendo en cuenta la retención indicada previamente.
Prometheus se despliega usando un StatefulSet, por lo tanto los PVCs se crean usando un PVC template definido en el propio StatefulSet. Cuando no hay proveedor de disco, los PVs se tienen que crear a mano con etiquetas que permitan definir selectores para que los PVCs que se creen dinámicamente puendan usar los PVs correctos.
Ejemplo de PV:
apiVersion: v1
kind: PersistentVolume
metadata:
name: prometheus-1
namespace: cattle-monitoring-system
labels:
minsait/storage: prometheus
spec:
capacity:
storage: 100Gi
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: minsait/node
operator: In
values:
- osp1
accessModes:
- ReadWriteOnce
hostPath:
path: /Data/onesaitplatform/prometheus
Hay un bug en RKE usando almacenamiento Local o HostPath con subpaths en el volumen persistido. El chart de Helm hace el mapeo de PVCs con los PODs de Prometheus usando subpaths y por lo tanto falla. Si esto ocurre, aparentemente está bien instalado, pero los datos no se persisten en el directorio indicado si no en un volumen local de Kubernetes en /var/lib/kubelet. Para solucionar esto se tiene que editar el YAML y añadir la configuración disableMountSubPath: true. Esto se hace en la sección storageSpec de la configuración prometheusSpec.
prometheus:
prometheusSpec
storageSpec:
disableMountSubPath: true
Para configurar la persistencia de Grafana se necesita crear un PV y un PVC manualmente ya que no hay proveedor de disco.
Finalmente, se pueden definir reglas de afinidad para elegir en qué nodos se desplegarán los recursos. Por ejemplo:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: minsait/env
operator: In
values:
- osp
Algunos pods que se usan para extraer métricas de los nodos se despliegan en todos los nodos.
Finalmente, si se quiere borrar la aplicación de monitorización es necesario borrar varios recursos manualmente. Una vez la aplicación se ha borrado desde el marketplace hay que comprobar que el namespace de monitorización se ha borrado. En ocasiones un resurso se queda bloqueado en estado updating en APIServices. Se pueden borrar todos los APIServices que sean de monitorización. Lo mismo hay que hacer con los CRD (Custom Resource Definitios). Además algunos webhooks pueden quedarse sin bloqueados. Esto se puede comprobar, y borrar, con los siguientes comandos: