Feature: Internal DNS Template for Kuberentes Services and Pods

[nitin-nizhawan]

What would you like to be added:

Currently, external DNS support fqdn-template parameter. There are certain limitations of this option.

1. This provides a single template for all resource types. We would like a separate template for each resource so that a different pattern for DNS can be specified for each type of resource.
2. Currently, fqdn-template parameter only works for public IP addresses for the resource. We would like to add support for internal or private IPs.
3. DNS entries are created for only those resources which have the hostname annotation

Therefore, To address these limitations this feature adds support for generating DNS entries for all supported Kubernetes resources for DNS (Service, Pod) using resource-type-specific internal DNS templates. This allows users to create DNS records for internal/private IPs for all objects of a given type, not just those with specific annotations.

Different templates are required for each resource type. This requires addition of following parameters

--internal-service-template
--internal-pod-template

In future other parameters can be added for other resource types if required.

Why is this needed:

This feature is required to enable ExternalDNS to fully replace CoreDNS for internal service discovery within Kubernetes clusters. By allowing the creation of DNS entries for internal IP addresses with names matching those generated by CoreDNS, users can seamlessly migrate workloads and DNS-based service discovery from CoreDNS to ExternalDNS.

This allows customers to move dataplane for DNS queries to directly external DNS providers which are highly available and remove dependency on CoreDNS.

Details

New command-line flags:

--internal-service-template
--internal-pod-template

• If a flag is specified, all objects of that type will get a DNS entry using the template and their internal/private IPs.
• If both the regular and internal templates are set, both public and internal DNS entries are created.
• If neither is set, fallback to annotation-based logic.
• Headless services: Internal DNS entries are generated for all endpoints of headless services when the internal template is set.
• DNS names: The DNS entries created should have names that match those generated by CoreDNS for maximum compatibility.

Example Usage

Since, this will be used to replace CoreDNS in a kubernetes cluster. Following is sample configuration of this feature

--internal-service-template = {{.Name}}.{{.Namespace}}.svc.cluster.local

This will instruct ExternalDNS to create DNS records of the specified form in template for all service objects object. These DNS Records will point to internal/private IPs for all services.

[ivankatliarchuk]

I would agree that is nice to have a way to configure FQDN per source, as FQDN is quite powerfull. But even then you not necessary need that

Example

--template=`{{ if eq .Kind "Service"}}service.tld.com{{ end}}, { if eq .Kind "Pod"}}pod.priivate.tld{{ end}}`

^ Just an example

However, half of the statements are not correct. FQDN templating should not know explicitly where it Public or Private. Expectation is to use template engine with IF/Else/Equal and etc to generate templates

Example FQDN tests

• pod https://github.com/kubernetes-sigs/external-dns/blob/master/source/pod_fqdn_test.go
• service https://github.com/kubernetes-sigs/external-dns/blob/master/source/service_fqdn_test.go
• node https://github.com/kubernetes-sigs/external-dns/blob/master/source/node_fqdn_test.go

[nitin-nizhawan]

Hi @ivankatliarchuk Thanks for this information. It seems this addresses the requirement for a type specific template.

Although, I think other requirement is to populate these with private/internal addresses rather than public address.

Any idea how could we enable that feature?

[ivankatliarchuk]

To better understand the scenario, it would be helpful if you could share examples of the Kubernetes resources and explain the 'sources' you're discussing. I'm struggling to grasp the distinction between 'Public and Private addresses' in this specific context.

[nitin-nizhawan]

Hi @ivankatliarchuk For example, if cluster has following two services

> kubectl get svc -A 
NAMESPACE           NAME                               TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)          AGE
default             kubernetes                         ClusterIP      10.0.0.1       <none>           443/TCP          64d
default             test-service                       LoadBalancer   10.0.77.184    102.222.113.140   5678:31794/TCP   25s

ExternalDNS should create following two DNS records

kubernetes.default.svc.cluster.local  A  10.0.0.1
test-service.default.svc.cluster.local  A  10.0.77.184

This should happen without having to add annotation to services as it has to be done for all services. By private addresses I meant CLUSTER-IP for service and by public I meant EXTERNAL-IP

[ivankatliarchuk]

I understand the situation better now.

The decision to use annotations for this specific use case was made some time ago. I believe it's still possible to introduce a flag to control this behavior.

Currently, for this functionality to work, all LoadBalancer service types must indeed be annotated, as per the documentation

annotations:
  "external-dns.alpha.kubernetes.io/internal-hostname": "default.svc.cluster.local"

Given this, why is configuring this annotation not considered a viable option?

[nitin-nizhawan]

Annotation is not viable because it has to replace CoreDNS and Coredns will be removed. It will provide service discovery for all service resources including those managed by system , not just those with the annotation which is currently done by CoreDNS.

From the user point of view it should work as mentioned in kubernetes documentation , https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

[ivankatliarchuk]

External-DNS is a controller; it's not the same as native Kubernetes DNS that mention in kubernetes docs. It adds capabilities on top of the default behavior by managing external DNS entries. External-DNS is not a replacement for native kubernetes tooling

[ivankatliarchuk]

CoreDNS is an internal, high-performance cluster DNS backed by in-cluster ETCD as storage for records. External-DNS is a controller that creates DNS entries in external providers (AWS, Cloudflare, etc.). They are vastly different; External-DNS's performance is limited by API calls, unlike CoreDNS. Replacing one with the other is technically feasible but would be an architectural mismatch given their differing roles and performance implications.