Document migration from ExtendedDaemonSet

Remove EDS from user-facing feature documentation and describe the supported upgrade sequence: migrate to a native DaemonSet on the last EDS-capable Operator release before upgrading.\n\nCONTP-1895

Author: tbavelier

README.md

@@ -12,14 +12,14 @@
 > [!WARNING]
 > ⚠️ If you are upgrading to **Operator v1.22.0+** from **<v1.18.0** or you haven't migrated Daemonset `matchLabels`, see the [migration guide][19].
 
-
+> [!WARNING]
+> ExtendedDaemonSet support has been removed. Before upgrading from an EDS-capable Operator release, follow the [ExtendedDaemonSet migration guide][21].
 
 The **Datadog Operator** aims to provide a new way of deploying the [Datadog Agent][1] on Kubernetes. Once deployed, the Datadog Operator provides:
 
 - Agent configuration validation that limits configuration mistakes.
 - Orchestration of creating/updating Datadog Agent resources.
 - Reporting of Agent configuration status in its Kubernetes CRD resource.
-- Optionally, use of an advanced `DaemonSet` deployment by leveraging the [ExtendedDaemonSet][2].
 - Many other features to come :).
 
 The **Datadog Operator** is [RedHat certified][10] and available on [operatorhub.io][11].
@@ -75,7 +75,6 @@ See the [deprecated configurations and migration guidelines][17] page.
 See the [How to Contribute page][9].
 
 [1]: https://github.com/DataDog/datadog-agent/
-[2]: https://github.com/DataDog/extendeddaemonset
 [3]: https://github.com/DataDog/helm-charts/tree/main/charts/datadog
 [4]: https://github.com/DataDog/datadog-agent/tree/6.15.0/Dockerfiles/manifests
 [5]: https://github.com/DataDog/datadog-operator/blob/main/docs/getting_started.md
@@ -94,6 +93,7 @@ See the [How to Contribute page][9].
 [18]: https://github.com/DataDog/datadog-operator/blob/main/docs/datadog_agent_profiles.md
 [19]: https://github.com/DataDog/datadog-operator/blob/main/docs/agent_metadata_changes.md
 [20]: https://github.com/DataDog/datadog-operator/blob/main/docs/datadog_agent_internal.md
+[21]: https://github.com/DataDog/datadog-operator/blob/main/docs/extendeddaemonset_migration.md
 
 ## Release
 

docs/data_collected.md

@@ -27,7 +27,6 @@ The OpenMetrics check is enabled by default through Autodiscovery annotations an
 - Create/Update/Delete Service <Namespace/Name>
 - Create/Update/Delete ConfigMap <Namespace/Name>
 - Create/Update/Delete DaemonSet <Namespace/Name>
-- Create/Update/Delete ExtendedDaemonSet <Namespace/Name>
 - Create/Update/Delete Deployment <Namespace/Name>
 - Create/Update/Delete ClusterRole </Name>
 - Create/Update/Delete Role <Namespace/Name>
@@ -40,4 +39,4 @@ The OpenMetrics check is enabled by default through Autodiscovery annotations an
 [1]: https://docs.datadoghq.com/containers/kubernetes/data_collected/
 [2]: https://docs.datadoghq.com/account_management/api-app-keys/
 [3]: https://docs.datadoghq.com/integrations/openmetrics/
-[4]: https://docs.datadoghq.com/containers/kubernetes/integrations/?tab=annotations
+[4]: https://docs.datadoghq.com/containers/kubernetes/integrations/?tab=annotations

docs/datadog_agent_profiles.md

@@ -34,7 +34,7 @@ The DAP spec has two main sections:
 * `profileAffinity` is used to target a subset of nodes. It accepts a list of [NodeSelectorRequirements](https://pkg.go.dev/k8s.io/api/core/v1#NodeSelectorRequirement).
 * `config` defines the configuration to override in the DDA. It follows the configuration formatting of the Operator's [DatadogAgentSpec](https://github.com/DataDog/datadog-operator/blob/98276c56ad824f81be6f75128d230d2c4eda4c0b/apis/datadoghq/v2alpha1/datadogagent_types.go#L28).
 
-When a DAP is applied, the Operator creates a new DaemonSet for that profile using the same name as the DAP. Even if the Operator is configured to use ExtendedDaemonSets, it will still create DaemonSets for any DAPs. It will also create a DaemonSet (or an ExtendedDaemonSet, if enabled) for a default profile. The default profile uses the same name as the DDA and applies to all nodes that are not targeted by a DAP.
+When a DAP is applied, the Operator creates a new DaemonSet for that profile using the same name as the DAP. It also creates a DaemonSet for the default profile. The default profile uses the same name as the DDA and applies to all nodes that are not targeted by a DAP.
 
 ```console
 $ kubectl get ds

docs/extendeddaemonset_migration.md

@@ -0,0 +1,33 @@
+# Migrating from ExtendedDaemonSet
+
+ExtendedDaemonSet support has been removed from the Datadog Operator. The
+Operator now deploys every node Agent with a native Kubernetes DaemonSet and no
+longer installs EDS API types, watches EDS resources, or accepts
+`--supportExtendedDaemonset` and `--eds*` flags.
+
+Do not upgrade directly while the current Operator is managing an
+ExtendedDaemonSet. The new Operator does not read, migrate, or delete existing
+EDS resources.
+
+## Upgrade procedure
+
+1. While running the last EDS-capable Operator release, disable EDS by removing
+   `--supportExtendedDaemonset=true` or setting it to `false`. Remove any
+   `--eds*` options as well.
+2. Wait for that Operator release to migrate the node Agent to a native
+   DaemonSet. Confirm the DaemonSet is fully ready:
+
+   ```shell
+   kubectl -n <agent-namespace> get daemonset
+   kubectl -n <agent-namespace> rollout status daemonset/<agent-name>
+   ```
+
+3. Confirm that no ExtendedDaemonSet or ExtendedDaemonSetReplicaSet remains in
+   the Agent namespace. Do not remove the EDS controller or CRDs until the
+   native DaemonSet is healthy.
+4. Upgrade the Datadog Operator and remove the obsolete EDS controller and CRDs
+   if no other workload uses them.
+
+Custom Operator Deployment manifests must not pass the removed EDS flags. Helm
+or OLM configuration that previously enabled EDS must be updated to render a
+DaemonSet-only Operator deployment before the upgrade.

docs/gke_autopilot/internal.md

@@ -48,7 +48,7 @@ DatadogAgentInternal
   -> build configured/enabled features and required components
   -> manage global and feature dependencies
   -> reconcile Deployment-backed components
-  -> reconcile Node Agent DaemonSet or ExtendedDaemonSet
+  -> reconcile Node Agent DaemonSet
   -> cleanup stale resources
 ```
 

docs/installation.md

@@ -192,12 +192,15 @@ Other operator startup options can also be configured via environment variable:
 | DDGR requeue period        | `--datadogGenericResourceRequeuePeriod` | `DD_GENERIC_RESOURCE_REQUEUE_PERIOD` | `60s`   |
 | Controller revisions       | `--createControllerRevisions`        | `DD_CREATE_CONTROLLER_REVISIONS`      | `false` |
 
-ExtendedDaemonset options (`--supportExtendedDaemonset` and `--eds*`),
-the leader election toggle (`--enable-leader-election`), pprof (`--pprof`),
+The leader election toggle (`--enable-leader-election`), pprof (`--pprof`),
 log options (`--loglevel`, `--logEncoder`), secret backend options
 (`--secretBackend*`, `--secretRefreshInterval`), and `--version` are only
 configurable using CLI flags in the shipped manifests.
 
+ExtendedDaemonSet flags were removed. If they are present in a custom
+Deployment manifest, remove them before upgrading. See the
+[ExtendedDaemonSet migration guide](extendeddaemonset_migration.md).
+
 Boolean values follow Go's [`strconv.ParseBool`](https://pkg.go.dev/strconv#ParseBool):
 `true`, `True`, `TRUE`, `1` or `false`, `False`, `FALSE`, `0`. The strings
 `yes` and `no` are **not** accepted and are logged as errors, leaving the

docs/introspection.md

@@ -101,8 +101,8 @@ override:
 
 ### Operator v1.4.0 <= x < v1.6.0
 
-1. Upgrade to Operator v1.4.0+ **without** enabling introspection. The Operator should label the existing node Agent DaemonSet or ExtendedDaemonSet with the label `agent.datadoghq.com/provider=""`.
-2. Enable introspection in the Operator following the instructions above. The Operator should delete the unused node Agent DaemonSet or ExtendedDaemonSet.
+1. Upgrade to Operator v1.4.0+ **without** enabling introspection. The Operator should label the existing node Agent workload with the label `agent.datadoghq.com/provider=""`.
+2. Enable introspection in the Operator following the instructions above. The Operator should delete the unused node Agent workload.
 
 ### Operator v1.6.0+
 

docs/untaint_controller.md

@@ -101,7 +101,7 @@ env:
 
 When `--untaintControllerEnabled` is enabled, the operator injects a toleration for
 `agent.datadoghq.com/not-ready=presence:NoSchedule` into the node Agent
-DaemonSet (or ExtendedDaemonSet) pod template, unless an equivalent toleration
+DaemonSet pod template, unless an equivalent toleration
 is already present. When **`--untaintControllerWaitForCSIDriver`** is also true **and**
 the DatadogCSIDriver controller is running (`--datadogCSIDriverEnabled=true`), the same
 toleration is injected into the **Datadog CSI node-server** DaemonSet pod

hack/update-golang.sh

@@ -121,7 +121,7 @@ for file in $go_mod_files; do
 done
 
 # api/go.mod stays at initial patch release for the minor Go version: it is a types-only CRD module imported by
-# external projects (Agent, EDS, dd-source autoscaling, ...). A stricter `go`
+# external projects (Agent, dd-source autoscaling, ...). A stricter `go`
 # directive would force consumers off Go n-1 for no real benefit since the
 # module ships no runtime code that could trigger stdlib CVEs.
 api_go_mod="$ROOT/api/go.mod"