GKE sur Bare Metal inclut plusieurs options de journalisation et de surveillance des clusters, y compris des services gérés basés dans le cloud, des outils Open Source et une compatibilité validée avec des solutions commerciales tierces. Cette page décrit ces options et fournit des conseils de base pour sélectionner la solution adaptée à votre environnement.
Options pour GKE sur une solution Bare Metal
Vous disposez de plusieurs options de journalisation et de surveillance pour votre environnement GKE sur bare metal:
- Cloud Logging et Cloud Monitoring, activés par défaut sur les composants du système Bare Metal
- Prometheus et Grafana, disponibles depuis Cloud Marketplace
- Configurations validées avec des solutions tierces
Cloud Logging et Cloud Monitoring
Google Cloud Observability est la solution d'observabilité intégrée à Google Cloud. Elle offre une solution de journalisation entièrement gérée, la collecte de métriques, la surveillance, la création de tableaux de bord et les alertes. Cloud Monitoring surveille GKE sur les clusters Bare Metal de la même manière que les clusters GKE basés dans le cloud.
Les agents peuvent être configurés pour modifier le champ d'application de la journalisation et de la surveillance, ainsi que le niveau des métriques collectées:
- Le champ d'application de la journalisation et de la surveillance peut être défini pour les composants système uniquement (par défaut), ou pour les composants système et les applications.
- Le niveau de métriques collectées peut être configuré pour un ensemble optimisé de métriques (par défaut) ou pour des métriques complètes.
Pour en savoir plus, consultez la section Configurer des agents Stackdriver pour GKE sur une solution Bare Metal de ce document.
Logging et Monitoring fournissent une solution d'observabilité basée sur le cloud unique, puissante et facile à configurer. Nous vous recommandons vivement d'utiliser Logging et Monitoring lorsque vous exécutez des charges de travail uniquement sur GKE sur Bare Metal, ou sur GKE et GKE sur Bare Metal. Pour les applications avec des composants exécutés sur GKE sur une solution Bare Metal et une infrastructure sur site standard, vous pouvez envisager d'autres solutions pour obtenir une vue de bout en bout de ces applications.
Pour en savoir plus sur l'architecture, la configuration et les données répliquées par défaut dans votre projet Google Cloud, consultez la page Fonctionnement de Logging et Monitoring pour GKE sur Bare Metal.
Pour en savoir plus sur Logging, consultez la documentation Cloud Logging.
Pour en savoir plus sur Monitoring, consultez la documentation Cloud Monitoring.
Pour savoir comment afficher et utiliser les métriques d'utilisation des ressources Cloud Monitoring de GKE sur Bare Metal au niveau du parc, consultez la page Utiliser la présentation de l'édition Enterprise de Google Kubernetes Engine (GKE).
Prometheus et Grafana
Prometheus et Grafana sont deux produits de surveillance Open Source populaires disponibles dans Cloud Marketplace :
Prometheus recueille des métriques sur les applications et le système.
Alertmanager gère l'envoi d'alertes à l'aide de différents mécanismes.
Grafana est un outil de création de tableaux de bord.
Prometheus et Grafana peuvent être activés sur chaque cluster d'administrateur et d'utilisateur. Prometheus et Grafana sont recommandés pour les équipes d'application ayant déjà une expérience de ces produits. Ces produits sont également recommandés pour les équipes opérationnelles qui préfèrent conserver les métriques d'application dans le cluster à des fins de dépannage des problèmes de connexion réseau.
Solutions tierces
Google a collaboré avec plusieurs fournisseurs tiers de solutions de journalisation et de surveillance pour que leurs produits fonctionnent bien avec GKE sur une solution Bare Metal. Ces fournisseurs incluent notamment Datadog, Elastic et Splunk. D'autres solutions tierces validées seront ajoutées ultérieurement.
Les guides de solution suivants sont disponibles pour utiliser des solutions tierces avec GKE sur une solution Bare Metal:
- Surveiller GKE sur une solution Bare Metal avec Elastic Stack
- Collecter des journaux sur GKE sur Bare Metal avec Splunk Connect
Fonctionnement de Logging et Monitoring pour GKE sur Bare Metal
Cloud Logging et Cloud Monitoring sont installés et activés dans chaque cluster dès la création d'un cluster d'administrateur ou d'utilisateur.
Les agents Stackdriver incluent plusieurs composants sur chaque cluster :
Opérateur Stackdriver (
stackdriver-operator-*
). Gère le cycle de vie de tous les autres agents Stackdriver déployés sur le cluster.Ressource personnalisée Stackdriver. Ressource créée automatiquement dans le cadre du processus d'installation de GKE sur solution Bare Metal.
Agent de métriques GKE (
gke-metrics-agent-*
). Un DaemonSet basé sur un collecteur OpenTelemetry qui scrape les métriques de chaque nœud pour Cloud Monitoring. Un DaemonSetnode-exporter
et un déploiementkube-state-metrics
sont également inclus pour fournir plus de métriques sur le cluster.Transfert de journaux Stackdriver (
stackdriver-log-forwarder-*
) : DaemonSet Fluent Bit qui transfère les journaux de chaque machine vers Cloud Logging. Le transfert de journaux met en mémoire tampon les entrées de journal sur le nœud localement et les renvoie pendant quatre heures maximum. Si le tampon est plein ou si le transfert de journaux ne peut pas atteindre l'API Cloud Logging pendant plus de quatre heures, les journaux sont supprimés.Agent Anthos Metadata (
stackdriver-metadata-agent-
) : déploiement qui envoie des métadonnées pour les ressources Kubernetes telles que des pods, des déploiements ou des nœuds à l'API Config Monitoring pour les opérations. Ces données sont utilisées pour enrichir les requêtes de métriques en vous permettant d'effectuer des requêtes par nom de déploiement, nom de nœud ou même nom de service Kubernetes.
Vous pouvez afficher les agents installés par Stackdriver en exécutant la commande suivante :
kubectl -n kube-system get pods -l "managed-by=stackdriver"
La sortie de la commande ressemble à ceci :
kube-system gke-metrics-agent-4th8r 1/1 Running 1 (40h ago) 40h
kube-system gke-metrics-agent-8lt4s 1/1 Running 1 (40h ago) 40h
kube-system gke-metrics-agent-dhxld 1/1 Running 1 (40h ago) 40h
kube-system gke-metrics-agent-lbkl2 1/1 Running 1 (40h ago) 40h
kube-system gke-metrics-agent-pblfk 1/1 Running 1 (40h ago) 40h
kube-system gke-metrics-agent-qfwft 1/1 Running 1 (40h ago) 40h
kube-system kube-state-metrics-9948b86dd-6chhh 1/1 Running 1 (40h ago) 40h
kube-system node-exporter-5s4pg 1/1 Running 1 (40h ago) 40h
kube-system node-exporter-d9gwv 1/1 Running 2 (40h ago) 40h
kube-system node-exporter-fhbql 1/1 Running 1 (40h ago) 40h
kube-system node-exporter-gzf8t 1/1 Running 1 (40h ago) 40h
kube-system node-exporter-tsrpp 1/1 Running 1 (40h ago) 40h
kube-system node-exporter-xzww7 1/1 Running 1 (40h ago) 40h
kube-system stackdriver-log-forwarder-8lwxh 1/1 Running 1 (40h ago) 40h
kube-system stackdriver-log-forwarder-f7cgf 1/1 Running 2 (40h ago) 40h
kube-system stackdriver-log-forwarder-fl5gf 1/1 Running 1 (40h ago) 40h
kube-system stackdriver-log-forwarder-q5lq8 1/1 Running 2 (40h ago) 40h
kube-system stackdriver-log-forwarder-www4b 1/1 Running 1 (40h ago) 40h
kube-system stackdriver-log-forwarder-xqgjc 1/1 Running 1 (40h ago) 40h
kube-system stackdriver-metadata-agent-cluster-level-5bb5b6d6bc-z9rx7 1/1 Running 1 (40h ago) 40h
Métriques Cloud Monitoring
Pour obtenir la liste des métriques collectées par Cloud Monitoring, consultez la page Afficher les métriques GKE sur Bare Metal.
Configurer des agents Stackdriver pour GKE sur une solution Bare Metal
Les agents Stackdriver installés avec GKE sur Bare Metal collectent des données sur les composants du système dans le but de gérer et de résoudre les problèmes liés à vos clusters. Les sections suivantes décrivent la configuration de Stackdriver et les modes de fonctionnement.
Composants système uniquement (mode par défaut)
Lors de l'installation, les agents Stackdriver sont configurés par défaut pour collecter des journaux et des métriques, y compris des informations sur les performances (par exemple, l'utilisation du processeur et de la mémoire) et des métadonnées similaires, pour les composants système fournis par Google. Celles-ci incluent toutes les charges de travail du cluster d'administrateur et, pour les clusters d'utilisateur, les charges de travail dans les espaces de noms kube-system, gke-system, gke-connect, Istio-system et config-management-system.
Composants système et applications
Pour activer la journalisation et la surveillance des applications en plus du mode par défaut, suivez la procédure décrite dans Activer la journalisation et la surveillance des applications.
Métriques optimisées (métriques par défaut)
Par défaut, les déploiements kube-state-metrics
exécutés dans le cluster collectent et transmettent un ensemble optimisé de métriques Kube à Google Cloud Observability (anciennement Stackdriver).
Moins de ressources sont nécessaires pour collecter cet ensemble optimisé de métriques, ce qui améliore les performances globales et l'évolutivité.
Pour désactiver les métriques optimisées (non recommandé), remplacez le paramètre par défaut dans votre ressource personnalisée Stackdriver.
Utilisez Managed Service pour Prometheus pour les composants système sélectionnés
Google Cloud Managed Service pour Prometheus fait partie de Cloud Monitoring et est disponible en tant qu'option pour les composants système. Voici quelques-uns des avantages de Managed Service pour Prometheus:
Vous pouvez continuer à utiliser votre surveillance basée sur Prometheus existante sans modifier vos alertes et vos tableaux de bord Grafana.
Si vous utilisez à la fois GKE et GKE sur Bare Metal, vous pouvez utiliser le même langage de requête Prometheus (PromQL) pour les métriques de tous vos clusters. Vous pouvez également utiliser l'onglet PromQL de l'Explorateur de métriques de la console Google Cloud.
Activer et désactiver Managed Service pour Prometheus
Managed Service pour Prometheus est activé par défaut dans GKE sur Bare Metal.
Pour désactiver Managed Service pour Prometheus:
Ouvrez l'objet Stackdriver nommé
stackdriver
pour le modifier:kubectl --kubeconfig CLUSTER_KUBECONFIG --namespace kube-system \ edit stackdriver stackdriver
Ajoutez la porte de caractéristiques
enableGMPForSystemMetrics
et définissez-la surfalse
:apiVersion: addons.gke.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: featureGates: enableGMPForSystemMetrics: false
Fermez votre session de retouche.
Afficher les données de métriques
Lorsque enableGMPForSystemMetrics
est défini sur true
, les métriques des composants suivants ont un format différent pour la manière dont ils sont stockés et interrogés dans Cloud Monitoring:
- kube-apiserver
- kube-scheduler
- kube-controller-manager
- kubelet et cAdvisor
- kube-state-metrics
- node-exporter
Dans le nouveau format, vous pouvez interroger les métriques précédentes à l'aide de PromQL ou du langage de requête Monitoring (MQL):
PromQL
Exemple de requête PromQL:
histogram_quantile(0.95, sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le))
MQL
Pour utiliser MQL, définissez la ressource surveillée sur prometheus_target
, utilisez le nom de la métrique avec le préfixe kubernetes.io/anthos
et ajoutez le type Prometheus en tant que suffixe au nom de la métrique.
fetch prometheus_target
| metric 'kubernetes.io/anthos/apiserver_request_duration_seconds/histogram'
| align delta(5m)
| every 5m
| group_by [], [value_histogram_percentile: percentile(value.histogram, 95)]
Configurer des tableaux de bord Grafana avec Managed Service pour Prometheus
Pour utiliser Grafana avec les données de métriques de Managed Service pour Prometheus, suivez la procédure décrite dans Interroger avec Grafana pour authentifier et configurer une source de données Grafana afin d'interroger les données de Managed Service pour Prometheus.
Des exemples de tableaux de bord Grafana sont disponibles dans le dépôt anthos-samples sur GitHub. Pour installer les exemples de tableaux de bord, procédez comme suit:
Téléchargez les exemples de fichiers JSON:
git clone https://github.com/GoogleCloudPlatform/anthos-samples.git cd anthos-samples/gmp-grafana-dashboards
Si votre source de données Grafana a été créée sous un nom différent avec
Managed Service for Prometheus
, modifiez le champdatasource
dans tous les fichiers JSON:sed -i "s/Managed Service for Prometheus/[DATASOURCE_NAME]/g" ./*.json
Remplacez [DATASOURCE_NAME] par le nom de la source de données de votre Grafana qui pointait vers le service Prometheus
frontend
.Accédez à l'interface utilisateur de Grafana depuis votre navigateur, puis sélectionnez + Importer dans le menu Tableaux de bord.
Importez le fichier JSON, ou copiez et collez le contenu du fichier, puis sélectionnez Charger. Une fois le contenu du fichier chargé, sélectionnez Import (Importer). Vous pouvez également modifier le nom du tableau de bord et l'UID avant l'importation.
Le tableau de bord importé devrait se charger correctement si votre GKE sur Bare Metal et la source de données sont correctement configurés. Par exemple, la capture d'écran suivante montre le tableau de bord configuré par
cluster-capacity.json
.
Autres ressources
Pour en savoir plus sur Managed Service pour Prometheus, consultez les pages suivantes:
Les métriques du plan de contrôle GKE sont compatibles avec PromQL
Utiliser Managed Service pour Prometheus pour les applications utilisateur sur GKE sur Bare Metal
Configurer les ressources des composants Stackdriver
Lorsque vous créez un cluster, GKE sur une solution Bare Metal crée automatiquement une ressource personnalisée Stackdriver. Vous pouvez modifier la spécification de la ressource personnalisée pour remplacer les valeurs par défaut des demandes et limites de processeurs et de mémoire d'un composant Stackdriver, et remplacer séparément le paramètre de métrique optimisée par défaut.
Remplacer les valeurs par défaut de processeur et les demandes de mémoire et limites pour un composant Stackdriver
Les clusters à densité élevée des pods introduit des volumes de journalisation et de surveillance plus importants.accrues. Dans les cas extrêmes, les composants Stackdriver peuvent indiquer être à proximité de la limite d'utilisation du processeur et de la mémoire, ou même de subir des redémarrages constants du fait des limites de ressources. Dans ce cas, pour remplacer les valeurs par défaut des demandes de ressources mémoire et de processeur et des limites d'un composant Stackdriver, procédez comme suit :
Exécutez la commande suivante pour ouvrir la ressource personnalisée Stackdriver dans un éditeur de ligne de commande :
kubectl -n kube-system edit stackdriver stackdriver
Dans la ressource personnalisée Stackdriver, ajoutez la section
resourceAttrOverride
sous le champspec
:resourceAttrOverride: DAEMONSET_OR_DEPLOYMENT_NAME/CONTAINER_NAME: LIMITS_OR_REQUESTS: RESOURCE: RESOURCE_QUANTITY
Notez que la section
resourceAttrOverride
remplace toutes les limites et demandes par défaut du composant spécifié. Les composants suivants sont compatibles avecresourceAttrOverride
:gke-metrics-agent/gke-metrics-agent
stackdriver-log-forwarder/stackdriver-log-forwarder
stackdriver-metadata-agent-cluster-level/metadata-agent
node-exporter/node-exporter
kube-state-metrics/kube-state-metrics
Voici un exemple de fichier :
apiVersion: addons.gke.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: anthosDistribution: baremetal projectID: my-project clusterName: my-cluster clusterLocation: us-west-1a resourceAttrOverride: gke-metrics-agent/gke-metrics-agent: requests: cpu: 110m memory: 240Mi limits: cpu: 200m memory: 4.5Gi
Pour enregistrer les modifications apportées à la ressource personnalisée Stackdriver, enregistrez et quittez l'éditeur de ligne de commande.
Vérifiez l'état du pod :
kubectl -n kube-system get pods -l "managed-by=stackdriver"
Une réponse pour un pod opérationnel se présente comme suit :
gke-metrics-agent-4th8r 1/1 Running 1 40h
Vérifiez la spécification du pod du composant pour vous assurer que les ressources sont définies correctement.
kubectl -n kube-system describe pod POD_NAME
Remplacez
POD_NAME
par le nom du pod que vous venez de modifier. Par exemple,gke-metrics-agent-4th8r
.La réponse se présente comme suit :
Name: gke-metrics-agent-4th8r Namespace: kube-system ... Containers: gke-metrics-agent: Limits: cpu: 200m memory: 4.5Gi Requests: cpu: 110m memory: 240Mi ...
Désactiver les métriques optimisées
Par défaut, les déploiements kube-state-metrics
exécutés dans le cluster collectent et transmettent un ensemble optimisé de métriques kube à Stackdriver. Si vous avez besoin de métriques supplémentaires, nous vous recommandons de les remplacer dans la liste des métriques GKE sur Bare Metal.
Voici quelques exemples de remplacements que vous pouvez utiliser :
Métrique désactivée | Remplacements |
---|---|
kube_pod_start_time |
container/uptime |
kube_pod_container_resource_requests |
container/cpu/request_cores container/memory/request_bytes |
kube_pod_container_resource_limits |
container/cpu/limit_cores container/memory/limit_bytes |
Pour désactiver le paramètre par défaut des métriques optimisées (non recommandé), procédez comme suit:
Ouvrez votre ressource personnalisée Stackdriver dans un éditeur de ligne de commande :
kubectl -n kube-system edit stackdriver stackdriver
Définissez le champ
optimizedMetrics
surfalse
.apiVersion: addons.gke.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: anthosDistribution: baremetal projectID: my-project clusterName: my-cluster clusterLocation: us-west-1a optimizedMetrics: false
Enregistrez les modifications et quittez l'éditeur de ligne de commande.
Serveur de métriques
Metrics-server est la source des métriques de ressources de conteneur pour divers pipelines d'autoscaling. Metrics-server extrait les métriques des kubelets et les expose via l'API Metrics de Kubernetes. Les autoscalers horizontal et vertical de pods exploitent ensuite ces métriques pour savoir à quel moment déclencher l'autoscaling. Metrics-server est mis à l'échelle à l'aide du module addon-resizer.
Dans les cas extrêmes où la densité de pods élevée entraîne trop de journalisation et de surveillance, metrics-server peut être arrêté et redémarré en raison de limites de ressources. Dans ce cas, vous pouvez allouer plus de ressources au serveur de métriques en modifiant le ConfigMap metrics-server-config
dans l'espace de noms gke-managed-metrics-server, et en changeant la valeur de cpuPerNode
et memoryPerNode
.
kubectl edit cm metrics-server-config -n gke-managed-metrics-server
L'exemple de contenu du fichier ConfigMap est le suivant :
apiVersion: v1
data:
NannyConfiguration: |-
apiVersion: nannyconfig/v1alpha1
kind: NannyConfiguration
cpuPerNode: 3m
memoryPerNode: 20Mi
kind: ConfigMap
Après avoir mis à jour le fichier ConfigMap, recréez les pods metrics-server à l'aide de la commande suivante :
kubectl delete pod -l k8s-app=metrics-server -n gke-managed-metrics-server
Configuration requise pour Logging et Monitoring
Plusieurs exigences de configuration sont requises pour activer Cloud Logging et Cloud Monitoring avec GKE sur Bare Metal. Ces étapes sont incluses dans la section Configurer un compte de service à utiliser avec Logging et Monitoring sur la page "Activer les services Google" et dans la liste suivante :
- Un espace de travail Cloud Monitoring doit être créé dans le projet Google Cloud. Pour ce faire, cliquez sur Monitoring dans la console Google Cloud et suivez le workflow.
Vous devez activer les API Stackdriver suivantes :
Vous devez attribuer les rôles IAM suivants au compte de service utilisé par les agents Stackdriver :
logging.logWriter
monitoring.metricWriter
stackdriver.resourceMetadata.writer
monitoring.dashboardEditor
opsconfigmonitoring.resourceMetadata.writer
Tarification
L'utilisation des journaux système et des métriques de l'édition Google Kubernetes Engine (GKE) Enterprise est gratuite.
Dans un cluster GKE sur Bare Metal, les journaux système et les métriques de l'édition Google Kubernetes Engine (GKE) Enterprise incluent les éléments suivants:
- Journaux et métriques de tous les composants d'un cluster d'administrateur
- Journaux et métriques des composants de ces espaces de noms dans un cluster d'utilisateur :
kube-system
,gke-system
,gke-connect
,knative-serving
,istio-system
,monitoring-system
,config-management-system
,gatekeeper-system
,cnrm-system
Pour en savoir plus, consultez la page Tarifs de l'observabilité Google Cloud.
Pour en savoir plus sur l'attribution de crédits pour les métriques Cloud Logging, contactez le service commercial au sujet des tarifs.