Support alternative k8s cluster TLD (non .cluster.local ones)

[Tristan971]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, 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

Tell us about the feature Kubernetes defaults to "cluster.local" as top-level domain for cluster-internal DNS records. This is however configurable and may be preferred different, for various reasons ranging from environment differentiation (in logs etc) to soft safeguard (easier to spot misconfigurations) when managing a significant amount of clusters.

It'd be great to make this a flag of sorts with the associated helm values files properties.

It is relatively common (read: most of the time, though not invariably) something projects support when dealing with cluster-wide concerns; taking a fairly similar-in-spirit database operator for example https://github.com/zalando/postgres-operator/blob/v1.8.2/charts/postgres-operator/values.yaml#L94-L95

Which product(s) is this request for? Operators

Tell us about the problem The specific notice was seeing the TLS certificate generation (and the general operation, as far as a quick glance allows) of the PXC operator (and others) assuming (and hardcoding, in its sources) this .cluster.local suffix with no option to change it.

This can be worked around using extra SANs of course, but it's always better to not risk breaking future assumptions that might get baked into the project about this.

Describe alternatives you've considered

• Changing the domain of clusters to align with this "opinionated" (I guess?) default of k8s
• Baking in relevant extra SANs for now

Additional context As far as I can tell, the "dependency" of the operator (at least the PXC one) on that is currently minimal at best (essentially just the TLS generation and some e2e tests), so it's probably just about the easiest time it'd be to "correct" this.

Also while I'm no experimented gopher I'd be happy to contribute this change (whatever form it takes) if it helps.

[spron-in]

@Tristan971 thanks for sharing this!

I think it is a viable request. We already do something similar for our Operator for MongoDB:

#  clusterServiceDNSSuffix: svc.cluster.local

We will discuss it internally first and I will let you know. Do you change the domain name of the cluster sometimes or it is static for the creation time?

[Tristan971]

Good to hear!

Do you change the domain name of the cluster sometimes or it is static for the creation time?

In my case it is static from cluster creation, and if I were to change it live I would do so fully expecting things to break.

So for dynamic-ness I suppose it’d be a « cool if it’s trivial to get alongside, but unnecessary » thing (to me anyway)