Datadog Kubernetes Autoscaling surveille en continu vos ressources Kubernetes pour fournir des recommandations de mise à l’échelle immédiates et une mise à l’échelle automatique multidimensionnelle de vos charges de travail Kubernetes. Vous pouvez déployer la mise à l’échelle automatique via l’interface Web Datadog ou avec une DatadogPodAutoscaler ressource personnalisée.

Fonctionnement

Datadog utilise des métriques d’utilisation en temps réel et historiques ainsi que des signaux d’événements provenant de vos agents Datadog existants pour formuler des recommandations. Vous pouvez ensuite examiner ces recommandations et choisir de les déployer.

Par défaut, Datadog Kubernetes Autoscaling utilise des valeurs de coût estimées pour le CPU et la mémoire afin d’afficher les opportunités d’économies et les estimations d’impact. Vous pouvez également utiliser Kubernetes Autoscaling avec Cloud Cost Management pour obtenir des rapports basés sur les coûts exacts de vos types d’instances.

La mise à l’échelle automatisée des charges de travail est alimentée par une DatadogPodAutoscaler ressource personnalisée qui définit le comportement de mise à l’échelle au niveau de chaque charge de travail. Datadog Cluster Agent agit en tant que contrôleur pour cette ressource personnalisée.

Remarque : Chaque cluster peut avoir un maximum de 1000 charges de travail optimisées avec Datadog Kubernetes Autoscaling.

Compatibilité

• Distributions : cette fonctionnalité est compatible avec l’ensemble des distributions Kubernetes prises en charge par Datadog.
• Mise à l’échelle automatique de la charge de travail : cette fonctionnalité constitue une alternative à l’Horizontal Pod Autoscaler (HPA) et au Vertical Pod Autoscaler (VPA). Datadog recommande de supprimer tout HPA ou VPA d’une charge de travail lors de l’activation de Datadog Kubernetes Autoscaling afin de l’optimiser. Ces charges de travail sont identifiées dans l’application pour votre compte. Remarque : Vous pouvez tester Datadog Kubernetes Autoscaling tout en conservant votre HPA et/ou VPA en créant un DatadogPodAutoscaler avec mode: Preview dans la section applyPolicy.

Prérequis

• Remote Configuration doit être activé à la fois au niveau de l’organisation et sur les Agents de votre cluster cible. Consultez Activation de Remote Configuration pour obtenir des instructions de configuration.

• Helm, pour la mise à jour de votre Datadog Agent.

• (Pour les utilisateurs de Datadog Operator) kubectl CLI, pour la mise à jour du Datadog Agent.

• Lorsque vous utilisez la mise à l’échelle automatique en temps réel, Datadog recommande d’utiliser la dernière version du Datadog Agent. Cela permet de garantir l’accès aux dernières améliorations et optimisations. Les recommandations de mise à l’échelle nécessitent que l’intégration Kubernetes State Core soit activée.
  
  

  Fonctionnalité	Version minimale de l’Agent
  Recommandations de mise à l’échelle de la charge de travail dans l’application	7.50+
  Mise à l’échelle de la charge de travail en temps réel	7.66.1+
  Recommandations et mise à l’échelle automatique pour Argo Rollout	7.71+
  Mise à l’échelle automatique du cluster (inscription à la version préliminaire)	7.72+
  Redimensionnement vertical de pod sur place (opt-in)	7.78+
  Activation du profil de cluster, étiquette de charge de travail	7.78+
  Activation du profil de cluster, étiquette de namespace	7.79+

• Les autorisations utilisateur suivantes :

  • Gestion de l’organisation (requise pour Remote Configuration)
  • API Keys Write (requise pour Remote Configuration)
  • Workload Scaling Write
  • Autoscaling Manage

• (Recommandé) Noyau Linux v5.19+ et cgroup v2

Configuration

helm upgrade datadog-operator datadog/datadog-operator

spec:
  features:
    autoscaling:
      workload:
        enabled: true
    eventCollection:
      unbundleEvents: true
  override:
    clusterAgent:
      env:
        - name: DD_AUTOSCALING_FAILOVER_ENABLED
          value: "true"
    nodeAgent:
      env:
        - name: DD_AUTOSCALING_FAILOVER_ENABLED
          value: "true"

...
spec:
  features:
    admissionController:
      enabled: true
...

kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml

datadog:
  autoscaling:
    workload:
      enabled: true
  kubernetesEvents:
    unbundleEvents: true

...
clusterAgent:
  admissionController:
    enabled: true
...

helm repo update

helm upgrade -f datadog-values.yaml <RELEASE_NAME> datadog/datadog

Estimations des coûts et économies liés à l’inactivité

  (cpu_capacity - max(cpu_usage, cpu_requests)) * core_rate_per_hour
+ (mem_capacity - max(mem_usage, mem_requests)) * memory_rate_per_hour

  (max(cpu_usage, cpu_requests) - cpu_usage) * core_rate_per_hour
+ (max(mem_usage, mem_requests) - mem_usage) * memory_rate_per_hour

Utilisation

Identifier les ressources à redimensionner

La page de résumé de l’autoscaling constitue un point de départ pour les équipes de plateforme afin de comprendre les opportunités totales d’économies de ressources Kubernetes à l’échelle d’une organisation, et de filtrer par clusters et namespaces clés.

La page de configuration offre la possibilité de sélectionner plusieurs charges de travail à mettre à l’échelle et de gérer votre optimisation par lots.

La vue de mise à l’échelle du cluster fournit des informations par cluster sur le total de CPU inutilisé, le total de mémoire inutilisée et les coûts.

Cliquez sur un cluster pour obtenir des informations détaillées et un tableau des charges de travail du cluster triées par économies estimées. Si vous êtes propriétaire d’une application ou d’un service individuel, vous pouvez également filtrer par nom d’équipe ou de service directement depuis la vue de liste Workload Scaling.

Depuis l’une de ces vues, cliquez sur Optimize sur une charge de travail pour voir sa recommandation de mise à l’échelle, puis passez à Enable Autoscaling for a workload.

Enable Autoscaling for a workload

Une fois que vous avez identifié une charge de travail à optimiser, inspectez son Scaling Recommendation. Cliquez sur Configure Recommendation pour ajouter des contraintes ou ajuster les niveaux d’utilisation cibles avant l’activation.

Il existe trois façons d’activer la mise à l’échelle automatique pour une charge de travail. Choisissez le chemin qui correspond à la manière dont vous déployez vos charges de travail aujourd’hui.

Chemin A : Datadog UI

Le moyen le plus rapide de commencer est la Setup page dans le Datadog UI. L’assistant vous guide à travers cinq étapes : sélectionner un cluster, vérifier les exigences de l’Agent et des autorisations, choisir une méthode d’installation, sélectionner un modèle de mise à l’échelle et déployer. Modèles disponibles dans l’assistant :

• Optimiser les coûts : cible d’utilisation CPU élevée, réduction agressive, seuil de réplicas le plus bas. Idéal pour les charges de travail sans état et sensibles aux coûts.
• Optimiser l’équilibre : cible d’utilisation modérée, augmentation rapide, réduction équilibrée. Idéal pour la plupart des charges de travail sans état.
• Optimiser les performances : cible d’utilisation prudente, augmentation rapide, réduction lente, seuil de réplicas plus élevé. Idéal pour les services avec état ou critiques.
• Personnaliser : commencez à partir de l’un des modèles ci-dessus et ajustez vous-même la cible CPU, les réplicas et les fenêtres de stabilisation.

L’assistant de configuration est idéal pour essayer la mise à l’échelle automatique sur une seule charge de travail, se familiariser avec une recommandation ou intégrer un petit ensemble de charges de travail. (Nécessite les autorisations Workload Scaling Write et Autoscaling Manage.)

