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

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

Accéder au sélecteur de projet
Sélectionnez ou créez un projet Google Cloud.

Remarque : Si vous ne comptez pas conserver les ressources créées dans cette procédure, créez un projet au lieu de sélectionner un projet existant. Après avoir suivi ces étapes, vous pouvez supprimer le projet. Cela entraîne la suppression de toutes les ressources qui lui sont associées.

Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier si la facturation est activée sur un 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. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Préparer l'environnement

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

En bas de la fenêtre de la console, une session Cloud Shell s'ouvre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé avec des valeurs prédéfinies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.
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.
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

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

Déployez l'application Boutique en ligne :
```
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/main/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.
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

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

Dans la console, accédez à la page Surveillance.

Accéder à Monitoring
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.

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.

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

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

Accéder à la page Tableaux de bord
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'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)

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

Accéder à la page "Tableaux de bord"
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.

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.

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')

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.

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

Accéder à la page "Alertes"
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.

Dans la console, accédez à la page Gérer les ressources.
Accéder à la page Gérer les ressources
Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Étapes suivantes

Consultez la section Bonnes pratiques pour l'exécution d'applications Kubernetes à coût maîtrisé sur GKE pour en savoir plus sur l'optimisation des coûts sur GKE.
Pour obtenir d'autres conseils et bonnes pratiques sur l'optimisation des coûts GKE, consultez la page Optimisation des coûts sur Google Cloud pour les développeurs et les opérateurs.
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.
Explorez des architectures de référence, des schémas, des tutoriels et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.