Merge branch 'main' into eck-3.2.0

Author: rhr323

.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 @@
+The API key created previously will be used by the local deployment to authenticate with the corresponding set of permissions to the remote deployment. For that, you need to add the API key to the local deployment's keystore.