Helm Chart Webhook Provider port mismatch

[Skaronator]

What happened:

External-dns uses a hardcoded port (8888) for Webhook providers:

external-dns/main.go

Line 371 in b336c52

webhookapi.StartHTTPApi(p, nil, cfg.WebhookProviderReadTimeout, cfg.WebhookProviderWriteTimeout, "127.0.0.1:8888")

However, the Helm chart defines a liveness probe for the webhook provider on port 8080:

external-dns/charts/external-dns/templates/deployment.yaml

Line 162 in b336c52

containerPort: 8080

This inconsistency results in a CrashLoopBackOff, as the health check is looking for the service on port 8080, while the actual service runs on port 8888.

What you expected to happen:

Both ports are hardcoded and should be aligned to avoid this issue.

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• External-DNS version (use external-dns --version): external-dns-helm-chart-1.15.0
• DNS provider: webhook
• Others:

[mloiseleur]

The documentation explain the purpose of those two ports:

The default recommended port is 8888, and should listen only on localhost (ie: only accessible for k8s probes and external-dns).

And

The metrics should listen “:8080” on /metrics following Open Metrics format.

For security reason, only this metrics port is exposed in the Chart. It allows API port to listen only for localhost, so only external-dns can call it. The metrics port is not sensitive, so it can listen more widely without any risk.

external-dns/charts/external-dns/templates/deployment.yaml

Lines 159 to 162 in 45257fb

	ports:
	- name: http-webhook
	protocol: TCP
	containerPort: 8080

The probes are entirely configurable:

external-dns/charts/external-dns/values.yaml

Lines 252 to 260 in 45257fb

	livenessProbe:
	httpGet:
	path: /healthz
	port: http-webhook
	initialDelaySeconds: 10
	periodSeconds: 10
	timeoutSeconds: 5
	failureThreshold: 2
	successThreshold: 1

So I am not sure to get your issue. There is no mismatch, it's done on purpose, for security reason.

[Skaronator]

Thanks for the detailed explanation, that makes sense! I raised an issue with the webhook provider I use.