Aws-load-balancer-controller: Use an existing ALB

Created on 30 Sep 2017 · 22Comments · Source: kubernetes-sigs/aws-load-balancer-controller

As a user of Terraform (or, substitute CloudFormation), I would like to use an existing ALB with the ingress controller so that I can keep my infrastructure automation centralized rather than in several different places. This also externalizes the various current and future associations between ALB and other parts of the infrastructure that may already be defined in TF/CFN (certs, Route53, WAF, CloudFront, other config).

kinfeature lifecyclrotten

Source

countergram

👍45

Most helpful comment

What is ETA for this?

jainishshah17 on 24 Jun 2020

👍7

All 22 comments

@countergram Thanks, we've heard this request and similar a few times now.

Seems a feature that many would like is an ability to explicitly call our a named ALB via annotation (or eventually configmap).

joshrosso on 4 Oct 2017

Is there any updates for this issues?

markbooch on 24 Oct 2018

Hey, I might have solved your problem in this PR: https://github.com/kubernetes-sigs/aws-alb-ingress-controller/pull/830 . Testing and feedback is welcome :)

marcosdiez on 25 Jan 2019

@joshrosso Is there any update on this request?

benderillo on 20 Mar 2019

Relevant: https://github.com/kubernetes-sigs/aws-alb-ingress-controller/issues/914

tdmalone on 7 Apr 2019

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 on 6 Jul 2019

I was able to use one ALB for multiple Ingress Resources in Version 1.0.1. I did create a new cluster and installed Version 1.1.2, which is creating a new ALB for each Ingress Resource. Is there anyway that I can use same ALB in 1.1.2 ?

npolagani on 1 Aug 2019

👍1

^ cross-posted at https://github.com/kubernetes-sigs/aws-alb-ingress-controller/issues/984#issue-475466050, https://github.com/kubernetes-sigs/aws-alb-ingress-controller/issues/724#issuecomment-517113838

tdmalone on 6 Aug 2019

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

fejta-bot on 5 Sep 2019

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

fejta-bot on 5 Oct 2019

@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.

k8s-ci-robot on 5 Oct 2019

@leoskyrocker: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

k8s-ci-robot on 29 Oct 2019

@M00nF1sh @joshrosso Any update here? I think this issue is still relevant today and yet unsolved.

Having a way for Kubernetes to attach to existing ALBs/Target Groups is incredibly valuable for lots of reasons. Really surprised there's no way to do it right now.

gkrizek on 4 Mar 2020

@gkrizek
we'll address this issue in V2.
For attach to existing TargetGroups, we'll expose an CRD called endpointBinding to allow do that.
For attach to existing ALB, we haven't decided whether to use an annotation on Ingress(like alb-arn: xxxx) or an AWS tag on the ALB(like ownership: shared, ingress: ingress-name, cluster: cluster-name). any opinions?

M00nF1sh on 4 Mar 2020

👍1

@M00nF1sh Great to hear! I hate to be "that guy" but is there a v2 anticipated release date?

I like the CRD idea for target groups, I think that's the right direction. I think both options are valid for the ALB, however I think tags are preferred. Because with an ARN you might have to do some wacky stuff to get the ARN into a manifest/helm chart. With tags it'd be pretty easy to define without needed explicit values from AWS. Also it would allow for an ingress to attach to multiple ALBs if one chooses.

gkrizek on 4 Mar 2020

@gkrizek There is no anticipated released date yet( i cannot promise one), but I'll keep update https://github.com/kubernetes-sigs/aws-alb-ingress-controller/projects/1 whenever i got time to work on it 🤣.
BTW, there is an alpha version of V2 which works just fine: https://github.com/kubernetes-sigs/aws-alb-ingress-controller/releases/tag/v1.2.0-alpha.1 (you can reuse an ALB by apply correct tags, however, the controller will try to delete the ALB once we delete the ingress)

M00nF1sh on 4 Mar 2020

having a single ingress: tag forces a many:1 relationship of ingresses to ALBs which contradicts the concept of ingress grouping mentioned in other issues. It'd be great if the design could allow many ALBs to be reused by many ingresses. Perhaps a "binding" CRD similar to the endpoint/targetgroup solution mentioned above?

rifelpet on 4 Mar 2020

@M00nF1sh I figured so 😉 . Sounds good, I'll check out the alpha for now. Thanks for the help.

gkrizek on 4 Mar 2020

@rifelpet
it's actually an ingress.k8s.aws/stack: <value> annotation on ALB in V2, where the can be "namespace/ingress-name" or "group-name". So it's still a 1-1 relation between a group and ALB.

(However, personally i favor to require an explicit annotation of ..../alb-arn:xxxx on one-of-ingresses among group to denote the reuse, since tagging on ALB requires to plan for Ingress before hand)

What do you mean by allow many ALBs to be reused by many ingresses.? Current design is one group will only have one ALB.

It's possible to extend it to be like one group with multiple ALB(like auto-split rules), but is there really a use case for this?
since i assume there are app-specific dependencies like some Ingress must be hosted by a single DNS name, so it's impossible for the controller to make the split decision if rule exceeds ALB's limits, instead it's better for the user to split there ingresses into different groups.

M00nF1sh on 4 Mar 2020

ok, my main concern was supporting a 1-1 relation between a group and ALB and it sounds like the tags can achieve that 👍

rifelpet on 4 Mar 2020

Hi @M00nF1sh keen to start testing with the v1.2.0-alpha.1 version - can you point me to what tags are needed in order to reuse an existing ALB?

BTW, there is an alpha version of V2 which works just fine: https://github.com/kubernetes-sigs/aws-alb-ingress-controller/releases/tag/v1.2.0-alpha.1 (you can reuse an ALB by apply correct tags, however, the controller will try to delete the ALB once we delete the ingress)