Configuration des live containers

Ressources Kubernetes

L’Agent Datadog et l’Agent de cluster peuvent être configurés afin de récupérer des ressources Kubernetes pour des live containers. Une telle configuration vous permet de surveiller l’état de vos pods, déploiements et autres entités Kubernetes dans un espace de nommage ou une zone de disponibilité spécifique. Cela vous permet également de consulter les spécifications de ressources pour les échecs de pods d’un déploiement ou encore de mettre en corrélation l’activité d’un nœud avec les logs associés.

Avant d’effectuer les configurations ci-dessous pour les ressources Kubernetes des live containers, il est nécessaire d’installer au minimum la version 7.27.0 de l’Agent ainsi que la version 1.11.0 de l’Agent de cluster.

Si vous utilisez le chart Helm Datadog officiel :

  • Utilisez au minimum la version 2.10.0 du chart. Remarque : assurez-vous que la version minimale ou une version ultérieure de l’Agent et de l’Agent de cluster est codée en dur dans le fichier values.yaml de votre chart Helm.

  • Vérifiez que l’Agent de processus est activé. Pour ce faire, modifiez le fichier datadog-values.yaml afin d’inclure ce qui suit :

    datadog:
        # (...)
        processAgent:
            enabled: true
    
  • Déployez une nouvelle version.

Dans certaines configurations, il arrive que l’Agent de processus et l’Agent de cluster ne parviennent pas à détecter automatiquement un nom de cluster Kubernetes. Lorsque c’est le cas, la fonctionnalité ne démarre pas et l’avertissement suivant s’affiche dans le log de l’Agent de cluster : Orchestrator explorer enabled but no cluster name set: disabling. Vous devez alors définir datadog.clusterName sur le nom de votre cluster dans values.yaml.

La version 1.11.0 ou une version ultérieure de l’Agent de cluster est requise pour commencer la configuration du DaemonSet. L’Agent de cluster doit être en cours d’exécution et l’Agent doit pouvoir communiquer avec celui-ci. Consultez la section Configuration de l’Agent de cluster pour en savoir plus.

  1. Définissez le conteneur de l’Agent de cluster à l’aide de la variable d’environnement suivante :

      - name: DD_ORCHESTRATOR_EXPLORER_ENABLED
        value: "true"
    
  2. Définissez le ClusterRole de l’Agent de cluster à l’aide des autorisations RBAC suivantes.

    Notez bien que pour les apiGroups apps et batch, les live containers ont besoin d’autorisations pour recueillir des ressources Kubernetes de base (pods, services, nodes, etc.). Elles devraient déjà se trouver dans le RBAC si vous avez suivi la documentation relative à la configuration de l’Agent de cluster. Si elles sont absentes, prenez soin de les ajouter (après deployments, replicasets) :

      ClusterRole:
      - apiGroups:  # To create the datadog-cluster-id ConfigMap
        - ""
        resources:
        - configmaps
        verbs:
        - create
        - get
        - update
      ...
      - apiGroups:  # Required to get the kube-system namespace UID and generate a cluster ID
        - ""
        resources:
        - namespaces
        verbs:
        - get
      ...
      - apiGroups:  # To collect new resource types
        - "apps"
        resources:
        - deployments
        - replicasets
        verbs:
        - list
        - get
        - watch
      - apiGroups:
        - "batch"
        resources:
        - cronjobs
        - jobs
        verbs:
        - list
        - get
        - watch
      ...
    

    Ces autorisations sont requises pour créer une ConfigMap datadog-cluster-id dans le même espace de nommage que le DaemonSet de l’Agent et le déploiement de l’Agent de cluster, mais également pour recueillir les ressources Kubernetes prises en charge.

    Si la ConfigMap cluster-id n’est pas créée par l’Agent de cluster, le pod de l’Agent ne peut pas recueillir de ressources. Pour y remédier, modifiez les autorisations de l’Agent de cluster et redémarrez son pod afin qu’il puisse créer la ConfigMap, puis redémarrez le pod de l’Agent.

  3. L’Agent de processus, qui s’exécute dans le DaemonSet de l’Agent, doit être activé et en cours d’exécution. La collecte de processus ne doit pas forcément être en cours. Les options suivantes doivent également être configurées :

    - name: DD_ORCHESTRATOR_EXPLORER_ENABLED
      value: "true"
    

Dans certaines configurations, il arrive que l’Agent de processus et l’Agent de cluster ne parviennent pas à détecter automatiquement un nom de cluster Kubernetes. Lorsque c’est le cas, la fonctionnalité ne démarre pas et l’avertissement suivant s’affiche dans le log de l’Agent de cluster : Orchestrator explorer enabled but no cluster name set: disabling. Vous devez alors définir ajouter les options suivantes dans la section env de l’Agent de cluster et de l’Agent de processus :

- name: DD_CLUSTER_NAME
  value: "<NOM_CLUSTER>"

Matrice de compatibilité de la collecte de ressources

Le tableau suivant présente la liste des ressources recueillies et des versions minimales de l’Agent, l’Agent de cluster et du chart Helm requises pour la collecte.

RessourceVersion minimale de l’AgentVersion minimale de l’Agent de clusterVersion minimale du chart Helm
ClusterRoleBindings7.27.01.19.02.30.9
ClusterRoles7.27.01.19.02.30.9
Clusters7.27.01.12.02.10.0
CronJobs7.27.01.13.12.15.5
DaemonSets7.27.01.14.02.16.3
Déploiements7.27.01.11.02.10.0
Tâches7.27.01.13.12.15.5
Nœuds7.27.01.11.02.10.0
PersistentVolumes7.27.01.18.02.30.4
PersistentVolumeClaims7.27.01.18.02.30.4
Pods7.27.01.11.02.10.0
ReplicaSets7.27.01.11.02.10.0
RoleBindings7.27.01.19.02.30.9
Roles7.27.01.19.02.30.9
ServiceAccounts7.27.01.19.02.30.9
Services7.27.01.11.02.10.0
Statefulsets7.27.01.15.02.20.1

Instructions pour les versions précédentes de l’Agent et de l’Agent de cluster

La vue des ressources Kubernetes pour les live containers nécessitait auparavant au minimum la version 7.21.1 de l’Agent et la version 1.9.0 de l’Agent de cluster. Les versions minimales ont cependant été mises à jour. Pour ces anciennes versions, la configuration de DaemonSet impliquait un processus légèrement différent. Par souci de commodité, les instructions sur ce processus sont indiquées ci-dessous.

Si vous utilisez le chart Helm Datadog officiel :

  • Utilisez une version du chart ultérieure à 2.10.0 et antérieure à 2.4.5. SI vous utilisez la version 2.10.0 ou une version ultérieure, consultez plutôt les dernières instructions de configuration. Remarque : assurez-vous que les versions de l’Agent et de l’Agent de cluster sont codées en dur, avec les versions minimales requises, dans le fichier values.yaml de votre chart Helm.
  • Définissez datadog.orchestratorExplorer.enabled sur true dans values.yaml.
  • Déployez une nouvelle version.

Dans certaines configurations, il arrive que l’Agent de processus et l’Agent de cluster ne parviennent pas à détecter automatiquement un nom de cluster Kubernetes. Lorsque c’est le cas, la fonctionnalité ne démarre pas et l’avertissement suivant s’affiche dans le log de l’Agent de cluster : Orchestrator explorer enabled but no cluster name set: disabling. Vous devez alors définir datadog.clusterName sur le nom de votre cluster dans values.yaml.

L’Agent de cluster doit être en cours d’exécution et l’Agent doit pouvoir communiquer avec celui-ci. Consultez la section Configuration de l’Agent de cluster pour en savoir plus.

  1. Définissez le conteneur de l’Agent de cluster à l’aide de la variable d’environnement suivante :

      - name: DD_ORCHESTRATOR_EXPLORER_ENABLED
        value: "true"
    
  2. Définissez le ClusterRole de l’Agent de cluster à l’aide des autorisations RBAC suivantes.

    Remarque : pour les apiGroups apps, les live containers ont besoin d’autorisations pour recueillir des ressources Kubernetes de base (pods, services, nodes, etc.). Elles devraient déjà se trouver dans le RBAC si vous avez suivi la documentation relative à la configuration de l’Agent de cluster. Si elles sont absentes, prenez soin de les ajouter (après deployments, replicasets) :

      ClusterRole:
      - apiGroups:  # To create the datadog-cluster-id ConfigMap
        - ""
        resources:
        - configmaps
        verbs:
        - create
        - get
        - update
      ...
      - apiGroups:  # Required to get the kube-system namespace UID and generate a cluster ID
        - ""
        resources:
        - namespaces
        verbs:
        - get
      ...
      - apiGroups:  # To collect new resource types
        - "apps"
        resources:
        - deployments
        - replicasets
        - daemonsets
        - statefulsets
        verbs:
        - list
        - get
        - watch
    

    Ces autorisations sont requises pour créer une ConfigMap datadog-cluster-id dans le même espace de nommage que le DaemonSet de l’Agent et le déploiement de l’Agent de cluster, mais également pour recueillir les déploiements et les ReplicaSets.

    Si la ConfigMap cluster-id n’est pas créée par l’Agent de cluster, le pod de l’Agent n’est pas initié et génère le statut CreateContainerConfigError. Si le pod de l’Agent est bloqué par l’absence de la ConfigMap, modifiez les autorisations de l’Agent de cluster et redémarrez ses pods pour permettre la création de la ConfigMap. Le pod de l’Agent récupérera automatiquement un statut normal.

  3. L’Agent de processus, qui s’exécute dans le DaemonSet de l’Agent, doit être activé et en cours d’exécution. La collecte de processus ne doit pas forcément être en cours. Les options suivantes doivent également être configurées :

    - name: DD_ORCHESTRATOR_EXPLORER_ENABLED
      value: "true"
    - name: DD_ORCHESTRATOR_CLUSTER_ID
      valueFrom:
        configMapKeyRef:
          name: datadog-cluster-id
          key: id
    

Dans certaines configurations, il arrive que l’Agent de processus et l’Agent de cluster ne parviennent pas à détecter automatiquement un nom de cluster Kubernetes. Lorsque c’est le cas, la fonctionnalité ne démarre pas et l’avertissement suivant s’affiche dans le log de l’Agent de cluster : Orchestrator explorer enabled but no cluster name set: disabling. Vous devez alors définir ajouter les options suivantes dans la section env de l’Agent de cluster et de l’Agent de processus :

- name: DD_CLUSTER_NAME
  value: "<NOM_CLUSTER>"

Ajouter des tags personnalisés aux ressources

Vous pouvez ajouter des tags personnalisés aux ressources Kubernetes afin de faciliter le filtrage de la vue des ressources Kubernetes.

Des tags supplémentaires sont ajoutés via la variable d’environnement DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS.

Remarque : ces tags s’affichent uniquement dans la vue des ressources Kubernetes.

SI vous utilisez le chart Helm officiel, ajoutez la variable d’environnement à l’Agent de processus et à l’Agent de cluster en définissant respectivement agents.containers.processAgent.env et clusterAgent.env dans values.yaml.

  agents:
    containers:
      processAgent:
        env:
          - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
            value: "tag1:value1 tag2:value2"
  clusterAgent:
    env:
      - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
        value: "tag1:value1 tag2:value2"

Déployez ensuite une nouvelle version.

Définissez la variable d’environnement sur les conteneurs de l’Agent de processus et de l’Agent de cluster :

- name: DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS
  value: "tag1:value1 tag2:value2"

Inclure ou exclure des conteneurs

Il est possible d’inclure et/ou d’exclure des conteneurs pour la collecte en temps réel :

  • Pour exclure des conteneurs, passez la variable d’environnement DD_CONTAINER_EXCLUDE ou ajoutez container_exclude: dans le fichier de configuration principal datadog.yaml.
  • Pour inclure des conteneurs, passez la variable d’environnement DD_CONTAINER_INCLUDE ou ajoutez container_include: dans le fichier de configuration principal datadog.yaml.

Ces deux arguments ont pour valeur un nom d’image. Les expressions régulières sont également prises en charge.

Par exemple, pour exclure toutes les images Debian à l’exception des conteneurs dont le nom commence par frontend, ajoutez les deux lignes de configuration suivantes dans votre fichier datadog.yaml :

container_exclude: ["image:debian"]
container_include: ["name:frontend.*"]

Remarque : pour la version 5 de l’Agent, au lieu d’ajouter les lignes ci-dessus dans le fichier de configuration principal datadog.conf, ajoutez explicitement un fichier datadog.yaml dans /etc/datadog-agent/. En effet, l’Agent de processus exige que toutes les options de configuration se trouvent à cet emplacement. Cette configuration exclut uniquement les conteneurs de la collecte en temps réel, et non de la fonction Autodiscovery.

Nettoyage d’informations sensibles

Pour éviter toute fuite de données sensibles, vous pouvez nettoyer des termes sensibles dans les fichiers YAML des conteneurs. Le nettoyage de conteneur est activé par défaut pour les charts Helm. Plusieurs termes sensibles sont fournis par défaut :

  • password
  • passwd
  • mysql_pwd
  • access_token
  • auth_token
  • api_key
  • apikey
  • pwd
  • secret
  • credentials
  • stripetoken

Vous pouvez définir des termes sensibles supplémentaires en fournissant une liste de termes via la variable d’environnement DD_ORCHESTRATOR_EXPLORER_CUSTOM_SENSITIVE_WORDS. Ces termes viennent s’ajouter aux termes par défaut et ne les écrasent pas.

Remarque : les termes sensibles supplémentaires ne doivent pas inclure de majuscules, car l’Agent compare le texte au pattern en minuscules. Cela signifie que le terme password remplace MY_PASSWORD par MY_*******, tandis que le terme PASSWORD ne nettoie aucune donnée.

Vous devez configurer cette variable d’environnement pour les Agents suivants :

  • process-agent
  • cluster-agent
env:
    - name: DD_ORCHESTRATOR_EXPLORER_CUSTOM_SENSITIVE_WORDS
      value: "customword1 customword2 customword3"

Par exemple, puisque password est un terme sensible, la fonctionnalité de nettoyage remplace toutes les occurrences de <MY_PASSWORD> ci-dessous par la chaîne d’astérisques *********** :

password <MY_PASSWORD>
password=<MY_PASSWORD>
password: <MY_PASSWORD>
password::::== <MY_PASSWORD>

Les chemins contenant des termes sensibles ne sont toutefois pas modifiés. Par exemple, le chemin /etc/vaultd/secret/haproxy-crt.pem n’est pas remplacé par /etc/vaultd/******/haproxy-crt.pem, même si secret est un terme sensible.

Pour aller plus loin