Migrer vers Stackdriver Kubernetes Engine Monitoring

Google Kubernetes Engine (GKE) offre deux options pour la surveillance et la journalisation. Ces options sont fournies par toutes les révisions de GKE disponibles pour les nouveaux clusters et pour les mises à jour des clusters existants :

Cette page décrit les différences entre ces deux options, ainsi que les éléments à modifier pour passer de l'ancienne version de Stackdriver à Stackdriver Kubernetes Engine Monitoring.

Quand dois-je migrer ?

Vous pouvez à tout moment migrer vos configurations Stackdriver Monitoring et Stackdriver Logging existantes depuis l'ancien Stackdriver vers Stackdriver Kubernetes Engine Monitoring. Gardez toutefois à l'esprit que la compatibilité avec l'ancien Stackdriver peut être retirée lors d'une version ultérieure de GKE. Si la compatibilité avec l'ancien Stackdriver est supprimée mais que vous souhaitez continuer à utiliser Stackdriver Monitoring et Stackdriver Logging, vous devrez effectuer la migration vers Stackdriver Kubernetes Engine Monitoring avant le retrait de la compatibilité.

Le tableau suivant récapitule les versions de GKE à venir ainsi que leurs options de compatibilité :

Version de GKE Ancien Stackdriver Stackdriver Kubernetes Engine Monitoring
1.10 – 1.12.5 Par défaut À activer (bêta)
1.12.7 Par défaut Facultatif
1.13 Par défaut Facultatif
1.14 Facultatif Par défaut
1.15 Non disponible Par défaut

Qu'est-ce qui change ?

Stackdriver Kubernetes Engine 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 Engine Monitoring à vos clusters :

  • Modifications concernant la navigation : les tableaux de bord Stackdriver Monitoring se trouvent dans un nouveau menu nommé Ressources > Kubernetes Engine NEW (Kubernetes Engine NOUVEAU). Ce tableau de bord n'apparaît pas si vous ne disposez pas de cluster exploitant Stackdriver Kubernetes Engine Monitoring.

  • Modifications concernant les noms des types de ressources surveillées : 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).

  • Modifications concernant les noms des métriques Kubernetes : dans Stackdriver Kubernetes Engine Monitoring, les noms de métriques commencent désormais par le préfixe kubernetes.io/ au lieu de container.googleapis.com/.

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

Modification Ancien Stackdriver (hérité) Stackdriver Kubernetes Engine Monitoring (nouveau)
Menus du tableau de bord Ressources > Kubernetes Engine Ressources > Kubernetes Engine New (Kubernetes Engine nouveau)
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 Engine Monitoring et leur impact sur vos configurations existantes pour la surveillance et la journalisation.

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

Pour identifier les configurations Stackdriver Monitoring et Stackdriver Logging que vous devez mettre à jour dans le cadre de la migration vers Stackdriver Kubernetes Engine Monitoring, procédez comme suit :

  1. Depuis Cloud Console, accédez à la page Monitoring :

    Accéder à Monitoring

  2. Pour consulter l'état de la migration, procédez comme suit :

    • Si l'élément Settings (Paramètres) s'affiche dans le volet de navigation, cliquez sur Settings, puis sélectionnez l'onglet Kubernetes Migration Status (État de la migration Kubernetes).

    • Dans le cas contraire, cliquez sur Menu dans la barre d'outils, sélectionnez Workspace Settings (Paramètres de l'espace de travail), puis Kubernetes Migration Status (État de la migration Kubernetes).

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

Affichage du tableau de bord de migration Stackdriver.

Modifications des types de ressources

Stackdriver Kubernetes Engine 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 ressource Stackdriver Kubernetes Engine Monitoring (nouveau)
Notes de bas de tableau :
1 Dans le nouveau type de ressource 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 ressource 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 Engine Monitoring, les utilisations de nœuds sont modifiées pour utiliser le nouveau type de ressource k8s_node, y compris les journaux de nœud sous 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.
Monitoring uniquement :
gke_container (conteneur GKE)

Libellés :
  cluster_name
  container_name
  instance_id1
  namespace_id
  pod_id
  project_id
  zone2

Logging uniquement :
container (conteneur GKE)

Libellés :
  cluster_name
  container_name
  instance_id1
  namespace_id
  pod_id
  project_id
  zone2

Monitoring et Logging :
k8s_container (conteneur Kubernetes)

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

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

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

Libellés :
  cluster_name
  node_name
  project_id
  location2
 
(aucun)
Monitoring et Logging :
k8s_pod5 (pod Kubernetes)

Libellés :
  cluster_name
  namespace_name
  pod_name
  project_id
  location2

Logging uniquement
gke_cluster (GKE_cluster)

Libellés :
  cluster_name
  project_id
  location

Monitoring et Logging :
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 .

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

Exemples :
  .../container/cpu/utilization
  .../container/uptime
  .../container/memory/bytes_total
Métriques Stackdriver Kubernetes
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 Engine Monitoring. Si votre groupe de ressources inclut des graphiques personnalisés, vous devrez peut-être les modifier également.

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 Engine Monitoring.

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 GKE :

  1. Dans Cloud Console, sélectionnez le projet Google Cloud contenant un cluster GKE à mettre à jour vers Stackdriver Kubernetes Engine Monitoring :

    Accéder à Cloud Console

  2. Sélectionnez Monitoring.

  3. Pour consulter l'état de la migration, procédez comme suit :

    • Si l'élément Settings (Paramètres) s'affiche dans le volet de navigation, cliquez sur Settings, puis sélectionnez l'onglet Kubernetes Migration Status (État de la migration Kubernetes).

    • Dans le cas contraire, cliquez sur Menu dans la barre d'outils, sélectionnez Workspace Settings (paramètres de l'espace de travail), **Kubernetes Migration Status (é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 Engine 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. Un point dont vous devez tenir compte est de savoir quand effectuer ces modifications. 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 règles 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 Engine 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 Engine Monitoring.

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 afin qu'ils correspondent utilisent les types de ressources Stackdriver Kubernetes Engine Monitoring correspondants.

Modifications des contenus d'entrées de journal

Lorsque vous effectuez une mise à jour vers Stackdriver Kubernetes Engine 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 est susceptible de changer. Les entrées de journal Stackdriver Kubernetes Engine 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 du 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 du 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 Engine 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 Engine Monitoring et, à l'occasion, dans certaines entrées de journal Ancien Stackdriver. Dans Stackdriver Kubernetes Engine Monitoring, ce champ permet de conserver certaines informations précédemment contenues dans les champs d'entrée de journal metadata.
Ressources d'entrées de journal
resource.labels (Libellés de ressources1)
Ressources d'entrées de journal
resource.labels (Libellés de ressources1)
Métadonnées d'entrées de journal
labels (Libellés 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

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 Engine 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.