Version 1.9. Cette version est compatible conformément à la politique de compatibilité avec les versions d'Anthos, en fournissant les derniers correctifs et mises à jour pour les failles de sécurité, les expositions et les problèmes affectant Anthos Clusters on VMware (GKE On-Prem). Reportez-vous aux notes de version pour plus de détails. Il s'agit de la version la plus récente.

Journalisation et surveillance

Anthos clusters on VMware (GKE On-Prem) inclut plusieurs options de journalisation et de surveillance des clusters, y compris des services gérés basés dans le cloud et des outils Open Source, mais aussi une compatibilité validée avec des solutions commerciales tierces. Ce document décrit ces options et fournit des conseils de base pour sélectionner la solution adaptée à votre environnement.

Options pour Anthos clusters on VMware

Vous disposez de plusieurs options de journalisation et de surveillance pour Anthos clusters on VMware :

  • Cloud Logging et Cloud Monitoring, activés par les agents de cluster déployés avec Anthos clusters on VMware.
  • Prometheus et Grafana, désactivés par défaut.
  • Configurations validées avec des solutions tierces

Cloud Logging et Cloud Monitoring

La suite Google Cloud Operations (anciennement Stackdriver) est la solution d'observabilité intégrée pour 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 les clusters Anthos clusters on VMware de la même manière que les clusters GKE basés dans le cloud.

Vous pouvez configurer les agents intégrés au cluster pour le champ d'application de la surveillance et de la journalisation, ainsi que pour le niveau de métriques collecté :

  • 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 ou pour des métriques complètes.

Pour en savoir plus, consultez la section Configurer les agents Logging et Monitoring pour les Anthos clusters on VMware.

Cloud Logging et Cloud Monitoring conviennent parfaitement aux clients qui recherchent une solution unique et facile à configurer, puissante et basée sur le cloud. Nous vous recommandons vivement d'utiliser Logging et Monitoring lorsque vous exécutez des charges de travail uniquement sur Anthos clusters on VMware, ou que vous les exécutez sur GKE et Anthos clusters on VMware. Pour les applications avec des composants s'exécutant sur une infrastructure standard traditionnelle sur site et Anthos clusters on VMware, vous pouvez envisager d'autres solutions pour une vue de bout en bout de ces applications.

Prometheus et Grafana

Prometheus et Grafana sont deux produits de surveillance Open Source populaires :

  • 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, ou 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 de solutions tierces de journalisation et de surveillance pour faire en sorte que leurs produits fonctionnent bien avec Anthos clusters on VMware. 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 Anthos clusters on VMware :

Fonctionnement de Logging et Monitoring pour Anthos clusters on VMware

Les agents Logging et 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 collectent des données concernant les composants système, à savoir la portée que vous pouvez configurer.

Pour afficher les données collectées sur Google Cloud Console, vous devez configurer le projet Cloud qui stocke les journaux et les métriques à afficher.

Les agents Logging et Monitoring incluent plusieurs composants sur chaque cluster :

  • Gestionnaire Logging et Monitoring (stackdriver-operator-*). Il gère le cycle de vie de tous les autres agents Logging et Monitoring déployés sur le cluster.

  • Ressource personnalisée Stackdriver. Une ressource créée automatiquement dans le cadre du processus d'installation d'Anthos clusters on VMware. Les utilisateurs peuvent modifier la ressource personnalisée pour mettre à jour à tout moment les valeurs telles que l'ID du projet, le nom du cluster et l'emplacement du cluster.

  • Transfert de journaux (stackdriver-log-forwarder-*). Un daemonset Fluent Bit qui transmet les journaux de chaque machine à 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 la mémoire tampon est saturée ou si le service de transfert de journaux ne peut pas atteindre l'API Cloud Logging pendant plus de quatre heures, les journaux sont supprimés.

  • Collecteur de métriques (stackdriver-prometheus-k8s-*). Un StatefulSet Sidecar Stackdriver Prometheus et Prometheus qui envoie les métriques Prometheus à l'API Cloud Logging.

  • Collecteur de métadonnées (stackdriver-metadata-agent-*). Un déploiement qui envoie des métadonnées pour des ressources Kubernetes telles que des pods, des déploiements ou des nœuds à l'API Stackdriver Resource Metadata. 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, par nom de nœud ou même par nom de service Kubernetes.

