36 Kubernetes Monitoring

Kubernetes Monitoring überwacht den Zustand und die Leistung eines Clusters, hilft bei der frühzeitigen Problemidentifikation und erleichtert das proaktive Cluster-Management.

Effizientes Kubernetes Monitoring ist für die Betreuung containerisierter Infrastrukturen wesentlich, da es Transparenz schafft, die Zuverlässigkeit erhöht und eine optimierte Ressourcenverwendung ermöglicht.

36.1 Überblick

Monitoring-Tools sammeln Metriken und Logs von verschiedenen Komponenten eines Clusters, darunter Nodes, Pods, Deployments und Services. Diese Informationen helfen bei der Beurteilung der Gesundheit und Performance des Clusters.

36.2 Schlüsselmetriken

36.2.1 Ressourcennutzung

• CPU: Messung der CPU-Auslastung pro Container, Pod oder Node.
• Speicher: Überwachung des Speicherplatzverbrauchs und Verfügbarkeit.
• Netzwerk: Bandbreite, Durchsatz und Fehler in der Netzwerkkommunikation.

36.2.2 Verfügbarkeit

• Uptime: Betriebszeit von Services und Anwendungen.
• Health Checks: Statusprüfungen von Anwendungen und Infrastruktur.

36.2.3 Performance

• Latency: Antwortzeiten der Anwendungen.
• Throughput: Anzahl der bearbeiteten Anfragen innerhalb eines Zeitraums.

36.3 Interaktionen

• Services: Verbindungen und Abhängigkeiten zwischen Services.
• Nodes: Interaktionen und Zustand der Cluster Nodes.
• Control Plane: Performance und Zustand der Kubernetes Control Plane-Komponenten.

36.4 Monitoring Layer

36.4.1 Cluster Monitoring

Überwacht den Zustand und die Performance des gesamten Clusters. Dazu gehören Nodes, Cluster-Ressourcen und die Kubernetes Control Plane.

• Nodes: Verfügbarkeit und Ressourcennutzung von Cluster Nodes.
• Cluster State: Überwachung von Ereignissen und Zuständen des gesamten Clusters.
• Control Plane: Gesundheitsstatus der Kubernetes API, des Schedulers, Controller-Managers und etcd.

36.4.2 Node Monitoring

Fokussiert sich auf einzelne Nodes im Cluster. Hierzu zählen die Überwachung von Systemmetriken und die Gewährleistung der Node-Gesundheit.

• System Metrics: CPU, Speicher, Disk IO und Netzwerknutzung pro Node.
• Node Status: Ready, NotReady, UnderPressure (wenn Ressourcen knapp sind).

36.4.3 Pod Monitoring

Überwacht die Laufzeitumgebung einzelner Pods, was für die Anwendungsleistung entscheidend ist.

• Pod Metrics: Ressourcennutzung auf Pod-Ebene, wie CPU und Speicher.
• Container Health: Lebenszyklus und Gesundheitszustand der Container innerhalb der Pods.

36.4.4 Application Monitoring

Stellt sicher, dass Anwendungen wie erwartet funktionieren und ihre Performance-Ziele erfüllen.

• Application Logs: Ausgabe und Fehlermeldungen der Anwendungscontainer.
• Custom Metrics: Spezifische Metriken, die von der Anwendung selbst veröffentlicht werden.
• End-User Experience: Response Times und Error Rates aus Nutzersicht.

36.4.5 Network Monitoring

Bezieht sich auf die Überwachung der Netzwerkperformance und der Kommunikation zwischen den Komponenten.

• Network Traffic: Überwachung eingehender und ausgehender Netzwerkdaten.
• Service Mesh Metrics: Latenz, Durchsatz und Fehler in einem Service Mesh wie Istio.
• Ingress/Egress Monitoring: Überwachung der Netzwerkverbindungen, die in den Cluster hinein und aus ihm herausgehen.

36.4.6 Storage Monitoring

Überwacht die Speicherressourcen und deren Performance innerhalb des Kubernetes-Clusters.

• Volume Usage: Nutzung und Verfügbarkeit von Persistent Volumes.
• I/O Performance: Lese-/Schreibgeschwindigkeiten und IOPS von Speichergeräten.
• Storage Health: Zustand und Verfügbarkeit der Speichersysteme.

Durch die Kombination dieser Monitoring-Level erhält man eine ganzheitliche Sicht auf den Zustand und die Performance eines Kubernetes-Clusters und kann so die Zuverlässigkeit und Effizienz der containerisierten Anwendungen sicherstellen.

36.5 Monitoring tools

Die folgende Tabelle bietet einen Überblick über gängige Monitoring-Tools für Kubernetes, geordnet nach ihrer Bedeutung bzw. Beliebtheit. Diese Tools bieten eine breite Palette von Funktionen zur Überwachung, Verwaltung und Analyse von Kubernetes-Clustern. Die Tabelle enthält außerdem Informationen zum spezifischen Einsatzgebiet jedes Tools sowie weitere relevante Bemerkungen. Die Rangfolge und Details zu den Tools basieren auf der allgemeinen Anerkennung und Nutzung in der Kubernetes-Community.

Quellen 1 2

36.6 Datenfluss im Kubernetes Monitoring

Im Kubernetes Monitoring werden Metriken auf verschiedenen Ebenen erfasst: Sie starten bei den Anwendungen in den Pods, fließen durch den cAdvisor und das kubelet, um grundlegende Ressourcenmetriken zu sammeln, und münden schließlich im Metric Server. Dort werden sie zentralisiert und sind über die Kubernetes-API abrufbar, wodurch Monitoring-Tools und Services im Cluster darauf zugreifen können.

36.6.1 Metriken in Pods

Anwendungen in Kubernetes laufen in Containern, die in Pods organisiert sind. Jeder Pod kann eine oder mehrere Anwendungen enthalten. Metriken, die von diesen Anwendungen generiert werden, umfassen beispielsweise Anfragen pro Sekunde, Antwortzeiten und Fehlerzahlen.

36.6.1.1 Custom Metrics

Anwendungen können spezifische Metriken ausgeben, die über Endpunkte (meist /metrics) für Monitoring-Tools zugänglich sind. Diese Endpunkte werden typischerweise von einem Prometheus-Client bereitgestellt.

36.6.2 cAdvisor und Kubelet

Jeder Node im Kubernetes-Cluster läuft mit einem kubelet, dem Agenten, der die Pods und Container auf dem Node steuert. Eingebaut in das kubelet ist cAdvisor (Container Advisor), der für die Erfassung von Metriken der Container-Ressourcennutzung wie CPU, Speicher, Netzwerk und Festplattenauslastung verantwortlich ist.

36.6.2.1 cAdvisor

cAdvisor überwacht Container auf einem Node und erfasst die Ressourcennutzung und Leistungsdaten. Es arbeitet direkt auf der Betriebssystemebene eines Hosts und sammelt, aggregiert, verarbeitet und exportiert Informationen über laufende Container.

cAdvisor arbeitet dabei wie folgt:

• Ressourcennutzung: cAdvisor überwacht die Ressourcennutzung und Performance-Metriken von Containern. Er erfasst Informationen zu CPU, Speicher, Dateisystem und Netzwerknutzung.

• Namespace-Isolierung: In einem Linux-System nutzen Container Namespaces, um eine isolierte Sicht auf das System zu haben. cAdvisor interagiert mit diesen Namespaces, um Metriken zu erfassen.

• cgroups: cAdvisor liest Informationen aus den Control Groups (cgroups), die von der Linux-Kernel-Funktionalität bereitgestellt werden. Cgroups stellen Mechanismen zur Isolierung und Begrenzung der Ressourcennutzung von Prozessen zur Verfügung. Da jeder Container im Allgemeinen seine eigenen cgroups hat, kann cAdvisor spezifische Daten über die Ressourcennutzung jedes Containers erfassen.

• Docker-Integration: Bei Verwendung von Docker interagiert cAdvisor mit der Docker-Engine, um Informationen über Container-Instanzen und deren Ressourcenverbrauch zu erhalten.

• Export von Metriken: Die gesammelten Daten werden von cAdvisor aufbereitet und über eine RESTful-API oder über ein anderes Exportformat (z.B. Prometheus) für die Verwendung in Monitoring-Systemen bereitgestellt.

Der cAdvisor ist in das kubelet integriert und dient als eine der primären Quellen für Containermetriken im Kubernetes-Ökosystem.

36.6.2.2 Kubelet

Das kubelet sammelt die von cAdvisor bereitgestellten Daten und stellt sie über seine API bereit. Es ist auch für die Übermittlung dieser Daten an den Metric Server verantwortlich.

