Skip to content

[ECK] Update documentation for 3.1.0 #2019

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 12 commits into from
Jul 30, 2025
Merged

[ECK] Update documentation for 3.1.0 #2019

Show file tree
Hide file tree
Changes from 5 commits
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
b696c13
Docs for Fleet advanced config in ECK (#1446)
pebrc May 22, 2025
8f9ab83
Merge remote-tracking branch 'origin/main' into eck-3.1.0
barkbay Jul 3, 2025
9eb86fc
Update supported versions
barkbay Jul 3, 2025
02d6b31
Update ECK version in docset.yml
barkbay Jul 3, 2025
a87dc88
Merge remote-tracking branch 'origin/main' into eck-3.1.0
barkbay Jul 16, 2025
a2b1869
ECK: Document annotations and labels propagation (#2144)
barkbay Jul 17, 2025
8bfed5d
Keep supported versions for 3.0 available
barkbay Jul 17, 2025
10267d2
fix applies_to syntax
barkbay Jul 17, 2025
9138b0d
Test tabs
barkbay Jul 17, 2025
8359ee0
Include CSP and Helm info in the tabs
barkbay Jul 21, 2025
fb200bd
Merge remote-tracking branch 'origin/main' into eck-3.1.0
barkbay Jul 29, 2025
eb216f8
Merge branch 'main' into eck-3.1.0
eedugon Jul 30, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions deploy-manage/deploy/cloud-on-k8s.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -69,8 +69,8 @@ This section outlines the supported Kubernetes and {{stack}} versions for ECK. C

ECK is compatible with the following Kubernetes distributions and related technologies:

* Kubernetes 1.28-1.32
* OpenShift 4.14-4.18
* Kubernetes 1.29-1.33
* OpenShift 4.15-4.19
* Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), and Amazon Elastic Kubernetes Service (EKS)
* Helm: {{eck_helm_minimum_version}}+
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because these docs are going to continue to be valid for 3.0, we need to keep the 3.0 compatibility in this doc present.

could do it in tabs, table, or bulleted list. quickest hack would be:

Suggested change
* Kubernetes 1.29-1.33
* OpenShift 4.15-4.19
* Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), and Amazon Elastic Kubernetes Service (EKS)
* Helm: {{eck_helm_minimum_version}}+
* Kubernetes:
* {applies_to}`eck: 3.0`: 1.28-1.32
* {applies_to}`eck: 3.1`: 1.29-1.33
* OpenShift
* {applies_to}`eck: 3.0`: 4.14-4.18
* {applies_to}`eck: 3.1`: 4.15-4.19
* Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), and Amazon Elastic Kubernetes Service (EKS)
* Helm: {{eck_helm_minimum_version}}+

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could do it in tabs, table, or bulleted list. quickest hack would be:

I think tabs would be the most appropriate, but let's try your suggestion first.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

I'll now try the tabs...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tab variant:

image

I think I'll stick with tabs, happy to get feedbacks though

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any option is fine. I like both.
The list will probably not scale well when having 8-10 releases to mention, so better the tabs for that reason probably.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO, the tabs are not user friendly if the user knows his k8s version and wants to find out which ECK version he needs

Not a strong argument but this is already the case today. Also I can only remember users asking if the last version of K8s or OpenShift is supported by ECK. My feeling is that we're going to have to revisit this in the future, whatever our choice is today.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyways, I created this issue: elastic/docs-builder#1570

Maybe this could be a case for it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we go with tabs, the whole list will need to go in the tabs, because it's weird to split a list between tabs and not tabs

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looking at the mock of the bulleted list, I think removing the colon would make it look right if you were still considering using it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we go with tabs, the whole list will need to go in the tabs, because it's weird to split a list between tabs and not tabs

Makes sense, I'll do the change


Expand Down
17 changes: 16 additions & 1 deletion deploy-manage/deploy/cloud-on-k8s/configuration-fleet.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -146,8 +146,23 @@ By default, every reference targets all instances in your {{es}}, {{kib}} and {{

## Customize {{agent}} configuration [k8s-elastic-agent-fleet-configuration-custom-configuration]

In contrast to {{agents}} in standalone mode, the configuration is managed through {{fleet}}, and it cannot be defined through `config` or `configRef` elements.
In contrast to {{agents}} in standalone mode, the configuration is managed through {{fleet}}, and it cannot be defined through `config` or `configRef` elements with a few exceptions.

One of those exceptions is the configuration of providers as described in [advanced Agent configuration managed by Fleet](/reference/fleet/advanced-kubernetes-managed-by-fleet.md). When {{agent}} is managed by {{fleet}} and is orchestrated by ECK, the configuration of providers can simply be done through the `.spec.config` element in the Agent resource as of {applies_to}`stack: ga 8.13`:
Copy link
Contributor

@eedugon eedugon Jul 15, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@barkbay : what do we mean with the applies_to stack 8.13 here? That the providers configuration can be done only for Agents running 8.13 or later?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
One of those exceptions is the configuration of providers as described in [advanced Agent configuration managed by Fleet](/reference/fleet/advanced-kubernetes-managed-by-fleet.md). When {{agent}} is managed by {{fleet}} and is orchestrated by ECK, the configuration of providers can simply be done through the `.spec.config` element in the Agent resource as of {applies_to}`stack: ga 8.13`:
One of those exceptions is the configuration of providers as described in [advanced Agent configuration managed by Fleet](/reference/fleet/advanced-kubernetes-managed-by-fleet.md). Starting in stack version 8.13, if {{agent}} is managed by {{fleet}} and orchestrated by ECK, you can configure providers using the `.spec.config` element in the Agent resource:

Possible version switching the 8.13 statement to the narrative side.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This content was already reviewed here without notes: #1446

Copy link
Contributor

@eedugon eedugon Jul 15, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @pebrc for the extra details!

My opinion is still the same but of course it's not a big deal. Also when we reviewed the linked PR, I think the applies_to was added in a later commit, as otherwise I'd probably have highlighted it.

Anyway the current text and usage of the badge is all right too, so whatever you want.
cc: @shainaraskas

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can totally change it to whatever makes most sense from a docs perspective.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect, let's allow @shainaraskas to share her thoughts for a final decision :)

Shaina, do you like the usage of the inline badge there? I don't feel it very intuitive and I've suggested to change it to a narrative sentence, but maybe both approaches are fine.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that this is not ideal, partially because our labels don't look right in sentences.

one reason this is hard to reframe is that this is positioned as "one of these exceptions" - is this the only exception? are exceptions only valid as of 8.13?

this could get an Exceptions subheading that has an applies label at the heading level, ideally, if it makes sense.

if that doesn't make sense, I'd go with prose inline or a note inline. we'll have to refactor it later when we have more components at our disposal, but will read better in the short term.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I approved this PR already but some ECK 3.1 tagging should be added here before this is shipped


```yaml
apiVersion: agent.k8s.elastic.co/v1alpha1
kind: Agent
metadata:
name: elastic-agent
spec:
config:
fleet:
enabled: true
providers.kubernetes:
add_resource_metadata:
deployment: true
```

## Upgrade the {{agent}} specification [k8s-elastic-agent-fleet-configuration-upgrade-specification]

Expand Down
4 changes: 2 additions & 2 deletions docset.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,3 @@
project: 'Elastic documentation'
max_toc_depth: 2

Expand Down Expand Up @@ -280,8 +280,8 @@
kib-pull: "https://github.com/elastic/kibana/pull/"
stack-version: "9.0.3"
ece_version: "4.0.1"
eck_version: "3.0.0"
eck_release_branch: "3.0"
eck_version: "3.1.0"
eck_release_branch: "3.1"
eck_helm_minimum_version: "3.2.0"
eck_resources_list: "Elasticsearch, Kibana, APM Server, Beats, Elastic Agent, Elastic Maps Server, and Logstash"
eck_resources_list_short: "APM Server, Beats, Elastic Agent, Elastic Maps Server, and Logstash"
Expand Down
1 change: 1 addition & 0 deletions reference/fleet/advanced-kubernetes-managed-by-fleet.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -106,4 +106,5 @@ volumes:

1. By default the manifests for {{agent}} managed by {{fleet}} have `hostNetwork:true`. In order to support multiple installations of {{agent}}s in the same node you should set `hostNetwork:false`. See this relevant [example](https://github.com/elastic/elastic-agent/tree/main/docs/manifests/hostnetwork) as described in [{{agent}} Manifests in order to support Kube-State-Metrics Sharding](https://github.com/elastic/elastic-agent/blob/main/docs/elastic-agent-ksm-sharding.md).
2. The volume `/usr/share/elastic-agent/state` must remain mounted in [elastic-agent-managed-kubernetes.yaml](https://github.com/elastic/elastic-agent/blob/main/deploy/kubernetes/elastic-agent-managed-kubernetes.yaml), otherwise custom config map provided above will be overwritten.
3. If {{agent}} is deployed through ECK, you can define the provider configuration in the `spec.config` field of the Kubernetes custom resource. Refer to [{{fleet}}-managed {{agent}} on ECK](/deploy-manage/deploy/cloud-on-k8s/configuration-fleet.md) for details.

Loading