Adopting existing NLBs/TargetGroups that point towards host network pods

[fvlaicu]

Is your feature request related to a problem?

We're looking to use the AWS lb controller to manage load balancers on our Kubernetes fleet. Our ingress pods run in the host network and receive the traffic directly from the NLB. To be more clear, we add the AWS instances to the target group and send traffic to the ports on which the ingress pods run. I would like the ability to adopt/import the existing NLBs/TargetGroups as is.

Describe the solution you'd like A description of what you want to happen.

I would like to have a way for the instances that run the ingress pods to be added to the target group without the use of node ports (since the pods are already in the host network).

Describe alternatives you've considered A description of any alternative solutions or features you've considered.

[csantanapr]

Did you try using the TargetGroupBinding ?

With targetType: instance should allow you to point to the instance port

[M00nF1sh]

@fvlaicu the answer provided by fvlaicu is correct, you should use TargetGroupBinding on existing NLB/TargetGroups.

We don't have plans to officially support "adopt" existing resources for Ingress/Services at the moment. Though technically you can hack it by attach required aws tags to existing AWS resource to cheat the controller thus it believe those resources are created by it and use them

[fvlaicu]

I tried earlier to use a loadbalancer type service, however, that changed the target group and added node ports.

[M00nF1sh]

@fvlaicu You need to apply aws tags to existing targetGroups/security groups as well for the lbc to adopt it

[M00nF1sh]

we have a sync up, seems you only want the controller to manage the targets. So targetGroupBinding is the choice which allows you to bind a existing TargetGroup to a Service(you should be able to use a clusterIP or nodePort service)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[andrew-purdin]

Just curious @M00nF1sh , if this process works, why isn't it supported or officially documented?