elastic · leemthompo · Feb 18, 2025 · Feb 18, 2025 · Feb 18, 2025 · Feb 18, 2025
@@ -14,7 +14,6 @@ The [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application
 
 * Kibana
 * APM Server
-* Enterprise Search
 * Elastic Maps Server
 
 These resources expose the `scale` subresource which can be used by the Horizontal Pod Autoscaler controller to automatically adjust the number of replicas according to the CPU load or any other custom or external metric. This example shows how to create an `HorizontalPodAutoscaler` resource to adjust the replicas of a Kibana deployment according to the CPU load:

@@ -39,7 +39,6 @@ $$$ec-autoscaling-api-example-requirements-table$$$
 | coordinating and master nodes | ✓ | ✕ | ✕ |
 | Kibana | ✓ | ✕ | ✕ |
 | APM | ✓ | ✕ | ✕ |
-| Enterprise Search | ✓ | ✕ | ✕ |
 
 +
 

@@ -78,7 +78,6 @@ The following are known limitations and restrictions with autoscaling:
 
 * Autoscaling will not run if the cluster is unhealthy or if the last Elasticsearch plan failed.
 * Trial deployments cannot be configured to autoscale beyond the normal Trial deployment size limits. The maximum size per zone is increased automatically from the Trial limit when you convert to a paid subscription.
-* If Enterprise Search is left at the default size, and has no engines or sources configured for an extended period, it will be automatically disabled. This occurs whether autoscaling is enabled or not. Reactivate the service by editing the **Enterprise Search** settings for your deployment under **Cloud > Deployments > *your-deployment* > Edit**.
 * ELSER deployments do not scale automatically. For more information, refer to [ELSER](../../explore-analyze/machine-learning/nlp/ml-nlp-elser.md) and [Trained model autoscaling](../../explore-analyze/machine-learning/nlp/ml-nlp-auto-scale.md).
 
 

@@ -40,7 +40,6 @@ $$$ece-autoscaling-api-example-requirements-table$$$
 | coordinating and master nodes | ✓ | ✕ | ✕ |
 | Kibana | ✓ | ✕ | ✕ |
 | APM | ✓ | ✕ | ✕ |
-| Enterprise Search | ✓ | ✕ | ✕ |
 
 +
 

@@ -96,7 +96,6 @@ $$$faq-included$$$What is included in my paid {{ech}} deployment?
 
     * Free 1GB RAM Kibana instance
     * Free 1GB RAM Machine Learning node
-    * Free 2GB RAM Enterprise Search instance
     * Free 1GB RAM APM server
     * A free allowance for [data transfer and snapshot storage costs](#faq-dts)
 

@@ -37,7 +37,6 @@ Other Products
     * [APM event intake API Reference](/solutions/observability/apps/elastic-apm-events-intake-api.md)
     * [App Search API Reference](https://www.elastic.co/guide/en/app-search/current/api-reference.html)
     * [Elastic Security APIs](https://www.elastic.co/guide/en/security/current/security-apis.html)
-    * [Enterprise Search management APIs](https://www.elastic.co/guide/en/enterprise-search/current/management-apis.html)
     * [Fleet APIs](https://www.elastic.co/guide/en/fleet/current/fleet-api-docs.html)
     * [Logstash APIs](https://www.elastic.co/guide/en/logstash/current/monitoring-logstash.html)
     * [Workplace Search API Reference](https://www.elastic.co/guide/en/workplace-search/current/workplace-search-api-overview.html)

@@ -5,7 +5,7 @@ mapped_pages:
 
 # Change the ECE API URL [ece-config-api-base-url]
 
-You can configure the HTTPS URL used to access the ECE API. You can specify either a DNS host name or an IP address. The primary use for this is to enable [single sign-on](../../users-roles/cloud-enterprise-orchestrator/configure-sso-for-deployments.md) on your deployments, so you can log into Kibana and Enterprise Search automatically once logged in to ECE.
+You can configure the HTTPS URL used to access the ECE API. You can specify either a DNS host name or an IP address. The primary use for this is to enable [single sign-on](../../users-roles/cloud-enterprise-orchestrator/configure-sso-for-deployments.md) on your deployments, so you can log into Kibana automatically once logged in to ECE.
 
 To change the ECE API URL in the Cloud UI:
 

@@ -13,7 +13,6 @@ The components of the Elastic Stack that we support as part of a deployment are
 * Machine Learning (ML) nodes
 * Kibana instances
 * APM and Fleet instances
-* Enterprise Search instances
 
 Elastic Cloud Enterprise comes with some deployment templates already built in, but you can [create new deployment templates](ece-configuring-ece-create-templates.md) to address a particular use case you might have. To make the most out of your hardware, we also recommend that you [configure deployment templates](configure-deployment-templates.md), so that ECE knows where to deploy components of the Elastic Stack.
 
@@ -39,10 +38,6 @@ The deployment templates available are:
 
     Use this template to prevent, collect, detect, and respond to threats for unified protection across your infrastructure. Check the [**Elastic Security**](../../../solutions/security.md) documentation for more information.
 
-* **Elastic Enterprise Search template**
-
-    Default deployment template for Elastic Enterprise Search. Check the [**Enterprise Search**](https://www.elastic.co/guide/en/enterprise-search/current/index.html) documentation for more information.
-
 * **Elastic Observability template**
 
     This template allows you to consolidate your logs, metrics, application traces, and system availability with purpose-built UIs. Check the [**Elastic Observability**](../../../solutions/observability/get-started/what-is-elastic-observability.md) documentation for more information.

@@ -399,7 +399,7 @@ Before you start creating your own deployment templates, you should have: [tagge
 
 
 ::::{note}
-When specifying `node_roles` in the Elasticsearch plan of the deployment template, the template must contain all resource types and all Elasticsearch tiers. The deployment template must contain exactly one entry for each resource type. It must have one Elasticsearch, one Kibana, one APM, and one Enterprise Search. On top of that, it must also include all supported Elasticsearch tiers in the Elasticsearch plan. The supported tiers are identified by the IDs `hot_content`, `warm`, `cold`, `frozen`, `master`, `coordinating` and `ml`.
+When specifying `node_roles` in the Elasticsearch plan of the deployment template, the template must contain all resource types and all Elasticsearch tiers. The deployment template must contain exactly one entry for each resource type. It must have one Elasticsearch, one Kibana, and one APM. On top of that, it must also include all supported Elasticsearch tiers in the Elasticsearch plan. The supported tiers are identified by the IDs `hot_content`, `warm`, `cold`, `frozen`, `master`, `coordinating` and `ml`.
 ::::
 
 

@@ -24,7 +24,7 @@ To perform an offline installation without a private Docker registry, you have t
     For example, for Elastic Cloud Enterprise 3.8.1 and the Elastic Stack versions it shipped with, you need:
 
     * Elastic Cloud Enterprise 3.8.1
-    * Elasticsearch 8.17.1, Kibana 8.17.1, APM 8.17.1, and Enterprise Search 8.17.1
+    * Elasticsearch 8.17.1, Kibana 8.17.1, and APM 8.17.1
 
 2. Create .tar files of the images:
 

@@ -5,7 +5,7 @@ mapped_pages:
 
 # Manage your installation capacity [ece-manage-capacity]
 
-In ECE, every host is a runner. Depending on the size of your platform, runners can have [one or more roles](ece-roles.md): Coordinator, director, proxy, and allocator. While planning the capacity of your ECE installation, you have to properly size the capacity for all roles. However, the allocator role deserves particular attention, as it hosts the Elasticsearch, Kibana, APM,  Enterprise Search nodes, and the relevant services.
+In ECE, every host is a runner. Depending on the size of your platform, runners can have [one or more roles](ece-roles.md): Coordinator, director, proxy, and allocator. While planning the capacity of your ECE installation, you have to properly size the capacity for all roles. However, the allocator role deserves particular attention, as it hosts the Elasticsearch, Kibana, and APM nodes, and the relevant services.
 
 This section focuses on the allocator role, and explains how to plan its capacity in terms of memory, CPU, `processors` setting, and storage.
 

@@ -25,7 +25,6 @@ After installing or upgrading to version 2.10 or later:
     * For Elasticsearch, the certificate needs to allow for ***.es.<your-domain>**
     * For Kibana, the certificate needs to allow for ***.kb.<your-domain>**
     * For APM, the certificate needs to allow for ***.apm.<your-domain>**
-    * For Enterprise Search or AppSearch, the certificate needs to allow for ***.ent.<your-domain>**
     * For Fleet, the certificate needs to allow for ***.fleet.<your-domain>**
 
 3. In the **Platform** menu, select **Settings**.

@@ -55,7 +55,7 @@ stringData:
     logging.level: debug
 ```
 
-Refer to [Set compute resources for Kibana, Enterprise Search, Elastic Maps Server, APM Server and Logstash](manage-compute-resources.md#k8s-compute-resources-kibana-and-apm) for adjusting compute resources for Elastic Maps Server.
+Refer to [Set compute resources for Kibana, Elastic Maps Server, APM Server and Logstash](manage-compute-resources.md#k8s-compute-resources-kibana-and-apm) for adjusting compute resources for Elastic Maps Server.
 
 
 ## Scale out an Elastic Maps Server deployment [k8s-maps-scaling]

@@ -11,7 +11,6 @@ mapped_pages:
 * [*Run standalone Elastic Agent on ECK*](standalone-elastic-agent.md)
 * [*Run {{fleet}}-managed {{agent}} on ECK*](fleet-managed-elastic-agent.md)
 * [*Run Elastic Maps Server on ECK*](elastic-maps-server.md)
-* [*Run Enterprise Search on ECK*](enterprise-search.md)
 * [*Run Beats on ECK*](beats.md)
 * [*Run {{ls}} on ECK*](logstash.md)
 * [*Elastic Stack Helm Chart*](managing-deployments-using-helm-chart.md)

@@ -5,7 +5,7 @@ mapped_pages:
 
 # Configure the validating webhook [k8s-webhook]
 
-ECK can be configured to provide a [validating webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) that validates Elastic custom resources (Elasticsearch, Kibana, APM Server, Enterprise Search, Beats, Elastic Agent, Elastic Maps Server, and Logstash) before they are created or updated. Validating webhooks provide immediate feedback if a submitted manifest contains invalid or illegal configuration — which can help you catch errors early and save time that would otherwise be spent on troubleshooting.
+ECK can be configured to provide a [validating webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) that validates Elastic custom resources (Elasticsearch, Kibana, APM Server, Beats, Elastic Agent, Elastic Maps Server, and Logstash) before they are created or updated. Validating webhooks provide immediate feedback if a submitted manifest contains invalid or illegal configuration — which can help you catch errors early and save time that would otherwise be spent on troubleshooting.
 
 Validating webhooks are defined using a `ValidatingWebhookConfiguration` object that defines the following:
 

@@ -5,7 +5,7 @@ mapped_pages:
 
 # Create custom images [k8s-custom-images]
 
-You can create your own custom application images (Elasticsearch, Kibana, APM Server, Enterprise Search, Beats, Elastic Agent, Elastic Maps Server, and Logstash) instead of using the base images provided by Elastic. You might want to do this to have a canonical image with all the necessary plugins pre-loaded rather than [installing them through an init container](init-containers-for-plugin-downloads.md) each time a Pod starts.  You must use the official image as the base for custom images. For example, if you want to create an Elasticsearch 8.16.1 image with the [ICU Analysis Plugin](https://www.elastic.co/guide/en/elasticsearch/plugins/current/analysis-icu.html), you can do the following:
+You can create your own custom application images (Elasticsearch, Kibana, APM Server, Beats, Elastic Agent, Elastic Maps Server, and Logstash) instead of using the base images provided by Elastic. You might want to do this to have a canonical image with all the necessary plugins pre-loaded rather than [installing them through an init container](init-containers-for-plugin-downloads.md) each time a Pod starts.  You must use the official image as the base for custom images. For example, if you want to create an Elasticsearch 8.16.1 image with the [ICU Analysis Plugin](https://www.elastic.co/guide/en/elasticsearch/plugins/current/analysis-icu.html), you can do the following:
 
 1. Create a `Dockerfile` containing:
 

@@ -56,7 +56,7 @@ spec:
 ```
 
 ::::{note} 
-Configuration for other Elastic stack applications, like APM Server, Enterprise Search or Beats, is identical to the Kibana configuration except for the `apiVersion` and `kind` fields.
+Configuration for other Elastic stack applications, like APM Server, or Beats, is identical to the Kibana configuration except for the `apiVersion` and `kind` fields.
 ::::
 
 

@@ -49,7 +49,7 @@ spec:
 
 The name of the container in the [Pod Template](https://kubernetes.io/docs/concepts/workloads/pods/#pod-templates) must be `kibana`.
 
-Check [Set compute resources for Kibana, Enterprise Search, Elastic Maps Server, APM Server and Logstash](manage-compute-resources.md#k8s-compute-resources-kibana-and-apm) for more information.
+Check [Set compute resources for Kibana, Elastic Maps Server, APM Server and Logstash](manage-compute-resources.md#k8s-compute-resources-kibana-and-apm) for more information.
 
 
 ## {{kib}} configuration [k8s-kibana-configuration]

@@ -18,7 +18,7 @@ mapped_pages:
     oc adm pod-network make-projects-global elastic-system
     ```
 
-3. Create a namespace to hold the Elastic resources (Elasticsearch, Kibana, APM Server, Enterprise Search, Beats, Elastic Agent, Elastic Maps Server, and Logstash):
+3. Create a namespace to hold the Elastic resources (Elasticsearch, Kibana, APM Server, Beats, Elastic Agent, Elastic Maps Server, and Logstash):
 
     ::::{note} 
     A namespace other than the default namespaces (default, kube-**, openshift-**, etc) is required such that default [Security Context Constraint](https://docs.openshift.com/container-platform/4.12/authentication/managing-security-context-constraints.md) (SCC) permissions are applied automatically. Elastic resources will not work properly in any of the default namespaces.

@@ -61,7 +61,7 @@ spec:
 
 As the default `failurePolicy` of the webhook is `Ignore`, the operator continues to function even if the above annotations are not present. The downside is that you are still able to submit an invalid manifest using `kubectl` without receiving any immediate feedback.
 
-ECK has a fallback validation mechanism that reports validation failures as events associated with the relevant resource (Elasticsearch, Kibana, APM Server, Enterprise Search, Beats, Elastic Agent, Elastic Maps Server, and Logstash) that must be manually discovered by running `kubectl describe`. For example, to find the validation errors in an Elasticsearch resource named `quickstart`, you can run `kubectl describe elasticsearch quickstart`.
+ECK has a fallback validation mechanism that reports validation failures as events associated with the relevant resource (Elasticsearch, Kibana, APM Server, Beats, Elastic Agent, Elastic Maps Server, and Logstash) that must be manually discovered by running `kubectl describe`. For example, to find the validation errors in an Elasticsearch resource named `quickstart`, you can run `kubectl describe elasticsearch quickstart`.
 
 
 ## Connect Elastic Stack applications to the Istio service mesh [k8s-service-mesh-istio-stack-connection]

@@ -5,7 +5,7 @@ mapped_pages:
 
 # Manage compute resources [k8s-managing-compute-resources]
 
-To help the Kubernetes scheduler correctly place Pods in available Kubernetes nodes and ensure quality of service (QoS), it is recommended to specify the CPU and memory requirements for objects managed by the operator (Elasticsearch, Kibana, APM Server, Enterprise Search, Beats, Elastic Agent, Elastic Maps Server, and Logstash). In Kubernetes, `requests` defines the minimum amount of resources that must be available for a Pod to be scheduled; `limits` defines the maximum amount of resources that a Pod is allowed to consume. For more information about how Kubernetes uses these concepts, check [Managing Compute Resources for Containers](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/).
+To help the Kubernetes scheduler correctly place Pods in available Kubernetes nodes and ensure quality of service (QoS), it is recommended to specify the CPU and memory requirements for objects managed by the operator (Elasticsearch, Kibana, APM Server, Beats, Elastic Agent, Elastic Maps Server, and Logstash). In Kubernetes, `requests` defines the minimum amount of resources that must be available for a Pod to be scheduled; `limits` defines the maximum amount of resources that a Pod is allowed to consume. For more information about how Kubernetes uses these concepts, check [Managing Compute Resources for Containers](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/).
 
 ::::{note}
 The operator applies default requests and limits for memory and CPU. They may be suitable for experimenting with the Elastic Stack, however it is recommended to reevaluate these values for production use cases.

@@ -74,18 +74,6 @@ helm install eck-stack-with-apm-server elastic/eck-stack \
     --values https://raw.githubusercontent.com/elastic/cloud-on-k8s/2.16/deploy/eck-stack/examples/apm-server/basic.yaml -n elastic-stack
 ```
 
-
-## Installing an Elastic Enterprise Search Server along with Elasticsearch and Kibana using the eck-stack Helm Chart [k8s-install-enterprise-search-elasticsearch-kibana-helm] 
-
-The following section builds upon the previous sections, and allows installing an Elastic Enterprise Search Server along with Elasticsearch and Kibana.
-
-```sh
-# Install an eck-managed Elasticsearch, Kibana, and Enterprise Search Server using custom values.
-helm install eck-stack-with-enterprise-search elastic/eck-stack \
-    --values https://raw.githubusercontent.com/elastic/cloud-on-k8s/2.16/deploy/eck-stack/examples/enterprise-search/basic.yaml -n elastic-stack
-```
-
-
 ### Installing individual components of the Elastic Stack using the Helm Charts [k8s-eck-stack-individual-components] 
 
 You can install individual components in one of two ways using the provided Helm Charts.

@@ -7,7 +7,7 @@ mapped_pages:
 
 This section describes how to restrict associations that can be created between resources managed by ECK.
 
-When using the `elasticsearchRef` field to establish a connection to Elasticsearch from Kibana, APM Server, Enterprise Search, or Beats resources, by default the association is allowed as long as both resources are deployed to namespaces managed by that particular ECK instance. The association will succeed even if the user creating the association does not have access to one of the namespaces or the Elasticsearch resource.
+When using the `elasticsearchRef` field to establish a connection to Elasticsearch from Kibana, APM Server, or Beats resources, by default the association is allowed as long as both resources are deployed to namespaces managed by that particular ECK instance. The association will succeed even if the user creating the association does not have access to one of the namespaces or the Elasticsearch resource.
 
 The enforcement of access control rules for cross-namespace associations is disabled by default. Once enabled, it only enforces access control for resources deployed across two different namespaces. Associations between resources deployed in the same namespace are not affected.
 

@@ -91,7 +91,7 @@ spec:
 
 ## Disable TLS [k8s-disable-tls]
 
-You can explicitly disable TLS for Kibana, APM Server, Enterprise Search and the HTTP layer of Elasticsearch.
+You can explicitly disable TLS for Kibana, APM Server, and the HTTP layer of Elasticsearch.
 
 ```yaml
 spec:
-Original file line number
+Diff line change
@@ Expand Up @@
     ::::{note}
-    When specifying `node_roles` in the Elasticsearch plan of the deployment template, the template must contain all resource types and all Elasticsearch tiers. The deployment template must contain exactly one entry for each resource type. It must have one Elasticsearch, one Kibana, one APM, and one Enterprise Search. On top of that, it must also include all supported Elasticsearch tiers in the Elasticsearch plan. The supported tiers are identified by the IDs `hot_content`, `warm`, `cold`, `frozen`, `master`, `coordinating` and `ml`.
+    When specifying `node_roles` in the Elasticsearch plan of the deployment template, the template must contain all resource types and all Elasticsearch tiers. The deployment template must contain exactly one entry for each resource type. It must have one Elasticsearch, one Kibana, and one APM. On top of that, it must also include all supported Elasticsearch tiers in the Elasticsearch plan. The supported tiers are identified by the IDs `hot_content`, `warm`, `cold`, `frozen`, `master`, `coordinating` and `ml`.
     ::::
@@ Expand Down @@