Update kubernetes provider documentation and 8.6 release notes

docs/en/ingest-management/elastic-agent/configuration/autodiscovery/kubernetes-conditions-autodiscover.asciidoc

@@ -37,6 +37,10 @@ To automatically identify a Redis Pod and monitor it with the Redis integration,
 The condition `${kubernetes.labels.app} == 'redis'` will make the {agent} look for a Pod with the  label `app:redis` within the scope defined in its manifest.
 
 For a list of provider fields that you can use in conditions, refer to <<kubernetes-provider>>.
+Some examples of conditions usage are:
+1. For a pod with label `app.kubernetes.io/name=ingress-nginx` the condition should be `condition: ${kubernetes.labels.app.kubernetes.io/name} == "ingress-nginx"`
+2. For a pod with annotation `prometheus.io/scrape: "true"` the condition should be `${kubernetes.annotations.prometheus.io/scrape} == "true"`
+3. For a pod with name `kube-scheduler-kind-control-plane` the condition should be `${kubernetes.pod.name == "kube-scheduler-kind-control-plane"`
 
 
 The `redis` input defined in the {agent} manifest only specifies the`info` metricset. To learn about other available metricsets and their configuration settings, refer to the {metricbeat-ref}/metricbeat-module-redis.html[Redis module page].
@@ -67,7 +71,9 @@ You should now be able to see Redis data flowing in on index `metrics-redis.info
 
 NOTE: All assets (dashboards, ingest pipelines, and so on) related to the Redis integration are not installed. You need to explicitly <<install-uninstall-integration-assets,install them through {kib}>>.
 
-To set the target host dynamically for a targeted Pod based on its labels, use a variable in the {agent} policy to return path information from the provider:
+Conditions can also be used in the `Kubernetes` package in order to set the target host dynamically for a targeted Pod based on its labels.
+This is useful for datasets that target specific pods like `kube-scheduler` or `kube-controller-manager`.
+The following configuration will enable `kubernetes.scheduler` dataset only for pods which have the label `component=kube-scheduler` defined.
 
 [source,yaml]
 ----
@@ -84,6 +90,13 @@ To set the target host dynamically for a targeted Pod based on its labels, use a
   condition: ${kubernetes.labels.component} == 'kube-scheduler'
 ----
 
+NOTE: Pods' labels and annotations can be used in autodiscover conditions. In the case of labels or annotations that include dots(`.`), they can be used in conditions exactly as
+they are defined in the pods. For example `condition: ${kubernetes.labels.app.kubernetes.io/name} == 'ingress-nginx'`. This should not be confused with the dedoted (by default) labels and annotations
+stored into Elasticsearch(<<kubernetes-provider>>).
+
+WARNING: Before 8.6 release, labels used in autodiscover conditions were dedoted in case `labels.dedot` parameter was set to `true` in Kubernetes Provider 
+configuration (by default `true`). The same did not apply for annotations. This was fixed in 8.6 release. Refer to <<release-notes-8.6.0>>.
+
 WARNING: In some "As a Service" Kubernetes implementations, like GKE, the control plane nodes or even the Pods running on them won’t be visible. In these cases, it won’t be possible to use scheduler metricsets, necessary for this example. Refer https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-module-kubernetes.html#_scheduler_and_controllermanager[scheduler and controller manager] to find more information.
 
 Following the Redis example, if you deploy another Redis Pod with a different port, it should be detected. To check this, go, for example, to the field `service.address` under `metrics-redis.info-default`. It should be displaying two different services.

docs/en/ingest-management/elastic-agent/configuration/providers/kubernetes-provider.asciidoc

@@ -189,6 +189,10 @@ The available keys are:
 
 
 These are the fields available within config templating. The `kubernetes.*` fields will be available on each emitted event.
+
+NOTE: `kubernetes.labels.*` and `kubernetes.annotations.*` used in config templating are not dedoted and should not be confused with
+labels and annotations added in the final Elasticsearch document and which are dedoted by default. For examples refer to <<conditions-based-autodiscover>>.
+
 Note that not all of these fields are available by default and special configuration options
 are needed in order to include them.
 

docs/en/ingest-management/release-notes/release-notes-8.6.asciidoc

@@ -66,6 +66,21 @@ provided. For more information, refer to {agent-pull}1140[#1140].
 Remove the `--pprof` argument from any scripts or commands you use.
 ====
 
+[discrete]
+[[breaking-1398]]
+.Not dedoted Kubernetes pod labels to be used for autodiscover conditions
+[%collapsible]
+====
+*Details* +
+Kubernetes pod labels used in autodiscover conditions are not dedoted anymore. This means that
+`.` are not replaced with `_` in labels like `app.kubernetes.io/component=controller`.
+This follows the same approach as kubernetes annotations. For more information refer to <<kubernetes-provider>>.
+
+*Impact* +
+Any template used for standalone elastic agent or installed integration that makes use
+of dedoted kubernetes labels inside conditions has to be updated.
+====
+
 [discrete]
 [[known-issues-8.6.0]]
 === Known issues