support optional env which dictates status check url format

[peter-mcconnell]

What does this PR do?

Allows the user to (optionally) specify a custom cluster domain for their kubernetes cluster.

why?

Upon deploying this to one of my clusters I noticed the operator was complaining about not being able to get a status from the service:

On inspection I realised the cluster domain in my kubernetes cluster and the one hardcoded here https://github.com/grafana/k6-operator/blob/main/controllers/k6_start.go#L20 were different.

other items of note

I've updated the yaml manifest and Makefile to support passing this variable through during make deploy. The approach I took here was to use envsubstr - this is a new dependency for this repository but at a glance it appears to be in use on other projects in this org so I hope that's ok. source: https://github.com/search?q=org%3Agrafana+envsubst&type=code

testing
I have tested this with and without K6_CLUSTER_DOMAIN env set and confirmed:

• with no K6_CLUSTER_DOMAIN value set the default ...svc.cluster.local address is used
• with K6_CLUSTER_DOMAIN value set the url ...svc$K6_CLUSTER_DOMAIN address is used. Further - I've tested that this patch results in a successful deployment on our clusters.

[CLAassistant]

All committers have signed the CLA.

[yorugac]

Hi @peter-mcconnell, I'm terribly sorry for missing your PR! It totally slipped through my notifications 😞

Your use case is 100% valid and it'd be good to have a fix for it; but I wonder if it could be resolved in some other way? First that comes to mind is to use IP instead of DNS: I'd say I prefer DNS for reasons described in #89 and there's also a case of IPv6 in #171. OTOH, there was a bug with using DNS in #132, fixed in #140.

It'd be good to make a full review of the points mentioned in these issues and come up with some unified approach that will cover all cases, including the one raised in this PR.
@peter-mcconnell, if you'd like to grok this despite the delays, please feel free to 🙂 If not, that's fine, I'll review and work on this in the next year.

[mld]

We just started checking out k6-operator and got stuck on this issue too (custom cluster domain).
We forked and went with just removing the .cluster.local part in the check for now, but if one likes FQDN (which might be argued is a good thing), this feels like the way to handle it.

[illrill]

I think this was solved by #288, right?