fix(source/service): headless records and root/base domain (#5624)

Signed-off-by: ivan katliarchuk <ivan.katliarchuk@gmail.com>
This commit is contained in:
Ivan Ka 2025-07-09 08:43:28 +01:00 committed by GitHub
parent b27ec255aa
commit 1eccb64bcb
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 80 additions and 11 deletions

View File

@ -66,6 +66,73 @@ Multiple hostnames can be specified through a comma-separated list, e.g.
For `Pods`, uses the `Pod`'s `Status.PodIP`, unless they are `hostNetwork: true` in which case the NodeExternalIP is used for IPv4 and NodeInternalIP for IPv6.
Notes:
- This annotation `overrides` any automatically derived hostnames (e.g., from Ingress.spec.rules[].host).
- Hostnames must match the domain filter set in ExternalDNS (e.g., --domain-filter=example.com).
- This is an alpha annotation — subject to change; newer versions may support alternatives or deprecate it.
- This annotation is helpful for:
- Services or other resources without native hostname fields.
- Explicit overrides or multi-host situations.
- Avoiding reliance on auto-detection or heuristics.
### Use Cases for `external-dns.alpha.kubernetes.io/hostname` annotation
#### Explicit Hostname Mapping for Services
You have a Service (e.g. of type LoadBalancer or ClusterIP) and want to expose it under a custom DNS name:
```yml
apiVersion: v1
kind: Service
metadata:
name: my-service
annotations:
external-dns.alpha.kubernetes.io/hostname: app.example.com
spec:
type: LoadBalancer
...
```
> ExternalDNS will create a A or CNAME record for app.example.com pointing to the external IP or hostname of the service.
#### Multi-Hostname Records
You can assign multiple hostnames by separating them with commas:
```yml
annotations:
external-dns.alpha.kubernetes.io/hostname: api.example.com,api.internal.example.com
```
> ExternalDNS will create two DNS records for the same service.
#### Static DNS Assignment Without Ingress Rules
When using Ingress, you usually declare hostnames in the spec.rules[].host. But with this annotation, you can manage DNS independently:
```yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
external-dns.alpha.kubernetes.io/hostname: www.example.com
spec:
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-service
port:
number: 80
```
> Useful when DNS management is decoupled from routing logic.
## external-dns.alpha.kubernetes.io/ingress-hostname-source
Specifies where to get the domain for an `Ingress` resource.

View File

@ -169,7 +169,7 @@ Very important here, is to set the `hostPort`(only works if the PodSecurityPolic
Now we need to define a headless service to use to expose the Kafka pods. There are generally two approaches to use expose the nodeport of a Headless service:
1. Add `--fqdn-template={{name}}.example.org`
1. Add `--fqdn-template={{ .Name }}.example.org`
2. Use a full annotation
If you go with #1, you just need to define the headless service, here is an example of the case #2:
@ -190,22 +190,24 @@ spec:
component: kafka
```
This will create 3 dns records:
This will create 4 dns records:
```sh
kafka-0.example.org
kafka-1.example.org
kafka-2.example.org
kafka-0.example.org IP-0
kafka-1.example.org IP-1
kafka-2.example.org IP-2
example.org IP-0,IP-1,IP-2
```
If you set `--fqdn-template={{name}}.example.org` you can omit the annotation.
Generally it is a better approach to use `--fqdn-template={{name}}.example.org`, because then
you would get the service name inside the generated A records:
> !Notice rood domain with records `example.org`
If you set `--fqdn-template={{ .Name }}.example.org` you can omit the annotation.
```sh
kafka-0.ksvc.example.org
kafka-1.ksvc.example.org
kafka-2.ksvc.example.org
kafka-0.ksvc.example.org IP-0
kafka-1.ksvc.example.org IP-1
kafka-2.ksvc.example.org IP-2
ksvc.example.org IP-0,IP-1,IP-2
```
#### Using pods' HostIPs as targets