36.6.3 Metric Server

Der Metric Server agiert als zentrale Datensammelstelle für Metriken im Cluster. Er sammelt aggregierte Daten von allen Nodes im Cluster, die vom kubelet bereitgestellt werden.

36.6.3.1 Aggregation

Der Metric Server aggregiert die Daten, die er von den Nodes erhält, und speichert diese in einem internen Format, das für schnelle Abfragen optimiert ist. Er hält diese Metriken nicht dauerhaft vor, sondern bietet aktuelle Snapshots der Ressourcennutzung an.

36.6.4 Kubernetes API

Die Kubernetes-API stellt einen Zugangspunkt für externe Tools und Services bereit, um auf Metriken und Informationen über den Cluster zuzugreifen.

36.6.4.1 Zugriff auf Metriken

Tools wie Prometheus können Metriken direkt von der API abfragen, wobei sie die vom Metric Server bereitgestellten Informationen nutzen. Diese Metriken können dann für Monitoring, Alarmierung und andere Automatisierungen verwendet werden.

36.6.4.2 Horizontal Pod Autoscaler

Der Horizontal Pod Autoscaler (HPA) nutzt auch die Metriken von der Kubernetes-API, um Entscheidungen über das Hoch- und Runterfahren der Pod-Replikation basierend auf der aktuellen Last zu treffen.

36.7 Überprüfung der Kubernetes Monitoring Ebenen mit kubectl

Durch die Verwendung der beschriebenen Befehle können Sie detaillierte Einblicke in die Zustände und Metriken Ihres Kubernetes-Clusters erhalten. Sie erlauben eine granulare Analyse von der Custerebene bis hinunter auf die Anwendungsebene.

36.7.1 Cluster Level

36.7.1.1 Nodes Überprüfen

kubectl get nodes

NAME       STATUS   ROLES    AGE   VERSION
node1      Ready    master   1d    v1.20.2
node2      Ready    <none>   1d    v1.20.2
node3      Ready    <none>   1d    v1.20.2

36.7.1.2 Ressourcennutzung der Nodes

kubectl top nodes

NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
node1      190m         9%     1460Mi          77%
node2      113m         5%     780Mi           41%
node3      300m         15%    1100Mi          58%

36.7.1.3 Status der Cluster-Komponenten

kubectl get componentstatus

NAME                 STATUS    MESSAGE             ERROR
controller-manager   Healthy   ok                  
scheduler            Healthy   ok                  
etcd-0               Healthy   {"health":"true"}   

36.7.2 Node Level

36.7.2.1 Spezifischen Node Überprüfen

kubectl describe node <node-name>

Name:               node1
Roles:              master
Labels:             kubernetes.io/role=master
Annotations:        node.alpha.kubernetes.io/ttl=0
CreationTimestamp:  Wed, 01 Jul 2020 12:34:56 +0000
...

36.7.2.2 Pods auf einem Node Anzeigen

kubectl get pods --all-namespaces --field-selector spec.nodeName=<node-name>

NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE
kube-system   coredns-5644d7b6d9-mnqbb   1/1     Running   0          1d
...

36.7.3 Pod Level

36.7.3.1 Pods im Cluster Überprüfen

kubectl get pods --all-namespaces

NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE
kube-system   coredns-5644d7b6d9-mnqbb   1/1     Running   0          1d
...

36.7.3.2 Ressourcennutzung von Pods

kubectl top pod --all-namespaces

NAMESPACE     NAME                       CPU(cores)   MEMORY(bytes)
kube-system   coredns-5644d7b6d9-mnqbb   3m           70Mi
...

36.7.4 Container Level

36.7.4.1 Ressourcennutzung von Containern in einem Pod

kubectl top pod <pod-name> --containers

POD                  NAME             CPU(cores)   MEMORY(bytes)
coredns-5644d7b6d9   coredns          3m           70Mi
...

36.7.5 Application Level

36.7.5.1 Logs eines Containers in einem Pod

kubectl logs <pod-name> -c <container-name>

2021-07-01T12:34:56.7890Z INFO server: request received
...

36.7.5.2 Überwachung von Ereignissen in einem Namespace

kubectl get events -n <namespace>

LAST SEEN   TYPE      REASON               OBJECT                         MESSAGE
1m          Normal    Scheduled            pod/myapp-pod                  Successfully assigned default/myapp-pod to node1
...