Skip to content

Comments

Fix ingress status if type ClusterIP#12134

Open
walnuss0815 wants to merge 2 commits intotraefik:v3.5from
walnuss0815:bugfix/fix-ingress-status-clusterip
Open

Fix ingress status if type ClusterIP#12134
walnuss0815 wants to merge 2 commits intotraefik:v3.5from
walnuss0815:bugfix/fix-ingress-status-clusterip

Conversation

@walnuss0815
Copy link

@walnuss0815 walnuss0815 commented Oct 7, 2025

What does this PR do?

This PR fixes the Kubernetes ingress status if the traefik service is type ClusterIP. The field .spec.clusterIPs is now being used to generate the ingress status instead of the ExternalIPs. ExternalIPs is for IPs "for which nodes in the cluster will also accept traffic for this service".

Ref: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.34/#servicespec-v1-core

Motivation

I am having the same issue as described here argoproj/argo-cd#14607 which should be fixed by #11100 , but due to the usage of the externalIPs field it does not work as intended if the service type is ClusterIP.

More

  • Added/updated tests
  • Added/updated documentation

Additional Notes

@walnuss0815
Copy link
Author

I have built the image and tested it in my Kubernetes cluster. It works like expected and without an issues.

@nmengin
Copy link
Contributor

nmengin commented Oct 9, 2025

Hello @walnuss0815,

Thank you for your contribution.

Your PR looks more like a fix. Could you rebase it on the v3.5 branch please?

We've set the status to "design-review" to allow us to check the PR and ensure there is no deep impact on Traefik before moving forward.

We'll keep you updated once the analysis is done.

This commit fixes the Kubernetes ingress status if the traefik service is type
`ClusterIP`. The field `.spec.clusterIPs` is now being used to generate the
ingress status instead of the `ExternalIPs`. ExternalIPs is for IPs "for which
nodes in the cluster will also accept traffic for this service".

Ref: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.34/#servicespec-v1-core
@walnuss0815 walnuss0815 force-pushed the bugfix/fix-ingress-status-clusterip branch from fe1024e to 3d5b2bc Compare October 9, 2025 12:42
@walnuss0815 walnuss0815 changed the base branch from master to v3.5 October 9, 2025 12:43
@walnuss0815
Copy link
Author

Hi @nmengin,

I have rebased the fix on the v3.5 branch.

@rtribotte rtribotte added this to the 3.5 milestone Oct 16, 2025
@rtribotte rtribotte modified the milestones: 3.5, 3.6 Nov 12, 2025
@jkaplowitz
Copy link

jkaplowitz commented Dec 18, 2025

I had the exact same problem, with my traefik Service running as type ClusterIP and ArgoCD being unable to see anything in the resulting Ingress objects' status.loadBalancer.ingress lists to determine that the Ingresses are healthy. I built an image from the current version of this PR (commit 497fe75) and tried it locally. I can confirm that this fixes it for me.

In case it's relevant, my instance of ArgoCD is running in the same Kubernetes cluster as Traefik and can, if it wants to, route traffic to the traefik Service's cluster IP address without leaving the cluster. I'm not sure this matters though: even if my ArgoCD instance were running externally to the Kubernetes cluster with no ability to route to the cluster IP address of the traefik Service, ArgoCD's health check for an Ingress only cares that the status.loadBalancer.ingress list is non-empty with at least one value for hostname or IP, without actually attempting any form of routing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants