[Feature Request] Allow TargetGroupBinding to target IPs / CIDRs that are direct connected or peered

[KenFigueiredo]

Hey there!

Is your feature request related to a problem? I have a use case where I have on-premise Kubernetes cluster which is connected to my VPC via AWS Direct Connect and want to be able to auto register NodePort targets on the cluster automatically via the TargetGroupBinding. This isn't currently supported as IP targeting expects PodIps via the aws-vpc-cni which wouldn't exist in a non AWS bound cluster while instance targeting expects an EC2 instance id.

Describe the solution you'd like Support IP targeting with an "all" AZ on services exposed as Nodeports.

Describe alternatives you've considered Two workarounds on this are either manually managing a target group and hardcoding the exposed Ingress IP or creating a separate process to sync NodePorts -> Target Groups across all the nodes. However it's not a resilient solution as if those nodes ever get rotated or new nodes scale in / out of the cluster we have to manually track those nodes.

I made a PoC of this working on a private fork that by reusing the approach in the instance targeting and modifying the Endpoint Resolver & Resource Manager to accept NodeIPs as an alternative to InstanceIds and the rest of the logic of the controller seems to hold. Albeit I don't have enough context into the codebase to know what other implications this change could have.

[M00nF1sh]

@KenFigueiredo I think we can support this "instance mode" but using NodeIP instead of NodeInstance id when register targets. there are options:

1. add new fields into TargetGroupBindings and new annotations to service/ingresses to enable this feature per targetGroup
2. add a new feature flag to enable this feature cluster-wide for all instance type target groups. (could be a problem if cx wants some target-group to use instance-id but other target group to use instance-ip)

Personally i think the use case of this is pretty limited, thus option-2 above feels better to me which minimizes the impact/changes needed.

[KenFigueiredo]

@M00nF1sh

I'm in the same boat as you for option 2, I can't really think of a use case to need to target NodeIPs and InstanceIds within an EKS or kops-like cluster.

I might have some spare time coming up that I can reimplement my fork to use that approach instead. Right now I'm just checking for a specific annotation to exist on the TargetGroupBinding

[krishnaastica]

@M00nF1sh @KenFigueiredo Happy New Year.. Do we have any progress on this feature? It is one of the top blocker for our developed implementation model. Thanks in advance

[krishnaastica]

@M00nF1sh Wanted to know if this feature is currently available. HELP

[krishnaastica]

As we don't have this feature for now, as a workaround I have created a Lambda function which gets triggered based on CloudTrail events for RegisterTargets / DeRegisterTargets for the particular source target group. Upon trigger it will get the required details and will register or deregister the targets in the destination target group.

But this is a overhead and we look forward to this feature. @M00nF1sh

[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

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