aws-load-balancer-controller icon indicating copy to clipboard operation
aws-load-balancer-controller copied to clipboard

Optimize shared target groups

Open RobinFrcd opened this issue 1 year ago • 3 comments

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

RobinFrcd avatar Jul 09 '24 13:07 RobinFrcd

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?

shraddhabang avatar Jul 10 '24 21:07 shraddhabang

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 !

RobinFrcd avatar Jul 11 '24 00:07 RobinFrcd

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 avatar Oct 09 '24 01:10 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

k8s-triage-robot avatar Nov 08 '24 01:11 k8s-triage-robot

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

This bot triages 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:

  • Reopen this issue with /reopen
  • Mark this issue as fresh with /remove-lifecycle rotten
  • Offer to help out with Issue Triage

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

/close not-planned

k8s-triage-robot avatar Dec 08 '24 01:12 k8s-triage-robot

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages 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:

  • Reopen this issue with /reopen
  • Mark this issue as fresh with /remove-lifecycle rotten
  • Offer to help out with Issue Triage

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

/close not-planned

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-sigs/prow repository.

k8s-ci-robot avatar Dec 08 '24 01:12 k8s-ci-robot