Surveiller des clusters GKE pour l'optimisation des coûts à l'aide de Cloud Monitoring

Ce tutoriel explique comment surveiller vos clusters Google Kubernetes Engine (GKE) afin d'optimiser l'utilisation des ressources. Ce type d'optimisation est généralement une tâche complexe, car vous souhaitez réduire les coûts en réduisant la consommation de ressources sans compromettre la stabilité ni les performances de vos applications. Ce tutoriel vous guide tout au long d'un processus de configuration de tableaux de bord et de règles d'alerte dans le cas des causes les plus courantes de surprovisionnement sur GKE. Ce tutoriel fournit également des recommandations concernant les ressources, afin que vos applications puissent fonctionner de manière fiable et optimisée en termes de coûts.

Ce tutoriel est destiné aux développeurs et aux opérateurs qui souhaitent optimiser leurs clusters et applications GKE pour obtenir des coûts faibles, de hautes performances et une application hautement stable. Dans ce tutoriel, nous partons du principe que vous connaissez Docker, Kubernetes, les tâches Cron Kubernetes, GKE, Cloud Monitoring et Linux.

Présentation

L'optimisation des coûts est généralement interprétée à tort comme un processus ponctuel visant à réduire les coûts. Toutefois, comme le définit Gartner, l'optimisation des coûts est une discipline continue qui doit également maximiser la valeur commerciale. Lorsque vous mettez en œuvre une telle discipline dans le monde de Kubernetes, d'autres points de vue sont également importants.

Équilibrer quatre objectifs différents : réduire les coûts, atteindre les objectifs de performances, atteindre la stabilité et maximiser les résultats commerciaux

Comme le montre ce schéma, l'optimisation des coûts sur Kubernetes nécessite d'équilibrer quatre objectifs différents : réduire les coûts, atteindre les objectifs de performances, atteindre la stabilité et maximiser les résultats commerciaux. En d'autres termes, la réduction des coûts ne doit pas se faire au détriment de l'expérience utilisateur ou des performances de votre entreprise, sauf si cet impact est bien compris et délibéré.

Google Cloud fournit les outils nécessaires pour atteindre ces objectifs. Toutefois, toutes les équipes qui adoptent des solutions cloud comme Kubernetes pour leurs charges de travail ne disposent pas de l'expertise nécessaire pour atteindre leurs objectifs de performances et de stabilité. Souvent, leur solution consiste à surprovisionner leurs environnements afin de limiter l'impact sur votre activité.

Le surprovisionnement peut fournir une aide à court terme, mais au prix d'un coût plus élevé. Utilisez cette solution avec prudence et uniquement dans le cadre d'un processus d'optimisation continue des coûts. L'image suivante montre les quatre problèmes principaux rencontrés par les équipes qui entament ce type de démarche d'optimisation des coûts.

Les quatre principaux problèmes détectés par les équipes : culture, bin-packing (distribution), redimensionnement des applications et scaling à la baisse hors heures creuses.

  • Le premier problème est culturel. De nombreuses équipes qui adoptent le cloud public ne sont pas habituées au style de facturation à l'utilisation et, bien souvent, elles ne comprennent pas parfaitement l'environnement sur lequel leurs applications s'exécutent (dans le cas présent, Kubernetes). Le mouvement FinOps, qui a suscité beaucoup d'attention récemment, a pour objectif de faire évoluer cette culture. Une bonne pratique de FinOps consiste à fournir aux équipes des informations en temps réel sur leurs dépenses et leur impact sur l'entreprise. De petits éléments tels que ceux-ci ont un impact considérable sur la culture des entreprises, ce qui se traduit par une équation d'optimisation des coûts plus équilibrée.

  • Le deuxième problème concerne le bin-packing. Le bin-packing permet d'empaqueter des applications dans des nœuds GKE. Plus vous empaquetez vos applications dans des nœuds, plus vous économisez.

  • Le troisième problème concerne le redimensionnement d'une application. Le redimensionnement permet de configurer la requête de ressource et la cible d'autoscaling des charges de travail appropriées pour les objets déployés dans le cluster. Plus vous définissez précisément les ressources appropriées sur les pods, plus votre application s'exécute de manière fiable et, dans la plupart des cas, plus vous ouvrez d'espace dans le cluster.

  • Le dernier problème réside dans le fait d'effectuer le scaling à la baisse du cluster hors heures creuses. Dans l'idéal, pour économiser de l'argent en période de faible demande (par exemple, la nuit), votre cluster doit pouvoir effectuer un scaling à la baisse en fonction de la demande réelle. Cependant, dans certains cas, le scaling à la baisse ne se produit pas comme prévu en raison des charges de travail ou des configurations de cluster qui bloquent l'autoscaler de cluster (CA).

Afin d'optimiser efficacement les coûts de votre environnement, vous devez travailler en permanence sur ces problèmes. Pour vous permettre de vous concentrer sur les tâches pratiques, le reste de ce tutoriel ignore le problème culturel et vous explique comment utiliser Cloud Monitoring pour surveiller le bin-packing et le redimensionnement des applications dans un cluster GKE. Pour en savoir plus sur l'optimisation des coûts de votre cluster lors des périodes de faible demande, consultez la section Réduire les coûts en effectuant un scaling à la baisse des clusters GKE pendant les heures creuses.

Objectifs

  • Créer un cluster GKE
  • Déployer un exemple d'application
  • Configurer les composants pour exporter les métriques requises vers Cloud Monitoring
  • Générer de manière dynamique des tableaux de bord pour surveiller l'utilisation et les recommandations de ressources.
  • Générer de manière dynamique des règles d'alerte en cas de surprovisionnement ou de sous-provisionnement.

Coûts

Ce tutoriel utilise les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Avant de commencer

  1. Dans Google Cloud Console, accédez à la page de sélection du projet.

    Accéder au sélecteur de projet

  2. Sélectionnez ou créez un projet Google Cloud.

  3. Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier que la facturation est activée pour votre projet.

Une fois que vous avez terminé ce tutoriel, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Consultez la page Effectuer un nettoyage pour en savoir plus.

Préparer l'environnement

  1. Dans Cloud Console, ouvrez Cloud Shell. Dans ce tutoriel, vous allez exécuter des commandes dans Cloud Shell.

    En bas de la fenêtre de Cloud Console, une session Cloud Shell s'ouvre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel le SDK Cloud est déjà installé (y compris l'outil de ligne de commande gcloud), et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

  2. Dans Cloud Shell, configurez l'ID de votre projet Cloud et votre adresse e-mail, puis activez les API Compute Engine, GKE et Cloud Monitoring :

    PROJECT_ID=YOUR_PROJECT_ID
    ALERT_EMAIL=YOUR_EMAIL_ADDRESS
    CLUSTER=gke-cost-optimization-monitoring
    gcloud config set project $PROJECT_ID
    
    gcloud services enable \
        compute.googleapis.com \
        container.googleapis.com \
        monitoring.googleapis.com
    
    gcloud config set compute/region us-central1
    gcloud config set compute/zone us-central1-f
    

    Remplacez l'élément suivant :

    • YOUR_PROJECT_ID : ID du projet Cloud que vous utilisez dans ce tutoriel.
    • YOUR_EMAIL_ADDRESS : adresse e-mail pour recevoir des notifications lorsque des opportunités de surprovisionnement ou de sous-provisionnement sont détectées dans votre cluster.

    Vous pouvez choisir une région et une zone différentes.

  3. Clonez le dépôt GitHub gke-cost-optimization-monitoring :

    git clone https://github.com/GoogleCloudPlatform/gke-cost-optimization-monitoring
    cd gke-cost-optimization-monitoring
    

    Le code dans ce dépôt est organisé avec les dossiers suivants :

    • Racine : contient les fichiers main.go et Dockerfile que la tâche Cron utilise pour exporter des métriques personnalisées vers Cloud Monitoring.
    • api/ : contient l'API golang permettant de manipuler les objets Kubernetes et Monitoring.
    • k8s/templates/ : contient le modèle permettant de créer les tâches Cron, l'autoscaler vertical de pods et l'autoscaler horizontal de pods dans votre cluster.
    • monitoring/dashboards/templates/ : contient les modèles permettant de créer de manière dynamique les tableaux de bord de bin-packing et de redimensionnement des applications.
    • monitoring/policies/templates/ : contient les modèles permettant de créer de manière dynamique les règles d'alerte de bin-packing et de redimensionnement des applications.

