add featuregate for k8s 1.28 native sidecar container

[frzifus]

Description:

Link to tracking Issue(s):

• Resolves: Use k8s 1.28 native sidecar for OTEL collector sidecar mode #2376

Testing:

Documentation:

[frzifus]

Should we pre-define a startup probe that checks the ${service.telemetry.metrics.address}/metrics endpoint, expose it in the CRD or do something else?

wdyt @open-telemetry/operator-approvers ?

[swiatekm-sumo]

Is there a reason to treat it any differently than we do readiness probes and liveness probes? We can even default to the readiness probe if not set.

[frzifus]

Nope, but reusing the readiness probe sounds good to me 👍

[frzifus]

Is there a reason we provide another probe type in our API?

opentelemetry-operator/apis/v1beta1/opentelemetrycollector_types.go

Lines 101 to 104 in d4b24f3

	// Liveness config for the OpenTelemetry Collector except the probe handler which is auto generated from the health extension of the collector.
	// It is only effective when healthcheckextension is configured in the OpenTelemetry Collector pipeline.
	// +optional
	LivenessProbe *Probe `json:"livenessProbe,omitempty"`

Since that one does not contain a ProbeHandler:

opentelemetry-operator/apis/v1beta1/opentelemetrycollector_types.go

Line 208 in d4b24f3

type Probe struct {

Like here:
https://github.com/kubernetes/api/blob/5147c1a32f6a0b9b155bb84e59f933e0ff8a3792/core/v1/types.go#L2462-L2464

[jaronoff97]

I don't think there's a good reason... is there much of a difference between these things? Maybe in v1beta1 we should just use the upstream definition?

[frzifus]

Using the upstream definition would extend ours by the ProbeHandler.

[jaronoff97]

I think this makes sense... is there a way to write an e2e for this?

[swiatekm-sumo]

I think this makes sense... is there a way to write an e2e for this?

Sure, you'd need to add a new test suite and run it with the gate enabled. Then checking if the sidecar is an initContainer should be straightforward.