|
1 | 1 | # KEP-4427: Relaxed DNS search string validation |
2 | 2 |
|
3 | | -<!-- |
4 | | -A table of contents is helpful for quickly jumping to sections of a KEP and for |
5 | | -highlighting any additional information provided beyond the standard KEP |
6 | | -template. |
7 | | -
|
8 | | -Ensure the TOC is wrapped with |
9 | | - <code><!-- toc --&rt;<!-- /toc --&rt;</code> |
10 | | -tags, and then generate with `hack/update-toc.sh`. |
11 | | ---> |
12 | | - |
13 | 3 | <!-- toc --> |
14 | | -- [Release Signoff Checklist](#release-signoff-checklist) |
15 | 4 | - [Summary](#summary) |
16 | 5 | - [Motivation](#motivation) |
17 | 6 | - [Goals](#goals) |
@@ -42,48 +31,6 @@ tags, and then generate with `hack/update-toc.sh`. |
42 | 31 | - [Alternatives](#alternatives) |
43 | 32 | <!-- /toc --> |
44 | 33 |
|
45 | | -## Release Signoff Checklist |
46 | | - |
47 | | -<!-- |
48 | | -**ACTION REQUIRED:** In order to merge code into a release, there must be an |
49 | | -issue in [kubernetes/enhancements] referencing this KEP and targeting a release |
50 | | -milestone **before the [Enhancement Freeze](https://git.k8s.io/sig-release/releases) |
51 | | -of the targeted release**. |
52 | | -
|
53 | | -For enhancements that make changes to code or processes/procedures in core |
54 | | -Kubernetes—i.e., [kubernetes/kubernetes], we require the following Release |
55 | | -Signoff checklist to be completed. |
56 | | -
|
57 | | -Check these off as they are completed for the Release Team to track. These |
58 | | -checklist items _must_ be updated for the enhancement to be released. |
59 | | ---> |
60 | | - |
61 | | -Items marked with (R) are required *prior to targeting to a milestone / release*. |
62 | | - |
63 | | -- [x] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR) |
64 | | -- [x] (R) KEP approvers have approved the KEP status as `implementable` |
65 | | -- [x] (R) Design details are appropriately documented |
66 | | -- [x] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input (including test refactors) |
67 | | - - [ ] e2e Tests for all Beta API Operations (endpoints) |
68 | | - - [ ] (R) Ensure GA e2e tests meet requirements for [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) |
69 | | - - [ ] (R) Minimum Two Week Window for GA e2e tests to prove flake free |
70 | | -- [x] (R) Graduation criteria is in place |
71 | | - - [ ] (R) [all GA Endpoints](https://github.com/kubernetes/community/pull/1806) must be hit by [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) |
72 | | -- [x] (R) Production readiness review completed |
73 | | -- [x] (R) Production readiness review approved |
74 | | -- [ ] "Implementation History" section is up-to-date for milestone |
75 | | -- [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io] |
76 | | -- [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes |
77 | | - |
78 | | -<!-- |
79 | | -**Note:** This checklist is iterative and should be reviewed and updated every time this enhancement is being considered for a milestone. |
80 | | ---> |
81 | | - |
82 | | -[kubernetes.io]: https://kubernetes.io/ |
83 | | -[kubernetes/enhancements]: https://git.k8s.io/enhancements |
84 | | -[kubernetes/kubernetes]: https://git.k8s.io/kubernetes |
85 | | -[kubernetes/website]: https://git.k8s.io/website |
86 | | - |
87 | 34 | ## Summary |
88 | 35 |
|
89 | 36 | Currently, Kubernetes validates search string in the `dnsConfig.searches` according to [RFC-1123](https://datatracker.ietf.org/doc/html/rfc1123) |
@@ -205,28 +152,12 @@ See Proposal |
205 | 152 |
|
206 | 153 | ### Test Plan |
207 | 154 |
|
208 | | -<!-- |
209 | | -**Note:** *Not required until targeted at a release.* |
210 | | -The goal is to ensure that we don't accept enhancements with inadequate testing. |
211 | | -
|
212 | | -All code is expected to have adequate tests (eventually with coverage |
213 | | -expectations). Please adhere to the [Kubernetes testing guidelines][testing-guidelines] |
214 | | -when drafting this test plan. |
215 | | -
|
216 | | -[testing-guidelines]: https://git.k8s.io/community/contributors/devel/sig-testing/testing.md |
217 | | ---> |
218 | | - |
219 | 155 | [x] I/we understand the owners of the involved components may require updates to |
220 | 156 | existing tests to make this code solid enough prior to committing the changes necessary |
221 | 157 | to implement this enhancement. |
222 | 158 |
|
223 | 159 | ##### Prerequisite testing updates |
224 | 160 |
|
225 | | -<!-- |
226 | | -Based on reviewers feedback describe what additional tests need to be added prior |
227 | | -implementing this enhancement to ensure the enhancements have also solid foundations. |
228 | | ---> |
229 | | - |
230 | 161 | ##### Unit tests |
231 | 162 |
|
232 | 163 | Added validation will be covered by unit tests along with unit tests covering the behavior |
@@ -292,46 +223,10 @@ does not depend on the container runtime or its version. |
292 | 223 |
|
293 | 224 | ## Production Readiness Review Questionnaire |
294 | 225 |
|
295 | | -<!-- |
296 | | -
|
297 | | -Production readiness reviews are intended to ensure that features merging into |
298 | | -Kubernetes are observable, scalable and supportable; can be safely operated in |
299 | | -production environments, and can be disabled or rolled back in the event they |
300 | | -cause increased failures in production. See more in the PRR KEP at |
301 | | -https://git.k8s.io/enhancements/keps/sig-architecture/1194-prod-readiness. |
302 | | -
|
303 | | -The production readiness review questionnaire must be completed and approved |
304 | | -for the KEP to move to `implementable` status and be included in the release. |
305 | | -
|
306 | | -In some cases, the questions below should also have answers in `kep.yaml`. This |
307 | | -is to enable automation to verify the presence of the review, and to reduce review |
308 | | -burden and latency. |
309 | | -
|
310 | | -The KEP must have a approver from the |
311 | | -[`prod-readiness-approvers`](http://git.k8s.io/enhancements/OWNERS_ALIASES) |
312 | | -team. Please reach out on the |
313 | | -[#prod-readiness](https://kubernetes.slack.com/archives/CPNHUMN74) channel if |
314 | | -you need any help or guidance. |
315 | | ---> |
316 | | - |
317 | 226 | ### Feature Enablement and Rollback |
318 | 227 |
|
319 | | -<!-- |
320 | | -This section must be completed when targeting alpha to a release. |
321 | | ---> |
322 | | - |
323 | 228 | ###### How can this feature be enabled / disabled in a live cluster? |
324 | 229 |
|
325 | | -<!-- |
326 | | -Pick one of these and delete the rest. |
327 | | -
|
328 | | -Documentation is available on [feature gate lifecycle] and expectations, as |
329 | | -well as the [existing list] of feature gates. |
330 | | -
|
331 | | -[feature gate lifecycle]: https://git.k8s.io/community/contributors/devel/sig-architecture/feature-gates.md |
332 | | -[existing list]: https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/ |
333 | | ---> |
334 | | - |
335 | 230 | - [x] Feature gate (also fill in values in `kep.yaml`) |
336 | 231 | - Feature gate name: RelaxedDNSSearchValidation |
337 | 232 | - Components depending on the feature gate: kube-apiserver |
@@ -359,9 +254,6 @@ Unit tests will cover cover the scenarios described in the Proposal section. |
359 | 254 |
|
360 | 255 | ### Rollout, Upgrade and Rollback Planning |
361 | 256 |
|
362 | | -<!-- |
363 | | -This section must be completed when targeting beta to a release. |
364 | | ---> |
365 | 257 |
|
366 | 258 | ###### How can a rollout or rollback fail? Can it impact already running workloads? |
367 | 259 |
|
|
385 | 277 |
|
386 | 278 | ###### Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested? |
387 | 279 |
|
388 | | -<!-- |
389 | | -Describe manual testing that was done and the outcomes. |
390 | | -Longer term, we may want to require automated upgrade/rollback tests, but we |
391 | | -are missing a bunch of machinery and tooling and can't do that now. |
392 | | ---> |
393 | | - |
394 | 280 | Tested by hand. |
395 | 281 |
|
396 | 282 | ###### Is the rollout accompanied by any deprecations and/or removals of features, APIs, fields of API types, flags, etc.? |
|
399 | 285 |
|
400 | 286 | ### Monitoring Requirements |
401 | 287 |
|
402 | | -<!-- |
403 | | -This section must be completed when targeting beta to a release. |
404 | | -
|
405 | | -For GA, this section is required: approvers should be able to confirm the |
406 | | -previous answers based on experience in the field. |
407 | | ---> |
408 | | - |
409 | 288 | ###### How can an operator determine if the feature is in use by workloads? |
410 | 289 |
|
411 | | -<!-- |
412 | | -Ideally, this should be a metric. Operations against the Kubernetes API (e.g., |
413 | | -checking if there are objects with field X set) may be a last resort. Avoid |
414 | | -logs or events for this purpose. |
415 | | ---> |
416 | 290 | Existence of an underscore the `dnsConfig.searches` array in any pod spec or pod spec template |
417 | 291 | would indicate the feature is in use. |
418 | 292 |
|
|
435 | 309 |
|
436 | 310 | ### Dependencies |
437 | 311 |
|
438 | | -<!-- |
439 | | -This section must be completed when targeting beta to a release. |
440 | | ---> |
441 | | - |
442 | 312 | ###### Does this feature depend on any specific services running in the cluster? |
443 | 313 |
|
444 | 314 | No. This is a change to API validation. |
|
477 | 347 |
|
478 | 348 | ### Troubleshooting |
479 | 349 |
|
480 | | -<!-- |
481 | | -This section must be completed when targeting beta to a release. |
482 | | -
|
483 | | -For GA, this section is required: approvers should be able to confirm the |
484 | | -previous answers based on experience in the field. |
485 | | -
|
486 | | -The Troubleshooting section currently serves the `Playbook` role. We may consider |
487 | | -splitting it into a dedicated `Playbook` document (potentially with some monitoring |
488 | | -details). For now, we leave it here. |
489 | | ---> |
490 | | - |
491 | 350 | ###### How does this feature react if the API server and/or etcd is unavailable? |
492 | 351 |
|
493 | 352 | N/A. This is a change to validation within the API server. |
|
517 | 376 | - [x] Code (`k/k`) update PR(s): |
518 | 377 | - https://github.com/kubernetes/kubernetes/pull/130128 |
519 | 378 | - [ ] Docs (`k/website`) update PR(s): |
| 379 | +- [x] GA |
| 380 | + - [x] KEP (`k/enhancements`) update PR(s): |
| 381 | + - https://github.com/kubernetes/enhancements/pull/5352 |
| 382 | + - [x] Code (`k/k`) update PR(s): |
| 383 | + - https://github.com/kubernetes/kubernetes/pull/132036 |
| 384 | + - [ ] Docs (`k/website`) update PR(s): |
520 | 385 |
|
521 | 386 | ## Drawbacks |
522 | 387 |
|
|
0 commit comments