-
Notifications
You must be signed in to change notification settings - Fork 40k
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 #92312
Conversation
pkg/apis/core/types.go
Outdated
@@ -3406,8 +3406,23 @@ type LoadBalancerIngress struct { | |||
// (typically AWS load-balancers) | |||
// +optional | |||
Hostname string | |||
|
|||
// RouteType specifies the type of route to use for this ingress | |||
// Defaults to `VIP` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this has to be defaulted here?
kubernetes/pkg/apis/core/v1/defaults.go
Line 99 in 7030246
func SetDefaults_Service(obj *v1.Service) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since it needs to get populated by the cloud controller manager, I'm not sure it's the right place. Either we don't default it or we loop through the ingress
once EnsureLoadBalancer
is called. (Not sure when the SetDefaults_Service
is called exactly)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@thockin and/or @andrewsykim would know better,
can you please advice here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a choice.
Do we want every consumer of Service status to find a value in this field? Or do we want the absence of a value to imply a default? Practically speaking, the default is "VIP" since that's what we historically have implemented, so I would be fine to default it as suggested.
pkg/proxy/ipvs/proxier.go
Outdated
for _, ingress := range svcInfo.LoadBalancerIPStrings() { | ||
if ingress != "" { | ||
for _, ingress := range svcInfo.LoadBalancerIngress() { | ||
if ingress.IP != "" && ingress.RouteType != v1.LoadBalancerRouteTypeProxy { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if kube-proxy runs against a previous version of the APIserver this field would not be available, should we check first if the field exists?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔 in this case the field would just be an empty string no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general we say that clients can be older than servers but not newer. If you want to be pedantic, you check for nil and handle it as the default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@thockin do you rather see a IPMode as a string
or as a *string
. If we set a default on create, I think we can safely use a string
and check of empty string instead of nil
?
/remove-sig api-machinery |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks pretty straight-forward. That said, new fields generally need to be gated and disabled by default, so we can do safe rollbacks. See pkg/features/kube_features.go
pkg/apis/core/types.go
Outdated
@@ -3406,8 +3406,23 @@ type LoadBalancerIngress struct { | |||
// (typically AWS load-balancers) | |||
// +optional | |||
Hostname string | |||
|
|||
// RouteType specifies the type of route to use for this ingress | |||
// Defaults to `VIP` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a choice.
Do we want every consumer of Service status to find a value in this field? Or do we want the absence of a value to imply a default? Practically speaking, the default is "VIP" since that's what we historically have implemented, so I would be fine to default it as suggested.
pkg/apis/core/types.go
Outdated
// RouteType specifies the type of route to use for this ingress | ||
// Defaults to `VIP` | ||
// +optional | ||
RouteType LoadBalancerRouteType |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
names: This only applies when IP
is set, right? So maybe call it ipType
or ipDeliveryMode
or something starting with ip
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ipMode
sounds good, wdyt?
staging/src/k8s.io/code-generator/cmd/informer-gen/generators/generic.go
Outdated
Show resolved
Hide resolved
pkg/proxy/ipvs/proxier.go
Outdated
for _, ingress := range svcInfo.LoadBalancerIPStrings() { | ||
if ingress != "" { | ||
for _, ingress := range svcInfo.LoadBalancerIngress() { | ||
if ingress.IP != "" && ingress.RouteType != v1.LoadBalancerRouteTypeProxy { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general we say that clients can be older than servers but not newer. If you want to be pedantic, you check for nil and handle it as the default
@Sh4d1 are you able to address Tim's comments above? 😄 |
Also wondering how a provisional kep was implemented? |
Hence my question, I initially thought it will get shipped with 1.21 (And completly forgot the
And I completly missed the ping on kubernetes/enhancements#1860 sorry! I personally see no objection to create an exception for this feature, was waiting on Tim's opinion. |
I don't mind creating an exception, but this is not trying to end-run around the rules. I lost track of which features were targetted for which release. I am sorry. @kikisdeliveryservice No intention to bypass the process, apologies. There's just a lot of cross-checks and I moved too fast. If you prefer to revert this, I don't object - we can re-propose it and sit on it (though in fact some of this wil make other PRs easier, so maybe we merge some internal parts and sit on the feature). |
Thanks @thockin i've brought this to the attention of the Release Leads and we'll let you know shortly. |
Commented on the KEP issue for this, but figured I'd drop in here too 👋 I think at this point (we're SUPER close to code freeze..), we should revert this and not push for 1.20. There is a KEP PR in flight in k/enhancements that targets 1.21, I think it would be best if we targeted 1.21 for this feature. @thockin maybe doing a revert and landing the internal parts of it would be acceptable, but we're also 2 days away from code freeze so..... I totally get that ya'll were not trying to bypass the process and things fall through the cracks...we're just kind of out of runway to get the KEP for this updated and start wrangling docs IMO. |
The alpha e2e job started failing ingress tests as soon as this was merged, see https://testgrid.k8s.io/google-gce#gci-gce-alpha-enabled-default&width=20 |
This is the failure message:
Which seems to indicate that this broke compatibility with a status update that previously worked |
|
||
if utilfeature.DefaultFeatureGate.Enabled(features.LoadBalancerIPMode) { | ||
if len(ingress.IP) > 0 && ingress.IPMode == nil { | ||
allErrs = append(allErrs, field.Required(idxPath.Child("ipMode"), "must be specified when `ip` is set")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is what is failing in the alpha e2e job, so apparently this field is not consistently defaulted. if so, we cannot make it required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, it was only defaulted on Service
, completly missed the Ingress
. Reverted in #96454 and I'll make sure to include ingress in the new one!
Revert "Merge pull request #92312 from Sh4d1/kep_1860"
@Sh4d1 hello! we'd like to remove this entry from 1.20 Release Notes since it was reverted. can you replace the release notes with cc: @andrewsykim |
@wilsonehusin oops, yes! Done 😄 |
) | ||
// jump to service firewall chain | ||
writeLine(proxier.natRules, append(args, "-j", string(fwChain))...) | ||
if !utilfeature.DefaultFeatureGate.Enabled(features.LoadBalancerIPMode) || *ingress.IPMode == v1.LoadBalancerIPModeVIP { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why we still need LB forward chain? Is there any rules can jump to LB forward chain if ingress IPMode is Proxy?
What type of PR is this?
/kind feature
What this PR does / why we need it:
Implements kubernetes/enhancements#1392
Which issue(s) this PR fixes:
Fixes #79783
Fixes #66607
Special notes for your reviewer:
Naming for the new field still needs to be agreed on
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
/hold
/cc @thockin
/cc @andrewsykim