Aws-load-balancer-controller: Share the single ALB

[manojbadam]

I'm following through getting started guide and examples echoserver and 2048-game. I'm expecting the same ALB (with different rules & target groups) will be used for the both the ingress definitions in different namespaces. But I can see two different ALB's created, one for echo server and other for 2048-game. Is this expected ? or any configuration changes to make it happen ?

[M00nF1sh]

Hi, it's not supported for now.
we are going add support for this, details can be viewed in #688

[manojbadam]

Thanks @M00nF1sh also, another question - Is there a way can we assign the existing ALB (spin up outside of ingress-controller, through terraform/cloudformation) to the ingress definitions through annotations ?

[M00nF1sh]

@manojbadam It's also not supported, and haven't been planed yet.
Can you share me your use case for this? I can only think of two scenario for it:

1. Some organization have some strict policy that requires every ALB needs to be created by their own IT infrastructure system. (But if so, how can they deal with k8s service with LoadBalancer type?)

2. You are doing migrating an existing infrastructure into k8s. e.g. for /api/products, route traffic to existing system, for /api/orders, route traffic to system powered by k8s. (For this case, it will be complicated to support since we need to know which rule are created for k8s)

[manojbadam]

We would like to use an(or many) existing ALB(s), but let the ingress controller(s) manage the registration of pods (target groups) _onto_ it. We imagine this should happen via tags -- does the controller need to be aware that it itself did not assign a tag giving it permissions to edit target groups on the ALB?

This scenario is useful for a number of different reasons:

• kubernetes may not be the only service attaching routes to this alb
• like you mentioned, externally generated alb infrastructure
• "stickyness" - in some environments, the risk of alb deletion is not acceptable (no services != no need for the alb to exists)
• pre-provisioning: as is, the controller "lazy loads" an ALB (creates one _once_ a pod is ready - this might not be desired behavior)

[rifelpet]

for what its worth, we solve your stickyness issue by enabling deletion protection:

alb.ingress.kubernetes.io/attributes: deletion_protection.enabled=true

That way if all the services are deleted or the ingress is accidentally deleted, the ALB is not deleted and once the services or ingress are recreated, connectivity will be restored with no change in DNS. To truly delete the ALB, just remove the annotation first, then delete the ingress.

[marcosdiez]

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 :)

[tdmalone]

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

[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

[Giaco9]

Any news on this? I'm really interested in the support of already existent ALB in order to migrate our ECS workload to EKS. Is there any issue that I should follow?

Thanks

[M00nF1sh]

@Giaco9 Hi, there is an alpha version to use single ALB. (And it can reuse existing external-provisioned alb ideally by apply proper tags, but we don't plan to maintain support for that case)

[tdmalone]

@Giaco9 #914 is probably the best issue to watch currently.
There's a few though - I've listed them here: https://github.com/kubernetes-sigs/aws-alb-ingress-controller/issues/914#issuecomment-505689241

[Giaco9]

Thank you @tdmalone I subscribed to #914

@M00nF1sh what do you mean "we don't plan to maintain support for that case"? Is it like "use it as your own risk"?

Thank you :)

[M00nF1sh]

Thank you @tdmalone I subscribed to #914

@M00nF1sh what do you mean "we don't plan to maintain support for that case"? Is it like "use it as your own risk"?

Thank you :)

Yes. For example, the controller will try to delete the LB when you delete the Ingress. To fully support use external LB, an new annotation like external-lb should be added. There are many edge case around external LB usage, like how to handle existing listener / rules on the LB.

[npolagani]

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 ?

[tdmalone]

^ 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/228#issuecomment-517112339

[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

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