Migrer vers la suite des opérations Cloud pour GKE

Google Kubernetes Engine (GKE) offre deux options de surveillance et de journalisation.

Cette page décrit les différences entre ces deux options, ainsi que les éléments à modifier pour passer des anciennes fonctionnalités Logging et Monitoring à Cloud Operations pour GKE.

Quand dois-je migrer ?

Vous pouvez à tout moment migrer vos configurations Cloud Monitoring et Cloud Logging existantes de l'ancienne version de Logging et de Monitoring vers Cloud Operations pour GKE. Gardez toutefois à l'esprit que les anciennes fonctionnalités Logging et Monitoring ne sont pas compatibles avec GKE version 1.20.

Le tableau suivant récapitule les options de surveillance et de journalisation disponibles dans chaque version de GKE :

Version de GKE Anciennes fonctionnalités de journalisation et de surveillance Suite des opérations Cloud pour GKE
1.14 Disponible Par défaut
1.15 Disponible Par défaut
1.16 Disponible Par défaut
1.17 Disponible Par défaut
1.18 Disponible Par défaut
1.19 Disponible Par défaut
1,20 Non disponible Par défaut

Pour en savoir plus sur l'abandon des anciennes fonctionnalités Logging et Monitoring, consultez le guide Abandon de la compatibilité avec les anciennes fonctionnalités de GKE.

Quels sont les avantages offerts par l'utilisation de la suite d'opérations Cloud pour GKE ?

La suite d'opérations Cloud pour GKE offre de grands avantages, parmi lesquels :

Qu'est-ce qui change ?

La suite d'opérations Cloud pour GKE utilise un modèle de ressources différent de l'ancienne version de Logging et de Monitoring pour organiser ses métriques, journaux et métadonnées. Voici quelques modifications spécifiques apportées à vos clusters utilisant la suite d'opérations Cloud pour GKE :

  • Modification de la navigation : le tableau de bord Cloud Monitoring s'appelle GKE. Ce tableau de bord n'apparaît pas si vous ne disposez pas de clusters utilisant Cloud Operations pour GKE.

  • 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 Cloud Operations pour GKE, les noms de types de métriques commencent maintenant par le préfixe kubernetes.io/ plutôt que container.googleapis.com/.

  • Modifications des métadonnées logEntry : les entrées de journal de la suite d'opérations Cloud pour GKE ont modifié les noms de certains champs de resource.label et labels. Par exemple, le champ resource.labels.namespace_id est remplacé par resource.labels.namespace_name, mais sa valeur n'est pas modifiée.

  • Modifications de logName : Les entrées de journal de la suite d'opérations Cloud pour GKE incluent stdout ou stderr dans les noms de leurs journaux, tandis que les anciennes fonctionnalités Logging et Monitoring utilisent une plus grande variété de noms, y compris le nom du conteneur. Le nom du conteneur est toujours disponible dans la suite d'opérations Cloud pour GKE en guise de libellé de ressource sous la forme resource.labels.container_name.

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

Modifier (Ancien) Ancienne version de Logging et de Monitoring (Nouveau) Cloud Operations pour GKE
Menus du tableau de bord Tableaux de bord > Clusters GKE Tableaux de bord > GKE
Préfixes des métriques container.googleapis.com kubernetes.io
Types de ressources de métriques gke_container
gce_instance
(aucun)
k8s_container
k8s_node
k8s_pod
Types de ressources de journal container
gke_cluster
gce_instance
gke_nodepool
k8s_container
k8s_cluster
gke_cluster (journaux d'audit uniquement)
k8s_node
k8s_pod

Modifications des types de ressources

Cloud Operations pour GKE présente de nouveaux noms et de nouveaux noms à afficher pour les types de ressources, et de nouveaux noms pour 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) Ancien type de ressource Logging et Monitoring (Nouveau) Type de ressource Cloud Operations pour GKE
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 Cloud Operations pour GKE, 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

Que dois-je faire ?

Cette section contient des informations plus spécifiques sur les modifications apportées au modèle de données de la suite d'opérations Cloud pour GKE et sur leurs conséquences sur vos configurations de surveillance et de journalisation existantes.

Pour migrer votre cluster vers la suite d'opérations Cloud pour GKE, procédez comme suit :

  1. Identifiez vos configurations Logging et Monitoring : identifiez les configurations Logging et Monitoring susceptibles d'utiliser des valeurs qui diffèrent entre les anciennes fonctionnalités Logging et Monitoring et la suite d'opérations Cloud pour GKE.

  2. Mettez à jour vos configurations Logging et Monitoring : mettez à jour les configurations Logging et Monitoring pour refléter les modifications présentes dans la suite d'opérations Cloud pour GKE.

  3. Mettez à jour la configuration de votre cluster GKE : mettez à jour votre cluster GKE pour qu'il utilise le paramètre "suite d'opérations Cloud pour GKE".

Comme les modèles de ressources et les logNames diffèrent entre les anciennes fonctionnalités Logging et Monitoring et la suite d'opérations Cloud pour GKE, toutes les configurations Logging ou Monitoring faisant référence aux modifications dans les modèles de ressources doivent également être mises à jour. La migration peut nécessiter la mise à jour des configurations de Logging et Monitoring, y compris, mais sans s'y limiter, des éléments suivants :

  • tableaux de bord personnalisés
  • graphiques
  • filtres de groupe
  • règles d'alerte
  • récepteurs de journaux
  • exclusions de journaux
  • métriques basées sur les journaux dans Cloud Logging et Cloud Monitoring

Identifier les clusters à l'aide des anciennes fonctionnalités Logging et Monitoring

Il existe deux façons d'identifier les clusters d'un projet qui utilisent les anciennes fonctionnalités Logging et Monitoring.

  1. Utiliser l'outil de ligne de commande gcloud par projet

    Vous pouvez utiliser la commande gcloud suivante pour répertorier les valeurs de loggingService et de monitoringService pour chaque cluster du projet actuel.

    gcloud container clusters list | tail +2 | while read name loc rest ; do echo $name ; gcloud container clusters describe $name --zone $loc | egrep 'loggingService|monitoringService' ; echo ; done
    

    Un résultat de la commande semblable au texte ci-dessous doit s'afficher.

      cluster-1
      loggingService: logging.googleapis.com
      monitoringService: monitoring.googleapis.com
    
      cluster-2
      loggingService: logging.googleapis.com/kubernetes
      monitoringService: monitoring.googleapis.com/kubernetes
    
      cluster-3
      loggingService: logging.googleapis.com/kubernetes
      monitoringService: none
    

    Si le résultat d'un cluster contient loggingService: logging.googleapis.com ou monitoringService: monitoring.googleapis.com, le cluster utilise les anciennes fonctionnalités Logging et Monitoring.

    Si le résultat d'un cluster contient loggingService: logging.googleapis.com/kubernetes ou monitoringService:monitoring.googleapis.com/kubernetes, le cluster utilise Cloud Operations pour GKE.

  2. Utiliser le tableau de bord des clusters GKE de Cloud Monitoring

    1. Cliquez sur le tableau de bord des clusters GKE Cloud Monitoring.
    2. Sélectionnez l'espace de travail qui inclut le projet Google Cloud que vous souhaitez examiner pour les clusters exécutant les anciennes fonctionnalités Logging et Monitoring.
    3. Affichez la liste des clusters dans le tableau de bord. Seuls les clusters utilisant les anciennes fonctionnalités Logging et Monitoring s'affichent dans le tableau de bord.

      Par exemple, dans la capture d'écran suivante, quatre clusters utilisent les anciennes fonctionnalités Logging et Monitoring.

      Affichage des clusters utilisant les anciennes solutions.

Migrer vos ressources surveillées

Si vous utilisez les anciennes fonctionnalités Logging et Monitoring avec un cluster GKE dont la version du plan de contrôle est 1.15 ou ultérieure, les métriques de votre cluster sont disponibles dans les anciens modèles de ressources Monitoring et Cloud Operations pour GKE. Cela signifie que même avant la migration de vos clusters vers Cloud Operations pour GKE, vos clusters commencent à générer des métriques à l'aide du nouveau modèle de données, sans frais supplémentaires.

À partir de janvier 2021, vos tableaux de bord et alertes personnalisés seront mis à jour automatiquement pour faire référence aux nouvelles métriques du modèle de ressources. Si vous souhaitez migrer vos propres configurations Cloud Monitoring (graphiques dans les tableaux de bord, alertes et groupes personnalisés), vous devez mettre à jour chaque configuration en fonction du nouveau modèle de ressource.

Vous devez également migrer vos configurations si vous conservez votre configuration dans Terraform ou dans un autre gestionnaire de déploiement et vous synchronisez automatiquement les modifications.

Identifier les configurations pour l'ancien modèle de données

Pour identifier les configurations Cloud Monitoring à mettre à jour dans le cadre de la migration vers Cloud Operations pour GKE, consultez le tableau de bord État de la migration Kubernetes :

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

    Accéder à Monitoring

  2. Dans le volet de navigation de 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 suivant montre qu'une règle d'alerte doit être mise à jour :

Affichage du tableau de bord de migration.

Mettre à jour des configurations Cloud Monitoring

Si votre cluster utilise la version GKE 1.15 ou ultérieure et l'ancienne version de Monitoring, il est publié sur les deux modèles de données. Dans ce cas, deux options s'offrent à vous pour effectuer la migration de vos configurations.

  • Clonez les configurations, puis mettez à jour les clones. Avec cette option, vous créez une copie de vos tableaux de bord, règles d'alerte et groupes existants, puis vous migrez les copies vers le nouveau modèle de ressource. Ainsi, vous pouvez continuer à utiliser Monitoring pour votre cluster en utilisant simultanément l'ancien et le nouveau modèle de données. Par exemple, avec cette option, vous auriez deux tableaux de bord : le tableau de bord d'origine qui continue à utiliser le modèle de ressource d'origine et un clone du tableau de bord d'origine qui utilise le nouveau modèle de ressource.

  • Mettez à niveau les configurations existantes concernées. Cette option passe immédiatement au nouveau modèle de données dans Cloud Monitoring.

