Si vous déployez le Datadog Agent à l’aide du chart Helm v2.7.0+ ou de Datadog Operator v0.7.0+, l’Agent de cluster est désactivé par défaut.

Depuis la version 1.0.0 du Datadog Operator, l’Agent de cluster est activé par défaut. L’Operator crée les autorisations RBAC requises, déploie l’Agent de cluster et modifie la configuration du DaemonSet de l’Agent.

Cela génère également automatiquement un jeton aléatoire dans un Secret partagé par le Cluster Agent et le Datadog Agent pour sécuriser la communication. Vous pouvez spécifier manuellement ce jeton en définissant le champ global.clusterAgentToken. Vous pouvez également le définir en référençant le nom d’un Secret existant et la clé de données contenant ce jeton.

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <DATADOG_API_KEY>
    clusterAgentTokenSecret:
      secretName: <SECRET_NAME>
      keyName: <KEY_NAME>

Lorsqu’il est défini manuellement, ce jeton doit comporter 32 caractères alphanumériques.

Depuis la version 2.7.0 du chart Helm, l’Agent de cluster est activé par défaut.

Pour l’activer sur des versions antérieures, ou si vous utilisez un fichier datadog-values.yaml personnalisé qui remplace la clé clusterAgent, mettez à jour votre fichier datadog-values.yaml avec la configuration suivante du Cluster Agent :

clusterAgent:
  # clusterAgent.enabled -- Set this to false to disable Datadog Cluster Agent
  enabled: true

Mettez ensuite à niveau votre chart Helm Datadog :

Cela met automatiquement à jour les fichiers RBAC nécessaires pour le Cluster Agent et le Datadog Agent. Les deux agents utilisent la même clé d’API.

Cela génère également automatiquement un jeton aléatoire dans un Secret partagé par le Cluster Agent et le Datadog Agent pour sécuriser la communication. Vous pouvez spécifier manuellement ce jeton en utilisant la configuration clusterAgent.token. Vous pouvez également le définir en référençant le nom d’un Secret existant contenant une valeur token via la configuration clusterAgent.tokenExistingSecret.

Lorsqu’il est défini manuellement, ce jeton doit comporter 32 caractères alphanumériques.

Pour configurer l’Agent de cluster Datadog avec un DaemonSet, procédez comme suit :

  1. Configurez les autorisations RBAC du Cluster Agent.
  2. Sécurisez la communication entre le Cluster Agent et l’Agent.
  3. Créez le Cluster Agent et son service.
  4. Configurez l’Agent de nœud pour communiquer avec le Cluster Agent.

Configurez les autorisations RBAC du Cluster Agent

L’Agent de cluster Datadog a besoin d’une autorisation RBAC adéquate pour être opérationnel :

  1. Examinez les manifestes dans le dossier RBAC de l’Agent de cluster Datadog. Remarque : Lorsque vous utilisez le Cluster Agent, vos node Agents ne peuvent pas interagir avec le serveur d’API Kubernetes — seul le Cluster Agent peut le faire.

  2. Pour configurer les autorisations RBAC du Cluster Agent, appliquez les manifestes suivants. (Vous l’avez peut-être déjà fait lors de la configuration du node Agent daemonset.)

kubectl apply -f "https://raw.githubusercontent.com/DataDog/datadog-agent/master/Dockerfiles/manifests/cluster-agent/rbac.yaml"
kubectl apply -f "https://raw.githubusercontent.com/DataDog/datadog-agent/master/Dockerfiles/manifests/cluster-agent/cluster-agent-rbac.yaml"

Ceci crée les ServiceAccount, ClusterRole et ClusterRoleBinding appropriés pour le Cluster Agent et met à jour le ClusterRole pour le node Agent.

Si vous utilisez Azure Kubernetes Service (AKS), vous pourriez avoir besoin d’autorisations supplémentaires. Consultez la FAQ RBAC pour DCA sur AKS.

Sécurisez la communication entre le Cluster Agent et le Datadog Agent

Le Datadog Agent et le Cluster Agent nécessitent un jeton pour sécuriser leur communication. Il est recommandé d’enregistrer ce jeton dans un Secret auquel le Datadog Agent et le Cluster Agent peuvent faire référence dans la variable d’environnement DD_CLUSTER_AGENT_AUTH_TOKEN. Cela permet de maintenir la cohérence et d’éviter que le jeton ne soit lisible dans le PodSpec.

Pour créer ce jeton, exécutez cette commande d’une ligne afin de générer un Secret nommé datadog-cluster-agent avec une token définie. Remplacez le <TOKEN> par 32 caractères alphanumériques.

kubectl create secret generic datadog-cluster-agent --from-literal=token='<TOKEN>' --namespace="default"

Remarque : Ceci crée un Secret dans l’espace de nom par défaut. Si vous utilisez un espace de nom personnalisé, mettez à jour le paramètre d’espace de nom de la commande avant de l’exécuter.

Le cluster-agent-deployment.yaml par défaut fourni pour le Cluster Agent est déjà configuré pour voir ce Secret avec la configuration de variable d’environnement :

- name: DD_CLUSTER_AGENT_AUTH_TOKEN
  valueFrom:
    secretKeyRef:
      name: datadog-cluster-agent
      key: token

Cette variable d’environnement doit être configurée (à l’aide des mêmes options) lors de la configuration du Datadog Agent.

Créez le Cluster Agent et son service

  1. Téléchargez les manifestes suivants :

  2. Dans le manifeste secret-api-key.yaml, remplacez PUT_YOUR_BASE64_ENCODED_API_KEY_HERE par votre clé d’API Datadog encodée en base64. Pour obtenir la version base64 de votre clé d’API, vous pouvez exécuter :

    echo -n '<Your API key>' | base64
    
  3. Dans le manifeste secrets-application-key.yaml, remplacez PUT_YOUR_BASE64_ENCODED_APP_KEY_HERE par votre clé d’application Datadog encodée en base64.

  4. Par défaut, le manifeste cluster-agent-deployment.yaml fait référence au jeton créé précédemment dans le Secret datadog-cluster-agent. Si vous stockez ce jeton d’une autre manière, configurez votre variable d’environnement DD_CLUSTER_AGENT_AUTH_TOKEN en conséquence.

  5. Déployez ces ressources pour que le déploiement du Cluster Agent puisse les utiliser :

    kubectl apply -f agent-services.yaml
    kubectl apply -f secret-api-key.yaml
    kubectl apply -f secret-application-key.yaml
    kubectl apply -f install_info-configmap.yaml
    
  6. Enfin, déployez le Datadog Cluster Agent :

    kubectl apply -f cluster-agent-deployment.yaml
    

Remarque : Dans votre Datadog Cluster Agent, définissez la variable d’environnement DD_SITE sur votre site Datadog : . La valeur par défaut est le site US datadoghq.com

Vérification

À ce stade, vous devez voir ce qui suit :

kubectl get deploy

NAME                    DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
datadog-cluster-agent   1         1         1            1           1d

kubectl get secret

NAME                    TYPE                                  DATA      AGE
datadog-cluster-agent   Opaque                                1         1d

kubectl get pods -l app=datadog-cluster-agent

datadog-cluster-agent-8568545574-x9tc9   1/1       Running   0          2h

kubectl get service -l app=datadog-cluster-agent

NAME                    TYPE           CLUSTER-IP       EXTERNAL-IP        PORT(S)          AGE
datadog-cluster-agent   ClusterIP      10.100.202.234   none               5005/TCP         1d

Remarque : Si vous exécutez déjà le Datadog Agent, vous devrez peut-être appliquer le manifeste rbac.yaml de l’Agent avant que le Cluster Agent puisse démarrer.

Configurer la communication du Datadog Agent

Modifiez la configuration de votre Datadog Agent de façon à ce qu’il communique avec l’Agent de cluster Datadog.

Dans votre fichier manifeste DaemonSet existant, définissez la variable d’environnement DD_CLUSTER_AGENT_ENABLED sur true. Ensuite, définissez DD_CLUSTER_AGENT_AUTH_TOKEN en utilisant la même syntaxe que celle utilisée dans Sécuriser la communication entre le Cluster Agent et l’Agent.

- name: DD_CLUSTER_AGENT_ENABLED
  value: "true"
- name: DD_CLUSTER_AGENT_AUTH_TOKEN
  valueFrom:
    secretKeyRef:
      name: datadog-cluster-agent
      key: token

Après avoir redéployé votre DaemonSet avec ces configurations en place, le Datadog Agent est en mesure de communiquer avec le Cluster Agent. Vous pouvez consulter le daemonset.yaml manifeste du Cluster Agent fourni pour un exemple complet.

Vérification

Pour vérifier que les pods du Datadog Agent et de l’Agent de cluster sont en cours d’exécution, utilisez la commande suivante :

kubectl get pods | grep agent

Vous devez voir ce qui suit :

datadog-agent-4k9cd                      1/1       Running   0          2h
datadog-agent-4v884                      1/1       Running   0          2h
datadog-agent-9d5bl                      1/1       Running   0          2h
datadog-agent-dtlkg                      1/1       Running   0          2h
datadog-agent-jllww                      1/1       Running   0          2h
datadog-agent-rdgwz                      1/1       Running   0          2h
datadog-agent-x5wk5                      1/1       Running   0          2h
[...]
datadog-cluster-agent-8568545574-x9tc9   1/1       Running   0          2h

Pour vérifier que le Datadog Agent est bien connecté à l’Agent de cluster, consultez la sortie de la commande status de l’Agent.

kubectl exec -it <AGENT_POD_NAME> agent status
[...]
=====================
Datadog Cluster Agent
=====================

  - Datadog Cluster Agent endpoint detected: https://10.104.246.194:5005
  Successfully connected to the Datadog Cluster Agent.
  - Running: 1.11.0+commit.4eadd95

La transmission des événements Kubernetes à votre compte Datadog commence alors. Les métriques pertinentes recueillies par vos Agents se voient assigner le tag correspondant dans les métadonnées de cluster.

Conteneurs Windows

L’Agent de cluster Datadog ne peut être déployé que sur des nœuds Linux.

Pour surveiller les conteneurs Windows, utilisez deux installations du Helm chart dans un cluster mixte. Le premier Helm chart déploie le Datadog Cluster Agent et l’Agent DaemonSet pour les nœuds Linux (avec targetSystem: linux). Le second Helm chart (avec targetSystem: windows) déploie l’Agent uniquement sur les nœuds Windows et se connecte au Cluster Agent existant déployé dans le cadre du premier Helm chart.

Utilisez le fichier datadog-values.yaml suivant pour configurer la communication entre les Agents déployés sur les nœuds Windows et le Cluster Agent.

targetSystem: windows
existingClusterAgent:
  join: true
  serviceName: "<EXISTING_DCA_SECRET_NAME>" # from the first Datadog Helm chart
  tokenSecretName: "<EXISTING_DCA_SERVICE_NAME>" # from the first Datadog Helm chart

# Disable datadogMetrics deployment since it should have been already deployed with the first chart.
datadog-crds:
  crds:
    datadogMetrics: false
# Disable kube-state-metrics deployment
datadog:
  kubeStateMetricsEnabled: false

Pour en savoir plus, consultez la documentation relative au dépannage des problèmes avec les conteneurs Windows.

Surveillance des services gérés AWS

Pour surveiller un service géré AWS comme Amazon Managed Streaming for Apache Kafka (MSK), ElastiCache ou Relational Database Service (RDS), définissez clusterChecksRunner dans votre Helm chart pour créer un Pod avec un rôle IAM attribué via serviceAccountAnnotation. Ensuite, définissez les configurations d’intégration sous clusterAgent.confd.

datadog-values.yaml

clusterChecksRunner:
  enabled: true
  rbac:
    # clusterChecksRunner.rbac.create -- If true, create & use RBAC resources
    create: true
    dedicated: true
    serviceAccountAnnotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::***************:role/ROLE-NAME-WITH-MSK-READONLY-POLICY
clusterAgent:
  confd:
    amazon_msk.yaml: |-
      cluster_check: true
      instances:
        - cluster_arn: arn:aws:kafka:us-west-2:*************:cluster/gen-kafka/*******-8e12-4fde-a5ce-******-3
          region_name: us-west-2

Pour aller plus loin