one gem from #kubecon2023 is the talk on #kubernetes declarative validation and admission; https://www.youtube.com/watch?v=rFaWmd7Y7i0
1. you can use CEL validation rules inside #kubernetes CRD schemas: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules - and these are a lot more versatile than previous validation attributes - (GA in 1.29)
2. you can use CEL validation in a stand-alone ValidatingAdmissionPolicy. this allows opt-in validation on native/custom types (so you can e.g. create company wide-policies) - https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/ (beta in 1.28)
this is a pretty large part of what people use admission controllers / admission controller frameworks for, and I would not be surprised if this starts slowly killing off an entire class of complex cluster tooling in favour of native #kubernetes validation
the schema validation rules could also help make controllers even more language agnostic as when we map between schema <-> language structs (schemars / kopium + k8s-openapi on #rust side) these rules could be represented as code (and maybe long-term, be used to run client-side validation)
it would require some work on the rust side, but it's a lot more exciting to have this explicit than buried in a code comment on the golang side.
early issue for kube in https://github.com/kube-rs/kube/issues/1367
new kube.rs doc on #kubernetes admission via controllers or cel {validation,policies} at https://kube.rs/controllers/admission/ in time for 1.29