À propos des journaux GKE

Autopilot Standard

---

Cette page présente les options de journalisation disponibles dans Google Kubernetes Engine (GKE).

Présentation

Les journaux GKE envoyés à Cloud Logging sont stockés dans un datastore persistant dédié. GKE, à proprement parler, peut certes conserver des journaux, mais ceux-ci ne sont pas stockés de manière permanente. Ainsi, les journaux des conteneurs GKE sont supprimés lorsque leur pod hôte est supprimé, lorsque le disque sur lequel ils sont stockés manque d'espace ou lorsqu'ils sont remplacés par des journaux plus récents. Les journaux système sont régulièrement supprimés afin de libérer de l'espace pour les nouveaux journaux. Les événements de cluster sont supprimés au bout d'une heure.

Agent de journalisation GKE

Pour les journaux de conteneurs et les journaux système, GKE déploie par défaut un agent de journalisation par nœud qui lit les journaux de conteneurs, ajoute des métadonnées utiles, puis les stocke dans Cloud Logging. L'agent de journalisation recherche les journaux de conteneurs dans les sources suivantes :

• Journaux de sortie et d'erreur standards des processus conteneurisés

• Journaux d'exécution de kubelet et du conteneur

• Journaux des composants système, tels que les scripts de démarrage de VM

Pour les événements, GKE utilise un déploiement dans l'espace de noms kube-system qui collecte automatiquement les événements et les envoie vers Logging.

Remarque : Le déploiement de l'exportateur d'événements dans GKE fonctionne selon un principe d'optimisation. Les événements Kubernetes peuvent ne pas capturer tous les événements. Pour résoudre les problèmes, nous vous recommandons d'utiliser vos journaux et métriques, en plus de vos événements Kubernetes.

Journaux collectés

Par défaut, GKE collecte plusieurs types de journaux à partir de votre cluster et les stocke dans Cloud Logging :

• Les journaux d'audit incluent le journal des activités d'administration, le journal d'accès aux données et le journal des événements. Pour plus d'informations sur les journaux d'audit pour GKE, consultez la documentation Journaux d'audit pour GKE. Les journaux d'audit pour GKE ne peuvent pas être désactivés.

• Les journaux système, y compris les journaux listés dans les journaux disponibles.

• Les journaux d'application incluent tous les journaux générés par des conteneurs non système s'exécutant sur des nœuds utilisateur.

Si vous le souhaitez, GKE peut collecter des types de journaux supplémentaires à partir de certains composants du plan de contrôle Kubernetes et les stocker dans Cloud Logging :

• Les journaux du serveur d'API incluent tous les journaux générés par le serveur d'API Kubernetes (kube-apiserver).

• Les journaux du programmeur incluent tous les journaux générés par le programmeur Kubernetes (kube-scheduler).

• Les journaux du gestionnaire de contrôleurs incluent tous les journaux générés par le gestionnaire de contrôleurs Kubernetes (kube-controller-manager).

Pour en savoir plus sur chacun de ces composants du plan de contrôle, consultez la page Architecture d'un cluster GKE.

Collecter vos journaux

Lorsque vous créez un cluster GKE, l'intégration à Cloud Logging est activée par défaut.

Les journaux système et d'application sont envoyés au routeur de journaux dans Cloud Logging.

Les journaux peuvent ensuite être ingérés dans Cloud Logging, exclus, ou exportés vers BigQuery, Pub/Sub ou Cloud Storage.

Vous pouvez également configurer un cluster standard pour ne capturer que les journaux système et non les journaux d'application. Pour les clusters Autopilot et Standard, les filtres d'exclusion vous permettent de réduire le volume de journaux envoyés à Cloud Logging.

Débit de journalisation

Lorsque la journalisation système est activée, un agent Cloud Logging dédié est automatiquement déployé et géré. Il s'exécute sur tous les nœuds GKE d'un cluster pour collecter les journaux, ajoute des métadonnées utiles sur le conteneur, le pod et le cluster, puis envoie les journaux à Cloud Logging à l'aide d'un agent basé sur fluentbit.

Si l'un des nœuds GKE nécessite un débit de journalisation supérieur par défaut et que votre cluster GKE Standard utilise le plan de contrôle version 1.23.13-gke.1000 ou ultérieure, vous pouvez configurer GKE pour déployer une une configuration alternative de l'agent Logging conçue pour maximiser le débit de journalisation.

Pour en savoir plus, consultez Ajuster le débit des journaux.

Collecter des journaux avec l'agent fluentd ou fluentbit personnalisé

L'agent de journalisation par défaut de GKE fournit une solution gérée pour déployer et gérer les agents qui envoient les journaux de vos clusters à Cloud Logging. Les journaux sont collectés à l'aide d'un agent basé sur fluentbit.

Collecter des journaux Linux auditd pour les nœuds GKE

Vous pouvez activer les journaux d'audit détaillés du système d'exploitation sur les nœuds GKE exécutant Container-Optimized OS. Les journaux du système d'exploitation sur vos nœuds fournissent de précieuses informations sur l'état de votre cluster et de vos charges de travail, par exemple des messages d'erreur, des tentatives de connexion et des exécutions de binaires. Ces informations peuvent servir à résoudre des problèmes ou à mener des investigations sur des incidents de sécurité.

Pour en savoir plus, consultez la page Activer les journaux d'audit Linux sur les nœuds GKE.

Journaux d'audit GKE

Pour en savoir plus sur les entrées de journal qui s'appliquent aux types de ressources "Cluster Kubernetes" et "Opérations du cluster GKE", consultez la page Journaux d'audit.

Contrôle d'accès à la journalisation

Il existe deux aspects du contrôle d'accès à la journalisation : l'accès aux applications et l'accès des utilisateurs. Cloud Logging définit des rôles IAM (Identity and Access Management) que vous pouvez utiliser pour accorder un accès approprié.

Accès aux applications

Les applications ont besoin d'autorisations pour écrire des journaux dans Cloud Logging, ce qui est accordé en attribuant le rôle IAM roles/logging.logWriter au compte de service associé au pool de nœuds sous-jacent.

Accès en lecture des utilisateurs

Vous devez disposer du rôle roles/logging.viewer pour lire les journaux de votre projet. Si vous devez avoir accès aux journaux d'accès aux données, vous devez disposer de l'autorisation IAM logging.privateLogViewer.

Pour en savoir plus sur les autorisations et les rôles, accédez au guide de contrôle des accès. Consultez également les bonnes pratiques pour les journaux d'audit Cloud, qui s'appliquent également à Cloud Logging en général.

Accès de l'administrateur des utilisateurs

Les rôles IAM roles/logging.configWriter et roles/logging.admin disposent de fonctionnalités d'administration. Le rôle IAM roles/logging.configWriter est requis pour créer un récepteur de journalisation couramment utilisé pour acheminer vos journaux vers un projet spécifique ou centralisé. Par exemple, vous pouvez utiliser un récepteur de journalisation avec un filtre de journalisation pour acheminer tous les journaux d'un espace de noms vers un bucket de journalisation centralisé.

Pour en savoir plus, consultez le guide du contrôle des accès de Cloud Logging.

Bonnes pratiques

• Journalisation structurée : l'agent de journalisation intégré à GKE lit les documents JSON sérialisés en chaînes à une seule ligne et écrits sur la sortie standard ou l'erreur standard, puis les envoie à la suite Google Cloud Observability en tant qu'entrées de journal structurées.
  • Consultez Journalisation structurée pour en savoir plus sur l'utilisation d'un agent de journalisation intégré.
  • Vous pouvez utiliser des filtres de journaux avancés pour filtrer les journaux en fonction des champs du document JSON.
  • Les champs communs aux journaux générés avec glog sont analysés, par exemple : severity, pid, source_file, source_line. Toutefois, la charge utile du message elle-même n'est pas analysée et s'affiche intégralement dans le message de journal obtenu dans Google Cloud Observability.
• Gravité : par défaut, les entrées de journaux écrites sur la sortie standard sont au niveau INFO et celles écrites sur l'erreur standard au niveau ERROR. Les journaux structurés peuvent inclure un champ de gravité severity qui définit le degré de sévérité de l'entrée de journal.
• Exportation vers BigQuery : pour une analyse supplémentaire, vous pouvez exporter des journaux vers des services externes, tels que BigQuery ou Pub/Sub. Les journaux exportés vers BigQuery conservent leur format et leur structure. Pour en savoir plus, consultez la page Présentation du routage et du stockage.
• Alertes : lorsque Logging enregistre un comportement inattendu, vous pouvez utiliser des métriques basées sur les journaux pour configurer des règles d'alertes. Vous trouverez un exemple dans la section Créer une règle d'alerte sur une métrique de compteur. Pour en savoir plus, consultez la Présentation des métriques basées sur les journaux.

• Rapports d'erreurs : pour collecter des erreurs à partir d'applications exécutées sur vos clusters, vous pouvez utiliser Error Reporting.

