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:
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:
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:
Um ein effektives Logging-System in Kubernetes zu implementieren, sollten folgende Best Practices beachtet werden:
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:
Die Daten für das Application Level Logging werden oft wie folgt vorgehalten:
Die Quelle der Log-Daten in einem Kubernetes-Cluster sind typischerweise:
Ein Log-Aggregator sammelt Logs von verschiedenen Quellen und bereitet sie für die Speicherung vor. Beispiele sind:
Nach der Aggregation werden Logs in einem zentralen Speichersystem abgelegt. Beliebte Optionen sind:
Visualisierungswerkzeuge helfen dabei, die gesammelten Daten zu analysieren und verständlich darzustellen:
API-Server-Logs sind essentiell, um die Aktionen zu verstehen, die auf dem Cluster ausgeführt wurden:
kubectl logs kube-apiserver-master -n kube-systemBeispieloutput:
I1104 19:00:00.123456 1 get.go:238] Reviewing request: /api/v1/namespaces/default/podsDiese Logs sind nützlich, um die Arbeitsweise des Controllers zu beobachten:
kubectl logs kube-controller-manager-master -n kube-systemBeispiel output:
I1104 19:05:00.654321 1 replica_set.go:450] Too few replicas for ReplicaSet default/my-replicaset, need 2, creating 1Scheduler-Logs helfen Ihnen, zu verstehen, wie und warum Pods auf bestimmte Knoten platziert werden:
kubectl logs kube-scheduler-master -n kube-systemBeispiel output:
I1104 19:10:00.789012 1 scheduler.go:207] Successfully assigned default/my-pod to worker-node1Etcd ist die konsistente und hochverfügbare Datenbank, die Kubernetes für alle Clusterdaten verwendet:
kubectl logs etcd-master -n kube-systemBeispiel output:
I1104 19:15:00.890123 1 snapshot.go:278] Saved snapshot at index 100000Fü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: TimeoutMit diesem Befehl erhalten Sie Logs von allen Containern in einem Pod:
kubectl logs <POD-NAME> -n <NAMESPACE> --all-containers=trueBeispiel 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 limitjournalctl ermöglicht es Ihnen,
systemd-journald-Ereignisse zu sehen, einschließlich der Logs von
Container-Runtimes:
journalctl -u kubeletBeispieloutput:
Nov 04 19:30:00 master-node kubelet[1234]: I1104 19:30:00.567890 kubelet.go:213] Starting kubelet main sync loop.Direkter Zugriff auf Logdateien für ältere Systeme ohne systemd:
cat /var/log/kube-apiserver.logBeispieloutput:
I1104 19:35:00.678901 server.go:154] Handling request: /api/v1/nodesEinrichten eines DaemonSets, das Fluentd auf allen Nodes installiert, um Logs zu sammeln:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd
namespace: kube-system
spec:
...Elasticsearch als Backend zum Speichern und Indizieren der Logs:
apiVersion: v1
kind: Service
metadata:
name: elasticsearch
namespace: kube-system
spec:
...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:
...Das nachfolgende Beispiel zeigt die Logfile Analyse eines Multicontainer PODS
kubectl get podsNAME 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 26hMit folgendem Befehl werden die Logs des ersten Containers im POD gelesen.
kubectl logs webserverDefaulted 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/webserverName: webserver
Namespace: default
.
.
Containers:
webserver:
Container ID:
.
.
adapter:
Container ID:
.
.Mit dem Kommando
kubectl logs pods/webserver -c webserverwird auf die bereits bekannten Logs des webserver Container zugegriffen und mit dem Kommando
kubectl logs pods/webserver -c adaptersind 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 startedDer 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 1hkubectl 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.
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.
sudo k3s kubectl get pods -n kube-systemServer-Logs:
journalctl -u k3sAgent-Logs:
journalctl -u k3s-agentUnter k3s sind die Node-Level Logs ähnlich denen eines traditionellen Kubernetes-Clusters:
System-Logs:
journalctl -xeDocker-Logs:
k3s verwendet standardmäßig containerd, aber wenn Docker verwendet wird:
journalctl -u dockerContainerd-Logs:
journalctl -u k3s -f | grep containerdUm 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=truek3s 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.