Join us at the Dash conference! July 16-17, NYC


Note: Agent version 6.0 and above only support versions of Kubernetes higher than 1.7.6. For prior versions of Kubernetes, consult the Legacy Kubernetes versions section.


To gather metrics, traces, and logs from your Kubernetes clusters, there are two options:

  1. Container installation (recommended) - The Agent runs inside a Pod. This implementation is sufficient for the majority of use cases, but note that it does not grant visibility into components of the system that exist outside Kubernetes. This method also does not monitor the starting phase of your Kubernetes cluster.
  2. Host installation (optional) - Installing the Agent on the host provides additional visibility into your ecosystem, independent of Kubernetes.

Note: Only one Datadog Agent shound run on each node; a sidecar per node is not generally recommended and may not function as expected.


In the context of using the Kubernetes integration, and when deploying Agents in a Kubernetes cluster, a set of rights are required for the Agent to integrate seamlessly.

You must allow the Agent to perform a few actions:

  • get and update the Configmaps named datadogtoken to update and query the most up-to-date version token corresponding to the latest event stored in ETCD.
  • list and watch the Events to pull the events from the API Server, format, and submit them.
  • get, update, and create for the Endpoint. The Endpoint used by the Agent for the Leader election feature is named datadog-leader-election.
  • list the componentstatuses resource, in order to submit service checks for the Control Plane’s components status.

You can find the templates in manifests/rbac in the datadog-agent GitHub repository. This creates a Service Account in the default namespace, a Cluster Role with the above rights, and a Cluster Role Binding.

Custom Integrations

For details on the usage of ConfigMaps in Kubernetes, consult Datadog’s Kubernetes Custom Integrations documentation.


Further Reading