Datadog Agent Host‑Path Docker Socket vs Kubernetes Cluster Agent Integration in Production

The goal is to maintain continuous collection of container metrics and logs from a Datadog Agent when moving from a local development cluster to a production Kubernetes environment that enforces strict security policies.

In local setups the Agent runs with privileged=true and mounts the node’s /var/run/docker.sock via a hostPath, allowing it to observe Docker events and read pod annotations such as ad.datadoghq.com/.logs for autodiscovery.

Production clusters frequently prohibit privileged containers and hostPath mounts through PodSecurityPolicies or OPA/Gatekeeper, and admission controllers may strip or alter those annotations, causing the Agent to lose visibility without clear error messages.

An unresolved decision is whether to replace the host‑socket approach with the Datadog Cluster Agent and Node Agent, which operate without privileged mode but require additional RBAC configuration and may not fully replicate the original discovery mechanism for existing custom checks.

Does removing privileged mode and hostPath mounts prevent the Agent from discovering Docker containers? Can the Cluster Agent and Node Agent fully replace host‑socket based autodiscovery for logs and metrics? What RBAC permissions are needed for the Node Agent to access pod annotations without interference from admission controllers?