-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Make Kubernetes aware of the LoadBalancer behaviour #1860
Comments
/sig network |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
Hi @Sh4d1 1.20 Enhancements Lead here. This KEP still seems to be a draft (it's provisional) but wanted to check-in to see if you thought this would be graduating alpha in 1.20? Enhancements Freeze is October 6th and by that time we require: The KEP must be merged in an implementable state Best, |
Note: this provisional kep was implemented without having a compliant kep or indicating to the enhancements team that it would be in the 1.20 milestone. |
👋 1.20 release lead here. We're really close to code freeze at this point (Thursday) and it seems like this KEP fell through the cracks and the process. Based on this comment in the PR above: kubernetes/kubernetes#92312 (comment) can we not land this in 1.20 and instead target 1.21? There are few things w/ the KEP that really should be address:
Looks like there is also a PR to update the KEP https://github.com/kubernetes/enhancements/pull/2134/files that addresses this stuff, however it also marks it as implemented and targets 1.21. Typically, we set to implemented only after the release. Can we circle back around on this and agree that we should try to land this in 1.21 at this point? We've already got a lot of content for the release so far (sig-docs has their work cut out for themselves!!!), we're two days out from code freeze, we have these disconnects mentioned above? |
@jeremyrickard just opened kubernetes/kubernetes#96454 to revert it, sorry again! |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
Rotten issues close after 30d of inactivity. Send feedback to sig-contributor-experience at kubernetes/community. |
@fejta-bot: Closing this issue. In response to this:
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/test-infra repository. |
/reopen |
@Sh4d1: Reopened this issue. In response to this:
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/test-infra repository. |
OK, I would promote it to GA in 1.32. |
Thanks @RyanAoh ! I will watch it, let me know if you need something from me! |
Dan and I added way more coverage with cloud-provider-kind so I think we are good to go |
Can I get a quick update? Is someone on the hook for a PR to promote this? |
I am not, @RyanAoh is in charge of this one :) |
@thockin I'm on it and I'll submit the PR(codes, docs and the PRR) this weekend. |
Hello @RyanAoh 👋, Enhancements team here. Just checking in as we approach enhancements freeze on 02:00 UTC Friday 11th October 2024 / 19:00 PDT Thursday 10th October 2024. This enhancement is targeting for stage Here's where this enhancement currently stands:
To track this KEP for enhancements freeze:
The status of this enhancement is marked as If you anticipate missing enhancements freeze, you can file an exception request in advance. Thank you! |
@tjons The Implementation History section has been added to the kep readme. |
@RyanAoh with all the requirements met, this enhancement is now |
Hello @RyanAoh 👋 1.32 Docs Shadow here. Does this enhancement work planned for 1.32 require any new docs or modifications to existing docs? Also, take a look at Documenting for a release to get yourself familiarize with the docs requirement for the release. |
Hi @RyanAoh 👋 -- this is Ryota (@rytswd) from the v1.32 Communications Team! For the v1.32 release, we are currently in the process of collecting and curating a list of potential feature blogs, and we'd love for you to consider writing one for your enhancement! As you may be aware, feature blogs are a great way to communicate to users about features which fall into (but not limited to) the following categories:
To opt in to write a feature blog, could you please let us know and open a "Feature Blog placeholder PR" (which can be only a skeleton at first) against the website repository by Wednesday, 30th Oct 2024? For more information about writing a blog, please find the blog contribution guidelines 📚 Tip Some timeline to keep in mind:
Note In your placeholder PR, use |
Hello, @RyanAoh 👋 1.32 Docs Shadow here. This is just a reminder to open a placeholder PR against dev-1.32 branch in the k/website repo for this (steps available here) for this KEP if it requires new or modifications to existing docs: The deadline for this is Thursday, Oct 24 at 18:00 PDT. |
Hello @RyanAoh 👋, Enhancements team here. With all the implementation(code related) PRs merged as per the issue description: This enhancement is now marked as Please note that KEPs targeting |
Hi @RyanAoh 👋, v1.32 Communications Team here again! This is a gentle reminder for the feature blog deadline mentioned above, which is 02:00 UTC Wednesday, 30th Oct. To opt in, please let us know and open a Feature Blog placeholder PR against Tip Some timeline to keep in mind:
Note In your placeholder PR, use |
@hacktivist123 The PR for the documentation is kubernetes/website#47938, which has already been merged. |
Thanks for the confirmation @RyanAoh ! |
<!-- section-start changelog --> ### Feature Highlights & Upgrade Notes #### Load Balancer IPs set to Private IPs If networking support is enabled, the load balancer IPs are now populated with the private IPs, unless the `load-balancer.hetzner.cloud/disable-private-ingress` annotation is set to `true`. Please make sure that you configured the annotation according to your needs, for example if you are using `external-dns`. #### Provided-By Label We introduced a the label `instance.hetzner.cloud/provided-by`, which will be automatically added to all **new** nodes. This label can have the values `cloud` or `robot` to distinguish between our products. We use this label in the csi-driver to ensure the daemonset is only running on cloud nodes. We recommend to add this label to your existing nodes with the appropriate value. - `kubectl label node $CLOUD_NODE_NAME instance.hetzner.cloud/provided-by=cloud` - `kubectl label node $ROBOT_NODE_NAME instance.hetzner.cloud/provided-by=robot` #### Load Balancer IPMode Proxy Kubernetes KEP-1860 added a new field to the Load Balancer Service Status that allows us to mark if the IP address we add should be considered as a Proxy (always send traffic here) and VIP (allow optimization by keeping the traffic in the cluster). Previously Kubernetes considered all IPs as VIP, which caused issues when when the PROXY protocol was in use. We have previously recommended to use the annotation `load-balancer.hetzner.cloud/hostname` to workaround this problem. We now set the new field to `Proxy` if the PROXY protocol is active so the issue should no longer appear. If you only added the `load-balancer.hetzner.cloud/hostname` annotation for this problem, you can remove it after upgrading. Further information: - kubernetes/enhancements#1860 - #160 (comment) ### Features - **service**: Specify private ip for loadbalancer (#724) - add support & tests for Kubernetes 1.31 (#747) - **helm**: allow setting extra pod volumes via chart values (#744) - **instance**: add label to distinguish servers from Cloud and Robot (#764) - emit event when robot server name and node name mismatch (#773) - **load-balancer**: Set IPMode to "Proxy" if load balancer is configured to use proxy protocol (#727) (#783) - **routes**: emit warning if cluster cidr is misconfigured (#793) - **load-balancer**: ignore nodes that don't use known provider IDs (#780) - drop tests for kubernetes v1.27 and v1.28 ### Bug Fixes - populate ingress private ip when disable-private-ingress is false (#715) - wrong version logged on startup (#729) - invalid characters in label instance-type of robot servers (#770) - no events are emitted as broadcaster has no sink configured (#774) ### Kubernetes Support This version was tested with Kubernetes 1.29 - 1.31. Furthermore, we dropped v1.27 and v1.28 support. <!-- section-end changelog --> --- <details> <summary><h4>PR by <a href="https://github.com/apricote/releaser-pleaser">releaser-pleaser</a> 🤖</h4></summary> If you want to modify the proposed release, add you overrides here. You can learn more about the options in the docs. ## Release Notes ### Prefix / Start This will be added to the start of the release notes. ```rp-prefix ### Feature Highlights & Upgrade Notes #### Load Balancer IPs set to Private IPs If networking support is enabled, the load balancer IPs are now populated with the private IPs, unless the `load-balancer.hetzner.cloud/disable-private-ingress` annotation is set to `true`. Please make sure that you configured the annotation according to your needs, for example if you are using `external-dns`. #### Provided-By Label We introduced a the label `instance.hetzner.cloud/provided-by`, which will be automatically added to all **new** nodes. This label can have the values `cloud` or `robot` to distinguish between our products. We use this label in the csi-driver to ensure the daemonset is only running on cloud nodes. We recommend to add this label to your existing nodes with the appropriate value. - `kubectl label node $CLOUD_NODE_NAME instance.hetzner.cloud/provided-by=cloud` - `kubectl label node $ROBOT_NODE_NAME instance.hetzner.cloud/provided-by=robot` #### Load Balancer IPMode Proxy Kubernetes KEP-1860 added a new field to the Load Balancer Service Status that allows us to mark if the IP address we add should be considered as a Proxy (always send traffic here) and VIP (allow optimization by keeping the traffic in the cluster). Previously Kubernetes considered all IPs as VIP, which caused issues when when the PROXY protocol was in use. We have previously recommended to use the annotation `load-balancer.hetzner.cloud/hostname` to workaround this problem. We now set the new field to `Proxy` if the PROXY protocol is active so the issue should no longer appear. If you only added the `load-balancer.hetzner.cloud/hostname` annotation for this problem, you can remove it after upgrading. Further information: - kubernetes/enhancements#1860 - #160 (comment) ``` ### Suffix / End This will be added to the end of the release notes. ```rp-suffix ### Kubernetes Support This version was tested with Kubernetes 1.29 - 1.31. Furthermore, we dropped v1.27 and v1.28 support. ``` </details> Co-authored-by: releaser-pleaser <>
Enhancement Description
k/enhancements
) update PR(s):k/k
) update PR(s):k/website
) update(s):k/enhancements
) update PR(s): KEP-1860 - Propose beta graduation and add missing PRR #4509k/k
) update PR(s): Promote LoadBalancerIPMode to Beta kubernetes#123418k/website
) update(s): Promote LoadBalancerIPMode to Beta website#45219k/enhancements
) update PR(s): Add the implementation history section #4891, Promote LoadBalancerIPMode to GA #4854k/k
) update PR(s): Promote LoadBalancerIPMode to GA kubernetes#127348k/website
) update(s): Promote LoadBalancerIPMode to GA website#47938Please to keep this description up to date. This will help the Enhancement Team track efficiently the evolution of the enhancement
The text was updated successfully, but these errors were encountered: