CRD "Strict mode" to validate schema on create and edit

[perithompson]

Please describe the problem you have

During the creation of new HTTPProxy resources, values, such as timeoutPolicy, can be incorrectly indented and the creation will be accepted without any errors or warnings. This can lead to long periods of troubleshooting believing the timeoutPolicy has been set correctly rather than being ignored. Could the CRD be edited to include a "strict mode" to validate the structure allowing for warnings to be presented for incorrect structure or prevent the object being created at all? This would greatly improve confidence in production deployments where it is important to validate the configuration is as expected.

[skriss]

xref #1978

[youngnick]

Thanks for this issue @perithompson. Functionally, we hope to deliver this by moving out CustomResourceDefinitions from v1alpha1 of the CRD object to v1 of the CRD object (#2678). That issue blocks a whole bunch of things, but we have been waiting until we could be reasonably confident that most of our users were running Kubernetes 1.16, which is the first version that had CRDv1 available.

Now that is the case, I'm hoping to push ahead with the CRDv1 work, which will enable pruning by default. Currently, when you send an object to the apiserver, any YAML that does not match the structural schema will be persisted to etcd, so when you ask for the object to check it, you'll get the full YAML, including the nonfunctional pieces back. CRDv1 has pruning enabled by default, while also enabling some other great features like kubectl explain (#1753).

Please keep watch on #2678, as that's currently blocking this feature. I'm not sure if we'll be able to get that change in for 1.9, but we will see what we can do. Could you confirm if you're using at least Kubernetes 1.16?

[perithompson]

Thanks for this @youngnick makes sense! Will add a watch to that issue, and in this case, it was Kubernetes 1.16.x where we experienced the problem.

[youngnick]

Awesome, I think I'm going to see if we can get CRDv1 into 1.9 - a big ask, but possible.