Merge branch 'main' into issue-3721-delete-schedules

Author: nastasha-solomon

.vscode/extensions.json

@@ -0,0 +1,5 @@
+{
+  "recommendations": [
+    "Elastic.elastic-docs-v3-utilities"
+  ]
+}

deploy-manage/autoscaling/autoscaling-in-ece-and-ech.md

@@ -82,14 +82,26 @@ In {{ece}} deployments, a warning is also issued in the ECE `service-constructor
 
 ## Restrictions and limitations[ec-autoscaling-restrictions]
 
+### Generic limitations
+
 The following are known limitations and restrictions with autoscaling:
 
 * Autoscaling will not run if the cluster is unhealthy or if the last {{es}} plan failed.
 
+### {{ech}}-specific limitations
+
 In {{ech}} the following additional limitations apply:
 
 * 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.
 * 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](../autoscaling/trained-model-autoscaling.md).
+* The maximum configurable node count is 32. This means that the `Maximum size per zone` in autoscaling is limited to the maximum RAM size of the instance configuration in use, multiplied by 32. 
+
+   For example, for the instance configuration [`aws.es.datahot.c6gd`](cloud://reference/cloud-hosted/aws-default.md), the maximum RAM size is 60GB. Therefore, the `Maximum size per zone` in autoscaling is limited to `60GB x 32 = 1.875TB` (displayed as `1.88TB` in the {{ecloud}} console UI). 
+   
+   For more details, refer to [Restrictions and known problems > Node count and size](../deploy/elastic-cloud/restrictions-known-problems.md#ec-node-count-size).
+
+
+### {{ece}}-specific limitations
 
 In {{ece}}, the following additional limitations apply:
 

deploy-manage/deploy/cloud-on-k8s/air-gapped-install.md

@@ -10,10 +10,14 @@ products:
   - id: cloud-kubernetes
 ---
 
-# Running in air-gapped environments [k8s-air-gapped]
+# Running ECK in air-gapped environments [k8s-air-gapped]
 
 The ECK operator can be run in an air-gapped environment without access to the open internet when configured to avoid pulling container images from `docker.elastic.co`.
 
+:::{note}
+To deploy ECK in Google Distributed Cloud (GDC) air-gapped refer to [Deploy ECK on GDC air-gapped](./eck-gdch.md).
+:::
+
 By default ECK does not require you to specify the container image for each {{stack}} application you deploy.
 
 ```yaml subs=true

deploy-manage/deploy/cloud-on-k8s/eck-gdch.md

