Datadog Helm Charts

The Datadog Helm repository contains official charts for several products. The following charts are currently supported:

• Datadog Agents: datadog/datadog
• Datadog Operator: datadog/datadog-operator
• Extended DaemonSet: datadog/extendeddaemonset
• Observability Pipelines Worker: datadog/observability-pipelines-worker
• Private Action Runner: datadog/private-action-runner
• Synthetics Private Location: datadog/synthetics-private-location

The Extended DaemonSet (EDS) is a replacement implementation for the standard Kubernetes DaemonSet resource. It provides advanced deployment capabilities that are not available in the default batch/v1 DaemonSet, specifically:

• Canary Deployment: The ability to deploy a new DaemonSet version to only a small subset of nodes to validate changes.
• Custom Rolling Update: Improved rolling update logic compared to the standard Kubernetes implementation.

The Private Location worker requires a configuration file. You can provide this in two ways:

1. Using configFile: Pass a JSON string or a file path via Helm. The chart will automatically create a secret from this content.
2. Using configSecret: If you prefer to manage the secret manually outside of the Helm chart, provide the name of your existing secret in the configSecret field. The secret's data must contain a key named synthetics-check-runner.json.

To successfully migrate from the standalone Datadog Helm chart to the Datadog Operator, the following conditions must be met (defined by the migration-supported helper):

1. Operator Enabled: The migration logic must be active.
2. CRD Version: The cluster must have the DatadogAgent CRD at version v2alpha1 (checked via datadogagents-crd-ready).
3. Operator Version: The Datadog Operator image must be version 1.22.0 or higher.

If these conditions are met, a migration job is triggered based on your configuration.

When adding new logic, conditionals, or helpers to the Datadog chart, prefer simplifying or reusing existing code over creating new files or helpers.

Patterns to avoid:

• Duplicate Helpers: Creating a new helper that duplicates logic already present in an existing one. (Instead: Extend or parameterize the existing helper).
• Duplicated Logic Blocks: Using if/else blocks across multiple templates. (Instead: Extract to a shared named template in _helpers.tpl).
• Redundant Files: Creating a new template file for a feature that could be a conditional block in an existing file. (Instead: Add the block to the existing file with a feature gate).
• Copy-pasted Mappings: Copying env var or volume mount mappings. (Instead: Refactor into a shared partial).

A critical constraint during migration is that your standalone Datadog deployment name must not match the name used by the operator subchart.

The operator subchart uses a deployment name derived from the pattern operator-subchart-deployment-name (which, when aliased as operator, resolves to {{ .Release.Name }}-operator).

If you attempt to migrate using a release name that contains datadog-operator, the chart will issue a warning because the resulting deployment names will collide, causing deployment errors.

By default, the Datadog Operator only watches resources (such as DatadogAgent and DatadogMonitor) that reside in the same namespace as the Operator itself.

You can override this behavior to allow the Operator to manage resources in specific namespaces or across the entire cluster.

Watch specific namespaces

To restrict or expand the Operator's scope to a specific list of namespaces, use the watchNamespaces key:

watchNamespaces:
- "default"
- "datadog"

Watch all namespaces

To configure the Operator to watch all namespaces in the cluster, provide an empty string in the list:

watchNamespaces:
- ""

Before merging, ensure all unit tests pass and verify that any changes to rendered manifests are intentional.

• Run Unit Tests: Use make unit-test-datadog.
• Verify Baselines: Check diffs in test/datadog/baseline/manifests/. If diffs exist, manually inspect the rendered YAML for:
  • Missing required fields (name, containers, selector).
  • Invalid field types.
  • Mismatched label selectors between spec.selector.matchLabels and pod template metadata.labels.
  • Malformed volume or mount definitions.

To use the CloudPrem Helm chart, you must first add the Datadog Helm repository to your local Helm configuration and update it.

helm repo add datadog https://helm.datadoghq.com
helm repo update

If you prefer not to pass the API key via --set, you can create a Kubernetes Secret manually and tell the chart to use it.

Important: When creating the Secret, the key field must be named api-key.

# 1. Create the secret (ensure the key is named 'api-key')
export DATADOG_SECRET_NAME=datadog-secrets
kubectl create secret generic $DATADOG_SECRET_NAME \
    --from-literal api-key="<DD_API_KEY>"

# 2. Install the chart referencing that secret
helm install --name <RELEASE_NAME> \
  --set datadog.apiKeyExistingSecret=$DATADOG_SECRET_NAME \
  datadog/observability-pipelines-worker

After the Datadog Operator is installed and verified, you can safely uninstall the original Datadog Helm chart. The Datadog Agent pods should remain unaffected, and the CRDs will remain on the cluster. The Operator will recreate the Cluster Agent, Cluster Agent service account, and Cluster Checks Runners if they were enabled.

helm uninstall <DATADOG_RELEASE_NAME>