GKE-Logs

Auf dieser Seite erhalten Sie eine Übersicht über die in Google Kubernetes Engine (GKE) verfügbaren Logging-Optionen.

Überblick

An Cloud Logging gesendete GKE-Logs werden in einem dedizierten, nichtflüchtigen Datenspeicher gespeichert. In GKE werden zwar eigene Logs gespeichert, die Speicherung dieser Logs ist aber nicht dauerhaft. Beispielsweise werden GKE-Containerlogs werden entfernt, wenn der jeweilige Host-Pod entfernt wird, wenn auf dem Laufwerk, auf dem sie gespeichert sind, nicht mehr genügend Speicherplatz vorhanden ist oder wenn sie durch neuere Logs ersetzt werden. Systemlogs werden regelmäßig gelöscht, um Platz für neue Logs zu schaffen. Clusterereignisse werden nach einer Stunde entfernt.

GKE-Logging-Agent

GKE bietet standardmäßig einen knotenspezifischen Logging-Agent, der Containerlogs liest, nützliche Metadaten hinzufügt und die Logs anschließend in Cloud Logging speichert. Der GKE-Logging-Agent sucht in den folgenden Quellen nach Containerlogs:

  • Standardausgabe- und Standardfehlerlogs aus containerisierten Prozessen

  • Kubelet- und Containerlaufzeitlogs

  • Logs für Systemkomponenten wie VM-Startskripts

Für Ereignisse nutzt GKE ein Deployment im Namespace kube-system, das Ereignisse automatisch erfasst und an Logging sendet.

Welche Logs erfasst werden

Standardmäßig erfasst GKE verschiedene Arten von Logs aus Ihrem Cluster und speichert diese in Cloud Logging:

  • Audit-Logs: Dazu gehören Administratoraktivitätslogs, Datenzugriffslogs und Ereignislogs. Ausführliche Informationen zu den Audit-Logs für GKE finden Sie in der Dokumentation zu Audit-Logs für GKE. Audit-Logs für GKE können nicht deaktiviert werden.

  • Systemlogs enthalten Logs aus den folgenden Quellen:

    • Alle Pods, die in den Namespaces kube-system, istio-system, knative-serving, gke-system und config-management-system ausgeführt werden.

    • Wichtige nicht containerbasierte Dienste, einschließlich docker/containerd-Laufzeit, kubelet, kubelet-monitor, node-problem-detector und kube-container-runtime-monitor.

    • Die Ausgabe serieller Ports des Knotens, wenn für serial-port-logging-enable der Metadaten der VM-Instanz der Wert "true" festgelegt ist. Mit GKE 1.16-13-gke.400 wird die Ausgabe des seriellen Ports für Knoten vom Logging-Agent erfasst. Wenn Sie das Logging der Ausgabe des seriellen Ports deaktivieren möchten, legen Sie beim Erstellen des Clusters --metadata serial-port-logging-enable=false fest. Die Ausgabe des seriellen Ports ist für die Fehlerbehebung bei Abstürzen, fehlgeschlagenen Startvorgängen, Startproblemen oder Problemen beim Herunterfahren von GKE-Knoten hilfreich. Durch Deaktivieren dieser Logs kann die Fehlerbehebung erschwert werden.

  • Anwendungslogs: Alle Logs, die von Nicht-System-Containern generiert wurden, die auf Nutzerknoten ausgeführt werden.

Optional kann GKE zusätzliche Arten von Logs aus bestimmten Komponenten der Kubernetes-Steuerungsebene erfassen und in Cloud Logging speichern:

  • API-Serverlogs: Alle vom Kubernetes API-Server generierten Logs (kube-apiserver).

  • Scheduler-Logs: Alle Logs, die vom Kubernetes-Planer (kube-scheduler) generiert werden.

  • Controller Manager-Logs: Alle Logs, die vom Kubernetes Controller Manager (kube-controller-manager) generiert werden.

Weitere Informationen zu den einzelnen Komponenten der Steuerungsebene finden Sie unter GKE-Clusterarchitektur.

Logs erfassen

Wenn Sie einen neuen GKE-Cluster erstellen, ist die Einbindung in Cloud Logging standardmäßig aktiviert.

System- und Anwendungslogs werden an den Logs Router in Cloud Logging gesendet.

Von dort können Logs in Cloud Logging aufgenommen, ausgeschlossen oder nach BigQuery, Pub/Sub oder Cloud Storage exportiert werden.

Ab GKE-Version 1.15.7 können Sie einen Standardcluster so konfigurieren, dass nur Systemlogs und keine Anwendungslogs erfasst werden. Sowohl bei Autopilot- als auch bei Standard-Clustern können Sie mit Ausschlussfiltern das Volumen der an Cloud Logging gesendeten Logs reduzieren.