Chemin B : GitOps

Définissez une ressource personnalisée DatadogPodAutoscaler qui cible votre charge de travail et appliquez-la via les outils que vous utilisez déjà pour déployer des manifestes Kubernetes, qu’il s’agisse de kubectl apply, Helm, ArgoCD, Terraform ou d’un autre outil GitOps. La création du manifeste est la même quel que soit le mécanisme de livraison. Consultez les exemples de configurations ci-dessous pour obtenir des points de départ prêts à être modifiés, couvrant l’optimisation des coûts, la mise à l’échelle équilibrée, le redimensionnement vertical uniquement et la mise à l’échelle horizontale par requête personnalisée.

Pour des guides spécifiques aux outils, consultez :

• Gérer DatadogPodAutoscaler avec ArgoCD
• Gérer DatadogPodAutoscaler avec Terraform

Exemples de configurations DatadogPodAutoscaler

Les exemples suivants présentent des configurations DatadogPodAutoscaler courantes pour différentes stratégies de mise à l’échelle. Utilisez-les comme points de départ et ajustez les valeurs pour répondre aux besoins de votre charge de travail. Si vous préférez choisir un modèle dans le Datadog UI, suivez le Chemin A ci-dessus.

apiVersion: datadoghq.com/v1alpha2
kind: DatadogPodAutoscaler
metadata:
    name: <WORKLOAD_NAME>
    namespace: <NAMESPACE>
spec:
    targetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: <WORKLOAD_NAME>
    owner: Local
    applyPolicy:
        mode: Apply
        scaleDown:
            rules:
                # Aggressive: allow 50% reduction every 2 minutes
                - periodSeconds: 120
                  type: Percent
                  value: 50
            stabilizationWindowSeconds: 300
        scaleUp:
            rules:
                - periodSeconds: 120
                  type: Percent
                  value: 50
            stabilizationWindowSeconds: 190
        update:
            strategy: Auto
    constraints:
        maxReplicas: 100
        # Allow scaling down to 1 replica for maximum savings
        minReplicas: 1
    objectives:
        # High utilization target to maximize cost efficiency
        - type: PodResource
          podResource:
            name: cpu
            value:
                type: Utilization
                utilization: 85

apiVersion: datadoghq.com/v1alpha2
kind: DatadogPodAutoscaler
metadata:
    name: <WORKLOAD_NAME>
    namespace: <NAMESPACE>
spec:
    targetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: <WORKLOAD_NAME>
    owner: Local
    applyPolicy:
        mode: Apply
        scaleDown:
            rules:
                # Conservative: allow only 20% reduction every 20 minutes
                - periodSeconds: 1200
                  type: Percent
                  value: 20
            stabilizationWindowSeconds: 600
        scaleUp:
            rules:
                - periodSeconds: 120
                  type: Percent
                  value: 50
            stabilizationWindowSeconds: 130
        update:
            strategy: Auto
    constraints:
        maxReplicas: 100
        # Maintain at least 2 replicas for availability
        minReplicas: 2
    objectives:
        # Moderate utilization target balances cost and performance
        - type: PodResource
          podResource:
            name: cpu
            value:
                type: Utilization
                utilization: 70

apiVersion: datadoghq.com/v1alpha2
kind: DatadogPodAutoscaler
metadata:
    name: <WORKLOAD_NAME>
    namespace: <NAMESPACE>
spec:
    targetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: <WORKLOAD_NAME>
    owner: Local
    applyPolicy:
        mode: Apply
        # Horizontal scaling disabled; only vertical resizing
        scaleDown:
            strategy: Disabled
        scaleUp:
            strategy: Disabled
        update:
            strategy: Auto
    constraints:
        maxReplicas: 100

apiVersion: datadoghq.com/v1alpha2
kind: DatadogPodAutoscaler
metadata:
    name: <WORKLOAD_NAME>
    namespace: <NAMESPACE>
spec:
    targetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: <WORKLOAD_NAME>
    owner: Local
    applyPolicy:
        mode: Apply
        scaleDown:
            rules:
                - periodSeconds: 1200
                  type: Percent
                  value: 20
            stabilizationWindowSeconds: 600
        scaleUp:
            rules:
                - periodSeconds: 120
                  type: Percent
                  value: 50
            stabilizationWindowSeconds: 130
        # Vertical updates disabled — horizontal only
        update:
            strategy: Disabled
    constraints:
        maxReplicas: 100
        minReplicas: 2
    objectives:
        - type: CustomQuery
          customQuery:
            # Replace with your own Datadog metric query
            request:
                formula: usage
                queries:
                    - name: usage
                      source: Metrics
                      metrics:
                        query: avg:redis.info.latency_ms{kube_cluster_name:<CLUSTER_NAME>,kube_namespace:<NAMESPACE>,kube_deployment:<WORKLOAD_NAME>}
            value:
                type: AbsoluteValue
                absoluteValue: 500M
            window: 5m0s
    fallback:
        horizontal:
            # With custom queries, local fallback is not activated by default
            enabled: false
            # Direction can be ScaleUp, ScaleDown or All
            direction: ScaleUp
            # When using custom queries, a CPU or Memory fallback objective is required
            objectives:
                - type: PodResource
                  podResource:
                    name: cpu
                    value:
                        type: Utilization
                        utilization: 70
            triggers:
                staleRecommendationThresholdSeconds: 600

Profils de cluster

Un DatadogPodAutoscalerClusterProfile est une ressource à portée de cluster qui contient un modèle de DatadogPodAutoscaler. Le Cluster Agent surveille les ressources Deployment et StatefulSet (et, sur 7.79+, les namespaces qui les contiennent) pour le label autoscaling.datadoghq.com/profile, et crée un DatadogPodAutoscaler géré pour chaque charge de travail correspondante. Un profil s’applique à de nombreuses charges de travail ; une charge de travail correspond toujours à un DatadogPodAutoscaler.

Les profils de cluster et le label au niveau de la charge de travail nécessitent Datadog Cluster Agent 7.78.0+. L’activation au niveau du namespace (labelliser un namespace pour inclure chaque charge de travail prise en charge qu’il contient dans un profil) nécessite Datadog Cluster Agent 7.79.0+. Les Cluster Agents plus anciens ignorent le label de profil.

Profils intégrés

Le Cluster Agent fournit trois profils intégrés et les recrée au démarrage, vous n’avez donc pas besoin de soumettre de YAML de CRD pour les utiliser. Les noms sont réservés.

Pour activer un profil sur une seule charge de travail, ajoutez le label au metadata.labels de la charge de travail :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: production
  labels:
    autoscaling.datadoghq.com/profile: datadog-optimize-balance
spec:
  # ...rest of the Deployment spec

Pour activer un profil sur chaque charge de travail prise en charge dans un namespace, labellisez plutôt le namespace (nécessite le Cluster Agent 7.79.0+) :

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    autoscaling.datadoghq.com/profile: datadog-optimize-balance

Profils personnalisés

Créez un DatadogPodAutoscalerClusterProfile lorsqu’aucun profil intégré ne correspond à votre politique de mise à l’échelle. Les profils sont à portée de cluster, appliquez-les donc sans flag --namespace (ou placez-les dans la couche au niveau du cluster de votre dépôt de configuration).

apiVersion: datadoghq.com/v1alpha2
kind: DatadogPodAutoscalerClusterProfile
metadata:
  name: cost-optimized-strict-floor
spec:
  template:
    applyPolicy:
      mode: Apply
      scaleUp:
        stabilizationWindowSeconds: 190
        rules:
          - type: Percent
            value: 50
            periodSeconds: 120
      scaleDown:
        stabilizationWindowSeconds: 300
        rules:
          - type: Percent
            value: 50
            periodSeconds: 120
    constraints:
      minReplicas: 1
    objectives:
      - type: PodResource
        podResource:
          name: cpu
          value:
            type: Utilization
            utilization: 85

Référencez le profil personnalisé depuis une charge de travail ou un namespace en utilisant le même label :

metadata:
  labels:
    autoscaling.datadoghq.com/profile: cost-optimized-strict-floor

Le corps du modèle accepte les mêmes champs qu’une spécification DatadogPodAutoscaler, moins targetRef (le Cluster Agent le remplit pour chaque charge de travail correspondante). Consultez les exemples de configurations ci-dessus pour connaître la gamme complète des champs que vous pouvez placer sous spec.template.

Priorité d’activation

Le Cluster Agent 7.79.0+ ajoute l’activation au niveau du namespace, le excluded Opt-out, et la règle de priorité entre eux. Sur le Cluster Agent 7.78.0, seule l’étiquette au niveau de la charge de travail est lue — les règles ci-dessous qui impliquent des namespaces ou la valeur excluded ne s’appliquent pas.

• Les étiquettes de charge de travail prévalent sur les étiquettes de namespace. Si un namespace est étiqueté autoscaling.datadoghq.com/profile=ns-profile et qu’une charge de travail à l’intérieur est étiquetée autoscaling.datadoghq.com/profile=workload-profile, la charge de travail utilise workload-profile.

• Opt out with excluded. Définissez autoscaling.datadoghq.com/profile: excluded sur une charge de travail pour l’exempter lorsque son namespace est étiqueté. Ceci est utile pour les charges de travail avec état ou critiques dans un espace de nom par ailleurs activé.

  apiVersion: apps/v1
  kind: StatefulSet
  metadata:
    name: payments-ledger
    namespace: production
    labels:
      autoscaling.datadoghq.com/profile: excluded
  

• Les noms de profil inconnus sont ignorés. Si une charge de travail ou un espace de nom fait référence à un profil qui n’existe pas, le Cluster Agent ne crée pas de DatadogPodAutoscaler géré et ne signale aucune erreur. La réconciliation prend en compte l’affectation dès qu’un profil portant ce nom est créé.

• La réconciliation est automatique. L’ajout, la modification ou la suppression de l’étiquette se propage à un DatadogPodAutoscaler géré en quelques secondes.

Types de charges de travail pris en charge

L’activation de profil prend en charge Deployment et StatefulSet. Pour d’autres types (par exemple, Argo Rollout), utilisez Path B : GitOps pour créer un DatadogPodAutoscaler directement.

Déployer les recommandations manuellement

Si vous souhaitez obtenir les recommandations de Datadog sans activer la mise à l’échelle automatique, vous pouvez les appliquer manuellement en une seule fois. Lorsque vous configurez des ressources pour vos déploiements Kubernetes, utilisez les valeurs suggérées dans la recommandation de mise à l’échelle. Vous pouvez également cliquer sur Export Recommendation pour voir une commande générée kubectl patch. Datadog continue d’actualiser la recommandation, mais le cluster ne change que lorsque vous réappliquez.

Gérez les charges de travail à grande échelle

Une fois qu’une charge de travail est mise à l’échelle automatiquement, les opérations du deuxième jour sont gérées via une combinaison de la ressource DatadogPodAutoscaler et de l’interface utilisateur Datadog :

