[otel/kube-stack] Update EDOT SDK k8s auto-instrumentation images to their latest versions

[trentm]

This also updates the vanilla OTel Go image version to its latest.

---

The versions of the EDOT language SDK images being used with the OTel Operator were quite old.
This manually updates them to the current latest.

/cc @jackshirazi, @xrmx, @dmathieu (as my best guess for the authority on the OTel Operator auto-instrumentation image for each of the languages I've updated here)

---

Is there a good place to discuss how/when/who should be regularly updating these versions?
Or perhaps use the :latest Docker tag, though that, of course, changes over time.

[mergify]

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

• backport-./d./d is the label that automatically backports to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[trentm]

This pull request does not have a backport label. Could you fix it @trentm? 🙏

I'd appreciate guidance on this. I don't know what backport targets would be appropriate for this PR.
I'll try backport-active-all.

[elasticmachine]

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

[pkoutsovasilis]

hey @trentm 👋 so backport-active-all will open backport PRs, when this one gets merged, to 9.0, 8.x, 8.18, 8.17 and 8.16 branches. I have a feeling that this change shouldn't go that far back but I am not 100% sure. As this PR affects the edot collector helm chart, I will need a chime in from the devs that have contributed to it @rogercoll @carsonip @swiatekm

[carsonip]

Sorry I would love to be more helpful here but I'm not familiar with the expectation of auto instrumentation SDK version bump risk and reward balance in backported versions.
cc @AlexanderWert

[jackshirazi]

yeah, these can be backported to any/every version and will work fine (and be better for the customer)

[swiatekm]

I'm reluctant to do this right before the final RC for 9.0.0 and 8.18.0 unless someone exhaustively tests these first. We don't have enough automated testing for this configuration to be confident we're not breaking something. See #7381 for a very recent example.

[jackshirazi]

To be clear what this change is, it is changing the default agent docker images that are downloaded into the kubernetes cluster that the customer is running, which can then be applied for auto-instrumentation of customer applications. The customer is able to override these docker images very easily. Sticking with the existing values means that customers onboarding will install old versions of the agents, applying the change means the customers install the latest released (and definitely tested) versions of the agents

When we defined these values, we considered using latest as the version for all agents instead of defined versions, and this would have been fine, but decided that it was more transparent for the customers to be on a specific default version rather than getting the latest release. But that was only for onboarding transparency, not safety. Having latest would have been perfectly safe.

All of which is to say, this not a risk on the Elastic infrastructure side, it only affects agent versions downloaded into customer clusters, and the more recent version the better where this is concerned

[swiatekm]

@jackshirazi I understand what this change accomplishes. I'm saying I'm not confident this won't break something for customers. If @elastic/ingest-otel-data, who are effectively the owners of this config, are confident the change is safe, I don't mind merging it.

[trentm]

@elastic/ingest-otel-data can we merge this? I'm not clear on what versions this should be backported to.

[girodav]

I am fine with merging this, after syncing with the other team members, as soon as #7327 (comment) is resolved. I think the risk is relatively low, considering this PR only affects auto-instrumentation and not the collector configuration or elastic-agent image used.

We should backport to at least 8.19 and 9.1 at the very least, but also 9.0.1 and 8.18.1.

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 2e8a849

Failed CI Steps

• x86_64:sudo: fleet-endpoint-security

History

• 💔 Build #19447 failed d2ea59a
• 💛 Build #18812 was flaky 9fe8451

cc @trentm

See #7327 (comment)

[girodav]

LGTM

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube