Set startupProbe on consul-dataplane container (injected as part of the Service Mesh implementation)

[komapa]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

Is your feature request related to a problem? Please describe.

We have an open ticket with HashiSupport on why the consul-dataplane container does not fully load in some cases but that problem revealed another shortcoming of the consul-dataplane container: It does not have any readinessProbe (or livenessProbe for that matter). What this means in reality is that if the consul-dataplane container does not start correctly (something in the initialization process gets wedged), we end up with a Pod that is never going to recover.

Feature Description

I proper for consul-k8s to set a startupProbe like this:

var startupProbe *corev1.Probe
	startupProbe = &corev1.Probe{
		ProbeHandler: corev1.ProbeHandler{
			TCPSocket: &corev1.TCPSocketAction{
				Port: intstr.FromInt(constants.ProxyDefaultInboundPort + mpi.serviceIndex),
			},
		},
		PeriodSeconds:       10,
		FailureThreshold:    6,
		InitialDelaySeconds: 1,
	}

What will need to be configurable is mostly the total time to wait for the container to start listening on its application port. In our case it can take sometimes close to a minute so some annotation on the Pod for some combination of FailureThreshold and PeriodSeconds will be required.

Use Case(s)

Described already

Contributions

Yes, if you think you will accept such a feature