-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Add expanded DNS configuration KEP #2596
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
Conversation
a346c44 to
e78ec0f
Compare
| #### Alpha -> Beta Graduation | ||
|
|
||
| - Address feedback from alpha | ||
| - Sufficient testing | ||
|
|
||
| #### Beta -> GA Graduation |
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.
should we go to beta directly and enable it by 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.
I think it would be ok to enable it by 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.
the relaxed validation cannot allow new expanded data into objects by default in the first release, since it would allow data the previous API server version would choke on
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.
@liggitt
Isn't it enough to wrap the feature into the feature gate to make the user can disable it if there is such a case?
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.
no. that means that, by default, the first version of the API server including this feature allows storing unsafe data. we must default safe.
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.
Ah... I think you are right. Let's go to alpha and disable the feature by 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.
Agree. We can very likely skip beta, but we can't skip alpha
| status: implementable | ||
| creation-date: 2021-04-02 | ||
| reviewers: | ||
| - TBD |
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.
@claudiubelu do you know the implications of this resolv.conf changes in windows?
| --> | ||
|
|
||
| In HA(highly-available) clusters, all kube-apiservers should enable or disable | ||
| expanded DNS configuration feature. |
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.
there should be no problem meanwhile they don't create pods with an expanded DNSConfig
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.
I think we should avoid the situation that there is a HA cluster with 1.22 apiserver and 1.21 apiserver having a pod with expanded DNS configuration due to partial roll-back.
If a user updates the pod, it can be updated by 1.22 apiserver or blocked by 1.21 apiserver. That will be an inconsistent behavior.
|
LGTM, this was previously discussed here the problem was discussed here kubernetes/kubernetes#100583 the KEP and the feature gate will help to document the feature and give us the possibility to avoid surprises :) |
e78ec0f to
8b37167
Compare
|
What does this need in terms of docs? |
|
I think we need some documentation updates like
|
fedcf67 to
fce09c5
Compare
|
Only updated the release signoff checklist to the desired state. |
|
|
||
| ### Version Skew Strategy | ||
|
|
||
| In clusters with a replicated control plane, all kube-apiservers should enable |
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 more about kubelets. It is valid to have kubelets be a (slightly) lower version than apiserver. Looking at kubelet code I can see this will throw warnings (pkg/kubelet/network/dns/dns.go Configurer.CheckLimitsForResolvConf()) but that does not hard-fail. Still worth noting here.
In the same file, Configurer.formDNSSearchFitsLimits(), it does truncate. That is what is important to note here (and to test-confirm) -- back-rev kubelet should be fine, it will just truncate the results.
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.
Updated.
thanks @thockin
|
@johnbelamaric |
|
@johnbelamaric |
2ca6725 to
d7713c8
Compare
4852c0e to
19a2876
Compare
|
@thockin @johnbelamaric |
19a2876 to
ce72cc7
Compare
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gjkim42, johnbelamaric, thockin The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/lgtm |
|
|
||
| Yes, the feature can be disabled by disabling the feature gate. | ||
|
|
||
| Once the feature is disabled, kube-apiserver will reject the pod having expanded |
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.
@gjkim42 what happens to existing pods in the API when the feature gate is disabled, and then something tries to update non-DNS podSpec fields? Do those things just their update denied, even though they didn't change any relevant fields?
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.
what happens to existing pods in the API when the feature gate is disabled
The existing pods will be running with the expanded DNS config.
and then something tries to update non-DNS podSpec fields? Do those things just their update denied, even though they didn't change any relevant fields?
In v1.22 or higher, you can update non-DNSConfig podSpec fields, because we will add the exception.
(See the PR in progress.)
In v1.21 or lower(downgrade), any update requests will be denied, if the pod already had expanded DNS config.
|
Hello @gjkim42 👋 , 1.22 Docs Shadow here. This enhancement is marked as Needs Docs for 1.22 release. Thank you! |
Enhancement issue: #2595
previous discussion: kubernetes/kubernetes#100583