Is it possible to skip creation of Path condition in alb listener rule?

[uyilmaz]

Is your feature request related to a problem?
There is a limit of 5 conditions per rule in alb. Rules created by alb ingress controller always include "Http Host Header" and "Path" conditions, which reduces available condition count to 3. Is it possible to skip adding the Path condition, so we can have 4 additional free condition slots? Because when path is /*, it also works without having the condition at all, so 1 condition slot is needlessly consumed.

Describe the solution you'd like
I'd like to be able to skip adding the "Path" condition to the listener rule and match using "Http Host Header" only.

Describe alternatives you've considered
Changing pathType to ImplementationSpecific or dropping any kind of path declarations in the ingress controller doesn't change anything, the path condition is still created.

[oliviassss]

@uyilmaz, thanks for the feedback. Just try to understand the use case here, what's the listener rules that you don't need a "path" condition? Like if you are building exact pathType or prefix pathType with path /?

[uyilmaz]

@oliviassss Thanks for replying! For my use case it doesn't matter if it's exact or prefix, both works since I only need to route based on the hostname. What I'd like to have is 4 free slots after the hostname that I can use for other rules (mainly IP based access restriction)

[sagar-soulai]

Please provide this functionality and make alb ingress similar like nginx ingress, because nginx ingress also supports path rewriting but alb doesn't support.

[Sarga]

I'm also interested in it.

[lblazewski]

Looking forward to this feature as well. Similar as described above, I am routing only on the host header so the path condition is not needed.

[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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten