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

Create option to reuse an existing ALB instead of creating a new ALB per Ingress #298

Open
julianvmodesto opened this Issue Jan 10, 2018 · 15 comments

Comments

Projects
None yet
@julianvmodesto
Copy link

julianvmodesto commented Jan 10, 2018

I read in this comment #85 (comment) that host-based routing was released for AWS ALBs shortly after ALB Ingress Controller was released.

It would be pretty cool to have an option to reuse an ALB for an Ingress via annotation -- i'd be interested in contributing towards this, but I'm not sure what's needed to make this feasible.

@pperzyna

This comment has been minimized.

Copy link

pperzyna commented Mar 12, 2018

@bigkraig Any update?

@mwelch-ptc

This comment has been minimized.

Copy link

mwelch-ptc commented Jun 20, 2018

Wait... I guess I missed this in reading the documentation. Are you saying that every Ingress created deploys it's own ALB? So for our 60 or so ingresses we'd end up with 60 ALB's? What about different host names within the same ingress? Does that at least reuse the same ALB?

@patrickf55places

This comment has been minimized.

Copy link

patrickf55places commented Jun 20, 2018

@mwelch-ptc That is correct. There is a 1-to-1 mapping of Ingress resources to ALBs, even if host names are the same.

@kurtdavis

This comment has been minimized.

Copy link

kurtdavis commented Jun 20, 2018

Seems to be fairly costly. We have looked at other solutions due to this issue.

@bigkraig

This comment has been minimized.

Copy link
Collaborator

bigkraig commented Jun 20, 2018

What is everyones thoughts on how to prioritize the rules if a single ALB spans ingress resources and potentially event namespaces? I can see where in larger clusters multiple teams may accidentally take the same path.

@vainu-arto

This comment has been minimized.

Copy link

vainu-arto commented Jun 21, 2018

What is everyones thoughts on how to prioritize the rules if a single ALB spans ingress resources and potentially event namespaces? I can see where in larger clusters multiple teams may accidentally take the same path.

This is a general Kubernetes ingress issue, not specific to this ingress controller. I think the discussion of this should be had in a more general forum instead of an issue against this controller.

@whithajess

This comment has been minimized.

Copy link
Contributor

whithajess commented Jul 16, 2018

Im tempted to say that this is not a general Kubernetes ingress issue.

Existing load balancers supported by Kubernetes are Layer 4 - And are supported by Ingress Controllers that do the Layer 7 (This means they can use 1 load balancer and then deal with layer 7 when it gets into the cluster)

ALB is Layer 7 and is dealing with it before it gets to Kubernetes, so we cannot assume they are going to change for this use case.

As this becomes more standard i think this could change GCE suggests "If you are exposing an HTTP(S) service hosted on Kubernetes Engine, HTTP(S) load balancing is the recommended method for load balancing." and I would imagine as EKS kicks off it will suggest the same.

@spacez320

This comment has been minimized.

Copy link

spacez320 commented Jul 29, 2018

We can already generally do this by having a singular ingress resource, although it makes whatever deployment scheme you're using for Kubernetes have to adjust to that. It's also worth pointing out that in Kubernetes Ingress documentation, it literally states:

An Ingress allows you to keep the number of loadbalancers down to a minimum.

I think it would be really nice to have the ability to do this in a nice way.

@bigkraig

This comment has been minimized.

Copy link
Collaborator

bigkraig commented Aug 3, 2018

@spacez320 I read that as that you can have an ingress with multiple services behind it, so a single load balancer for many services as opposed to a load balancer per service.

There is still the issue that the IngressBackend type does not have a way to reference a service in another namespace. I think until the ingress resource spec is changed, there isn't a correct way of implementing something like this.

@bigkraig bigkraig closed this Aug 3, 2018

@patrickf55places

This comment has been minimized.

Copy link

patrickf55places commented Aug 3, 2018

@bigkraig I don't think this issue should be closed. The issue isn't about having a single Ingress resource that can span multiple namespaces. It is about having multiple Ingress resources (possible across different namespaces, but not necessarily) that all use the same AWS application load balancer.

@bigkraig bigkraig reopened this Aug 3, 2018

@bigkraig

This comment has been minimized.

Copy link
Collaborator

bigkraig commented Aug 3, 2018

@patrickf55places got it, within the namespace is possible with the spec but I am still unsure how we would organize the routes or resolve conflicts.

@spacez320

This comment has been minimized.

Copy link

spacez320 commented Aug 4, 2018

@bigkraig Well, I think it's both, and I think that's what @patrickf55places meant by saying "possible across different namespaces, but not necessarily". We should be able to define an Ingress anywhere and share an Amazon load balancer, I think.

I understand if there's limitations in the spec, though. Should someone go out and try to raise this issue with the wider community? Is that possibly already happening?

@natefox

This comment has been minimized.

Copy link
Contributor

natefox commented Aug 15, 2018

What about using something similar to how nginx ingress handles it?
https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/mergeable-ingress-types

Multiple minions can be applied per master as long as they do not have conflicting paths. If a conflicting path is present then the path defined on the oldest minion will be used.

@joegoggins

This comment has been minimized.

Copy link

joegoggins commented Aug 30, 2018

I was glad to find this GitHub issue and also bummed that it seems like it will be a long time before this will get implemented. It smells like there is a lot of complexity associated with the change and potentially not resources to dig into it. I'm assuming it will be many months and thus our engineering team is going to switch our technical approach to use a different load balancing ingress strategy with AWS costs that scale economically in-line with our needs. If that assessment feels wrong, please let me know.

@jakubkulhan

This comment has been minimized.

Copy link

jakubkulhan commented Sep 26, 2018

I've created another ingress controller that combines multiple ingress resources into a new one => https://github.com/jakubkulhan/ingress-merge

Partial ingresses are annotated with kubernetes.io/ingress.class: merge, merge ingress controller processes them and outputs a new ingress annotated with kubernetes.io/ingress.class: alb, then ALB ingress controller takes over and creates single AWS load balancer.

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