external-dns icon indicating copy to clipboard operation
external-dns copied to clipboard

R53 entries are not created for pods

Open andreosipov opened this issue 1 year ago • 4 comments

What happened: External-dns controller doesn't create R53 entries in AWS for pods. This can be simple pods, deployments, stateful sets.

What you expected to happen: Create R53 A entry named "nginx-12345.example.net"

How to reproduce it (as minimally and precisely as possible): Arguments of external-dns controller:

args:
            - '--source=service'
            - '--source=ingress'
            - '--source=pod'
            - '--domain-filter=example.com'
            - '--domain-filter=example.net'
            - '--provider=aws'
            - '--aws-zone-type=public'
            - '--registry=txt'
            - '--txt-owner-id=cluster_name_1'

Nginx pod used for tests:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  annotations:
    external-dns.alpha.kubernetes.io/hostname: nginx-12345.example.net
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

Anything else we need to know?: With an argument '--log-level=debug' it's visible that external-dns just skips a target pod for some reasons: time="2024-03-06T13:10:20Z" level=debug msg="skipping pod nginx-pod. hostNetwork=false" Annotation "external-dns.alpha.kubernetes.io/internal-hostname" has the same behavior. With services and ingresses controller works fine and R53 entries are created. Setting "hostNetwork: true" there are no tracks at all of the target pod in debug logs, however r53 is still not created.

Environment:

  • External-DNS version (use external-dns --version): 0.14.0
  • DNS provider: aws
  • Others:

andreosipov avatar Mar 06 '24 13:03 andreosipov

Seeing similar behaviour with 0.14.1 in Azure with Azure Private DNS.

Cloud dns provider: Azure external-dns args:

args:
            - '--log-level=info'
            - '--log-format=text'
            - '--interval=1m'
            - '--source=ingress'
            - '--source=pod'
            - '--policy=sync'
            - '--registry=txt'
            - '--txt-owner-id=external-dns'
            - '--domain-filter=domain1.example.com'
            - '--domain-filter=domain2.example.com'
            - '--provider=azure-private-dns'

K8S platform: AKS Ingress Controller: ingress ingressRoute: networking.k8s.io/v1

thecmdradama avatar May 02 '24 04:05 thecmdradama

I have the same problem the code skips all pods that has hostNetwork = false for some reason. https://github.com/kubernetes-sigs/external-dns/blob/master/source/pod.go#L87

The hostnetwork for a pod is not recommend as it will listen in the Node network. I will try to use in my use case, otherwise I will fork the code and add a flag to disable this behavior

giovannicandido avatar May 27 '24 17:05 giovannicandido

We're having the same issue. The documentation for external-dns.alpha.kubernetes.io/internal-hostname states

For Pods, uses the Pod's Status.PodIP

It seems unnecessary to force the requirement of a hostNetwork in usecases where only the PodIP is required in the record, eg in cluster with container aware networking that allows routing of traffic directly to the pod IP from outside the cluster.

BrendanGalloway avatar Jun 26 '24 16:06 BrendanGalloway

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue as fresh with /remove-lifecycle stale
  • Close this issue with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot avatar Sep 24 '24 16:09 k8s-triage-robot