Monitorización del Cluster k3s con kube-prometheus-stack

# Monitorización del Cluster k3s con kube-prometheus-stack

**Fecha:** 2026-07-31 **Cluster:** k3s (8 nodos) — Raspberry Pi + AMD64 **Stack:** Prometheus + Grafana + Alertmanager + Node Exporter + kube-state-metrics

-–

## Resumen

Se desplegó monitorización completa sobre el cluster k3s usando el chart Helm `kube-prometheus-stack` (v69.7.3) gestionado vía ArgoCD (GitOps).

## Componentes desplegados

| Componente | Estado | |—|—| | **Prometheus** | 2/2 — 7 días retención, 30GB en MooseFS | | **Grafana** | 3/3 — `grafana.tech.eus` con cert Let’s Encrypt | | **Alertmanager** | 2/2 — groupings por namespace/severity | | **Node Exporter** | 8/8 — un agente por nodo | | **kube-state-metrics** | 1/1 — métricas de objetos K8s |

## Estructura GitOps

``` k8s/ ├── applications/monitoring.yaml → App ArgoCD (multi-source) ├── values/kube-prometheus-stack.yaml → Valores Helm ├── manifests/monitoring/ │ ├── kustomization.yaml │ └── grafana-ingress.yaml → IngressRoute + Certificate └── namespaces/monitoring.yaml ```

La aplicación ArgoCD usa **3 fuentes**: 1. Chart `kube-prometheus-stack` desde prometheus-community 2. Valores personalizados desde el repo 3. Manifiestos adicionales (IngressRoute, Certificate)

## Scrape target custom: Proxmox

Se añadió el endpoint de métricas de Proxmox/PVE:

```yaml additionalScrapeConfigs: - job_name: “proxmox” scrape_interval: 15s metrics_path: /metrics params: masterhost: [“192.168.0.123”] static_configs: - targets: [“192.168.0.123:9425”] ```

Prometheus scrapea `http://192.168.0.123:9425/metrics?masterhost=192.168.0.123\` cada 15 segundos.

## Problemas encontrados y soluciones

### 1. Permisos en PVC de MooseFS (subPath)

**Problema:** Prometheus arrancaba en CrashLoopBackOff con: ``` Error opening query log file /prometheus/queries.active: permission denied ```

**Causa:** El mount del PVC usa `subPath: prometheus-db`. Cuando se usa subPath, Kubernetes **no aplica el `fsGroup`** al subdirectorio. Prometheus corre como user 1000 (group 2000) pero el volumen MooseFS no tenía permisos para ese user.

**Solución:** `chmod -R 777` al PVC directamente desde MooseFS.

**Alternativa implementada (no ejecutada por el fix manual):** Init container que hace `chown -R 1000:2000 /prometheus` antes de arrancar Prometheus, ejecutado como root para poder cambiar los permisos.

### 2. Sync de ArgoCD atascado por hook job

**Problema:** El sync de ArgoCD se quedaba en “Running” esperando al hook `kube-prometheus-stack-admission-create` que intentaba pull de `registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.5.1` (403 Forbidden).

**Solución:** Habilitar `certManager.enabled: true` en el prometheusOperator para que use cert-manager (ya instalado en el cluster) en lugar del certgen job. Además añadir `SkipHooks=true` en syncOptions.

### 3. Conflicto de Ingress existente

**Problema:** Ya existía un Ingress `grafana` en namespace `default` (de una instalación anterior de Grafana) que también apuntaba a `grafana.tech.eus`. Esto causaba conflicto con el nuevo IngressRoute en `monitoring`.

**Solución:** Eliminar el Ingress antiguo del namespace `default`.

## Dashboards precargados

- **Node Exporter Full** (ID 1860, rev 37) - **Kubernetes Cluster Monitoring** (ID 7249, rev 1) - **Pods** (ID 8588, rev 1)

## Acceso

- **Grafana:** `https://grafana.tech.eus\` (admin/admin — cambiar contraseña)

## Notas

- Almacenamiento: MooseFS para Prometheus (30GB) y Grafana (10GB) - Node Exporters desplegados automáticamente en todos los nodos del cluster - Alertmanager configurado con groupings por namespace y severidad - Las alertas se pueden conectar a Telegram/email más adelante