Gérer les journaux GKE

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

Présentation

Lorsque vous activez l'intégration de Cloud Operations pour GKE avec Cloud Logging et Cloud Monitoring pour votre cluster, vos journaux sont stockés dans un datastore 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 de vos charges de travail système et d'application déployées dans 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 plus d'informations 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 de kube-system, et sont décrits dans la section Contrôler la collecte des journaux d'application.

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

Collecter vos journaux

Lorsque vous créez un cluster GKE, l'intégration de Cloud Operations pour GKE à 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.

Valeurs par défaut de Logging

Lorsqu'il est activé, un agent dédié est automatiquement déployé et géré. Il s'exécute sur le nœud GKE pour collecter les 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 dans Cloud Logging ou exclus. Le routeur de journaux permet également d'exporter vos journaux vers BigQuery, Pub/Sub ou Cloud Storage.

Depuis GKE 1.16-13-gke.400, les les données en sortie du port série des nœuds est conservée dans Cloud Logging. Pour désactiver la journalisation des données en sortie du port série sur Cloud Logging, définissez --metadata serial-port-logging-enable=false lors de la création du cluster.

Personnalisation de la collecte des journaux système uniquement

À partir de la version 1.15.7 de GKE, vous pouvez configurer Cloud Operations pour GKE pour ne capturer que les journaux système et non les journaux d'application.

Collection de journaux avec l'agent 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 les journaux d'audit détaillés du système d'exploitation sur les nœuds Google Kubernetes Engine 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 les messages d'erreur, les tentatives de connexion et les exécutions binaires. Vous pouvez vous servir de ces informations pour déboguer les problèmes ou étudier 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, accédez au guide de contrôle des accès. Vous pouvez également consulter le document Bonnes pratiques pour les journaux d'audit Cloud, qui s'applique é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 : 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.