37 Logging in Kubernetes

37.1 Motivation

Logging ist ein kritischer Aspekt des Systemmanagements und der Betriebsüberwachung in Kubernetes. Es ermöglicht Entwicklern und Systemadministratoren, Einblick in das Verhalten von Anwendungen und die Leistung von Clustern zu erhalten. Die Protokollierung unterstützt bei:

Fehlerbehebung: Schnelle Identifikation und Behebung von Problemen in Anwendungen und Infrastruktur.
Monitoring: Überwachung der Systemleistung und Erkennung von Anomalien.
Auditierung: Nachverfolgung von Benutzeraktivitäten und Änderungen im System.
Compliance: Sicherstellung, dass die Systeme den regulatorischen Anforderungen entsprechen.
Analyse: Gewinnung von Einsichten zur Verbesserung der Anwendungsleistung und Benutzererfahrung.

37.2 Cluster-Level Logging

Cluster-Level Logging in Kubernetes bezieht sich auf das Sammeln und Speichern von Log-Daten auf einer Ebene, die unabhängig von einzelnen Knoten, Pods oder Containern ist. Dieses Konzept ist wichtig, da:

Pod-Lebenszyklus: Pods und ihre Container können erstellt, gelöscht und neu gestartet werden. Ihre Logs sollten erhalten bleiben.
Knotenfehler: Bei einem Knotenausfall sollten die Logs zugänglich sein, um die Ursache zu ermitteln.
Skalierbarkeit: Mit der Skalierung des Clusters sollten die Logs zentral verwaltet werden, um Konsistenz und Verfügbarkeit zu gewährleisten.

37.2.1 Kubernetes Native Logging-Lösungen

Kubernetes selbst bietet keine native Speicherlösung für Log-Daten. Stattdessen können Administratoren und Entwickler auf verschiedene externe Lösungen zurückgreifen, wie:

Elasticsearch und Kibana: Für Speicherung, Durchsuchung und Visualisierung von Log-Daten.
Fluentd und Fluent Bit: Als Log-Aggregatoren, die Daten an Speicher-Backends weiterleiten.
Prometheus und Grafana: Für das Monitoring und die Visualisierung von Metriken, die aus Log-Daten extrahiert werden können.

37.2.2 Best Practices

Um ein effektives Logging-System in Kubernetes zu implementieren, sollten folgende Best Practices beachtet werden:

Zentrale Speicherung: Speichern Sie Logs an einem zentralen Ort, der unabhängig von der Lebensdauer der Container oder Pods ist.
Log-Rotation: Implementieren Sie Log-Rotation, um Speicherplatz zu sparen und die Übersichtlichkeit zu bewahren.
Sicherheit: Schützen Sie Log-Daten durch Zugriffskontrollen und Verschlüsselung.
Redundanz: Stellen Sie sicher, dass Log-Daten redundant gespeichert werden, um Datenverlust zu vermeiden.
Lebenszyklusmanagement: Definieren Sie Richtlinien für das Lebenszyklusmanagement von Logs, einschließlich Retention-Policies und Archivierung.

37.3 Application Level Logging in Kubernetes

37.3.1 Handhabung von Application Level Logging

Application Level Logging in Kubernetes konzentriert sich auf die Erfassung und Verwaltung von Protokollen, die speziell von den Anwendungen innerhalb der Pods erzeugt werden. Diese Form des Loggings ist entscheidend für die Analyse und das Verständnis des Anwendungsverhaltens sowie der Performance. Es liefert detaillierte Informationen zu Vorgängen auf Anwendungsebene und ist eine wichtige Ergänzung zum Cluster-Level Logging für eine umfassende Überwachung und sollte daher mit Bedacht implementiert und gepflegt werden.

Es umfasst:

Anwendungsspezifische Ereignisse: Benutzeraktionen, Geschäftslogik oder andere Vorgänge, die innerhalb der Anwendung stattfinden.
Anwendungsspezifische Metriken: Leistungsindikatoren, die für die Anwendung kritisch sind.
Anwendungsspezifische Fehler: Fehlermeldungen, die von der Anwendung generiert werden und nicht direkt vom Kubernetes-System stammen.

37.3.2 Speicherung der Daten

Die Daten für das Application Level Logging werden oft wie folgt vorgehalten:

Innerhalb des Containers: In Dateien, die von der Anwendung direkt geschrieben werden.
Externe Speichersysteme: Datenbanken, Dateisysteme oder spezialisierte Logging-Dienste, die außerhalb des Kubernetes-Clusters betrieben werden können.

37.3.3 Unterschiede zum Cluster-Level Logging

Granularität: Application Level Logging ist feingranularer und auf die Anwendung selbst fokussiert, während Cluster-Level Logging die gesamte Cluster-Umgebung betrachtet.
Lebenszyklus: Application Logs können unabhängig vom Lebenszyklus der Pods oder Container verwaltet werden, insbesondere wenn sie extern gespeichert werden.
Formatierung: Die Log-Daten auf Anwendungsebene können in einem Format vorliegen, das spezifisch für die Anwendung oder das Geschäftsmodell ist.
Zugriff: Entwickler haben oft direkten Zugriff auf Application Logs, während Cluster-Level Logs möglicherweise von Systemadministratoren verwaltet werden.

37.3.4 Best Practices für Application Level Logging

Strukturierte Logs: Verwendung von strukturierten Log-Formaten wie JSON, um die Analyse und das Parsing zu erleichtern.
Konsistente Log-Levels: Definieren von Log-Levels (z.B. INFO, WARN, ERROR), um die Wichtigkeit von Log-Einträgen zu signalisieren.
Korrelation: Implementierung von Korrelations-IDs, um Logs über verschiedene Services hinweg nachverfolgen zu können.
Sicherheit: Anwendung von Sicherheitsmaßnahmen wie Zugriffskontrollen und Verschlüsselung, um sensible Daten in den Logs zu schützen.
Performance: Sicherstellung, dass das Logging die Performance der Anwendung nicht negativ beeinflusst.

37.4 Aufbau einer Logging-Pipeline in Kubernetes

37.4.1 Data Source

Die Quelle der Log-Daten in einem Kubernetes-Cluster sind typischerweise:

Container Logs: Standardausgabe (stdout) und Standardfehler (stderr) von Container-Prozessen.
Kubernetes System Logs: Logs von Kubernetes-Diensten wie Kubelet, Kubernetes API-Server.
Anwendungslogs: Spezifische Log-Dateien, die von Anwendungen innerhalb von Containern geschrieben werden.

37.4.2 Aggregator

Ein Log-Aggregator sammelt Logs von verschiedenen Quellen und bereitet sie für die Speicherung vor. Beispiele sind:

Fluentd: Ein Open-Source-Datenkollektor, der Logs sammelt, transformiert und weiterleitet.
Fluent Bit: Eine leichtgewichtige Version von Fluentd, optimiert für minimalen Ressourcenverbrauch.
Logstash: Ein Datenverarbeitungstool, das Daten sammelt, filtert und transformiert.

37.4.3 Log Storage

Nach der Aggregation werden Logs in einem zentralen Speichersystem abgelegt. Beliebte Optionen sind:

Elasticsearch: Eine Such- und Analyse-Engine, die schnelle, skalierbare und flexible Speicherung bietet.
Amazon S3: Ein Cloud-Speicherdienst von Amazon, der für die Speicherung großer Mengen von Log-Daten verwendet werden kann.
Google Cloud Storage: Ein Cloud-Speicherdienst von Google, der ähnlich wie Amazon S3 funktioniert.

37.4.4 Visualization

Visualisierungswerkzeuge helfen dabei, die gesammelten Daten zu analysieren und verständlich darzustellen:

Kibana: Eine Web-Oberfläche für Elasticsearch, die Datenvisualisierung und Suchfunktionen bietet.
Grafana: Eine Open-Source-Plattform für Monitoring und Analyse, die auch die Visualisierung von Log-Daten unterstützt.
Splunk: Eine kommerzielle Lösung, die Datenindexierung, Suche, Analyse und Visualisierung bietet.

37.4.5 Beispiel einer Logging-Pipeline

Erfassung: Container schreiben stdout und stderr, die von einem Sidecar-Container oder einem Node-Agent wie Fluent Bit erfasst werden.
Aggregation: Fluent Bit leitet die Logs an einen zentralen Fluentd-Aggregator weiter, der die Daten filtert und bereinigt.
Speicherung: Fluentd sendet die aufbereiteten Logs an Elasticsearch, wo sie indiziert und gespeichert werden.
Analyse und Visualisierung: Kibana verbindet sich mit Elasticsearch, um die Daten zu visualisieren und Benutzern das Durchführen von Abfragen zu ermöglichen.

37.4.6 Wichtige Überlegungen

Skalierbarkeit: Die Pipeline muss mit dem Wachstum des Clusters skalieren können.
Fehlertoleranz: Sie sollte robust gegenüber Ausfällen sein und eine kontinuierliche Log-Erfassung gewährleisten.
Sicherheit: Zugriffskontrollen und Verschlüsselung sind notwendig, um die Integrität und Vertraulichkeit der Log-Daten zu schützen.
Compliance: Die Pipeline muss die Einhaltung von Compliance-Anforderungen wie GDPR oder HIPAA unterstützen.

37.5 Kubernetes Logging: Praktischer Leitfaden

37.5.1 Abrufen von Logs auf Cluster-Ebene

37.5.1.1 API-Server-Logs

API-Server-Logs sind essentiell, um die Aktionen zu verstehen, die auf dem Cluster ausgeführt wurden:

kubectl logs kube-apiserver-master -n kube-system

Beispieloutput:

I1104 19:00:00.123456 1 get.go:238] Reviewing request: /api/v1/namespaces/default/pods

37.5.1.2 Controller-Manager-Logs

Diese Logs sind nützlich, um die Arbeitsweise des Controllers zu beobachten:

kubectl logs kube-controller-manager-master -n kube-system

Beispiel output:

I1104 19:05:00.654321 1 replica_set.go:450] Too few replicas for ReplicaSet default/my-replicaset, need 2, creating 1

37.5.1.3 Scheduler-Logs

Scheduler-Logs helfen Ihnen, zu verstehen, wie und warum Pods auf bestimmte Knoten platziert werden:

kubectl logs kube-scheduler-master -n kube-system

Beispiel output:

I1104 19:10:00.789012 1 scheduler.go:207] Successfully assigned default/my-pod to worker-node1

37.5.1.4 Etcd-Logs

Etcd ist die konsistente und hochverfügbare Datenbank, die Kubernetes für alle Clusterdaten verwendet:

kubectl logs etcd-master -n kube-system

Beispiel output:

I1104 19:15:00.890123 1 snapshot.go:278] Saved snapshot at index 100000

37.5.2 Application-Level Logging

37.5.2.1 Container-Logs abrufen

Für das Debugging auf Anwendungsebene ist der Zugriff auf Container-Logs erforderlich:

kubectl logs <POD-NAME> -n <NAMESPACE>

Beispiel output:

2023-11-04T19:20:00.987654Z INFO Started POST "/api/v1/items"
2023-11-04T19:20:01.123456Z ERROR Failed to retrieve data: Timeout

37.5.2.2 Logs aller Container in einem Pod

Mit diesem Befehl erhalten Sie Logs von allen Containern in einem Pod:

kubectl logs <POD-NAME> -n <NAMESPACE> --all-containers=true

Beispiel output:

Container 1:
2023-11-04T19:25:00.345678Z INFO Accepting connections on port 8080

Container 2:
2023-11-04T19:25:00.456789Z WARN Memory usage is on the high side: 80% of limit

37.5.2.3 Logs mit journalctl

journalctl ermöglicht es Ihnen, systemd-journald-Ereignisse zu sehen, einschließlich der Logs von Container-Runtimes:

journalctl -u kubelet

Beispieloutput:

Nov 04 19:30:00 master-node kubelet[1234]: I1104 19:30:00.567890 kubelet.go:213] Starting kubelet main sync loop.

37.5.2.4 Logs aus /var/log

Direkter Zugriff auf Logdateien für ältere Systeme ohne systemd:

cat /var/log/kube-apiserver.log

Beispieloutput:

I1104 19:35:00.678901 server.go:154] Handling request: /api/v1/nodes

37.5.3 Persistente Log-Archivierung

37.5.3.1 Einrichten von Fluentd für die Log-Sammlung

Einrichten eines DaemonSets, das Fluentd auf allen Nodes installiert, um Logs zu sammeln:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
spec:
  ...

37.5.3.2 Einrichten von Elasticsearch zum Speichern der Logs

Elasticsearch als Backend zum Speichern und Indizieren der Logs:

apiVersion: v1
kind: Service
metadata:
  name: elasticsearch
  namespace: kube-system
spec:
  ...

37.5.3.3 Kibana für das Log-Monitoring verwenden

Kibana bietet eine Web-Oberfläche, um die in Elasticsearch gespeicherten Logs zu durchsuchen und zu visualisieren:

apiVersion: v1
kind: Service
metadata:
  name: kibana
  namespace: kube-system
spec:
  ...

37.5.4 Beispiel

Das nachfolgende Beispiel zeigt die Logfile Analyse eines Multicontainer PODS

kubectl get pods

NAME                 READY   STATUS    RESTARTS   AGE
webserver            2/2     Running   0          26h
log-app              2/2     Running   0          26h
redis-st-1           1/1     Running   0          26h
ambassador-example   2/2     Running   0          26h
redis-st-0           1/1     Running   0          26h

Mit folgendem Befehl werden die Logs des ersten Containers im POD gelesen.

kubectl logs webserver

Defaulted container "webserver" out of: webserver, adapter
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: can not modify /etc/nginx/conf.d/default.conf (read-only file system?)
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
.
.
.

In der Regel soll aber gezielt ein bestimmter Container angesprochen. Dazu wird erst per kubectl describe die Container ID herausgesucht.

kubectl describe pod/webserver

Name:             webserver
Namespace:        default
.
.
Containers:
  webserver:
    Container ID:   
    .
    .
  adapter:
    Container ID:  
    .
    .

Mit dem Kommando

kubectl logs pods/webserver -c webserver

wird auf die bereits bekannten Logs des webserver Container zugegriffen und mit dem Kommando

kubectl logs pods/webserver -c adapter

sind auch die Logfiles des zweiten Container erreichbar.

2023/11/04 10:39:52 Starting NGINX Prometheus Exporter Version=0.4.2 GitCommit=f017367
2023/11/04 10:39:53 NGINX Prometheus Exporter has successfully started

Der Logoutput kann dabei mit den üblichen Filterkommandos der verwendeten Shell reduziert werden und es stehen Filteroptionen des log Kommandos zur Verfügung.

Beispiel: Das folgende Kommando zeigt die Logging Einträge der vergangenen Stunde an:

kubectl logs pods/webserver -c adapter --since 1h

kubectl logs <pod-name> --since=<time>: Zeigt Logs seit einem bestimmten Zeitraum an (z.B. 1h für eine Stunde).

kubectl logs <pod-name> --tail=<number>: Zeigt die letzten <number> Zeilen des Logs.

kubectl logs <pod-name> --since-time=<RFC3339-timestamp>: Zeigt Logs seit einem exakten Zeitpunkt im RFC3339 Format.

kubectl logs <pod-name> --timestamps: Fügt jedem Logeintrag einen Zeitstempel hinzu.

kubectl logs <pod-name> -f: Streamt die Logs in Echtzeit (follow).

kubectl logs <pod-name> --previous: Zeigt Logs des zuletzt gestoppten Containers an.

kubectl logs <pod-name> -c <container-name> --limit-bytes=<number>: Begrenzt die Logausgabe auf eine bestimmte Anzahl von Bytes.

Reference

37.6 Kubernetes Logging im k3s Cluster

37.6.1 k3s Cluster-Level Logs

Für das Log-Management in einem k3s-Cluster, einer auf Edge, IoT und CI/Workloads spezialisierten, ressourcenschonenden Kubernetes-Distribution, ist Kenntnis der Systemkomponenten und korrekter Befehle notwendig. Diese ermöglichen eine effektive Überwachung des Clusterzustands und erlauben zeitnahe Eingriffe bei auftretenden Problemen.

37.6.1.1 Zustand der k3s Cluster-Komponenten prüfen

sudo k3s kubectl get pods -n kube-system

37.6.1.2 Logs von k3s Cluster-Komponenten abrufen

Server-Logs:
```
journalctl -u k3s
```
Agent-Logs:
```
journalctl -u k3s-agent
```

37.6.2 Node-Level Logs

Unter k3s sind die Node-Level Logs ähnlich denen eines traditionellen Kubernetes-Clusters:

System-Logs:
```
journalctl -xe
```
Docker-Logs:

k3s verwendet standardmäßig containerd, aber wenn Docker verwendet wird:
```
journalctl -u docker
```
Containerd-Logs:
```
journalctl -u k3s -f | grep containerd
```

37.6.3 Pod- und Container-Level Logs

Um Logs von Pods und Containern in einem k3s Cluster abzurufen, nutzen Sie das k3s-Äquivalent von kubectl:

Logs eines spezifischen Pods:

sudo k3s kubectl logs <POD-NAME> -n <NAMESPACE>

Stream Logs eines Pods:

sudo k3s kubectl logs -f <POD-NAME> -n <NAMESPACE>

Logs von allen Containern eines Pods:

sudo k3s kubectl logs <POD-NAME> -n <NAMESPACE> --all-containers=true

37.6.4 Persistente Logs

k3s unterstützt auch die Konfiguration von persistentem Logging. Logs können in einem Persistent Volume gespeichert oder an externe Logging-Dienste wie ELK Stack oder Splunk weitergeleitet werden.