add new flag to allow configuring per pod FQDNs for service source.

[SerjKol80]

What would you like to be added:
Currently if you create FQDNs for K8S headless services, a service source will generate DNS record for the source. Also, in addition to that, if pods related to that service has a hostname configured, then FQDNs for each pod will also be created.
I.e. if you have service service-1 resulting into FQDN service-1.some.domain there will also be FQDNs like pod-1.service-1.some.domain be generated.

Currently, you will see such behavior only if you have headless service with pods where .Spec.Hostname is non-empty.

What we need is to be able to configure this behavior. We want a flag where you can explicitly enable or disable per pod FQDNs for headless services. And if you omit this flag, the default behavior is the same like today (based on .Spec.Hostname).

Why is this needed:
Some time we do not control .Spec.Hostname if we don't create static pods. I.e. if pods are created by Deployment it always keeps that field empty. Thus, you can't generate FQDNs for such pods. Also you can't avoid generating such FQDNs for pods created by StatefulSets because StatefulSet always sets some value to .Spec.Hostname.

[ivankatliarchuk]

There is no point to add/support a new flag for something that is already supported. For advanced use, try to understand how to FQDN templating per your requirement. https://github.com/kubernetes-sigs/external-dns/blob/master/docs/advanced/fqdn-templating.md. You could have pretty much any template, to reduce out-of-the-box FQDN garbage.

Example test

external-dns/source/service_fqdn_test.go

Line 208 in 8fd9c64

endpointSlices: []*discoveryv1.EndpointSlice{

[SerjKol80]

@ivankatliarchuk
Thank you for looking at this request.
I believe I familiar with FQDN templating pretty well, but I honestly don't understand how FQDN templating helps me with requested feature. Would you please give at list a high level hint how to get it for both cases (excluding pods from FQDNs for --source=service and including them all regardless to hostname)?

Here is an example.
Let's say I have one service:

apiVersion: v1
kind: Service
metadata:
  name: svc-1
spec:
  clusterIP: None
  type: ClusterIP

And I have one pod related to it:

apiVersion: v1
kind: Pod
metadata:
  name: pod-0
spec:
  hostname: pod-0

If I want to generate FQDN for this service:

external-dns --source=service --fqdn-template="{{.Name}}.svc.my-domain.com" ...

then a pod name will always be pre-attached to all DNS names (which were already resolved from the template by this time) here. So as a result I always get two FQDNs:

svc-1.svc.my-domain.com
pod-0.svc-1.svc.my-domain.com

To your comment

You could have pretty much any template, to reduce out-of-the-box FQDN garbage.

I don't see how templating can help to disable such per pod DNS names, if this happens after templates are already resolved to the list of domain names.

Similar to other case. If I have pod without hostname:

apiVersion: v1
kind: Pod
metadata:
  name: pod-2
spec:
  hostname: ""

there is no way to get FQDN:

pod-2.svc-1.svc.my-domain.com

Because for --source=service when it resolves FQDNs from the template it doesn't have any pod info in its context. Thus, I can't generate such names from the template. Similar to --source=pod, I don't have service in a template's context, thus can't generate above name either.

What am I missing? Would you please give at least high level hint to unblock me?