Optimize shared target groups

[RobinFrcd]

Hi, I have to expose a service in multiples ways (OIDC, IP filtering, etc..) but to do that I have to create multiple Ingresses. Every time I create a new Ingress, it creates a new target group, and I reached the number of target groups attached to my ALB: You have reached the maximum number of unique target groups that you can associate with a load balancer of type 'application': [100]. Is there a way to share target groups between Ingresses ? To have 1 service = 1 target group ?

Example: I have a service I want to expose in 2 ways:

• Open to the internet, but protected by an OIDC alb.ingress.kubernetes.io/auth-type: oidc
• Open to only a set of IPs with: alb.ingress.kubernetes.io/conditions.svc: > [{"field":"source-ip", "sourceIpConfig":{"values": ...}}]

This needs 2 different ingresses, but both are pointing to the same service. It results in 2 target groups, where it could work with only one.

Thanks !

Environment

• AWS Load Balancer controller version: v2.8.1
• Kubernetes version: 1.30
• Using EKS (yes/no), if so version?: eks.2

[shraddhabang]

Have you tried using the TargetGroupBinding for your service? You can then use this target group to be attached to your ingress using actions. Can you please try this configuration and see if this helps your case?

[RobinFrcd]

Thank you for your answer ! But it needs a targetGroupARN to be set right ? So I would need to create a first ingress, find a way to get its target group ARN and then, based on that, start another ingress using this targetGroupARN. Can't be done in a single deployment.

Thanks again for your help !

[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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten