Allow disabling Service creation in the Datadog Agent chart

[adlacfqueiro-tech]

Feature Request: Allow disabling Service creation in the Datadog Agent chart

Summary

The Datadog Helm chart always creates a Service for the Agent DaemonSet via the template agent-services.yaml.
There is currently no way to disable this behavior. This limitation makes it difficult to manage deployments that run multiple Datadog Agent DaemonSets in the same Kubernetes cluster.

Problem Description

In our setup, we use Karpenter to manage multiple node pools with different characteristics (e.g., compute-optimized, storage-heavy, GPU nodes, etc.).
For operational and scheduling reasons, we deploy two Datadog Agent DaemonSets in the same cluster - each one targeting a different set of nodes.

However, the Datadog chart automatically creates a Service for each release of the chart. This results in duplicate Services pointing to the same ports and labels, and there is no supported way to disable the Service creation when it’s not needed.

This causes unnecessary duplication and potential confusion for workloads relying on the agent.datadog.svc.cluster.local domain, which is expected to route to the node-local Agent on any node.

Proposed Feature

Add an option in the Datadog Agent chart to disable the creation of the Agent Service.
For example:

datadog:
  agent:
    service:
      enabled: true  # default behavior

or alternatively:

datadog:
  agent:
    createService: true  # default

Then wrap the agent-services.yaml template with a simple conditional such as:

{{- if .Values.datadog.agent.service.enabled }}
---
# existing Service definition
{{- end }}

Benefits

• Prevents duplicate Services when multiple Agent DaemonSets are deployed in the same cluster.
• Enables more flexible deployment models (e.g., multiple node pools with different agent configurations).
• Simplifies cluster management and Service discovery.
• Maintains backward compatibility by keeping Service creation enabled by default.

Additional Context

This enhancement would help teams using multiple node pools or specialized DaemonSet configurations avoid overlapping Services and simplify their deployment topologies.