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

Short answer

Removing privileged mode and the /var/run/docker.sock hostPath mount does not prevent the Agent from discovering containers — provided you switch discovery from the Docker API to the Kubernetes API. That is exactly what the Cluster Agent + Node Agent architecture does. It fully covers annotation-based autodiscovery for logs and metrics, with one caveat: custom checks that read low-level Docker engine internals (not exposed via the Kubelet) will lose data and must be rewritten or dropped.

What is confirmed vs. what is likely

Confirmed behavior: the Docker socket listener is the only thing that requires the socket mount. Without it, the Agent's Docker-based autodiscovery and docker.* metrics stop. Kubernetes autodiscovery instead reads pod annotations (ad.datadoghq.com/) through the API server, and container metrics come from the Kubelet — neither needs privilege or hostPath.

Likely explanation for your silent visibility loss: the admission controller stripping or rejecting the ad.datadoghq.com/* annotations is the more probable culprit than the Agent itself. The Agent fails quietly when annotations never reach the API server, which matches your symptom of "loses visibility without clear error messages."

RBAC the Node Agent actually needs

The Node Agent's ServiceAccount needs read access to pod metadata. The standard ClusterRole includes:

rules:
- apiGroups: [""]
  resources: ["pods", "nodes", "namespaces", "endpoints", "services"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets", "daemonsets", "statefulsets"]
  verbs: ["get", "list", "watch"]

The Cluster Agent additionally needs permissions for the resources it aggregates (e.g., events, and externalmetrics if you use the metrics adapter). Use the manifests from the Datadog Helm chart as the baseline rather than hand-rolling RBAC.

Dealing with admission controllers

RBAC cannot help if Gatekeeper mutates or strips annotations before pods are created — the Agent reads what the API server stored. You must whitelist the ad.datadoghq.com/ annotation prefix in your OPA/Gatekeeper policy (and any annotation-size or annotation-allowlist rules). Verify with:

kubectl get pod <name> -o jsonpath='{.metadata.annotations}'

If the ad.datadoghq.com/* keys are absent there, the problem is policy, not the Agent.

Verification checklist

• kubectl exec <node-agent> -- agent status — confirm the Kubernetes listener and config provider are active and autodiscovery templates are resolved.
• Check Node Agent logs for autodiscovery events referencing your pods.
• Check Cluster Agent logs for successful metadata sync to Node Agents.
• In the Datadog UI, confirm pod tags and log collection appear for production workloads.

Caveats for review

Exact RBAC resources and Helm values vary by Agent version (7.x assumed here); verify against the chart version you deploy. If any custom check depends on Docker engine stats unavailable through the Kubelet, identify it before cutover — that is the one gap the Cluster Agent pattern does not close.