Repository navigation
feat: select services by service-proxy-name label - #9
Conversation
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request updates the service selection logic to support the standard service.kubernetes.io/service-proxy-name: cozy-proxy label alongside the legacy networking.cozystack.io/wholeIP: "true" annotation. This improvement ensures that kube-proxy ignores services handled by cozy-proxy, preventing rule collisions in clusters using plain kube-proxy. The README has been updated with guidance on which selector to use and the controller code now implements the dual-selection logic. I have no feedback to provide.
Add support for the standard Kubernetes service.kubernetes.io/service-proxy-name label with value "cozy-proxy" as an alternative to the legacy networking.cozystack.io/wholeIP annotation. Either selector alone is sufficient; both may be set on the same Service. The label is the recommended selector for plain kube-proxy (iptables/IPVS) deployments, because kube-proxy natively skips services carrying it, eliminating the rule collision that otherwise breaks outbound SNAT after the move to raw table early_snat (v0.2.0). The annotation is retained for backward compatibility. Refs: #8 Co-Authored-By: Claude <[email protected]> Signed-off-by: Andrei Kvapil <[email protected]>
Co-Authored-By: Claude <[email protected]> Signed-off-by: Andrei Kvapil <[email protected]>
Co-Authored-By: Claude <[email protected]> Signed-off-by: Andrei Kvapil <[email protected]>
d5531a6 to
d3a72e6
Compare
Summary
Adds support for selecting services via the standard Kubernetes
service.kubernetes.io/service-proxy-name: cozy-proxylabel, in addition to the existingnetworking.cozystack.io/wholeIP: "true"annotation. A service matching either selector is managed by cozy-proxy.Motivation
Since v0.2.0 cozy-proxy performs stateless NAT in the
rawtable (early_snatchain). On clusters running plain kube-proxy (iptables/IPVS) — e.g. default RKE2 + Calico + MetalLB — kube-proxy installs its own LoadBalancer rules that race with cozy-proxy's raw-table NAT and break outbound SNAT. Theservice.kubernetes.io/service-proxy-namelabel is the standard Kubernetes mechanism that instructs kube-proxy to ignore a service, letting cozy-proxy fully own its packet path. Cozystack itself adopted the same label on VM LoadBalancer services in cozystack/cozystack#2357.The legacy annotation is kept as-is so existing deployments need no changes.
Changes
Test plan
service-proxy-name=cozy-proxyRefs: #8