Migrer vers Kubernetes Engine Operations

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 des anciennes fonctionnalités de journalisation et de surveillance à Kubernetes Engine Operations.

Quand dois-je migrer ?

Vous pouvez à tout moment migrer vos configurations Cloud Logging et Cloud Monitoring existantes des anciennes fonctionnalités de journalisation et de surveillance vers Kubernetes Engine Operations. Gardez toutefois à l'esprit que la compatibilité avec les anciennes fonctionnalités de journalisation et de surveillance peut être retirée lors d'une release ultérieure de GKE. Si la compatibilité avec les anciennes fonctionnalités de journalisation et de surveillance est supprimée, vous devez auparavant passer à Kubernetes Engine Operations si vous souhaitez continuer à utiliser Cloud Monitoring et Cloud Logging.

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

Version de GKE Ancienne version de Logging et de Monitoring Kubernetes Engine Operations
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 ?

Kubernetes Engine Operations 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 pour vos clusters utilisant Kubernetes Engine Operations :

  • Modifications concernant la navigation : les tableaux de bord Cloud Monitoring s'appellent Kubernetes Engine Nouveau. Ce tableau de bord n'apparaît pas si vous ne disposez pas de clusters exploitant Kubernetes Engine Operations.

  • 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 Kubernetes Engine Operations, 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 :

Modifier (Ancien) Ancienne version de Logging et de Monitoring (Nouveau) Kubernetes Engine Operations
Menus du tableau de bord Tableaux de bord > Kubernetes Engine Tableaux de bord > Kubernetes Engine New
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 Kubernetes Engine Operations et leurs conséquences sur vos configurations de surveillance et de journalisation existantes.

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

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

  1. Dans Cloud Console, accédez à Monitoring :

    Accéder à Monitoring

  2. Pour accéder à l'état de la migration, dans le volet de navigation Monitoring, cliquez sur Settings (Paramètres), puis sélectionnez l'onglet 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.

Modifications des types de ressources

Kubernetes Engine Operations comporte 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
(Ancien) Type de ressource Logging and Monitoring hérité (Nouveau) Type de ressource Kubernetes Engine Operations
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 Kubernetes Engine Operations, les utilisations liées aux nœuds sont modifiées pour utiliser le nouveau type de ressource k8s_node, y compris les journaux au niveau du 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é des anciennes fonctionnalités de journalisation et de surveillance.
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
  location2

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
(Anciennes) Anciennes métriques relatives aux fonctionnalités Logging et Monitoring (Nouveau) Métriques de Kubernetes Engine Operations
Anciennes métriques GKE
container.googleapis.com/

Exemples :
  .../container/cpu/utilization
  .../container/uptime
  .../container/memory/bytes_total
Métriques Kubernetes Engine Monitoring
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 des anciennes fonctionnalités de journalisation et de surveillance présentés dans le tableau Modifications des types de ressources précédent ou l'une des métriques des anciennes fonctionnalités de journalisation et de surveillance présentées dans le tableau Modifications des noms de métriques précédent, redéfinissez ces types et ces métriques sur les types de ressources et les métriques Kubernetes Engine Operations correspondants. 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 des anciennes fonctionnalités de journalisation et de surveillance présentés dans le tableau Modifications des types de ressources précédent ou l'une des métriques des anciennes fonctionnalités de journalisation et de surveillance présentées dans le tableau Modifications des noms de métriques précédent, redéfinissez ces types et ces métriques sur les types et les métriques Kubernetes Engine Operations correspondants.

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 Kubernetes Engine Operations :

    Accéder à Cloud Console

  2. Sélectionnez Monitoring.

  3. Pour accéder à l'état de la migration, dans le volet de navigation Monitoring, cliquez sur Settings (Paramètres), puis sélectionnez l'onglet 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 des anciennes fonctionnalités de journalisation et de surveillance présentés dans le tableau Modifications des types de ressources précédent ou l'une des métriques des anciennes fonctionnalités de journalisation et de surveillance présentées dans le tableau Modifications des noms de métriques précédent, redéfinissez ces types et ces métriques sur les types et les métriques Kubernetes Engine Operations correspondants.

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 Cloud Logging, et que vous utilisez l'un des types de ressources des anciennes fonctionnalités de journalisation et de surveillance présentés dans le tableau Modifications des types de ressources précédent, redéfinissez ces types sur les types Kubernetes Engine Operations correspondants.

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 des anciennes fonctionnalités de journalisation et de surveillance présenté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 Kubernetes Engine Operations.

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 des anciennes fonctionnalités de journalisation et de surveillance présentés dans le tableau Modifications des types de ressources précédent, modifiez vos filtres d'exportation et d'exclusion afin qu'ils utilisent les types de ressources Kubernetes Engine Operations correspondants.

Modifications des contenus d'entrées de journal

Lorsque vous effectuez une mise à jour vers Kubernetes Engine Operations, 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 de Kubernetes Engine Operations utilisent stdout ou stderr dans leurs noms de journal, tandis que les anciennes fonctionnalités de journalisation et de surveillance utilisaient une plus grande variété de noms, y compris le nom 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
(Ancien) Anciennes entrées du journal Logging et Monitoring (Nouveau) Entrées de journal Kubernetes Engine Operations
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.
2Le champ labels apparaît dans les nouvelles entrées de journal qui font partie de Kubernetes Engine Operations et parfois dans certaines entrées de journal des anciennes fonctionnalités de journalisation et de surveillance. Dans Kubernetes Engine Operations, 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 Cloud Logging, les journaux sont stockés avec le type de ressources qui les a générés. Puisque ces types ont changé dans Kubernetes Engine Operations, veillez à rechercher vos journaux dans les nouveaux types de ressources tels que Kubernetes Container, et non dans les types des anciennes fonctionnalités de journalisation et de surveillance tels que GKE Container.

Étape suivante

  • Pour en savoir plus sur le nouveau tableau de bord Kubernetes Engine Operations, consultez la page Observer le système.