Les sections suivantes fournissent des instructions concernant la migration de vos configurations pour les tableaux de bord, les règles d'alerte et les groupes.

Lors du choix de l'option, il convient de prendre en compte la part de l'historique de surveillance que vous souhaitez rendre disponible. Actuellement, Cloud Monitoring propose six semaines de données d'historique pour vos clusters. Après la mise à niveau du cluster GKE qui commence à écrire deux fois dans les modèles de données, l'ancien modèle de données dispose toujours des métriques historiques du cluster, tandis que le nouveau modèle de données ne comporte que des métriques qui commencent au moment de la mise à niveau.

Si vous n'avez pas besoin des données de l'historique, vous pouvez à tout moment mettre à niveau les configurations existantes vers le nouveau modèle de données. Si les données de l'historique sont importantes, vous pouvez cloner les configurations et mettre à jour les clones pour utiliser les nouveaux types de modèles de ressources.

Vous pouvez également attendre six semaines après que votre cluster a commencé à écrire deux fois dans les deux modèles de données. Après six semaines, les deux modèles de données ont les mêmes données historiques. Vous pouvez donc mettre à niveau les configurations existantes et passer au nouveau modèle de données.

Mettre à jour des tableaux de bord

Pour afficher vos tableaux de bord, procédez comme suit :

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

    Accéder à Monitoring

  2. Sélectionnez Tableaux de bord.

Pour cloner un tableau de bord et mettre à jour le clone, procédez comme suit :

  1. Recherchez le tableau de bord que vous souhaitez cloner.

  2. Cliquez sur Copier le tableau de bord (), puis saisissez un nom pour le tableau de bord cloné.

  3. Mettez à jour les configurations du nouveau tableau de bord si nécessaire.

Pour mettre à jour les définitions de graphiques dans le tableau de bord, procédez comme suit :

  1. Cliquez sur Autres options de graphique (⋮) pour le graphique que vous souhaitez modifier.

  2. Sélectionnez Modifier pour ouvrir le panneau Modifier le graphique.

  3. Modifiez le type de ressource et le nom de la métrique à convertir dans le nouveau modèle de données. Vous pouvez également mettre à jour les champs Filtre et Grouper par selon vos besoins.

Mettre à jour les règles d'alerte

Pour afficher vos règles d'alerte, procédez comme suit :

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

    Accéder à Monitoring

  2. Sélectionnez Alertes.

Pour cloner et mettre à jour une règle d'alerte, procédez comme suit :

  1. Sélectionnez la règle que vous souhaitez cloner dans le tableau Règles.

  2. Cliquez sur Copier pour lancer le flux de création de copie de la règle d'alerte.

  3. Modifiez les conditions faisant référence à l'ancien modèle de données pour mettre à jour le type de ressource et le nom de la métrique.

    La dernière étape du flux vous permet de saisir un nom pour la règle clonée.

Pour modifier une règle d'alerte en place, procédez comme suit :

  1. Sélectionnez la règle que vous souhaitez modifier dans la table Règles.

  2. Cliquez sur Modifier pour mettre à jour la règle.

  3. Mettez à jour les conditions qui font référence à l'ancien modèle de données.

Mettre à jour les groupes

Vous ne pouvez pas cloner de groupe via Google Cloud Console. Par conséquent, si vous souhaitez dupliquer un groupe, vous devez créer un groupe avec le même filtre.

Un filtre de groupe peut faire référence à l'ancien modèle de données de plusieurs manières.

  • Type de ressource : un groupe peut définir un filtre resource.type="gke_container". Comme le type gke_container peut être utilisé pour faire référence à différents types d'entités GKE, vous devez mettre à jour le filtre en fonction du type de ressource que vous souhaitez réellement mettre en correspondance : k8s_container, k8s_pod ou k8s_node. Si vous souhaitez faire correspondre plusieurs types, définissez un filtre avec plusieurs clauses combinées à l'opérateur OR.

  • Libellé cloud_account : un groupe peut définir un filtre resource.metadata.cloud_account="<var>CLOUD_ACCOUNT_ID</<var>". Dans le cadre d'un abandon séparé, le champ de métadonnées cloud_account n'est plus disponible. Pensez à utiliser le libellé resource.labels.project_id.

  • Libellé region : un groupe peut définir un filtre resource.metadata.region="<var>REGION_NAME</<var>". Le champ de métadonnées region n'est plus disponible dans le nouveau modèle de données. Si vous souhaitez faire correspondre des entités GKE en fonction de l'emplacement géographique, pensez à utiliser le libellé resource.labels.location.

Mapper des métriques entre les modèles de données

Cette section explique comment mapper les métriques de l'ancien modèle de données aux métriques du nouveau modèle de données. L'ancien modèle de données a publié 17 métriques différentes, répertoriées dans les tableaux ci-dessous. Certaines de ces métriques ont été publiées sur plusieurs types d'entités GKE, ce qui génère plus de 17 mappages pour convertir toutes les métriques.

Lorsque vous mappez des métriques, tenez compte des points suivants :

  • Le préfixe des anciennes métriques est container.googleapis.com/. Le préfixe des nouvelles métriques est kubernetes.io/.

  • Dans l'ancien modèle de données, le seul type de ressource est gke_container. Selon la manière dont vous avez défini les libellés de ressources, ce type de ressource peut faire référence à des conteneurs, pods, daemons système et machines GKE, qui correspondent aux nœuds GKE.

  • Vous pouvez interroger l'API Monitoring à l'aide de combinaisons de pod_id et container_name qui ne correspondent pas à celles répertoriées dans le tableau suivant. Les données renvoyées par ces requêtes ne sont pas définies, et aucun mappage de ces états non définis n'est fourni.

    Type d'entité GKE Filtre
    Conteneur pod_id != '' et container_name != ''
    (pod_id n'est pas une chaîne vide et container_name n'est pas une chaîne vide)
    Pod pod_id != '' et container_name == ''
    (pod_id n'est pas la chaîne vide et container_name est la chaîne vide)
    Daemon système pod_id == '' et container_name != 'machine'
    (pod_id est la chaîne vide et container_name correspond à docker-daemon, kubelets ou pods)
    Machine pod_id == '' et container_name == 'machine'
    (pod_id est la chaîne vide et container_name est la chaîne machine)

Les tableaux répertorient trois types de mappages :

  • Mappage direct entre l'ancien et le nouveau modèle.

  • Mappages qui nécessitent une configuration.

  • Mappages d'anciennes métriques n'ayant pas d'équivalent direct dans le nouveau modèle.

Mappage direct

Les métriques suivantes se traduisent directement entre l'ancien et le nouveau modèle.

Ancien nom de la métrique Ancien type d'entité GKE Nom de la nouvelle métrique Nouveau type de ressource GKE Remarques
container/accelerator/
duty_cycle
Conteneur container/accelerator/
duty_cycle
k8s_container
container/accelerator/
memory_total
Conteneur container/accelerator/
memory_total
k8s_container
container/accelerator/
memory_used
Conteneur container/accelerator/
memory_used
k8s_container
container/accelerator/
request
Conteneur container/accelerator/
request
k8s_container
container/cpu/
reserved_cores
Conteneur container/cpu/
limit_cores
k8s_container Consultez la section Mappages nécessitant une configuration pour le mappage lorsque la ressource est pod.
container/cpu/
usage_time
Conteneur container/cpu/
core_usage_time
k8s_container Consultez la section Mappages nécessitant une configuration pour le mappage lorsque la ressource est pod.
container/cpu/
usage_time
Daemon système node_daemon/cpu/
core_usage_time
k8s_node Dans l'ancien modèle de données,
gke_container.container_name correspond à docker-daemon, kubelets ou pods. Ces valeurs de filtre correspondent à celles du nouveau champ de modèle de données metric.component.
container/cpu/
utilization
Conteneur container/cpu/
limit_utilization
k8s_container
container/disk/
bytes_total
Pod pod/volume/
total_bytes
k8s_pod gke_container.device_name (Volume:config-volume) est traduit en k8s_pod.volume_name (config-volume) en supprimant le préfixe Volume: qui a été ajouté.
container/disk/bytes_used Pod pod/volume/
used_bytes
k8s_pod gke_container.device_name (Volume:config-volume) est traduit en k8s_pod.volume_name (config-volume) en supprimant le préfixe Volume: qui a été ajouté.
container/memory/
bytes_total
Conteneur container/memory/
limit_bytes
k8s_container
container/memory/
bytes_used
Conteneur container/memory/
used_bytes
k8s_container
container/memory/
bytes_used
Daemon système node_daemon/memory/
used_bytes
k8s_node Dans l'ancien modèle de données,
gke_container.container_name correspond à docker-daemon, kubelets ou pods. Ces valeurs de filtre correspondent à celles du nouveau champ de modèle de données metric.component.
container/disk/
inodes_free
Machine node/ephemeral_storage/
inodes_free
k8s_node L'ancien modèle de données comporte le champ instance_id, un identifiant de nombre aléatoire. Le nouveau modèle de données a node_name, un nom lisible.
container/disk/
inodes_total
Machine node/ephemeral_storage/
inodes_total
k8s_node L'ancien modèle de données comporte le champ instance_id, un identifiant de nombre aléatoire. Le nouveau modèle de données a node_name, un nom lisible.
container/pid_limit Machine node/pid_limit k8s_node L'ancien modèle de données comporte le champ instance_id, un identifiant de nombre aléatoire. Le nouveau modèle de données a node_name, un nom lisible.
container/pid_used Machine node/pid_used k8s_node L'ancien modèle de données comporte le champ instance_id, un identifiant de nombre aléatoire. Le nouveau modèle de données a node_name, un nom lisible.
Mappages qui nécessitent une configuration

Les métriques suivantes sont converties de l'ancien vers le nouveau modèle de données, avec une manipulation basique.

Ancien nom de la métrique Ancien type d'entité GKE Nom de la nouvelle métrique Nouveau type de ressource GKE Remarques
container/cpu/
reserved_cores
Pod SUM container/cpu/limit_cores
GROUP BY pod_name
k8s_container L'ancien modèle de données comporte un champ pod_id, un UUID. Le nouveau modèle de données a pod_name, un nom lisible.
container/cpu/
usage_time
Pod SUM container/cpu/core_usage_time
GROUP BY pod_name
k8s_container L'ancien modèle de données comporte un champ pod_id, un UUID. Le nouveau modèle de données a pod_name, un nom lisible.
container/disk/
bytes_total
Conteneur node/ephemeral_storage/
total_bytes
k8s_container gke_container.device_name correspond aux / ou logs. Chacune de ces valeurs est égale à la nouvelle valeur.
container/disk/
bytes_used
Conteneur container/ephemeral_storage/
used_bytes
k8s_container gke_container.device_name correspond aux / ou logs. Vous devez ajouter ces deux valeurs pour obtenir la nouvelle valeur. Dans le nouveau modèle de données, vous ne pouvez pas obtenir la valeur séparément de / et logs.
container/memory/
bytes_total
Pod SUM container/memory/limit_bytes
GROUP BY pod_name
k8s_container L'ancien modèle de données comporte un champ pod_id, un UUID. Le nouveau modèle de données a pod_name, un nom lisible.
container/memory/
bytes_used
Pod SUM container/memory/used_bytes
GROUP BY pod_name
k8s_container L'ancien modèle de données comporte un champ pod_id, un UUID. Le nouveau modèle de données a pod_name, un nom lisible.
Mappages n'ayant pas d'équivalent direct dans le nouveau modèle

Les métriques suivantes n'ont pas d'équivalent dans le nouveau modèle de données.

Utilisation du processeur pour le pod
Dans l'ancien modèle de données, cette métrique, basée sur la limite du processeur de chaque conteneur, représente une moyenne pondérée d'utilisation du processeur dans tous les conteneurs d'un pod.
Dans le nouveau modèle de données, cette valeur n'existe pas. Elle doit être calculée côté client en fonction de la limite et de l'utilisation de chaque conteneur.
Disponibilité
Dans l'ancien modèle de données, cette métrique correspond à une métrique cumulative représentant la fraction de temps pendant laquelle un conteneur est disponible en unités ms/s. Pour un conteneur toujours disponible, la valeur est d'environ 1 000 ms/s.
Dans le nouveau modèle de données, cette métrique correspond à une métrique de jauge en heures qui indique la durée d'exécution de chaque partie du système sans interruption.

Modifications des groupes de ressources

Si vous définissez vos propres groupes de ressources et utilisez certains des types de ressources des anciennes fonctionnalités Logging et Monitoring affichés dans le tableau Modifications des types de ressources précédent, modifiez-les pour les faire correspondre aux types de ressources de la suite d'opérations Cloud pour GKE. Si votre groupe de ressources inclut des graphiques personnalisés, vous devrez peut-être les modifier également.

Migrer vos ressources de journalisation

Pour migrer vos ressources de journalisation, suivez la procédure décrite dans les sections suivantes.

Modifications des contenus d'entrées de journal

Lorsque vous effectuez une mise à jour vers Cloud Operations pour GKE, 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é :

  • Vérifiez le champ logName dans vos filtres. Les entrées de journal de la suite d'opérations Cloud pour GKE utilisent stdout ou stderr dans leurs noms de journaux, alors que les anciennes fonctionnalités Logging et Monitoring utilisaient une plus grande variété de noms, y compris le nom du 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 de journal Logging et Monitoring (Nouveau) Entrées de journal Cloud Operations for GKE
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 Cloud Operations pour GKE et, à l'occasion, dans certaines anciennes entrées de journal Logging et Monitoring. Dans Cloud Operations pour GKE, 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 des entrées de journal
labels

libellés (Exemples)
  k8s-pod/app:
    "currencyservice"

  k8s-pod/pod-template-hash:
    "5a67f17c"

Exemples de journaux :

Modifications des types de ressources du conteneur :

Le texte en rouge et en gras met en évidence les différences entre les anciennes fonctionnalités Logging et Monitoring et la suite d'opérations Cloud pour GKE.

Modèle de ressource Exemples de journaux
Anciennes fonctionnalités de journalisation et de surveillance

{
  "insertId": "fji4tsf1a8o5h",
  "jsonPayload": {
    "pid": 1,
    "name": "currencyservice-server",
    "v": 1,
    "message": "conversion request successful",
    "hostname": "currencyservice-6995d74b95-zjkmj"
  },
  "resource": {
    "type": "container",
    "labels": {
      "project_id": "my-test-project",
      "cluster_name": "my-test-cluster",
      "pod_id": "currencyservice-6995d74b95-zjkmj",
      "zone": "us-central1-c",
      "container_name": "server",
      "namespace_id": "default",
      "instance_id": "1234567890"
    }
  },
  "timestamp": "2020-10-02T19:02:47.575434759Z",
  "severity": "INFO",
  "labels": {
    "container.googleapis.com/pod_name": "currencyservice-6995d74b95-zjkmj",
    "compute.googleapis.com/resource_name": "gke-legacy-cluster-default-pool-c534acb8-hvxk",
    "container.googleapis.com/stream": "stdout",
    "container.googleapis.com/namespace_name": "default"
  },
  "logName": "projects/my-test-project/logs/server",
  "receiveTimestamp": "2020-10-02T19:02:50.972304596Z"
}
Suite des opérations Cloud pour GKE

{
  "insertId": "mye361s5zfcl55amj",
  "jsonPayload": {
    "v": 1,
    "name": "currencyservice-server",
    "pid": 1,
    "hostname": "currencyservice-5b69f47d-wg4zl",
    "message": "conversion request successful"
  },
  "resource": {
    "type": "k8s_container",
    "labels": {
      "container_name": "server",
      "project_id": "my-test-project",
      "pod_name": "currencyservice-5b69f47d-wg4zl",
      "namespace_name": "onlineboutique",
      "location": "us-central1-c",
      "cluster_name": "my-prod-cluster"

    }
  },
  "timestamp": "2020-10-02T18:41:55.359669767Z",
  "severity": "INFO",
  "labels": {
    "k8s-pod/app": "currencyservice",
    "k8s-pod/pod-template-hash": "5b69f47d",
    "compute.googleapis.com/resource_name": "gke-legacy-cluster-default-pool-c534acb8-hvxk"
  },
  "logName": "projects/my-test-project/logs/stdout",
  "receiveTimestamp": "2020-10-02T18:41:57.930654427Z"
}

Modifications des types de ressources du cluster :

Le texte en rouge et en gras met en évidence les différences entre les anciennes fonctionnalités Logging et Monitoring et la suite d'opérations Cloud pour GKE.

Modèle de ressource Exemples de journaux
Anciennes fonctionnalités de journalisation et de surveillance

{
  "insertId": "962szqg9uiyalt",
  "jsonPayload": {
    "type": "Normal",
    "involvedObject": {
      "apiVersion": "policy/v1beta1",
      "uid": "a1bc2345-12ab-12ab-1234-123456a123456",
      "resourceVersion": "50968",
      "kind": "PodDisruptionBudget",
      "namespace": "knative-serving",
      "name": "activator-pdb"
    },
    "apiVersion": "v1",
    "reason": "NoPods",
    "source": {
      "component": "controllermanager"
    },
    "message": "No matching pods found",
    "kind": "Event",
    "metadata": {
      "selfLink": "/api/v1/namespaces/knative-serving/events/activator-pdb.163a42fcb707c1fe",
      "namespace": "knative-serving",
      "name": "activator-pdb.163a42fcb707c1fe",
      "uid": "a1bc2345-12ab-12ab-1234-123456a123456",
      "creationTimestamp": "2020-10-02T19:17:50Z",
      "resourceVersion": "1917"
    }
  },
  "resource": {
    "type": "gke_cluster",
    "labels": {
      "project_id": "my-test-project",
      "location": "us-central1-c",
      "cluster_name": "my-prod-cluster"
    }
  },
  "timestamp": "2020-10-02T21:33:20Z",
  "severity": "INFO",
  "logName": "projects/my-test-project/logs/events",
  "receiveTimestamp": "2020-10-02T21:33:25.510671123Z"
}
Suite des opérations Cloud pour GKE

{
  "insertId": "1qzipokg6ydoesp",
  "jsonPayload": {
    "involvedObject": {
      "uid": "a1bc2345-12ab-12ab-1234-123456a123456",
      "name": "istio-telemetry",
      "apiVersion": "autoscaling/v2beta2",
      "resourceVersion": "90505937",
      "kind": "HorizontalPodAutoscaler",
      "namespace": "istio-system"
    },
    "source": {
      "component": "horizontal-pod-autoscaler"
    },
    "kind": "Event",
    "type": "Warning",
    "message": "missing request for cpu",
    "metadata": {
      "resourceVersion": "3071416",
      "creationTimestamp": "2020-08-22T14:18:59Z",
      "name": "istio-telemetry.162d9ce2894d6642",
      "selfLink": "/api/v1/namespaces/istio-system/events/istio-telemetry.162d9ce2894d6642",
      "namespace": "istio-system",
      "uid": "a1bc2345-12ab-12ab-1234-123456a123456"
    },
    "apiVersion": "v1",
    "reason": "FailedGetResourceMetric"
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "project_id": "my-test-project"
      "location": "us-central1-a",
      "cluster_name": "my-prod-cluster1",
    }
  },
  "timestamp": "2020-10-02T21:39:07Z",
  "severity": "WARNING",
  "logName": "projects/my-test-project/logs/events",
  "receiveTimestamp": "2020-10-02T21:39:12.182820672Z"
}
   

