docs: add EDOT colletor kube-stack Helm values

[rogercoll]

What does this PR do?

Adds a sample configuration to be used when deploying the OpenTelemetry Kube Stack Helm Chart.

Why is it important?

This configuration will be used during the Elastic K8s Onboarding experience starting from 8.16. The EDOT collector is the central piece of the whole Chart deployment, if we provide an invalid image or collector's configuration, the deployment will fail.

The file is currently hosted in the elastic/opentelemetry repository, but this files needs to be versioned as it is tied to the stack's (elastic-agent) release version. The elastic/opentelemetry repository does not have a release strategy (neither backport) yet, thus, and being the EDOT collector the backbone of the deployment, we think that hosting this file in this repository would be more appropriate.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas: TODO task listed to do during the 8.16 FF phase
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in ./changelog/fragments using the changelog tool
• I have added an integration test or an E2E test

Disruptive User Impact

No

How to test this PR locally

Added a README.md file an installation section.

Related issues

Questions to ask yourself

• How are we going to support this in production?
• How are we going to measure its adoption?
• How are we going to debug this?
• What are the metrics I should take care of?
• ...

[mergify]

This pull request does not have a backport label. Could you fix it @rogercoll? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-./d./d is the label to automatically backport to the 8./d branch. /d is the digit

[mergify]

backport-v8.x has been added to help with the transition to the new branch 8.x.
If you don't need it please use backport-skip label and remove the backport-8.x label.

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[gizas]

I would update the path to values.yaml relative to what will be in this folder
So not ./resources/kubernetes/operator/helm/values.yaml rather /deploy/helm ....

[rogercoll]

Good point, I think I would prefer to keep it relative to the README's directory: 89cd2a6

[gizas]

nit: Dont have strong preference, wondering if we need the extra subfolder kube-stack.
Now is : deploy/helm/edot-collector/kube-stack/

[rogercoll]

nit: Dont have strong preference, wondering if we need the extra subfolder kube-stack. Now is : deploy/helm/edot-collector/kube-stack/

Not a strong opinion neither, maybe having the extra directory will be easier for us to add extra Helm Charts. Open to any suggestion

[rogercoll]

@eedugon Adding you as reviewer in case you want to share your feedback about the values path or anything related to the PR. Thanks!

[pkoutsovasilis]

@rogercoll while I am still reading through this PR, I have the following questions on top of my head:

• since this is another "deployment artifact" of elastic-agent an integration test should be part of this PR that tests at least that the agent pod is getting deployment and get healthy; is there any that I missed?!
• how do you plan to keep the agent version updated in the values.yaml?!

[rogercoll]

since this is another "deployment artifact" of elastic-agent an integration test should be part of this PR that tests at least that the agent pod is getting deployment and get healthy; is there any that I missed?!

Totally agree, is there any example I can look into?

how do you plan to keep the agent version updated in the values.yaml?!

I was thinking on Renovate. Not very familiar with the elastic-agent code, I will take look

[pkoutsovasilis]

Totally agree, is there any example I can look into?

You can look here I believe that with a few minor changes you can definitely test the EDOT helm chart

I was thinking on Renovate. Not very familiar with the elastic-agent code, I will take look

To be honest I am not super familiar with Renovate, maybe now we could the reverse of the above and you give me a PR/code link so I can have a look and get more familiar with it? 🙂

[rogercoll]

To be honest I am not super familiar with Renovate, maybe now we could the reverse of the above and you give me a PR/code link so I can have a look and get more familiar with it? 🙂

https://github.com/open-telemetry/opentelemetry-demo/blob/main/renovate.json5#L113
In the shared file, Renovate is configured to find the defined container images using regular expressions and later on create a PR to bump the version if needed.

Is there any other tool already available to do that? How PRs like #4592 are created?

[swiatekm]

To @pkoutsovasilis' point, I'd either comment this out or put a placeholder here, and assume implicitly that the agent version from the git revision applies. Otherwise we'll need to keep updating it via tooling on every active branch, and it's going to be very annoying. Even in this PR, it should be 8.17.0 - there's already a separate branch for 8.16.

Not sure how much of a problem this will be for Kibana. Maybe they can just fill the stack version in here?

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube