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.
Systemprotokolle, einschließlich der Protokolle, die in den verfügbaren Protokollen aufgeführt sind.
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.
Sie können einen Standardcluster auch so konfigurieren, dass nur Systemprotokolle und keine Anwendungsprotokolle erfasst werden. Sowohl für Autopilot- als auch für Standardcluster 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. Logs werden mit einem fluentbit-basierten Agent erfasst.
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. Außerdem empfehlen wir die Best Practices für Cloud-Audit-Logs, 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
INFOund in den Standardfehlerkanal geschriebene Logs befinden sich auf der EbeneERROR. Strukturierte Logs können einseverity-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 – Übersicht.
- 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.
Verfügbare Logs
Wenn Sie Logs an Cloud Logging senden, müssen Sie Systemlogs senden. Optional können Sie auch Logs aus zusätzlichen Quellen senden.
In der folgenden Tabelle sind die unterstützten Werte für das Flag --logging der Befehle create und update aufgeführt.
| Logquelle | --logging-Wert |
Erfasste Logs |
|---|---|---|
| Keine | NONE |
Keine an Cloud Logging gesendeten Logs; im Cluster ist kein Agent für die Logerfassung installiert. Dieser Wert wird für Autopilot-Cluster nicht unterstützt. |
| System | SYSTEM |
Erfasst Logs aus folgenden Quellen:
Erfasst auch Kubernetes-Ereignisse. Dieser Wert ist für alle Clustertypen erforderlich. |
| Arbeitslasten | WORKLOAD |
Alle Logs, die von Nicht-System-Containern generiert werden, die auf Nutzerknoten ausgeführt werden. Dieser Wert ist standardmäßig aktiviert, aber für alle Clustertypen optional. |
| API-Server | API_SERVER |
Alle von kube-apiserver generierten Logs. Dieser Wert ist für alle Clustertypen optional.
|
| Planer | SCHEDULER |
Alle von kube-scheduler generierten Logs. Dieser Wert ist für alle Clustertypen optional.
|
| Controller-Manager | CONTROLLER_MANAGER |
Alle von kube-controller-manager generierten Logs. Dieser Wert ist für alle Clustertypen optional.
|
Standardmäßig in GKE Enterprise aktivierte Logs
Wenn Sie einen neuen GKE-Cluster in Google Cloud erstellen, sind Arbeitslastlogs standardmäßig für alle Autopilot-Cluster aktiviert, können jedoch deaktiviert werden. Wir raten davon ab, Arbeitslastlogs aufgrund der Auswirkungen auf den Support zu deaktivieren.
Für Projekte der GKE Enterprise-Version sind standardmäßig zusätzliche nützliche Logs aktiviert, wenn Sie sich beim Erstellen des Clusters in einer Flotte registrieren.
) darauf hin, welche Logs standardmäßig aktiviert sind, wenn Sie einen neuen Cluster in einem Projekt mit aktiviertem GKE Enterprise erstellen und registrieren:
| Logname | Autopilot | Standard |
|---|---|---|
| System | ||
| Arbeitslasten | - | |
| API-Server | ||
| Planer | ||
| Controller-Manager |
Für die Logs der Steuerungsebene (API-Server, Planer und Controller Manager) fallen Cloud Logging-Gebühren an.
Preise
Logs der GKE-Steuerungsebene werden nach Cloud Logging exportiert. Es gelten die Preise für Cloud Logging.
Wenn Sie Logs in einen anderen Google Cloud-Dienst wie BigQuery exportieren, werden Ihnen die anfallenden Speicherkosten in Rechnung gestellt. Die Kosten für Cloud Logging finden Sie unter 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.