Aws-load-balancer-controller: Connect ingress object to existing (Apigee) load balancer?

[kencieszykowski]

Hey everyone,

Currently in the midst of a migration from ECS -> EKS and am struggling for formulate how this can be done (or whether or not this is the correct tool). We are utilizing the controller properly for nearly all of our applications; but we do have an external WAF in front of a shared load balancer, Apigee.

Is there any conceivable way to have the ingress controller create the target group and routing; but be able to specify an existing load balancer? I know this is a bit of a unique situation but any advice is much appreciated.

Thank you

[M00nF1sh]

Hi, it's not possible under current alb ingress controller.
But i do see that this is a valid use case. we may expose such functionality(bind an k8s service to an targetGroup) as an CRD in our next V2 version

[fhut]

Hello,

In addition to the use case presented by the original poster, not having the ALB managed by a kubernetes controller would also allow to use the same load balancer to forward some paths on a common hostname to lambda functions, services running in ECS, or on bare ec2.

I am curious what up/downsides you see in general when only the registration/deregistration of the pods or nodes with a pre-existing target group would be managed by this kubernetes controller.

In a typical setup, terraform or cloudformation will already be in use to create the infrastructure underlying the kubernetes cluster. These tools also offer the ability to manage an ALB, security groups, DNS entries, certificates, WAF rules, listeners, listener rules, and target groups. Unlike nodes and pods, those resources are durable and not dynamic in nature, and having a control loop to sync them from kubernetes resources seems redundant.

The thing terraform and cloudformation lack is dynamic control over the ip addresses or instance ids registered with the target group, and this dynamic control would then be the only job of this kubernetes controller.

[M00nF1sh]

@fhut
Its difference use cases. terraform & cloudFormation also lacks dynamic control of added new rules/new listeners etc.
However, for users that have fixed infrastructure settings, the targets to targetGroup binding functionality is indeed valuable.( they can get all benefits of k8s while keep use their tools to manage infrastructure).
I'll implement this functionality in V2

[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

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