[CONTP-1783] Surface DatadogInstrumentation CRD for integration kubernetes setup

aerospike/README.md

@@ -89,6 +89,8 @@ ad.datadoghq.com/<CONTAINER_NAME>.checks: |
   } 
 ```
 
+For supported Kubernetes workloads, you can use a `DatadogInstrumentation` resource instead of pod annotations. Use the same check instance configuration in `spec.config.checks`, set `integration: aerospike`, and set `containerImage` to match the application image. For setup details, see [Configure Autodiscovery with the DatadogInstrumentation CRD][16].
+
 
 ##### Log collection
 
@@ -155,3 +157,4 @@ Need help? Contact [Datadog support][9].
 [13]: https://github.com/DataDog/integrations-core/blob/7.36.x/aerospike/datadog_checks/aerospike/data/conf.yaml.example
 [14]: https://docs.datadoghq.com/containers/docker/integrations/
 [15]: https://docs.datadoghq.com/containers/guide/ad_identifiers/
+[16]: https://docs.datadoghq.com/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/

airflow/README.md

@@ -460,6 +460,8 @@ webserver:
       }
 ```
 
+For supported Kubernetes workloads, you can use a `DatadogInstrumentation` resource instead of pod annotations. Use the same check instance configuration in `spec.config.checks`, set `integration: airflow`, and set `containerImage` to match the application image. For setup details, see [Configure Autodiscovery with the DatadogInstrumentation CRD][28].
+
 Adjust the `ad.datadoghq.com/<CONTAINER_NAME>.checks` annotation accordingly if your container name differs.
 
 ##### Connect Airflow to DogStatsD
@@ -607,4 +609,5 @@ Need help? Contact [Datadog support][11].
 [24]: https://airflow.apache.org/docs/helm-chart/stable/index.html
 [25]: https://airflow.apache.org/docs/apache-airflow-providers-datadog/stable/index.html
 [26]: https://airflow.apache.org/docs/docker-stack/entrypoint.html#installing-additional-requirements
-[27]: https://docs.datadoghq.com/developers/dogstatsd/?tab=cgroups#origin-detection
+[27]: https://docs.datadoghq.com/developers/dogstatsd/?tab=cgroups#origin-detection
+[28]: https://docs.datadoghq.com/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/

apache/README.md

@@ -113,6 +113,8 @@ To configure this check for an Agent running on Kubernetes:
 
 Set [Autodiscovery Integrations Templates][10] as pod annotations on your application container. Aside from this, templates can also be configured with [a file, a configmap, or a key-value store][11].
 
+For supported Kubernetes workloads, you can use a `DatadogInstrumentation` resource instead of pod annotations. Use the same check instance configuration in `spec.config.checks`, set `integration: apache`, and set `containerImage` to match the application image. For setup details, see [Configure Autodiscovery with the DatadogInstrumentation CRD][23].
+
 **Annotations v1** (for Datadog Agent < v7.36)
 
 ```yaml
@@ -284,3 +286,4 @@ Additional helpful documentation, links, and articles:
 [20]: https://www.datadoghq.com/blog/monitoring-apache-web-server-performance
 [21]: https://www.datadoghq.com/blog/collect-apache-performance-metrics
 [22]: https://www.datadoghq.com/blog/monitor-apache-web-server-datadog
+[23]: https://docs.datadoghq.com/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/

argo_rollouts/README.md

@@ -20,6 +20,8 @@ This check uses [OpenMetrics][5] to collect metrics from the OpenMetrics endpoin
 
 The Argo Rollouts controller has Prometheus-formatted metrics readily available at `/metrics` on port `8090`. For the Agent to start collecting metrics, the Argo Rollouts pods need to be annotated. For more information about annotations, refer to the [Autodiscovery Integration Templates][3] for guidance. You can find additional configuration options by reviewing the [sample argo_rollouts.d/conf.yaml][4].
 
+For supported Kubernetes workloads, you can use a `DatadogInstrumentation` resource instead of pod annotations. Use the same check instance configuration in `spec.config.checks`, set `integration: argo_rollouts`, and set `containerImage` to match the application image. For setup details, see [Configure Autodiscovery with the DatadogInstrumentation CRD][12].
+
 **Note**: The listed metrics can only be collected if they are available. Some metrics are generated only when certain actions are performed. For example, the `argo_rollouts.info.replicas.updated` metric is exposed only after a replica is updated.
 
 The only parameter required for configuring the Argo Rollouts check is:
@@ -101,3 +103,4 @@ Additional helpful documentation, links, and articles:
 [9]: https://docs.datadoghq.com/help/
 [10]: https://docs.datadoghq.com/agent/kubernetes/log/
 [11]: https://www.datadoghq.com/blog/container-native-ci-cd-integrations/
+[12]: https://docs.datadoghq.com/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/

argo_workflows/README.md

@@ -20,6 +20,8 @@ This check uses [OpenMetrics][5] to collect metrics from the OpenMetrics endpoin
 
 The Argo Workflows Workflow Controller has [Prometheus-formatted metrics][11] available at `/metrics` on port `9090`. For the Agent to start collecting metrics, the Workflow Controller pod needs to be annotated. For more information about annotations, refer to the [Autodiscovery Integration Templates][3] for guidance. You can find additional configuration options by reviewing the [sample argo_workflows.d/conf.yaml][4].
 
+For supported Kubernetes workloads, you can use a `DatadogInstrumentation` resource instead of pod annotations. Use the same check instance configuration in `spec.config.checks`, set `integration: argo_workflows`, and set `containerImage` to match the application image. For setup details, see [Configure Autodiscovery with the DatadogInstrumentation CRD][13].
+
 The only parameter required for configuring the Argo Workflows check is:
 - `openmetrics_endpoint`: This parameter should be set to the location where the Prometheus-formatted metrics are exposed. The default port is `9090`. In containerized environments, `%%host%%` should be used for [host autodetection][3].
 
@@ -100,3 +102,4 @@ Additional helpful documentation, links, and articles:
 [10]: https://docs.datadoghq.com/agent/kubernetes/log/
 [11]: https://argo-workflows.readthedocs.io/en/stable/metrics/
 [12]: https://www.datadoghq.com/blog/container-native-ci-cd-integrations/
+[13]: https://docs.datadoghq.com/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/

argocd/README.md

@@ -31,6 +31,8 @@ The Datadog Agent can collect the exposed metrics using this integration. Follow
 
 Ensure that the Prometheus-formatted metrics are exposed in your Argo CD cluster. This is enabled by default if using Argo CD's [default manifests][10]. For the Agent to gather all metrics, each of the three aforementioned components needs to be annotated. For more information about annotations, see the [Autodiscovery Integration Templates][4] for guidance. Additional configuration options are available by reviewing the [sample argocd.d/conf.yaml][12].
 
+For supported Kubernetes workloads, you can use a `DatadogInstrumentation` resource instead of pod annotations. Create one `DatadogInstrumentation` resource per target workload, use the same check instance configuration in `spec.config.checks`, set `integration: argocd`, and set `containerImage` to match each component image. For setup details, see [Configure Autodiscovery with the DatadogInstrumentation CRD][17].
+
 There are use cases where Argo CD Applications contain labels that need to be exposed as Prometheus metrics. These labels are available using the `argocd_app_labels` metric, which is disabled on the Application Controller by default. Refer to the [ArgoCD Documentation][14] for instructions on how to enable it.
 
 Example configurations:
@@ -206,4 +208,4 @@ Additional helpful documentation, links, and articles:
 [14]: https://argo-cd.readthedocs.io/en/stable/operator-manual/metrics/#exposing-application-labels-as-prometheus-metrics
 [15]: https://github.com/DataDog/integrations-core/blob/master/argocd/datadog_checks/argocd/data/conf.yaml.example#L45-L72
 [16]: https://www.datadoghq.com/blog/container-native-ci-cd-integrations/
-
+[17]: https://docs.datadoghq.com/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/

calico/README.md

@@ -45,6 +45,8 @@ Using annotations:
        [....]
    ```
 
+   For a Prometheus pod managed by a supported Kubernetes workload, you can use a `DatadogInstrumentation` resource instead of pod annotations. Use the same check instance configuration in `spec.config.checks`, set `integration: openmetrics`, and set `containerImage` to match the Prometheus pod image. For setup details, see [Configure Autodiscovery with the DatadogInstrumentation CRD][16].
+
 You can find values for `<FELIX-SERVICE-IP>` and `<FELIX-SERVICE-PORT>` by running `kubectl get all -all-namespaces`.
 
 #### Installation with an OS-based Agent
@@ -162,3 +164,4 @@ Additional helpful documentation, links, and articles:
 [13]: https://docs.datadoghq.com/agent/docker/integrations/?tab=docker
 [14]: https://docs.datadoghq.com/agent/kubernetes/log/?tab=containerinstallation#setup
 [15]: https://www.datadoghq.com/blog/monitor-calico-with-datadog/
+[16]: https://docs.datadoghq.com/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/

coredns/README.md

@@ -69,6 +69,8 @@ To configure this check for an Agent running on Kubernetes:
 
 Set [Autodiscovery Integrations Templates][5] as pod annotations on your application container. Alternatively, you can configure templates with a [file, configmap, or key-value store][6].
 
+For supported Kubernetes workloads, you can use a `DatadogInstrumentation` resource instead of pod annotations. Use the same check instance configuration in `spec.config.checks`, set `integration: coredns`, and set `containerImage` to match the application image. For setup details, see [Configure Autodiscovery with the DatadogInstrumentation CRD][25].
+
 **Annotations v1** (for Datadog Agent < v7.36)
 
 ```yaml
@@ -282,3 +284,4 @@ Additional helpful documentation, links, and articles:
 [22]: https://www.datadoghq.com/blog/coredns-monitoring-tools/
 [23]: https://www.datadoghq.com/blog/monitoring-coredns-with-datadog/
 [24]: https://docs.datadoghq.com/integrations/guide/versions-for-openmetrics-based-integrations
+[25]: https://docs.datadoghq.com/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/

dcgm/README.md

@@ -289,6 +289,8 @@ LABEL "com.datadoghq.ad.instances"='[{"openmetrics_endpoint": "http://%%host%%:9
 
 Set [Autodiscovery Integrations Templates][12] as pod annotations on your application container. Aside from this, templates can also be configured with [a file, a configmap, or a key-value store][11].
 
+For supported Kubernetes workloads, you can use a `DatadogInstrumentation` resource instead of pod annotations. Create one `DatadogInstrumentation` resource per target workload, use the same check instance configuration in `spec.config.checks`, set `integration: dcgm`, and set `containerImage` to match each exporter image. For setup details, see [Configure Autodiscovery with the DatadogInstrumentation CRD][20].
+
 **Annotations v2** (for Datadog Agent v7.47+)
 
 ```yaml
@@ -412,3 +414,4 @@ Additional helpful documentation, links, and articles:
 [17]: https://docs.datadoghq.com/integrations/nvml/#metrics
 [18]: https://docs.datadoghq.com/gpu_monitoring/
 [19]: https://docs.datadoghq.com/gpu_monitoring/setup/?tab=datadogoperator
+[20]: https://docs.datadoghq.com/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/

elastic/README.md

@@ -277,6 +277,8 @@ To configure this check for an Agent running on Kubernetes:
 
 Set [Autodiscovery Integrations Templates][17] as pod annotations on your application container. Aside from this, templates can also be configured with [a file, a configmap, or a key-value store][18].
 
+For supported Kubernetes workloads, you can use a `DatadogInstrumentation` resource instead of pod annotations. Use the same check instance configuration in `spec.config.checks`, set `integration: elastic`, and set `containerImage` to match the application image. For setup details, see [Configure Autodiscovery with the DatadogInstrumentation CRD][31].
+
 **Annotations v1** (for Datadog Agent < v7.36)
 
 ```yaml
@@ -488,3 +490,4 @@ See [service_checks.json][26] for a list of service checks provided by this inte
 [28]: https://www.datadoghq.com/blog/monitor-elasticsearch-performance-metrics
 [29]: https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-put-role.html
 [30]: https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-put-user.html
+[31]: https://docs.datadoghq.com/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/

external_dns/README.md

@@ -32,6 +32,8 @@ metadata:
     ad.datadoghq.com/external-dns.instances: '[{"prometheus_url":"http://%%host%%:7979/metrics", "tags":["externaldns-pod:%%host%%"]}]'
 ```
 
+For supported Kubernetes workloads, you can use a `DatadogInstrumentation` resource instead of pod annotations. Use the same check instance configuration in `spec.config.checks`, set `integration: external_dns`, and set `containerImage` to match the application image. For setup details, see [Configure Autodiscovery with the DatadogInstrumentation CRD][9].
+
 - The `externaldns-pod` tag keeps track of the target DNS pod IP. The other tags are related to the Datadog Agent that is polling the information using the autodiscovery.
 - The autodiscovery annotations are done on the pod. To deploy, add the annotations to the metadata of the template's specification.
 
@@ -65,3 +67,4 @@ Need help? Contact [Datadog support][8].
 [6]: https://github.com/DataDog/integrations-core/blob/master/external_dns/metadata.csv
 [7]: https://github.com/DataDog/integrations-core/blob/master/external_dns/assets/service_checks.json
 [8]: https://docs.datadoghq.com/help/
+[9]: https://docs.datadoghq.com/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/

fluxcd/README.md

@@ -55,6 +55,8 @@ spec:
 # (...)
 ```
 
+For supported Kubernetes workloads, you can use a `DatadogInstrumentation` resource instead of pod annotations. Use the same check instance configuration in `spec.config.checks`, set `integration: fluxcd`, and set `containerImage` to match the application image. For setup details, see [Configure Autodiscovery with the DatadogInstrumentation CRD][14].
+
 #### Log collection
 
 _Available for Agent versions >6.0_
@@ -110,3 +112,4 @@ Additional helpful documentation, links, and articles:
 [11]: https://www.datadoghq.com/blog/container-native-integrations/#cicd-with-flux
 [12]: https://docs.datadoghq.com/agent/kubernetes/log/
 [13]: https://www.datadoghq.com/blog/container-native-ci-cd-integrations/
+[14]: https://docs.datadoghq.com/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/

haproxy/README.md

@@ -122,6 +122,8 @@ spec:
         - name: haproxy
 ```
 