Modifications des types de ressources de nœud :

Le texte en rouge et en gras met en évidence les différences entre les anciennes fonctionnalités Logging et Monitoring et la suite d'opérations Cloud pour GKE.

Modèle de ressource Exemples de journaux
Anciennes fonctionnalités de journalisation et de surveillance

{
  "insertId": "16qdegyg9t3n2u5",
  "jsonPayload": {
    "SYSLOG_IDENTIFIER": "kubelet",
    [...]
    "PRIORITY": "6",
    "_COMM": "kubelet",
    "_GID": "0",
    "_MACHINE_ID": "9565f7c82afd94ca22612c765ceb1042",
    "_SYSTEMD_UNIT": "kubelet.service",
    "_EXE": "/home/kubernetes/bin/kubelet"
  },
  "resource": {
    "type": "gce_instance",
    "labels": {
      "instance_id": "1234567890",
      "zone": "us-central1-a",
      "project_id": "my-test-project"
    }
  },
  "timestamp": "2020-10-02T21:43:14.390150Z",
  "labels": {
    "compute.googleapis.com/resource_name": "gke-legacy-monitoring-default-pool-b58ff790-29rr"
  },
  "logName": "projects/my-test-project/logs/kubelet",
  "receiveTimestamp": "2020-10-02T21:43:20.433270911Z"
}
   
