[Kubernetes Module] Add missing metrics for replicaset and pod owners

[gizas]

• Enhancement

Proposed commit message

• WHAT: We add information regarding the owner of pod and replicaset assets that was missing from Kube State Metrics endpoint.
• WHY: We disable the metadata enrichemnt for deployments and replicasets by default as per Disable Deployment and Replicaset enrichment by default elastic-agent-autodiscover#62. This means that our pods (either from deployments or cronjobs) wont have the needed information for the resource that creates them. We plan to fix this by introducsing relevant owner fields in state_pod and state_replicaset metricsets

Checklist

• 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.next.asciidoc or CHANGELOG-developer.next.asciidoc.

How to test this PR locally

1. Build metricbeat as per instructions here
   This will copy your new metricbeat executable into the kubernetes cluster you want to observe
2. Login to your Elastic Stack (where metricbeat of previous step sends data) and create a new Dataview for metricbeat-* indices.
3. Observe the new kubernetes.replicaset.replicas.owner.* and kubernetes.pod.owner.* fields

Related issues

• Relates #add_resource_metadata.cronjob overloads the memory usage elastic-agent-autodiscover#31

Screenshots

For Pod that owner is node:

For Pod that owner is replicaset:

For replicaset that owner is deployment:

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @gizas? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

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

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-10-06T12:05:05.642+0000

• Duration: 52 min 42 sec

Test stats 🧪

Test	Results
Failed	0
Passed	4436
Skipped	902
Total	5338

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[constanca-m]

Based on the fact that there was no change in the asciidoc file, I think you forgot to run mage update on the metricbeat folder @gizas

[gizas]

Based on the fact that there was no change in the asciidoc file, I think you forgot to run mage update on the metricbeat folder @gizas

Yes sorry for that Constanca, I opened the PR more as a draft in order to showcase the changes needed. I will push latest changes and also make the tests today

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b metadataowners upstream/metadataowners
git merge upstream/main
git push upstream metadataowners

[ChrsMark]

@gizas would that PR add 2nd layer controller/owner's information?
The 1st owner's information is provided already through the Metadata's Enricher at https://github.com/elastic/elastic-agent-autodiscover/blob/2cc3dcb075fe437467387d36096f554c13c6d144/kubernetes/metadata/resource.go#L138-L152.
So if this PR is only to cover the 1st layer owner's metadata then it seems it's already supported and the PR is redundant?

[ChrsMark]

How this would replace the disabled addition of the kubernetes.deployment field? This only adds the first level owner so in a case of Deploymenyt->ReplicaSet->Pod it won't add the Deployment information, right?

Also this is happening already supported through the Metadata Enricher -> https://github.com/elastic/elastic-agent-autodiscover/blob/2cc3dcb075fe437467387d36096f554c13c6d144/kubernetes/metadata/resource.go#L138-L152

[gizas]

It does not add the deployment name correct only 1st level, you are right.

I was thinking that we can justify that this is enough for the users in order to figure out the reference. Of course we need to document this. Otherwise even if we can try in code or with ingest pipelines to trim the strings and produce ancestors we might fall in mistakes because we are not sure for the existance.

Also if we integrate this elastic/elastic-agent-autodiscover#62, this means that also the enrichers will loose those metadata is not it?

[ChrsMark]

Through the Enricher every metrics' document for Pod's like pod.cpu.usage will be enriched with Pod's metadata. In this metadata the Enricher adds the owner name like kubernetes.cronjob.name, kubernetes.replicaset.name etc. So this is not related to the settings you change at elastic/elastic-agent-autodiscover#62. That's a diffrent feature takes place at https://github.com/elastic/elastic-agent-autodiscover/blob/2cc3dcb075fe437467387d36096f554c13c6d144/kubernetes/metadata/pod.go#L96-L122.

So still this patch seems to be redundant.
Could you try to run Metricbeat with k8s module enabled and see that Pod's metrics are enriched with the owner name (disable the deployment and cronjob metadata as usually to isolate the functionality)? This will help you understand how the feature works and that this patch actually overlaps already existent information.

[gizas]

So still this patch seems to be redundant.

@ChrsMark you are correct. I have repeated the tests and the 1st level citizens are there. So there is no need for this. I am going to close is as duplicate.

We will try to figure out how to add the 2nd level citizen creator on separate story