Journaux disponibles

Si vous choisissez d'envoyer des journaux à Cloud Logging, vous devez envoyer des journaux système. Vous pouvez également envoyer des journaux à partir de sources supplémentaires.

Le tableau suivant indique les valeurs acceptées pour l'option --logging pour les commandes create et update.

Source de journal	Valeur --logging	Journaux collectés
Aucun	NONE	Aucun journal envoyé à Cloud Logging. Aucun agent de collecte de journaux n'est installé dans le cluster. Cette valeur n'est pas acceptée pour les clusters Autopilot.
Système	SYSTEM	Collecte les journaux des éléments suivants : Tous les pods s'exécutant dans les espaces de noms kube-system, istio-system, knative-serving, gke-system et config-management-system. Services non conteneurisés, y compris l'environnement d'exécution docker/containerd, kubelet, kubelet-monitor, node-problem-detector et kube-container-runtime-monitor. La sortie des ports série du nœud, si les métadonnées de l'instance de VM serial-port-logging-enable sont définies sur "true" Collecte également les événements Kubernetes. Cette valeur est obligatoire pour tous les types de clusters.
Charges de travail	WORKLOAD	Tous les journaux générés par des conteneurs non-système s'exécutant sur des nœuds utilisateur. Cette valeur est activée par défaut, mais facultative pour tous les types de clusters.
Serveur d'API	API_SERVER	Tous les journaux générés par kube-apiserver. Cette valeur est facultative pour tous les types de clusters.
Programmeur	SCHEDULER	Tous les journaux générés par kube-scheduler. Cette valeur est facultative pour tous les types de clusters.
Gestionnaire de contrôleurs	CONTROLLER_MANAGER	Tous les journaux générés par kube-controller-manager. Cette valeur est facultative pour tous les types de clusters.

Journaux activés par défaut dans GKE Enterprise

Lorsque vous créez un cluster GKE sur Google Cloud, les journaux de charge de travail sont activés par défaut pour tous les clusters Autopilot, mais peuvent être désactivés.

Avertissement : Si vous désactivez Cloud Logging ou Cloud Monitoring, ou appliquez des filtres d'exclusion, le service client GKE est fourni dans la mesure du possible et peut nécessiter des efforts supplémentaires de la part de votre équipe d'ingénierie.

Pour les projets de l'édition GKE Enterprise, des journaux supplémentaires utiles sont activés par défaut si vous vous enregistrez dans un parc lors de la création du cluster.

Dans le tableau ci-dessous, une coche () indique les journaux activés par défaut lorsque vous créez et enregistrez un cluster dans un projet avec GKE Enterprise activé :

Nom du journal	Autopilot	Standard
Système
Charges de travail		-
Serveur d'API
Programmeur
Gestionnaire de contrôleurs

Les journaux du plan de contrôle (serveur d'API, programmeur et gestionnaire de contrôleurs) entraînent des frais Cloud Logging.

Tarifs

Les journaux du plan de contrôle GKE sont exportés vers Cloud Logging. Les tarifs de Cloud Logging s'appliquent.

Les coûts de stockage cumulés vous sont facturés lorsque vous exportez des journaux vers un autre service Google Cloud tel que BigQuery. Pour connaître les coûts associés à Cloud Logging, consultez la section Tarifs.

Quota

Les journaux du plan de contrôle consomment le quota de "requêtes d'écriture par minute" de l'API Cloud Logging. Avant d'activer les journaux du plan de contrôle, vérifiez votre utilisation maximale récente de ce quota. Si vous avez plusieurs clusters dans le même projet ou que vous approchez déjà de la limite de ce quota, vous pouvez demander une augmentation de la limite de quota avant d'activer les journaux du plan de contrôle.

Contrôle des accès

Si vous souhaitez limiter l'accès aux journaux du plan de contrôle Kubernetes au sein de votre organisation, vous pouvez créer un bucket de journal distinct avec des contrôles d'accès plus limités.

En optant pour le stockage dans un bucket de journaux distinct avec un accès limité, les journaux du plan de contrôle du bucket de journaux ne seront pas automatiquement accessibles à toute personne disposant d'un accès roles/logging.viewer au projet. En outre, si vous décidez de supprimer certains journaux de plan de contrôle en raison de problèmes de confidentialité ou de sécurité, le stockage de ces journaux dans un bucket de journaux distinct avec un accès limité permet de supprimer les journaux sans affecter les journaux d'autres composants ou services.