Migrer vers Stackdriver Kubernetes Monitoring

Options de Stackdriver

Il existe actuellement deux modes de compatibilité de Stackdriver dans GKE. Ces options sont proposées par toutes les versions de GKE disponibles pour les nouveaux clusters, ainsi que pour les mises à jour des clusters existants:

  • Ancien Stackdriver (disponibilité générale). Pour accéder à la documentation, reportez-vous aux pages Monitoring et Logging pour GKE.

  • Stackdriver Kubernetes Monitoring (Bêta) Pour accéder à la documentation, consultez la page Stackdriver Kubernetes Monitoring

La page Installer la compatibilité Stackdriver explique comment mettre à jour vos clusters GKE vers Stackdriver Kubernetes Monitoring. Cette page décrit les différences constatées dans Stackdriver lors de la mise à jour et les éléments que vous devez modifier lorsque vous utilisez Stackdriver Monitoring et Stackdriver Logging avec Stackdriver Kubernetes Monitoring.

Quand dois-je migrer ?

Vous devez migrer vos configurations Stackdriver existantes lorsque vous commencez à les utiliser avec Stackdriver Kubernetes Monitoring. Lors d'une version ultérieure de GKE, la compatibilité de l'ancien Stackdriver sera supprimée et vous devrez utiliser Stackdriver Kubernetes Monitoring :

  • Vous pouvez commencer à migrer vos clusters dès maintenant en optant pour la version bêta de Stackdriver Kubernetes Monitoring. La version bêta est désormais disponible dans toutes les versions de GKE approuvées pour les nouveaux clusters et pour la mise à jour des clusters existants.

  • Vous pouvez attendre la sortie d'une version en disponibilité générale de Stackdriver Kubernetes Monitoring.

Qu'est-ce qui change ?

Stackdriver Kubernetes Monitoring utilise un modèle de données différent pour organiser ses métriques, ses journaux et ses métadonnées. Voici quelques modifications spécifiques apportées par Stackdriver Kubernetes Monitoring à vos clusters :

  • Le tableau de bord Stackdriver Monitoring se trouve dans un nouveau menu nommé Ressources > Kubernetes (Bêta). Ce tableau de bord n'apparaît pas si Stackdriver Kubernetes Monitoring n'est utilisé par aucun de vos clusters.

  • Les noms des types de ressources surveillées sont différents. Par exemple, vos nœuds Kubernetes sont répertoriés dans le type de ressources surveillées k8s_node (nœud Kubernetes) au lieu de gce_instance (instance de VM Compute Engine).

  • Les noms de métriques Kubernetes sont différents. Les noms de types de métriques commencent maintenant par le préfixe kubernetes.io/ (métriques Stackdriver Kubernetes) au lieu de container.googleapis.com/.

Ces modifications sont récapitulées dans le tableau ci-dessous :

Modification Ancien Stackdriver (hérité) Stackdriver Kubernetes Monitoring (nouveau)
Menus du tableau de bord Ressources > Kubernetes Engine Ressources > Kubernetes (Bêta)
Préfixes des métriques container.googleapis.com kubernetes.io
Types de ressources gke_container (métriques)
container (journaux)
gce_instance
(aucun)
gke_cluster
k8s_container
k8s_container
k8s_node
k8s_pod
k8s_cluster

Que dois-je faire ?

Cette section contient des informations plus spécifiques sur les modifications apportées au modèle de données dans Stackdriver Kubernetes Monitoring et leur impact sur vos configurations Stackdriver existantes.

Utiliser le tableau de bord d'état de la migration

Pour vous aider à identifier les configurations Stackdriver que vous devez migrer dans le cadre de la mise à niveau vers Stackdriver Kubernetes Monitoring, Stackdriver fournit un tableau de bord d'état de la migration.

Pour afficher le tableau de bord, choisissez un espace de travail contenant un cluster Kubernetes à mettre à jour vers Stackdriver Kubernetes Monitoring. Sélectionnez Workspace Settings (Paramètres de l'espace de travail) > Kubernetes Migration Status (État de la migration Kubernetes) dans le menu déroulant de sélection du projet :

Accéder au tableau de bord d'état de la migration Kubernetes

L'exemple de tableau de bord ci-dessous montre que l'opération est terminée :

Tableau de bord de la migration

Modifications des types de ressources

Stackdriver Kubernetes Monitoring présente de nouveaux noms pour les types de ressources, l'affichage des types de ressources et les libellés qui identifient des ressources spécifiques. Ces modifications sont répertoriées dans le tableau suivant.

Modifications des types de ressources
Type de ressources Ancien Stackdriver (hérité) Type de ressources Stackdriver Kubernetes Monitoring (nouveau)
Notes de bas de tableau :
1 Dans le nouveau type de ressources utilisé pour la surveillance (uniquement), instance_id devient node_name dans metadata.system_labels.
2 zone désigne l'emplacement de ce conteneur ou de cette instance. location correspond à l'emplacement du nœud maître du cluster.
3 metadata.system_labels.node_name n'est pas disponible dans les types de ressources k8s_container utilisés pour la journalisation. Vous ne pouvez pas rechercher les journaux par nom de nœud.
4 Le type de ressources gce_instance peut représenter des nœuds Kubernetes ainsi que des instances de VM non associées à Kubernetes. Lors de la mise à niveau vers Stackdriver Kubernetes Monitoring, les utilisations liées aux nœuds sont modifiées pour utiliser le nouveau type de ressources, k8s_node, y compris les journaux de niveau nœud portant les noms suivants : kubelet, docker, kube-proxy, startupscript et node-problem-detector.
5 Les nœuds k8s_pod et k8s_cluster peuvent inclure des journaux non présents dans la version de compatibilité Ancien Stackdriver.
Surveillance uniquement :
gke_container (conteneur GKE)

Libellés :
  cluster_name
  container_name
  instance_id1
  namespace_id
  pod_id
  project_id
  zone2

Journalisation uniquement :
container (conteneur GKE)

Libellés :
  cluster_name
  container_name
  instance_id1
  namespace_id
  pod_id
  project_id
  zone2

Surveillance et journalisation :
k8s_container (conteneur Kubernetes)

Libellés :
  cluster_name
  container_name
  metadata.system_labels.node_name3
  namespace_name
  pod_name
  project_id
  location2

Journalisation uniquement :
gce_instance (instance de VM Compute Engine)4

Libellés :
  cluster_name
  instance_id
  project_id
  zone2
Surveillance et journalisation
k8s_node4 (nœud Kubernetes)

Libellés :
  cluster_name
  node_name
  project_id
  location2
 
(aucun)
Surveillance et journalisation :
k8s_pod5 (pod Kubernetes)

Libellés :
  cluster_name
  namespace_name
  node_name
  project_id
  location2

Journalisation uniquement
gke_cluster (cluster GKE)

Libellés :
  cluster_name
  project_id
  location

Surveillance et journalisation :
k8s_cluster5 (cluster Kubernetes)

Libellés :
  cluster_name
  project_id
  location

Modifications des noms de métriques

Le tableau suivant montre quelques exemples des changements de noms de métriques. À chaque utilisation, vous devez remplacer toute métrique dont le nom commence par container.googleapis.com/ par une nouvelle métrique dont le nom commence par kubernetes.io/. En plus d'un nouveau préfixe, les nouveaux noms de métriques peuvent présenter d'autres différences. Recherchez les nouvelles métriques dans kubernetes.io (métriques Stackdriver Kubernetes).

Modifications des noms de métriques
Métriques Ancien Stackdriver (hérité) Métriques Stackdriver Kubernetes Monitoring (nouveau)
Métriques GKE héritées
container.googleapis.com/

Exemples :
  .../container/cpu/utilization
  .../container/uptime
  .../container/memory/bytes_total
Métrique Kubernetes Stackdriver
kubernetes.io/

Exemples :
  .../container/cpu/request_utilization
  .../container/uptime
  .../node/memory/total_bytes
  .../node/cpu/total_cores

Modifications des groupes de ressources

Si vous définissez vos propres groupes de ressources et utilisez l'un des types de ressources Ancien Stackdriver indiqués dans le tableau Modifications des types de ressources précédent, ou l'une des métriques Ancien Stackdriver figurant dans le tableau Modifications des noms de métriques précédent, modifiez ces types et métriques afin qu'ils correspondent à ceux de Stackdriver Kubernetes Monitoring. Si votre groupe de ressources inclut des graphiques personnalisés, vous devrez peut-être les modifier également.

Conseil : Vérifiez que vos groupes mis à jour contiennent le même nombre de ressources qu'avant la mise à niveau. Un nombre trop faible de ressources peut indiquer que vous avez omis certaines modifications.

Modifications des graphiques et tableaux de bord personnalisés

Si vous définissez vos propres graphiques et tableaux de bord personnalisés et utilisez l'un des types de ressources Ancien Stackdriver indiqués dans le tableau Modifications des types de ressources précédent, ou des métriques Ancien Stackdriver figurant dans le tableau Modifications des noms de métriques précédent, modifiez ces types et métriques afin qu'ils correspondent à ceux de Stackdriver Kubernetes Monitoring.

Conseil : Vérifiez que vos graphiques mis à jour reçoivent des données horodatées après la mise à jour. Des données manquantes peuvent indiquer que certaines métriques n'ont pas été modifiées correctement.

Si vous avez besoin d'aide pour vos graphiques et tableaux de bord personnalisés, consultez le tableau de bord d'état de la migration Kubernetes :

  1. En haut de la page "Stackdriver Monitoring", choisissez un espace de travail contenant un cluster Kubernetes à mettre à jour vers Stackdriver Kubernetes Monitoring.

  2. Sélectionnez Workspace Settings (Paramètres de l'espace de travail) > Kubernetes Migration Status (État de la migration Kubernetes) :

    Accéder au tableau de bord d'état de la migration Kubernetes

Modifications des règles d'alerte et de disponibilité

Si vous définissez des règles d'alerte ou des tests de disponibilité et utilisez l'un des types de ressources Ancien Stackdriver indiqués dans le tableau Modifications des types de ressources précédent, ou des métriques Ancien Stackdriver figurant dans le tableau Modifications des noms de métriques précédent, modifiez ces types et métriques afin qu'ils correspondent à ceux de Stackdriver Kubernetes Monitoring.

La mise à niveau des règles d'alerte et des tests de disponibilité sont sans doute les modifications les plus difficiles à effectuer et à valider. Modifiez-vous la configuration de vos règles avant la mise à niveau du cluster ou après ? Les anciennes règles échouent après la mise à jour et les nouvelles règles avant la mise à jour.

Au lieu de modifier les règles existantes, il est préférable de les conserver et d'en créer de nouvelles lors de l'application des mises à jour. Vous pourrez ainsi suivre plus facilement les règles dont l'échec ou la réussite sont attendus à différentes étapes de la mise à jour.

Voici d'autres conseils :

  • Examinez vos stratégies et estimez combien de temps votre cluster mis à jour devra fonctionner avant d'avoir accumulé suffisamment de données pour atteindre son point d'équilibre.

  • Essayez de déterminer les performances de vos règles ou métriques individuelles avant la mise à jour afin de pouvoir les comparer avec leur comportement après la mise à jour.

Journalisation des requêtes

Si vous utilisez des requêtes pour rechercher et filtrer vos journaux dans Stackdriver Logging et que vous utilisez l'un des types de ressources Ancien Stackdriver indiqués dans le tableau Modifications des types de ressources précédent, modifiez ces types afin qu'ils correspondent à ceux de Stackdriver Kubernetes Monitoring.

Métriques basées sur les journaux

Si vous définissez vos propres métriques basées sur les journaux et utilisez les métriques ou les types de ressources Ancien Stackdriver indiqués dans les tableaux Modifications des noms de métriques ou Modifications des types de ressources précédents, modifiez ces métriques et types de ressources afin qu'ils correspondent à ceux de Stackdriver Kubernetes Monitoring.

Conseil : Si vous ne voyez aucun exemple de métriques basées sur les journaux après la mise à jour vers Stackdriver Kubernetes Monitoring, il se peut que vous utilisiez encore les métriques ou les types de ressources Ancien Stackdriver.

Exportations et exclusions de journaux

Si vous exportez ou excluez certains de vos journaux, et si vos filtres d'exportation ou d'exclusion utilisent les types de ressources Ancien Stackdriver indiqués dans le tableau Modifications des types de ressources précédent, modifiez vos filtres d'exportation et d'exclusion pour qu'ils utilisent les types de ressources Stackdriver Kubernetes Monitoring correspondants.

Conseil : Avant de mettre à jour Stackdriver Kubernetes Monitoring, notez le nombre approximatif d'entrées de journal que vous exportez ou excluez de votre projet GCP et vérifiez que vous obtenez le même nombre après la mise à jour.

Modifications des contenus d'entrées de journal

Lorsque vous effectuez une mise à jour vers Stackdriver Kubernetes Monitoring, vous pouvez constater que certaines informations contenues dans les entrées de journal ont été déplacées dans des champs portant un nom différent. Ces informations peuvent apparaître dans les requêtes de journaux utilisées dans les métriques basées sur les journaux, les récepteurs de journaux et les exclusions de journaux.

Le tableau suivant, Modifications des entrées de journal, répertorie les nouveaux champs et libellés. En voici un résumé :

  • Le champ logName peut changer. Les entrées de journal Stackdriver Kubernetes Monitoring utilisent stdout ou stderr dans leurs noms de journal, tandis que l'ancien Stackdriver utilisait une plus grande variété de noms, y compris des noms de conteneur. Le nom du conteneur est toujours disponible en tant que libellé de ressource.
  • Vérifiez le champ labels dans les entrées de journal. Ce champ peut contenir des informations précédemment contenues dans les champs d'entrée de journal metadata.
  • Vérifiez le champ resource.labels dans les entrées de journal. Les nouveaux types de ressources comportent des valeurs de libellé supplémentaires.
Modifications des entrées de journal
Entrées de journal Ancien Stackdriver (hérité) Entrées de journal Stackdriver Kubernetes Monitoring (nouveau)
Notes de bas de tableau :
1 Les libellés de ressources identifient des ressources spécifiques qui génèrent des métriques, telles que des clusters et des nœuds particuliers.
2 Le champ labels apparaît dans les nouvelles entrées de journal faisant partie de Stackdriver Kubernetes Monitoring et, à l'occasion, dans certaines entrées de journal Ancien Stackdriver. Dans Stackdriver Kubernetes Monitoring, ce champ permet de conserver certaines informations précédemment contenues dans les champs d'entrée de journal metadata.
3 Le champ systemLabels n'est pas utilisé pour les entrées de journal dans la version en disponibilité générale de Stackdriver Kubernetes Monitoring, bien que certaines informations apparaissent dans les versions bêta. À compter de la version 1.12.6, ces informations sont déplacées vers le champ labels des entrées de journal.
4 Le champ userLabels n'est pas utilisé pour les entrées de journal dans la version en disponibilité générale de Stackdriver Kubernetes Monitoring, bien que certaines informations apparaissent dans les versions bêta. À compter de la version 1.12.6, ces informations sont déplacées vers le champ labels des entrées de journal.
Ressources d'entrées de journal
resource.labels (étiquettes de ressources1)
Ressources d'entrées de journal
resource.labels (étiquettes de ressources1)
Métadonnées d'entrées de journal
labels (étiquettes d'entrées de journal2)

libellés (exemples)
  compute.googleapis.com/resource_name:
    "fluentd-gcp-v3.2.0-d4d9p"

  container.googleapis.com/namespace_name:
    "kube-system"

  container.googleapis.com/pod_name:
    "fluentd-gcp-scaler-8b674f786-d4pq2"

  container.googleapis.com/stream:
    "stdout"
Métadonnées d'entrées de journal
labels

(aucun)
Métadonnées de ressources d'entrées de journal
metadata.systemLabels3 (étiquettes système)

(aucun)
Métadonnées d'entrées de journal
metadata.userLabels4 (étiquettes utilisateur)

Modifications des emplacements de journal

Dans Stackdriver Logging, les journaux sont stockés avec le type de ressources qui les a générés. Étant donné que ces types ont été modifiés dans Stackdriver Kubernetes Monitoring, veillez à rechercher vos journaux dans les nouveaux types de ressources tels que Kubernetes Container et non dans les types Ancien Stackdriver tels que GKE Container.

Étape suivante

  • Pour en savoir plus sur le nouveau tableau de bord Stackdriver Kubernetes Monitoring, consultez la page Observer le système.
Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Stackdriver Monitoring
Besoin d'aide ? Consultez notre page d'assistance.