Merge branch 'main' into issue-3536

Author: colleenmcginnis

.github/workflows/update-kube-stack-version.yml

@@ -36,7 +36,7 @@ jobs:
     - name: Run update script
       id: update-script
       run: |
-        echo "Running kube-stack-version update script..."
+        echo "Running version update script (kube-stack-version and helm-version)..."
         python scripts/update_kube_stack_version.py
         echo "Script completed successfully"
 
@@ -60,19 +60,22 @@ jobs:
       uses: peter-evans/create-pull-request@v7
       with:
         token: ${{ secrets.GITHUB_TOKEN }}
-        commit-message: 'chore: update kube-stack-version'
-        title: 'chore: update kube-stack-version'
+        commit-message: 'chore: update kube-stack-version and helm-version'
+        title: 'chore: update kube-stack-version and helm-version'
         body: |
-          This PR automatically updates the `kube-stack-version` in `docset.yml` based on the latest version from the elastic-agent repository.
+          This PR automatically updates the `kube-stack-version` and `helm-version` in `docset.yml` based on the latest versions from the Kibana and Elastic Agent repositories.
           
           **Changes:**
-          - Updated `kube-stack-version` to the latest value from elastic-agent repository
+          - Updated `kube-stack-version` to the latest value from the Kibana repository
+          - Updated `helm-version` to the latest value from the Elastic Agent repository
           
           **Generated by:** [Update Kube Stack Version workflow](https://github.com/${{ github.repository }}/actions/workflows/update-kube-stack-version.yml)
           
           This is an automated update. Please review the changes before merging.
         branch: update-kube-stack-version
         delete-branch: true
+        team-reviewers: |
+          ingest-docs
         labels: |
           automated
           chore
@@ -91,7 +94,7 @@ jobs:
           git diff HEAD -- docset.yml >> $GITHUB_STEP_SUMMARY
           echo '```' >> $GITHUB_STEP_SUMMARY
         else
-          echo "ℹ️ **No changes needed** - kube-stack-version is already up to date" >> $GITHUB_STEP_SUMMARY
+          echo "ℹ️ **No changes needed** - kube-stack-version and helm-version are already up to date" >> $GITHUB_STEP_SUMMARY
         fi
 
     - name: Summary
@@ -102,5 +105,5 @@ jobs:
         if [ "${{ steps.check-changes.outputs.has_changes }}" == "true" ]; then
           echo "✅ **PR Created** - Changes detected and pull request created" >> $GITHUB_STEP_SUMMARY
         else
-          echo "ℹ️ **No changes needed** - kube-stack-version is already up to date" >> $GITHUB_STEP_SUMMARY
+          echo "ℹ️ **No changes needed** - kube-stack-version and helm-version are already up to date" >> $GITHUB_STEP_SUMMARY
         fi

.gitignore

@@ -9,10 +9,10 @@
 # Add LLM/AI related files
 AGENTS.md
 .github/copilot-instructions.md
-.github/instructions/**.instructions.md
+.github/instructions
 CLAUDE.md
 GEMINI.md
 .cursor
 
 # VS code settings
-.vscode
+.vscode

deploy-manage/_snippets/autoops-callout-with-ech.md

@@ -1,5 +1,4 @@
 :::{admonition} Simplify monitoring with AutoOps
-Use AutoOps in your {{ech}}, ECE, ECK, or self-managed deployments. 
-
-AutoOps is a monitoring tool that simplifies cluster management through performance recommendations, resource utilization visibility, and real-time issue detection with resolution paths. For more information, refer to [](/deploy-manage/monitor/autoops.md).
-::::
+:applies_to: { ess:, ece:, eck:, self:, "serverless": "ga" }
+AutoOps is a monitoring tool that simplifies cluster management through performance recommendations, resource utilization visibility, and real-time issue detection with resolution paths. Learn more about [](/deploy-manage/monitor/autoops.md).
+:::

deploy-manage/_snippets/autoops-cc-ech-faq.md

@@ -1,3 +1,3 @@
 This path is not supported. Currently, we only support using Cloud Connect to connect ECE, ECK, and self-managed clusters to AutoOps.
 
-For {{ech}} clusters, AutoOps is set up and enabled automatically in all supported [regions](/deploy-manage/monitor/autoops/ec-autoops-regions.md), and can be [accessed](/deploy-manage/monitor/autoops/ec-autoops-how-to-access.md#ec-autoops-how-to-access) from the deployment overview page.
+For {{ech}} deployments, AutoOps is set up and enabled automatically in all supported [regions](/deploy-manage/monitor/autoops/ec-autoops-regions.md), and can be [accessed](/deploy-manage/monitor/autoops/ec-autoops-how-to-access.md) from the deployment overview page.

deploy-manage/api-keys/elastic-cloud-api-keys.md

@@ -34,9 +34,11 @@ These keys provides access to the API that enables you to manage your deployment
 
     ::::{note}
     When an API key is nearing expiration, Elastic sends an email to the creator of the API key and each of the operational contacts. When you use an API key to authenticate, the API response header `X-Elastic-Api-Key-Expiration` indicates the key’s expiration date. You can log this value to detect API keys that are nearing expiration.
+
+    Once an API key expires, it will automatically be removed from the API Keys tab.
     ::::
 
-5. Click **Create API key**, copy the generated API key, and store it in a safe place. You can also download the key as a CSV file.
+6. Click **Create API key**, copy the generated API key, and store it in a safe place. You can also download the key as a CSV file.
 
 The API key needs to be supplied in the `Authorization` header of a request, in the following format:
 

deploy-manage/deploy/cloud-enterprise/ece-networking-prereq.md

@@ -16,9 +16,9 @@ For versions 2.4.0 and 2.4.1, IPv6 should remain enabled on any host with the Pr
 
 * [Inbound traffic](#ece-inbound)
 * [Outbound traffic](#ece-outbound)
+* [Container communication on the same host](#ece-container-communication-on-same-host)
 * [Hosts in multiple data centers](#ece-multiple-data-centers)
 
-
 ## Inbound traffic [ece-inbound]
 
 When there are multiple hosts for each role, the inbound networking and ports can be represented by the following diagram:
@@ -68,6 +68,21 @@ Outbound traffic must also permit connections to the [snapshot repositories](../
 ::::
 
 
+## Container communication on the same host [ece-container-communication-on-same-host]
+
+The following ports need to be open for containers communicating with the host or with each other on the same host:
+
+| Port(s) | Purpose | Host role |
+| --- | --- | --- |
+| 53 | DNS resolver | All roles |
+| 2180 | ZooKeeper admin port | All roles |
+| 2375 | Docker admin port | All roles |
+| 2191-2199 | Debug ports | Director |
+| 5000-5010 | Java Virtual Machine (JVM)/debug ports | All roles |
+| 8080-8084 | Health/monitoring ports | All roles |
+| 9000, 9043 | Internal proxy use | Proxy |
+| 9244 | Internal proxy port | All roles |
+
 
 ## Hosts in multiple data centers [ece-multiple-data-centers]
 

deploy-manage/deploy/cloud-on-k8s/pod-disruption-budget.md

@@ -19,12 +19,13 @@ In {{eck}} 3.1 and earlier, all clusters follow the [default PodDisruptionBudget
 :::
 
 ## Advanced rules (Enterprise license required)
+
 ```{applies_to}
 deployment:
   eck: ga 3.2
 ```
 
-In Elasticsearch clusters managed by ECK and licensed with an Enterprise license, a separate PDB is created for each type of `nodeSet` defined in the manifest. This setup allows Kubernetes upgrade or maintenance operations to be executed more quickly. Each PDB permits one Elasticsearch Pod per `nodeSet` to be disrupted at a time, provided the Elasticsearch cluster maintains the health status described in the following table:
+In {{es}} clusters managed by ECK and licensed with an Enterprise license, PDBs are created based on {{es}} node roles, allowing Kubernetes upgrade or maintenance operations to be executed more quickly. Multiple `nodeSets` with the same roles, such as `master` or `ml`, are combined into a single PDB. Each PDB permits one {{es}} Pod to be disrupted at a time, provided the {{es}} cluster maintains the health status described in the following table.
 
 | Role | Cluster health required | Notes |
 |------|------------------------|--------|
@@ -40,6 +41,7 @@ In Elasticsearch clusters managed by ECK and licensed with an Enterprise license
 Single-node clusters are not considered highly available and can always be disrupted regardless of license type.
 
 ## Default rules (Basic license) [default-pdb-rules]
+
 :::{note}
 In {{eck}} 3.1 and earlier, all clusters follow this behavior regardless of license type.
 :::

deploy-manage/deploy/elastic-cloud/serverless.md

@@ -20,7 +20,7 @@ products:
 Serverless projects use the core components of the {{stack}}, such as {{es}} and {{kib}}, and are based on an architecture that decouples compute and storage. Search and indexing operations are separated, which offers high flexibility for scaling your workloads while ensuring a high level of performance.
 
 :::{note}
-There are differences between {{es-serverless}} and {{ech}}, for a list of differences between them, see [differences between {{ech}} and {{es-serverless}}](../elastic-cloud.md#general-what-is-serverless-elastic-differences-between-serverless-projects-and-hosted-deployments-on-ecloud).
+There are differences between {{es-serverless}} and {{ech}}. Learn more in [Compare {{ech}} and {{es-serverless}}](../elastic-cloud.md#general-what-is-serverless-elastic-differences-between-serverless-projects-and-hosted-deployments-on-ecloud).
 :::
 
 ## Get started
@@ -55,6 +55,9 @@ Afterwards, you can:
   * **Data:** Choose the data you want to ingest and the method to ingest it. By default, data is stored indefinitely in your project, and you define the retention settings for your data streams.
   * **Performance:** For granular control over costs and query performance against your project data, serverless projects come with a set of predefined settings you can edit.
 
+:::{include} /deploy-manage/_snippets/autoops-callout-with-ech.md
+:::
+
 ## Monitor serverless status [general-serverless-status]
 
 Serverless projects run on cloud platforms, which may undergo changes in availability. When availability changes, Elastic makes sure to provide you with a current service status.

deploy-manage/monitor.md

@@ -24,7 +24,7 @@ Depending on your deployment type, you can use a variety of solutions for monito
 
 You have several options for monitoring your cluster or deployment.
 
-Use [AutoOps](/deploy-manage/monitor/autoops.md) in your {{ech}}, ECE, ECK, or self-managed deployments. AutoOps is a monitoring tool that simplifies cluster management through performance recommendations, resource utilization visibility, and real-time issue detection with resolution paths. 
+Use [](/deploy-manage/monitor/autoops.md) to simplify cluster management through performance recommendations, resource utilization visibility, and real-time issue detection with resolution paths. 
 
 Alternatively, you can use [Stack Monitoring](/deploy-manage/monitor/stack-monitoring.md) to monitor logs and metrics across the {{stack}}.
 
@@ -47,7 +47,8 @@ deployment:
 
 AutoOps diagnoses issues in {{es}} by analyzing hundreds of metrics, providing root-cause analysis and accurate resolution paths. With AutoOps, customers can prevent and resolve issues, cut down administration time, and optimize resource utilization.
 
-In the [regions](/deploy-manage/monitor/autoops/ec-autoops-regions.md) where it has been rolled out, AutoOps is automatically available in [{{ech}} deployments](/deploy-manage/monitor/autoops/ec-autoops-how-to-access.md) and [{{serverless-full}} projects](/deploy-manage/monitor/autoops/autoops-for-serverless.md), and can be set up for [ECE, ECK, and self-managed clusters](/deploy-manage/monitor/autoops/cc-autoops-as-cloud-connected.md).
+:::{include} /deploy-manage/monitor/_snippets/autoops-availability.md
+:::
 
 ### Stack monitoring
 

deploy-manage/monitor/_snippets/autoops-availability.md

@@ -0,0 +1 @@
+AutoOps is automatically available in [{{ech}} deployments](/deploy-manage/monitor/autoops/ec-autoops-how-to-access.md) and [{{serverless-full}} projects](/deploy-manage/monitor/autoops/autoops-for-serverless.md), and can be set up for [ECE, ECK, and self-managed clusters](/deploy-manage/monitor/autoops/cc-autoops-as-cloud-connected.md) through Cloud Connect.