Vous pouvez afficher tous les agents en exécutant la commande suivante :

  kubectl -n kube-system get pods | grep stackdriver

La sortie de la commande ressemble à ceci :

stackdriver-log-forwarder-bpf8g               1/1     Running   0   4h31m
stackdriver-log-forwarder-cht4m               1/1     Running   0   4h31m
stackdriver-log-forwarder-fth5s               1/1     Running   0   4h31m
stackdriver-log-forwarder-kw4j2               1/1     Running   0   4h29m
stackdriver-metadata-agent-cluster-level...   1/1     Running   0   4h31m
stackdriver-operator-76ddb64d57-4tcj9         1/1     Running   0   4h37m
stackdriver-prometheus-k8s-0                  2/2     Running   0   4h31m

Configurer les agents Logging et Monitoring pour Anthos clusters on VMware

Les agents installés avec Anthos clusters on VMware collectent des données sur les composants du système, en fonction de vos paramètres et de votre configuration, dans le but de gérer et de résoudre les problèmes liés à vos clusters.

Composants système uniquement (champ d'application par défaut)

Lors de l'installation, les agents collectent les journaux et les métriques, y compris les détails des performances (par exemple, l'utilisation du processeur et de la mémoire) et les métadonnées similaires pour les composants système fournis par Google. Ceux-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. Vous pouvez configurer ou désactiver les agents comme décrit dans les sections suivantes.

Le champ d'application des journaux et des métriques collectés peut être étendu à des applications spécifiques. Pour savoir comment activer la journalisation et la surveillance des applications, consultez la section Activer Logging et Monitoring pour les applications utilisateur.

Métriques optimisées (métriques par défaut)

Par défaut, les agents de métriques exécutés dans le cluster collectent et signalent un ensemble optimisé de métriques de conteneur et de kubelet dans la suite d'opérations de Google Cloud (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é. Ceci est particulièrement important pour les métriques au niveau du conteneur, en raison du grand nombre d'objets à surveiller.

Pour désactiver les métriques optimisées (non recommandé), définissez le champ optimizedMetrics sur false dans votre ressource personnalisée Stackdriver. Pour en savoir plus sur la modification de votre ressource personnalisée Stackdriver, consultez la section Configurer les ressources des composants Stackdriver. Toutes les métriques Anthos clusters on VMware, y compris celles exclues par défaut, sont décrites dans la section Métriques Anthos.

Stackdriver désactivé

Vous pouvez désactiver complètement les agents Logging et Monitoring en supprimant la ressource personnalisée Stackdriver. Avant de désactiver Stackdriver, consultez la page d'assistance pour en savoir plus sur les conséquences que cela peut avoir sur les contrats de niveau de service de l'assistance Google Cloud.

Pour désactiver Stackdriver pour Anthos clusters on VMware, procédez comme suit :

kubectl -n kube-system delete stackdriver stackdriver

Les agents Logging et Monitoring capturent les données stockées localement, suivant votre configuration de stockage et de conservation. Les données sont dupliquées dans le projet Google Cloud spécifié lors de l'installation, à l'aide d'un compte de service autorisé à écrire des données dans ce projet. Vous pouvez désactiver ces agents à tout moment, comme décrit précédemment.

Vous pouvez également gérer et supprimer les données collectées par les agents Logging et Monitoring comme toutes les autres données de métriques et de journal, comme décrit dans la documentation de Cloud Monitoring.

Configuration requise pour Logging et Monitoring

