[Enhancement]: Nameserver

[gertschouten]

Related problem

Our Mirrormaker2 connectors need to use different nameservers for name resolution depending on in which Openshift namespace they are deployed.
dnsConfig and dnsPolicy on Pods allow for configuration of /etc/resolv.conf.
However, CRDs for connectors don't seem to expose this.
A volumeMount to /etc/resolv.conf based on ConfigMap seems not to be allowed (only additional mounts to /mnt).
Custom commands that update /etc/resolv.conf don't seem to be supported either.
JVM System properties don't seem to support an option to configure nameservers either.

Unless there are other mechanisms to configure Kafkamirrormaker2 containers to utilize specific nameservers, exposing dnsConfig and dnsPolicy on the CRD(s) seem to be the most logical way to support this feature.

Suggested solution

Let the CRD(s) expose dnsConfig and dnsPolicy for pods.

Alternatives

No response

Additional context

No response

[scholzj]

You should probably elaborate on the use-case and why this is a general issue.

[gertschouten]

The use case is replication between on premises Kafka clusters provisioned with Strimzi and Confluent Cloud clusters with private connectivity. Now, we run two networks on premises. One for dev/qa namespaces and one for prod, on Openshift. Target clusters are segregated in three seperate networks: dev, stage, prod.
Brokers in target clusters have common subdomains. They only differ on the domain prefix.
To connect an on premises dev to a remote dev and an on premises qa01 to a remote stage cluster, due to undifferentiated domains, resolution needs to happen with seperate nameservers.
Configuring dns forwarding on a central AD controller would not allow for different resolution for dev and stage and prod (all target brokers have the same domain).
Configuring dns forwarding with Openshift DNS operator achieves resolution per cluster/network. I.e. prod cluster gets forwarded and resolves to the respective remote prod environment, however, both dev and qa01 would get forwarded and resolve to undifferentiated remote resolver (not allowing to different based on source namespace dev and qa01 since they belong to the same source cluster).
To really differentiate resolution for dev and qa01 towards remote brokers in dev and stage, resolution needs to be configured at a lower-level.
A mirrormaker2 in namespace dev should get ip(s) for broker name(s) resolved within the remote dev environment. A mirrormaker2 in namespace qa01 should get ip(s) for broker name(s) resolved within the remote stage environment.
Remote broker names are dynamic as these scale in and out based on workload.

dnsConfig, dnsPolicy would allow to lift configuration for resolution for these connectors to the level of the pods within its namespace and thereby match the corresponding remote resolver.

I.e. the use case is a scenario where remote server names have identical domains across environments and environments (here at the source) don't exist in different networks (different dev and qa namespaces share the same source cluster: a dev/qa Openshift cluster).

[scholzj]

Ok, thanks for the clarification. We will triage it in the next call, but I think it makes sense. Would you be interested in contributing it assuming it is accepted?

[gertschouten]

Thank you, Jakub. Assuming this feature gets accepted, I’d be glad to contribute. I need to discuss it with my superior before making any firm commitments. Let's synchronize on this point after triage.

[ventsislav-georgiev]

This will be really useful as a workaround for our issue with Cloud DNS: #9551. We may deploy CoreDNS explicitly for the Strimzi components.

[scholzj]

@ventsislav-georgiev I'm not sure how it relates to your issue. In your case, you IIRC do not have basic DNS functionality in your Kubernetes cluster - in other words your cluster is non-compliant. This issue is about some weird multi-network environment.

Unfortunately, we did not get to this in the last community call triage as we run out of time. I do not expect that this would have any general objections. But I expect that it would ned a proposal to explain the use cases and how it will be actually done.