Gérer les journaux GKE

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

Aperçu

Lorsque vous activez l'intégration de Kubernetes Engine Operations à Cloud Logging et Cloud Monitoring pour votre cluster, vos journaux sont stockés dans un magasin de données persistant dédié. Bien que GKE lui-même enregistre des journaux, 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.

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. 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.

Journaux collectés

Par défaut, GKE collecte les journaux des charges de travail du système et des applications déployées sur le cluster.

  • Journaux système : ces journaux incluent les journaux d'audit du cluster, y compris le journal d'activité d'administration, le journal d'accès aux données et le journal des événements. Pour en savoir plus sur les journaux d'audit pour GKE, consultez la documentation Journaux d'audit pour GKE. Certains journaux système s'exécutent en tant que conteneurs, tels que ceux du kube-system, et sont décrits dans la section Contrôler la collecte de vos journaux d'application.

  • Journaux d'application : les conteneurs Kubernetes collectent les journaux de vos charges de travail, écrits dans STDOUT et STDERR.

Collecter des journaux

Lorsque vous créez un cluster GKE, l'intégration des opérations Kubernetes Engine à Cloud Logging et Cloud Monitoring est activée par défaut.

Pour l'ancienne version de Cloud Logging, vous pouvez suivre la documentation pour savoir comment activer ou désactiver l'intégration à Logging.

Journalisation par défaut

Lorsque cette option est activée, un agent dédié est automatiquement déployé et géré. Il s'exécute sur le nœud GKE pour collecter des journaux, ajoute des métadonnées utiles sur le conteneur, le pod et le cluster, puis envoie les journaux à Cloud Logging. Les journaux système et les journaux d'application de votre charge de travail sont ensuite transmis au routeur de journaux dans Cloud Logging.

Les journaux sont ensuite ingérés à Cloud Logging ou exclus. Le routeur de journaux propose également une étape facultative permettant d'exporter vos journaux vers BigQuery, Pub/Sub ou Cloud Storage.

Personnalisation de la collecte des journaux pour les journaux système uniquement

À partir de la version 1.15.7 de GKE, vous pouvez configurer les opérations Kubernetes Engine pour ne capturer que les journaux système et non les journaux d'application.

Collecte de journaux avec fluentd 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. Si vous souhaitez modifier le comportement par défaut des agents fluentd, vous pouvez exécuter un agent fluentd personnalisé.

Vous trouverez ci-dessous des cas d'utilisation courants :

Collecter des journaux Linux auditd pour les nœuds GKE

Vous pouvez activer des journaux d'audit du système d'exploitation détaillés sur les nœuds Google Kubernetes Engine exécutant Container-Optimized OS. Les journaux du système d'exploitation de 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 vous servir à résoudre des problèmes ou à enquêter sur les 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 que vous pouvez utiliser pour accorder un accès approprié.

Accès aux applications

Les applications ont besoin d'une autorisation pour écrire des journaux, qui est accordée par l'attribution du rôle IAM roles/logging.logWriter au compte de service d'une application. Lorsque vous créez un cluster GKE, le rôle roles/logging.logWriter est activé par défaut.

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, consultez le guide Contrôle des accès. Vous pouvez également consulter le document Bonnes pratiques relatives aux journaux d'audit Cloud, qui s'applique également à Cloud Logging en général.

Accès administrateur de l'utilisateur

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 : les chaînes JSON à une seule ligne écrites sur la sortie standard ou l'erreur standard seront lues dans la suite d'opérations Google comme des entrées de journaux structurés. Consultez la page Journalisation structurée pour plus de détails. Vous pouvez utiliser des filtres de journaux avancés pour filtrer les journaux en fonction de leurs champs.
  • 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 : vous pouvez exporter les journaux vers des services externes, tels que BigQuery ou Pub/Sub, pour y effectuer des analyses supplémentaires. Les journaux exportés vers BigQuery conservent leur format et leur structure. Pour en savoir plus, consultez la section Présentation des exportations de journaux.
  • Alertes : vous pouvez utiliser des métriques basées sur les journaux pour configurer des règles d'alertes lorsque Logging enregistre un comportement inattendu. Vous trouverez un exemple dans la section Créer une règle d'alerte simple 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 : vous pouvez utiliser Stackdriver Error Reporting pour collecter les erreurs survenues dans vos clusters.