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.
There are a number of different ways to monitor your Kubernetes system using Datadog. Choosing one depends on how your system is structured and the type of monitoring you desire. There are four options for installing the Datadog Agent for Kubernetes: DaemonSets, Helm charts, installing the Agent directly on the host, and the Datadog Cluster Agent.
To gather metrics, traces, and logs from your Kubernetes clusters, there are four options:
Note: Only one Datadog Agent should run on each node; a sidecar per pod 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:
datadogtokento update and query the most up-to-date version token corresponding to the latest event stored in ETCD.
Eventsto pull the events from the API Server, format, and submit them.
Endpoint. The Endpoint used by the Agent for the Leader election feature is named
componentstatusesresource, 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.
For details on the usage of ConfigMaps in Kubernetes, consult Datadog’s Kubernetes Custom Integrations documentation.