+For supported Kubernetes workloads, you can use a `DatadogInstrumentation` resource instead of pod annotations. Use the same check instance configuration in `spec.config.checks`, set `integration: haproxy`, and set `containerImage` to match the application image. For setup details, see [Configure Autodiscovery with the DatadogInstrumentation CRD][31].
+
 <!-- xxz tab xxx -->
 <!-- xxz tabs xxx -->
 
@@ -435,3 +437,4 @@ Need help? Contact [Datadog support][20].
 [28]: https://github.com/DataDog/integrations-core/blob/0e34b3309cc1371095762bfcaf121b0b45a4e263/haproxy/datadog_checks/haproxy/data/conf.yaml.example#L631
 [29]: https://docs.datadoghq.com/integrations/guide/versions-for-openmetrics-based-integrations
 [30]: https://docs.datadoghq.com/integrations/guide/prometheus-host-collection/
+[31]: https://docs.datadoghq.com/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/

istio/README.md

@@ -90,6 +90,8 @@ This annotation specifies the container `discovery` to match the default contain
 
 The method for applying these annotations varies depending on the [Istio deployment strategy (Istioctl, Helm, Operator)][22] used. Consult the Istio documentation for the proper method to apply these pod annotations. See the [sample istio.d/conf.yaml][8] for all available configuration options.
 
+For supported Kubernetes workloads, you can use a `DatadogInstrumentation` resource instead of pod annotations. Use the same check instance configuration in `spec.config.checks`, set `integration: istio`, and set `containerImage` to match the application image. For setup details, see [Configure Autodiscovery with the DatadogInstrumentation CRD][33].
+
 ##### Ambient mode configuration
 
 Istio ambient mode, generally available in Istio v1.24, replaces sidecar injection with two shared components: the `ztunnel` DaemonSet (L4 zero-trust tunneling) and optional `waypoint` proxies (L7 HTTP/gRPC processing). Set `istio_mode: ambient` and configure one or more of `ztunnel_endpoint`, `waypoint_endpoint`, and `istiod_endpoint` on the same instance. The check scrapes each endpoint that is set. Adjust the URLs in the example below to match your cluster's hostnames and ports.
@@ -309,4 +311,5 @@ Additional helpful documentation, links, and articles:
 [27]: https://istio.io/latest/docs/tasks/observability/logs/access-log/
 [30]: https://docs.datadoghq.com/security/application_security/?source=istio-tile-overview
 [31]: https://docs.datadoghq.com/security/application_security/setup/istio/?source=istio-tile-setup
-[32]: https://www.datadoghq.com/blog/app-api-protection-envoy-istio-nginx-haproxy/
+[32]: https://www.datadoghq.com/blog/app-api-protection-envoy-istio-nginx-haproxy/
+[33]: https://docs.datadoghq.com/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/

karpenter/README.md

@@ -22,6 +22,8 @@ This check uses [OpenMetrics][5] to collect metrics from the OpenMetrics endpoin
 
 Make sure that the Prometheus-formatted metrics are exposed in your Karpenter cluster and on which port. You can configure the port by following the instructions on the [Metrics][10] page in the Karpenter documentation. For the Agent to start collecting metrics, the Karpenter pods need to be annotated. For more information about annotations, refer to the [Autodiscovery Integration Templates][3] for guidance. You can find additional configuration options by reviewing the [sample karpenter.d/conf.yaml][4].
 
+For supported Kubernetes workloads, you can use a `DatadogInstrumentation` resource instead of pod annotations. Use the same check instance configuration in `spec.config.checks`, set `integration: karpenter`, and set `containerImage` to match the application image. For setup details, see [Configure Autodiscovery with the DatadogInstrumentation CRD][13].
+
 **Note**: The listed metrics can only be collected if they are available. Some metrics are generated only when certain actions are performed. For example, the `karpenter.nodes.terminated` metric is exposed only after a node is terminated.
 
 The only parameter required for configuring the Karpenter check is:
@@ -105,3 +107,4 @@ Additional helpful documentation, links, and articles:
 [10]: https://karpenter.sh/docs/reference/metrics/
 [11]: https://docs.datadoghq.com/agent/kubernetes/log/
 [12]: https://www.datadoghq.com/blog/container-native-integrations/#autoscaling-and-resource-utilization-with-karpenter
+[13]: https://docs.datadoghq.com/containers/guide/configure-autodiscovery-with-the-datadoginstrumentation-crd/