Pour afficher les données Logging et Monitoring, vous devez configurer le projet Cloud qui stocke les journaux et les métriques à afficher. Ce projet Cloud s'appelle votre projet de journalisation et de surveillance.

  1. Activez les API suivantes dans votre projet de journalisation et de surveillance :

  2. Attribuez les rôles IAM suivants au compte de service logging-monitoring sur votre projet correspondant.

    • logging.logWriter
    • monitoring.metricWriter
    • stackdriver.resourceMetadata.writer
    • monitoring.dashboardEditor
    • opsconfigmonitoring.resourceMetadata.writer

Tarifs

Aucuns frais ne s'appliquent pour les journaux système et les métriques Anthos.

Dans un cluster Anthos sur un cluster VMware, les journaux système et les métriques Anthos 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 section Tarifs de la suite Google Cloud Operations.

Pour en savoir plus sur l'attribution de crédits pour les métriques Cloud Logging, contactez le service commercial au sujet des tarifs.

Fonctionnement de Prometheus et Grafana pour Anthos clusters on VMware

Chaque cluster Anthos clusters on VMware est créé avec Prometheus et Grafana désactivés par défaut. Vous pouvez suivre le guide d'installation pour les activer.

Le serveur Prometheus est mis en place avec une configuration haute disponibilité comprenant deux instances dupliquées qui s'exécutent sur deux nœuds distincts. Les besoins en ressources sont ajustés pour accepter les clusters exécutant jusqu'à cinq nœuds, chacun gérant jusqu'à 30 pods qui diffusent des métriques personnalisées. Prometheus dispose d'un objet PersistentVolume dédié avec un espace disque préalloué afin de recevoir les données pour une période de conservation de quatre jours, plus un tampon de sécurité supplémentaire.

Le plan de contrôle d'administrateur et chaque cluster d'utilisateur disposent d'une pile de surveillance dédiée que vous pouvez configurer indépendamment. Chaque cluster d'administrateur et d'utilisateur inclut une pile de surveillance qui fournit un ensemble complet de fonctionnalités : Prometheus Server pour la surveillance, Grafana pour l'observabilité et Prometheus Alertmanager pour les alertes.

Tous les points de contrôle de surveillance, les données de métriques transférées et les API de surveillance sont sécurisés à l'aide de composants Istio utilisant des règles mTLS et RBAC. L'accès aux données de surveillance est limité aux administrateurs de cluster.

Métriques collectées par Prometheus

Prometheus collecte les métriques et métadonnées suivantes à partir du plan de contrôle d'administrateur et des clusters d'utilisateur :

  • Utilisation des ressources, telles que l'utilisation du processeur sur les pods et les nœuds
  • Métriques du plan de contrôle Kubernetes
  • Métriques des modules complémentaires et des composants système Kubernetes s'exécutant sur des nœuds, tels que kubelet
  • État du cluster, comme par exemple l'état des pods lors d'un déploiement
  • Métriques des applications.
  • Métriques des machines, comme par exemple réseau, entropie et inodes.

Surveillance multicluster

L'instance Prometheus et Grafana installée sur le cluster d'administration est spécialement configurée pour fournir des informations sur l'intégralité de l'instance Anthos clusters on VMware, y compris sur le cluster d'administration et sur chacun des clusters d'utilisateur. Ainsi, vous pouvez effectuer les opérations suivantes :

  • Utiliser un tableau de bord Grafana pour accéder aux métriques de tous les clusters d'utilisateur et d'administrateur.
  • Afficher les métriques de clusters d'utilisateur individuels dans les tableaux de bord Grafana. Les métriques sont disponibles pour des requêtes directes en résolution complète.
  • Accéder aux métriques de niveau nœud et charge de travail des clusters d'utilisateur pour les requêtes agrégées, les tableaux de bord et les alertes (les métriques de charge de travail sont limitées aux charges de travail exécutées dans l'espace de noms kube-system).
  • Configurer des alertes pour des clusters spécifiques.

Étape suivante