Clarify ECK support scope for ingress controllers (#908)

### Background 

In an internal ticket (stl-1548) and also an internal slack channel,
@jeanfabrice, @pebrc and I discussed about support scope of ingress
controllers.
We came up with the plan to clarify this in public doc as below:

### Docs need updated

- https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-recipes.html
-
https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-traffic-splitting.html
- https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-maps.html
-
https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-maps-http-configuration.html#k8s-maps-ingress
-
https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-stack-helm-chart.html#k8s-eck-stack-ingress

### Text to add 

> **Note: Support Scope for Ingress Controllers**
> 
> Ingress is a standard Kubernetes concept. While ECK-managed workloads
can be publicly exposed via ingresses and we provide example ingress
configuration recipes, setting up an Ingress controller requires
in-house Kubernetes expertise. If configuring ingress presents
challenges, we recommend using a standard Load Balancer (LB) as an
alternative solution.


### docs-content pages to edit

- http://localhost:3000/deploy-manage/deploy/cloud-on-k8s/recipes
-
http://localhost:3000/deploy-manage/deploy/cloud-on-k8s/requests-routing-to-elasticsearch-nodes
-
http://localhost:3000/deploy-manage/deploy/cloud-on-k8s/elastic-maps-server
-
http://localhost:3000/deploy-manage/deploy/cloud-on-k8s/http-configuration#k8s-maps-ingress
-
http://localhost:3000/deploy-manage/deploy/cloud-on-k8s/managing-deployments-using-helm-chart

### Sample view

**:: Without link**

<img width="1156" alt="image"
src="https://github.com/user-attachments/assets/e517f28c-46cd-4697-9aa3-5e1ca2771607"
/>

**:: With link**

<img width="714" alt="image"
src="https://github.com/user-attachments/assets/5bf3ac3e-6730-4fa2-90f2-80217a922e6c"
/>

Clicking the link [example ingress configuration
recipes](http://localhost:3000/deploy-manage/deploy/cloud-on-k8s/recipes)
will redirect page to
http://localhost:3000/deploy-manage/deploy/cloud-on-k8s/recipes

---------

Co-authored-by: Edu González de la Herrán <[email protected]>

Author: kunisen

deploy-manage/deploy/cloud-on-k8s/elastic-maps-server.md

@@ -35,6 +35,11 @@ The following sections describe how to customize an Elastic Maps Server deployme
     * [Disable TLS](http-configuration.md#k8s-maps-http-disable-tls)
     * [Ingress and Kibana configuration](http-configuration.md#k8s-maps-ingress)
 
+:::{admonition} Support scope for Ingress Controllers
+[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) is a standard Kubernetes concept. While ECK-managed workloads can be publicly exposed using ingress resources, and we provide [example configurations](/deploy-manage/deploy/cloud-on-k8s/recipes.md), setting up an Ingress controller requires in-house Kubernetes expertise. 
+
+If ingress configuration is challenging or unsupported in your environment, consider using standard `LoadBalancer` services as a simpler alternative.
+:::
 
 
 

deploy-manage/deploy/cloud-on-k8s/http-configuration.md

@@ -33,5 +33,10 @@ You can disable the generation of the self-signed certificate and hence disable
 
 To use Elastic Maps Server from your Kibana instances, you need to configure Kibana to fetch maps from your Elastic Maps Server instance by using the [`map.emsUrl`](/explore-analyze/visualize/maps/maps-connect-to-ems.md#elastic-maps-server-kibana) configuration key. The value of this setting needs to be the URL where the Elastic Maps Server instance is reachable from your browser. The certificates presented by Elastic Maps Server need to be trusted by the browser, and the URL must have the same origin as the URL where your Kibana is hosted to avoid cross origin resource issues. Check the [recipe section](https://github.com/elastic/cloud-on-k8s/tree/2.16/config/recipes/) for an example on how to set this up using an Ingress resource.
 
+:::{admonition} Support scope for Ingress Controllers
+[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) is a standard Kubernetes concept. While ECK-managed workloads can be publicly exposed using ingress resources, and we provide [example configurations](/deploy-manage/deploy/cloud-on-k8s/recipes.md), setting up an Ingress controller requires in-house Kubernetes expertise. 
+
+If ingress configuration is challenging or unsupported in your environment, consider using standard `LoadBalancer` services as a simpler alternative.
+:::
 
 

deploy-manage/deploy/cloud-on-k8s/managing-deployments-using-helm-chart.md

@@ -101,6 +101,13 @@ helm install es-quickstart elastic/eck-elasticsearch -n elastic-stack --create-n
 
 ## Adding Ingress to the Elastic stack [k8s-eck-stack-ingress] 
 
+:::{admonition} Support scope for Ingress Controllers
+[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) is a standard Kubernetes concept. While ECK-managed workloads can be publicly exposed using ingress resources, and we provide [example configurations](/deploy-manage/deploy/cloud-on-k8s/recipes.md), setting up an Ingress controller requires in-house Kubernetes expertise. 
+
+If ingress configuration is challenging or unsupported in your environment, consider using standard `LoadBalancer` services as a simpler alternative.
+:::
+
+
 Both {{es}} and {{kib}} support [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/), which can be enabled using the following options:
 
 **If an individual chart is used (not eck-stack)**

deploy-manage/deploy/cloud-on-k8s/recipes.md

@@ -22,4 +22,11 @@ This section includes recipes that provide configuration examples for some commo
 Compared to other configuration examples that are consistently tested, like [fleet-managed Elastic Agent on ECK](configuration-examples-fleet.md), [standalone Elastic Agent on ECK](configuration-examples-standalone.md), or [Beats on ECK](/deploy-manage/deploy/cloud-on-k8s/configuration-examples-beats.md), the recipes in this section are not regularly tested by our automation system, and therefore should not be considered to be production-ready.
 ::::
 
+:::{admonition} Support scope for Ingress Controllers
+[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) is a standard Kubernetes concept. While ECK-managed workloads can be publicly exposed using ingress resources, and we provide [example configurations](/deploy-manage/deploy/cloud-on-k8s/recipes.md), setting up an Ingress controller requires in-house Kubernetes expertise. 
+
+If ingress configuration is challenging or unsupported in your environment, consider using standard `LoadBalancer` services as a simpler alternative.
+:::
+
+
 

deploy-manage/deploy/cloud-on-k8s/requests-routing-to-elasticsearch-nodes.md

@@ -12,6 +12,13 @@ The default Kubernetes service created by ECK, named `<cluster_name>-es-http`, i
 
 As an alternative, you can use features provided by third-party software such as service meshes and ingress controllers to achieve more advanced traffic management configurations. Check the [recipes directory](https://github.com/elastic/cloud-on-k8s/tree/2.16/config/recipes) in the ECK source repository for a few examples.
 
+:::{admonition} Support scope for Ingress Controllers
+[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) is a standard Kubernetes concept. While ECK-managed workloads can be publicly exposed using ingress resources, and we provide [example configurations](/deploy-manage/deploy/cloud-on-k8s/recipes.md), setting up an Ingress controller requires in-house Kubernetes expertise. 
+
+If ingress configuration is challenging or unsupported in your environment, consider using standard `LoadBalancer` services as a simpler alternative.
+:::
+
+
 The service configurations shown in these sections are based on the following Elasticsearch cluster definition:
 
 ```yaml