[nr-ebpf-agent]: cos and bottle rocket support

[kkhandelwal-nr]

Is this a new chart

No

What this PR does / why we need it:

• Container-Optimized OS (COS) Support: Added full support for Google's Container-Optimized OS with automatic kernel header installation
• Bottlerocket OS Support: Added support for AWS Bottlerocket with automated kernel header retrieval
• Enhanced Data Filtering: Introduced granular filtering capabilities for APM and network metrics data
  • apmDataFilters: Filter APM data by pod labels, entity names, or APM agent presence
  • networkMetricsDataFilter: Filter network metrics by pod labels or entity names
  • allDataFilters: Global filters affecting all data types
• Refactored Init Container: Moved kernel header installation logic from inline bash to ConfigMap-based script for better maintainability
• Configuration Reorganization: Restructured values.yaml with clearer naming and logical grouping
  • tcpStatsReporting → networkMetricsReporting
  • dropDataNewRelic → allDataFilters.dropNewRelicBundle
  • dropDataForNamespaces → allDataFilters.dropNamespaces
  • dropDataServiceNameRegex → allDataFilters.dropServiceNameRegex
  • allowServiceNameRegex → allDataFilters.keepServiceNameRegex
• Added installer-script ConfigMap for init container logic

Which issue this PR fixes

(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

• fixes #

Special notes for your reviewer:

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• Chart Version bumped
• Variables are documented in the README.md
• Title of the PR starts with chart name (e.g. [mychartname])

[stefansedich]

Should the image tag here not be configurable too?

[stefansedich]

We would need the image tag for the init container configurable too for this to work for us.

[kkhandelwal-nr]

@stefansedich We'll need to introduce a new param in the values.yaml in order to make image tag for init container configurable. I would like to understand why the current implementation will not work in your case?

[burhan-nr]

LGTM

[stefansedich]

@stefansedich We'll need to introduce a new param in the values.yaml in order to make image tag for init container configurable. I would like to understand why the current implementation will not work in your case?

@kkhandelwal-nr we utilize immutable tags in our private ECR repo where we copy images to, a mutable tag would not work for us and is not best practice either, a new version of an image should be a new tag.

[stefansedich]

@kkhandelwal-nr any guidance on this one? would it be possible for the init container to use an image that does not have a mutable tag?

[kkhandelwal-nr]

@stefansedich The base image for init container is updated only when we need to upgrade package version that resides in the image. Other than that, there is no update in functionality. Hence we keep this a mutable tag.
To help you out, we can introduce a new param for base image tag in the values.yml in the next release.
Please let us know if this unblocks you.

[stefansedich]

@stefansedich The base image for init container is updated only when we need to upgrade package version that resides in the image. Other than that, there is no update in functionality. Hence we keep this a mutable tag. To help you out, we can introduce a new param for base image tag in the values.yml in the next release. Please let us know if this unblocks you.

I assume we could then just use the main versioned image for the init container? if so that would work for us.

[kkhandelwal-nr]

Yes. Since we push updates for base image to same tag, you can pull that image, retag it for your private ECR repo and use your tag in the values.yml (using new param that we'll be introducing).

[stefansedich]

Yes. Since we push updates for base image to same tag, you can pull that image, retag it for your private ECR repo and use your tag in the values.yml (using new param that we'll be introducing).

So I am unable to use the 1.2.0 tag for the init container? Is agent-base-image-latest pointing to 1.2.0 (latest tag) or is it a completely seperate image?

If these are seperate images it would make more sense if the image lived at say newrelic/newrelic-ebpf-agent-base and was also tagged for each release, could then utilise the latest tag to point to the latest release if desired.

Mashing it into the single repo like this and providing only a latest tag does not play nice with those out there following best practices.

[kkhandelwal-nr]

So I am unable to use the 1.2.0 tag for the init container? Is agent-base-image-latest pointing to 1.2.0 (latest tag) or is it a completely separate image?

Yes, these are separate images. 1.2.0 is build on top of agent-base-image-latest.

If these are separate images it would make more sense if the image lived at say newrelic/newrelic-ebpf-agent-base and was also tagged for each release, could then utilise the latest tag to point to the latest release if desired.

As mentioned earlier, we hardly make any updates in the base image. Hence we kept a mutable tag and used the existing repo. In future, we can surely move this to a separate repo if the changes are too frequent.