Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Meilleures pratiques en matière d'optimisation des coûts
L'optimisation des coûts consiste à obtenir les résultats de votre entreprise au prix le plus bas. En suivant la documentation de ce guide, vous optimiserez vos charges de travail Amazon EKS.
## Consignes générales
Dans le cloud, il existe un certain nombre de directives générales qui peuvent vous aider à optimiser les coûts de vos microservices :
+ Assurez-vous que les charges de travail exécutées sur Amazon EKS sont indépendantes des types d'infrastructure spécifiques pour l'exécution de vos conteneurs. Cela vous donnera une plus grande flexibilité en ce qui concerne leur exécution sur les types d'infrastructure les moins coûteux. Lorsque vous utilisez Amazon EKS avec EC2, il peut y avoir des exceptions lorsque des charges de travail nécessitent un type d' EC2 instance spécifique, comme [un GPU](https://docs.aws.amazon.com/eks/latest/userguide/gpu-ami.html) ou d'autres types d'instances, en raison de la nature de la charge de travail.
+ Sélectionnez des instances de conteneur au profil optimal : profilez vos environnements de production ou de pré-production et surveillez les indicateurs critiques tels que le processeur et la mémoire, à l'aide de services tels qu'[Amazon CloudWatch Container Insights pour Amazon EKS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html) ou d'outils tiers disponibles dans l'écosystème Kubernetes. Cela nous permettra d'allouer la bonne quantité de ressources et d'éviter le gaspillage de ressources.
+ Profitez des différentes options d'achat disponibles sur AWS pour exécuter EKS EC2, par exemple On-Demand, Spot et Savings Plan.
## Meilleures pratiques d'optimisation des coûts chez EKS
Il existe trois domaines généraux de bonnes pratiques en matière d'optimisation des coûts dans le cloud :
+ Ressources rentables (Auto Scaling, Down Scaling, politiques et options d'achat)
+ Sensibilisation aux dépenses (à l'aide d'AWS et d'outils tiers)
+ Optimisation au fil du temps (bonne taille)
Comme pour toute directive, il y a des compromis. Assurez-vous de travailler avec votre organisation pour comprendre les priorités relatives à cette charge de travail et les meilleures pratiques les plus importantes.
### Comment utiliser ce guide
Ce guide est destiné aux équipes DevOps chargées de la mise en œuvre et de la gestion des clusters EKS et des charges de travail qu'ils prennent en charge. Le guide est organisé en différents domaines de bonnes pratiques pour en faciliter la consommation. Chaque rubrique contient une liste de recommandations, d'outils à utiliser et de meilleures pratiques pour optimiser les coûts de vos clusters EKS. Il n'est pas nécessaire de lire les sujets dans un ordre particulier.
### Principaux services AWS et fonctionnalités de Kubernetes
L'optimisation des coûts est prise en charge par les services et fonctionnalités AWS suivants :
+ EC2 Types d'instances, Savings Plan (et instances réservées) et instances ponctuelles, à des prix différents.
+ Auto Scaling ainsi que les politiques Auto Scaling natives de Kubernetes. Pensez à Savings Plan (instances précédemment réservées) pour des charges de travail prévisibles. Utilisez des magasins de données gérés tels que EBS et EFS pour garantir l'élasticité et la durabilité des données d'application.
+ Le tableau de bord de la console Billing and Cost Management ainsi qu'AWS Cost Explorer fournissent une vue d'ensemble de votre utilisation d'AWS. Utilisez AWS Organizations pour obtenir des informations de facturation détaillées. Les détails de plusieurs outils tiers ont également été partagés.
+ Amazon CloudWatch Container Metrics fournit des mesures relatives à l'utilisation des ressources par le cluster EKS. Outre le tableau de bord Kubernetes, plusieurs outils de l'écosystème Kubernetes peuvent être utilisés pour réduire le gaspillage.
Ce guide inclut un ensemble de recommandations que vous pouvez utiliser pour améliorer l'optimisation des coûts de votre cluster Amazon EKS.
## Commentaires
Ce guide est publié GitHub afin de recueillir les commentaires directs et les suggestions de l'ensemble de la communauté EKS/Kubernetes. Si vous avez une bonne pratique que vous pensez que nous devrions inclure dans le guide, veuillez signaler un problème ou soumettre un PR dans le GitHub référentiel. Notre intention est de mettre à jour le guide périodiquement au fur et à mesure que de nouvelles fonctionnalités sont ajoutées au service ou lorsqu'une nouvelle bonne pratique évolue.
# Cadre d'optimisation des coûts
AWS Cloud Economics est une discipline qui aide les clients à accroître leur efficacité et à réduire leurs coûts grâce à l'adoption de technologies informatiques modernes telles qu'Amazon EKS. La discipline recommande de suivre une méthodologie appelée « cadre de gestion financière dans le cloud (CFM) » qui comprend 4 piliers :
![\[Cadre CFM\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/cfm_framework.png)
## Le pilier See : mesure et responsabilité
Le pilier See est un ensemble fondamental d'activités et de technologies qui définissent comment mesurer, surveiller et responsabiliser les dépenses liées au cloud. Elle est souvent appelée « observabilité », « instrumentation » ou « télémétrie ». Les capacités et les limites de l'infrastructure « d'observabilité » dictent ce qui peut être optimisé. Obtenir une image claire de vos coûts est une première étape essentielle de l'optimisation des coûts, car vous devez savoir par où commencer. Ce type de visibilité orientera également les types d'activités que vous devrez effectuer pour optimiser davantage votre environnement.
Voici un bref aperçu de nos meilleures pratiques pour le pilier See :
+ Définissez et gérez une stratégie de balisage pour vos charges de travail.
+ Utilisez le [balisage d'instance](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html#tag-resources-for-billing) : le balisage des clusters EKS vous permet de voir les coûts de chaque cluster et de les répartir dans vos rapports sur les coûts et l'utilisation.
+ Établissez des rapports et surveillez l'utilisation d'EKS en utilisant des technologies telles que [Kubecost](https://www.ibm.com/docs/en/kubecost/self-hosted/2.x?topic=installations-amazon-eks-integration).
+ [Activez les tableaux de bord Cloud Intelligence](https://wellarchitectedlabs.com/cost/200_labs/200_enterprise_dashboards/). En étiquetant correctement les ressources et en utilisant des visualisations, vous pouvez mesurer et estimer les coûts.
+ Répartissez les coûts du cloud aux applications, aux secteurs d'activité (LoBs) et aux sources de revenus.
+ Définissez, mesurez et diffusez efficiency/value KPIs avec les parties prenantes de l'entreprise. Par exemple, créez un KPI « métrique unitaire » qui mesure le coût par transaction. Par exemple, un service de covoiturage peut avoir un KPI pour le « coût par trajet ».
Pour plus de détails sur les technologies et activités recommandées associées à ce pilier, veuillez consulter la section [Optimisation des coûts - Observabilité](cost-opt-observability.md) de ce guide.
## Le pilier de l'épargne : optimisation des coûts
Ce pilier est basé sur les technologies et les capacités développées dans le pilier « Voir ». Les activités suivantes relèvent généralement de ce pilier :
+ Identifiez et éliminez les déchets dans votre environnement.
+ Architecte et concepteur au service de la rentabilité.
+ Choisissez la meilleure option d'achat, par exemple les instances à la demande par rapport aux instances Spot.
+ Adaptez-vous en fonction de l'évolution des services : à mesure que les services AWS évoluent, la manière d'utiliser efficacement ces services peut changer. Soyez prêt à vous adapter pour tenir compte de ces changements.
Ces activités étant opérationnelles, elles dépendent fortement des caractéristiques de votre environnement. Posez-vous la question suivante : quels sont les principaux facteurs de coûts ? Quelle est la valeur commerciale de vos différents environnements ? Quelles sont les options d'achat et les choix d'infrastructure, par exemple les types de familles d'instances, les mieux adaptés à chaque environnement ?
Vous trouverez ci-dessous une liste hiérarchisée des facteurs de coûts les plus courants pour les clusters EKS :
1. **Coûts de calcul :** la combinaison de plusieurs types de familles d'instances, d'options d'achat et l'équilibre entre évolutivité et disponibilité nécessitent une attention particulière. Pour plus d'informations, consultez les recommandations de la section [Optimisation des coûts - Calcul](cost-opt-compute.md) de ce guide.
1. **Coûts de mise en réseau :** l'utilisation de 3 AZs pour les clusters EKS peut potentiellement augmenter les coûts du trafic inter-AZ. Pour nos recommandations sur la manière de trouver un équilibre entre les exigences de haute disponibilité et la réduction des coûts du trafic réseau, veuillez consulter la section [Optimisation des coûts - Mise en réseau](cost-opt-networking.md) de ce guide.
1. **Coûts de stockage :** en fonction de la stateful/stateless nature des charges de travail dans les clusters EKS et de la manière dont les différents types de stockage sont utilisés, le stockage peut être considéré comme faisant partie de la charge de travail. Pour les considérations relatives aux coûts de stockage EKS, veuillez consulter la section [Optimisation des coûts - Stockage](cost-opt-storage.md) de ce guide.
## Le pilier du plan : planification et prévisions
Une fois les recommandations du pilier See mises en œuvre, les clusters sont optimisés en permanence. Au fur et à mesure que l'on acquiert de l'expérience dans l'exploitation efficace des clusters, les activités de planification et de prévision peuvent se concentrer sur :
+ Budgétiser et prévoir les coûts du cloud de manière dynamique.
+ Quantification de la valeur commerciale fournie par les services de conteneurs EKS.
+ Intégrer la gestion des coûts du cluster EKS à la planification de la gestion financière informatique.
## Le pilier Run
L'optimisation des coûts est un processus continu qui implique un ensemble d'améliorations progressives :
![\[Volant d'optimisation des coûts\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/flywheel.png)
Obtenir le parrainage exécutif pour ce type d'activités est crucial pour intégrer l'optimisation du cluster EKS dans les « FinOps » efforts de l'organisation. Il permet l'alignement des parties prenantes grâce à une compréhension commune des coûts du cluster EKS, à la mise en œuvre de garde-fous en matière de coûts du cluster EKS et à la garantie que l'outillage, l'automatisation et les activités évoluent en fonction des besoins de l'organisation.
## Références
+ [Économie du cloud AWS, gestion financière du cloud](https://aws.amazon.com/aws-cost-management/)
# Sensibilisation aux dépenses
La connaissance des dépenses consiste à comprendre qui, où et quoi est à l'origine des dépenses dans votre cluster EKS. L'obtention d'une image précise de ces données vous aidera à mieux connaître vos dépenses et à mettre en évidence les domaines à corriger.
## Recommandations
### Utiliser Cost Explorer
[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) possède une easy-to-use interface qui vous permet de visualiser, de comprendre et de gérer vos coûts et votre utilisation d'AWS au fil du temps. Vous pouvez analyser les données de coût et d'utilisation à différents niveaux à l'aide des filtres disponibles dans Cost Explorer.
#### Coûts liés au plan de contrôle EKS et à EKS Fargate
À l'aide des filtres, nous pouvons vérifier les coûts engagés pour les coûts EKS sur le plan de contrôle et le module Fargate, comme indiqué dans le schéma ci-dessous :
![\[Cost Explorer - Plan de contrôle EKS\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/eks-controlplane-costexplorer.png)
À l'aide des filtres, nous pouvons demander les coûts agrégés engagés pour les Fargate Pods dans toutes les régions d'EKS, ce qui inclut à la fois les heures de processeur virtuel par processeur et les Go d'heures, comme le montre le schéma ci-dessous :
![\[Cost Explorer - EKS Fargate\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/eks-fargate-costexplorer.png)
#### Marquage des ressources
Amazon EKS prend en charge l'[ajout de balises AWS](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html) à vos clusters Amazon EKS. Cela permet de contrôler facilement l'accès à l'API EKS pour gérer vos clusters. Les balises ajoutées à un cluster EKS sont spécifiques à la ressource du cluster AWS EKS, elles ne se propagent pas aux autres ressources AWS utilisées par le cluster, telles que les EC2 instances ou les équilibreurs de charge. Aujourd'hui, le balisage des clusters est pris en charge pour tous les clusters EKS nouveaux et existants via l'API, la console et SDKs.
AWS Fargate est une technologie qui fournit une capacité de calcul adaptée à la demande pour les conteneurs. Avant de pouvoir planifier des pods sur Fargate dans votre cluster, vous devez définir au moins un profil Fargate qui indique quels pods doivent utiliser Fargate lors de leur lancement.
Ajouter et répertorier des balises dans un cluster EKS :
```
$ aws eks tag-resource --resource-arn arn:aws:eks:us-west-2:xxx:cluster/ekscluster1 --tags team=devops,env=staging,bu=cio,costcenter=1234
$ aws eks list-tags-for-resource --resource-arn arn:aws:eks:us-west-2:xxx:cluster/ekscluster1
{
"tags": {
"bu": "cio",
"env": "staging",
"costcenter": "1234",
"team": "devops"
}
}
```
Une fois que vous avez activé les balises de répartition des [coûts dans AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html), AWS utilise les balises de répartition des coûts pour organiser vos coûts de ressources dans votre rapport de répartition des coûts, afin de vous permettre de classer et de suivre plus facilement vos coûts AWS.
Les identifications n’ont pas de signification sémantique pour Amazon EKS et sont interprétées strictement comme des chaînes de caractères. Par exemple, vous pouvez définir un ensemble de balises pour vos clusters Amazon EKS afin de vous aider à suivre le propriétaire et le niveau de pile de chaque cluster.
### Utiliser AWS Trusted Advisor
AWS Trusted Advisor propose un ensemble complet de vérifications et de recommandations relatives aux meilleures pratiques dans cinq catégories : optimisation des coûts, sécurité, tolérance aux pannes, performances et limites de service.
Pour optimiser les coûts, Trusted Advisor aide à éliminer les ressources inutilisées et inutilisées et recommande de prendre des engagements en matière de capacité réservée. Les principales mesures qui aideront Amazon EKS concerneront notamment les EC2 instances peu utilisées, les adresses IP élastiques non associées, les équilibreurs de charge inactifs et les volumes EBS sous-utilisés. La liste complète des contrôles est disponible sur https://aws.amazon.com/premiumsupport/ technology/trusted-advisor/best -practice-checklist/.
The Trusted Advisor fournit également des recommandations sur les Savings Plans et les EC2 instances réservées pour les instances et Fargate, qui vous permet de vous engager à utiliser un montant d'utilisation constant en échange de tarifs réduits.
**Note**
Les recommandations de Trusted Advisor sont des recommandations génériques et ne sont pas spécifiques à EKS.
### Utiliser le tableau de bord Kubernetes
***Tableau de bord Kubernetes***
Le tableau de bord Kubernetes est une interface utilisateur Web à usage général pour les clusters Kubernetes, qui fournit des informations sur le cluster Kubernetes, notamment l'utilisation des ressources au niveau du cluster, du nœud et du pod. Le déploiement du tableau de bord Kubernetes sur un cluster Amazon EKS est décrit dans la documentation [Amazon](https://docs.aws.amazon.com/eks/latest/userguide/dashboard-tutorial.html) EKS.
Le tableau de bord fournit des informations détaillées sur l'utilisation des ressources pour chaque nœud et chaque pod, ainsi que des métadonnées détaillées sur les pods, les services, les déploiements et les autres objets Kubernetes. Ces informations consolidées offrent une visibilité sur votre environnement Kubernetes.
![\[Tableau de bord Kubernetes\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/kubernetes-dashboard.png)
***commandes kubectl top et describe***
Afficher les métriques d'utilisation des ressources avec les commandes kubectl top et kubectl describe. kubectl top affichera l'utilisation actuelle du processeur et de la mémoire pour les pods ou les nœuds de votre cluster, ou pour un pod ou un nœud spécifique. La commande kubectl describe fournira des informations plus détaillées sur un nœud ou un pod spécifique.
```
$ kubectl top pods
$ kubectl top nodes
$ kubectl top pod pod-name --namespace mynamespace --containers
```
À l'aide de la commande top, la sortie affiche la quantité totale de CPU (en cœurs) et de mémoire (en MiB) utilisée par le nœud, ainsi que les pourcentages de capacité allouable du nœud que ces chiffres représentent. Vous pouvez ensuite passer au niveau suivant, le niveau du conteneur dans les pods, en ajoutant un indicateur *--containers*.
```
$ kubectl describe node
$ kubectl describe pod
```
*kubectl describe* renvoie le pourcentage de capacité totale disponible représenté par chaque demande ou limite de ressource.
kubectl top and describe, suivez l'utilisation et la disponibilité des ressources critiques telles que le processeur, la mémoire et le stockage sur les pods, nœuds et conteneurs Kubernetes. Cette prise de conscience aidera à comprendre l'utilisation des ressources et à contrôler les coûts.
### Utilisez CloudWatch Container Insights
Utilisez [CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html) pour collecter, agréger et résumer les métriques et les journaux de vos applications conteneurisées et de vos microservices. Container Insights est disponible pour Amazon Elastic Kubernetes Service EC2 sur Amazon et pour les plateformes Kubernetes sur Amazon. EC2 Les métriques incluent l'utilisation des ressources telles que l'UC, la mémoire, le disque et le réseau.
L'installation des insights est décrite dans la [documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html).
CloudWatch crée des métriques agrégées au niveau du cluster, du nœud, du pod, de la tâche et du service sous forme de CloudWatch métriques.
**La requête suivante affiche une liste de nœuds, triée par utilisation moyenne du processeur par nœud**
```
STATS avg(node_cpu_utilization) as avg_node_cpu_utilization by NodeName
| SORT avg_node_cpu_utilization DESC
```
**Utilisation du processeur par nom de conteneur**
```
stats pct(container_cpu_usage_total, 50) as CPUPercMedian by kubernetes.container_name
| filter Type="Container"
```
**Utilisation du disque par nom de conteneur**
```
stats floor(avg(container_filesystem_usage/1024)) as container_filesystem_usage_avg_kb by InstanceId, kubernetes.container_name, device
| filter Type="ContainerFS"
| sort container_filesystem_usage_avg_kb desc
```
D'autres exemples de requêtes sont fournis dans la [documentation Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-view-metrics.html).
Cette prise de conscience aidera à comprendre l'utilisation des ressources et à contrôler les coûts.
### Utiliser Kubecost pour la sensibilisation et les conseils en matière de dépenses
Des outils tiers tels que [kubecost](https://kubecost.com/) peuvent également être déployés sur Amazon EKS pour obtenir une visibilité sur le coût de fonctionnement de votre cluster Kubernetes. Consultez ce [blog AWS](https://aws.amazon.com/blogs/containers/how-to-track-costs-in-multi-tenant-amazon-eks-clusters-using-kubecost/) pour le suivi des coûts à l'aide de Kubecost
Déploiement de kubecost à l'aide de Helm 3 :
```
$ curl -sSL https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
$ helm version --short
v3.2.1+gfe51cd1
$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/
$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/c^C
$ kubectl create namespace kubecost
namespace/kubecost created
$ helm repo add kubecost https://kubecost.github.io/cost-analyzer/
"kubecost" has been added to your repositories
$ helm install kubecost kubecost/cost-analyzer --namespace kubecost --set kubecostToken="aGRoZEBqc2pzLmNvbQ==xm343yadf98"
NAME: kubecost
LAST DEPLOYED: Mon May 18 08:49:05 2020
NAMESPACE: kubecost
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
--------------------------------------------------Kubecost has been successfully installed. When pods are Ready, you can enable port-forwarding with the following command:
kubectl port-forward --namespace kubecost deployment/kubecost-cost-analyzer 9090
Next, navigate to http://localhost:9090 in a web browser.
$ kubectl port-forward --namespace kubecost deployment/kubecost-cost-analyzer 9090
NOTE: If you are using Cloud 9 or have a need to forward it to a different port like 8080, issue the following command
$ kubectl port-forward --namespace kubecost deployment/kubecost-cost-analyzer 8080:9090
```
Tableau de bord Kubecost - ![\[Kubernetes Cluster Auto Scaler logs\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/kube-cost.png)
### Utiliser l'outil d'analyse de la répartition des coûts et de la planification des capacités de Kubernetes
[Kubernetes Opex Analytics](https://github.com/rchakode/kube-opex-analytics) est un outil destiné à aider les entreprises à suivre les ressources consommées par leurs clusters Kubernetes afin d'éviter les surpaiements. Pour ce faire, il génère des rapports d'utilisation à court (7 jours), à moyen (14 jours) et à long terme (12 mois) fournissant des informations pertinentes sur la quantité de ressources dépensée par chaque projet au fil du temps.
![\[Analyses Opex de Kubernetes\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/kube-opex-analytics.png)
### Échelle de yoga
Yotascale aide à répartir avec précision les coûts de Kubernetes. La fonction d'allocation des coûts de Yotascale Kubernetes utilise les données de coûts réels, qui incluent les remises sur les instances réservées et les prix des instances au comptant, au lieu d'estimations génériques des taux du marché, pour déterminer l'empreinte financière totale de Kubernetes.
Plus de détails peuvent être trouvés sur [leur site Web](https://www.yotascale.com/).
### Conseiller Alcide
Alcide est un partenaire technologique avancé du réseau de partenaires AWS (APN). Alcide Advisor permet de s'assurer que la configuration de votre cluster, de vos nœuds et de vos pods Amazon EKS est réglée pour fonctionner conformément aux meilleures pratiques de sécurité et aux directives internes. Alcide Advisor est un service sans agent d'audit et de conformité Kubernetes conçu pour garantir un DevSecOps flux fluide et sécurisé en durcissant la phase de développement avant de passer à la production.
Vous trouverez plus de détails dans ce billet de [blog](https://aws.amazon.com/blogs/apn/driving-continuous-security-and-configuration-checks-for-amazon-eks-with-alcide-advisor/).
## Autres outils
### Collecte des déchets Kubernetes
Le rôle du [ramasse-miettes de Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/) est de supprimer certains objets qui avaient autrefois un propriétaire, mais qui n'en ont plus.
### Nombre de Fargate
[Fargatecount](https://github.com/mreferre/fargatecount) est un outil utile qui permet aux clients AWS de suivre, à l'aide d'une CloudWatch métrique personnalisée, le nombre total de pods EKS déployés sur Fargate dans une région spécifique d'un compte spécifique. Cela permet de suivre tous les pods Fargate exécutés sur un cluster EKS.
### Popeye - Un désinfectant pour clusters Kubernetes
[Popeye - Un désinfectant de cluster Kubernetes est un utilitaire qui analyse le cluster](https://github.com/derailed/popeye) Kubernetes en direct et signale les problèmes potentiels liés aux ressources et aux configurations déployées. Il nettoie votre cluster en fonction de ce qui est déployé et non de ce qui se trouve sur le disque. En scannant votre cluster, il détecte les erreurs de configuration et vous aide à vous assurer que les meilleures pratiques sont en place
### Ressources
Consultez les ressources suivantes pour en savoir plus sur les meilleures pratiques en matière d'optimisation des coûts.
#### Documentation et blogs
+ [Amazon EKS prend en charge le balisage](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html)
#### Outils
+ [Qu'est-ce qu'AWS Billing and Cost Management ?](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)
+ [Informations sur les CloudWatch conteneurs Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html)
+ [Comment suivre les coûts dans les clusters Amazon EKS à locataires multiples à l'aide de Kubecost](https://aws.amazon.com/blogs/containers/how-to-track-costs-in-multi-tenant-amazon-eks-clusters-using-kubecost/)
+ [Kubecost](https://kubecost.com/)
+ [Kube Opsview](https://github.com/hjacobs/kube-ops-view)
+ [Analyses Opex de Kubernetes](https://github.com/rchakode/kube-opex-analytics)
# Calcul et mise à l'échelle automatique
En tant que développeur, vous évaluerez les besoins en ressources de votre application, par exemple en termes de processeur et de mémoire, mais si vous ne les ajustez pas continuellement, elles risquent de devenir obsolètes, ce qui peut augmenter vos coûts et détériorer les performances et la fiabilité. Il est plus important d'ajuster en permanence les besoins en ressources d'une application que de les satisfaire correctement du premier coup.
Les meilleures pratiques mentionnées ci-dessous vous aideront à créer et à exploiter des charges de travail sensibles aux coûts qui permettent d'obtenir des résultats commerciaux tout en minimisant les coûts et en permettant à votre organisation de maximiser son retour sur investissement. Voici un ordre d'importance élevé pour optimiser les coûts de calcul de votre cluster :
1. Dimensionnez correctement les charges de travail
1. Réduction de la capacité inutilisée
1. Optimisez les types de capacité de calcul (par exemple Spot) et les accélérateurs (par exemple GPUs)
## Dimensionnez correctement vos charges de travail
Dans la plupart des clusters EKS, l'essentiel des coûts provient des EC2 instances utilisées pour exécuter vos charges de travail conteneurisées. Vous ne serez pas en mesure de dimensionner correctement vos ressources informatiques si vous ne comprenez pas vos exigences en matière de charges de travail. C'est pourquoi il est essentiel que vous utilisiez les demandes et les limites appropriées et que vous modifiiez ces paramètres si nécessaire. En outre, les dépendances, telles que la taille de l'instance et la sélection du stockage, peuvent affecter les performances de la charge de travail, ce qui peut avoir diverses conséquences imprévues sur les coûts et la fiabilité.
*Les demandes* doivent correspondre à l'utilisation réelle. Si les demandes d'un conteneur sont trop élevées, la capacité sera inutilisée, ce qui représente un facteur important dans le coût total du cluster. Chaque conteneur d'un pod, par exemple l'application et les sidecars, doit avoir ses propres demandes et limites définies pour garantir que les limites globales des pods sont aussi précises que possible.
Utilisez des outils tels que [Goldilocks](https://www.youtube.com/watch?v=DfmQWYiwFDk), [KRR](https://www.youtube.com/watch?v=uITOzpf82RY) et [Kubecost](https://aws.amazon.com/blogs/containers/aws-and-kubecost-collaborate-to-deliver-cost-monitoring-for-eks-customers/) pour estimer les demandes de ressources et les limites pour vos conteneurs. En fonction de la nature des applications, des performance/cost exigences et de leur complexité, vous devez déterminer quels indicateurs sont les meilleurs pour évoluer, à quel moment les performances de votre application se dégradent (point de saturation) et comment ajuster les demandes et les limites en conséquence. Veuillez vous référer à la section [Taille correcte de l'application](https://docs.aws.amazon.com/eks/latest/best-practices/node_and_workload_efficiency.html) pour obtenir de plus amples informations à ce sujet.
Nous vous recommandons d'utiliser le Horizontal Pod Autoscaler (HPA) pour contrôler le nombre de répliques de votre application à exécuter, le Vertical Pod Autoscaler (VPA) pour ajuster le nombre de demandes et les limites dont votre application a besoin par réplique, et un autoscaler de nœuds tel que [Karpenter](http://karpenter.sh/) ou [Cluster Autoscaler pour ajuster en permanence le nombre total de nœuds de votre cluster](https://github.com/kubernetes/autoscaler). Les techniques d'optimisation des coûts à l'aide de Karpenter et Cluster Autoscaler sont décrites dans une section ultérieure de ce document.
Le Vertical Pod Autoscaler peut ajuster les demandes et les limites attribuées aux conteneurs afin que les charges de travail s'exécutent de manière optimale. Vous devez exécuter le VPA en mode audit afin qu'il n'apporte pas automatiquement de modifications et ne redémarre pas vos pods. Il proposera des modifications en fonction des indicateurs observés. Toute modification affectant les charges de travail de production doit d'abord être examinée et testée dans un environnement hors production, car elle peut avoir un impact sur la fiabilité et les performances de votre application.
## Réduire la consommation
Le meilleur moyen d'économiser de l'argent est de fournir moins de ressources. L'un des moyens d'y parvenir consiste à ajuster les charges de travail en fonction de leurs exigences actuelles. Vous devez commencer tout effort d'optimisation des coûts en vous assurant que vos charges de travail répondent à leurs exigences et évoluent de manière dynamique. Cela nécessitera d'obtenir des métriques à partir de vos applications et de définir des configurations telles que [https://kubernetes.io/docs/tasks/run-application/configure-pdb/](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)[Pod Readiness Gates](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.5/deploy/pod_readiness_gate/) pour garantir que votre application peut évoluer dynamiquement à la hausse et à la baisse en toute sécurité. Il est important de noter qu'une restriction PodDisruptionBudgets peut empêcher Cluster Autoscaler et Karpenter de réduire les nœuds, étant donné que Cluster Autoscaler et Karpenter respectent tous les deux. PodDisruptionBudgets La valeur « minAvailable » dans le PodDisruptionBudget doit toujours être inférieure au nombre de pods dans le déploiement et vous devez garder une bonne mémoire tampon entre les deux, par exemple dans un déploiement de 6 pods où vous souhaitez qu'un minimum de 4 pods fonctionnent en permanence, réglez le « minAvailable » sur 4. PodDisruptionBidget Cela permettra à Cluster Autoscaler et Karpenter de vider et d'expulser en toute sécurité les pods des nœuds sous-utilisés lors d'un événement de réduction des nœuds. Reportez-vous au document [FAQ de Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-types-of-pods-can-prevent-ca-from-removing-a-node).
L'Horizontal Pod Autoscaler est un autoscaler de charge de travail flexible qui peut ajuster le nombre de répliques nécessaires pour répondre aux exigences de performance et de fiabilité de votre application. Il dispose d'un modèle flexible permettant de définir quand augmenter ou diminuer en fonction de diverses mesures telles que le processeur, la mémoire ou de mesures personnalisées, telles que la profondeur de la file d'attente, le nombre de connexions à un pod, etc.
[Le serveur de métriques Kubernetes permet une mise à l'échelle en réponse à des indicateurs intégrés tels que l'utilisation du processeur et de la mémoire, mais si vous souhaitez effectuer une mise à l'échelle en fonction d'autres indicateurs, tels que la profondeur des files d'attente Amazon CloudWatch ou SQS, vous devez envisager des projets de mise à l'échelle automatique pilotés par des événements tels que KEDA.](https://keda.sh/) Reportez-vous à [ce billet de blog](https://aws.amazon.com/blogs/mt/proactive-autoscaling-of-kubernetes-workloads-with-keda-using-metrics-ingested-into-amazon-cloudwatch/) pour savoir comment utiliser KEDA avec CloudWatch les métriques. Si vous n'êtes pas certain des indicateurs à surveiller et sur lesquels vous baser, consultez les [meilleures pratiques en matière de surveillance des indicateurs importants](https://aws-observability.github.io/observability-best-practices/guides/#monitor-what-matters).
La réduction de la consommation de charge de travail crée une capacité excédentaire dans un cluster et, avec une configuration d'autoscaling appropriée, vous pouvez automatiquement réduire le nombre de nœuds et réduire vos dépenses totales. Nous vous recommandons de ne pas essayer d'optimiser la capacité de calcul manuellement. Le planificateur Kubernetes et les autoscalers de nœuds ont été conçus pour gérer ce processus à votre place.
## Réduction de la capacité inutilisée
Une fois que vous avez déterminé la taille appropriée pour les applications, réduisant ainsi le nombre de demandes excédentaires, vous pouvez commencer à réduire la capacité de calcul allouée. Vous devriez être en mesure de le faire de manière dynamique si vous avez pris le temps de dimensionner correctement vos charges de travail dans les sections ci-dessus. Deux autoscalers de nœuds principaux sont utilisés avec Kubernetes dans AWS.
### Karpenter et Cluster Autoscaler
Karpenter et Kubernetes Cluster Autoscaler augmenteront le nombre de nœuds de votre cluster en fonction de la création ou de la suppression de pods et de l'évolution des exigences de calcul. L'objectif principal des deux est le même, mais Karpenter adopte une approche différente pour le provisionnement et le déprovisionnement de la gestion des nœuds, ce qui peut contribuer à réduire les coûts et à optimiser l'utilisation à l'échelle du cluster.
À mesure que la taille des clusters augmente et que la variété des charges de travail augmente, il devient de plus en plus difficile de préconfigurer les groupes de nœuds et les instances. Tout comme pour les demandes de charge de travail, il est important de définir une base de référence initiale et de l'ajuster en permanence selon les besoins.
Si vous utilisez Cluster Autoscaler, il respectera les valeurs « minimum » et « maximum » de chaque groupe Auto Scaling (ASG) et ajustera uniquement la valeur « souhaitée ». Il est important de faire attention lorsque vous définissez ces valeurs pour l'ASG sous-jacent, car Cluster Autoscaler ne sera pas en mesure de réduire un ASG au-delà de son nombre « minimum ». Définissez le nombre « souhaité » comme le nombre de nœuds dont vous avez besoin pendant les heures normales de bureau et le nombre « minimum » comme le nombre de nœuds dont vous avez besoin en dehors des heures de bureau. Reportez-vous au document [FAQ de Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#auto-discovery-setup).
### Expandeur de priorité Cluster Autoscaler
Le Kubernetes Cluster Autoscaler fonctionne en redimensionnant des groupes de nœuds (appelés groupes de nœuds) vers le haut ou vers le bas au fur et à mesure que les applications augmentent ou diminuent. Si vous ne dimensionnez pas les charges de travail de manière dynamique, le Cluster Autoscaler ne vous aidera pas à économiser de l'argent. Le Cluster Autoscaler nécessite qu'un administrateur du cluster crée des groupes de nœuds à l'avance pour que les charges de travail soient consommées. Les groupes de nœuds doivent être configurés pour utiliser des instances ayant le même « profil », c'est-à-dire à peu près la même quantité de processeur et de mémoire.
Vous pouvez avoir plusieurs groupes de nœuds et le Cluster Autoscaler peut être configuré pour définir des niveaux de dimensionnement prioritaires. Chaque groupe de nœuds peut contenir des nœuds de tailles différentes. Les groupes de nœuds peuvent avoir différents types de capacité et l'extenseur de priorité peut d'abord être utilisé pour dimensionner les groupes les moins coûteux.
Vous trouverez ci-dessous un exemple d'extrait de configuration de cluster qui utilise un `ConfigMap`` pour prioriser la capacité réservée avant d'utiliser des instances à la demande. Vous pouvez utiliser la même technique pour prioriser les instances Graviton ou Spot par rapport aux autres types.
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
managedNodeGroups:
- name: managed-ondemand
minSize: 1
maxSize: 7
instanceType: m5.xlarge
- name: managed-reserved
minSize: 2
maxSize: 10
instanceType: c5.2xlarge
```
```
apiVersion: v1
kind: ConfigMap
metadata:
name: cluster-autoscaler-priority-expander
namespace: kube-system
data:
priorities: |-
10:
- .*ondemand.*
50:
- .*reserved.*
```
L'utilisation de groupes de nœuds peut aider les ressources de calcul sous-jacentes à faire ce que l'on attend par défaut, par exemple en répartissant les nœuds AZs, mais toutes les charges de travail n'ont pas les mêmes exigences ou attentes. Il est donc préférable de laisser les applications déclarer leurs besoins de manière explicite. Pour plus d'informations sur Cluster Autoscaler, consultez la section des [meilleures pratiques](https://docs.aws.amazon.com/eks/latest/best-practices/cas.html).
### Déplanificateur
Le Cluster Autoscaler peut ajouter et supprimer de la capacité des nœuds d'un cluster en fonction de la nécessité de planifier de nouveaux pods ou de la sous-utilisation de nœuds. Il ne prend pas en compte de manière globale le placement des pods une fois qu'ils ont été planifiés sur un nœud. Si vous utilisez le Cluster Autoscaler, vous devez également consulter le [déplanificateur Kubernetes pour éviter de gaspiller de la capacité dans](https://github.com/kubernetes-sigs/descheduler) votre cluster.
Si vous avez 10 nœuds dans un cluster et que chaque nœud est utilisé à 60 %, vous n'utilisez pas 40 % de la capacité allouée dans le cluster. Avec le Cluster Autoscaler, vous pouvez définir le seuil d'utilisation par nœud à 60 %, mais cela n'essaiera de réduire qu'un seul nœud lorsque l'utilisation est tombée en dessous de 60 %.
Avec le déplanificateur, il peut examiner la capacité et l'utilisation du cluster une fois que les pods ont été planifiés ou que des nœuds ont été ajoutés au cluster. Il tente de maintenir la capacité totale du cluster au-dessus d'un seuil spécifié. Il peut également supprimer des pods en fonction de l'altération des nœuds ou de nouveaux nœuds qui rejoignent le cluster pour s'assurer que les pods fonctionnent dans leur environnement informatique optimal. Notez que le déplanificateur ne planifie pas le remplacement des pods expulsés mais s'appuie sur le planificateur par défaut pour cela.
### Consolidation de Karpenter
Karpenter adopte une approche « sans groupe » pour la gestion des nœuds. Cette approche est plus flexible pour les différents types de charge de travail et nécessite moins de configuration initiale pour les administrateurs de clusters. Au lieu de prédéfinir des groupes et de dimensionner chaque groupe en fonction des besoins des charges de travail, Karpenter utilise des fournisseurs et des modèles de nœuds pour définir de manière générale le type d' EC2 instances pouvant être créées et les paramètres relatifs aux instances au fur et à mesure de leur création.
Le bin packing est une pratique qui consiste à utiliser une plus grande partie des ressources de l'instance en répartissant davantage de charges de travail sur un nombre réduit d'instances de taille optimale. Bien que cela contribue à réduire vos coûts de calcul en provisionnant uniquement les ressources utilisées par vos charges de travail, cela comporte un compromis. Le démarrage de nouvelles charges de travail peut prendre plus de temps car de la capacité doit être ajoutée au cluster, en particulier lors d'événements de grande envergure. Tenez compte de l'équilibre entre l'optimisation des coûts, les performances et la disponibilité lors de la configuration de l'emballage en bacs.
Karpenter peut effectuer une surveillance continue et un binpack afin d'améliorer l'utilisation des ressources des instances et de réduire vos coûts de calcul. Karpenter peut également sélectionner un nœud de travail plus rentable pour votre charge de travail. Cela peut être réalisé en activant l'indicateur « consolidation » sur true dans le fournisseur (exemple d'extrait de code ci-dessous). L'exemple ci-dessous montre un exemple de fournisseur qui permet la consolidation. Au moment de la rédaction de ce guide, Karpenter ne remplacera pas une instance Spot en cours d'exécution par une instance Spot moins chère. Pour plus de détails sur la consolidation de Karpenter, consultez [ce blog](https://aws.amazon.com/blogs/containers/optimizing-your-kubernetes-compute-costs-with-karpenter-consolidation/).
```
apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
name: enable-binpacking
spec:
consolidation:
enabled: true
```
Pour les charges de travail susceptibles de ne pas être interruptibles, par exemple les tâches par lots de longue durée sans point de contrôle, pensez à annoter les pods avec l'annotation. `do-not-evict` En refusant l'expulsion des modules, vous dites à Karpenter qu'il ne doit pas supprimer volontairement les nœuds contenant ce module. Toutefois, si un `do-not-evict` pod est ajouté à un nœud alors que celui-ci se vide, les pods restants seront tout de même expulsés, mais ce pod bloquera la terminaison jusqu'à ce qu'il soit retiré. Dans les deux cas, le nœud sera bouclé pour empêcher que des travaux supplémentaires ne soient planifiés sur le nœud. Vous trouverez ci-dessous un exemple montrant comment définir l'annotation :
```
apiVersion: v1
kind: Pod
metadata:
name: label-demo
labels:
environment: production
annotations: +
"karpenter.sh/do-not-evict": "true"
spec:
containers:
* name: nginx
image: nginx
ports:
** containerPort: 80
```
### Supprimez les nœuds sous-utilisés en ajustant les paramètres du Cluster Autoscaler
L'utilisation des nœuds est définie comme la somme des ressources demandées divisée par la capacité. Par défaut, `scale-down-utilization-threshold` il est défini sur 50 %. Ce paramètre peut être utilisé conjointement avec et`scale-down-unneeded-time`, qui détermine la durée pendant laquelle un nœud doit être inutile avant de pouvoir être réduit. La valeur par défaut est de 10 minutes. Les pods toujours en cours d'exécution sur un nœud réduit seront planifiés sur d'autres nœuds par kube-scheduler. L'ajustement de ces paramètres peut aider à supprimer les nœuds sous-utilisés, mais il est important de tester d'abord ces valeurs afin de ne pas forcer le cluster à se réduire prématurément.
Vous pouvez empêcher la réduction de la taille en veillant à ce que les pods dont l'expulsion coûte cher soient protégés par une étiquette reconnue par le Cluster Autoscaler. Pour ce faire, assurez-vous que les pods dont l'expulsion coûte cher comportent l'annotation`cluster-autoscaler.kubernetes.io/safe-to-evict=false`. Voici un exemple de fichier yaml pour définir l'annotation :
```
apiVersion: v1
kind: Pod
metadata:
name: label-demo
labels:
environment: production
annotations: +
"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"
spec:
containers:
* name: nginx
image: nginx
ports:
** containerPort: 80
```
### Étiquetez les nœuds avec Cluster Autoscaler et Karpenter
Les [balises](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) de ressources AWS sont utilisées pour organiser vos ressources et pour suivre vos coûts AWS de manière détaillée. Ils ne sont pas directement corrélés aux étiquettes Kubernetes pour le suivi des coûts. Il est recommandé de commencer par l'étiquetage des ressources Kubernetes et d'utiliser des outils tels que [Kubecost pour obtenir des rapports sur les coûts d'infrastructure basés sur les étiquettes Kubernetes](https://aws.amazon.com/blogs/containers/aws-and-kubecost-collaborate-to-deliver-cost-monitoring-for-eks-customers/) apposées sur les pods, les espaces de noms, etc.
Les nœuds de travail doivent disposer de balises pour afficher les informations de facturation dans AWS Cost Explorer. Avec Cluster Autoscaler, balisez vos nœuds de travail au sein d'un groupe de nœuds gérés à l'aide d'un modèle de [lancement](https://docs.aws.amazon.com/eks/latest/userguide/launch-templates.html). Pour les groupes de nœuds autogérés, balisez vos instances à l'aide [du groupe de dimensionnement EC2 automatique](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-tagging.html). Pour les instances mises en service par Karpenter, balisez-les à l'aide de [spec.tags dans](https://karpenter.sh/docs/concepts/nodeclasses/#spectags) le modèle de nœud.
### Clusters à locataires multiples
Lorsque vous travaillez sur des clusters partagés par différentes équipes, vous risquez de ne pas avoir de visibilité sur les autres charges de travail exécutées sur le même nœud. Bien que les demandes de ressources puissent aider à isoler certains problèmes liés aux « voisins bruyants », tels que le partage du processeur, elles peuvent ne pas isoler toutes les limites des ressources, telles que I/O l'épuisement du disque. Toutes les ressources consommables d'une charge de travail ne peuvent pas être isolées ou limitées. Les charges de travail qui consomment des ressources partagées à des taux plus élevés que les autres charges de travail doivent être isolées en fonction des [entorses](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) et des tolérances des nœuds. Une autre technique avancée pour une telle charge de travail est l'[épinglage du processeur](https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#static-policy), qui garantit un processeur exclusif au lieu d'un processeur partagé pour le conteneur.
[L'isolation des charges de travail au niveau d'un nœud peut s'avérer plus coûteuse, mais il est possible de planifier des [BestEffort](https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/#besteffort)tâches ou de réaliser des économies supplémentaires en utilisant des [instances réservées](https://aws.amazon.com/ec2/pricing/reserved-instances/), des [processeurs Graviton](https://aws.amazon.com/ec2/graviton/) ou Spot.](https://aws.amazon.com/ec2/spot/)
Les clusters partagés peuvent également être soumis à des contraintes de ressources au niveau du cluster, telles que l'épuisement des adresses IP, les limites de service Kubernetes ou les demandes de dimensionnement des API. Vous devriez consulter le [guide des meilleures pratiques d'évolutivité](https://docs.aws.amazon.com/eks/latest/best-practices/scale-control-plane.html) pour vous assurer que vos clusters respectent ces limites.
Vous pouvez isoler les ressources au niveau d'un espace de noms ou d'un approvisionneur Karpenter. [Les quotas de ressources](https://kubernetes.io/docs/concepts/policy/resource-quotas/) permettent de définir des limites quant au nombre de ressources que les charges de travail peuvent consommer dans un espace de noms. Cela peut être un bon garde-fou initial, mais il doit être évalué en permanence pour s'assurer qu'il n'empêche pas artificiellement l'augmentation des charges de travail.
Les fournisseurs Karpenter peuvent [définir des limites sur certaines des ressources consommables](https://karpenter.sh/docs/concepts/nodepools/#speclimitsresources) d'un cluster (par exemple, processeur, GPU), mais vous devrez configurer les applications clientes pour utiliser le fournisseur approprié. Cela peut empêcher un seul fournisseur de créer trop de nœuds dans un cluster, mais il convient de l'évaluer en permanence pour s'assurer que la limite n'est pas trop basse et, par conséquent, empêcher les charges de travail de s'étendre.
### Mise à l'échelle automatique planifiée
Il se peut que vous deviez réduire la taille de vos clusters le week-end et en dehors des heures de bureau. Cela est particulièrement pertinent pour les clusters de test et non liés à la production pour lesquels vous souhaitez réduire à zéro lorsqu'ils ne sont pas utilisés. Des solutions telles que [cluster-turndown peuvent réduire le](https://github.com/kubecost/cluster-turndown) nombre de répliques à zéro en fonction d'un calendrier cron. Vous pouvez également y parvenir avec Karpenter, comme indiqué dans le blog [AWS](https://aws.amazon.com/blogs/containers/manage-scale-to-zero-scenarios-with-karpenter-and-serverless/) suivant.
## Optimisation des types de capacité de calcul
Après avoir optimisé la capacité de calcul totale de votre cluster et utilisé le bin packing, vous devez examiner le type de calcul que vous avez fourni dans vos clusters et le mode de paiement de ces ressources. AWS propose des [plans d'économies de calcul](https://aws.amazon.com/savingsplans/compute-pricing/) qui peuvent réduire le coût de votre calcul. Nous les classerons selon les types de capacité suivants :
+ Spot
+ Savings Plans
+ À la demande
+ Fargate
Chaque type de capacité comporte des compromis différents en termes de frais de gestion, de disponibilité et d'engagements à long terme, et vous devrez choisir celui qui convient le mieux à votre environnement. Aucun environnement ne doit reposer sur un seul type de capacité et vous pouvez combiner plusieurs types d'exécution dans un seul cluster afin d'optimiser les exigences et les coûts de charge de travail spécifiques.
### Spot
Le type de capacité [ponctuelle](https://aws.amazon.com/ec2/spot/) approvisionne EC2 les instances à partir de la capacité inutilisée d'une zone de disponibilité. Spot propose les remises les plus importantes (jusqu'à 90 %), mais ces instances peuvent être interrompues lorsqu'elles sont nécessaires ailleurs. En outre, il n'est pas toujours possible de fournir de nouvelles instances Spot et les instances Spot existantes peuvent être récupérées moyennant un [préavis d'interruption de 2 minutes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html). Si le processus de démarrage ou d'arrêt de votre application est long, les instances Spot ne sont peut-être pas la meilleure option.
Le calcul ponctuel doit utiliser une grande variété de types d'instances afin de réduire le risque de ne pas disposer de capacité ponctuelle disponible. Les interruptions d'instance doivent être gérées pour arrêter les nœuds en toute sécurité. Les nœuds approvisionnés avec Karpenter ou faisant partie d'un groupe de nœuds gérés prennent automatiquement en charge les notifications d'[interruption d'instance](https://docs.aws.amazon.com/eks/latest/best-practices/karpenter.html). Si vous utilisez des nœuds autogérés, vous devrez exécuter le [gestionnaire de terminaison de nœuds](https://github.com/aws/aws-node-termination-handler) séparément pour arrêter correctement les instances ponctuelles.
Il est possible d'équilibrer les instances ponctuelles et à la demande dans un seul cluster. Avec Karpenter, vous pouvez créer des [approvisionneurs pondérés afin de trouver un équilibre entre les](https://karpenter.sh/docs/concepts/scheduling/#on-demandspot-ratio-split) différents types de capacité. Avec Cluster Autoscaler, vous pouvez créer des [groupes de nœuds mixtes avec des instances ponctuelles, à la demande ou réservées.](https://aws.amazon.com/blogs/containers/amazon-eks-now-supports-provisioning-and-managing-ec2-spot-instances-in-managed-node-groups/)
Voici un exemple d'utilisation de Karpenter pour prioriser les instances Spot par rapport aux instances à la demande. Lorsque vous créez un fournisseur, vous pouvez spécifier Spot, On-Demand ou les deux (comme indiqué ci-dessous). [Lorsque vous spécifiez les deux, et si le pod ne précise pas explicitement s'il doit utiliser Spot ou On-Demand, Karpenter donne la priorité à Spot lorsqu'il approvisionne un nœud avec une stratégie d'allocation. price-capacity-optimization ](https://aws.amazon.com/blogs/compute/introducing-price-capacity-optimized-allocation-strategy-for-ec2-spot-instances/)
```
apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
name: spot-prioritized
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot", "on-demand"]
```
### Savings Plans, instances réservées et AWS EDP
Vous pouvez réduire vos dépenses informatiques en utilisant un [plan d'économies de calcul](https://aws.amazon.com/savingsplans/compute-pricing/). Les plans d'épargne offrent des prix réduits pour un engagement d'un ou trois ans d'utilisation du calcul. L'utilisation peut s'appliquer aux EC2 instances d'un cluster EKS, mais s'applique également à toute utilisation de calcul telle que Lambda et Fargate. Grâce aux plans d'épargne, vous pouvez réduire les coûts tout en continuant à choisir n'importe quel type d' EC2 instance pendant votre période d'engagement.
Un plan d'économies de calcul peut réduire vos EC2 coûts jusqu'à 66 % sans nécessiter d'engagement quant aux types d'instances, aux familles ou aux régions que vous souhaitez utiliser. Les économies sont automatiquement appliquées aux instances lorsque vous les utilisez.
EC2 Instance Savings Plans permet de réaliser jusqu'à 72 % d'économies sur le calcul avec un engagement d'utilisation dans une région et une EC2 famille spécifiques, par exemple les instances de la famille C. Vous pouvez transférer l'utilisation vers n'importe quelle zone de la région, utiliser n'importe quelle génération de la famille d'instances, par exemple c5 ou c6, et utiliser n'importe quelle taille d'instance au sein de la famille. La réduction sera automatiquement appliquée à toute instance de votre compte correspondant aux critères du plan d'épargne.
Les [instances réservées](https://aws.amazon.com/ec2/pricing/reserved-instances/) sont similaires à EC2 Instance Savings Plan, mais elles garantissent également la capacité dans une zone de disponibilité ou une région et réduisent les coûts (jusqu'à 72 %) par rapport aux instances à la demande. Une fois que vous aurez calculé la capacité réservée dont vous aurez besoin, vous pourrez sélectionner la durée pour laquelle vous souhaitez les réserver (1 an ou 3 ans). Les remises seront automatiquement appliquées lorsque vous exécuterez ces EC2 instances dans votre compte.
Les clients ont également la possibilité de souscrire un contrat d'entreprise avec AWS. Les contrats d’entreprise offrent aux clients la possibilité de personnaliser les accords qui répondent le mieux à leurs besoins. Les clients peuvent bénéficier de remises sur les tarifs basés sur le programme AWS EDP (Enterprise Discount Program). Pour plus d'informations sur les contrats d'entreprise, veuillez contacter votre représentant commercial AWS.
### À la demande
Les EC2 instances à la demande présentent l'avantage d'une disponibilité sans interruption, par rapport aux instances ponctuelles, et de l'absence d'engagement à long terme, par rapport aux plans d'épargne. Si vous souhaitez réduire les coûts d'un cluster, vous devez réduire votre utilisation des EC2 instances à la demande.
Après avoir optimisé vos exigences en matière de charge de travail, vous devriez être en mesure de calculer une capacité minimale et maximale pour vos clusters. Ce chiffre peut changer au fil du temps, mais il diminue rarement. Envisagez d'utiliser un Savings Plan pour tout ce qui est inférieur au minimum, et optez pour une capacité qui n'affectera pas la disponibilité de votre application. Tout autre élément qui ne peut pas être utilisé en permanence ou qui est requis pour des raisons de disponibilité peut être utilisé à la demande.
Comme indiqué dans cette section, le meilleur moyen de réduire votre consommation est de consommer moins de ressources et d'utiliser au maximum les ressources que vous fournissez. Avec le Cluster Autoscaler, vous pouvez supprimer les nœuds sous-utilisés à l'aide du paramètre. `scale-down-utilization-threshold` Avec Karpenter, il est recommandé d'activer la consolidation.
Pour identifier manuellement les types d' EC2 instances qui peuvent être utilisés avec vos charges de travail, vous devez utiliser [ec2-instance-selector](https://github.com/aws/amazon-ec2-instance-selector), qui peut afficher les instances disponibles dans chaque région ainsi que les instances compatibles avec EKS. Exemple d'utilisation pour des instances dotées d'une architecture de processus x86, de 4 Go de mémoire, de 2 V CPUs et disponibles dans la région us-east-1.
```
ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 \
-r us-east-1 --service eks
c5.large
c5a.large
c5ad.large
c5d.large
c6a.large
c6i.large
t2.medium
t3.medium
t3a.medium
```
Pour les environnements non liés à la production, vous pouvez automatiquement réduire la taille des clusters pendant les heures non utilisées, telles que la nuit et le week-end. Le [cluster-turndown](https://github.com/kubecost/cluster-turndown) du projet kubecost est un exemple de contrôleur capable de réduire automatiquement votre cluster en fonction d'un calendrier défini.
### Ordinateur Fargate
Le calcul Fargate est une option de calcul entièrement gérée pour les clusters EKS. Il permet d'isoler les pods en planifiant un pod par nœud dans un cluster Kubernetes. Il vous permet de dimensionner vos nœuds de calcul en fonction des besoins en CPU et en RAM de votre charge de travail afin de contrôler étroitement l'utilisation de la charge de travail dans un cluster.
Fargate peut faire évoluer des charges de travail allant de 2,5 vCPU avec 0,5 Go de mémoire à 16 vCPU avec 120 Go de mémoire. Le nombre de [variations de taille des pods](https://docs.aws.amazon.com/eks/latest/userguide/fargate-pod-configuration.html) disponibles est limité et vous devez comprendre comment votre charge de travail s'adapte le mieux à une configuration Fargate. Par exemple, si votre charge de travail nécessite 1 vCPU avec 0,5 Go de mémoire, le plus petit pod Fargate sera un vCPU avec 2 Go de mémoire.
Bien que Fargate présente de nombreux avantages, tels que l' EC2 absence de gestion d'instance ou de système d'exploitation, il peut nécessiter une capacité de calcul supérieure à celle des instances EC2 traditionnelles, car chaque pod déployé est isolé en tant que nœud distinct dans le cluster. Cela nécessite davantage de duplication pour des éléments tels que le Kubelet, les agents de journalisation et tout ce DaemonSets que vous déployez généralement sur un nœud. DaemonSets ne sont pas pris en charge dans Fargate et ils devront être convertis en pods « `sidecars » et exécutés en même temps que l'application.
Fargate ne peut pas tirer parti du bin packing ou du surprovisionnement du processeur, car la limite de la charge de travail est un nœud qui n'est pas extensible ou partageable entre les charges de travail. Fargate EC2 vous permettra de gagner du temps dans la gestion des instances, ce qui a un coût en soi, mais les coûts liés au processeur et à la mémoire peuvent être plus élevés que ceux EC2 des autres types de capacité. Les modules Fargate peuvent tirer parti d'un plan d'économies de calcul pour réduire les coûts à la demande.
## Optimisation de l'utilisation du calcul
Une autre façon d'économiser de l'argent sur votre infrastructure informatique consiste à utiliser un calcul plus efficace pour la charge de travail. Cela peut être dû à des solutions informatiques à usage général plus performantes, comme les [processeurs Graviton](https://aws.amazon.com/ec2/graviton/), qui sont jusqu'à 20 % moins chers et 60 % plus économes en énergie qu'un processeur x86, ou à des accélérateurs spécifiques à la charge de travail tels que et. GPUs [FPGAs](https://aws.amazon.com/ec2/instance-types/f1/) Vous devrez créer des conteneurs pouvant [fonctionner sur l'architecture ARM](https://aws.amazon.com/blogs/containers/how-to-build-your-containers-for-arm-and-save-with-graviton-and-spot-instances-on-amazon-ecs/) et [configurer des nœuds dotés des accélérateurs adaptés à](https://aws.amazon.com/blogs/compute/running-gpu-accelerated-kubernetes-workloads-on-p3-and-p2-ec2-instances-with-amazon-eks/) vos charges de travail.
EKS est capable d'exécuter des clusters à architecture mixte (par exemple amd64 et arm64) et si vos conteneurs sont compilés pour plusieurs architectures, vous pouvez tirer parti des processeurs Graviton avec Karpenter en autorisant les deux architectures dans votre fournisseur. Pour maintenir des performances constantes, il est toutefois recommandé de conserver chaque charge de travail sur une architecture informatique unique et de n'utiliser une architecture différente que si aucune capacité supplémentaire n'est disponible.
Les fournisseurs peuvent être configurés avec plusieurs architectures et les charges de travail peuvent également demander des architectures spécifiques dans leurs spécifications de charge de travail.
```
apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
name: default
spec:
requirements:
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
```
Avec Cluster Autoscaler, vous devez créer un groupe de nœuds pour les instances Graviton et définir des [tolérances de nœuds sur votre charge de travail](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) afin d'utiliser la nouvelle capacité.
GPUs et FPGAs peut augmenter considérablement les performances de votre charge de travail, mais celle-ci devra être optimisée pour utiliser l'accélérateur. De nombreux types de charges de travail pour l'apprentissage automatique et l'intelligence artificielle peuvent être utilisés GPUs pour le calcul, et les instances peuvent être ajoutées à un cluster et montées dans une charge de travail à l'aide de demandes de ressources.
```
spec:
template:
spec:
- containers:
...
resources:
limits:
nvidia.com/gpu: "1"
```
Certains matériels GPU peuvent être partagés entre plusieurs charges de travail afin qu'un seul GPU puisse être provisionné et utilisé. Pour savoir comment configurer le partage de charge de travail par GPU, consultez le [plug-in du périphérique GPU virtuel](https://aws.amazon.com/blogs/opensource/virtual-gpu-device-plugin-for-inference-workload-in-kubernetes/) pour plus d'informations. Vous pouvez également consulter les blogs suivants :
+ [Partage de GPU sur Amazon EKS avec le découpage temporel et les instances accélérées NVIDIA EC2 ](https://aws.amazon.com/blogs/containers/gpu-sharing-on-amazon-eks-with-nvidia-time-slicing-and-accelerated-ec2-instances/)
+ [Optimisation de l’utilisation des GPU avec le GPU multi-instances (MIG) de NVIDIA sur Amazon EKS : exécution d’un plus grand nombre de pods par GPU pour des performances améliorées](https://aws.amazon.com/blogs/containers/maximizing-gpu-utilization-with-nvidias-multi-instance-gpu-mig-on-amazon-eks-running-more-pods-per-gpu-for-enhanced-performance/)
# Optimisation des coûts - Mise en réseau
L'architecture des systèmes pour une haute disponibilité (HA) est une bonne pratique pour garantir la résilience et la tolérance aux pannes. Dans la pratique, cela signifie répartir vos charges de travail et l'infrastructure sous-jacente sur plusieurs zones de disponibilité (AZs) dans une région AWS donnée. La mise en place de ces caractéristiques pour votre environnement Amazon EKS améliorera la fiabilité globale de votre système. Parallèlement à cela, vos environnements EKS seront probablement également composés d'une variété de constructions (c'est-à-dire VPCs), de composants (c'est-à-dire) et d'intégrations (par exemple, ECR et autres registres de conteneurs ELBs).
La combinaison de systèmes à haute disponibilité et d'autres composants spécifiques à des cas d'utilisation peut jouer un rôle important dans la manière dont les données sont transférées et traitées. Cela aura à son tour un impact sur les coûts liés au transfert et au traitement des données.
Les pratiques détaillées ci-dessous vous aideront à concevoir et à optimiser vos environnements EKS afin d'atteindre un meilleur rapport coût-efficacité pour différents domaines et cas d'utilisation.
## Communication d'un pod à un autre
En fonction de votre configuration, la communication réseau et le transfert de données entre les pods peuvent avoir un impact significatif sur le coût global d'exécution des charges de travail Amazon EKS. Cette section abordera différents concepts et approches visant à atténuer les coûts liés à la communication entre les pods, tout en tenant compte des architectures à haute disponibilité (HA), des performances des applications et de la résilience.
### Limiter le trafic à une zone de disponibilité
Le projet Kubernetes a commencé très tôt à développer des constructions sensibles à la topologie, notamment des étiquettes telles que kubernetes. io/hostname, topology.kubernetes.io/region, and topology.kubernetes.io/zoneattribué aux nœuds pour activer des fonctionnalités telles que la répartition de la charge de travail entre les domaines de défaillance et les approvisionneurs de volumes sensibles à la topologie. Après avoir obtenu leur diplôme dans Kubernetes 1.17, les étiquettes ont également été utilisées pour permettre des fonctionnalités de routage adaptées à la topologie pour la communication entre pods.
Vous trouverez ci-dessous quelques stratégies permettant de contrôler le volume de trafic cross-AZ entre les pods de votre cluster EKS afin de réduire les coûts et de minimiser la latence.
*Si vous souhaitez obtenir une visibilité précise de la quantité de trafic cross-AZ entre les pods de votre cluster (par exemple, la quantité de données transférées en octets), [consultez cet article](https://aws.amazon.com/blogs/containers/getting-visibility-into-your-amazon-eks-cross-az-pod-to-pod-network-bytes/).*
![\[Routage tenant compte de la topologie\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/topo_aware_routing.png)
Comme le montre le schéma ci-dessus, les services sont la couche d'abstraction réseau stable qui reçoit le trafic destiné à vos pods. Lorsqu'un service est créé, plusieurs EndpointSlices sont créés. Chacun EndpointSlice possède une liste de points de terminaison contenant un sous-ensemble d'adresses Pod ainsi que les nœuds sur lesquels ils s'exécutent et toute information topologique supplémentaire. Lors de l'utilisation de l'Amazon VPC CNI, kube-proxy, un daemonset exécuté sur chaque nœud, maintient les règles réseau pour permettre la communication avec le pod et la découverte de services (une alternative basée sur eBPF CNIs peut ne pas utiliser kube-proxy mais fournir un comportement équivalent). Il joue le rôle de routage interne, mais il le fait en fonction de ce qu'il consomme du produit créé EndpointSlices.
Sur EKS, kube-proxy utilise principalement les règles NAT iptables (ou [IPVS](https://docs.aws.amazon.com/eks/latest/best-practices/ipvs.html), [NFTables](https://kubernetes.io/blog/2025/02/28/nftables-kube-proxy/)comme alternative) pour la distribution du trafic entre tous les pods du cluster, quel que soit leur nœud ou leur emplacement AZ. Cette distribution par défaut peut entraîner un routage du trafic inter-AZ, ce qui peut entraîner une augmentation de la latence pour les applications sensibles et des frais de transfert de données inter-AZ dans les déploiements de grande envergure.
**Utilisation du routage adapté à la topologie (anciennement connu sous le nom de topologie sensible à la topologie)**
Lorsque le [https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) est activé et implémenté sur un service Kubernetes, le EndpointSlice contrôleur alloue proportionnellement des points de terminaison aux différentes zones dans lesquelles votre cluster est réparti. Pour chacun de ces points de terminaison, le EndpointSlice contrôleur définira également un *indice* pour la zone. Les *conseils* décrivent la zone pour laquelle un point de terminaison doit desservir le trafic. `kube-proxy`acheminera ensuite le trafic d'une zone vers un point de terminaison en fonction *des indications* appliquées.
Le schéma ci-dessous montre comment EndpointSlices les indices sont organisés de manière à savoir vers quelle destination ils doivent se rendre en fonction de leur point d'origine zonal. `kube-proxy` Sans indications, il n'existe pas d'allocation ou d'organisation de ce type et le trafic sera acheminé par proxy vers différentes destinations zonales, quelle que soit sa provenance.
![\[Endpoint Slice\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/endpoint_slice.png)
Dans certains cas, le EndpointSlice contrôleur peut appliquer un *indice* pour une zone différente, ce qui signifie que le point de terminaison peut finir par desservir le trafic provenant d'une autre zone. La raison en est d'essayer de maintenir une répartition uniforme du trafic entre les points de terminaison situés dans différentes zones.
Vous trouverez ci-dessous un extrait de code expliquant comment activer le *routage adapté à la topologie pour* un service.
```
apiVersion: v1
kind: Service
metadata:
name: orders-service
namespace: ecommerce
annotations:
service.kubernetes.io/topology-mode: Auto
spec:
selector:
app: orders
type: ClusterIP
ports:
* protocol: TCP
port: 3003
targetPort: 3003
```
La capture d'écran ci-dessous montre le résultat obtenu lorsque le EndpointSlice contrôleur a correctement appliqué un indice à un point de terminaison pour une réplique de Pod exécutée dans l'Arizona`eu-west-1a`.
![\[Coquille en tranches\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/slice_shell.png)
**Note**
Il est important de noter que le routage tenant compte de la topologie est toujours en version bêta. Cette fonctionnalité fonctionne de manière plus prévisible avec des charges de travail réparties uniformément dans la topologie du cluster, car le contrôleur alloue les points de terminaison de manière proportionnelle entre les zones, mais peut ignorer les assignations d'indices lorsque les ressources des nœuds d'une zone sont trop déséquilibrées pour éviter une surcharge excessive. Par conséquent, il est fortement recommandé de l'utiliser en conjonction avec des contraintes de planification qui augmentent la disponibilité d'une application, telles que les [contraintes de propagation de la topologie des pods](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/). Notez que les indices peuvent également ne pas être attribués lorsque la capacité fluctue entre les zones, par exemple lors de l'utilisation d'instances [ponctuelles Amazon EC2](https://aws.amazon.com/ec2/spot/), car les interruptions ou les remplacements ne sont pas détectés en temps réel lors du calcul de la distribution proportionnelle.
**Utilisation de la distribution du trafic**
Introduite dans Kubernetes 1.30 et rendue généralement disponible dans la version 1.33, la [distribution du trafic](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution) offre une alternative plus simple au routage basé sur la topologie pour la préférence du trafic dans la même zone. Bien que Topology Aware Routing tente d'utiliser une approche intelligente du routage du trafic pour éviter de surcharger les points de terminaison, cela a entraîné un comportement imprévisible. La distribution du trafic privilégie plutôt la prévisibilité. *L' PreferClose option demande à kube-proxy de créer des règles qui acheminent d'abord le trafic vers les points de terminaison de même zone en fonction de l'indice zonal défini par le contrôleur.* EndpointSlice Lorsqu'aucun point de terminaison de même zone n'est disponible, il suffit de répartir le trafic entre n'importe quel point de terminaison du cluster pour le service. Cette fonctionnalité est conçue pour les charges de travail qui acceptent le compromis consistant à optimiser la proximité plutôt que la tentative de répartition uniforme de la charge proposée par le routage basé sur la topologie.
Vous trouverez ci-dessous un extrait de code expliquant comment activer la *distribution du trafic* pour un service.
```
apiVersion: v1
kind: Service
metadata:
name: orders-service
namespace: ecommerce
spec:
trafficDistribution: PreferClose
selector:
app: orders
type: ClusterIP
ports:
* protocol: TCP
port: 3003
targetPort: 3003
```
Lors de l'activation de la distribution du trafic, un défi courant se pose : les points de terminaison d'une même zone de zone peuvent être surchargés si la majeure partie du trafic provient de cette même zone. Cette surcharge peut créer des problèmes importants :
+ Un seul HPA (Horizontal Pod Autoscaler) gérant un déploiement multi-AZ peut réagir en répartissant les pods entre différents. AZs Cependant, cette action ne permet pas de remédier efficacement à l'augmentation de la charge dans la zone affectée.
+ Cette situation peut à son tour entraîner une inefficacité des ressources. Lorsque des autoscalers de clusters tels que Karpenter détectent le scale-out entre différents modules AZs, ils peuvent approvisionner des nœuds supplémentaires dans les nœuds non affectés AZs, ce qui entraîne une allocation de ressources inutile.
Pour relever ce défi :
+ Créez des déploiements distincts par zone, qui auraient leur propre capacité HPAs à évoluer indépendamment les uns des autres.
+ Tirez parti des contraintes de répartition topologique pour garantir la répartition de la charge de travail au sein du cluster, ce qui permet d'éviter la surcharge des terminaux dans les zones à fort trafic.
**Utilisation d'autoscalers : provisionner des nœuds vers une zone de disponibilité spécifique**
*Nous vous recommandons vivement* d'exécuter vos charges de travail dans des environnements à haute disponibilité répartis sur plusieurs AZs environnements. Cela améliore la fiabilité de vos applications, en particulier en cas d'incident lié à un problème avec un AZ. Si vous êtes prêt à sacrifier la fiabilité pour réduire les coûts liés au réseau, vous pouvez limiter vos nœuds à une seule AZ.
Pour exécuter tous vos pods dans la même zone de zone, configurez les nœuds de travail dans la même zone ou planifiez les pods sur les nœuds de travail exécutés sur la même zone de zone. Pour approvisionner des nœuds au sein d'une seule AZ, définissez un groupe de nœuds avec des sous-réseaux appartenant à la même AZ avec [Cluster Autoscaler (CA)](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler). Pour [Karpenter,](https://karpenter.sh/) utilisez `topology.kubernetes.io/zone` et spécifiez l'AZ dans laquelle vous souhaitez créer les nœuds de travail. Par exemple, l'extrait de code Karpenter Provisioner ci-dessous approvisionne les nœuds de l'AZ us-west-2a.
**Charpentier**
```
apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
name: single-az
spec:
requirements:
* key: "topology.kubernetes.io/zone"`
operator: In
values: ["us-west-2a"]
```
**Cluster Autoscaler (CA)**
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-ca-cluster
region: us-east-1
version: "1.21"
availabilityZones:
* us-east-1a
managedNodeGroups:
* name: managed-nodes
labels:
role: managed-nodes
instanceType: t3.medium
minSize: 1
maxSize: 10
desiredCapacity: 1
...
```
**Utilisation de l'attribution des pods et de l'affinité des nœuds**
Sinon, si vous avez plusieurs nœuds de travail exécutés en plusieurs AZs, chaque nœud portera l'étiquette *[topology.kubernetes.io/zone](http://topology.kubernetes.io/zone%E2%80%9D)* avec la valeur de son AZ (par exemple us-west-2a ou us-west-2b). Vous pouvez utiliser `nodeSelector` ou `nodeAffinity` planifier des pods pour les nœuds dans une seule zone de disponibilité. Par exemple, le fichier manifeste suivant planifiera le Pod dans un nœud exécuté dans AZ us-west-2a.
```
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
nodeSelector:
topology.kubernetes.io/zone: us-west-2a
containers:
* name: nginx
image: nginx
imagePullPolicy: IfNotPresent
```
### Restreindre le trafic vers un nœud
Dans certains cas, il ne suffit pas de restreindre le trafic au niveau d'une zone. Outre la réduction des coûts, vous devrez peut-être également réduire la latence du réseau entre certaines applications qui communiquent fréquemment entre elles. Afin d'optimiser les performances du réseau et de réduire les coûts, vous devez trouver un moyen de limiter le trafic vers un nœud spécifique. Par exemple, le microservice A doit toujours communiquer avec le microservice B sur le nœud 1, même dans les configurations à haute disponibilité (HA). Le fait que le microservice A sur le nœud 1 communique avec le microservice B sur le nœud 2 peut avoir un impact négatif sur les performances souhaitées pour les applications de cette nature, en particulier si le nœud 2 se trouve dans une zone de disponibilité complètement distincte.
**Utilisation de la politique de trafic interne du service**
Afin de limiter le trafic réseau du Pod à un nœud, vous pouvez utiliser la *[politique de trafic interne du service](https://kubernetes.io/docs/concepts/services-networking/service-traffic-policy/)*. Par défaut, le trafic envoyé au service d'une charge de travail sera distribué de manière aléatoire entre les différents points de terminaison générés. Ainsi, dans une architecture HA, cela signifie que le trafic provenant du microservice A peut être dirigé vers n'importe quelle réplique du microservice B sur un nœud donné à travers les différents nœuds. AZs Toutefois, lorsque la politique de trafic interne du service est définie sur`Local`, le trafic sera limité aux points de terminaison situés sur le nœud d'où provient le trafic. Cette politique impose l'utilisation exclusive de points de terminaison locaux aux nœuds. Par conséquent, les coûts liés au trafic réseau pour cette charge de travail seront inférieurs à ceux d'une distribution à l'échelle du cluster. De plus, la latence sera plus faible, ce qui rendra votre application plus performante.
**Note**
Il est important de noter que cette fonctionnalité ne peut pas être combinée avec le routage tenant compte de la topologie dans Kubernetes.
![\[Trafic interne local\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/local_traffic.png)
Vous trouverez ci-dessous un extrait de code expliquant comment définir la *politique de trafic interne* pour un service.
```
apiVersion: v1
kind: Service
metadata:
name: orders-service
namespace: ecommerce
spec:
selector:
app: orders
type: ClusterIP
ports:
* protocol: TCP
port: 3003
targetPort: 3003
internalTrafficPolicy: Local
```
Pour éviter que votre application ne se comporte de manière inattendue en raison d'une baisse de trafic, vous devez envisager les approches suivantes :
+ Exécutez suffisamment de répliques pour chacun des pods communicants
+ Disposez d'une répartition relativement uniforme des pods en utilisant les contraintes de [propagation topologique](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)
+ Utiliser les [règles d'affinité des pods](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) pour la colocalisation des pods communicants
Dans cet exemple, vous avez 2 répliques du microservice A et 3 répliques du microservice B. Si les répliques du microservice A sont réparties entre les nœuds 1 et 2 et que le microservice B possède ses 3 répliques sur le nœud 3, il ne sera pas en mesure de communiquer en raison de la politique de trafic interne. `Local` Lorsqu'aucun point de terminaison local n'est disponible, le trafic est supprimé.
![\[node-local_no_peer\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/no_node_local_1.png)
Si le microservice B possède 2 de ses 3 répliques sur les nœuds 1 et 2, il y aura une communication entre les applications homologues. Mais vous auriez toujours une réplique isolée de Microservice B sans aucune réplique homologue avec laquelle communiquer.
![\[node-local_with_peer\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/no_node_local_2.png)
**Note**
Dans certains scénarios, une réplique isolée telle que celle illustrée dans le schéma ci-dessus peut ne pas être préoccupante si elle répond toujours à un objectif (par exemple, répondre aux demandes provenant du trafic entrant externe).
**Utilisation de la politique de trafic interne du service avec des contraintes de dispersion topologique**
L'utilisation de la *politique de trafic interne* associée aux *contraintes de dispersion topologique* peut être utile pour garantir que vous disposez du nombre approprié de répliques pour communiquer des microservices sur différents nœuds.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: express-test
spec:
replicas: 6
selector:
matchLabels:
app: express-test
template:
metadata:
labels:
app: express-test
tier: backend
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: express-test
```
**Utilisation de la politique de trafic interne du service avec les règles d'affinité des pods**
Une autre approche consiste à utiliser les règles d'affinité des pods lors de l'utilisation de la politique de trafic interne du service. Grâce à l'affinité des pods, vous pouvez influencer le planificateur pour qu'il colocalise certains pods en raison de leurs communications fréquentes. En appliquant des contraintes de planification strictes (`requiredDuringSchedulingIgnoredDuringExecution`) à certains pods, vous obtiendrez de meilleurs résultats en matière de colocation de pods lorsque le planificateur place des pods sur des nœuds.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: graphql
namespace: ecommerce
labels:
app.kubernetes.io/version: "0.1.6"
...
spec:
serviceAccountName: graphql-service-account
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- orders
topologyKey: "kubernetes.io/hostname"
```
## Communication entre le Load Balancer et le Pod
Les charges de travail EKS sont généralement dirigées par un équilibreur de charge qui distribue le trafic aux pods concernés de votre cluster EKS. Votre architecture peut comprendre des équilibreurs de charge internes orientés vers l' and/or extérieur. En fonction de votre architecture et de la configuration du trafic réseau, la communication entre les équilibreurs de charge et les pods peut contribuer de manière significative aux frais de transfert de données.
Vous pouvez utiliser le [AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller) pour gérer automatiquement la création de ressources ELB (ALB et NLB). Les frais de transfert de données que vous devrez payer dans le cadre de telles configurations dépendront du chemin emprunté par le trafic réseau. Le contrôleur AWS Load Balancer prend en charge deux modes de trafic réseau, le *mode instance et le mode* *IP*.
Lorsque vous utilisez *le mode instance*, un nœud NodePort sera ouvert sur chaque nœud de votre cluster EKS. L'équilibreur de charge transfère ensuite le trafic de manière uniforme sur les nœuds. Si le Pod de destination est exécuté sur un nœud, aucun frais de transfert de données ne sera encouru. Toutefois, si le pod de destination se trouve sur un nœud distinct et dans une zone de zone différente de celle NodePort où le trafic est reçu, il y aura un saut réseau supplémentaire entre le kube-proxy et le pod de destination. Dans un tel scénario, des frais de transfert de données inter-AZ seront facturés. En raison de la répartition uniforme du trafic entre les nœuds, il est fort probable que des frais de transfert de données supplémentaires soient associés aux sauts de trafic réseau entre zones des kube-proxies vers les pods de destination concernés.
Le schéma ci-dessous représente un chemin réseau pour le trafic circulant de l'équilibreur de charge vers le Pod de destination NodePort, puis depuis celui-ci `kube-proxy` vers le Pod de destination sur un nœud distinct dans une autre zone de disponibilité. Il s'agit d'un exemple du paramètre du *mode instance*.
![\[LB vers Pod\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/lb_2_pod.png)
Lorsque le *mode IP* est utilisé, le trafic réseau est transmis par proxy depuis l'équilibreur de charge directement vers le Pod de destination. Par conséquent, cette approche n'entraîne *aucun frais de transfert de données*.
**Note**
Il est recommandé de configurer votre équilibreur de charge en *mode trafic IP* afin de réduire les frais de transfert de données. Pour cette configuration, il est également important de vous assurer que votre équilibreur de charge est déployé sur tous les sous-réseaux de votre VPC.
Le schéma ci-dessous décrit les chemins réseau pour le trafic circulant entre l'équilibreur de charge et les Pods en *mode IP* du réseau.
![\[Mode IP\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/ip_mode.png)
## Transfert de données depuis le registre des conteneurs
### Amazon ECR
Le transfert de données vers le registre privé Amazon ECR est gratuit. Le *transfert de données à l'intérieur de la région est gratuit*, mais le transfert de données vers Internet et entre les régions sera facturé aux tarifs de transfert de données Internet des deux côtés du transfert.
Vous devez utiliser la [fonction de réplication d'image ECRs ](https://docs.aws.amazon.com/AmazonECR/latest/userguide/replication.html) intégrée pour répliquer les images de conteneur pertinentes dans la même région que vos charges de travail. De cette façon, la réplication serait facturée une seule fois, et toutes les extractions d'images de la même région (intra-région) seraient gratuites.
Vous pouvez réduire davantage les coûts de transfert de données associés à l'extraction d'images depuis l'ECR (transfert de données sortant) *en utilisant les points de terminaison [VPC d'interface](https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/what-are-vpc-endpoints.html) pour vous connecter aux référentiels ECR de la région*. L'approche alternative consistant à se connecter au point de terminaison AWS public d'ECR (via une passerelle NAT et une passerelle Internet) entraînera des coûts de traitement et de transfert de données plus élevés. La section suivante abordera plus en détail la réduction des coûts de transfert de données entre vos charges de travail et les services AWS.
Si vous exécutez des charges de travail avec des images particulièrement volumineuses, vous pouvez créer vos propres Amazon Machine Images (AMIs) personnalisées à partir d'images de conteneur prémises en cache. Cela peut réduire le temps d'extraction initial de l'image et les coûts potentiels de transfert de données d'un registre de conteneurs vers les nœuds de travail EKS.
## Transfert de données vers Internet et les services AWS
Il est courant d'intégrer les charges de travail Kubernetes à d'autres services AWS ou à des outils et plateformes tiers via Internet. L'infrastructure réseau sous-jacente utilisée pour acheminer le trafic vers et depuis la destination concernée peut avoir un impact sur les coûts engagés dans le processus de transfert de données.
### Utilisation de passerelles NAT
Les passerelles NAT sont des composants réseau qui effectuent la traduction d'adresses réseau (NAT). Le schéma ci-dessous décrit les pods d'un cluster EKS communiquant avec d'autres services AWS (Amazon ECR, DynamoDB et S3) et des plateformes tierces. Dans cet exemple, les Pods s'exécutent séparément AZs dans des sous-réseaux privés. Pour envoyer et recevoir du trafic depuis Internet, une passerelle NAT est déployée sur le sous-réseau public d'une AZ, permettant à toutes les ressources possédant des adresses IP privées de partager une seule adresse IP publique pour accéder à Internet. Cette passerelle NAT communique à son tour avec le composant Internet Gateway, permettant aux paquets d'être envoyés à leur destination finale.
![\[Passerelle NAT\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/nat_gw.png)
Lorsque vous utilisez des passerelles NAT pour de tels cas d'utilisation, *vous pouvez minimiser les coûts de transfert de données en déployant une passerelle NAT dans chaque zone de disponibilité.* De cette façon, le trafic acheminé vers Internet passera par la passerelle NAT dans la même zone de zone, évitant ainsi le transfert de données entre zones de zone de zone. Cependant, même si vous économiserez sur le coût du transfert de données inter-AZ, cette configuration implique le coût d'une passerelle NAT supplémentaire dans votre architecture.
Cette approche recommandée est illustrée dans le schéma ci-dessous.
![\[Approche recommandée\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/recommended_approach.png)
### Utilisation de points de terminaison de VPC
Pour réduire davantage les coûts dans de telles architectures, *vous devez utiliser des [points de terminaison VPC](https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/what-are-vpc-endpoints.html) pour établir la connectivité entre vos charges de travail et* les services AWS. Les points de terminaison VPC vous permettent d'accéder aux services AWS depuis un VPC sans data/network que les paquets ne transitent par Internet. Tout le trafic est interne et reste au sein du réseau AWS. Il existe deux types de points de terminaison VPC : les points de terminaison VPC d'interface (pris en charge [par de nombreux services AWS)](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html) et les points de terminaison VPC Gateway (uniquement pris en charge par S3 et DynamoDB).
**Points de terminaison VPC Gateway**
*Aucun coût horaire ou de transfert de données n'est associé aux points de terminaison VPC Gateway*. Lorsque vous utilisez des points de terminaison VPC Gateway, il est important de noter qu'ils ne sont pas extensibles au-delà des limites des VPC. Ils ne peuvent pas être utilisés dans le peering VPC, les réseaux VPN ou via Direct Connect.
**Points de terminaison VPC d'interface**
Les points de terminaison VPC sont [facturés à l'heure](https://aws.amazon.com/privatelink/pricing/) et sont soumis à des frais supplémentaires associés au traitement des données via l'ENI sous-jacent. Notez que le transfert de données inter-AZ [n'est pas facturé](https://aws.amazon.com/about-aws/whats-new/2022/04/aws-data-transfer-price-reduction-privatelink-transit-gateway-client-vpn-services/).
Le schéma ci-dessous montre les pods communiquant avec les services AWS via des points de terminaison VPC.
![\[Points de terminaison d’un VPC\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/vpc_endpoints.png)
## Transfert de données entre VPCs
Dans certains cas, vous pouvez avoir des charges de travail dans des VPC distincts (au sein de la même région AWS) qui doivent communiquer entre eux. Cela peut être accompli en autorisant le trafic à traverser l'Internet public via des passerelles Internet connectées aux VPC respectifs. Une telle communication peut être activée en déployant des composants d'infrastructure tels que des instances EC2, des passerelles NAT ou des instances NAT dans des sous-réseaux publics. Cependant, une configuration incluant ces composants entraînera des frais pour les processing/transferring données entrantes et sortantes du VPCs. Si le trafic à destination et en provenance de la ligne séparée VPCs se déplace AZs, le transfert de données sera soumis à des frais supplémentaires. Le schéma ci-dessous décrit une configuration qui utilise des passerelles NAT et des passerelles Internet pour établir une communication entre des charges de travail de différents types. VPCs
![\[Entre VPCs\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/between_vpcs.png)
### Connexions d'appairage de VPC
Pour réduire les coûts liés à de tels cas d'utilisation, vous pouvez utiliser le [peering VPC.](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) Avec une connexion d'appairage VPC, aucun frais de transfert de données n'est facturé pour le trafic réseau qui reste dans la même zone de distribution. Si le trafic se croise AZs, des frais seront encourus. Néanmoins, l'approche de peering VPC est recommandée pour une communication rentable entre des charges de travail distinctes au sein d'une même VPCs région AWS. Cependant, il est important de noter que le peering VPC est principalement efficace pour la connectivité VPC 1:1, car il ne permet pas la mise en réseau transitive.
Le schéma ci-dessous est une représentation de haut niveau de la communication des charges de travail via une connexion d'appairage VPC.
![\[Appairage\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/peering.png)
### Connexions réseau transitives
Comme indiqué dans la section précédente, les connexions d'appairage VPC ne permettent pas la connectivité réseau transitive. Si vous souhaitez en connecter 3 ou plus VPCs avec des exigences de réseau transitives, vous devez utiliser un [Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) (TGW). Cela vous permettra de surmonter les limites de l'appairage VPC ou de surmonter toute surcharge opérationnelle associée à la présence de plusieurs connexions d'appairage VPC entre plusieurs. VPCs Vous êtes [facturé sur une base horaire](https://aws.amazon.com/transit-gateway/pricing/) et pour les données envoyées au TGW. *Aucun coût de destination n'est associé au trafic inter-AZ qui passe par le TGW.*
Le schéma ci-dessous montre le trafic inter-AZ passant par un TGW entre des charges de travail situées dans des régions AWS différentes VPCs mais au sein de la même région AWS.
![\[Transitif\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/transititive.png)
## Utilisation d'un Service Mesh
Les maillages de service offrent de puissantes fonctionnalités réseau qui peuvent être utilisées pour réduire les coûts liés au réseau dans vos environnements de clusters EKS. Cependant, vous devez examiner attentivement les tâches opérationnelles et la complexité qu'un maillage de services introduira dans votre environnement si vous en adoptez un.
### Limiter le trafic aux zones de disponibilité
**Utilisation de la distribution pondérée par localité d'Istio**
Istio vous permet d'appliquer des politiques réseau au trafic *après* le routage. Cela se fait à l'aide de [règles de destination](https://istio.io/latest/docs/reference/config/networking/destination-rule/) telles que la [distribution pondérée par localité](https://istio.io/latest/docs/tasks/traffic-management/locality-load-balancing/distribute/). Grâce à cette fonctionnalité, vous pouvez contrôler le poids (exprimé en pourcentage) du trafic pouvant atteindre une certaine destination en fonction de son origine. La source de ce trafic peut provenir d'un équilibreur de charge externe (ou public) ou d'un Pod au sein du cluster lui-même. Lorsque tous les points de terminaison du Pod seront disponibles, la localité sera sélectionnée sur la base d'un algorithme d'équilibrage de charge pondéré. Si certains points de terminaison ne fonctionnent pas correctement ou ne sont pas disponibles, [le poids de la localité sera automatiquement ajusté](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/locality_weight.html) pour refléter cette modification des points de terminaison disponibles.
**Note**
Avant d'implémenter la distribution pondérée par localité, vous devez commencer par comprendre les modèles de trafic de votre réseau et les implications que la politique des règles de destination peut avoir sur le comportement de votre application. Il est donc important de mettre en place des mécanismes de suivi distribués avec des outils tels qu'[AWS X-Ray](https://aws.amazon.com/xray/) ou [Jaeger](https://www.jaegertracing.io/).
Les règles de destination Istio détaillées ci-dessus peuvent également être appliquées pour gérer le trafic entre un équilibreur de charge et les pods de votre cluster EKS. Les règles de distribution pondérées par localité peuvent être appliquées à un service qui reçoit du trafic provenant d'un équilibreur de charge à haute disponibilité (en particulier la passerelle d'entrée). Ces règles vous permettent de contrôler la quantité de trafic à destination en fonction de son origine zonale, c'est-à-dire l'équilibreur de charge dans ce cas. S'il est configuré correctement, le trafic de sortie entre zones sera réduit par rapport à un équilibreur de charge qui répartit le trafic de manière uniforme ou aléatoire entre les répliques de Pod de différentes manières. AZs
Vous trouverez ci-dessous un exemple de bloc de code d'une ressource Destination Rule dans Istio. Comme on peut le voir ci-dessous, cette ressource spécifie des configurations pondérées pour le trafic entrant provenant de 3 pays différents AZs de la `eu-west-1` région. Ces configurations indiquent que la majorité du trafic entrant (70 % dans ce cas) en provenance d'une AZ donnée doit être transmise par proxy à une destination située dans la même AZ d'où il provient.
```
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: express-test-dr
spec:
host: express-test.default.svc.cluster.local
trafficPolicy:
loadBalancer: +
localityLbSetting:
distribute:
- from: eu-west-1/eu-west-1a/ +
to:
"eu-west-1/eu-west-1a/_": 70
"eu-west-1/eu-west-1b/_": 20
"eu-west-1/eu-west-1c/_": 10
- from: eu-west-1/eu-west-1b/_ +
to:
"eu-west-1/eu-west-1a/_": 20
"eu-west-1/eu-west-1b/_": 70
"eu-west-1/eu-west-1c/_": 10
- from: eu-west-1/eu-west-1c/_ +
to:
"eu-west-1/eu-west-1a/_": 20
"eu-west-1/eu-west-1b/_": 10
"eu-west-1/eu-west-1c/*": 70**
connectionPool:
http:
http2MaxRequests: 10
maxRequestsPerConnection: 10
outlierDetection:
consecutiveGatewayErrors: 1
interval: 1m
baseEjectionTime: 30s
```
**Note**
Le poids minimum pouvant être distribué à la destination est de 1 %. La raison en est de conserver les régions et zones de basculement au cas où les terminaux de la destination principale deviendraient défectueux ou indisponibles.
Le schéma ci-dessous décrit un scénario dans lequel il existe un équilibreur de charge hautement disponible dans la région *eu-west-1* et une distribution pondérée par localité est appliquée. La politique de règle de destination de ce diagramme est configurée pour envoyer 60 % du trafic en provenance d'*eu-west-1a* vers des pods situés dans la même zone, tandis que 40 % du trafic en provenance d'*eu-west-1a doit être dirigé vers des pods situés dans eu-west-1b*.
![\[J'arrête le contrôle du trafic\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/istio-traffic-control.png)
### Limiter le trafic aux zones de disponibilité et aux nœuds
**Utilisation de la politique de trafic interne du service avec Istio**
*Pour atténuer les coûts réseau associés au trafic entrant *externe* et au trafic *interne* entre les pods, vous pouvez combiner les règles de destination d'Istio et la politique de trafic interne du service Kubernetes.* La manière de combiner les règles de destination d'Istio avec la politique de trafic interne du service dépendra largement de 3 éléments :
+ Le rôle des microservices
+ Schémas du trafic réseau sur les microservices
+ Comment les microservices doivent être déployés dans la topologie du cluster Kubernetes
Le schéma ci-dessous montre à quoi ressemblerait le flux réseau dans le cas d'une demande imbriquée et comment les politiques susmentionnées contrôleraient le trafic.
![\[Politique de trafic externe et interne\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/external-and-internal-traffic-policy.png)
1. L'utilisateur final fait une demande à **APP A,** qui à son tour envoie une demande imbriquée à **APP C.** Cette demande est d'abord envoyée à un équilibreur de charge hautement disponible, qui possède des instances dans AZ 1 et AZ 2, comme le montre le schéma ci-dessus.
1. La demande entrante externe est ensuite acheminée vers la bonne destination par le service virtuel Istio.
1. Une fois la demande acheminée, la règle de destination Istio contrôle le volume de trafic destiné à la demande en AZs fonction de son origine (AZ 1 ou AZ 2).
1. Le trafic est ensuite dirigé vers le service pour **l'APP A**, puis est transmis par proxy aux points de terminaison du Pod respectifs. Comme le montre le schéma, 80 % du trafic entrant est envoyé aux points de terminaison Pod dans l'AZ 1, et 20 % du trafic entrant est envoyé à l'AZ 2.
1. **APP A** envoie ensuite une demande interne à **APP C.** Le service **APP C** dispose d'une politique de trafic interne activée (`internalTrafficPolicy``: Local`).
1. La demande interne de **l'APP A** (sur le **NŒUD 1**) à **l'APP C** est réussie en raison du point de terminaison local disponible pour **l'APP** C.
1. **La demande interne de **l'APP A** (sur le **NŒUD 3) à** **l'APP C** échoue car aucun *point de terminaison local au nœud* n'est disponible pour l'APP C.** Comme le montre le schéma, APP C n'a pas de répliques sur NODE 3. **\$1** \$1
Les captures d'écran ci-dessous ont été capturées à partir d'un exemple réel de cette approche. La première série de captures d'écran montre une demande externe réussie adressée à un `graphql` et une demande imbriquée envoyée avec succès `graphql` à une `orders` réplique colocalisée sur le nœud. `ip-10-0-0-151.af-south-1.compute.internal`
![\[Avant\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/before.png)
![\[Avant les résultats\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/before-results.png)
Avec Istio, vous pouvez vérifier et exporter les statistiques de tous les [clusters et points de terminaison en amont](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/intro/terminology) connus de vos proxys. Cela peut permettre de se faire une idée du flux réseau ainsi que de la part de distribution entre les services d'une charge de travail. En reprenant le même exemple, les `orders` points de terminaison connus du `graphql` proxy peuvent être obtenus à l'aide de la commande suivante :
```
kubectl exec -it deploy/graphql -n ecommerce -c istio-proxy -- curl localhost:15000/clusters | grep orders
```
```
...
orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**rq_error::0**
orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**rq_success::119**
orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**rq_timeout::0**
orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**rq_total::119**
orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**health_flags::healthy**
orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**region::af-south-1**
orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**zone::af-south-1b**
...
```
Dans ce cas, le `graphql` proxy ne connaît que le `orders` point de terminaison de la réplique avec laquelle il partage un nœud. Si vous supprimez le `internalTrafficPolicy: Local` paramètre du service des commandes et que vous réexécutez une commande comme celle ci-dessus, les résultats renverront tous les points de terminaison des répliques répartis sur les différents nœuds. De plus, en examinant `rq_total` les points de terminaison respectifs, vous remarquerez une part relativement uniforme de la distribution sur le réseau. Par conséquent, si les points de terminaison sont associés à des services en amont exécutés dans des AZs environnements différents, cette distribution du réseau entre les zones entraînera des coûts plus élevés.
Comme indiqué dans une section précédente ci-dessus, vous pouvez co-localiser des pods qui communiquent fréquemment en utilisant l'affinité des pods.
```
...
spec:
...
template:
metadata:
labels:
app: graphql
role: api
workload: ecommerce
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- orders
topologyKey: "kubernetes.io/hostname"
nodeSelector:
managedBy: karpenter
billing-team: ecommerce
...
```
Lorsque les `orders` répliques `graphql` et ne coexistent pas sur le même nœud (`ip-10-0-0-151.af-south-1.compute.internal`), la première demande `graphql` est réussie, comme indiqué `200 response code` dans la capture d'écran de Postman ci-dessous, tandis que la deuxième demande imbriquée de `graphql` à `orders` échoue avec un. `503 response code`
![\[After\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/after.png) ![\[After results\]](http://docs.aws.amazon.com/fr_fr/eks/latest/best-practices/images/after-results.png)
## Ressources supplémentaires
+ [Gestion de la latence et des coûts de transfert de données sur EKS à l'aide d'Istio](https://aws.amazon.com/blogs/containers/addressing-latency-and-data-transfer-costs-on-eks-using-istio/)
+ [Exploration de l'effet des indices tenant compte de la topologie sur le trafic réseau dans Amazon Elastic Kubernetes Service](https://aws.amazon.com/blogs/containers/exploring-the-effect-of-topology-aware-hints-on-network-traffic-in-amazon-elastic-kubernetes-service/)
+ [Obtenir de la visibilité sur les octets réseau de votre Amazon EKS Cross-AZ d'un point à l'autre](https://aws.amazon.com/blogs/containers/getting-visibility-into-your-amazon-eks-cross-az-pod-to-pod-network-bytes/)
+ [Optimisez le trafic AZ avec Istio](https://youtu.be/EkpdKVm9kQY)
+ [Optimisez le trafic AZ avec un routage adapté à la topologie](https://youtu.be/KFgE_lNVfz4)
+ [Optimisez les coûts et les performances de Kubernetes grâce à la politique de trafic interne des services](https://youtu.be/-uiF_zixEro)
+ [Optimisez les coûts et les performances de Kubernetes grâce à la politique de trafic interne d'Istio and Service](https://youtu.be/edSgEe7Rihc)
+ [Présentation des coûts de transfert des données pour les architectures courantes](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [Comprendre les coûts de transfert de données pour les services de conteneurs AWS](https://aws.amazon.com/blogs/containers/understanding-data-transfer-costs-for-aws-container-services/)
# Stockage
## Présentation
Il existe des scénarios dans lesquels vous souhaiterez peut-être exécuter des applications qui doivent préserver les données à court ou à long terme. Pour de tels cas d'utilisation, les volumes peuvent être définis et montés par des Pods afin que leurs conteneurs puissent accéder à différents mécanismes de stockage. Kubernetes prend en charge différents types de [volumes](https://kubernetes.io/docs/concepts/storage/volumes/) pour le stockage éphémère et persistant. Le choix du stockage dépend largement des exigences de l'application. Chaque approche a des implications financières, et les pratiques décrites ci-dessous vous aideront à optimiser les coûts pour les charges de travail nécessitant une certaine forme de stockage dans vos environnements EKS.
## Volumes éphémères
Les volumes éphémères sont destinés aux applications qui nécessitent des volumes locaux transitoires mais qui n'ont pas besoin que les données soient conservées après les redémarrages. Cela inclut les exigences relatives à l'espace de travail, à la mise en cache et aux données d'entrée en lecture seule, telles que les données de configuration et les secrets. [Vous trouverez plus de détails sur les volumes éphémères de Kubernetes ici.](https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/) La plupart des volumes éphémères (par exemple EmptyDir, ConfigMap, DownwardAPI, secret, hostpath) sont sauvegardés par des périphériques inscriptibles connectés localement (généralement le disque racine) ou par de la RAM. Il est donc important de choisir le volume hôte le plus rentable et le plus performant.
### Utilisation des volumes EBS
*Nous vous recommandons de commencer par [gp3](https://aws.amazon.com/ebs/general-purpose/) comme volume racine de l'hôte.* Il s'agit du dernier volume SSD à usage général proposé par Amazon EBS et propose également un prix inférieur (jusqu'à 20 %) par Go par rapport aux volumes gp2.
### Utilisation d'Amazon EC2 Instance Stores
[Les magasins d' EC2 instances Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) fournissent un stockage temporaire au niveau des blocs pour vos EC2 instances. Le stockage fourni par les magasins d' EC2 instance est accessible via des disques physiquement connectés aux hôtes. Contrairement à Amazon EBS, vous ne pouvez attacher des volumes de stockage d'instance que lorsque l'instance est lancée, et ces volumes n'existent que pendant la durée de vie de l'instance. Ils ne peuvent pas être détachés et rattachés à d'autres instances. Pour en savoir plus sur les magasins d' EC2 instances Amazon, [cliquez ici](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html). *Aucun frais supplémentaire n'est associé à un volume de stockage d'instance.* Cela les rend (volumes de stockage d'instance) *plus rentables* que les EC2 instances générales comportant de grands volumes EBS.
Pour utiliser des volumes de stockage locaux dans Kubernetes, vous devez partitionner, configurer et formater les disques à [l'aide des EC2 données utilisateur d'Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-add-user-data.html) afin que les volumes puissent être montés selon les spécifications du pod [HostPath](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath). Vous pouvez également tirer parti du [Local Persistent Volume Static Provisioner](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner) pour simplifier la gestion du stockage local. Le fournisseur statique de volumes persistants locaux vous permet d'accéder aux volumes de stockage d'instance locaux via l'interface Kubernetes PersistentVolumeClaim (PVC) standard. En outre, il fournira PersistentVolumes (PVs) qui contient des informations sur l'affinité des nœuds pour planifier les pods sur les bons nœuds. Bien qu'il utilise Kubernetes PersistentVolumes, les volumes de stockage d' EC2 instance sont de nature éphémère. Les données écrites sur des disques éphémères ne sont disponibles que pendant la durée de vie de l'instance. Lorsque l'instance est interrompue, les données le sont également. Veuillez consulter ce [blog](https://aws.amazon.com/blogs/containers/eks-persistent-volumes-for-instance-store/) pour plus de détails.
N'oubliez pas que lorsque vous utilisez des volumes de stockage d' EC2 instance Amazon, la limite totale d'IOPS est partagée avec l'hôte et elle lie les pods à un hôte spécifique. Vous devez examiner attentivement vos exigences en matière de charge de travail avant d'adopter les volumes de stockage d' EC2 instance Amazon.
## Volumes persistants
Kubernetes est généralement associé à l'exécution d'applications apatrides. Cependant, il existe des scénarios dans lesquels vous souhaiterez peut-être exécuter des microservices qui doivent préserver des données ou des informations persistantes d'une demande à l'autre. Les bases de données sont un exemple courant de tels cas d'utilisation. Cependant, les capsules et les contenants ou processus qu'elles contiennent sont de nature éphémère. Pour conserver les données au-delà de la durée de vie d'un pod, vous pouvez PVs définir l'accès au stockage à un emplacement spécifique indépendant du pod. *Les coûts associés dépendent PVs fortement du type de stockage utilisé et de la manière dont les applications l'utilisent.*
[Différents types d'options de stockage compatibles avec Kubernetes sur PVs Amazon EKS sont répertoriés ici.](https://docs.aws.amazon.com/eks/latest/userguide/storage.html) Les options de stockage décrites ci-dessous sont Amazon EBS, Amazon EFS, Amazon FSx for Lustre et Amazon FSx for NetApp ONTAP.
### Volumes Amazon Elastic Block Store (EBS)
Les volumes Amazon EBS peuvent être utilisés sous forme de Kubernetes PVs pour fournir des volumes de stockage au niveau des blocs. Ils conviennent parfaitement aux bases de données qui reposent sur des lectures et écritures aléatoires et aux applications gourmandes en débit qui effectuent des lectures et des écritures longues et continues. [Le pilote Amazon Elastic Block Store Container Storage Interface (CSI)](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) permet aux clusters Amazon EKS de gérer le cycle de vie des volumes Amazon EBS pour les volumes persistants. L'interface de stockage de conteneurs permet et facilite l'interaction entre Kubernetes et un système de stockage. Lorsqu'un pilote CSI est déployé sur votre cluster EKS, vous pouvez accéder à ses fonctionnalités via les ressources de stockage natives de Kubernetes, telles que les volumes persistants (PVs), les réclamations de volumes persistants () et les classes de stockage (PVCs). SCs Ce [lien](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes) fournit des exemples pratiques d'interaction avec les volumes Amazon EBS à l'aide du pilote Amazon EBS CSI.
#### Choisir le bon volume
*Nous vous recommandons d'utiliser la dernière génération de stockage par blocs (gp3) car elle offre un juste équilibre entre prix et performances*. Il vous permet également d'adapter les IOPS et le débit du volume indépendamment de la taille du volume sans avoir à fournir de capacité de stockage par blocs supplémentaire. Si vous utilisez actuellement des volumes gp2, nous vous recommandons vivement de migrer vers des volumes gp3. Le billet de blog [Migration de clusters Amazon EKS de volumes EBS gp2 vers gp3](https://aws.amazon.com/blogs/containers/migrating-amazon-eks-clusters-from-gp2-to-gp3-ebs-volumes/) explique comment migrer de gp2 à *gp3 *sur** des clusters Amazon EKS avec sauvegarde et restauration à l'aide de la fonctionnalité CSI [Volume Snapshots](https://kubernetes.io/docs/concepts/storage/volume-snapshots/), qui nécessite une interruption des applications.
Amazon EBS permet de modifier les caractéristiques du volume, telles que la taille du volume, les IOPS et le débit en ligne. [https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/](https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/)
Lorsque vous avez des applications qui nécessitent des performances supérieures et des volumes supérieurs à ce que [peut supporter un seul volume gp3](https://aws.amazon.com/ebs/general-purpose/), vous devriez envisager d'utiliser [io2 block express.](https://aws.amazon.com/ebs/provisioned-iops/) Ce type de stockage est idéal pour votre déploiement le plus important, le plus I/O intensif et le plus critique, tel que SAP HANA ou d'autres grandes bases de données nécessitant une faible latence. N'oubliez pas que les performances EBS d'une instance sont limitées par les limites de performances de l'instance, de sorte que toutes les instances ne prennent pas en charge les volumes io2 block express. Vous pouvez consulter les types d'instances pris en charge et d'autres considérations dans ce [document](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/provisioned-iops.html).
*Un seul volume gp3 peut prendre en charge jusqu'à 16 000 IOPS maximum, 1 000 débits maximum, 16 MiB/s TiB maximum. La dernière génération de volume SSD IOPS provisionné qui fournit jusqu'à 256 000 IOPS, 4 000 Mbits/s, un débit et 64 TiB.*
Parmi ces options, vous devez adapter au mieux les performances et le coût de votre stockage aux besoins de vos applications.
#### Surveillez et optimisez au fil du temps
Il est important de comprendre les performances de base de votre application et de les surveiller pour les volumes sélectionnés afin de vérifier si elles répondent à vos attentes requirements/expectations ou si elles sont surapprovisionnées (par exemple, un scénario dans lequel les IOPS allouées ne sont pas pleinement utilisées).
Au lieu d'allouer un volume important dès le début, vous pouvez augmenter progressivement la taille du volume au fur et à mesure que vous accumulez des données. Vous pouvez redimensionner les volumes de manière dynamique à l'aide de la fonctionnalité [de redimensionnement des volumes](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes/resizing) du pilote CSI Amazon Elastic Block Store (). aws-ebs-csi-driver *N'oubliez pas que vous pouvez uniquement augmenter la taille du volume EBS.*
Pour identifier et supprimer les volumes EBS en suspens, vous pouvez utiliser la catégorie d'[optimisation des coûts d'AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html). Cette fonctionnalité vous permet d'identifier les volumes non attachés ou ceux dont l'activité d'écriture est très faible pendant un certain temps. [Popeye](https://github.com/derailed/popeye), un outil open source natif du cloud et en lecture seule, analyse les clusters Kubernetes en direct et signale les problèmes potentiels liés aux ressources et aux configurations déployées. Par exemple, il peut rechercher les fichiers inutilisés PVs PVCs et vérifier s'ils sont liés ou s'il existe une erreur de montage du volume.
Pour en savoir plus sur la surveillance, veuillez consulter le [guide d'observabilité de l'optimisation des coûts d'EKS](https://docs.aws.amazon.com/eks/latest/best-practices/cost-opt-observability.html).
Une autre option que vous pouvez envisager est celle des recommandations relatives aux [volumes Amazon EBS d'AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-ebs-recommendations.html). Cet outil identifie automatiquement la configuration de volume optimale et le niveau de performance requis. Par exemple, il peut être utilisé pour des paramètres optimaux relatifs aux IOPS provisionnées, à la taille des volumes et aux types de volumes EBS en fonction de l'utilisation maximale des 14 derniers jours. Il quantifie également les économies mensuelles potentielles découlant de ses recommandations. Vous pouvez consulter ce [blog](https://aws.amazon.com/blogs/storage/cost-optimizing-amazon-ebs-volumes-using-aws-compute-optimizer/) pour plus de détails.
#### Politique de conservation des sauvegardes
Vous pouvez sauvegarder les données de vos volumes Amazon EBS en prenant des point-in-time instantanés. Le pilote Amazon EBS CSI prend en charge les instantanés de volume. Vous pouvez apprendre à créer un instantané et à restaurer un PV EBS en suivant les étapes décrites [ici](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/examples/kubernetes/snapshot/README.md).
Les instantanés suivants sont des sauvegardes incrémentielles, ce qui signifie que seuls les blocs de l'appareil qui ont changé après votre dernier instantané sont enregistrés. Cela réduit le temps nécessaire pour créer l’instantané, ainsi que les coûts de stockage en ne dupliquant pas les données. Cependant, l'augmentation du nombre d'anciens instantanés EBS sans politique de conservation appropriée peut entraîner des coûts imprévus lors d'une exploitation à grande échelle. Si vous sauvegardez directement des volumes Amazon EBS via l'API AWS, vous pouvez tirer parti d'[Amazon Data Lifecycle Manager](https://aws.amazon.com/ebs/data-lifecycle-manager/) (DLM) qui fournit une solution de gestion du cycle de vie automatisée et basée sur des règles pour les instantanés Amazon Elastic Block Store (EBS) et les Amazon Machine Images () soutenues par EBS. AMIs La console facilite l'automatisation de la création, de la conservation et de la suppression des instantanés EBS et. AMIs
**Note**
Il n'existe actuellement aucun moyen d'utiliser Amazon DLM via le pilote Amazon EBS CSI.
Dans un environnement Kubernetes, vous pouvez utiliser un outil open source appelé [Velero](https://velero.io/) pour sauvegarder vos volumes persistants EBS. Vous pouvez définir un indicateur TTL lors de la planification de la tâche pour faire expirer les sauvegardes. Voici un [guide](https://velero.io/docs/v1.12/how-velero-works/#set-a-backup-to-expire) de Velero à titre d'exemple.
### Amazon Elastic File System (EFS)
[Amazon Elastic File System (EFS)](https://aws.amazon.com/efs/) est un système de fichiers entièrement élastique sans serveur qui vous permet de partager des données de fichiers à l'aide d'une interface de système de fichiers et d'une sémantique de système de fichiers standard pour un large éventail de charges de travail et d'applications. Wordpress et Drupal, les outils de développement tels que JIRA et Git, les systèmes de bloc-notes partagés tels que Jupyter et les répertoires personnels sont des exemples de charges de travail et d'applications.
L'un des principaux avantages d'Amazon EFS est qu'il peut être monté par plusieurs conteneurs répartis sur plusieurs nœuds et plusieurs zones de disponibilité. Un autre avantage est que vous ne payez que pour le stockage que vous utilisez. Les systèmes de fichiers EFS s'agrandissent et se réduisent automatiquement au fur et à mesure que vous ajoutez et supprimez des fichiers, ce qui élimine le besoin de planification des capacités.
Pour utiliser Amazon EFS dans Kubernetes, vous devez utiliser le pilote Amazon Elastic File System Container Storage Interface (CSI),. [aws-efs-csi-driver](https://github.com/kubernetes-sigs/aws-efs-csi-driver) Actuellement, le conducteur peut créer des [points d'accès](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) de manière dynamique. Cependant, le système de fichiers Amazon EFS doit d'abord être provisionné et fourni en entrée dans le paramètre de classe de stockage Kubernetes.
#### Choisir la bonne classe de stockage EFS
Amazon EFS propose [quatre classes de stockage](https://docs.aws.amazon.com/efs/latest/ug/storage-classes.html).
Deux classes de stockage standard :
+ Norme Amazon EFS
+ [Accès standard et peu fréquent à Amazon EFS (EFS Standard-IA)](https://aws.amazon.com/blogs/aws/optimize-storage-cost-with-reduced-pricing-for-amazon-efs-infrequent-access/)
Deux classes de stockage à zone unique :
+ [Zone Amazon EFS One](https://aws.amazon.com/blogs/aws/new-lower-cost-one-zone-storage-classes-for-amazon-elastic-file-system/)
+ Accès peu fréquent à Amazon EFS One Zone (EFS One Zone-IA)
Les classes de stockage à accès peu fréquent (IA) sont optimisées en termes de coûts pour les fichiers auxquels on n'accède pas tous les jours. Grâce à la gestion du cycle de vie d'Amazon EFS, vous pouvez déplacer des fichiers auxquels vous n'avez pas accédé pendant la durée de la politique de cycle de vie (7, 14, 30, 60 ou 90 jours) vers les classes de stockage IA, *ce qui peut réduire les coûts de stockage jusqu'à 92 % par rapport aux classes de stockage EFS Standard et EFS One Zone respectivement*.
Avec EFS Intelligent-Tiering, la gestion du cycle de vie surveille les modèles d'accès de votre système de fichiers et déplace automatiquement les fichiers vers la classe de stockage la plus optimale.
**Note**
aws-efs-csi-driver n'a actuellement aucun contrôle sur la modification des classes de stockage, la gestion du cycle de vie ou la hiérarchisation intelligente. Ils doivent être configurés manuellement dans la console AWS ou via l'EFS APIs.
**Note**
aws-efs-csi-driver n'est pas compatible avec les images de conteneur basées sur Windows.
**Note**
Il existe un problème de mémoire connu lorsque *vol-metrics-opt-in*(pour émettre des métriques de volume) est activée en raison de la [DiskUsage](https://github.com/kubernetes/kubernetes/blob/ee265c92fec40cd69d1de010b477717e4c142492/pkg/volume/util/fs/fs.go#L66)fonction qui consomme une quantité de mémoire proportionnelle à la taille de votre système de fichiers. *Actuellement, nous recommandons de désactiver l'**option `-- vol-metrics-opt-in `sur les systèmes de fichiers volumineux pour éviter de consommer trop de mémoire. Voici un [lien vers](https://github.com/kubernetes-sigs/aws-efs-csi-driver/issues/1104) un problème sur GitHub pour plus de détails.*
### Amazon FSx pour Lustre
Lustre est un système de fichiers parallèle à hautes performances couramment utilisé dans les charges de travail nécessitant un débit de latence pouvant atteindre des centaines de millisecondes GB/s et inférieures à la milliseconde par opération. Il est utilisé pour des scénarios tels que la formation à l'apprentissage automatique, la modélisation financière, le HPC et le traitement vidéo. [Amazon FSx for Lustre](https://aws.amazon.com/fsx/lustre/) fournit un stockage partagé entièrement géré alliant évolutivité et performance, parfaitement intégré à Amazon S3.
Vous pouvez utiliser des volumes de stockage persistants Kubernetes soutenus par FSx for Lustre à l'aide du [pilote CSI FSx for Lustre d'Amazon EKS ou de](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) votre cluster Kubernetes autogéré sur AWS. Consultez la [documentation Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/fsx-csi.html) pour plus de détails et des exemples.
#### Lien vers Amazon S3
Il est recommandé de lier un référentiel de données à long terme hautement durable résidant sur Amazon S3 à votre système de fichiers FSx for Lustre. Une fois liés, les grands ensembles de données sont chargés latéralement selon les besoins depuis Amazon S3 vers les systèmes FSx de fichiers Lustre. Vous pouvez également réexécuter vos analyses et vos résultats dans S3, puis supprimer votre système de fichiers Lustre.
#### Choisir les bonnes options de déploiement et de stockage
FSx for Lustre propose différentes options de déploiement. La première option s'appelle *scratch* et ne réplique pas les données, tandis que la seconde option est appelée *persistante*, ce qui, comme son nom l'indique, conserve les données.
La première option (*scratch*) peut être utilisée *pour réduire le coût du traitement temporaire des données à court terme*. L'option de déploiement persistant *est conçue pour un stockage à long terme* qui réplique automatiquement les données au sein d'une zone de disponibilité AWS. Il prend également en charge le stockage SSD et HDD.
Vous pouvez configurer le type de déploiement souhaité dans les paramètres de StorageClass Kubernetes du système de fichiers FSx for lustre. Voici un [lien](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/tree/master/examples/kubernetes/dynamic_provisioning#edit-storageclass) qui fournit des exemples de modèles.
**Note**
Pour les charges de travail sensibles à la latence ou les charges de travail nécessitant les plus hauts niveaux d'IOP/débit, vous devez choisir le stockage SSD. Pour les charges de travail axées sur le débit qui ne sont pas sensibles à la latence, vous devez choisir le stockage sur disque dur.
#### Activer la compression des données
Vous pouvez également activer la compression des données sur votre système de fichiers en spécifiant « LZ4 » comme type de compression de données. Une fois activé, tous les fichiers nouvellement écrits seront automatiquement compressés FSx pour Lustre avant d'être écrits sur le disque et décompressés lors de leur lecture. LZ4 l'algorithme de compression de données est sans perte, de sorte que les données d'origine peuvent être entièrement reconstruites à partir des données compressées.
Vous pouvez configurer le type de compression des données comme indiqué dans LZ4 les paramètres du système de fichiers StorageClass Kubernetes FSx for Lustre. La compression est désactivée lorsque la valeur est définie sur NONE, qui est la valeur par défaut. Ce [lien](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/tree/master/examples/kubernetes/dynamic_provisioning#edit-storageclass) fournit des exemples de modèles.
**Note**
Amazon FSx for Lustre n'est pas compatible avec les images de conteneurs basées sur Windows.
### Amazon FSx pour NetApp ONTAP
[Amazon FSx for NetApp ONTAP](https://aws.amazon.com/fsx/netapp-ontap/) est un espace de stockage partagé entièrement géré basé sur le système NetApp de fichiers ONTAP. FSx for ONTAP fournit un stockage de fichiers partagé riche en fonctionnalités, rapide et flexible, largement accessible à partir d'instances de calcul Linux, Windows et macOS exécutées sur AWS ou sur site.
Amazon FSx for NetApp ONTAP prend en charge deux niveaux de stockage : *1 niveau principal et 2 niveaux* *de pool de capacité*.
Le *niveau principal est un niveau* basé sur des SSD hautes performances et provisionné pour les données actives sensibles à la latence. Le *niveau du pool de capacité* entièrement élastique est optimisé en termes de coûts pour les données rarement consultées, évolue automatiquement au fur et à mesure que les données sont hiérarchisées et offre une capacité pratiquement illimitée en pétaoctets. Vous pouvez activer la compression et la déduplication des données sur le stockage du pool de capacité et réduire davantage la capacité de stockage consommée par vos données. NetAppLa FabricPool fonctionnalité native basée sur des règles surveille en permanence les modèles d'accès aux données, transférant automatiquement les données de manière bidirectionnelle entre les niveaux de stockage afin d'optimiser les performances et les coûts.
NetAppAstra Trident fournit une orchestration dynamique du stockage à l'aide d'un pilote CSI qui permet aux clusters Amazon EKS de gérer le cycle de vie des volumes persistants soutenus PVs par Amazon FSx pour NetApp les systèmes de fichiers ONTAP. Pour commencer, consultez la section [Utiliser Astra Trident avec Amazon FSx pour NetApp ONTAP](https://docs.netapp.com/us-en/trident/trident-use/trident-fsx.html) dans la documentation d'Astra Trident.
## Autres considérations
### Minimiser la taille de l'image du conteneur
Une fois les conteneurs déployés, les images des conteneurs sont mises en cache sur l'hôte sous forme de couches multiples. En réduisant la taille des images, la quantité de stockage requise sur l'hôte peut être réduite.
En utilisant dès le départ des images de base allégées, telles que des images à gratter ou des images de conteneur [sans distribution](https://github.com/GoogleContainerTools/distroless) (qui contiennent uniquement votre application et ses dépendances d'exécution), *vous pouvez réduire les coûts de stockage en plus d'autres avantages connexes tels que la réduction de la surface d'attaque et des temps d'extraction des* images plus courts.
Vous devriez également envisager d'utiliser des outils open source, tels que [Slim.ai](https://www.slim.ai/docs/quickstart), qui fournit un moyen simple et sécurisé de créer des images minimales.
Plusieurs couches de packages, d'outils, de dépendances d'applications et de bibliothèques peuvent facilement augmenter la taille de l'image du conteneur. En utilisant des versions en plusieurs étapes, vous pouvez copier des artefacts de manière sélective d'une étape à l'autre, en excluant tout ce qui n'est pas nécessaire de l'image finale. [Vous pouvez consulter d'autres bonnes pratiques en matière de création d'images ici.](https://docs.docker.com/get-started/09_image_best/)
Une autre chose à prendre en compte est la durée de conservation des images mises en cache. Vous souhaiterez peut-être nettoyer les images périmées du cache d'images lorsqu'une certaine quantité de disque est utilisée. Cela vous permettra de vous assurer que vous disposez de suffisamment d'espace pour le fonctionnement de l'hôte. Par défaut, le [kubelet](https://kubernetes.io/docs/reference/generated/kubelet) collecte les déchets sur les images non utilisées toutes les cinq minutes et sur les conteneurs non utilisés toutes les minutes.
*Pour configurer les options pour la collecte de conteneurs et d'images inutilisés, ajustez le kubelet à l'aide d'un [fichier de configuration](https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/) et modifiez les paramètres liés à la collecte de déchets à l'aide du type de [https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/)ressource.*
[Vous pouvez en savoir plus à ce sujet dans la documentation de Kubernetes.](https://kubernetes.io/docs/concepts/architecture/garbage-collection/#containers-images)
# Observabilité
## Introduction
Les outils d'observabilité vous aident à détecter, corriger et étudier efficacement vos charges de travail. Le coût des données de télémétrie augmente naturellement à mesure que vous utilisez EKS. Il peut parfois être difficile de trouver un équilibre entre vos besoins opérationnels et de mesurer ce qui compte pour votre entreprise et de maîtriser les coûts d'observabilité. Ce guide se concentre sur les stratégies d'optimisation des coûts pour les trois piliers de l'observabilité : les logs, les métriques et les traces. Chacune de ces meilleures pratiques peut être appliquée indépendamment pour répondre aux objectifs d'optimisation de votre organisation.
## Journalisation
La journalisation joue un rôle essentiel dans la surveillance et le dépannage des applications de votre cluster. Plusieurs stratégies peuvent être utilisées pour optimiser les coûts d'exploitation forestière. Les meilleures pratiques répertoriées ci-dessous incluent l'examen de vos politiques de conservation des journaux afin de mettre en œuvre des contrôles précis sur la durée de conservation des données de journal, l'envoi des données de journal vers différentes options de stockage en fonction de leur importance et l'utilisation du filtrage des journaux pour affiner les types de messages de journal stockés. La gestion efficace de la télémétrie des journaux peut permettre à vos environnements de réaliser des économies.
## Plan de contrôle EKS
### Optimisez les journaux de votre plan de contrôle
[Le plan de contrôle Kubernetes est un [ensemble de composants](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) qui gèrent les clusters et ces composants envoient différents types d'informations sous forme de flux de journaux à un groupe de journaux sur Amazon. CloudWatch](https://aws.amazon.com/cloudwatch/) Bien que l'activation de tous les types de journaux du plan de contrôle présente des avantages, vous devez connaître les informations contenues dans chaque journal et les coûts associés au stockage de toutes les données télémétriques des journaux. Les frais d'[ingestion et de stockage CloudWatch des données Logs standard vous sont facturés pour les journaux](https://aws.amazon.com/cloudwatch/pricing/) envoyés à Amazon CloudWatch Logs depuis vos clusters. Avant de les activer, déterminez si chaque flux de log est nécessaire.
Par exemple, dans les clusters non liés à la production, activez de manière sélective des types de journaux spécifiques, tels que les journaux du serveur API, uniquement à des fins d'analyse, puis désactivez-les par la suite. Toutefois, pour les clusters de production, où vous ne pourrez peut-être pas reproduire les événements et où la résolution des problèmes nécessite davantage d'informations de journal, vous pouvez activer tous les types de journaux. D'autres détails sur la mise en œuvre de l'optimisation des coûts du plan de contrôle figurent dans ce billet de [blog](https://aws.amazon.com/blogs/containers/understanding-and-cost-optimizing-amazon-eks-control-plane-logs/).
#### Diffuser les journaux vers S3
Une autre bonne pratique d'optimisation des coûts consiste à diffuser les journaux du plan de contrôle vers S3 via CloudWatch des abonnements Logs. L'utilisation CloudWatch des [abonnements](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions.html) Logs vous permet de transférer les journaux de manière sélective vers S3, ce qui permet un stockage à long terme plus rentable que la conservation des journaux indéfiniment CloudWatch. Par exemple, pour les clusters de production, vous pouvez créer un groupe de journaux critique et tirer parti des abonnements pour diffuser ces journaux vers S3 après 15 jours. Cela vous permettra d'accéder rapidement aux journaux à des fins d'analyse, mais également de réaliser des économies en transférant les journaux vers un espace de stockage plus rentable.
**Important**
Depuis le 5 septembre 2023, les journaux EKS sont classés comme des journaux vendus dans Amazon Logs. CloudWatch Les Vended Logs sont des journaux de service AWS spécifiques publiés nativement par les services AWS pour le compte du client et disponibles à des prix réduits sur le volume. Consultez la [page de CloudWatch tarification d'Amazon](https://aws.amazon.com/cloudwatch/pricing/) pour en savoir plus sur la tarification de Vended Logs.
## Plan de données EKS
### Conservation de journal
La politique CloudWatch de conservation par défaut d'Amazon consiste à conserver les journaux indéfiniment et à ne jamais expirer, ce qui entraîne des coûts de stockage applicables à votre région AWS. Afin de réduire les coûts de stockage, vous pouvez personnaliser la politique de rétention pour chaque groupe de journaux en fonction de vos exigences en matière de charge de travail.
Dans un environnement de développement, une longue période de conservation peut ne pas être nécessaire. Toutefois, dans un environnement de production, vous pouvez définir une politique de rétention plus longue pour répondre aux exigences de dépannage, de conformité et de planification des capacités. Par exemple, si vous utilisez une application de commerce électronique pendant la haute saison des fêtes, si le système est soumis à une charge de travail plus importante et que des problèmes peuvent survenir qui ne sont pas immédiatement perceptibles, vous devez définir une durée de conservation des journaux plus longue pour un dépannage détaillé et une analyse post-événement.
Vous pouvez [configurer vos périodes de rétention](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention) dans la CloudWatch console AWS ou dans l'[API AWS](https://docs.aws.amazon.com/cli/latest/reference/logs/put-retention-policy.html) avec une durée comprise entre 1 jour et 10 ans en fonction de chaque groupe de journaux. Le fait de disposer d'une période de conservation flexible permet de réduire les coûts de stockage des journaux, tout en conservant les journaux critiques.
### Options de stockage des journaux
Le stockage est un facteur important des coûts d'observabilité. Il est donc essentiel d'optimiser votre stratégie de stockage des journaux. Vos stratégies doivent correspondre aux exigences de vos charges de travail tout en préservant les performances et l'évolutivité. L'une des stratégies pour réduire les coûts de stockage des journaux consiste à tirer parti des compartiments AWS S3 et de ses différents niveaux de stockage.
#### Transférer les journaux directement vers S3
Envisagez de transférer les journaux moins critiques, tels que les environnements de développement, directement vers S3 plutôt que vers Cloudwatch. Cela peut avoir un impact immédiat sur les coûts de stockage des journaux. Une option consiste à transférer les journaux directement vers S3 à l'aide de Fluentbit. Vous définissez cela dans la `[OUTPUT]` section, la destination où les journaux des conteneurs FluentBit sont transmis à des fins de conservation. Consultez les paramètres de configuration supplémentaires [ici](https://docs.fluentbit.io/manual/pipeline/outputs/s3#worker-support).
```
[OUTPUT]
Name eks_to_s3
Match application.*
bucket $S3_BUCKET name
region us-east-2
store_dir /var/log/fluentbit
total_file_size 30M
upload_timeout 3m
```
#### Transférer les journaux CloudWatch uniquement à des fins d'analyse à court terme
Pour les journaux plus critiques, tels que les environnements de production dans lesquels vous devrez peut-être effectuer une analyse immédiate des données, pensez à les transférer vers CloudWatch. Vous définissez cela dans la `[OUTPUT]` section, la destination où les journaux des conteneurs FluentBit sont transmis à des fins de conservation. Consultez les paramètres de configuration supplémentaires [ici](https://docs.fluentbit.io/manual/pipeline/outputs/cloudwatch).
```
[OUTPUT]
Name eks_to_cloudwatch_logs
Match application.*
region us-east-2
log_group_name fluent-bit-cloudwatch
log_stream_prefix from-fluent-bit-
auto_create_group On
```
Toutefois, cela n'aura pas d'effet immédiat sur vos économies. Pour réaliser des économies supplémentaires, vous devrez exporter ces journaux vers Amazon S3.
#### Exporter vers Amazon S3 depuis CloudWatch
Pour stocker les CloudWatch journaux Amazon à long terme, nous vous recommandons d'exporter vos CloudWatch journaux Amazon EKS vers Amazon Simple Storage Service (Amazon S3). Vous pouvez transférer les journaux vers le compartiment Amazon S3 en créant une tâche d'exportation via la [console](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3ExportTasksConsole.html) ou l'API. Une fois que vous l'avez fait, Amazon S3 propose de nombreuses options pour réduire encore les coûts. Vous pouvez définir vos propres [règles de cycle de vie Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) pour déplacer vos journaux vers une classe de stockage adaptée à vos besoins, ou tirer parti de la classe de stockage [Amazon S3 Intelligent-Tiering](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/) pour qu'AWS déplace automatiquement les données vers un stockage à long terme en fonction de votre modèle d'utilisation. Veuillez consulter ce [blog](https://aws.amazon.com/blogs/containers/understanding-and-cost-optimizing-amazon-eks-control-plane-logs/) pour plus de détails. Par exemple, pour votre environnement de production, les journaux sont conservés CloudWatch pendant plus de 30 jours avant d'être exportés vers le compartiment Amazon S3. Vous pouvez ensuite utiliser Amazon Athena pour interroger les données du compartiment Amazon S3 si vous devez consulter les journaux ultérieurement.
### Réduire les niveaux de journalisation
Pratiquez la journalisation sélective pour votre application. Vos applications et vos nœuds génèrent des journaux par défaut. Pour les journaux de vos applications, ajustez les niveaux de journalisation en fonction de la criticité de la charge de travail et de l'environnement. Par exemple, l'application Java ci-dessous génère des `INFO` journaux, ce qui est la configuration d'application par défaut typique et, selon le code, peut entraîner un volume élevé de données de journal.
```
import org.apache.log4j.*;
public class LogClass {
private static org.apache.log4j.Logger log = Logger.getLogger(LogClass.class);
public static void main(String[] args) {
log.setLevel(Level.INFO);
log.debug("This is a DEBUG message, check this out!");
log.info("This is an INFO message, nothing to see here!");
log.warn("This is a WARN message, investigate this!");
log.error("This is an ERROR message, check this out!");
log.fatal("This is a FATAL message, investigate this!"); } }
```
Dans un environnement de développement, modifiez votre niveau de journalisation sur`DEBUG`, car cela peut vous aider à résoudre les problèmes ou à détecter les problèmes potentiels avant qu'ils ne soient mis en production.
```
log.setLevel(Level.DEBUG);
```
Dans un environnement de production, pensez à modifier votre niveau de journalisation à `ERROR` ou`FATAL`. Cela ne produira le journal que lorsque votre application contient des erreurs, ce qui réduit le volume de sortie du journal et vous aide à vous concentrer sur les données importantes concernant le statut de votre application.
```
log.setLevel(Level.ERROR);
```
Vous pouvez affiner les niveaux de journalisation des différents composants Kubernetes. Par exemple, si vous utilisez [Bottlerocket](https://bottlerocket.dev/) comme système d'exploitation EKS Node, certains paramètres de configuration vous permettent d'ajuster le niveau du journal des processus kubelet. Vous trouverez ci-dessous un extrait de ce paramètre de configuration. Notez le [niveau de journalisation](https://github.com/bottlerocket-os/bottlerocket/blob/3f716bd68728f7fd825eb45621ada0972d0badbb/README.md?plain=1#L528) par défaut de **2** qui ajuste la verbosité de journalisation du processus. `kubelet`
```
[settings.kubernetes]
log-level = "2"
image-gc-high-threshold-percent = "85"
image-gc-low-threshold-percent = "80"
```
Pour un environnement de développement, vous pouvez définir un niveau de journalisation supérieur à **2** afin de visualiser des événements supplémentaires, ce qui est utile pour le débogage. Pour un environnement de production, vous pouvez définir le niveau sur **0** afin de n'afficher que les événements critiques.
### Tirez parti des filtres
Lorsque vous utilisez une configuration EKS Fluentbit par défaut pour envoyer des journaux de conteneur à Cloudwatch, FluentBit capture et envoie **TOUS les** journaux de conteneurs d'applications enrichis de métadonnées Kubernetes à Cloudwatch, comme indiqué dans le bloc de configuration ci-dessous. `[INPUT]`
```
[INPUT]
Name tail
Tag application.*
Exclude_Path /var/log/containers/cloudwatch-agent*, /var/log/containers/fluent-bit*, /var/log/containers/aws-node*, /var/log/containers/kube-proxy*
Path /var/log/containers/*.log
Docker_Mode On
Docker_Mode_Flush 5
Docker_Mode_Parser container_firstline
Parser docker
DB /var/fluent-bit/state/flb_container.db
Mem_Buf_Limit 50MB
Skip_Long_Lines On
Refresh_Interval 10
Rotate_Wait 30
storage.type filesystem
Read_from_Head ${READ_FROM_HEAD}
```
La `[INPUT]` section ci-dessus traite de l'ingestion de tous les journaux du conteneur. Cela peut générer une grande quantité de données qui ne sont peut-être pas nécessaires. Le filtrage de ces données peut réduire la quantité de données de journal envoyées, réduisant CloudWatch ainsi vos coûts. Vous pouvez appliquer un filtre à vos journaux avant qu'ils ne soient renvoyés vers CloudWatch. Fluentbit le définit dans la `[FILTER]` section. Par exemple, empêcher l'ajout des métadonnées Kubernetes aux événements du journal peut réduire le volume de votre journal.
```
[FILTER]
Name nest
Match application.*
Operation lift
Nested_under kubernetes
Add_prefix Kube.
[FILTER]
Name modify
Match application.*
Remove Kube.
Remove Kube.
Remove Kube.
[FILTER]
Name nest
Match application.*
Operation nest
Wildcard Kube.*
Nested_under kubernetes
Remove_prefix Kube.
```
## Métriques
[Les métriques](https://aws-observability.github.io/observability-best-practices/signals/metrics/) fournissent des informations précieuses concernant les performances de votre système. En consolidant tous les indicateurs relatifs au système ou aux ressources disponibles dans un emplacement centralisé, vous pouvez comparer et analyser les données de performance. Cette approche centralisée vous permet de prendre des décisions stratégiques plus éclairées, telles que l'augmentation ou la réduction des ressources. En outre, les indicateurs jouent un rôle crucial dans l'évaluation de l'état des ressources, vous permettant de prendre des mesures proactives si nécessaire. En général, les coûts d'observabilité augmentent en fonction de la collecte et de la conservation des données de télémétrie. Vous trouverez ci-dessous quelques stratégies que vous pouvez mettre en œuvre pour réduire le coût de la télémétrie métrique : collecter uniquement les mesures importantes, réduire la cardinalité de vos données de télémétrie et affiner la granularité de votre collecte de données de télémétrie.
### Surveillez ce qui compte et collectez uniquement ce dont vous avez besoin
La première stratégie de réduction des coûts consiste à réduire le nombre de mesures que vous collectez et, par conséquent, à réduire les coûts de rétention.
1. Commencez par revenir à vos exigences et/ou à celles de vos parties prenantes afin de déterminer [les indicateurs les plus importants](https://aws-observability.github.io/observability-best-practices/guides/#monitor-what-matters). Les indicateurs de réussite sont différents pour chacun \$1 Sachez à quoi ressemble *une belle* apparence et mesurez en conséquence.
1. Envisagez d'étudier en profondeur les charges de travail que vous soutenez et d'identifier ses indicateurs de performance clés (KPIs), également appelés « signaux d'or ». Elles devraient être conformes aux exigences des entreprises et des parties prenantes. Le calcul SLIs et SLOs l' SLAs utilisation d'Amazon CloudWatch et de Metric Math sont essentiels pour gérer la fiabilité des services. Suivez les meilleures pratiques décrites dans ce [guide](https://aws-observability.github.io/observability-best-practices/guides/operational/business/key-performance-indicators/#10-understanding-kpis-golden-signals) pour surveiller et maintenir efficacement les performances de votre environnement EKS.
1. Passez ensuite en revue les différentes couches de l'infrastructure pour [connecter et corréler](https://aws-observability.github.io/observability-best-practices/signals/metrics/#correlate-with-operational-metric-data) le cluster EKS, le nœud et les indicateurs d'infrastructure supplémentaires à votre charge KPIs de travail. Stockez vos indicateurs commerciaux et opérationnels dans un système dans lequel vous pouvez les corréler et tirer des conclusions en fonction des impacts observés sur les deux.
1. EKS expose les métriques du plan de contrôle, du cluster kube-state-metrics, des pods et des nœuds. La pertinence de tous ces indicateurs dépend de vos besoins, mais il est probable que vous n'ayez pas besoin de tous les indicateurs sur les différentes couches. Vous pouvez utiliser ce guide [des indicateurs essentiels d'EKS](https://aws-observability.github.io/observability-best-practices/guides/containers/oss/eks/best-practices-metrics-collection/) comme référence pour surveiller l'état général d'un cluster EKS et vos charges de travail.
Voici un exemple de configuration de Prometheus Scrape dans lequel nous utilisons le pour ne conserver que les métriques `relabel_config` de Kubelet et pour supprimer toutes les métriques `metric_relabel_config` de conteneur.
```
kubernetes_sd_configs:
- role: endpoints
namespaces:
names:
- kube-system
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
tls_config:
insecure_skip_verify: true
relabel_configs:
- source_labels: [__meta_kubernetes_service_label_k8s_app]
regex: kubelet
action: keep
metric_relabel_configs:
- source_labels: [__name__]
regex: container_(network_tcp_usage_total|network_udp_usage_total|tasks_state|cpu_load_average_10s)
action: drop
```
### Réduire la cardinalité le cas échéant
La cardinalité fait référence au caractère unique des valeurs des données en combinaison avec leurs dimensions (par exemple, les étiquettes Prometheus) pour un ensemble de mesures spécifique. Les métriques de cardinalité élevée ont de nombreuses dimensions et chaque combinaison de métriques de dimensions présente un caractère unique plus élevé. Une cardinalité plus élevée entraîne une augmentation de la taille des données de télémétrie métrique et des besoins de stockage, ce qui augmente les coûts.
Dans l'exemple de cardinalité élevée ci-dessous, nous voyons que la métrique, la latence, comporte des dimensions, requestiD, customerID et service et que chaque dimension possède de nombreuses valeurs uniques. La cardinalité est la mesure de la combinaison du nombre de valeurs possibles par dimension. Dans Prometheus, chaque ensemble de dimensions/étiquettes uniques est considéré comme une nouvelle métrique. Une cardinalité élevée signifie donc un plus grand nombre de métriques.
Dans les environnements EKS comportant de nombreuses métriques et dimensions/étiquettes par métrique (cluster, espace de noms, service, pod, conteneur, etc.), la cardinalité a tendance à augmenter. Afin d'optimiser les coûts, considérez soigneusement la cardinalité des indicateurs que vous collectez. Par exemple, si vous agrégez une métrique spécifique à des fins de visualisation au niveau du cluster, vous pouvez supprimer les étiquettes supplémentaires situées sur une couche inférieure, telles que l'étiquette de l'espace de noms.
Afin d'identifier les métriques de cardinalité élevées dans Prometheus, vous pouvez exécuter la requête PROMQL suivante pour déterminer quelles cibles de scrape ont le plus grand nombre de métriques (cardinalité) :
```
topk_max(5, max_over_time(scrape_samples_scraped[1h]))
```
et la requête PROMQL suivante peut vous aider à déterminer quelles cibles de scrape présentent les taux de désabonnement (combien de nouvelles séries de métriques ont été créées au cours d'un scrape donné) les plus élevés :
```
topk_max(5, max_over_time(scrape_series_added[1h]))
```
Si vous utilisez grafana, vous pouvez utiliser l'outil Mimir de Grafana Lab pour analyser vos tableaux de bord Grafana et les règles de Prometheus afin d'identifier les métriques de haute cardinalité non utilisées. Suivez [ce guide](https://grafana.com/docs/grafana-cloud/account-management/billing-and-usage/control-prometheus-metrics-usage/usage-analysis-mimirtool/?pg=blog&plcmt=body-txt#analyze-and-reduce-metrics-usage-with-grafana-mimirtool) pour savoir comment utiliser les `mimirtool analyze prometheus` commandes `mimirtool analyze` et pour identifier les métriques actives qui ne sont pas référencées dans vos tableaux de bord.
### Tenez compte de la granularité métrique
La collecte de métriques à une granularité plus élevée, par exemple chaque seconde au lieu de chaque minute, peut avoir un impact important sur le volume de données télémétriques collectées et stockées, ce qui augmente les coûts. Déterminez des intervalles de collecte raisonnables ou mesurez des intervalles de collecte entre une granularité suffisante pour détecter les problèmes transitoires et un niveau suffisamment bas pour être rentable. Réduisez la granularité des métriques utilisées pour la planification des capacités et l'analyse de fenêtres temporelles étendues.
[Vous trouverez ci-dessous un extrait de la configuration par défaut d'AWS Distro for Opentelemetry (ADOT) EKS Addon Collector.](https://docs.aws.amazon.com/eks/latest/userguide/deploy-deployment.html)
**Important**
l'intervalle global de grattage de Prometheus est fixé à 15 s. Cet intervalle de récupération peut être augmenté, ce qui entraîne une diminution de la quantité de données métriques collectées dans Prometheus.
```
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: my-collector-amp
...
config: |
extensions:
sigv4auth:
region: "++++++" service: "aps"++++++
receivers:
#
# Scrape configuration for the Prometheus Receiver
# This is the same configuration used when Prometheus is installed using the community Helm chart
#
prometheus:
config:
global: scrape_interval: 15s
scrape_timeout: 10s
```
## Tracing
Le principal coût associé au traçage provient de la génération du stockage des traces. Avec le traçage, l'objectif est de recueillir suffisamment de données pour diagnostiquer et comprendre les aspects liés aux performances. Cependant, comme les coûts des traces de X-Ray sont basés sur les données transmises à X-Ray, l'effacement des traces une fois qu'elles ont été transmises ne réduira pas vos coûts. Examinons les moyens de réduire les coûts de suivi tout en conservant les données nécessaires pour effectuer une analyse appropriée.
### Appliquer les règles d'échantillonnage
La fréquence d'échantillonnage des rayons X est prudente par défaut. Définissez des règles d'échantillonnage qui vous permettent de contrôler la quantité de données que vous collectez. Cela améliorera l'efficacité des performances tout en réduisant les coûts. En [diminuant le taux d'échantillonnage](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-sampling.html#xray-console-custom), vous pouvez collecter des traces à partir de la demande uniquement pour ce dont vos charges de travail ont besoin, tout en maintenant une structure de coûts inférieure.
Par exemple, vous avez une application Java dont vous souhaitez déboguer les traces de toutes les demandes pour une route problématique.
**Configuration via le SDK pour charger les règles d'échantillonnage à partir d'un document JSON**
```
{
"version": 2,
"rules": [
{
"description": "debug-eks",
"host": "*",
"http_method": "PUT",
"url_path": "/history/*",
"fixed_target": 0,
"rate": 1,
"service_type": "debug-eks"
}
],
"default": {
"fixed_target": 1,
"rate": 0.1
}
}
```
**Par le biais de la console**
### Appliquer Tail Sampling avec AWS Distro for OpenTelemetry (ADOT)
ADOT Tail Sampling vous permet de contrôler le volume de traces ingérées dans le service. Cependant, Tail Sampling vous permet de définir les politiques d'échantillonnage une fois que toutes les étapes de la demande ont été terminées plutôt qu'au début. Cela limite encore davantage la quantité de données brutes transférées CloudWatch, réduisant ainsi les coûts.
Par exemple, si vous collectez 1 % du trafic vers une page de destination et 10 % des demandes vers une page de paiement, cela peut vous laisser 300 traces sur une période de 30 minutes. Avec une règle ADOT Tail Sampling qui filtre les erreurs spécifiques, vous pourriez vous retrouver avec 200 traces, ce qui réduit le nombre de traces stockées.
```
processors:
groupbytrace:
wait_duration: 10s
num_traces: 300
tail_sampling:
decision_wait: 1s # This value should be smaller than wait_duration
policies:
- ..... # Applicable policies**
batch/tracesampling:
timeout: 0s # No need to wait more since this will happen in previous processors
send_batch_max_size: 8196 # This will still allow us to limit the size of the batches sent to subsequent exporters
service:
pipelines:
traces/tailsampling:
receivers: [otlp]
processors: [groupbytrace, tail_sampling, batch/tracesampling]
exporters: [awsxray]
```
### Tirez parti des options de stockage Amazon S3
Vous devez utiliser le compartiment AWS S3 et ses différentes classes de stockage pour stocker les traces. Exportez les traces vers S3 avant l'expiration de la période de conservation. Utilisez les règles du cycle de vie d'Amazon S3 pour déplacer les données de suivi vers la classe de stockage qui répond à vos besoins.
Par exemple, si vous avez des traces datant de 90 jours, [Amazon S3 Intelligent-Tiering](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/) peut automatiquement déplacer les données vers un stockage à long terme en fonction de vos habitudes d'utilisation. Vous pouvez utiliser [Amazon Athena](https://aws.amazon.com/athena/) pour interroger les données dans Amazon S3 si vous devez vous référer aux traces ultérieurement. Cela peut encore réduire vos coûts de suivi distribué.
## Ressources supplémentaires :
+ [Guide des meilleures pratiques en matière d'observabilité](https://aws-observability.github.io/observability-best-practices/guides/)
+ [Collecte de statistiques sur les meilleures pratiques](https://aws-observability.github.io/observability-best-practices/guides/containers/oss/eks/)
+ [AWS re:Invent 2022 - Bonnes pratiques en matière d'observabilité chez Amazon () COP343](https://www.youtube.com/watch?v=zZPzXEBW4P8)
+ [AWS re:Invent 2022 - Observabilité : meilleures pratiques pour les applications modernes () COP344](https://www.youtube.com/watch?v=YiegAlC_yyc)