Suite des opérations Cloud pour GKE

{
  "insertId": "kkbgd6e5tmkpmvjji",
  "jsonPayload": {
    "SYSLOG_IDENTIFIER": "kubelet",
   [...]
    "_CAP_EFFECTIVE": "3fffffffff",
    "_HOSTNAME": "gke-standard-cluster-1-default-pool-f3929440-f4dy",
    "PRIORITY": "6",
    "_COMM": "kubelet",
    "_TRANSPORT": "stdout",
    "_GID": "0",
    "MESSAGE": "E1002 21:43:14.870346    1294 pod_workers.go:190] Error syncing pod 99ba1919-d633-11ea-a5ea-42010a800113 (\"stackdriver-metadata-agent-cluster-level-65655bdbbf-v5vjv_kube-system(99ba1919-d633-11ea-a5ea-42010a800113)\"), skipping: failed to \"StartContainer\" for \"metadata-agent\" with CrashLoopBackOff: \"Back-off 5m0s restarting failed container=metadata-agent pod=stackdriver-metadata-agent-cluster-level-65655bdbbf-v5vjv_kube-system(99ba1919-d633-11ea-a5ea-42010a800113)\""
  },
  "resource": {
    "type": "k8s_node",
    "labels": {
      "cluster_name": "my-prod-cluster-1",
      "location": "us-central1-a",
      "node_name": "gke-standard-cluster-1-default-pool-f3929440-f4dy"
       "project_id": "my-test-project",
    }
  },
  "timestamp": "2020-10-02T21:43:14.870426Z",
  "logName": "projects/my-test-project/logs/kubelet",
  "receiveTimestamp": "2020-10-02T21:43:20.788933199Z"
}

Mises à jour de la configuration de Logging

Cette section décrit les modifications que vous devrez peut-être apporter à votre configuration Cloud Logging dans le cadre d'une migration vers Cloud Operations pour GKE. Vous devez également migrer vos configurations si vous conservez votre configuration dans Terraform ou dans un autre gestionnaire de déploiement et vous synchronisez automatiquement les modifications.

Journalisation des requêtes

Si vous utilisez des requêtes pour rechercher et filtrer vos journaux dans Cloud Logging et utilisez l'un des types de ressources des anciennes fonctionnalités Logging et Monitoring affichés dans le tableau Modifications des types de ressources précédent, modifiez ces types pour les faire correspondre à ceux de la suite d'opérations Cloud pour GKE.

Par exemple, dans les anciennes fonctionnalités Logging et Monitoring, vous interrogez les journaux de conteneur utilisant le type de ressource container lorsque vous êtes dans la suite d'opérations Cloud pour GKE et utilisez le type de ressource k8s_container pour interroger les journaux de conteneur.

  resource.type="k8s_container"

Autre exemple, dans les anciennes fonctionnalités Logging et Monitoring, vous interrogez des noms de journaux spécifiques pour les conteneurs utilisant le nom du conteneur. Dans la suite d'opérations Cloud pour GKE, vous utilisez les noms des journaux stdout et stderr permettant d'interroger les journaux de conteneur.

  resource.type="k8s_container"
  log_name="projects/YOUR_PROJECT_NAME/logs/stdout"
  resource.labels.container_name="CONTAINER_NAME"

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 Logging et Monitoring affichés dans le tableau Modifications des noms de métriques et Modification des types de ressources précédents, modifiez-les pour les faire correspondre à ceux de la suite d'opérations Cloud pour GKE.

Vous pouvez rechercher vos métriques basées sur les journaux à l'aide de la commande suivante de l'outil gcloud :

  gcloud logging metrics list --filter='filter~resource.type=\"container\" OR filter~resource.type=container'

  gcloud logging metrics list --filter='filter~resource.labels.namespace_id'

  gcloud logging metrics list --filter='filter~resource.labels.pod_id'

  gcloud logging metrics list --filter='filter~resource.labels.zone'

Vous pouvez mettre à jour vos métriques basées sur les journaux à l'aide de la commande suivante de l'outil gcloud :

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.type=\"container\" OR resource.type=\"k8s_container\"'

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.namespace_id=\"YOUR_NAMESPACE\" OR resource.labels.namespace_name=\"YOUR_NAMESPACE\"'

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.pod_id=\"YOUR_POD_NAME\" OR resource.labels.pod_name=\"YOUR_NAME\"'

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.zone=\"YOUR_ZONE\" OR resource.labels.location=\"YOUR_ZONE\"'