@@ -0,0 +1,42 @@
+---
+applies_to:
+  deployment:
+    eck: all
+products:
+  - id: cloud-kubernetes
+---
+
+# Deploy ECK on Google Distributed Cloud air-gapped
+
+You can install {{eck}} (ECK) directly from the marketplace available within your [Google Distributed Cloud (GDC) air-gapped](https://cloud.google.com/distributed-cloud/hosted/docs/latest/gdch/overview) environment.
+
+:::{note}
+The Elastic Package Registry (EPR) container image is not yet available in GDC and must be deployed manually if you plan to use [integrations](integration-docs://reference/index.md). All other dependencies, such as the Elastic Artifact Registry and Elastic Endpoint Artifact Repository, must also be built and hosted locally as described in the [air-gapped deployment documentation](/deploy-manage/deploy/self-managed/air-gapped-install.md).
+
+For extra guidance on running ECK in isolated environments, refer to [Running ECK in air-gapped environments](/deploy-manage/deploy/cloud-on-k8s/air-gapped-install.md).
+:::
+
+## Install ECK
+
+To install ECK:
+
+1. Open the **Marketplace** in your GDC console.
+2. Search for **Elastic Cloud on Kubernetes (BYOL)**.
+3. Click **Install**.
+4. Select a **user cluster**, review or adjust the installation parameters, and start the installation.
+
+    If you prefer to customize the configuration, refer to the [ECK configuration guide](/deploy-manage/deploy/cloud-on-k8s/configure.md) for details on setting operator parameters in the **Configure the service** page.
+
+Once completed, ECK will be running in your GDC air-gapped environment.
+
+![ECK-GDCH](/deploy-manage/images/eck-gdch.png)
+
+Next, open a terminal with `kubectl` and choose one of the following options:
+
+* [Start a trial](/deploy-manage/license/manage-your-license-in-eck.md#k8s-start-trial) to enable ECK’s enterprise features.
+* Continue using ECK in free & basic mode.
+* [Apply an Enterprise license](/deploy-manage/license/manage-your-license-in-eck.md#k8s-add-license).
+
+## Next steps
+
+Follow the [ECK Quickstart guide](/deploy-manage/deploy/cloud-on-k8s/elasticsearch-deployment-quickstart.md) to deploy {{es}} and {{kib}} for your use case, whether it’s [Observability](/solutions/observability.md), [Security](/solutions/security.md), or [Search](/solutions/search.md).

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

@@ -37,6 +37,7 @@ ECK supports multiple installation methods. Choose the one that best fits your i
 * [Install ECK using a Helm chart](./install-using-helm-chart.md)
 * [](./deploy-eck-on-openshift.md)
 * [](./deploy-eck-on-gke-autopilot.md)
+* [Deploy ECK on Google Distributed Hosted Cloud](./eck-gdch.md)
 * [](./deploy-fips-compatible-version-of-eck.md)
 
 For air-gapped environments, refer to [](./air-gapped-install.md) to understand the requirements and installation considerations.

deploy-manage/deploy/elastic-cloud/restrictions-known-problems.md

@@ -24,6 +24,8 @@ When using {{ecloud}}, there are some limitations you should be aware of:
 * [Restoring a snapshot across deployments](#ec-snapshot-restore-enterprise-search-kibana-across-deployments)
 * [Migrate Fleet-managed {{agents}} across deployments by restoring a snapshot](#ec-migrate-elastic-agent)
 * [Regions and Availability Zones](#ec-regions-and-availability-zone)
+* [Node count and size](#ec-node-count-size)
+* [Repository analysis API is unavailable in {{ecloud}}](#ec-repository-analyis-unavailable)
 
 For limitations related to logging and monitoring, check the [Restrictions and limitations](../../monitor/stack-monitoring/ece-ech-stack-monitoring.md#restrictions-monitoring) section of the logging and monitoring page.
 
@@ -131,6 +133,15 @@ To make a seamless migration, after restoring from a snapshot there are some add
 * The AWS `us-west-1` region is limited to two availability zones for ES data nodes and one (tiebreaker only) virtual zone (as depicted by the `-z` in the AZ (`us-west-1z`). Deployment creation with three availability zones for {{es}} data nodes for hot, warm, and cold tiers is not possible. This includes scaling an existing deployment with one or two AZs to three availability zones. The virtual zone `us-west-1z` can only hold an {{es}} tiebreaker node (no data nodes). The workaround is to use a different AWS US region that allows three availability zones, or to scale existing nodes up within the two availability zones.
 * The AWS `eu-central-2` region is limited to two availability zones for CPU Optimized (ARM) Hardware profile ES data node and warm/cold tier. Deployment creation with three availability zones for {{es}} data nodes for hot (for CPU Optimized (ARM) profile), warm and cold tiers is not possible. This includes scaling an existing deployment with one or two AZs to three availability zones. The workaround is to use a different AWS region that allows three availability zones, or to scale existing nodes up within the two availability zones.
 
-## Repository Analysis API is unavailable in {{ecloud}} [ec-repository-analyis-unavailable]
+## Node count and size [ec-node-count-size]
+* In the {{ecloud}} console UI, the maximum configurable node count is 32.
+  The total RAM for `Size per zone` is calculated by multiplying the maximum RAM size of the [instance configuration](cloud://reference/cloud-hosted/hardware.md) in use by 32. For example, for the instance configuration [`aws.es.datahot.c6gd`](cloud://reference/cloud-hosted/aws-default.md), the maximum RAM size is 60GB. Therefore, the total RAM for `Size per zone` is `60GB x 32 = 1.875TB` (displayed as `1.88TB` in the {{ecloud}} console UI).
+  
+  This maximum node count limitation applies to the UI and affects both the maximum `Size per zone` during manual scaling and the `Maximum size per zone` in autoscaling. This limit is in place to prevent users from inadvertently deploying excessive capacity. 
+  
+  This limitation does not apply when using the API for manual scaling or autoscaling. If you require additional capacity, you can use the [Elastic Cloud API](cloud://reference/cloud-hosted/ec-api-restful.md) to scale up or configure the maximum size for autoscaling, in a self-sufficient way. Refer to the [Update a deployment](cloud://reference/cloud-hosted/ec-api-deployment-crud.md#ec_update_a_deployment) example to learn how to make a deployment update request using the API.
+* Apart from the maximum node count configurable in the {{ecloud}} console UI, there are other service limits based on each instance configuration. These service limits are typically greater than 32. For more details, please [contact Elastic support for assistance](/troubleshoot/index.md).
+
+## Repository analysis API is unavailable in {{ecloud}} [ec-repository-analyis-unavailable]
 
 * The {{es}} [Repository analysis API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-snapshot-repository-analyze) is not available in {{ecloud}} due to deployments defaulting to having [operator privileges](../../users-roles/cluster-or-deployment-auth/operator-privileges.md) enabled that prevent non-operator privileged users from using it along with a number of other APIs.

deploy-manage/images/eck-gdch.png

@@ -14,7 +14,7 @@ products:
 # Collect monitoring data with Metricbeat [monitoring-metricbeat]
 
 
-Yu can use {{metricbeat}} to collect data about {{kib}} and ship it to the monitoring cluster.
+You can use {{metricbeat}} to collect data about {{kib}} and ship it to the monitoring cluster.
 
 To learn about monitoring in general, refer to [](/deploy-manage/monitor/stack-monitoring.md).
 

deploy-manage/monitor/stack-monitoring/kibana-monitoring-metricbeat.md

@@ -24,6 +24,17 @@ Remote clusters are especially useful in two cases:
 In the case of remote clusters, the {{es}} cluster or deployment initiating the connection and requests is often referred to as the **local cluster**, while the {{es}} cluster or deployment receiving the requests is referred to as the **remote cluster**.
 ::::
 
+## Security models and connection modes
+
+When configuring remote clusters, you can choose between two security models and two connection modes. Both security models are compatible with either connection mode.
+
+- [Security models](./remote-clusters/security-models.md): API key–based authentication (recommended) or TLS certificate–based authentication (deprecated).
+- [Connection modes](./remote-clusters/connection-modes.md): Sniff mode (direct connections to {{es}} nodes) or proxy mode (connections through a reverse proxy or load balancer endpoint).
+
+::::{note}
+In managed or orchestrated environments, such as {{ech}}, {{ece}}, and {{eck}}, you can select the security model, but the connection mode is effectively limited to *proxy*. This is because sniff mode requires {{es}} nodes publish addresses to be directly reachable across clusters, which is generally not practical in containerized deployments.
+::::
+
 ## Setup
 
 Depending on the environment the local and remote clusters are deployed on and the security model you wish to use, the exact details needed to add a remote cluster vary but generally follow the same path:

deploy-manage/remote-clusters.md

@@ -0,0 +1,44 @@
+---
+navigation_title: Connection modes
+applies_to:
+  stack: ga
+  serverless: unavailable
+products:
+  - id: elasticsearch
+---
+# Remote cluster connection modes
+
+When you configure a remote cluster, the local cluster needs a way to connect to the nodes of the remote cluster. {{es}} supports two connection modes to handle different network architectures:
+
+- **Proxy mode**: The local cluster connects through a reverse proxy or load balancer, which forwards traffic to the appropriate nodes in the remote cluster. You can configure this mode using either the {{kib}} UI or the {{es}} API.
+- **Sniff mode**: The local cluster discovers the remote cluster’s gateway nodes and connects to them directly. This mode can only be configured using the {{es}} API.
+
+::::{note}
+Connection modes work independently of [security models](./security-models.md). Both connection modes are compatible with either security model.
+::::
+
+The choice between proxy and sniff mode depends on your network architecture and deployment type.  
+
+- **Self-managed clusters:** If direct connections on the publish addresses between {{es}} nodes in both clusters are possible, you can use sniff mode. If direct connectivity is difficult to implement—for example, when clusters are separated by NAT, firewalls, or containerized environments—you can place a reverse proxy or load balancer in front of the remote cluster and use proxy mode instead.  
+
+- **Managed environments ({{ece}}, {{ech}}, {{eck}}):** Direct node-to-node connectivity is generally not feasible, so these deployments always rely on the proxy connection mode.
+
+The following sections describe each method in more detail.
+
+## Proxy mode
+
+In proxy mode, a cluster alias is registered with a name of your choosing and the address of a TCP (layer 4) reverse proxy specified with the `cluster.remote.<cluster_alias>.proxy_address` setting. You must configure this proxy to route connections to one or more nodes of the remote cluster. The service port to forward traffic to depends on the [security model](./security-models.md) in use, as each model uses a different service port.
+
+When you register a remote cluster using proxy mode, {{es}} opens several TCP connections to the proxy address and uses these connections to communicate with the remote cluster. In proxy mode, {{es}} disregards the publish addresses of the remote cluster nodes, which means that the publish addresses of the remote cluster nodes do not need to be accessible to the local cluster.
+
+Proxy mode is not the default connection mode when adding remotes using the {{es}} API, so you must set `cluster.remote.<cluster_alias>.mode: proxy` to use it. Refer to [Proxy mode remote cluster settings](elasticsearch://reference/elasticsearch/configuration-reference/remote-clusters.md#remote-cluster-proxy-settings) for more information about configuring proxy mode.
+
+::::{note}
+Remote clusters configured through **{{kib}}** support only proxy mode. You can’t select a connection mode or configure sniff mode from the UI.
+::::
+
+## Sniff mode
+
+In sniff mode, a cluster alias is registered with a name of your choosing and a list of addresses of *seed* nodes specified with the `cluster.remote.<cluster_alias>.seeds` setting. When you register a remote cluster using sniff mode, {{es}} retrieves from one of the seed nodes the addresses of up to three *gateway nodes*. Each `remote_cluster_client` node in the local {{es}} cluster then opens several TCP connections to the publish addresses of the gateway nodes. This mode therefore requires that the gateway nodes' publish addresses are accessible to nodes in the local cluster.
+
+Sniff mode is the default connection mode when adding a remote cluster through the {{es}} API. Refer to [Sniff mode remote cluster settings](elasticsearch://reference/elasticsearch/configuration-reference/remote-clusters.md#remote-cluster-sniff-settings) for more information about configuring sniff mode.