Créer le cluster GKE

  1. Dans Cloud Shell, créez un cluster GKE :

    gcloud container clusters create $CLUSTER \
        --enable-ip-alias \
        --release-channel=stable \
        --machine-type=e2-standard-2 \
        --enable-autoscaling --min-nodes=1 --max-nodes=5 \
        --enable-vertical-pod-autoscaling
    

    Cette configuration n'est pas une configuration de production, mais elle convient à ce tutoriel. Dans cette configuration, vous activez l'autoscaler vertical de pods (VPA) pour extraire les fondations permettant de redimensionner l'application.

Déployer l'exemple d'application

  1. Déployez l'application Boutique en ligne :

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/master/release/kubernetes-manifests.yaml
    

    L'application Boutique en ligne est une boutique Web de démonstration composée de nombreux microservices rédigés dans différents langages de programmation.

  2. Pour simuler un environnement plus réaliste, créez un HPA pour les déploiements de la Boutique en ligne :

    kubectl get deployments --field-selector='metadata.name!=adservice,metadata.name!=cartservice' -o go-template-file=k8s/templates/cpu-hpa.gtpl | kubectl apply -f -
    
    kubectl get deployments --field-selector='metadata.name==cartservice' -o go-template-file=k8s/templates/memory-hpa.gtpl | kubectl apply -f -
    

    Notez que vous créez des objets HPA avec une cible de processeur pour la plupart des déploiements de la Boutique en ligne, un HPA avec une cible de mémoire pour le déploiement de cartservice et aucune configuration de HPA pour adservice. Cette configuration permet d'illustrer différentes visualisations de tableau de bord, comme indiqué dans les sections suivantes.

Configurer les composants pour exporter des métriques vers Cloud Monitoring

  1. Créez et transférez le code de l'exportateur de métriques personnalisées :

    docker build . -t gcr.io/$PROJECT_ID/metrics-exporter
    docker push gcr.io/$PROJECT_ID/metrics-exporter
    

    Ce code est chargé d'interroger les objets VPA et HPA dans votre cluster et d'envoyer des métriques personnalisées basées sur ces données à Cloud Monitoring. Cette mise en œuvre exporte des recommandations cibles de VPA et l'utilisation cible des ressources HPA : le processeur et la mémoire définis sous forme de pourcentage.

  2. Déployez la tâche Cron pour envoyer toutes les minutes des métriques d'autoscaler de charge de travail à Cloud Monitoring :

    sed "s/PROJECT_ID/$PROJECT_ID/g" k8s/templates/metrics-exporter.yaml > k8s/metrics-exporter.yaml
    kubectl create ns custom-metrics
    kubectl apply -f k8s/metrics-exporter.yaml
    

    Si vous exécutez ce tutoriel dans votre propre cluster (au lieu de celui que vous avez créé précédemment) et que l'identité de la charge de travail est activée, assurez-vous de suivre la procédure décrite dans Utiliser Workload Identity pour permettre l'exportation des métriques vers Cloud Monitoring.

  3. Créez un VPA pour tous les objets Deployments, StatefulSets et DaemonSets du cluster :

    rm k8s/vpas.yaml 2> /dev/null
    ALL_NAMESPACES=$(kubectl get namespaces -o jsonpath={.items[*].metadata.name})
    for NAMESPACE in $ALL_NAMESPACES
    do
        kubectl get deployments,statefulset,daemonset -n $NAMESPACE -o go-template-file=k8s/templates/vpa.gtpl >> k8s/vpas.yaml
    done
    kubectl apply -f k8s/vpas.yaml
    

    L'extrait de code précédent crée un VPA en mode Off pour tous les objets de tous les espaces de noms, y compris les objets système. Cette approche offre une vue plus précise des recommandations au niveau du cluster et du pool de nœuds. Toutefois, pour éviter de surcharger le service metrics-server, nous vous recommandons de ne pas exécuter le script précédent tel quel dans les clusters volumineux, où plusieurs centaines d'applications sont déployées. Pour un scénario à cluster volumineux, nous vous recommandons d'exécuter le script précédent uniquement pour les espaces de noms pour lesquels vous souhaitez optimiser les coûts. Dans ce scénario, les recommandations au niveau du cluster et du pool de nœuds ne sont pas précises. Vous devez donc les ignorer ou les supprimer.

