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.
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 incluent les journaux des sources suivantes :
Tous les pods s'exécutant dans les espaces de noms
kube-system,istio-system,knative-serving,gke-systemetconfig-management-systemLes services principaux non conteneurisés, y compris l'environnement d'exécution
docker/containerd,kubelet,kubelet-monitor,node-problem-detectoretkube-container-runtime-monitorLa sortie des ports série du nœud, si les métadonnées de l'instance de VM
serial-port-logging-enablesont définies sur "true" Depuis GKE 1.16-13-gke.400, les données en sortie du port série des nœuds sont collectées par l'agent Logging. Pour désactiver la journalisation des données en sortie du port série, définissez--metadata serial-port-logging-enable=falselors de la création du cluster. La sortie du port série est utile pour résoudre les problèmes de plantages, les échecs de démarrage, les problèmes de démarrage ou d'arrêt des nœuds GKE. La désactivation de ces journaux peut compliquer la résolution des problèmes.
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.
À partir de la version 1.15.7 de GKE, vous pouvez 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 des 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 la page 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. Selon la version de votre plan de contrôle GKE, fluentd or fluentbit sont utilisés pour collecter les journaux. À partir de la version GKE 1.17, les journaux sont collectés à l'aide d'un agent basé sur fluentbit.
Les clusters GKE utilisant des versions antérieures à GKE 1.17 utilisent un agent basé sur fluentd. 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 :
Supprimer les données sensibles de vos journaux
Collecter des journaux supplémentaires non écrits dans
STDOUTouSTDERRUtiliser des paramètres liés aux performances
Utiliser un format de journaux personnalisé
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
INFOet celles écrites sur l'erreur standard au niveauERROR. Les journaux structurés peuvent inclure un champ de gravitéseverityqui 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 du plan de contrôle
Vous pouvez configurer un cluster GKE pour envoyer vers Cloud Logging des journaux émis par le serveur d'API, le programmeur et le gestionnaire de contrôleurs Kubernetes.
Conditions requises
L'envoi à Cloud Logging des journaux émis par les composants du plan de contrôle Kubernetes nécessite la version 1.22.0 ou ultérieure du plan de contrôle GKE et nécessite l'activation de la collecte des journaux système.
Configurer la collecte des journaux du plan de contrôle
Consultez les instructions de configuration de la journalisation pour un nouveau cluster ou pour un cluster existant.
Tarifs
Les journaux du plan de contrôle GKE sont exportés vers Cloud Logging. Les tarifs de Cloud Logging s'appliquent.
Quotas
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.