Skip to content
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

HAP Ingress not finding service if targetPort is http #1084

Open
rafaelcpalmeida opened this issue Feb 29, 2024 · 2 comments
Open

HAP Ingress not finding service if targetPort is http #1084

rafaelcpalmeida opened this issue Feb 29, 2024 · 2 comments

Comments

@rafaelcpalmeida
Copy link

Description of the problem

HAProxy Ingress can't find my service if my targetPort is set to http

Expected behavior

HAProxy Ingress would my service even if my targetPort is set to http

Steps to reproduce the problem

  1. Install HAP Ingress
  2. Deploy your pod with named ports
  3. Create a new service and set the target port to the name of the port of the pod

Environment information

HAProxy Ingress version: v0.14.6

Command-line options:

--configmap=default/forge-ingress-haproxy-haproxy-ingress --ingress-class=haproxy --sort-backends

Global options:

cross-namespace-services: allow
healthz-port: '10253'
stats-port: '1936'

Here are the logs for the attempts of reconciliation.

If the service has the following ports configuration

  ports:
    - name: http
      protocol: TCP
      port: 8000
      targetPort: http

The logs show

I0229 16:04:28.273463       7 controller.go:339] starting haproxy update id=19
I0229 16:04:28.273543       7 converters.go:67] applying 2 change notifications: [update/Endpoints:floating-point-jwt-auth/fp-jwt-auth update/Service:floating-point-jwt-auth/fp-jwt-auth]
I0229 16:04:28.273581       7 ingress.go:232] syncing 1 host(s) and 2 backend(s)
W0229 16:04:28.273665       7 ingress.go:444] skipping auth-url on Ingress 'floating-point-rest-api/fp-rest-api': port not found: '8000'
W0229 16:04:28.273697       7 backend.go:189] skipping auth-url on Ingress 'floating-point-rest-api/fp-rest-api': service 'fp-jwt-auth:8000' was not found
I0229 16:04:28.273764       7 instance.go:441] updating 0 host(s): []
I0229 16:04:28.273774       7 instance.go:458] updating 2 backend(s): [floating-point-jwt-auth_fp-jwt-auth_8000 floating-point-rest-api_fp-rest-api_http]
I0229 16:04:28.273796       7 dynupdate.go:215] diff outside endpoints of backend 'floating-point-rest-api_fp-rest-api_http'
I0229 16:04:28.273812       7 dynupdate.go:104] need to reload due to config changes: [backends]
I0229 16:04:28.294793       7 instance.go:401] haproxy successfully reloaded (embedded daemon)
I0229 16:04:28.294848       7 controller.go:348] finish haproxy update id=19: parse_ingress=0.238253ms write_maps=0.038453ms write_config=0.881407ms reload_haproxy=20.126960ms total=21.285073ms

However, if we update the service to

  ports:
    - name: http
      protocol: TCP
      port: 8000
      targetPort: 8000

The logs show:

I0229 16:07:49.031973       7 controller.go:348] finish haproxy update id=24: parse_ingress=0.070875ms write_maps=0.008510ms total=0.079385ms
I0229 16:08:13.200591       7 controller.go:339] starting haproxy update id=25
I0229 16:08:13.200687       7 converters.go:67] applying 2 change notifications: [update/Endpoints:floating-point-jwt-auth/fp-jwt-auth update/Service:floating-point-jwt-auth/fp-jwt-auth]
I0229 16:08:13.200710       7 ingress.go:232] syncing 1 host(s) and 2 backend(s)
I0229 16:08:13.200876       7 instance.go:441] updating 0 host(s): []
I0229 16:08:13.200887       7 instance.go:458] updating 1 backend(s): [floating-point-rest-api_fp-rest-api_http]
I0229 16:08:13.200938       7 dynupdate.go:104] need to reload due to config changes: [frontend]
I0229 16:08:13.240620       7 instance.go:401] haproxy successfully reloaded (embedded daemon)
I0229 16:08:13.240671       7 controller.go:348] finish haproxy update id=25: parse_ingress=0.204812ms write_maps=0.050514ms write_config=4.957019ms reload_haproxy=34.701674ms total=39.914019ms
@jcmoraisjr
Copy link
Owner

Hi, this is a known behavior already reported in #981 . The way to circumvent this for now is to either use a port number in the service declaration, or use the named target port in the auth-url declaration. Here's the relevant doc snippet:

If the service uses named ports, use the service’s port.targetPort field value instead.

Copy link

This issue got stale and will be closed in 7 days.

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

No branches or pull requests

2 participants