L’Agent de cluster Datadog a besoin des autorisations RBAC adéquates pour fonctionner :
Examinez les manifestes dans le dossier RBAC de l’Agent de cluster Datadog. Notez que lorsque vous utilisez l’Agent de cluster, vos Agents de nœud ne peuvent pas interagir avec le serveur d’API Kubernetes ; seul l’Agent de cluster peut le faire.
Pour configurer les autorisations RBAC de l’Agent de cluster, appliquez les manifestes suivants. Il se peut que vous ayez déjà effectué cette opération lors de la configuration du daemonset de l’Agent de nœud.
Cela permet de créer les objets ServiceAccount, ClusterRole et ClusterRoleBinding appropriés pour l’Agent de cluster, et de mettre à jour l’objet ClusterRole pour l’Agent de nœud.
Si vous utilisez Azure Kubernetes Service (AKS), vous aurez besoin de permissions supplémentaires. Consultez la FAQ dédiée pour les RBAC sur AKS pour le DCA.
Sécuriser les communications entre l’Agent de cluster et l’Agent
Utilisez l’une des options suivantes pour sécuriser les communications entre l’Agent Datadog et l’Agent de cluster Datadog.
Créez un secret et accédez à celui-ci avec une variable d’environnement.
Définissez un token dans une variable d’environnement.
Utilisez une ConfigMap pour gérer vos secrets.
Si vous définissez la valeur sans utiliser de secret, le token est alors lisible dans le PodSpec.
Vous pouvez également modifier la valeur du secret dans le fichier agent-secret.yaml qui se trouve dans le répertoire manifest/cluster-agent ou le créer avec :
Utilisez ce secret avec la variable d’environnement DD_CLUSTER_AGENT_AUTH_TOKEN dans les manifestes de l’Agent de cluster et de l’Agent basé sur des nœuds.
Remarque : dans votre Agent de cluster Datadog, définissez <DD_SITE> sur votre site Datadog : . Valeur par défaut : datadoghq.com.
Vérification
À ce stade, vous devriez voir ce qui suit :
-> kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
datadog-cluster-agent 1111 1d
-> kubectl get secret
NAME TYPE DATA AGE
datadog-agent-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 l’Agent Datadog est déjà exécuté, vous devrez peut-être appliquer le manifeste agent-rbac.yaml pour que l’Agent de cluster puisse s’exécuter.
Configurer l’Agent Datadog
Une fois l’Agent de cluster Datadog configuré, configurez votre Agent Datadog de façon à le faire communiquer avec l’Agent de cluster Datadog.
Configuration
Configurer les autorisations RBAC des Agents basés sur des nœuds
Téléchargez le manifeste agent-rbac.yaml. Remarque : lorsque vous utilisez l’Agent de cluster, vos Agents de nœud ne peuvent pas interagir avec le serveur d’API Kubernetes ; seul l’Agent de cluster peut le faire.
La transmission des événements Kubernetes à votre compte Datadog commence alors. Les métriques pertinentes recueillies par vos Agents se voient assignées le tag correspondant dans les métadonnées de cluster.
Surveillance des services AWS gérés
Pour surveiller un service AWS géré comme MSK, ElastiCache ou RDS, créez un pod avec un rôle IAM attribué via la serviceAccountAnnotation dans le chart Helm.
clusterChecksRunner:enabled:truerbac:# clusterChecksRunner.rbac.create -- Si true, créer et utiliser des ressources RBACcreate:truededicated:trueserviceAccountAnnotations:eks.amazonaws.com/role-arn:arn:aws:iam::***************:role/ROLE-NAME-WITH-MSK-READONLY-POLICYclusterAgent: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
Documentation, liens et articles supplémentaires utiles: