GKE-Logs verwalten

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

Überblick

Wenn Sie die Einbindung von Cloud Operations for GKE in Cloud Logging und Cloud Monitoring für Ihren Cluster aktivieren, werden Ihre Logs in einem dedizierten nichtflüchtigen Datenspeicher abgelegt. 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 bietet standardmäßig einen knotenspezifischen Logging-Agent für Container- und Systemlogs. Dieser liest Containerlogs, fügt nützliche Metadaten hinzu und speichert sie anschließend. Der 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 Logs für Ihre auf dem Cluster bereitgestellten System- und Anwendungsarbeitslasten.

  • Systemlogs: Diese Logs enthalten die Audit-Logs für den Cluster, einschließlich des Administratoraktivitätslogs, des Datenzugriffslogs und des Ereignislogs. Ausführliche Informationen zu den Audit-Logs für GKE finden Sie in der Dokumentation zu Audit-Logs für GKE. Einige Systemlogs werden als Container ausgeführt, z. B. für kube-system. Informationen dazu finden Sie im Abschnitt Sammlung Ihrer Anwendungslogs steuern.

  • Anwendungslogs: Kubernetes-Container erfassen Logs für Ihre Arbeitslasten, die nach STDOUT und STDERR geschrieben werden.

Logs erfassen

Beim Erstellen eines neuen GKE-Clusters ist die Cloud Operations for GKE-Einbindung in Cloud Logging und Cloud Monitoring standardmäßig aktiviert.

Für Legacy-Cloud Logging folgen Sie der Dokumentation zum Aktivieren oder Deaktivieren der Logging-Einbindung.

Standardeinstellungen für Logging

Wenn aktiviert, wird ein dedizierter Agent automatisch bereitgestellt und verwaltet. Dieser wird auf dem GKE-Knoten ausgeführt, um Logs zu erfassen, hilfreiche Metadaten zu Container, Pod und Cluster hinzuzufügen und die Logs dann an Cloud Logging zu senden. Sowohl Systemlogs als auch die Anwendungslogs Ihrer Arbeitslast werden dann an den Logs Router in Cloud Logging übertragen.

Von dort werden Logs entweder in Cloud Logging übernehmen oder davon ausgeschlossen. Der Logs Router bietet auch einen optionalen Schritt zum Exportieren Ihrer Logs nach BigQuery, Pub/Sub oder Cloud Storage.

Logsammlung für ausschließliche Erfassung von Systemlogs anpassen

Ab der GKE-Version 1.15.7 können Sie Cloud Operations for GKE so konfigurieren, dass nur Systemlogs und keine Anwendungslogs erfasst werden.

Logsammlung mit benutzerdefiniertem fluentd

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. Wenn Sie das Standardverhalten der fluentd-Agents ändern möchten, können Sie einen benutzerdefinierten fluentd-Agent ausführen.

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

  • Entfernen vertraulicher Daten aus den Logs

  • Erfassen zusätzlicher Logs, die nicht nach STDOUT oder STDERR geschrieben werden

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

Sie können ausführliche Audit-Logs für Betriebssysteme auf Google Kubernetes Engine-Knoten aktivieren, auf denen Container-Optimized OS ausgeführt wird. Betriebssystemlogs auf Ihren Knoten enthalten wertvolle Informationen zum Status Ihres Clusters und Ihrer Arbeitslasten, z. B. Fehlermeldungen, Anmeldeversuche und Binärausführungen. Sie können mit diesen Informationen Probleme beheben oder Sicherheitsvorfälle 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, mit denen Sie den entsprechenden Zugriff gewähren können.

Anwendungszugriff

Anwendungen benötigen die Berechtigung zum Schreiben von Logs. Diese wird durch Zuweisung der IAM-Rolle roles/logging.logWriter an das Dienstkonto für eine Anwendung erteilt. Wenn Sie einen GKE-Cluster erstellen, ist die Rolle roles/logging.logWriter standardmäßig aktiviert.

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. Außerdem empfehlen wir das Dokument Best Practices für Cloud-Audit-Logs, das auch allgemein für Cloud Logging hilfreich ist.

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: In die Standardausgabe oder in den Standardfehlerkanal geschriebene einzeilige JSON-Strings werden als strukturierte Logeinträge in die Operations-Suite von Google Cloud eingelesen. Weitere Informationen finden Sie unter Strukturiertes Logging. Sie können Erweiterte Logfilter verwenden, um Logs anhand ihrer Felder zu filtern.
  • Schweregrad: In die Standardausgabe geschriebene Logs befinden sich auf der Ebene "INFO" und in den Standardfehlerkanal geschriebene Logs befinden sich auf der Ebene "FEHLER". Strukturierte Logs können ein severity-Feld enthalten, das die Wichtigkeit des Logs festlegt.
  • Exportieren nach BigQuery: Sie können Logs exportieren, um zusätzliche Analysen auszuführen – z. B. in externen Diensten wie BigQuery oder Pub/Sub. Das Format und die Struktur von nach BigQuery exportierten Logs wird beibehalten. Weitere Informationen finden Sie unter Übersicht über Logexporte.
  • Benachrichtigungen: Sie können logbasierte Messwerte verwenden, um Benachrichtigungsrichtlinien für den Fall festzulegen, dass Logging unerwartetes Verhalten protokolliert. Ein Beispiel finden Sie unter Einfache Benachrichtigungsrichtlinie für einen Zählermesswert erstellen. Ausführliche Informationen zu logbasierten Messwerten finden Sie unter Übersicht zu logbasierten Messwerten.
  • Error Reporting: Sie können Error Reporting verwenden, um Fehler zu erfassen, die in den Clustern auftreten.