Monitoring Stack – Prometheus / Grafana

Veröffentlicht am 15. Dezember 2024

Hinweis Setup Raspberry Pis: In meinen vorherigen Artikeln habe ich gezeigt, wie ich mein Kubernetes-Cluster auf einem Raspberry Pi-Setup eingerichtet habe + wie meine Staging / Namespace Strategie via ArgoCD implementiert wurde. Falls du diese Beiträge noch nicht kennst, kannst du sie hier und hier nachlesen. In diesem Beitrag geht es einen Schritt weiter: Ich zeige dir, welchen Monitoring Stack ich für das Clusters und der darauf laufenden Applikationen wähle.

Motivation

In meinem Setup möchte ich Operatoren einsetzen, um den administrativen Aufwand möglichst gering zu halten. Operatoren automatisieren viele Prozesse und sorgen dafür, dass das System zuverlässig und effizient läuft, ohne dass man ständig manuell eingreifen muss.

Zudem soll es für User im Cluster einfach möglich sein, eigene Metriken zu scrapen und passende Grafana-Dashboards für ihre Anwendungen zu erstellen. Ziel ist es, diesen Prozess ohne zusätzlichen Administrationsaufwand zu ermöglichen. Damit fördere ich die Autonomie der User, während ich gleichzeitig die Komplexität für die Verwaltung reduziere.

Ziel-Architektur

Die Zielarchitektur des Setups sieht folgendermaßen aus:

Management-Namespace (mngt):
Hier hosten wir den Prometheus Operator und eine dazugehörige Prometheus-Instanz. Zusätzlich wird ein Grafana Operator bereitgestellt.
Grafana Datasource:
Eine Grafana-Datenquelle wird erstellt, die auf die Prometheus-Instanz verweist, um alle relevanten Metriken zentral abrufen zu können.
Monitoring-Beispiele:
Als Beispiel für Monitoring-Anwendungsfälle überwachen wir:
- Cilium zur Netzwerküberwachung.
- Das Kubernetes-Cluster selbst, mittels kube-state-metrics.

Erweiterbarkeit für User-Namespaces:
Es soll später möglich sein, in den User-Namespaces (z. B. dev, qa, prod) eigene Prometheus-Endpunkte zu definieren und Custom-Grafana-Dashboards zu erstellen. Dies ermöglicht den Usern eine einfache und flexible Möglichkeit zur Überwachung ihrer Anwendungen – ohne zusätzlichen Administrationsaufwand.

Prometheus-Setup

Das Prometheus-Setup (Metrik Tool unseres Monitoring Stack) erfolgt Schritt für Schritt unter Verwendung des Prometheus Operators. Hier sind die konkreten Schritte und Dateien, die dafür notwendig sind:

Prometheus Operator einrichten
Als Basis nutzen wir den Prometheus Operator. Die benötigten CRDs, Deployments und Ressourcen werden aus der bundle.yaml erzeugt, die wir uns zuvor heruntergeladen haben.

RBAC-Konfiguration
Erstellen einer RBAC-YAML-Datei zur Steuerung der Zugriffsrechte für den Prometheus Operator und die Prometheus-Instanz.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources:
  - nodes
  - nodes/metrics
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources:
  - configmaps
  verbs: ["get"]
- apiGroups:
  - networking.k8s.io
  resources:
  - ingresses
  verbs: ["get", "list", "watch"]
