Ces coûts répartis sont enrichis avec des tags provenant des nœuds, pods, tâches et volumes. Vous pouvez utiliser ces tags pour ventiler les coûts selon n’importe quelles dimensions associées.
Seuls les tags de la ressource directe, comme un pod, ainsi que des nœuds sous-jacents, sont ajoutés aux métriques de coûts par défaut. Pour inclure des labels en tant que tags, des annotations en tant que tags ou des tags provenant de ressources associées comme les namespaces, consultez la section Extraction de tags Kubernetes.
Calculer
Pour l’allocation de calcul Kubernetes, un nœud Kubernetes est associé aux coûts de son instance host. Le nom de cluster du nœud et tous les tags du nœud sont ajoutés au coût de calcul total du nœud. Cela vous permet d’associer des dimensions au niveau du cluster au coût de l’instance, sans prendre en compte les pods planifiés sur le nœud.
Ensuite, Datadog examine tous les pods ayant été exécutés sur ce nœud pendant la journée. Le coût du nœud est attribué à chaque pod en fonction des ressources utilisées et de la durée d’exécution. Ce coût calculé est enrichi avec l’ensemble des tags du pod.
Remarque : seuls les tags des pods et des nœuds sont ajoutés aux métriques de coûts. Pour inclure des labels, activez les labels en tant que tags pour les nœuds et les pods.
Tous les autres coûts reçoivent la même valeur et les mêmes tags que la métrique source aws.cost.amortized.
Stockage de volumes persistants
Pour l’allocation du stockage de volumes persistants Kubernetes, les volumes persistants (PV), les demandes de volumes persistants (PVC), les nœuds et les pods sont associés aux coûts de leurs volumes EBS. Tous les tags associés aux PV, aux PVC, aux nœuds et aux pods sont ajoutés aux postes de coûts des volumes EBS.
Ensuite, Datadog examine tous les pods ayant revendiqué le volume ce jour-là. Le coût du volume est attribué à un pod en fonction des ressources utilisées et de la durée d’exécution. Ces ressources incluent la capacité de stockage provisionnée, les IOPS et le débit. Ce coût attribué est enrichi avec l’ensemble des tags du pod.
Amazon ECS sur EC2
Pour l’allocation ECS, Datadog détermine quelles tâches ont été exécutées sur chaque instance EC2 utilisée pour ECS. Si vous activez AWS Split Cost Allocation, les métriques attribuent les coûts ECS en fonction de l’utilisation plutôt que de la réservation, offrant ainsi un niveau de détail plus granulaire.
En fonction des ressources utilisées par la tâche, Datadog attribue à celle-ci la part correspondante du coût de calcul de l’instance. Le coût calculé est enrichi avec l’ensemble des tags de la tâche ainsi que tous les tags des conteneurs (à l’exception des noms de conteneurs) exécutés dans la tâche.
Amazon ECS sur Fargate
Les tâches ECS exécutées sur Fargate sont déjà entièrement allouées dans le CUR. CCM enrichit ces données en ajoutant des tags prêts à l’emploi et des tags de conteneurs au coût AWS Fargate.
Transfert de données
Pour l’allocation du transfert de données Kubernetes, un nœud Kubernetes est associé à ses coûts de transfert de données provenant du CUR. Le nom de cluster du nœud et tous les tags du nœud sont ajoutés au coût total de transfert de données du nœud. Cela vous permet d’associer des dimensions au niveau du cluster au coût du transfert de données, sans prendre en compte les pods planifiés sur le nœud.
Ensuite, Datadog examine les ressources de charge de travail quotidiennes exécutées sur ce nœud. Le coût du nœud est attribué au niveau de la charge de travail en fonction du volume de trafic réseau utilisé. Ce coût calculé est enrichi avec l’ensemble des tags de la ressource de charge de travail.
Remarque : seuls les tags des pods et des nœuds sont ajoutés aux métriques de coûts. Pour inclure des labels, activez les labels en tant que tags pour les nœuds et les pods.
Cloud Network Monitoring doit être activé sur tous les hosts AWS pour permettre une allocation précise des coûts de transfert de données. Si certains hosts n’ont pas Cloud Network Monitoring activé, les coûts de transfert de données de ces hosts ne sont pas alloués et peuvent apparaître comme un compartiment n/a selon les conditions de filtre et de regroupement.
Datadog prend en charge l’allocation des coûts de transfert de données uniquement avec les ressources de charge de travail standard 6. Pour les ressources de charge de travail personnalisées, les coûts de transfert de données ne peuvent être alloués qu’au niveau du cluster, et non au niveau du nœud ou du namespace.
Seuls les tags de la ressource directe, comme un pod, ainsi que des nœuds sous-jacents, sont ajoutés aux métriques de coûts par défaut. Pour inclure des labels en tant que tags, des annotations en tant que tags ou des tags provenant de ressources associées comme les namespaces, consultez la section Extraction de tags Kubernetes.
Calculer
Pour l’allocation de calcul Kubernetes, un nœud Kubernetes est associé aux coûts de son instance host. Le nom de cluster du nœud et tous les tags du nœud sont ajoutés au coût de calcul total du nœud. Cela vous permet d’associer des dimensions au niveau du cluster au coût de l’instance, sans prendre en compte les pods planifiés sur le nœud.
Ensuite, Datadog examine tous les pods ayant été exécutés sur ce nœud pendant la journée. Le coût du nœud est attribué à chaque pod en fonction des ressources utilisées et de la durée d’exécution. Ce coût calculé est enrichi avec l’ensemble des tags du pod.
Remarque : seuls les tags des pods et des nœuds sont ajoutés aux métriques de coûts. Pour inclure des labels, activez les labels en tant que tags pour les nœuds et les pods.
Tous les autres coûts reçoivent la même valeur et les mêmes tags que la métrique source azure.cost.amortized.
Seuls les tags de la ressource directe, comme un pod, ainsi que des nœuds sous-jacents, sont ajoutés aux métriques de coûts par défaut. Pour inclure des labels en tant que tags, des annotations en tant que tags ou des tags provenant de ressources associées comme les namespaces, consultez la section Extraction de tags Kubernetes.
Calculer
Pour l’allocation de calcul Kubernetes, un nœud Kubernetes est associé aux coûts de son instance host. Le nom de cluster du nœud et tous les tags du nœud sont ajoutés au coût de calcul total du nœud. Cela vous permet d’associer des dimensions au niveau du cluster au coût de l’instance, sans prendre en compte les pods planifiés sur le nœud.
Ensuite, Datadog examine tous les pods ayant été exécutés sur ce nœud pendant la journée. Le coût du nœud est attribué à chaque pod en fonction des ressources utilisées et de la durée d’exécution. Ce coût calculé est enrichi avec l’ensemble des tags du pod.
Remarque : seuls les tags des pods et des nœuds sont ajoutés aux métriques de coûts. Pour inclure des labels, activez les labels en tant que tags pour les nœuds et les pods.
Tous les autres coûts reçoivent la même valeur et les mêmes tags que la métrique source gcp.cost.amortized.
Coûts Kubernetes sans Agent
Pour afficher les coûts des clusters GKE sans activer Datadog Infrastructure Monitoring, utilisez GKE cost allocation. Activez GKE cost allocation sur les clusters GKE non surveillés pour accéder à cet ensemble de fonctionnalités. Cette approche comporte un certain nombre de limitations (voir ci-dessous).
Limitations et différences par rapport à l’Agent Datadog
- Il n’y a pas de prise en charge du suivi des coûts inactifs des charges de travail.
- Le coût des pods individuels n’est pas suivi, seuls le coût agrégé d’une charge de travail et du namespace le sont. Il n’existe pas de tag
pod_name. - GKE enrichit les données uniquement avec les labels de pods et ignore tous les tags Datadog que vous ajoutez.
- La liste complète des limitations se trouve dans la documentation officielle de GKE.
Pour activer l’allocation des coûts GKE, consultez la documentation officielle de GKE.
