Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Support specifying a custom subnet for L7 ILBs #1382

Open
cezarsa opened this issue Mar 15, 2021 · 4 comments
Open

Feature: Support specifying a custom subnet for L7 ILBs #1382

cezarsa opened this issue Mar 15, 2021 · 4 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@cezarsa
Copy link

cezarsa commented Mar 15, 2021

Currently it's not possible to create a L7 Internal Load Balancer using Ingress objects in a subnet different from the one used for nodes. According to GKE networking best practices doc it's recommended to reserve a separated subnet for L4 ILBs and I can see that the same arguments for isolation would also hold for L7 ILBs, if that was possible.

For L4 ILBs created using a Service with type LoadBalancer, this can be done using the annotation networking.gke.io/internal-load-balancer-subnet from kubernetes/kubernetes#82257. Would it be possible for support for the same annotation to be added to Ingress objects? Another possibility would be a new field in FrontendConfig objects.

@fejta-bot
Copy link

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-contributor-experience at kubernetes/community.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 13, 2021
@fejta-bot
Copy link

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-contributor-experience at kubernetes/community.
/lifecycle rotten

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jul 13, 2021
@freehan freehan added kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. labels Jul 21, 2021
@plgingembre
Copy link

@cezarsa, thanks for your question! I actually have a question for you, can you elaborate on the use case on your end for this option in Ingress? How are you working around that missing option today?

Thanks,
Pierre-Louis

@cezarsa
Copy link
Author

cezarsa commented May 24, 2022

Hey @plgingembre, since creating this feature request I moved on to a new job, working mostly with a different cloud provider. Answering based on what I remember and it's possible I'm incorrect.

I think the primary use case would be being able to create firewall rules matching a subset of L7 ILBs. Without this annotation, all L7 ILB IPs would be allocated from the node IP subnet and it would be impossible to tell at a glance if an IP belongs to a node or to an ILB.

The workaround I guess was creating individual firewall rules for each individual ILB IP, since they also didn't support network tags at the time at least.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Development

No branches or pull requests

5 participants