1 Introducción
2 Tecnologías
3 Despliegue en Rancher
4 Cómo acceder a la Monitorización en Rancher
5 Cómo acceder a la Monitorización de los componentes de Plataforma
6 Nuevo Sistema de Monitorización en Rancher >= 2.5
- 6.1 Desplegando la Monitorización desde Cluster Explorer

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:

kubectl get validatingwebhookconfiguration -A --insecure-skip-tls-verify=true
# kubectl delete validatingwebhookconfiguration/rancher-monitoring-admission --insecure-skip-tls-verify=true

kubectl get mutatingwebhookconfiguration -A --insecure-skip-tls-verify=true
# kubectl delete mutatingwebhookconfiguration/rancher-monitoring-admission --insecure-skip-tls-verify=true

platform-doc-es

¿Qué ofrece la Monitorización básica de Plataforma?