New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Haproxy does not handle Services of the type ExternalName #100
Comments
I have tested the older haproxy ingress, it does work with it. The backend configuration in haproxy pod is created properly:
The service YAML used:
The ingress YAML used:
From the source code of this project i found no mentions of ExternalName. |
That looks interesting! |
Currently IC handles this but without runtime DNS resolution. |
Hello, Sorry but I do not understand the previous comments regarding this issue We installed the latest HA proxy ingress controller with helm (0.12.3 which seems to correspond to 2.2.13 haproxy version when we check in the pod) and we just encountered this issue with externalName service as a backend. |
@Mo3m3n long time no see man! I asked about (sort of) this same issue in Slack: https://haproxy.slack.com/archives/CR9N5UNAZ/p1634152029118800 Related issue seems to be that I cannot have multiple ingresses, which define different values for I tried to add
|
Has this been fixed? https://github.com/haproxytech/kubernetes-ingress/releases/tag/v1.6.5 has as the only Changlog entry that:
Presumably that means that forwarding to ExternalName Services otherwise works in version v1.6.4+ |
We have a Haproxy Ingress Controller and I have a requirement to forward request to cloudfront so I am using ExternalName service type with cloudfront url and I can see cloudfront url being added in haproxy config file But when I hit it returns 503, but if I give cloudfront ip it works , and also I am able to do dig/nslookup so I dont think its a dns issue . |
Hi @akarshjain40 can you post the configuration file especially the cloudfront backend part? I've tested externalName with latest IC version and google as external service. It seems to work. |
apiVersion: v1
|
Hi, can you check with |
Hi, I had checked with false its still same, and there is no log of ssl handshake failure its just 503 even when it is true |
@mecampbellsoup |
@pmorch |
This is the type of config-snippet that I was talking about here which is changing the resolving behavior at startup. EDIT: I suggest you remove the config-snippet cause even the sni part may not be required in your case, what you need instead is to set the server-ssl annotation to true since in your case the target server is expecting encrypted traffic (server port 443). Should you need more help, please send the haproxy config of the corresponding backend and related haproxy traffic logs. |
Hi, |
There does not seem to be any support for this at the moment, when you configure a Edit: the error above shows when you describe the Ingress resource, but the haproxy configuration is correctly pointing to the external server. When configured properly (SNI, Hostname…) then everything works 🎉 |
Guess we can support controller:
hostNetwork: false Option 2: |
Hi,
when creating a service of the type "ExternalName" and an ingress pointing towards it, then the ingress controller keeps repeating:
This type of service will never have an endpoint. It would make sense to use the returned CNAME as the backend pool server that is returned by the service.
Tested with.
See https://kubernetes.io/docs/concepts/services-networking/service/#externalname
This functionality does work with nginx-ingress controller.
The text was updated successfully, but these errors were encountered: