Moderne Microservice-Architekturen beschleunigen die Anwendungsentwicklung und -bereitstellung in Cloud-Umgebungen, doch die Gewährleistung der Beobachtbarkeit dieser verteilten Strukturen stellt eine erhebliche Herausforderung dar. Insbesondere die Protokollverwaltung ist entscheidend, um das Verhalten einer Anwendung zu verstehen, Probleme zu diagnostizieren und Leistungsengpässe zu identifizieren. Traditionelle Ansätze beinhalten oft den direkten Export von Protokollen aus dem Hauptanwendungscontainer, was jedoch die Verantwortlichkeiten der Anwendung erhöhen und die Flexibilität verringern kann.

In diesem Leitfaden werden wir das leistungsstarke Sidecar-Container-Muster untersuchen, ein weit verbreitetes Designmuster in Kubernetes-Umgebungen. Das Sidecar-Muster lagert eine Kernverantwortung des Hauptanwendungscontainers (z. B. die Protokollsammlung) in einen separaten Container aus, wodurch Anwendungen sauberer, modularer und besser verwaltbar werden. Dies ermöglicht es uns, den Mechanismus zur Protokollsammlung und -weiterleitung unabhängig von der Anwendung zu aktualisieren und zu verwalten.

Was ist das Sidecar-Container-Muster und warum sollte es für die Protokollverwaltung verwendet werden?

Das Sidecar-Muster bezieht sich auf einen Hilfscontainer, der neben dem Hauptanwendungscontainer innerhalb eines Pods läuft. Da dieser Hilfscontainer im selben Pod wie der Hauptcontainer läuft, teilt er sich dieselben Netzwerk- und Speicherressourcen. Diese Funktion ermöglicht es dem Sidecar, die Ausgabe der Hauptanwendung leicht zu erfassen oder mit ihr zu interagieren.

Speziell für die Protokollverwaltung bietet ein Sidecar-Container folgende Vorteile:

• Trennung der Anliegen (Separation of Concerns): Die einzige Verantwortung der Hauptanwendung ist die Ausführung der Geschäftslogik, während die Aufgabe der Protokollsammlung und -weiterleitung an den Sidecar delegiert wird.
• Flexibilität und unabhängige Updates: Der Protokollsammlungsagent (Sidecar) kann unabhängig von der Hauptanwendung aktualisiert oder ersetzt werden. Dies ermöglicht Änderungen in den Protokollstrategien, ohne die Anwendung selbst neu kompilieren oder bereitstellen zu müssen.
• Standardisierung: Sie können den Protokollsammlungsprozess über alle Anwendungen hinweg standardisieren, indem Sie dasselbe Sidecar-Image verwenden.
• Zentrale Protokollverwaltungsintegration: Der Sidecar kann so konfiguriert werden, dass er gesammelte Protokolle an ein zentrales Protokollverwaltungssystem (z. B. Elasticsearch, Loki, Splunk usw.) sendet.

Praktische Anwendung: Protokollsammlungs-Sidecar mit Fluent Bit in Kubernetes

Kommen wir nun zu einem praktischen Beispiel, das demonstriert, wie Protokolle einer einfachen Nginx-Anwendung mit einem Fluent Bit-basierten Sidecar-Container gesammelt und verarbeitet werden. In diesem Beispiel schreibt Nginx seine Protokolle in ein gemeinsam genutztes Volume, und der Fluent Bit Sidecar liest diese Protokolle und leitet sie an seine eigene Standardausgabe (stdout) weiter. In einem realen Szenario würde Fluent Bit die Protokolle an Kafka, Elasticsearch oder eine andere Protokollsenke senden.

1. Erstellen eines EmptyDir-Volumes für die Protokollfreigabe

Die Hauptanwendung (Nginx) benötigt ein Verzeichnis zum Schreiben von Protokollen, und der Sidecar liest diese Protokolle aus demselben Verzeichnis. Wir können hierfür ein emptyDir-Volume verwenden.

2. Definition der Nginx-Anwendung und des Fluent Bit Sidecar-Containers

Die untenstehende Kubernetes-Deployment-Definition enthält einen Nginx-Hauptanwendungscontainer und einen Fluent Bit Sidecar-Container zum Sammeln von Protokollen. Fluent Bit ist so konfiguriert, dass es Protokolle liest, die Nginx in das Verzeichnis /var/log/nginx schreibt.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-with-log-sidecar
  labels:
    app: nginx-logging
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-logging
  template:
    metadata:
      labels:
        app: nginx-logging
    spec:
      volumes:
        - name: nginx-logs
          emptyDir: {}
        - name: fluentbit-config
          configMap:
            name: fluentbit-log-sidecar-config
      containers:
        - name: nginx-app
          image: nginx:latest
          ports:
            - containerPort: 80
          volumeMounts:
            - name: nginx-logs
              mountPath: /var/log/nginx # Nginx wird Protokolle hier schreiben
          lifecycle:
            postStart:
              exec:
                command: ["/bin/sh", "-c", "while true; do echo \"$(date) Nginx access log entry\" >> /var/log/nginx/access.log; sleep 5; done"]
        - name: fluentbit-sidecar
          image: fluent/fluent-bit:latest
          command: ["fluent-bit", "-c", "/fluent-bit/etc/fluent-bit.conf"]
          volumeMounts:
            - name: nginx-logs
              mountPath: /var/log/nginx
            - name: fluentbit-config
              mountPath: /fluent-bit/etc/fluent-bit.conf
              subPath: fluent-bit.conf
          resources:
            limits:
              memory: "64Mi"
              cpu: "100m"
            requests:
              memory: "32Mi"
              cpu: "50m"

3. Fluent Bit Konfiguration (ConfigMap)

Wir müssen eine ConfigMap für die Fluent Bit-Konfigurationsdatei erstellen, die definiert, wie Fluent Bit Protokolle liest und verarbeitet. Diese ConfigMap wird vom fluentbit-config-Volume im obigen Deployment verwendet.

apiVersion: v1
kind: ConfigMap
metadata:
  name: fluentbit-log-sidecar-config
data:
  fluent-bit.conf: |
    [SERVICE]
        Flush        1
        Log_Level    info
        Daemon       off
        Parsers_File parsers.conf

    [INPUT]
        Name        tail
        Path        /var/log/nginx/access.log # Pfad zur Nginx-Protokolldatei
        Tag         nginx_access_log
        Read_from_Head true

    [OUTPUT]
        Name   stdout
        Match  *

Die obige Fluent Bit Konfiguration:

• Der Abschnitt [INPUT] überwacht kontinuierlich (tail) die Datei /var/log/nginx/access.log.
• Der Abschnitt [OUTPUT] leitet die gelesenen Protokolle an die Standardausgabe des Fluent Bit-Containers um. So können Sie die Protokolle mit dem Befehl kubectl logs <pod-name> -c fluentbit-sidecar einsehen.

Funktionsweise

Wenn Sie diese Konfiguration auf Ihrem Kubernetes-Cluster anwenden:

1. Ein Pod wird erstellt.
2. Innerhalb dieses Pods starten sowohl der Nginx-Container als auch der Fluent Bit Sidecar-Container.
3. Der Nginx-Container beginnt, Protokolle in die Datei /var/log/nginx/access.log zu schreiben.
4. Der Fluent Bit Sidecar überwacht die Datei /var/log/nginx/access.log im selben gemeinsamen Volume.
5. Er liest neue Protokolleinträge und leitet sie an seine Standardausgabe um.

Um dies zu überprüfen, können Sie den folgenden Befehl mit dem Pod-Namen ausführen:

kubectl logs <nginx-with-log-sidecar-POD_ID> -c fluentbit-sidecar

In der Ausgabe sehen Sie die von Nginx erzeugten Protokolleinträge. Dies zeigt an, dass der Sidecar die Protokolle erfolgreich gesammelt und verarbeitet hat.

Erweiterte Szenarien und Best Practices

• Ressourcenverwaltung: Das Festlegen von CPU- und Speicherlimits für Sidecar-Container ist wichtig, um die Ressourcennutzung der Hauptanwendung nicht zu beeinträchtigen. Leichtgewichtige Agenten wie Fluent Bit verbrauchen in der Regel wenig Ressourcen.
• Ausfallsicherheit: Stellen Sie sicher, dass die Hauptanwendung weiterhin läuft, wenn der Sidecar einen Fehler aufweist. Im Allgemeinen sollten Sidecar-Probleme die Hauptanwendung nicht stoppen.
• Hot Reload: Einige Sidecar-Agenten unterstützen das „Hot Reloading“ bei Konfigurationsänderungen, ohne dass der Container neu gestartet werden muss.
• Komprimierung und Verschlüsselung: Protokolle können sensible Informationen enthalten. Das Anwenden von Komprimierung und Verschlüsselung vor dem Senden an ein zentrales System schont die Bandbreite und erhöht die Sicherheit.

Fazit

Das Sidecar-Container-Muster in Kubernetes bietet eine elegante und effektive Möglichkeit, übergreifende Anliegen wie die Protokollverwaltung von Ihrer Hauptanwendung zu trennen. Dieser Ansatz verbessert die Beobachtbarkeit in Ihren Microservice-Architekturen, hält Ihren Anwendungscode sauberer und macht Ihre Protokollsammlungsinfrastruktur flexibler. Mit dem praktischen Beispiel in diesem Leitfaden können Sie dieses Muster problemlos in Ihren eigenen Cloud-nativen Anwendungen implementieren und Ihre betriebliche Effizienz steigern.