• Modifiez le modèle de mise à l’échelle. Modifiez directement le spec DatadogPodAutoscaler de la charge de travail (CPU target, replica bounds, scale-up and scale-down rules), ou choisissez un modèle différent dans la vue de liste Workload Scaling : Les modifications prennent effet lors de la prochaine réconciliation.
• Mettez en pause la mise à l’échelle automatique sans supprimer la ressource. Définissez applyPolicy.mode: Preview pour garder les recommandations visibles dans .status tout en empêchant le contrôleur de les appliquer. Ceci est utile lors d’une exécution parallèlement à un HPA ou un VPA pendant l’évaluation.
• Surveillez le déploiement. La [vue de liste Workload Scaling] affiche le statut en direct de la recommandation de chaque charge de travail, la dernière action appliquée et toute erreur de réconciliation.
• Supprimez la mise à l’échelle automatique proprement. Supprimez DatadogPodAutoscaler la ressource pour arrêter la mise à l’échelle automatique. Les ressources de pod existantes restent à leurs dernières valeurs appliquées, et la charge de travail revient à ce que son contrôleur parent (Deployment, StatefulSet, etc.) spécifie lors du prochain déploiement.

Référence

Comment les recommandations verticales sont calculées

Datadog calcule les recommandations de mise à l’échelle verticale pour le CPU et la mémoire en analysant les données d’utilisation historique des conteneurs sur les 8 derniers jours. La méthodologie utilisée pour chaque ressource dépend du fait que la demande de cette ressource est égale à sa limite, reflétant le concept de Kubernetes Quality of Service (QoS) class. Le CPU et la mémoire sont évalués indépendamment : une charge de travail peut utiliser la méthodologie Burstable pour le CPU et la méthodologie Guaranteed pour la mémoire, ou vice versa.

Recommandations de mémoire

Burstable (la requête de mémoire est inférieure à la limite de mémoire) :

Guaranteed (la requête de mémoire est égale à la limite de mémoire) :

Remarque : Le suivi du pic de mémoire capture l’utilisation de mémoire la plus élevée jamais enregistrée par tout conteneur ayant existé au cours de la fenêtre de rétrospection de 8 jours. Cela signifie que même si un conteneur a démarré avant cette fenêtre, son utilisation maximale (par exemple, au démarrage) est toujours prise en compte dans la recommandation.

Recommandations de CPU

Burstable (la requête CPU est inférieure à la limite CPU) :

Guaranteed (la demande CPU est égale à la limite CPU) :

Principes de conception clés

• Fenêtre de rétrospection de 8 jours : Toutes les recommandations prennent en compte les données d’utilisation des 8 derniers jours, fournissant suffisamment d’historique pour capturer les modèles de trafic hebdomadaires tout en restant réactif aux changements.
• Pondérations décroissantes : Pour les recommandations de demande de classe Burstable (CPU ou mémoire), les échantillons plus anciens sont moins fortement pondérés, de sorte que la recommandation s’adapte plus rapidement aux changements d’utilisation récents.
• Marges de sécurité : Chaque recommandation inclut une marge au-dessus de l’utilisation observée (5 à 10 %) pour fournir une réserve contre les pics inattendus.
• OOMKill response : Lorsque la mémoire est de type Guaranteed (la demande est égale à la limite) et qu’un OOMKill se produit, une augmentation de 20 % est appliquée pour réduire la probabilité de pannes de mémoire répétées.
• Guaranteed-class preservation : Lorsqu’une ressource a une demande égale à la limite, Datadog utilise le calcul le plus conservateur (au niveau de la limite) pour les deux, garantissant que les recommandations n’introduisent pas d’écart entre la demande et la limite.

Lectures complémentaires

Documentation, liens et articles supplémentaires utiles:

Utilisation des ressources KubernetesDOCUMENTATION Autorisations des rôles DatadogDOCUMENTATION Remote ConfigurationDOCUMENTATION Mise à l'échelle des charges de travail Kubernetes sur des métriques personnaliséesBLOG Optimisez les charges de travail Kubernetes avec Custom Query Scaling.BLOG Centralisez et gérez votre pipeline OpenTelemetry avec la passerelle DDOTBLOG Dimensionnez correctement vos charges de travail et réduisez vos coûts avec Datadog Kubernetes Autoscaling.BLOG Mise à l'échelle automatique des charges de travail Kubernetes avec DatadogCENTRE D'ARCHITECTURE