Kubernetes Umgebungen sind schnell aufgebaut und Applikationen installiert – jedoch stellt sich spätestens nach dem erstmaligen Deployment die Frage – Wie lassen sich diese Umgebungen und die darin befindlichen Applikationen überwachen, sodaß der Zustand der Umgebung beurteilt und im Fehlerfall eine Analyse (Debugging) durchgeführt werden kann?
Kubernetes Monitoring, Logging & Alerting mit AWS Boardmitteln
Welche Komponenten einer Kubernetes-Umgebung sollten überwacht werden?
- Kritische Komponenten: API-Server, Scheduler, Controller-Manager sowie Etcd Storage.
- Ressourcennutzung: Die Ressourcennutzung der Knoten und Pods sollte überwacht werden, um sicherzustellen, dass diese nicht überlastet sind.
- Leistung: Die Leistung der Anwendungen sollte überwacht werden, um sicherzustellen, dass sie die gewünschten Anforderungen erfüllen.
- Log-Dateien: Die Logmeldungen der Anwendungen und Komponenten sollten überwacht werden, um Fehlermeldungen zu identifizieren und eine spätere Fehleranalyse zu vereinfachen.
Welche Möglichkeiten gibt es Kubernetes Umgebungen zu überwachen?
- Native Überwachungstools (im Regelfall Open-Source)
- Metrics Server: Der Metrics Server stellt Metriken für die kritischen Komponenten von Kubernetes bereit.
- Prometheus: Prometheus ist ein Open-Source-Monitoring-Tool, das Metriken aus verschiedenen Quellen sammeln und speichern kann.
- Grafana: Grafana ist eine Open-Source-Visualisierungs-Plattform, die Metriken aus Prometheus anzeigen kann.
- Kommerzielle Überwachungstools
- New Relic: New Relic bietet eine umfassende Monitoring-Lösung für Kubernetes-Umgebungen.
- Datadog: Datadog bietet ebenfalls eine umfassende Monitoring-Lösung für Kubernetes-Umgebungen.
- Site24x7: Site24x7 bietet eine kostengünstige Monitoring-Lösung für Kubernetes-Umgebungen.
Welche Ansätze und Möglichkeiten gibt es die Überwachung einer Kubernetes Umgebung zu abzubilden?
- Individual-Konfiguration: Aufbau einer eigenständigen MLA (Monitoring, Logging, Alerting) Umgebung
- Managed-Services: Nutzung von Managed Service Angeboten der Hyper-Scaler – hier: AWS
Wir wollen uns nachfolgend die konkrete Implementierung einer Monitoring & Logging Umgebung basierend auf dem Managed-Service Angebot von AWS näher anschauen.
Implementierung von Prometheus und Grafana mit Hilfe von Amazon Managed Grafana + Amazon Managed Service for Prometheus
Ausgangssituation:
Ein EKS-Cluster wurde bereits bereitgestellt und unsere Beispiel-Applikation wurde auf dem Cluster deployed – wir wollen nun den Cluster-Zustand sowie die darauf befindliche Workload (Applikation) überwachen.
Implementierung:
- Definition der gewünschten Monitoring Metriken:
- Node: Node-Health, CPU Usage, Memory Usage
- Kubernetes Pods: Pod Memory Usage, Pod CPU Usage, Application Health
- Allgemeines:
- Das Deployment der Komponenten auf AWS Seite erfolgt über Terraform
- Die Deployment Konfigurationen sind in HCL (HashiCorp configuration language) verfasst
Monitoring
- Deployen einer Logging Group für Managed Prometheus sowie des Managed Prometheus Services, anlegen eines IAM Service Accounts fuer das schreiben von Metriken einer In-Cluster Prometheus Instanz
- Deployen und Konfigurieren einer In-Cluster Prometheus Instanz zum einsammeln der Cluster-Metriken, wahlweise Prometheus Operator oder einen einfachen Prometheus Server mittels Helm.Es wird eine Remote Write Konfiguration vorgenommen um die Datenhaltung bei dem Managed Service zu belassen. Die folgenden Werte sollten in der Datei prometheus.yml gespeichert werden wobei der Platzhalter PROMETHEUS_ENDPOINT durch die URL vom Managed Prometheus Service ersetzt werden sollte:
Abschliessend kann die In-Cluster Prometheus Instanz mit den folgenden Befehlen installiert werden:
- Konfigurieren von dem Managed Prometheus Service innerhalb von dem Managed Grafana Service als Datasource, wahlweise kann diese Datenquelle durch die Grafana Benutzeroberfläche erfolgen, oder durch Terraform basierend auf dem Grafana Provider:
- Konfigurieren eines Grafana Dashboards zum visualisieren der gewünschten Metriken
Logging
- Logmeldungen werden mit Hilfe eines Collectors wie z.B. FluentBit an CloudWatch übertragen. CloudWatch ist die Lösung von AWS zum Sammeln und Aggregieren von Logs und Metriken. Damit Fluentbit dazu berechtigt ist Logmeldungen and CloudWatch zu übertragen, benötigen wir eine entsprechende Policy sowie einen IAM Service Account:
- Anschliessend kann Fluentbit mittles Helm im EKS Cluster installiert werden. Die folgenden Werte sollten in der Datei fluentbit.yml gespeichert werden. Die Platzhalter CLUSTER_NAME und AWS_ACCOUNT_ID müssen durch den Namen des EKS Clusters und die ID des AWS Kontos, in dem die Lösung ausgerollt wird, ersetzt werden.
- Abschliessend kann Fluentbit mit den folgenden Befehlen installiert werden:
- Konfigurieren von CloudWatch innerhalb von dem Managed Grafana Service als Datasource
- Konfigurieren eines Grafana Dashboards zum visualisieren der gesammelten Logdaten
Alerting
Als Ziel für die Alarmmeldungen nutzen wir AWS SNS (Simple Notification Service). SNS ist ein vollständig von AWS verwalteter Pub/Sub-Service für A2A (Application to Application) und A2P (Application to Person) Nachrichten.
- In SNS wird ein sogenanntes “Topic” gebraucht, in das wir unsere Nachrichten schreiben können:
- Ein Alertmanager ist bereits Bestandteil des Managed Prometheus Service, hier kann die Konfiguration entsprechend der eigenen Vorstellungen vorgenommen werden. Als Beispiel wird hier eine Standardroute mittels des oben genannten SNS (Simple Notification Service) Topics konfiguriert:
- Abschliessend können Abonnenten durch die AWS Konsole für das angelegt SNS (Simple Notification Service) Topic angelegt werden
- Konfigurieren von Alarmmeldungen mittels Prometheus Regeln welche vom Alertmanager and SNS (Simple Notification Service) übertragen werden
Vorteile der Lösung:
- Schnelle Bereitstellung einer Monitoring, Logging und Alerting Lösung für Kubernetes
- Skalierbarkeit – die Lösung skaliert mit dem Log-Volumen – Hochlast Situation sind im Preismodell des Managed Service bereits berücksichtigt
- Geringe Betriebskosten – Kein Patch-Management und Wartung der Systeme notwendig
- Hohe Verfügbarkeit – Amazon Managed Prometheus ist von Haus aus in verschiedenen Availability Regionen ausgerollt und damit für eine hohe Verfügbarkeit ausgelegt
Beispiel-Dashboards
Links:
- Grafana Dashboard Library: https://grafana.com/grafana/dashboards/?pg=docs-grafana-latest-dashboards
- Amazon Managed Service for Prometheus: https://docs.aws.amazon.com/grafana/latest/userguide/prometheus-data-source.html
- Amazon Managed Grafana: https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html
Fazit
Mit Hilfe der aufgezeigten Lösung lässt sich schnell und einfach eine skalierbare Monitoring & Logging Lösung implementieren um eine Kubernetes Umgebung zu überwachen.
Durch die Nutzung von Managed Services lässt sich die Bereitstellungszeit enorm verkürzen sodass sich die DevOps Teams & Cluster-Administratoren darauf konzentrieren können, Mehrwert in Richtung des Kunden zu erzeugen, z.B. durch die Konfiguration von individuellen Dashboards für Debugging oder Performance Tests.