Can you support a "null" or "empty" webhook provider

[aceeric]

What would you like to be added:

Thank you for External DNS! Would you consider a null or empty webhook provider sidecar?

Why is this needed:

I have kind of a unique use case. I'll try to present it simply:

1. I run k8s on my desktop with each cluster node being a VM (using KVM.) I use this for development and experimentation.
2. When I provision an ingress in the cluster with host foo.io I don't really need any DNS manipulation per se: I just need /etc/hosts on my desktop modified because the entire cluster - VMs and all - is on my desktop computer...
3. So I was successfully using External DNS with the v0.14.0 image and the 1.13.1 chart which supported provider: webhook and then I would specify extraArgs with --webhook-provider-url=http://192.168.0.49:5000 where that IP address was my desktop.
4. Then I run a really simple Python http server on my desktop as the webhook, and the Python server responds to the webhook calls from External DNS coming from the cluster VM(s) and configures /etc/hosts on my desktop

So by simply creating an ingress with host testme.foo.io and the required annotations, my /etc/hosts is updated by External DNS via my Python webhook - then I can fire up my browser and access https://testme.foo.io. That was working great.

I wanted to update to latest chart and image. Unfortunately with the new v0.18.0 image, my use case does not appear to be supported because an empty provider is not allowed. The error is:

$ k -n external-dns logs deploy/external-dns -f
time="2025-06-28T22:08:29Z" level=fatal msg="flag parsing error: enum value must be one of akamai,alibabacloud,aws,aws-sd,azure,azure-dns,azure-private-dns,civo,cloudflare,coredns,digitalocean,dnsimple,exoscale,gandi,godaddy,google,inmemory,linode,ns1,oci,ovh,pdns,pihole,plural,rfc2136,scaleway,skydns,transip,webhook, got ''"

I helm install chart version 1.17.0 with these values to get the error above:

provider:
  name:

extraArgs:
- --provider=webhook
- --webhook-provider-url=http://192.168.0.49:5000

image:
  tag: v0.18.0

I've also tried these helm values:

provider:
  name: webhook
  webhook:
    livenessProbe:
      httpGet:
      exec:
        command: ["sh", "-c", "true"]
    readinessProbe:
      httpGet:
      exec:
        command: ["sh", "-c", "true"]
    securityContext:
      runAsUser: 1000
    image:
      repository: alpine
      tag: latest

Unfortunately that required hand adding a command for the webhook sidecar because the chart doesn't support it:

command:
- /bin/sh
- -c
- sleep 1000

And I've tried hand-deleting the webhook sidecar from the external-dns deployment after the chart installs. In both those cases (using alpine, and deleting the side car) external dns never fully starts. It dies and restarts after this log entry:

time="2025-06-28T23:27:00Z" level=info msg="Created Kubernetes client https://10.32.0.1:443"
time="2025-06-28T23:28:00Z" level=fatal msg="failed to sync *v1.EndpointSlice: context deadline exceeded with timeout 1m0s"

So it seems to really want that side car there...

If a null or empty sidecar was allowed then I would be back in business with the latest release. Basically this feature can be interpreted as: "There's no webhook provider side-car - the provider is external to the cluster at the endpoint specified by the -webhook-provider-url arg.

Thank you for your great work, and considering my suggestion. If you think it makes sense I can look at submitting a PR.

[aceeric]

Correction - it looks like the actual issue was that in Kubernetes 1.33.1, the extenral-dns clusterrole needs:

- apiGroups:
  - discovery.k8s.io
  resources:
  - endpointslices
  verbs:
  - get
  - watch
  - list

I was able to run the pod after hand-deleting the sidecar. So it really looks like this is purely a Helm issue:

1. The extenral-dns clusterrole needs to be modified
2. The chart needs to support the ability to not template in a sidecar. Maybe a new value like:

   provider:
     name: webhook
     sidecar: false
   

[aceeric]

Ah I can see that endpointslices are in the master branch waiting to be tagged. So the only change is for the sidecar to be optionally excluded

[szuecs]

Hi!
I wonder if you can try to run your python script as the sidecar.
If that would work there would be no change needed.

I am also not opposed against the change, but I would be curious to understand. :)

[mloiseleur]

I agree with @szuecs comment.
If you transform your python script into a real webhook provider for this use case, in a sidecar mounting your /etc/host, there would be no change needed and others would be able to use this setup as well (ie: not just you).
This kind of setup might also help for external-dns ci, for dev or simpler e2e testing.

[aceeric]

Hello and thank you for responding. In this particular case I am running a Kubernetes cluster in VMs (guests) on my desktop Ubuntu machine (host). The python service in question modifies /etc/hosts on the host machine so that from the host machine, I can access the workloads in the cluster VMs. Your solution would require me to provision the VMs (guests) with access to the host file system which - I think is possible but not my preference. I'd rather keep the VMs purely dedicated to Kubernetes.

This link will explain it: https://github.com/aceeric/desktop-kubernetes/tree/external-dns/hostsfile-server

Purely from a design perspective, since External DNS interacts with the webhook via a URL why should the chart mandate that a sidecar exists? Especially since the application itself does not require it. In other words the chart in its present form levies a requirement on the runtime configuration that the server does not require.

But if there is a reluctance to adopt the PR - that's not a problem. Since I'm Helm-installing external-dns, I can easily post-process the output of the chart (kustomize?) and snip out the sidecar if you don't wish to approve the PR. Again - I appreciate all your work and thank you for your consideration.

[max06]

I have the same issue - but I'm not using a webhook.

The common factor: We are both using v0.18.0. Going back to v0.17.0 as defined in the helm chart works.

[k8s-triage-robot]

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