Logging-Durchsatz

Wenn das System-Logging aktiviert ist, wird automatisch ein dedizierter Cloud Logging-Agent bereitgestellt und verwaltet. Dieser Agent wird auf allen GKE-Knoten in einem Cluster ausgeführt, um Logs zu erfassen, hilfreiche Metadaten zu Container, Pod und Cluster hinzuzufügen und die Logs dann mit einem fluentbit-basierten Agent an Cloud Logging zu senden.

Wenn ein GKE-Knoten mehr als den Standard-Logdurchsatz benötigt und Ihr GKE-Standardcluster eine Steuerungsebene der Version 1.23.13-gke.1000 oder höher verwendet, können Sie GKE so konfigurieren, dass eine alternative Konfiguration des Logging-Agent bereitgestellt wird, der den Logging-Durchsatz maximieren soll.

Weitere Informationen finden Sie unter Logdurchsatz anpassen.

Logerfassung mit benutzerdefinierter fluentd oder fluentbit

Der Standard-Logging-Agent von GKE bietet eine verwaltete Lösung zum Bereitstellen und Verwalten von Agents, die Logs für Ihre Cluster an Cloud Logging senden. Abhängig von der Version der GKE-Steuerungsebene werden entweder fluentd oder fluentbit zum Erfassen von Logs verwendet. Ab GKE 1.17 werden Logs mit einem fluentbit-basierten Agent erfasst. GKE-Cluster mit Versionen vor GKE 1.17 verwenden einen fluentd-basierten Agent. Wenn Sie das Standardverhalten der fluentd-Agenten ändern möchten, können Sie einen angepassten fluentd-Agent oder einen angepassten fluentbit-Agent ausführen.

Zu den häufigsten Anwendungsfällen gehören:

  • Entfernen vertraulicher Daten aus den Logs

  • Erfassen zusätzlicher Logs, die nicht in STDOUT oder STDERR geschrieben wurden

  • Verwenden bestimmter leistungsbezogener Einstellungen

  • Benutzerdefinierte Logformatierung

Linux-auditd-Logs für GKE-Knoten erfassen

Sie können ausführliche Audit-Logs für Betriebssysteme auf GKE-Knoten aktivieren, auf denen Container-Optimized OS ausgeführt wird. Betriebssystemlogs auf den Knoten liefern wertvolle Informationen über den Status Ihres Clusters und der Arbeitslasten, z. B. Fehlermeldungen, Anmeldeversuche und binäre Ausführungen. Sie können diese Informationen verwenden, um Probleme zu beheben oder Sicherheitsvorfälle zu untersuchen.

Weitere Informationen finden Sie unter Linux-Audit-Logs für GKE-Knoten aktivieren.

GKE-Audit-Logs

Ausführliche Informationen zu Logeinträgen für die Ressourcentypen Kubernetes-Cluster und GKE-Clustervorgänge finden Sie unter Audit-Logging.

Zugriffssteuerung für Logging

Es gibt zwei Bereiche der Zugriffssteuerung für Anwendungen: Anwendungszugriff und Nutzerzugriff. Cloud Logging bietet IAM-Rollen (Identity and Access Management), mit denen Sie den entsprechenden Zugriff gewähren können.

Anwendungszugriff

Anwendungen benötigen Berechtigungen zum Schreiben von Logs in Cloud Logging. Dazu wird dem Dienstkonto, das mit dem zugrunde liegenden Knotenpool verknüpft ist, die IAM-Rolle roles/logging.logWriter zugewiesen.

Lesezugriff für Nutzer

Zur Anzeige von Logs in Ihrem Projekt benötigen Sie die Rolle roles/logging.viewer. Für den Zugriff auf die Datenzugriffslogs ist die IAM-Berechtigung logging.privateLogViewer erforderlich.

Weitere Informationen zu Berechtigungen und Rollen finden Sie im Leitfaden zur Zugriffssteuerung. Weitere Informationen finden Sie unter Best Practices für Cloud-Audit-Logging, die auch allgemein für Cloud Logging gelten.

Administratorzugriff für Nutzer

Die IAM-Rollen roles/logging.configWriter und roles/logging.admin stellen die administrativen Funktionen bereit. Die IAM-Rolle roles/logging.configWriter ist erforderlich, um eine Logging-Senke zu erstellen, die in der Regel zum Weiterleiten Ihrer Logs an ein bestimmtes oder zentrales Projekt verwendet wird. Sie können beispielsweise eine Logging-Senke zusammen mit einem Logging-Filter verwenden, um alle Logs für einen Namespace an einen zentralen Logging-Bucket weiterzuleiten.

Weitere Informationen finden Sie im Leitfaden zur Zugriffssteuerung für Cloud Logging.

Best Practices

  • Strukturiertes Logging: Der in GKE integrierte Logging-Agent liest JSON-Dokumente, die in einzeilige Strings serialisiert und in die Standardausgabe oder den Standardfehler geschrieben wurden, und sendet sie in Google Cloud Observability als strukturierte Logeinträge.
    • Weitere Informationen zur Arbeit mit einem integrierten Logging-Agent finden Sie unter Strukturiertes Logging.
    • Sie können Erweiterte Logfilter verwenden, um Logs anhand der Felder des JSON-Dokuments zu filtern.
    • Bei mit glog generierten Logs werden die üblichen Felder geparst, z. B. severity, pid, source_file, source_line. Die eigentliche Nachrichtennutzlast wird jedoch nicht geparst und erscheint unverändert in der daraus resultierenden Lognachricht in Google Cloud Observability.
  • Schweregrad: In die Standardausgabe geschriebene Logs befinden sich auf der Ebene INFO und in den Standardfehlerkanal geschriebene Logs befinden sich auf der Ebene ERROR. Strukturierte Logs können ein severity-Feld enthalten, das den Schweregrad des Logs festlegt.
  • Exportieren nach BigQuery: Für weitere Analysen können Sie Logs in externe Dienste wie BigQuery oder Pub/Sub exportieren. Das Format und die Struktur von Logs, die nach BigQuery exportiert wurden, wird beibehalten. Weitere Informationen finden Sie unter Routing und Speicher.
  • Benachrichtigungen: Wenn Logging unerwartetes Verhalten protokolliert, können Sie mithilfe von logbasierten Messwerten Benachrichtigungsrichtlinien einrichten. Ein Beispiel finden Sie unter Benachrichtigungsrichtlinie für einen Zählermesswert erstellen. Ausführliche Informationen zu logbasierten Messwerten finden Sie unter Übersicht zu logbasierten Messwerten.
  • Fehlerberichte: Um Fehler aus Anwendungen zu erfassen, die auf Ihren Clustern ausgeführt werden, können Sie Error Reporting verwenden.

Logs der Steuerungsebene

Sie können einen GKE-Cluster so konfigurieren, dass Logs, die vom Kubernetes API-Server, vom Planer und vom Controller-Manager ausgegeben werden, an Cloud Logging gesendet werden.

Voraussetzungen

Zum Senden von Logs, die von Komponenten der Kubernetes-Steuerungsebene an Cloud Logging ausgegeben werden, ist die GKE-Steuerungsebene 1.22.0 oder höher erforderlich. Außerdem muss die Erfassung von Systemlogs aktiviert sein.

Erfassung von Logs der Steuerungsebene konfigurieren

Weitere Informationen finden Sie in der Anleitung zum Konfigurieren der Logging-Unterstützung für einen neuen Cluster oder für einen vorhandenen Cluster.

Preise

Logs der GKE-Steuerungsebene werden nach Cloud Logging exportiert. Es gelten die Cloud Logging-Preise.

Kontingent

Logs der Steuerungsebene verbrauchen das Kontingent „Schreibanfragen pro Minute” der Cloud Logging API. Bevor Sie Logs auf Steuerungsebene aktivieren, prüfen Sie die letzte Spitzennutzung dieses Kontingents. Wenn sich viele Cluster im selben Projekt befinden oder sich dem Limit dieses Kontingents nähern, können Sie eine Erhöhung des Kontingentlimits beantragen, bevor Sie Logs der Steuerungsebene aktivieren.

Zugriffssteuerung

Wenn Sie den Zugriff in Ihrer Organisation auf Logs der Steuerungsebene von Kubernetes beschränken möchten, können Sie einen separaten Log-Bucket mit eingeschränkteren Zugriffssteuerungen erstellen.

Wenn Sie sie in einem separaten Log-Bucket mit eingeschränktem Zugriff speichern, sind Logs der Steuerungsebene im Log-Bucket nicht automatisch für Nutzer mit roles/logging.viewer-Zugriff auf das Projekt zugänglich. Wenn Sie bestimmte Logs der Steuerungsebene aus Datenschutz- oder Sicherheitsgründen löschen möchten, können Sie diese Logs außerdem in einem separaten Log-Bucket mit eingeschränktem Zugriff löschen, ohne dass dies Auswirkungen auf Logs aus anderen Komponenten oder Diensten hat.