- apiGroups: ["monitoring.coreos.com"]
  resources: ["prometheuses", "servicemonitors", "podmonitors"]
  verbs: ["get", "list", "watch", "create", "update", "delete", "deletecollection"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
- kind: ServiceAccount
  name: prometheus

Prometheus-Instanz erstellen
Eine eigene Prometheus-Instanz wird durch eine Prometheus-Custom-Resource definiert.

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
  labels:
    app: prometheus
spec:
  serviceMonitorSelector: {}
  podMonitorSelector: {}
  replicas: 1
  version: "v2.26.0"
  resources:
    requests:
      cpu: 100m
      memory: 400Mi
    limits:
      cpu: 200m
      memory: 800Mi
  securityContext:
    fsGroup: 2000
    runAsNonRoot: true
    runAsUser: 1000
  serviceAccountName: prometheus
  retention: 10d

Service für Prometheus-Expose
Ein Service wird erstellt, um die Prometheus-Instanz nach außen bereitzustellen und die Metrik-Schnittstelle zugänglich zu machen.

apiVersion: v1
kind: Service
metadata:
  name: prometheus
  labels:
    app: prometheus
spec:
  ports:
  - name: web
    port: 9090
    targetPort: web
  selector:
    app.kubernetes.io/name: prometheus
  sessionAffinity: ClientIP

ServiceMonitor für Metrik-Scraping
Ein ServiceMonitor wird eingerichtet, um den zuvor erstellten Service nach Metriken zu überwachen.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: prometheus-self
  labels:
    app: prometheus
spec:
  endpoints:
  - interval: 30s
    port: web
  selector:
    matchLabels:
      app: prometheus

Grafana-Setup

Das Setup für Grafana (Visualisierungstool unseres Monitoring Stack) erfolgt unter Verwendung des Grafana Operators, der uns eine flexible und automatisierte Verwaltung von Grafana ermöglicht. Hier sind die konkreten Schritte für die Installation und Konfiguration:

Installation des Grafana Operators
Der Grafana Operator wird über Helm installiert. Für eine kontinuierliche Verwaltung kann der Deployment-Prozess mit ArgoCD automatisiert werden. Die Helm-Chart für den Grafana Operator findet sich unter:
Grafana Operator Helm Chart

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  namespace: default
  name: grafana
spec:
  project: default
  source:
    repoURL: 'https://github.com/grafana-operator/grafana-operator'
    targetRevision: master  # Branch oder Tag im Repository
    path: deploy/helm/grafana-operator  # Pfad zur Helm-Chart oder zu den Kustomize-Dateien
    helm:
      releaseName: grafana-operator
  destination:
    server: 'https://kubernetes.default.svc'
  syncPolicy:
    automated:
      prune: true  # Entfernt Ressourcen, die nicht mehr im Repository vorhanden sind
      selfHeal: true  # Synchronisiert automatisch bei Abweichungen
    syncOptions:
      - CreateNamespace=true  # Erzeugt den Namespace, falls dieser nicht existiert

Grafana-Instanz erstellen
Der Grafana Operator ermöglicht die Erstellung einer Grafana-Instanz über eine Custom Resource (CR):

apiVersion: grafana.integreatly.org/v1beta1
kind: Grafana
metadata:
  name: grafana
  labels:
    dashboards: "grafana"
spec:
  config:
    log:
      mode: "console"
    security:
      admin_user: admin
      admin_password: password

Grafana-Datenquelle konfigurieren
Eine Grafana Datasource wird erstellt, um die Verbindung zur Prometheus-Instanz herzustellen. Die Prometheus-URL verweist auf den internen Service-Endpunkt: http://prometheus.mngt.svc.cluster.local:9090.

apiVersion: grafana.integreatly.org/v1beta1
kind: GrafanaDatasource
metadata:
  namespace: mngt
  name: prometheus
spec:
  instanceSelector:
    matchLabels:
      dashboards: "grafana"
  allowCrossNamespaceImport: true
  datasource:
    uid: prometheus
    access: proxy
    database: prometheus
    jsonData:
      timeInterval: 5s
      tlsSkipVerify: true
    name: prometheus
    type: prometheus
    url: http://prometheus.mngt.svc.cluster.local:9090

Beispiel Kube-State-Metrics

Um die Metriken des Kubernetes-Clusters zu erfassen, wird das Tool kube-state-metrics eingesetzt. Dieses stellt detaillierte Informationen über den Zustand von Kubernetes-Ressourcen zur Verfügung. Hier sind die einzelnen Schritte für das Deployment und die Konfiguration:

Deployment von Kube-State-Metrics
Als Basis verwenden wir die Ressourcen aus dem offiziellen Repository: kube-state-metrics. Die folgenden YAML-Dateien wurden heruntergeladen, um alle notwendigen Kubernetes-Definitionen bereitzustellen:

cluster-role.yaml: Definiert die Berechtigungen für kube-state-metrics.
cluster-role-binding.yaml: Bindet die Cluster-Role an den Service Account.
service-account.yaml: Erstellt den Service Account für kube-state-metrics.
deployment.yaml: Deployment-Definition für die kube-state-metrics-Pods.
service.yaml: Service zur Freigabe eines Ports.

kustomization.yaml: Zur Verwaltung der Ressourcen mit kubectl kustomize.

Service Monitor für Kube-State-Metrics
Ein ServiceMonitor wird erstellt, um sicherzustellen, dass Prometheus die Metriken von kube-state-metrics scrapen kann

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: kube-state-metrics-monitor
  labels:
    app: kube-state-metrics
spec:
  endpoints:
  - interval: 30s
    port: http-metrics
  selector:
    matchLabels:
      app: kube-state-metrics

Grafana-Dashboard für Kube-State-Metrics
Um die erfassten Cluster-Metriken zu visualisieren, wird in Grafana eine Datenquelle erstellt (falls noch nicht geschehen), die auf die Prometheus-Instanz verweist.
Ein fertiges Grafana-Dashboard für kube-state-metrics kann z. B. aus der offiziellen Grafana-Dashboard-Bibliothek importiert werden.
Kube-State-Metrics Dashboard: kube-state-metrics-v2

TAGSArgoCD Cluster Grafana Kubernetes Monitoring Prometheus

DevOps, Cloud, Backend