[helm] add kube-state-metric subchart dependency

[pkoutsovasilis]

What does this PR do?

This PR refactors the Elastic Agent Helm chart to include the kube-state-metrics (KSM) chart as a subchart dependency. The changes enable users to seamlessly deploy KSM alongside the Elastic Agent for all different deployment options, improving the out-of-the-box experience for Kubernetes monitoring.

Key changes include:

• Addition of the KSM Helm chart as a subchart dependency.
• Introduction of values that allow enabling or disabling KSM deployment (kube-state-metrics.enabled) and deploying Elastic Agent as a sidecar container to the former (kubernetes.state.agentAsSidecar.enabled)
  • PS: now that kube-state-metrics derive from another subchart deploying elastic-agent through ECK as a sidecar is not feasible. values.schema.json has been updated to prevent such configuration
• Refactoring of the Helm chart structure to incorporate KSM configurations and clean-up unused code.
  • The templates that regard the input of kube-state-metrics in kubernetes integration got significantly reduced resulting in an easier to follow code
  • The templates that regard the k8s tuning of each preset based on the Helm values got migrated to a separate folder to promote segregation from input-related templates, thus resulting in an easier to follow code

This PR consists of 3 commits:

• 546ec26 just introduce the kube-state-metric subchart dependency
• 27748fa the actual changes of this PR
• a019dbf examples showcasing the new functionality

since a019dbf, which is the main change of this PR, is +529 additions -1268 deletions I deem that this PR complies with the team PR policies but happy to try to split it up in smaller chunks if it doesn't 🙂

Why is it important?

This PR is important because it enhances the Elastic Agent Helm chart to simplify the deployment and management of Kubernetes monitoring. By including kube-state-metrics as a subchart dependency, the PR significantly reduces user friction and ensures better alignment with Kubernetes integration requirements.

The refactoring also:

• Improves maintainability by reducing template complexity and segregating logic for better readability.
• Provides flexibility for users to enable or disable KSM and enable or disable embedding elastic-agent as a sidecar to the former, catering to diverse use cases.

Checklist

• I have read and understood the pull request guidelines of this project.
• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• 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

This PR introduces a new default behavior that includes the kube-state-metrics chart as a dependency. By default:

• kube-state-metrics is deployed. Users must explicitly disable it by setting kube-state-metrics.enabled=false to opt out of deploying
• all kube-state-metrics related metrics are now captured by the cluster-wide agent preset. Users opting to deploy elastic-agent as a sidecar to kube-state-metrics must explicitly enable it in the values file by setting kubernetes.state.agentAsSidecar.enabled=true.
• Unsupported configurations, such as deploying Elastic Agent as a sidecar to KSM managed by ECK, are now restricted.

For users upgrading existing installations, ksmSharded preset is gonna be uninstalled and their kube-state-metrics related flow will follow the logic above

How to test this PR locally

• Follow one of the newly introduced examples
• Run k8s integration tests

  mage integration:auth
  PLATFORMS=linux/arm64 EXTERNAL=true SNAPSHOT=true PACKAGES=docker mage -v package 
  INSTANCE_PROVISIONER=kind STACK_PROVISIONER=stateful K8S_VERSION=v1.31.1 SNAPSHOT=true mage integration:kubernetes
  

Related issues

• Relates Fleet managed Elastic Agent installation with Helm Chart missing topics ingest-docs#1531

[elasticmachine]

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

[blakerouse]

Looks good to me. Just a question on the dependency keeping in sync with release.

[blakerouse]

Are we going to add any automation to keep this in-sync with released versions or is this going to be manual?

[pkoutsovasilis]

good point 👌 I have to investigate how we could employ renovate to do that 🙂 do you believe this could be a follow-up PR?

[blakerouse]

absolutely, in a follow up

this is already large enough ;-)

[swiatekm]

Looks good to me. I flagged some minor typos. I've also noticed that we're committing charts/ - that should be in .gitignore in my opinion.

[pkoutsovasilis]

Hey @swiatekm 👋 so just to understand, you are against committing charts/ however to me having it in the repo, it allows a developer/CI run to install the Helm chart directly from the diskpath. If charts/kube-state-metric-*.tgz is missing then you have either helm depedency build or helm package before being able to install the helm chart. And to this exact end, having it in our repo makes our CI potentially less flaky as there are no external dependencies to be downloaded during helm install. So what is your proposal on these points if we don't commit it?

[swiatekm]

Hey @swiatekm 👋 so just to understand, you are against committing charts/ however to me having it in the repo, it allows a developer/CI run to install the Helm chart directly from the diskpath. If charts/kube-state-metric-*.tgz is missing then you have either helm depedency build or helm package before being able to install the helm chart. And to this exact end, having it in our repo makes our CI potentially less flaky as there are no external dependencies to be downloaded during helm install. So what is your proposal on these points if we don't commit it?

What you're proposing is vendoring the Helm Chart's dependencies. I'm not opposed to that in principle, but is there any particular reason to do it here, and not for the agent application itself? Package managers exist so dependencies can be installed in a reproducible and consistent manner. Users will install this Chart from a Helm repo, and I don't see much reason why we wouldn't require developers to do the same.

Separately, it's another artifact we'd have to keep in sync with Chart.lock.

[pkoutsovasilis]

Separately, it's another artifact we'd have to keep in sync with Chart.lock.

I am not quite sure I understand why the above is an issue; in my thinking we could employ renovate to keep this in sync?

But again what is the counter-proposal here? Specifically, how should we change the Helm render examples, integration framework, etc. to accommodate for the chart/* to be omitted?

[pkoutsovasilis]

@swiatekm 👋 As agreed after our offline sync here is the commit 3349bb0 that allows us to not have the chart/* inside the elastic-agent chart but makes sure that our mage targets and CI tests build the chart dependencies properly

[swiatekm]

👍

[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