Aws-load-balancer-controller: Map `/` to `/*`

[rahulwa]

I believe path: / in ingress object should be treated as /* in alb ingress controller implementation.

Most of the upstream projects (Charts examples) considers ingress path / as /* and it is so wild assumption that many charts doesn't even provides a way to override it while installing them.

---

alb-ingress-controller version: 1.0-beta.7

[marcusianlevine]

Upgrading to 1.0-beta.7 broke our existing deployment of this controller due to this issue: root path rules created on ALBs do not route any path other than the exact root path {hostname}/

[marcusianlevine]

Found a work-around: if you explicitly set the path for your backends to /* then the ALB rule will be created as a wildcard

Only downside is the endpoint URLs provided for the ingress by k8s won't work since they will be .../*

Here's the relevant part of the source code: https://github.com/kubernetes-sigs/aws-alb-ingress-controller/blob/354477f8d9ec26831b6f94f10c1a2f3873a4ba11/internal/alb/rs/rule.go#L73

Might try to open a PR with a separate case for o.Path == '/'

[vincentjorgensen]

@marcusianlevine What do you mean: "endpoint URLs provided for the ingress by k8s won't work since they will be .../"? I have my last ALB paths.path='/' and it seems to catch whatever else. What I would prefer, is if I could override the default to be my rule and not the 404 rule that the Ingress is inserting.

[bigkraig]

You can change the default backend by setting a default backend in the ingress. It’s set outside of the paths. I’m on my phone or I’d dig up an example or the ingress docs, but if you search around you should be able to find it

[marcusianlevine]

Originally (pre-1.0) we had ingress rules of the form:

  - host: my-service.example.com
    http:
      paths:
      - backend:
          serviceName: my-service
          servicePort: 80

Which would lead to host-based rules on the ALB which route all paths with my-service.example.com in the host header

However after upgrading to 1.0-beta.7 the rules on the ALB were created with "Host is my-service.example.com" AND "Path is /"

So now any path other than my-service.example.com/ gets 404'd by the ALB, as described by @rahulwa

By explicitly specifying the path key of the ingress rule to /* the ALB rule routes any path under the specified host, such as my-service.example.com/login:

  - host: my-service.example.com
    http:
      paths:
      - path: /*
        backend:
          serviceName: my-service
          servicePort: 80

AFAIK that's the intended behavior of path: / in the ingress spec, but ALBs don't treat / as a wild-card path so this ingress controller needs to map path: / to a rule with /*

[marcusianlevine]

According to the release notes of 1.0-beta.7 this is a known side-effect of making 404 the default backend: https://github.com/kubernetes-sigs/aws-alb-ingress-controller/releases/tag/1.0-beta.7

I think there are a couple of options to make the default logic more sane:

1. Don't create a path condition if path.Path == '/'
2. Append * according to some logic: path.Path == '/' or maybe even any path that ends in a slash

All the other ingress controllers I've used (Zalando ALB, official NGINX) map the root path / to any path (wildcard)

For reference here's the AWS ALB docs on wildcard paths: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#path-conditions

[M00nF1sh]

There is actually a long running issue about the path usage: https://github.com/kubernetes/contrib/issues/885
In short: nginx ingress controller does wildcard expansion, so / maps regex /*
GKE ingress controller doesn't do wildcard expansion, so / maps regex /$, and you have to explicitly specify /*

From my POV, i think the GKE behavior(which we adopted) is better, since it's maps natively to the cloud implementation(path condition in rules).
Also, it's more flexible, since you cannot achieve explicit "/$" match if you do wildcard expansion.

[bigkraig]

@marcusianlevine I'm hesitant to add wildcards since it would make it impossible for someone to set a rule on something that ends in a /, but adding that path-pattern was a mistake and is addressed in #670

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[Vrtak-CZ]

this is still not solved :-(

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[tewner]

What happened with this? Was there a decision made?

[M00nF1sh]

@tewner
Yes, the current behavior is of ingress path is per cloud-provider, and we will stick to the ALB's path rule.
There have been discussing in the k8s community to add more cloud-agnostic behavior to ingress(like a additional field like path-regex).

[tewner]

Thank you @M00nF1sh . I can't honestly say that I understand this decision, but I assume it was made by people way more knowledgable than me!

Shouldn't Kubernetes abstract the platform-specific config away from my app? The application requests an ingress. I configure each of my Kubernetes clusters with my ingress-controller-of-choice, and worst-case I convince my developers to add annotations which are only relevant to specific controllers. The same Application-defined ingress should be platform-agnostic and runnable on any cloud provider.