Configurer des tableaux de bord pour surveiller l'utilisation et les recommandations de ressources

  1. Dans Cloud Console, accédez à la page Surveillance.

    Accéder à Monitoring

  2. Créer un projet.

    1. Sur la page Ajouter votre projet à un espace de travail, sélectionnez votre projet Cloud.
    2. Cliquez sur Ajouter.

    La création de l'espace de travail peut prendre plusieurs minutes.

  3. Dans Cloud Shell, générez les tableaux de bord de manière dynamique pour l'optimisation des coûts :

    YOUR_NAMESPACES=$( echo $ALL_NAMESPACES| sed 's/[a-zA-Z0-9_.-]*-system//g; s/gke-[a-zA-Z0-9_.-]*//g; s/kube-public//g; s/kube-node-lease//g; s/custom-metrics//g')
    for NAMESPACE in $YOUR_NAMESPACES
    do
        GTPL_FILE='./monitoring/dashboards/templates/app-rightsizing.gtpl'
        OUTPUT_FILE="./monitoring/dashboards/app-rightsizing-$CLUSTER-$NAMESPACE.yaml"
    
        kubectl get deployments,statefulset,daemonset -n $NAMESPACE -o go-template-file=$GTPL_FILE > $OUTPUT_FILE
    
        sed -i.bkp "s/CLUSTER_TO_REPLACE/$CLUSTER/g" $OUTPUT_FILE
        sed -i.bkp "s/NAMESPACE_TO_REPLACE/$NAMESPACE/g" $OUTPUT_FILE
    
        replace=""
        i=0
        while : ; do
            if grep -q "Y_POS_TO_REPLACE_$i" $OUTPUT_FILE
            then
                ((yPos=12 + (4 * $i)))
                replace="s/Y_POS_TO_REPLACE_$i/$yPos/g; ${replace}"
                ((i=i+1))
            else
                break
            fi
        done
        eval "sed -i.bkp '$replace' $OUTPUT_FILE"
        rm "$OUTPUT_FILE.bkp"
    done
    
    sed "s/CLUSTER_TO_REPLACE/$CLUSTER/g" ./monitoring/dashboards/templates/binpacking.yaml > ./monitoring/dashboards/binpacking.yaml
    

    En plus de créer un tableau de bord bin-packing, ce script génère également un tableau de bord de redimensionnement d'application pour chaque espace de noms de votre cluster, à l'exclusion des espaces de noms système. Dans ce tutoriel, le script ne génère qu'un seul tableau de bord pour l'espace de noms default, car la Boutique en ligne est entièrement déployée dans cet espace de noms. Toutefois, si vous exécutez le même script dans votre propre cluster GKE, il génère un tableau de bord pour chacun de vos espaces de noms.

  4. Importez les tableaux de bord générés dans Cloud Monitoring :

    for filename in monitoring/dashboards/*.yaml; do
        echo "Creating dashboard policy based on file: $filename"
        gcloud monitoring dashboards create \
            --config-from-file=$filename
    done
    

    Le résultat ressemble à ce qui suit :

    Creating dashboard policy based on file: monitoring/dashboards/app-rightsizing-gke-cost-optimization-monitoring-default.yaml
    Created [9c1a6cb6-3424-44a8-b824-f2ec959f6588].
    Creating dashboard policy based on file: monitoring/dashboards/binpacking.yaml
    Created [97f6349d-4880-478d-9da8-ca3c8a433093].
    

Afficher le tableau de bord de redimensionnement d'une application

  1. Accédez à la page Tableaux de bord de surveillance.

    Accéder à la page Tableaux de bord

  2. Cliquez sur le tableau de bord GKE - Redimensionnement d'application (gke-cost-optimization-monitoring:default).

Le reste de cette section explique comment afficher et interpréter les graphiques affichés dans le tableau de bord.

L'environnement de démonstration installé présente une charge constante simulée. En d'autres termes, vous ne remarquerez pas de changements importants dans les graphiques au fil du temps. Toutefois, si vous exécutez ce même tutoriel dans vos propres clusters, vous devez patienter quelques heures (idéalement, 24 heures ou plus) pour observer les dynamiques de scaling à la hausse et à la baisse et la répartition des distributions de charge au cours de la journée et la semaine.

La première ligne du graphique indique le surprovisionnement de l'espace de noms ; la deuxième ligne affiche les cinq applications les plus surprovisionnées ; et la troisième ligne affiche les cinq applications les plus sous-provisionnées.

Comme le montre le graphique précédent, les trois premières lignes du tableau de bord récapitulent les informations suivantes sur l'espace de noms agrégé :

  • Première ligne : processeur et mémoire : surprovisionnement des espaces de noms. Fournit un bref aperçu de l'optimisation des coûts de vos applications dans cet espace de noms donné.
  • Deuxième ligne : processeur et mémoire : les cinq applications les plus surprovisionnées. Cette page indique où trouver les applications sur lesquelles vous devez essayer d'améliorer l'espace de noms.
  • Troisième ligne : CPU et mémoire : les cinq applications les plus sous-provisionnées. Comme pour la deuxième ligne, cette ligne présente les applications qui nécessitent une attention particulière. Toutefois, dans ce scénario, vous ne vous focalisez pas sur les économies, mais sur le bon fonctionnement des applications dans votre cluster. Si le message "Aucune donnée disponible" s'affiche, cela signifie qu'aucune opportunité n'a été trouvée.

Le graphique suivant présente les détails du tableau de bord par application en termes de processeur, de mémoire et d'instances dupliquées. Chaque ligne représente une application de l'espace de noms donné. Ces informations sont utiles pour dimensionner vos applications en comparant les besoins indiqués par les développeurs (lignes requested_<cores|memory>) à ceux réellement utilisés par les applications (lignes used_<cores|memory>).

Le tableau de bord de redimensionnement d&#39;application affiche les détails du processeur, de la mémoire et des instances dupliquées.

Les sections suivantes traitent des trois lignes des graphiques précédents.

Première ligne : processeur (p/ pod)

Selon la configuration de votre charge de travail, ces graphiques présentent différentes indications pour vous aider à déterminer la taille adaptée à votre application :

  • Recommandation de processeur pour l'autoscaler vertical de pods (vpa_recommended_cores) : cette indication s'affiche lorsque votre application n'a pas configuré de HPA (graphique CPU: adservice (p/Pod) dans le tableau de bord) ou si l'HPA est configuré avec n'importe quelle métrique autre que le processeur (graphique CPU: cartservice (p/Pod) dans le tableau de bord). Lorsque vous voyez ces indications, nous vous recommandons vivement de les appliquer statiquement ou, si vous maîtrisez l'affichage de l'historique des graphiques, d'activer l'autoscaler vertical de pods avec le mode Initial ou Auto.

  • Utilisation cible du processeur pour l'HPA (hpa_target_utilization) : cette indication s'affiche lorsque votre application est configurée avec l'HPA en fonction de l'utilisation du processeur (tous les autres graphiques du processeur). Dans ce scénario, nous vous recommandons d'effectuer les opérations suivantes :

    • Cas de surprovisionnement : si l'utilisation réelle (used_cores) est constamment très inférieure à la cible HPA (hpa_target_utilization), cela signifie que le déploiement s'exécute à la valeur spécifiée dans la valeur HPA minReplicas. L'action suggérée dans le cadre de ce scénario consiste à réduire la valeur minReplicas.
    • Cas de sous-provisionnement : si l'utilisation réelle (used_cores) est constamment supérieure à la cible HPA (hpa_target_utilization), le déploiement s'exécute à la valeur spécifiée dans la valeur HPA maxReplicas. L'action suggérée ici consiste à augmenter la valeur maxReplicas ou à augmenter les ressources demandées pour agrandir les pods.
    • Comprendre les scalings à la hausse et à la baisse : observez les graphiques CPU et Replicas pour savoir quand l'HPA sur processeur déclenche un scaling à la hausse ou à la baisse du pod.
    • Optimisation de l'utilisation cible de l'HPA : consultez nos bonnes pratiques avant d'appliquer quoi que ce soit à votre environnement.
    • Il est également important d'éviter de mélanger les autoscalers vertical et horizontal ou la mémoire dans la même charge de travail. Pour ce faire, utilisez la méthode MPA.

Deuxième ligne : mémoire (p/ pod)

De même qu'avec la ligne du processeur, selon la configuration de votre charge de travail, ces graphiques présentent différentes indications pour vous aider à déterminer la taille adaptée à votre application :

  • Recommandation de mémoire pour l'autoscaler vertical de pods (vpa_recommended_bytes) : cette indication s'affiche lorsque votre application n'a pas configuré de HPA (graphique Mem: adservice (p/Pod) dans le tableau de bord) ou si l'HPA est configuré avec n'importe quelle métrique autre que la mémoire (graphique Men: emailservice (p/Pod) dans le tableau de bord). Envisagez d'appliquer ces recommandations pour éviter de perdre des ressources et des événements "Out of Memory Kill" (OOMKill), ou si vous maîtrisez l'historique des graphiques, d'activer l'autoscaler vertical de pods avec le mode Initial ou Auto.

  • Utilisation de la cible de mémoire HPA (hpa_target_utilization) : cette indication s'affiche lorsque votre application est configurée avec HPA en fonction de l'utilisation de la mémoire (graphique Mem: cartservice (p/Pod) dans le tableau de bord). Dans ce scénario, nous vous recommandons d'effectuer les opérations suivantes :

    • Cas de surprovisionnement : si l'utilisation réelle (used_bytes) est constamment très inférieure à la cible HPA (hpa_target_utilization), le déploiement s'exécute à la valeur spécifiée dans la valeur HPA minReplicas. L'action suggérée dans le cadre de ce scénario consiste à réduire la valeur minReplicas.
    • Cas de sous-provisionnement : si l'utilisation réelle (used_bytes) est constamment supérieure à la cible HPA (hpa_target_utilization), votre déploiement s'exécute à la valeur spécifiée dans la valeur HPAmaxReplicas. L'action suggérée ici consiste à augmenter la valeur maxReplicas ou à augmenter les ressources demandées pour agrandir les pods.
    • Comprendre les scalings à la hausse et à la baisse : observez les graphiques Mem et Replicas pour savoir quand l'HPA sur mémoire déclenche un scaling à la hausse ou à la baisse du pod.
    • Optimisation de l'utilisation cible de l'HPA : consultez nos bonnes pratiques avant d'appliquer quoi que ce soit à votre environnement.
    • Il est également important d'éviter de mélanger les autoscalers vertical et horizontal ou la mémoire dans la même charge de travail. Pour ce faire, utilisez la méthode MPA.

Troisième ligne : instances dupliquées

Les graphiques de cette ligne indiquent le nombre de pods présents dans une application donnée. Ces informations sont utiles pour comprendre la volatilité des ressources utilisées par rapport aux ressources recommandées pour les charges de travail déployées avec le HPA.

Afficher le tableau de bord du bin-packing (distribution)

  1. Accédez de nouveau à la page Tableaux de bord de surveillance.

    Accéder à la page "Tableaux de bord"

  2. Cliquez sur le tableau de bord GKE - Bin-Packing du cluster (gke-cost-optimization-monitoring).

Comme le montrent les graphiques suivants, le tableau de bord de Bin-Packing présente des informations agrégées par cluster (première ligne) et par pools de nœuds (deuxième ligne). Ces informations sont utiles au bin-packing de votre cluster en comparant la capacité pouvant être allouée dans le cluster et dans les pools de nœuds (lignes allocable_<cores|memory>) avec les estimations de vos développeurs (lignes requested_<cores|memory>).

Le tableau de bord de Bin-Packing présente des informations agrégées par cluster (première ligne) et par pools de nœuds (deuxième ligne).

Une analyse utile que vous pouvez effectuer en complément de ces graphiques consiste à vérifier si vous manquez d'un type de ressource (par exemple, de la mémoire) et gaspillez un autre type de ressource (par exemple, le processeur). Dans ce scénario, l'autoscaler de cluster déclenche des scalings à la hausse, car il n'y a plus de mémoire disponible pour intégrer au cluster des pods planifiés. Un autre cas courant est lié à la densité des pods, c'est-à-dire le nombre de pods par nœud. Dans le graphique Pool de nœuds : nombre de pods, vous pouvez voir la densité des pods dans chaque pool de nœuds et la comparer aux informations configurées (non fournies dans le graphique). Si vous avez atteint la densité configurée pour votre pool de nœuds, l'autorité de certification lance de nouveaux nœuds pour s'adapter aux pods planifiés, même si vous disposez d'une grande quantité de processeurs et de mémoire disponible.

Une autre analyse importante, non disponible dans les tableaux de bord précédents, est liée aux configurations minimale et maximale de vos autoscalers. Par exemple, il est possible que votre cluster ne fasse pas l'objet d'un scaling à la baisse la nuit, car vos HPA ou votre autorité de certification ont besoin de plus que le minimum. De plus, il est possible que votre autorité de certification ne démarre pas de pods dans le pool de nœuds attendu, car elle a peut-être atteint le nombre maximal de nœuds configurés pour ce pool.

Limites du tableau de bord

  • Bien que le tableau de bord de redimensionnement d'application présente des informations agrégées pour toutes les applications d'un espace de noms donné, il affiche uniquement les données concernant le processeur, la mémoire et les instances dupliquées pour les huit premières applications, triées par nom, en raison d'une limite du nombre de widgets autorisés dans un tableau de bord unique. Si vous constatez que les applications affichées ne sont pas les plus importantes, modifiez le tableau de bord en fonction de vos besoins.
  • Le tableau de bord bin-packing fournit des données agrégées pour les clusters et les pools de nœuds. Dans le cas d'un grand nombre de clusters ou de pools de nœuds, la visualisation est limitée, car les filtres ne sont pas autorisés à s'exécuter dans le langage MQL (Monitoring Query Language) permettant de créer les graphiques.
  • Le chargement du tableau de bord bin-packing peut prendre beaucoup de temps lorsqu'il surveille des clusters volumineux avec des centaines d'applications. Dans ce cas, pour réduire la quantité de données chargées, nous vous recommandons d'éviter de filtrer le tableau de bord sur une longue période.

Configurer des règles d'alerte en cas de surprovisionnement et de sous-provisionnement

Lorsque l'équipe financière de votre entreprise vous demandera pourquoi votre facture cloud a doublé récemment, vous aimeriez éviter d'avoir à répondre que vous rencontrez un problème de surprovisionnement. Pour éviter une telle situation, nous vous recommandons vivement de créer des règles d'alerte qui se déclenchent lorsque votre environnement commence à différer de ce que vous aviez prévu.

  1. Dans Cloud Shell, créez un canal de notification :

    gcloud beta monitoring channels create \
        --display-name="Cost Optimization team (Primary)" \
        --description="Primary contact method for the Cost Optimization effort"  \
        --type=email \
        --channel-labels=email_address=${ALERT_EMAIL}
    

    Le résultat ressemble à ce qui suit :

    Created notification channel [projects/your_project/notificationChannels/13166436832066782447].
    

    La commande précédente crée un canal de notification de type email pour simplifier les étapes du tutoriel. Dans les environnements de production, nous vous recommandons d'utiliser une stratégie moins asynchrone en définissant le canal de notification sur sms ou pagerduty.

  2. Définissez une variable dont la valeur est celle qui a été affichée dans l'espace réservé NOTIFICATION_CHANNEL_ID :

    NOTIFICATION_CHANNEL_ID=$(gcloud beta monitoring channels list --filter='displayName="Cost Optimization team (Primary)"' | grep 'name:' | sed 's/name: //g')
    
  3. Créez et déployez de manière dynamique les règles d'alerte :

    for NAMESPACE in $YOUR_NAMESPACES
    do
        for templatefile in monitoring/policies/templates/rightsizing/*.yaml; do
            outputfile=monitoring/policies/$(basename $templatefile)
            sed "s/CLUSTER_TO_REPLACE/$CLUSTER/g;s/NAMESPACE_TO_REPLACE/$NAMESPACE/g" $templatefile > $outputfile
            echo "Creating alert policy based on file: $outputfile"
            gcloud alpha monitoring policies create \
                --policy-from-file=$outputfile \
                --notification-channels=$NOTIFICATION_CHANNEL_ID
        done
    done
    
    for templatefile in monitoring/policies/templates/binpacking/*.yaml; do
        outputfile=monitoring/policies/$(basename $templatefile)
        sed "s/CLUSTER_TO_REPLACE/$CLUSTER/g;s/NAMESPACE_TO_REPLACE/$NAMESPACE/g" $templatefile > $outputfile
        echo "Creating alert policy based on file: $outputfile"
        gcloud alpha monitoring policies create \
            --policy-from-file=$outputfile \
            --notification-channels=$NOTIFICATION_CHANNEL_ID
    done
    

    Le résultat ressemble à ce qui suit :

    Creating alert policy based on file: monitoring/policies/app-rightsizing-cpu-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/18091138402474167583].
    Creating alert policy based on file: monitoring/policies/app-rightsizing-cpu-underprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/8586234469403227589].
    Creating alert policy based on file: monitoring/policies/app-rightsizing-memory-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/9685822323903723723].
    Creating alert policy based on file: monitoring/policies/app-rightsizing-memory-underprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/15705075159352926212].
    Creating alert policy based on file: monitoring/policies/nodepools-binpacking-cpu-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/14555072091442814207].
    Creating alert policy based on file: monitoring/policies/nodepools-binpacking-memory-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/1442392910032052087].
    

    Par défaut, les règles d'alerte créées contiennent la spécification pour le déclenchement d'alertes si les applications sont surprovisionnées de plus de 80 % et les pools de nœuds de plus de 40 %, sur une période supérieure à un jour. Veillez à ajuster ces règles pour répondre à vos besoins d'utilisation des ressources.

  4. Accédez à la page Alertes Monitoring pour afficher la règle d'alerte.

    Accéder à la page "Alertes"

  5. Cliquez sur l'une des règles créées pour vérifier ou modifier les détails de votre configuration d'alerte.

Nettoyer

Pour éviter que les ressources utilisées dans ce tutoriel soient facturées sur votre compte Google Cloud, procédez comme suit :

Supprimer le projet

Le moyen le plus simple d'empêcher la facturation est de supprimer le projet que vous avez créé pour ce tutoriel.

  1. Dans Cloud Console, accédez à la page Gérer les ressources.

    Accéder à la page Gérer les ressources

  2. Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Étapes suivantes