Vous pouvez également mettre à jour vos métriques basées sur les journaux dans Cloud Console.

Exportation de journaux

Si vous exportez l'un de vos journaux en utilisant les types de ressources des anciennes fonctionnalités Logging et Monitoring affichés dans le tableau Modifications des types de ressources précédent, modifiez votre exportation afin d'utiliser les types de ressources de la suite d'opérations Cloud pour GKE correspondants. Les entrées de journal de la suite d'opérations Cloud pour GKE utilisent stdout ou stderr dans leurs noms de journal, tandis que les anciennes fonctionnalités Logging et Monitoring utilisent le nom du conteneur.

Deux éléments importants doivent être pris en compte lors de la modification du nom du journal :

  1. Modifications apportées à l'exportation des tables et des emplacements de fichiers de destination : les valeurs de nom de journal dans la suite d'opérations Cloud pour GKE incluent stdout ou stderr plutôt que le nom du conteneur. Le nom du conteneur est toujours disponible en tant que libellé de ressource. Le traitement du nom de journal dans les exportations Cloud Storage ou les requêtes sur les tables BigQuery doivent être modifiés pour utiliser les noms de journaux stdout et stderr.
  2. Valeurs logName : les valeurs de nom de journal permettent de déterminer la structure des fichiers exportés dans Cloud Storage et la structure des tables dans BigQuery. L'utilisation des fichiers Cloud Storage et des tables BigQuery doit être ajustée pour tenir compte de la structure des dossiers dans Cloud Storage et de la structure des tables dans BigQuery.

Pour localiser les récepteurs Logging concernés, utilisez les commandes suivantes de l'outil de ligne de commande gcloud :

  gcloud logging sinks list --filter='filter~resource.type=\"container\" OR filter~resource.type=container'

  gcloud logging sinks list --filter='filter~resource.labels.namespace_id'

  gcloud logging sinks list --filter='filter~resource.labels.pod_id'

  gcloud logging sinks list --filter='filter~resource.labels.zone'

Vous pouvez utiliser la commande suivante de l'outil gcloud pour mettre à jour vos récepteurs Logging.

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.type=\"container\" OR resource.type=\"k8s_container\"'

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.namespace_id=\"YOUR_NAMESPACE\" OR resource.labels.namespace_name=\"YOUR_NAMESPACE\"'

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.pod_id=\"YOUR_POD_NAME\" OR resource.labels.pod_name=\"YOUR_NAME\"'

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.zone=\"YOUR_ZONE\" OR resource.labels.location=\"YOUR_ZONE\"'

Vous pouvez également mettre à jour vos métriques basées sur les journaux dans Cloud Console.

Exclusion de journaux

Si vous excluez l'un de vos journaux et si vos filtres d'exclusion utilisent les types de ressources des anciennes fonctionnalités Logging et Monitoring affichés dans le tableau Modifications des types de ressources précédent, modifiez vos filtres d'exclusion pour les faire correspondre à ceux de la suite d'opérations Cloud pour GKE.

Pour en savoir plus sur l'affichage des exclusions de journaux, reportez-vous au guide Afficher les filtres d'exclusion.

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 Cloud Operations pour GKE, 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.

Mettre à jour la configuration de votre cluster

Après avoir migré tous les journaux et surveillé les ressources pour utiliser le format de données de la suite d'opérations Cloud pour GKE, la dernière étape consiste à mettre à jour votre cluster GKE pour qu'il utilise la suite d'opérations Cloud pour GKE.

Pour mettre à jour la configuration de journalisation et de surveillance de votre cluster GKE, procédez comme suit :

CONSOLE

  1. Accédez à la page Clusters GKE de votre projet. Le bouton suivant vous y emmène :

    Accéder à la page "Clusters Kubernetes"

  2. Cliquez sur le cluster que vous souhaitez mettre à jour afin d'utiliser la suite d'opérations Cloud pour GKE.

  3. Sur la ligne intitulée Suite d'opérations Cloud pour GKE, cliquez sur l'icône Modifier.

  4. Dans la boîte de dialogue qui s'affiche, vérifiez que l'option Activer la suite des opérations Cloud pour GKE est sélectionnée.

  5. Dans le menu déroulant de cette boîte de dialogue, sélectionnez les journaux et les métriques que vous souhaitez collecter. Le paramètre par défaut (recommandé) de la suite d'opérations Cloud pour GKE est la journalisation et la surveillance du système et de la charge de travail. Si vous sélectionnez une valeur dans cette liste déroulante autre que "Ancienne fonctionnalité Logging et Monitoring", le cluster sera mis à jour pour commencer à utiliser la suite d'opérations Cloud pour GKE plutôt que les anciennes fonctionnalités Logging et Monitoring.

  6. Cliquez sur Enregistrer les modifications.

GCLOUD

  1. Exécutez cette commande :

    gcloud container clusters update [CLUSTER_NAME] \
      --zone=[ZONE] \
      --project=[PROJECT_ID] \
      --enable-stackdriver-kubernetes
    

Étape suivante